Internet 網關要求 - 起草

這個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%puclearcase/" target="_blank" >cc.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進展的結果一些修正加入本規范是可能發生的。 為得到在這個域中的更進一步的論述和建議參見RFC948 [ 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報頭中的其他的域、內部優先級和合理為基礎。 然而，這些機制極不大可能涉及一個對于網關本身的用戶記錄。