因特網網關模型不要求網關重裝具有目的地址而不是網關本身的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.