rfc985.txt

中文RFC 384 篇

[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文档中文翻译计划