[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文檔中文翻譯計劃