RFC 985

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：15222775@61.(15222775@61. hbzzx2001@yahoo.com.cn) 
译文发布时间：2002-3-2
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group                    Network Technical Advisory Group
Request for Comments: 985                NSF
                                         May 1986
Internet网关要求- -草案
(Requirements for Internet Gateways - Draft)
本备忘录状态
这个RFC总结了对于用于网络上支持DARPA网际协议的网关的需求。 同时它适用于国家科学基金会研究程序，技术要求用通俗的上下文给予规定，相信可适用于整个Internet团体。 这些文档是由NSF网络技术服务小组的网关要求小组委员会和Internet组织委员会、网间体系结构工作组和Internet工程工作小组共同合作制定的。 欢迎讨论和建议以进行改进。
本备忘录的分发不受限制。
本文档的宗旨是引导供应厂商提供可以用于Internet应用的产品或为在一个Internet应用中使用而改编产品。 它列举一些必需的协议而且给与RFCs参考和描述当前的规范的其它文档。 因为该规范正在逐渐发展所以可能包含不明确的或不完整的资料。 这样的话更进一步的详述给定被归入本文档的指导。 与NSF scientific网络团体有关的具体政策问题概括成一个附录。
*********************************************************************
这个是网关要求的报告书的草稿版。
注解可以在这个文档上找到而且可能并入最后的版。 注解是从如今开发的网关、网关的具体的供应厂商和潜在供应厂商那里搜索来的。 评论阶段截止86八月15用90天时间，在这一期间修订版将分配一个新RFC号码。
*********************************************************************
这个文档的建议和评论可以发给小组委员会会长Dave Mills ( mills@_usc - isid.arpa)，或NTAG委员会会长Dave Farber ( farber@_huey.udel.edu）。成员如下：
Hank Dardy， NRLdardy@nrl.arpa
Dave Farber， U Delawarefarber@huey.udel.edu
Dennis Jennings， JVNCjennings%pucc.bitnet@wiscvm.wisc.edu
Larry Landweber， U Wisconsin landweber@rsch.wisc.edu
Tony Lauck， DECrhea!bergil!lauck@decwrl.arpa
Dave Mills (Chairman)， Linkabit mills@usc-isid.arpa
Dennis Perry， DARPA/IPTOperry@ipto.arpa
小组委员会感谢以下投稿者和特邀稿件评审员∶
Len Bosack， Stanford U/CISCO bosack@su-score.arpa
Bob Braden， ISIbraden@isi-braden.arpa
Hans-Werner Braun， U Michiganhwb@gw.umich.edu
Noel Chiappa， MIT/Proteon jnc@proteon.arpa
Doug Comer， Purdue Udec@cs.purdue.edu
Ira Fuchs， Princeton U fuchs%pucc.bitnet@wiscvm.wisc.edu
Ed Krol， U Illinoiskrol%uiucvmd.bitnet@wiscvm.wisc.edu
Barry Leiner， RIACS leiner@riacs.arpa
Mike Muuss， BRLmike@brl.arpa
Ron Natalie， BRL ron@brl.arpa
Harvey Newman， CITnewman@cit-hex.arpa
Jon Postel， ISIpostel@usc-isib.arpa
Marshall Rose， NRTC mrose@nrtc-gremlin.northrop.com
Jeff Schiller， MITjis@bitsy.mit.edu
Lixia Zhang， MIT lixia@xx.lcs.mit.edu
1.介绍
以下各节为不熟悉DARPA网际体系结构和因特网网关模型的人士提供的介绍和背景知识。 关于网间体系结构和协议栈支持方面的一般背景和详述可以在DDN协议手册[ 25]和阿帕网参考手册[ 26]中可以找到，而且可以从网络信息中心、SRI International、Menlo Park、CA 94025中获得。 熟悉这些概念的读者可以直接进入第2节。
1.1. DARPA Internet体系结构
DARPA Internet系统由共同地为支持DARPA Internet协议体系结构的主机提供包运输的网络和许多网关组成。 这些协议包括 Internet协议( IP)、Internet控制消息协议( ICMP)、传输控制协议( TCP)和随他们而定的应用协议。 所有protocols都使用IP来作为基本的包-传送机构。 IP是一个数据报，或无连接服务，包含服务说明、分段/重组和安全信息规定。
ICMP被认为是IP不可分割的部分，尽管结构上位于IP之上。
ICMP提供错误报告、流量控制和初站网关重定向。 可靠的数据投递由协议栈中的TCP提供，它提供端到端重传、重新排序与连接控制。
无连接服务由用户数据报协议提供( UDP)。
Internet团体目前包括数千个连接到超过有120个网关的400多个网络上的主机。 现在注册ARPA单独域名的主机远远超过2400并且注册其他域名的主机还是个未知数，总数以每月百分之十的速度增加。 Internet团体中的许多主机、网关和网络由民间组织包括大学、研究实验室和设备制造商管理。 其余大部分由US DoD管理并且作为DDN Internet的一部分考虑，DDN Internet目前由个网络系统组成∶试验性部分或ARPANET、不保密的部分或MILNET、和被指定为机密的还没有集体名称部分。
Internet模型包含成分网络，称作局域网络将他们同国际互联网络系统区别开来，后者仅需要提供数据报(无连接)运输。 仅要求它“尽力”投递某个包或数据报。 每个数据报载有32位的源和目的地址，它们以三种格式编码，提供一个由两部分组成的地址，其中一个是本机的网络号码并且另一个是在那个本地网络上的主机号。按照国际互联网络服务说明，数据报可以无序传递、丢弃或复制与/或包含错误。 在那些提供了面向连接的服务的网络中，由于虚拟电路提供了额外的可靠性提高了系统的端到端的健壮性，但不是绝对需要。
在国际互联网模型中局域网的互相连接依赖于因特网网关。 这些网关仅仅提供了数据报传输以及设法使用尽量少的状态信息支持这种介于路由灵活性和健壮性之间的服务。 在传统模型中网关在每个局域网上具有一个物理接口和地址，这些局域网提供转发服务。 网关同时参与一个和多个分布式路由选择和可达性算法例如：用来维护它的路由表网关到网关协议或者外部网关协议用来维护它的路由表。
1.2.因特网网关模型
一个因特网网网关是一个完备的、独立的报文分组交换机，用来完成以下功能：
1.用来连接两个或更多个报文分组交换网络，包括封装、地址转换以及流量控制。
2.符合在这个文档中规定的具体DARPA互连网协议，包括互联网协议（IP）、互联网控制消息协议（ICMP），外部网关协议以及其他所需要的协议。
3.支持内部网关协议可达性或者路由算法，在一个系统中运行多个网关的情况下。为了在系统之间交换路由支持外部网关协议可达性路由算法，特别是工作于BBN的国防高级研究项目管理局核心系统。
4.按照在资源管理、拥塞控制以及公平性方面的技术接受和转发国际互联网数据报。 能够辨别各种各样的错误情况并且按照规定产生国际互联网信报控制协议错误以及信息报文。
5.提供系统支持工具，包括装载、调试、状态报告、异常报告和控制。
在某些情况下网关可能连接到一个分组交换局域网，这个局域网具有一般的局域网路由、错误控制和资源管理能力。 其他的网关可能通过串行线路直接相连，所以这些功能必须由网关的本身来提供。
网关制造商提供三种典型的方案：
1.国家或者区域网络。 这一类网关的应当具有交换多个连续不断地流量，每秒1.5兆比特范围内以每秒数千个包的速度。 他们应当是高性能具有冗余能力的多处理器设备，作为一个系统提供并且能够从一个遥远的或者国家的监控中心进行操作。这些网关的设计强调巨大吞吐量、对吞吐量敏感的资源管理和非常高的安全性。典型的应用就是国家科学基金会骨干网络或者是一个集团或者地区的网络。
2.校园网络。 这种类型的网络应当能够处理某些10兆比特每秒的突发流量的交换处理（以太网等等），处理某些64每秒千比特、每秒数千个包的速度范围内的流量。 他们是中等性能的设备，他们一般能够从不同的供应厂商那里获得，用于校园网络并在校园电子计算机中心进行控制。 这些网关的设计应当强调较低的平均延迟时间以及良好的处理突发事件的性能、能够提供对延迟以及类型服务敏感的资源管理。 他们的主要功能可能是去连接各种各样的局域网和校园计算资源，包括高速互联国家和区域网络。一个重要的因素就是非常灵活的路由机制，因为这些网关可能根据性能价格比选择某种骨干网络。
3.部门网络 这种类型的网络应当能够处理少量少量10兆比特每秒的突发流量的交换处理（以太网等等），处理少量少量64每秒千比特、每秒几百个包的速度范围内的流量。他们可能是从许多不同供应厂商那里取得的具有中等性能的设备，同时他们用来处理协议匹配、局域网中继都以及作为通用的报文分组交换。 他们可能是通过各种用户在本地进行维护，不能用作转接交换机。
重要的一点是能够实现在没有人照管的情况下互联网网关照样能够正常工作，但是设备以及软件的失误可能影响到整个互联网络。 虽然上面一些方案涉及某些来自监督中心的网关的绝对管制，通常通过一个包括其他的网络和因特网网关的路径，其它可能涉及更少的控制过程。
因此网关必须非常健壮并且被期望在，可能在一个恶化的情况，如极端拥挤或网络资源失败的条件下也能够运行。
⒉协议要求
Internet体系结构运用数据报网关互连网络和子网。 这些网关起中间系统( IS)的作用，具有对应于ISO无连接网络模型并且包括其定义的包格式、路由算法和有关程序。 在下文中假定协议实现支持全部协议，包括所有要求的选项，例外仅仅作为附注。
2.1. Internet协议( IP)
这是用于国际互联网络系统的基础数据报协议。
它在RFC - 791 [ 1]以及MIL - STD - 1777 [ 5]说明，其中两者都是用来描述同一个标准，但是却用了完全不同的措词。
根据当前网关要求，以下是能够忽略的，尽管将来可能需要他们: 业务域类型、安全选项、流式ID选项和时间戳选项。
然而，为了辨认，这些参数的解释必须符合该标准规范。
因特网网关模型不要求网关重装具有目的地址而不是网关本身的IP数据报。 然而，至于那些网关直接作为一个同位体参加的协议，包括routing和monitor/control协议，网关可能必须重装配发给it的数据报。这个考虑大多于EGP相干。
注意， IP地址的五种分类。 从A类到E类， D类和E类地址专供试验性之用。 那些不参予这些实验的网关应该忽略所有具有一个D类或E类目的地IP地址的包。 接收这样的包不会不会导致ICMP Destination Unreachable（目的地不可达）或ICMP重定向报文。
2.2. Internet控制消息协议( ICMP)
这是一个辅助协议，用于传达通知和错误报文，并且在RFC - 792 [ 2]中给于描述。
一个网络的子网之间的区别，取决于一个任意的如RFC - 950 [ 21]描写的掩码，对于那个网络外部通常是不可见的。 这个区别在某些ICMP报文中是很重要的， ICMP
目的地不可达和ICMP重定向报文也是如此。 ICMP目的地不可达报文是由一个响应那些因为目的地不可达或停机而不能被转发的数据报的网关发送的。 可以选择几种类型，包括一个指定目的网络然后另一个指定目的地主机。然而，前者暗示的地址范围是不确定的，除非该子网屏蔽为发送者所知，但一般情况下不是这样。 最好避免使用ICMP目的地网络不可达报文。 作为替代，一个ICMP目的主机不可达报文应该发送到每一个不同不可达IP地址。
为一个指定的主机或网络，ICMP重定向报文由一个网关发送给一个主机，以便改变有主机所用的地址。取决于它应用于一个具体的主机、网络或服务，可以在四种报文类型中加以选择。
象在前一情况一样，这些区别可能随子网掩码而定。 象上述情况一样，最好通过利用ICMP报文暗示一个地址范围(例如网络不可达，网络重定向)，有利于暗示具体地址(例如主机不可达、主机重定向)。
ICMP源熄灭报文已经成为论争的课题。 当这个报文被一个主机或网关产生或解释时详细地规定那些情况是不现实的。
新的主机和网关实现预计支持ICMP地址掩码报文，在RFC - 950中详细描述了ICMP地址掩码报文。 尽管不需要为ICMP时间戳报文提供校正数据功能，但它是非常令人想要的，因为已经发现为ICMP时间戳报文提供校正数据功能对网络调试和网络维护是非常有用的。
2.3.外部网关协议( EGP)
这是用于在Internet的网关系统之间交换信息的基础协议，在RFC - 904 [ 11]中详细描述了该协议。
然而， EGP按照目前的定义是一个不对称协议，仅仅具有在RFC - 904中定义的“非内核”程序。 目前不存在规定的"内核"程序，但是"内核"程序是建立一个与操作系统无关Internet所必需的。 RFC - 975 [ 27]提议进行某些修改产生一个对称模型; 然而，这不是一个官方规范。
原则上，能够建立一个具有“非核心”EGP网关的、与操作系统无关Internet，它使用EGP距离域去传送某些公制例如站数。 然而，在这种方法中禁止将EGP作为一个路由算法，因为标准的实现采用非常地慢地改变拓扑并且没有防止回路特性。
EGP模型要求每个网关属于一个网关的自治系统。 如果一个路由算法运行于一个自治系统的一个或多个网关之中，它的数据库必须与EGP实现相关连，这时，当一个网络声明由于路由算法停机时，该网络还通过EGP向其他的自治系统声明停机。 这个是最小化使通信去"黑洞"的设计的必要条件，并且保障在其他的系统上公平的利用资源。
目前EGP规范没有定义同位体发现或鉴别程序并且没有定义在更新报文中的距离域的解释，这样的程序可能将来定义(参见RFC - 975)。 当前no存在轮询参数选择的指导而且没有具体恢复程序以防万一某些报文错误
(例如"政府禁止")。 EGP实现最好包括初始化这些参数的规定作为监视与控制程序的一部分而且改变这些程序而不要求重新编译重新启动该网关。
2.4.地址解析协议( ARP)
这是一个辅助协议用于管理在一个局部网络环境中的机器地址和Internet地址之间的地址转换功能，在RFC - 826 [ 4]中详细描述了地址解析协议( ARP)。然而，存在许多与子网有关的不能解析的问题和对地址的响应不在同一个子网络或网络中。这个问题，与ICMP和各种各样的网关模型缠绕在一起，在附录A详细讨论。
⒊子网划分
子网划分的概念被引进以便允许在一个组织内部任意复杂的互连LAN组织，虽然Internet系统反对在网络号码和routing复杂性方面的迅速增长。 子网络体系结构在RFC - 950 [ 21]中详细描述，是用来规定一个标准方法，不必为主机实现重新配置，与子网划分方案无关。 该文档还有规定了一个新的ICMP地址掩码报文，一个网关能够为主机规定某些子网络方案的细节，在新的主机和网关实现中被要求。
当前子网络规范RFC - 950未描述网关使用的具体程序。
最好为每个网络接口提供一个(子)网络地址和地址掩码而且这些值作为该网关配置过程的一部分制定。 在任何具体的网关运行期间通常不必改变这些值；然而，可以增加新网关与/和(子)网络而且修改一个网关的配置而不必让整个网络停机。
⒋局部网络接口
用于在各种各样的子网上传输数据报的包格式，在下列大量文档中详细描述。
4.1.经由X.25的公用数据网
为经由x.25访问的公用数据网规定的格式是在RFC - 877 [ 8]中详细描述。 数据报通过标准３层虚拟电路按照正确的分组序列传送。 虚拟电路通常根据需要动态地建立而且一段时期之后仍没有通信量便超时。 网络通过LAPB链路级协议为每个虚拟电路完成重传、重新排序和流量控制。 为了改善用户入口线的利用经常使用多个并行虚拟电路，那些可能导致偶然重新排序。 通常通过一览表建立Internet和x.121地址之间的一致性。将来可能被一种目录程序替代。
4.2.经由1822本地主机、遥远的主机或HDLC遥远的主机的ARPANET
为经由1822访问的阿帕网规定的格式在BBN报告1822 [ 3]中详细描述，包括若干用户接入方法手续。 本地主机( LH)和非常地遥远的主机( VDH)方法不推荐新的实现。 遥远的主机( DH)方法当主机和IMP由不多于2000英里电缆连接时使用，而HDLC遥远的主机用于巨大的距离，这里要求一个调制解调器。 当使用时，网络通过HDLC链路级协议为每个虚拟电路完成重传、重新排序和流量控制。 而ARPANET 1822协议目前已经被广泛地使用，预计他们最后超越DDN标准X.25协议(见下文)而且在RFC - 979 [ 29]中详细描述了新的PSN点到点传输协议。
提到的报告给与各种各样的ARPANET用户接入方法的详细资料它既不规定IP信息包封装格式也不规定地址变换。 这些通常是简单的而且便于实现，详细资料超出容易地访问的文档的范围。为索取补充资料，潜在性供应厂商鼓励联系这文档的启始部分。
连接到ARPANET/MILNET IMPs的网关必须包括避免主机-端口堵塞( RFNM计算)的部件而且为侦听和报告(象ICMP不可达报文一样)目的主机或网关的失败。
4.3.经由DDN标准x.25的阿帕网
这些为经由x.25的ARPANET网络的格式在国防数据网x.25主机接口规范[ 6]中详细描述。
这个文档描述两组程序， DDN Basic X.25和DDN Standard X.25，但是只有后者适合于在Internet系统中使用。 除了在地址映射不同外， DDN Standard X.25程序与公众数据子网x.25程序相似，网络通过LAPB链路级协议为每个虚拟电路完成重传、重新排序和流量控制。
4.4.以太网
为以太网规定的格式在RFC - 894 [ 10]中详细描述。数据报按照具有48位源和目的地地址字段和一个16位类型字段的以太网信息包压缩。 以太网地址和Internet地址之间的地址转换通过地址解析协议做到，地址解析协议在所有以太网实现中都被要求。 没有显式重传、重新排序或流量控制。 尽管大多数硬件接口可能在电缆冲突的情况下自动地重传输。
作为IEEE 802.3进展的结果一些修正加入本规范是可能发生的。 为得到在这个域中的更进一步的论述和建议参见RFC 948 [ 20]。 还要注意IP广播地址， IP广播地址已经成为以太网和类似技术的初始应用
在IP地址的主机域具有一个全1值。 某些原始实现为此选择全0值，不与目前RFC - 950 [ 21]定义的规范一致。
更进一步的需要考虑的事项参见附录一个。
4.5.串行线路协议
为了建立网络网关可能用作分组交换机。在某些配置中网关可能借助于异步或同步串行线路（有或者没有调制解调器）彼此相互连接，并和某些主机相互连接。 当以预计误差速度和其它因素来证明它是正确的的时候，可能在该串行的线路上需要一个链路级协议。虽然没有必要为此使用一个具体的标准规约，最好使用标准硬件和协议，除非有反对原因。 为了支持配置的很大的差异性，最好允许这里使用的资源在全部x.25 (例如"对称型")上的能发生变化; 然而， X.25 LAPB可能还是可接受的。 在异步线不明确的选择情况下。
⒌互用性
为了保证从不同的供应厂商获得的网关间的互用性，必须规定协议定界点。 关于路由选择功能的互用性，按照EGP规定。 所有网关系统必须包括一个或多个网关（用一个核心网关支持EGP），如RFC - 904 [ 11]所描写。 网关最好能够在这样一个模式中操作，这个模式不需要一个核心网关或核心系统。 关于这些问题的补充论述能够在RFC - 975 [ 27 ]中发现。
关于在网络层和网络层在下面的互用性，已经规定两个协议分界点，一个协议分界点为以太网规定而且另一个协议分界点为串行线路规定。 在以太网情况下，那些协议按照4.4节和这个文档附录A规定。 对于不同供应厂商的网关间的串行线路，这些协议在这个文档的4.5节详细说明。
有时候对这些要求对例外情况也适合。
⒍子网体系结构
为建立中等尺寸的网络这些网关同时可能起普通分组交换机作用。 这个要求辅助功能以便管理网络路由选择、控制和配置。 虽然规定用于任何具体的、也许专利的体系结构的机制的细节超出这个文档的范围，但是大量基本要求必须由任何可接受的体系结构提供。
6.1.可达性程序
健壮该体系结构必须提供一个健壮机制，以便建立在网络中的每个链接与节点（包括各种网关）的工作状态，这些链接连接他们而且也连接这些主机。 通常，这些至少要求一个链路级可达性协议，这个链路级可达性协议越过每个链接一个定期交换“Hello”报文。 这些功能也许应该是固有的，供链路级协议使用的例如LAPB（平衡型链路接入协议）DDCMP（数字数据通信报文协议）。 然而，假定一个主机或网关不管它的链路级可达性协议操作是否正确，它都能正确地运转通常是不明智的。 另外，确认被要求用一个运行的路由算法或同等层级可达性协议（例如用于EGP的）形式。
一个链接与/和网关的故障和恢复通常被认为网络事件而且必须汇报给控制中心。 尽管不需要报告路径本身不要求改正路由算法的功能但是它是所希望的。
6.2.路由算法
参与路由选择机制（不管静态的或动态的）的国际互联网络团体的反复经验是最主要的工程问题在于网络设计。 在所有且平常的网络拓扑中，必要的路由的动态程度为有效运行所不可缺少的，不管它受人工或自动方法或两者兼而有之的影响。 特别是，如果路由变更是手工地制做的，改变必须允许为重新配置而不拆卸网关，更可取地，改变可能来自一个远地例如一个远地控制中心。
因为所有网络能够由一个经营全部业务控制中心维护是不可能的，所以自动-替换或改换路由功能部件也许被要求。 这个通常被认为正常情况，所以作为网络中的唯一的分组交换机的网关系统应该拥有一个路由算法，路由算法做对链接和其它网关故障作出反应的能力而且自动地唤起改变。
下面是一列被认为必需的功能部件∶
1.该算法必须检测一个链接或其他的网关的故障或恢复而且在一个小于标准的TCP用户超时时间间隔内(一个分钟是一个可靠的假定)转到适当的路径。
2.该算法决不能形成邻机网关间路由回路并且必须包含避免和扼制可能在非邻机网关之间形成的路由回路的规定。 一个回路时间决不应该长于标准的TCP user超时时间间隔。
3.控制通信量必须操作路由算法。不可较大地降级或毁坏正常网络操作。在那些在一个局部地区中的可能随时地毁坏正常运行状态方面变化不可给在边远的地区的网络带来破坏。
4.如果网络的尺寸增加，资源需要必须用一个有效方法控制。 ，比如，参考表格应该复述而且数据库更新零碎的处理、改变用广播散播到一个很广的范围。 可达性和延迟公制，如果使用，不可直接取决于去所有其他的网关连通性或具体网络广播机制的应用。轮询过程(例如为了保持一致性的检查)应该仅仅少量使用而且决不可引进一个超出一个独立于网络布局的常数开销。
5.通过利用一个缺省网关作为一个减少路由选择数据尺寸的方法，鉴于多路径、回路和错配置弱点等许多问题被强烈地阻止。 如果使用，它应该限于一个发现功能，用经由路由算法或者EGP外部或内部数据库贮藏的路由。
6.这个文档不对路由算法的类型限制，类型有基于节点、基于链接或任何其他的算法、或公制例如延迟或路程段计算。 然而路由数据库的尺寸不允许超出一个独立于网络布局计计算时间的数目(附属链接的平均数)常数。 一个先进设计不会要求全部的路由数据库受控制于任何具体的网关，所以发现和高速缓存技术可能是必需的。
⒎运行和维护
网关和分组交换机经常作为一个系统，某些组织同意操作和维护这些网关以及与相应的电信公司一起解决链接问题。注意那些网络控制地点可能不是物理上连接受控网络是很重要的。 通常，适用如下必要条件∶
1.每个网关必须对于局部硬件维护目的是一个独立装置。 意指必须可以在该网关地点仅仅使用现场的工具（也许仅仅一个磁盘磁带和本地终端）就能用来运行诊断程序。 虽然不要求但是希望在有的故障情况下经由网络运行诊断并且经由该网络自动重新启动和转储。 通常这些需要专用设备。
通过利用成熟的传输服务例如TCP通常是不明智的，如果只是需要重新启动和转储该网关。需要考虑的事项应该是给定的以UDP或具体监控协议例如HMP为基础单重传覆盖协议，HMP（主机监督协议）在RFC - 869 [ 7]中详细描述。
2.它必须对从该控制场地手工地重新启动和转储该网关来说是可能的。 每个网关必须包括一个或者启动一个重新启动或者遥控地点信号监视时钟，如果该软件不定期重新设置的话。 该涉及数据最好居住位于控制场地并且经由该网络传送；然而，通过利用在该网关地点本地设备是可接受的。然而，启动重新引导或转储的操作必须是经由该网络可用的，假定一个路径生效并且连接链路链接是运行着的。
⒊必须提供A机制去聚集通信量统计包括但不限于包标签、错误报文标签等等。 检索这些数据的较佳的方法是显式的方法，定期要求控制场地使用一个以UDP或 HMP为基础标准数据报协议。
 通过利用成熟的传输服务例如TCP通常是不明智的，如果只是需要收取发自该网关的统计资料。需要考虑的事项应该是给定的以UDP或具体监控协议例如HMP为基础单重传覆盖协议，HMP（主机监督协议）在RFC - 869 [ 7]中详细描述。
4.异常报告( "陷阱")作为硬件或软件故障的结果存在，(可能的时候批量减少包开销)这些软件故障应给立即使用一个以UDP或HMP为基础标准数据报协议传输给控制场地。
必须提供一个机制以便显示在控制场地的链路链接与节点状态的连续不断的库。 最好是所有生效链路链接与节点的完整的映射，但是只显示由于路由算法停机而使用的元件也是可接受的。 这些信息通常在控制场地局部可用的，假定是一个参与该路由算法的地点。
上述功能通常需要于一个控制场地或代理合作。 提供这些功能的更可取的方法是作为一个用户程序提供一个适合于在标准软件环境例如UNIX操作系统中运行的程序。 该程序可能使用标准IP协议例如TCP传输控制协议、UDP用户数据报文协议和HMP主机监控协议去控制和监视那些网关。 通过利用专门定做需要重大的额外投资的主机硬件和软件是强烈地阻止的；然而，某些供应厂商可能推选供应控制代理作为网关作为其中一部分的网络的必要的组成部分。如果是这种情况，一个可以用来从一个远地使用Internet协议和路径操作该控制代理的方法是需要的，并且具有关于局部代理终端相等的功能。
经由国际互联网络路径遥控一个网关可能涉及一个直接手段，或者一个间接手段，其中该网关直接支持TCP与/和UDP，该直接手段控制代理支持这些协议并且使用专有协议控制该网关本身。前者是更可取的，尽管随便任一个方法都是可接受的。
⒏参考和文献目录
[1]Defense Advanced Research Projects Agency， "Internet Protocol"，DARPA Network Working Group Report RFC-791， USC Information Sciences Institute， September 1981.
[2]Defense Advanced Research Projects Agency， "Internet Control Message Protocol"， DARPA Network Working Group Report RFC-792， USC Information Sciences Institute， September 1981.
[3]Advanced Research Projects Agency， "Interface Message Processor - Specifications for the Interconnection of a Host and an IMP"， BBN Report 1822， Bolt Beranek and Newman， December 1981.
[4]Plummer， D.， "An Ethernet Address Resolution Protocol"， DARPA Network Working Group Report RFC-826， Symbolics， September 1982.
[5]United States Department of Defense， "Military Standard Internet Protocol"， Military Standard MIL-STD-1777， August 1983.

[6]Defense Communications Agency， "Defense Data Network X.25 Host Interface Specification"， BBN Communications， December 1983.
[7]Hinden， R.， "A Host Monitoring Protocol"， DARPA Network Working Group Report RFC-869， BBN Communications， December 1983.
[8]Korb， J.T.， "A Standard for the Transmission of IP Datagrams over Public Data Networks"， DARPA Network Working Group Report RFC-877， Purdue University， September 1983.
[9]Nagle， J.， "Congestion Control in IP/TCP Internetworks"， DARPA Network Working Group Report RFC-896， Ford Aerospace， January 1984.
[10] Hornig， C.， "A Standard for the Transmission of IP Datagrams over Ethernet Networks"， DARPA Network Working Group Report RFC-894， Symbolics， April 1984.
[11] Mills， D.L.， "Exterior Gateway formal Specification"， DARPA Network Working Group Report RFC-904， M/A-COM Linkabit，April 1984.
[12] Postel， J.， and J. Reynolds.， "ARPA-Internet Protocol Policy"， DARPA Network Working Group Report RFC-902， USC Information Sciences Institute， July 1984.
[13] Kirton， P.， "EGP Gateway under Berkeley UNIX 4.2"， DARPA Network Working Group Report RFC-911， USC Information Sciences Institute， August 1984.
[14] Postel， J.， "Multi-LAN Address Resolution"， DARPA Network Working Group Report RFC-925， USC Information Sciences Institute， October 1984.
[15] International Standards Organization， "Protocol for Providing the Connectionless-Mode Network Services"， DARPA Network Working Group Report RFC-926， International Standards Organization，December 1984.
[16] National Research Council， "Transport Protocols for Department of Defense Data Networks"， DARPA Network Working Group Report RFC-942， National Research Council， March 1985.
[17] Postel， J.， "DOD Statement on NRC Report"， DARPA Network Working Group Report RFC-945， USC Information Sciences Institute，April 1985.
[18] International Standards Organization， "Addendum to the Network Service Definition Covering Network Layer Addressing"， DARPA Network Working Group Report RFC-941， International Standards Organization， April 1985.
[19] Leiner， B.， J. Postel， R. Cole and D. Mills， "The DARPA Internet Protocol Suite"， Proceedings INFOCOM 85， Washington DC，March 1985]Also in: IEEE Communications Magazine， March 1985.
[20] Winston， I.， "Two Methods for the Transmission of IP Datagrams over IEEE 802.3 Networks"， DARPA Network Working Group Report RFC-948， University of Pennsylvania， June 1985.
[21] Mogul， J.， and J. Postel， "Internet Standard Subnetting Procedure"， DARPA Network Working Group Report RFC-950， Stanford University， August 1985.
[22] Reynolds， J.， and J. Postel， "Official ARPA-Internet Protocols"，DARPA Network Working Group Report RFC-961， USC Information Sciences Institute， October 1985.
[23] Reynolds， J.， and J. Postel， "Assigned Numbers"， DARPA Network Working Group Report RFC-960， USC Information Sciences Institute， December 1985.
[24] Nagle， J.， "On Packet Switches with Infinite Storage"， DARPA Network Working Group Report RFC-970， Ford Aerospace，December 1985.
[25] Defense Communications Agency， "DDN Protocol Handbook"，NIC-50004， NIC-50005， NIC-50006， (three volumes)， SRI International， December 1985.
[26] Defense Communications Agency， "ARPANET Information Brochure"，NIC-50003， SRI International， December 1985.
[27] Mills， D.L.， "Autonomous Confederations"， DARPA Network Working Group Report RFC-975， M/A-COM Linkabit， February 1986.
[28] Jacobsen， O.， and J. Postel， "Protocol Document Order Information"，DARPA Network Working Group Report RFC-980， SRI International， March 1986.
[29] Malis， A.G.， "PSN End-to-End Functional Specification"， DARPA Network Working Group Report RFC-979， BBN Communications，March 1986.
附录A.以太网管理
下面是在一个规定在以太网上的主机和网关所用的程序摘要信息。
A.1.硬件
只有当它的目的地以太网地址匹配分配的接口地址或者一个广播/多点播送地址时才接受一个来自电缆的包。 过滤估计可能是由接口硬件完成; 然而，如果硬件不工作软件驱动程序应该完成。 某些主机包括一个任选功能，这种任选功能于具有一个具体子网络的指派的多点播送地址关联以便限制对于测试等等的访问。这个功能部件激活的时候，被指派的多点播送地址替换该广播地址。
A.2. IP数据报
在广播/多点播送(根据目的地以太网地址决定)情况下一个IP数据报被丢弃，如果按照分配的主机IP地址和子网掩码判断的结果该源IP地址不同于子网络的话。 最好这测试由一个配置参数替换，为了支持罕见的情况（多于一个子网络可能共存在相同电缆上）。
A.3. ARP（地址分辨协议）数据报
一个ARP应答被丢弃，如果目的地IP地址不匹配本地主机地址。 一个ARP请求被丢弃，如果该源IP地址不同于子网络。 最好这测试由一个配置参数替换，为了支持罕见的情况（多于一个子网络可能共存在相同电缆上），参见RFC - 925。 一个ARP应答只有当目的地协议IP地址从本地主机(按照判断由于路由算法停机)时可以达到才产生并且下一个路程段不经由相同接口。 如果该本地主机起一个网关作用，这个可能导致ARP应答不在同一个子网络里的目的地。
A.4. ICMP重定向
一个ICMP重定向被丢弃如果目的地IP地址不匹配本地主机地址或新的目标地址不在同一个子网络。 一个接收的重定更新路由数据库旧的目标地址。 如果没有路由或与旧的目标地址有关，那些重定向被忽略。
如果旧的路由与一个缺省网关相联系，一个与新目标地址有关新路由插入该数据库。 注意不可能发送一个无理由的重定向除非发送者拥有相当多想象力。
当用子网络的时候，存在某些模糊的重定向范围，除非所有涉及的主机和网关都事先了解该子网掩码。 通过避免利用ICMP网络重定向报文有利于ICMP主机重定向报文。 这个需要原发送端(例如重定向接收器)支持一个普通IP地址转换高速缓存，而非通常的网络列表。
然而，这个正常地是在ARP情况下完成。
一个ICMP重定向只有当目的地IP地址从本地主机(按照判断由于路由算法停机)可以达到时才产生，并且目标地址在路由数据库中定义，下一个路程段经由同一个接口。 重定向决不会在给一个IP网络或子网络广播地址的响应中发送或在给一个D类或E类IP地址响应中发送。
ICMP重定向决不转发，与目的地址无关。 ICMP重定向本身的源IP地址不被检查，因为发送网关可能使用它的不在普遍的网络上的一个地址。压缩IP数据报源IP地址不被检查，在假定该主机或网关发送该初始IP数据报上知道它是怎么完成的。
附录B.政策问题
以下那些节论述某些特别关心NSF科学的网络团体的问题。 这个问题拥有在该政策范围中的原始参考有关，而且在技术区拥有分支。
b.1.互连技术b.1.互连技术
当前不同的供应厂商的Internet系统间的最重要的普遍的互连技术是Ethernet（以太网）。 其中的理由如下∶
1.以太网规范已被充分理解而且成熟
2.以太网技术几乎所有的方面是独立于供应厂商。
3.以太网配套的系统越来越普遍
这些优越性组合有利于使用以太网技术作为NSF网络系统间的分界交叉点，NSF网络系统由不同的供应厂商供应，该网络系统与技术无关。 NSF网关的一个必要条件是尽可能用用于一个给定的供应厂商供应网的交换技术所有权，它的网关必须支持一个连接其他的供应厂商的网关以太网。
NSF网关要求将来可能规定其他的互连技术，这是可能发生的。 最可能候选人是那些以x.25或IEEE 802为基础的技术，但是其他的技术包括宽带电缆、光纤的或其他的协议例如DDCMP同时可能被考虑。
所有权和可扩展问题
Internet技术是一个正在发展着的、可适应的技术。 尽管支持这些技术的主机、网关和网络已经连续运转许多年，供应厂商用户和操作者应该知道不是所有网络问题已经都被充分地理解。因此，当新的需要或更好的解决方案被开发出来供NSF网络里使用的时候也许必须需要新的协议。 一般说来，这些新的协议可能被设计成所有应用方面与存在协议具有互操作性;然而，它可能偶而发生，就是说现有的系统必须提高到支持这些协议的程度。
NSF系统供应商应该理解他们还要保证留意当前Internet技术的发展而且准备不时地酌情升级它们的产品。 因此，强烈地鼓励这些供应厂商考虑产品的可延伸性并且根据它们的产品的基本性能定期进行升级。 一个最大的成效以及长期坚持这样做的回报的方式就是和学术界合作参与前进的Internet研究和开发程序，。
B.3.多协议网关
尽管对于一个NSF网关技术要求当前仅仅规定Internet协议组，支持将来的协议组并且允许同时操作多于一个的协议组也是合乎需要的东西。
无疑地， ISO协议栈是作为这些组其中最初的候选人之一。 其他的候选人包括XNS和DECnet。
对于NSF网关未来需求可能包括供应除Internet之外其他的协议栈以及他们之间互相配合的模型和规范， 举例来说， ISO组最后可能成为最大一个是可能发生的; 然而，还要求支持其他的组。
当前NSF网关要求不包括上面网络层协议，例如TCP，除非为网络监视或控制所必需。 供应厂商应该承认未来需求在Internet和ISO应用程序之间交互工作，比如，可能导致一个可能――网关在各级直到应用程序级上都要支持多个协议。 包括在这个文档的网络级NSF网关要求可能被结合进应用层网关必要条件文档。
B.4.存取控制和记帐
当时设计中没有要求包括具体存取控制和记帐机制； 然而，这些重要议题当前正在研究中并且可能已经并入一个在最近期间重新起草的文档之中。 鼓励供应厂商在它们的产品中尽快引进这些机制。 虽然没有为当时已经浮现的存取控制和记帐定义通用模式，可以描述这些模型看上去应该具有的一般特征，他们中的一些应该如下∶
1.主要存取控制和管理帐户机制可能位于主机服务本身之中，而不是网关、分组交换机或工作站。
2影响存取控制和管理帐户机制的利益代理也许必须在网关、分组交换机或工作站内。 这些可能用来进行资料搜集、执行口令保护或调节资源优先权和合理性。 然而，用于这些代理的体系结构和协议可能是一个局部事情但是预先规定是不可能的。
3. NSF网关也许要求包括存取控制和会计机制，以包源/目的地址以及在IP报头中的其他的域、内部优先级和合理为基础。 然而，这些机制极不大可能涉及一个对于网关本身的用户记录。
RFC 985――Requirements for Internet Gateways -- Draft              Internet网关要求- -草案




1
RFC文档中文翻译计划