RFC 1122A

網絡工做組互聯網工程任務組
徵求意見：1122 R. Braden，編輯
1989年10月

Internet主機的要求 - 通訊層

本備忘錄的狀態

此RFC是Internet社區的官方規範。它
經過引用，修改，糾正和補充
與主機相關的主協議標準文檔。分配
這份文件是無限的。

概要

這是定義和討論需求的一對RFC
用於Internet主機軟件。該RFC涵蓋了通訊
協議層：鏈路層，IP層和傳輸層; 它的
配套RFC-1123涵蓋了應用程序和支持協議。

目錄

1.介紹...............................................五
1.1互聯網架構.............................. 6
1.1.1互聯網主機.................................... 6
1.1.2建築假設......................... 7
1.1.3互聯網協議套件........................... 8
1.1.4嵌入式網關代碼............................. 10
1.2通常考慮因素................................. 12
1.2.1繼續互聯網發展..................... 12
1.2.2穩健性原則.............................. 12
1.2.3錯誤記錄..................................... 13
1.2.4配置..................................... 14
1.3閱讀本文件.................................. 15
1.3.1組織...................................... 15
1.3.2要求...................................... 16
1.3.3術語....................................... 17
1.4致謝........................................ 20

2. LINK LAYER .............................................. .... 21
   2.1引言........................................... 21

互聯網工程任務組[第1頁]

RFC1122引言1989年10月

2.2議定書步行.................................. 21
  2.3具體問題........................................ 21
     2.3.1預告片協議談判...................... 21
     2.3.2地址解析協議 -  ARP ................ 22
        2.3.2.1 ARP緩存驗證......................... 22
        2.3.2.2 ARP包隊列............................. 24
     2.3.3以太網和IEEE 802封裝............... 24
  2.4 LINK / INTERNET LAYER INTERFACE .......................... 25
  2.5連接層要求摘要........................ 26

3. INTERNET LAYER PROTOCOLS .................................... 27
   3.1引言............................................ 27
   3.2協議步行.................................. 29
   3.2.1互聯網協議 - IP ............................ 29
   3.2.1.1版本號............................... 29
   3.2.1.2校驗和..................................... 29
   3.2.1.3尋址................................... 29
   3.2.1.4碎片和重組................. 32
   3.2.1.5識別................................ 32
   3.2.1.6服務類型.............................. 33
   3.2.1.7生存時間................................. 34
   3.2.1.8選項...................................... 35
   3.2.2互聯網控制消息協議 - ICMP .......... 38
   3.2.2.1目的地沒法到達...................... 39
   3.2.2.2重定向..................................... 40
   3.2.2.3源淬火................................ 41
   3.2.2.4超過期間................................ 41
   3.2.2.5參數問題............................ 42
   3.2.2.6迴應請求/回覆........................... 42
   3.2.2.7信息請求/回覆.................... 43
   3.2.2.8時間戳和時間戳回覆................ 43
   3.2.2.9地址掩碼請求/回覆................... 45
   3.2.3互聯網組管理協議IGMP ........... 47
   3.3具體問題........................................ 47
   3.3.1路由出站數據報........................ 47
   3.3.1.1本地/遠程決策........................ 47
   3.3.1.2網關選擇............................ 48
   3.3.1.3路由緩存.................................. 49
   3.3.1.4死網關檢測....................... 51
   3.3.1.5新網關選擇........................ 55
   3.3.1.6初始化............................... 56
   3.3.2從新組裝........................................ 56
   3.3.3碎片..................................... 58
   3.3.4本地多宿主................................. 60
   3.3.4.1簡介................................. 60
   3.3.4.2多宿主要求..................... 61
   3.3.4.3選擇源地址.................... 64
   3.3.5源路由轉發........................... 65

互聯網工程專責小組[第2頁]

RFC1122引言1989年10月

3.3.6廣播........................................ 66
     3.3.7 IP組播................................... 67
     3.3.8錯誤報告................................... 69
  3.4互聯網/傳輸層接口..................... 69
  3.5互聯網層要求摘要.................... 72

4.運輸協議......................................... 77
4.1用戶數據協議 - UDP .......................... 77
4.1.1引言...................................... 77
4.1.2協議步行............................. 77
4.1.3具體問題................................... 77
4.1.3.1港口........................................ 77
4.1.3.2 IP選項................................... 77
4.1.3.3 ICMP消息................................ 78
4.1.3.4 UDP校驗和................................ 78
4.1.3.5 UDP多宿主.............................. 79
4.1.3.6無效地址............................ 79
4.1.4 UDP /應用層接口................... 79
4.1.5 UDP要求摘要.......................... 80
4.2傳輸控制協議 - TCP ................... 82
4.2.1引言...................................... 82
4.2.2協議步行............................. 82
4.2.2.1衆所周知的端口............................. 82
4.2.2.2使用Push .................................. 82
4.2.2.3窗口尺寸.................................. 83
4.2.2.4緊急指針............................... 84
4.2.2.5 TCP選項.................................. 85
4.2.2.6最大段大小選項.................. 85
4.2.2.7 TCP校驗和................................. 86
4.2.2.8 TCP鏈接狀態圖................. 86
4.2.2.9初始序列號選擇............ 87
4.2.2.10同時開放嘗試.................. 87
4.2.2.11從舊的重複SYN中恢復.....................
4.2.2.12 RST段................................. 87
4.2.2.13關閉鏈接........................ 87
4.2.2.14數據通訊.......................... 89
4.2.2.15重傳超時...................... 90
4.2.2.16管理窗口......................... 91
4.2.2.17探測零窗口........................ 92
4.2.2.18被動OPEN呼叫.......................... 92
4.2.2.19生存時間................................ 93
4.2.2.20事件處理............................ 93
4.2.2.21確認排隊的段............... 94
4.2.3具體問題................................... 95
4.2.3.1重傳超時計算........... 95
4.2.3.2什麼時候發送ACK段.................. 96
4.2.3.3什麼時候發送窗口更新................. 97
4.2.3.4什麼時候發送數據............................ 98

互聯網工程專責小組[第3頁]

RFC1122引言1989年10月

4.2.3.5 TCP鏈接失敗...................... 100
        4.2.3.6 TCP保持活動.............................. 101
        4.2.3.7 TCP多宿主.............................. 103
        4.2.3.8 IP選項................................... 103
        4.2.3.9 ICMP消息................................ 103
        4.2.3.10遠程地址驗證................... 104
        4.2.3.11 TCP流量模式........................ 104
        4.2.3.12效率.................................. 105
     4.2.4 TCP /應用層接口................... 106
        4.2.4.1異步報告......................... 106
        4.2.4.2服務類型.............................. 107
        4.2.4.3沖洗呼叫................................... 107
        4.2.4.4多宿主.................................. 108
     4.2.5 TCP要求摘要........................... 108

5.參考............................................... .. 112

本文檔定義並討論了主機系統實現IP協議簇的要求,涵蓋了鏈路層、IP層和傳輸層三個通訊協議層。與之相應的RFC文檔「因特網主機要求--應用與支持」[INTR：1]闡述了應用層的協議，同時參閱「因特網網關要求」[INTRO：2]。

這些文檔旨在爲因特網通訊軟件的開發者、實現者及用戶提供指導。這些文檔凝聚了Internet研究和開發組織的相關人員的許多技術經驗與智慧。

本文檔列舉了主機連上因特網所必須的標準協議參照了相關的RFC文檔和其餘文檔中關於這些協議最新的描述。修正了參考文檔中的一些錯誤併爲實現者增長了額外的討論和指導。

對於每一個協議，文檔中包含了詳細的必需要求、推薦要求和可選要求。讀者們應當明確文檔中所述的必需要求並不完備，對於因特網主機完整的要求主要是在標準協議文檔中定義。本RFC只是對其進行修改、修正和完善。

若是一個協議是在認真閱讀了RFC的標準並與因特網技術社團有了必定的交互，同時按照軟件工程要求進行良好的溝通的基礎上完成的，那麼這個協議於本文檔的要求應該基本吻合。對於協議較好的實現是同時，本RFC中所述的「要求」已經在標準文檔中闡述過了，所以，在不少狀況下，本RFC中的「要求」已在陳述中暗示或暗示標準協議文件，所以它們包含在這裏，在一個感受，多餘。然而，他們被包括在內是由於有些過去實施作出了錯誤的選擇，形成了問題互操做性，性能和/或健壯性問題。
本文檔包括了許多的要求和推薦項。簡單地列出全部的要求是很危險的，由於： 1. 有些要求比其餘的更重要，而還有一部分是可選的內容。

2. 有一些產品因爲設計在嚴格的上下文環境中所以可能選擇使用一些不一樣的規程。

但對於面向通常需求的主機爲了在交互中適應因特網的多樣性和複雜性，必需要聽從本文檔的規程規定。雖然在實際上有許多的實現並無徹底按照本文檔所述的要求，但這些規程是理想的模式，也是咱們努力的方向。

這些要求是基於現行的因特網體系結構的層次設計的。隨着其餘的規程的不斷髮展，文檔所述的內容也須要更新，加以辨別或者添加新的信息。

介紹部分由與主機相關的因特網體系結構的概貌開始，並給主機軟件生產商一些總體的意見。最後會有一些閱讀文檔的剩餘部分和術語的一些指導。
1.1 因特網體系結構

因特網的體系結構和支持協議簇可參照DDN協議手冊[INTRO：3]，背景

資料舉例參照[INTRO：9][INTRO：10][INTRO：11]。[INTRO：5]的參考描述了得到因特網協議文檔的過程；[INTRO：6]包含了IP協議分配的一系列序號。 1.1.1 Internet主機

一個主機電腦，也就是常說的「主機」是通訊服務的最後客戶端。主機經過網絡和/或使用因特網通訊服務表明用戶執行應用層程序。而因特網主機就是OSI協議簇[INTRO：13]中「端系統(end-system)」的概念。

因特網通訊系統由互聯的網絡構成，這些網絡支持了經過IP協議相互通訊的主機電腦。網絡間的互聯是經過使用分組交換的電腦即因特網社區裏所說的「網關(gateway)」或「IP路由器(IProute)」，也就是OSI中的「媒介系統(intermeida system)」。RFC「因特網網關要求[INTRO：2]」包含了因特網網關的官方規程。那篇RFC、本文檔和[INTRO：1]定義了現行的因特網體系結構的實現規則。

因特網主機有不少不一樣的大小，速度和功能。在大小上，主機的雖然能夠小到工做站的微處理器大到大型機和超級計算機。在功能上，主機小到單目標主機(譬如服務器終端)大到支持許多線上網絡服務，尤爲是包括遠程登陸，文件傳輸和電子郵件的服務齊全的主機。
若是主機有多個接口，或不一樣的網絡，那麼它就會被稱爲多主宿主，見術語1.1.3節。

1.1.2 體系結構設想

現行的因特網體系結構是基於通訊系統的設想。之中與主機相關的設想以下：

(a) 互聯網是一個網絡的網絡。

每一個主機都與某個特定的網絡直接相連，但這種鏈接只是概念上的。處於同一網絡的兩臺主機只有在對遠程網絡的通訊中採用一組相同協議的條件下才能進行通訊
理解：主機與主機鏈接是邏輯上的，而且二者都須要用同種協議進行通信。
(b) 網關不能保存鏈接狀態信息

爲了加強通訊系統的健壯性，網關旨在獨立於其餘數據報來轉發每一個IP數據報。結果，雖然中間網關和網絡有可能失敗，爲了保證服務的健壯性能夠找出其餘的通路。
理解：網關不處理網絡層以上的信息，保證服務的健壯性。
全部端到端的流控制和可靠性所需的狀態信息是在主機傳輸層或應用層實現的。而全部的鏈接控制信息是在通訊的端點產生的，故僅當端點失敗時信息會丟失。
理解：流控和可靠性由傳輸層或者應用層實現，例如TCP/IP的流控以及可靠性，QOS，都是在傳輸層實現；鏈接信息在端點產生。
(c) 路由的複雜性由網關處理

路由是一個複雜又困難的問題必須有網關而不是主機來處理。一個重要的目標就是使主機軟件能屏蔽不可避免的因特網路由體系發展帶來的變化。
理解：路由功能交由網關處理，避免internet技術的變化對於主機的影響。

(d) 系統必須可以適應普遍的網絡變化

因特網設計的根本目標是適應各類網絡的狀況--譬如帶寬、延時、分組丟失、分組重排和最大分組大小。另外一個目標是在面對使用各類不一樣帶寬的網絡、網關和主機時，能夠保持健壯性。最後的目標是達到保全的「開放系統互連(OSI)」：使得每一個因特網主機能夠同多不一樣的因特網通路與其餘因特網主機健壯地有效地合做。
有時主機實現者的設計目標較爲模糊，好比，局域網環境顯然要比整個因特網狀況更好，局域網的丟包率較低，時延較少並且不進行分組重傳。有些生產商在簡單的局域網上較好地實現了主機系統，但在總體的互聯上狀況很糟糕。生產上判斷一件產品是否經濟可行實在有限的局域網市場上試驗的。可是被隔離的局域網並不一直是孤立的，它們經過網關相互相連，鏈接到某個組織內的網絡，最終鏈接到整個因特網。最後顧客和生產者都是用的是徹底的標準的因特網主機軟件。

本文檔中指出的要求是爲能完成完備的功能的因特網主機而設計的，可以經過任意的因特網通路達到完備的互用性。
理解：廣域網具備的網絡特徵：帶寬，延遲，包丟失，包重排序，以及包過小，，有些主機軟件，系統，服務器在局域網能很好的運行，可是在廣域網上卻很糟糕，所以生產者都會用徹底符合標準的軟件。
1.1.3 互聯網協議簇
互聯網系統進行通訊，主機必須包含互聯網協議的一套分層協議，一個主機必須在每一層上至少實現一個協議。協議層以下描述

1. 應用層

應用層是互聯網協議簇中的最高層。雖然有一些因特網應用層協議確實包含了一些內部的子層劃分，但基於因特網的軟件集並無再把應用層再劃分子層。因特網軟件集中的應用層協議必須包含最高兩層--表示層和應用層--根據OSI參考模型的規定。

咱們將應用層協議分爲兩類：直接爲用戶提供服務的用戶協議和提供系統功能的支持協議。對於用戶和支持協議的要求將在相關的RFC文檔中找到[INTRO：1]。

最常使用的因特網用戶協議包括： a)Telnet(用於遠程登陸) b)FTP(用於文件傳輸) c)SMTP(電子郵件發送) 同時還有許多標準化的用戶協議[INTRO：4]和許多私有用戶協議。

支持協議用於主機的名字映射，導入和管理，包括SNMP、BOOTP、RARP和DNS(域名系統)協議。

2. 傳輸層

傳輸層爲應用層提供了端到端的通訊服務。如今主要有兩種傳輸層協議：

a)傳輸控制協議()TCP0 b)用戶數據報協議(UDP)

TCP是面向鏈接的傳輸服務提供端到端的可靠傳輸，從新排序和流控制。UDP是一個面向非鏈接的傳輸服務。

傳輸層協議將在第四章中進行討論。 3. 網絡層

全部的因特網傳輸層協議都使用了IP協議將數據由源主機傳送至目的主機。IP指一個面向非鏈接的網絡服務，不提供端到端的保證。
這樣，IP數據報有可能在到達目的主機時就已經被破壞、重傳、亂序或安全到達。IP以上的各層在須要時負責服務的可靠性。IP協議包括了尋址、服務類型、分片、重組和安全信息的規定。

IP協議的面向非鏈接是因特網體系結構的一項根本的典型的特徵。因特網IP是OSI面向非鏈接的網絡協議的模型[INTRO：12]。

ICMP是IP不可分割的一個控制協議，雖然在體系結構上，它位於IP層，但它像傳輸層協議TCP或UDP協議同樣使用IP分組來攜帶數據。ICMP包括錯誤報告，擁塞報告和第一跳網關重定向。 IGMP是用於創建可以進行IP多播的動態主機組的網絡層協議。 IP、ICMP、IGMP這些網絡層協議將在第三章中進行討論。 4. 鏈路層

主機爲了在直接相連的網絡中進行通訊必須實現接口與網絡相連的通訊協議。咱們稱之爲鏈路層或媒體介入層協議。

在許多不一樣類型的網絡上有許多鏈路層的協議與之相適應，請參照第二章。

嵌入式網關代碼

有些因特網主機軟件包含了嵌入式的網關功能，那麼這些主機在執行主機的應用層功能時就能夠像王冠同樣轉發分組。

這樣雙目的的系統必須既按照網關要求的RFC規定[INTRO：2]又按照針對其主機功能的文檔規定。在全部相交迭的狀況中這兩個規定必須達成一致。

對於主機中嵌入網關的功能因特網社區內有許多不一樣的意見。主要的爭議以下：

1.優勢：

在網絡不太規範的獨立的本地網絡中，是主機具備網關的功能多是方便又經濟的。

但也有許多對於嵌入式網關功能的體系結構上的爭議：多宿主的應用比早期的碰見要廣泛得多而多宿主的功能uaoxiu 主機箱王冠同樣作出路由選擇。若是多宿主主機包含了一個嵌入式的網關，它就能夠很好地進行路由並做出理想的路由選擇。

2.缺點：

網關算法和協議一直不斷改變並將隨着因特網系統的發展而繼續改變。在主機IP層中加入網關的功能的嘗試將會迫使主機系統跟隨着這些改變而不斷更新。最後網關IP層一般比主機的更復雜，這就使得這一實現和操做更加複雜。

這兩種觀點都各有優勢，從中能夠得出一個結論：主機管理員必須對因而否使主機扮演網關的角色有明確的控制。參照3.1節的詳細說明。

1.2 總體設計

因特網主機軟件的生產商已經認識到的和新的生產商們必須認真考慮的有兩個重要的方面。 1.2.1 Internet的可持續性發展

1.1.4
因特網爆炸性的增加揭示了管理和在給予大數據報分組通訊系統中規模控制的問題。這些問題已經被提出來了，那麼本文檔中所描述的規程也將會有持續的發展。既然生產商和相關組織已經進行了大規模的劃分，那麼這些改變也將會謹慎的規劃並加以控制。

發展、演化和修訂是今天計算機網絡協議的特色，這一狀況還將持續多年。若是爲IP協議簇設計的計算機通訊網絡軟件的生產商沒有隨着要求的變化而進行維護和更新，那麼將會有一大批很不高興的顧客。因特網是一個巨大的通訊網絡而用戶將不停地與之接觸。經驗代表某個軟件的不足將很快在整個因特網社區裏傳開。 1.2.2 健壯性(魯棒性)要求

每層的協議都有一個總體的規則，這一規則的應用將爲健壯性和互用性帶來巨大的好處[IP：1]。 「對於收到的信息要放寬要求，而對於發出的信息要嚴格規定。」

軟件應該能共處理每個有可能發生的錯誤不管其發生的可能性大小，遲早會接收到一個處於某種錯誤或屬性的狀況下的分組，那麼只有軟件在設計前考慮到這一點，才能夠避免混亂的發生。總的說來，最好在設計時假設網絡充滿了旨在傳送會帶來最糟糕的影響的惡意的實體。基於這樣的假設，雖然因特網上最嚴重的問題是由小几率事件引發的沒有被重視機制致使的，設計出來的產品才具備可靠的保護性。但人們的第一每每不會經歷如此曲折的過程。

面對改變的適應性應該是因特網主機軟件各層設計的要點，舉一個簡單的例子，假設某個協議規定列舉了某個特定的首部字段的值--好比，類型字段，斷口字段或錯誤號。這個列舉值一般不是徹底的。這樣，若是協議規定了四種可能的錯誤代碼，那麼這個軟件不該該在第五種取值出現時就癱瘓了。這個違背定義的編號應該寫入日誌(見下文)但他不該該引發故障。

第二個關鍵原則也很重要：其餘主機上的軟件可能包含了一些缺陷，很不明智地使用了了一些合法但很模糊的協議特徵。不使用明確的簡單的部分來避免麻煩的結果是不明智的。這樣作的必然結果就是「當心提防這些行爲不正常的主機」，主機軟件應該預先考慮到這個問題，不只僅是不要成爲行爲不正常的主機，還要合做來減小此類主機對於共享的通訊設備的損害。 1.2.3 錯誤日誌

因特網有不少的主機和網關係統，每個系統都實現了許多的協議和協議層，有些包含了漏洞了與相應的因特網協議軟件不相符的部分。因爲其複雜性、多樣性和功能的分佈性，要診斷因特網的問題常常比較困難。

若是主機在實現時包括了一個仔細設計記錄錯誤或「奇怪的」協議時間的工具，那麼對於因特網問題的解決會有所幫助。當錯誤被記錄時應該儘量多地記錄診斷信息。尤爲記錄發生錯誤的分組的首部一般是比較有用的。可是應該注意錯誤日誌不該該佔用過多的資源，不然將影響主機的工做。
如今異常但無害的協議事件傾向於在錯誤日誌文件上溢出，這一點能夠經過使用「循環」日誌來避免。這對於過濾和計算重複報文是頗有用的。有一種看起來還不錯的策略是：(1) 老是計算異常的數量而且可管理協議[INTRO：1]隨時獲取(2) 所要記錄的事件應該能夠進行選擇。好比應該容許是記錄「全部的事件」仍是「記錄主機X的全部事件」。

要注意不一樣的管理下對於主機內正常的錯誤記錄策略是有所不一樣的。有時的處理方式是「若是這個信息不會傷害我，那麼我不想知道」，而有時是抱着更激進的更警戒的態度來檢測和屏蔽協議異常。 1.2.4 設置

若是主機在實現因特網協議時可以徹底地自我配置是最理想的。這將徹底在ROM完成，將簡化了無盤工做站，對局域網管理員和系統生產上來時也是極大的福音。但咱們尚未那麼理想，事實上還遠着呢。

本文檔中的任何一點都有一個可配置選項的參數。這是有緣由的，有時最優值仍存在着不肯定性，有可能在從此須要更新使用新的推薦值。同時，還有一些值取決於全局因子--好比主機的大小，或通訊載荷的分佈，或臨近網絡的速度和拓撲結構--而自適應算法可能不可行或無效。有時可配置性是管理方面的須要。 最後有些配置選項須要與陳舊的或者不正確的協議實現相配合，這些狀況在因特網的某些區域仍然存在。爲了是正確的系統能夠與這些有問題的系統共存，管理員經常不得不將正確的系統進行「錯誤配置」。這個問題將在這些有問題的系統退出使用舞臺後才能夠逐步改善，但這個問題生產商是不能夠忽略的。 當咱們說一個參數必須被配置，這並非須要在每一次啓動時都從配置文件中準確地讀出。咱們推薦實現者爲每個參數設立一個默認值，因此配置文件只有在那些默認值在特定的安裝狀況下是不合適的纔要進行重載。這樣的配置要求保證了在必要時能夠進行重載，即便是在只支持二進制或基於ROM的產品。 本文檔要求在某些狀況下給默認值設定特定值。默認值的選擇在配置項控制與存在的有缺陷的系統相適應時是一個敏感的問題。若是因特網成功地聚合了完整的互操做，那麼這些植入實現中的默認值也必須實現官方的協議，而不是進行「誤配置」以配合原來有問題的實現。咱們要求生產者按照標準來選擇默認值。
RFC1122-A(中文版)

最後咱們提醒生產者必須爲全部的配置參數提供相應的文檔，包括其限制和效果。

組織

1.3 閱讀文檔

1.3.1

做爲實現網絡軟件的組織原則的協議分層一樣也用於妥當的組

織。在描述這些規則之，咱們假定是實現嚴格意義上對於協議分層的反映。這些接下來的三個部分分別闡述了鏈路層，網絡層和傳輸層的要求。相關的RFC[INTRO：1]包含了應用層軟件的部分。這個分層組織方法是爲了簡潔性所選擇的。 可是對於協議簇和推薦的實現方法來講，嚴格的分層是一個並不完美的模型。處在不一樣層的協議間的交互是複雜的優點是微妙的，而有些特定的功能經常須要涉及多個層次。在實現中有許多涉及選擇，而其中許多須要闖髒性的「打破」嚴格的分層界限。每一個實現這都應該仔細閱讀[INTRO：7]和[INTRO：8]的參考。 本文檔描述了層之間經過使用功能符號(好比例程調用)的概念服務接口，就像在TCP[TCP：！]中使用的那樣。主機的實現必須支持這些調用的邏輯信息流，但賓不是須要竹子的有調用自己是鹹。好比許多實現反映了傳輸層和IP層之間經過使用相同的數據結構來實現合做。這些數據結構並非明確的例程調用，而是傳遞許多須要的信息的代理。 總的來講，每一個文檔中的主要部分都是從以下的子部分組成的： (1) 介紹

(2) 協議概要--逐部分考慮了協議規格文檔，改正錯誤，陳述了可能模糊或定義不完備的要求，而且提供了進一步的說明和解釋。 (3) 關鍵問題--討論了協議的設計和實現問題，這些在概要裏沒有涉及到。 (4) 接口--討論了對於之相鄰的更高地服務接口。 (5) 概要--包括了這個部分的要求的小結。 本文檔的許多獨立主題標記爲「討論」或「實現」的附加說明的材料。這一材料旨在對以前的要求進行解釋和說明。它也包括了一些針對未來有可能的方向或發展的建議。實現的材料包括了實現者可能考慮到的建議的方法。

概要小結部分旨在給文章提供指導和索引，但並非很完整的。這些小結不會單獨於整個RFC文檔而被獨立引用。
1.3.2 需求
2.在本文檔中，下列用於定義每一個要求的z重要性的詞語將使用大寫字母。

包括：

(1) "MUST"

這個詞或者形容詞「REQUIRED」表示這個項市規定是必須有的部分。（必須）必須）

(2) "SHOULD"

這個詞或者形容詞「RECOMMENDED」表示在特定的狀況下若是有正當的理由能夠忽略這個項，但應該充分了解其含義而且在選擇一個不一樣的過程當中要謹慎地權衡。（應該）應該）

(3) "MAY"

這個詞或者形容詞「OPTIONAL」編者這個鄉是個徹底的可選項。生產商能夠選擇包含這個項，由於某個特定的市場環境可能須要它或者由於它對產品有幫助，好比另外一個生產者忽略了這個項。能夠）（能夠）

若是實現沒有知足一個或多個「MUST」的協議要求，那麼這個實現就是不合適的。若是一個實現知足協議全部的「MUST」和「SHOULD」要求，那麼這個實現就能夠叫作「不管何種狀況都是合適的」。若是知足了全部的「MUST」項但不是全部的「SHOULD」項那麼就稱做「在必定條件下是合適的」。 1.3.3 術語 本文檔使用了以下的專有名詞： Segment報文段

報文段是TCP協議中的端到端的傳輸單元。報文段是

TCP首部和應用層數據構成。報文段封裝成了IP數據報進行傳輸。

Message報文

在更低層的協議描述中，報文是傳輸層的傳輸單元。特別的，一個TCP報文段就是一個報文。一個報文由傳輸層協議首部和應用層數據組成。爲了在因特網上進行端到端傳輸，報文必須封裝在一個數據報中。

IP Datagram IP數據報

一個IP數據報是IP協議中的端到端的傳輸單元。IP數據報時有一個IP首部和傳輸層數據，好比一個IP首部和一個報文。
在網絡層(第三部分)的描述中，「datagram」應該被理解成是IP數據報。

Package 分組

一個分組是經過網絡層和鏈路層之間的接口的數據單元。包括了IP首部和數據。分組多是完整的IP數據報或者是一個IP數據報的分片。

Frame 幀

幀是連路層協議的傳輸單元，包括了鏈路層的首部和一個分組。

Connected Network 互聯網絡

一個主機鏈接着的網絡一般稱做「本地網絡」或這個主機的子網絡。可是這些術語會引發混亂，所以咱們在本文檔中使用「Connected Network(互聯網絡)」。

Multihomed 多宿主

若是一臺主機有多個IP地址咱們就說這個主機是多宿主的。對於多宿主的討論，下見3.3.4。

Physical network interface物理網絡接口

物理網絡接口是指鏈接到互聯網絡並擁有一個鏈路層地址(多是惟一的)的物理接口。若是一臺主機上有多個物理網絡接口，它們能夠共享鏈路層地址，但不一樣的主機在相同的物理網絡中的地址必須是惟一的。

Logical [network] interface邏輯[網絡]接口

咱們定義了一個邏輯網絡接口，做爲區別於惟一的IP地址，而鏈接在互聯網絡中的邏輯通路，見3.3.4。

Specific-destination address特定目的地址

這是一個數據報的有效目的地址，即便在廣播或多播時仍然有效，見3.2.1.3。

Path 路徑

在某個給定的時刻，有一個特定的援助激發像一個特定的目的主機的全部IP數據報會按相同的順序通過網關。路徑之一一個方向。在一對主機間的兩個方向上有多條不一樣的路徑是正常的狀況。

MTU 最大傳輸單元 MTU是可被傳輸的最大分組的大小。
frame, packet, datagram, message, 和segment在數據報中以下圖所示：

A. 互聯網絡上的傳輸:

___ | LL hdr | IP hdr | (data) |

|____|____|_____|

<---------- Frame -----------------------------> <----------Packet -------------------->

B. IP分片前或IP重組後的狀況:

__ | IP hdr | transport| Application Data |

|____|_hdr|__|

<-------- Datagram ------------------> <-------- Message -----------> TCP的狀況:

__ | IP hdr | TCP hdr | Application Data |

|____|__|__|

<-------- Datagram ------------------> <-------- Segment -----------> 1.4 感謝

本文檔集成了許多因特網協議的專家的貢獻和意見，包括大學和研究實驗室的表明，生產商以及政府部門。主要由IETF組織完成。

編者主要感謝下列孜孜不倦的同仁，他們爲了本文檔在過去的18個月中參加了許多會議，閱覽了3百萬字節的電子郵件，他們是：Philip Almquist, Dave

Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

此外，下屬的同仁也作出了很大的貢獻：Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia

(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA).

如下人員也在特定的領域內做出了巨大貢獻: Eric Allman

(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto).

咱們十分感謝上述的全部人，還有那些被咱們不注意間忘了加在名冊中的同仁。

---------------------------------------------------------------------------------------------------------------------- 2. 鏈路層 2.1 介紹

全部的因特網系統，包括主機和網關，都對鏈路層協議有着相同的要求。這些要求在「因特網網關要求」[INTRO：2]的第三章中詳細給出，本文中只是作了添補的工做。

2.2 協議概要 無 2.3 關鍵問題 2.3.1 追蹤協議協商Trailer Protocol Negotiation

追蹤協議[LINK：1] 能夠封裝鏈路層，但僅當通訊雙方都確認使能夠用這個協議。若是系統不是對每一個目的主機都動態地協商使用追蹤協議，那麼默認配置必須必須禁止這個協議。 必須

討論：

追蹤協議從新封裝了發送給物理網絡的分組的數據內容。有時候，追蹤者經過減小操做系統中數據的複製量來提升高層協議的性能。高層協議並無感受到追蹤者的做用，但收發雙方的主機必須必須瞭解這個協議是否啓用。 必須

對於追蹤着不恰當的使用會致使很混亂的局面。只有大小屬性明確的分組可使用追蹤者封裝，而一般交換的分組只有不多一部分有這樣的屬性。所以，若是一個系統使用追蹤者，而另外一個系統沒有使用，那麼就會有一些分組成功到達而另外一部分消失在了黑洞裏的狀況出現。 實現：

以太網中，用追蹤者封裝的分組使用遠程以太網類型[LINK：1]而且追蹤者協商是在ARP尋找目的系統的鏈路層地址時工做的。

特別地，ARP交換一般使用通常的IP協議類型完成，但主機若想使用追蹤者會發送一個額外的」追蹤者ARP應答」分組，好比一個ARP應答知名類型是追蹤者封裝協議類型，不然就是用正常的ARP應答格式。若是主機配置成使用追蹤者來接收一個遠端機器的追蹤者ARP應答報文 ，那麼主機就能夠把這個遠端機器加入使用追蹤者的名冊中，好比經過在ARP Cache中做一個標記。

想要接收追蹤者封裝的主機在其完成了正常的ARP報文交換後要發送追蹤者ARP應答。這樣，一臺主機若是收到了對於其IP協議地址的ARP請求，那麼它能夠在正常的針對IP的 ARP應答報文後追加發送一個追蹤者ARP應答報文。那麼發送針對IP的ARP請求的主機在收到正常的ARP應答時還會收到一個追蹤者ARP應答/這樣在針對IP的ARP交換過程當中，收發雙方均可以應答它所收到的追蹤者封裝。

這種使用額外的追蹤者ARP應答保溫而不是發送追蹤者協議類型的ARP應答的機制是爲了不ARP報文的連續交換而設計的，爲了防止工做不正常的主機不按照規程或常規，使用其它ARP應答類型來應答追蹤者ARP應答的狀況發生。若是一個請求IP解析的ARP應答是對一個特別的請求而作出的，那麼發送追蹤者ARP應答來響應市能夠避免以上的問題的。當收到了ARP應答，但主機地址仍然不知道的狀況是存在的。追蹤者ARP應答通常都是追加在一個應答ARP請求的應答包中。

2.3.2 地址解析協議--ARP 2.3.2.1 ARP緩衝區的有效期

地址解析協議(ARP)[LINK：2]的實現必須必須提供超時高速緩存記錄必須

的刷新機制。若是這一機制須要一個超時值，那麼配置時應該應該給出。 應該

也必須必須包括防止ARP洪水(高速地向某個相同的IP地址接二連三必須

的發送ARP請求)的機制。推薦的最大速率是每秒鐘向每一個目的地址發送一個ARP請求。

討論：

ARP規程[LINK：2]建議但並非強行規定當主機以太網地址發生變化時可以保持緩衝記錄的有效性的超時機制。隨着ARP代理的流行(見[INTRO：2]的2.4部分)，主機中的ARP緩衝項可能會無效的狀況的大大增多，所以主機就須要了一些確認ARP-Cache有效性的機制。即便沒有ARP代理，較長時間的ARP有效時間對於自動修正可能錯誤的ARP記錄也是有幫助的。 實現： 下列四種機制可用於刷新舊的緩衝記錄。 (1) 超時—即便緩衝內的記錄仍在使用也要定時地更新。超時應該在」更新」(檢查廣播的ARP的源地址字段，忽略目的地址字段)時進行。對於ARP代理的狀況，每分鐘要進行一次超時檢查。

(2) 單播輪詢—定時地發送點到點的ARP請求來主動地輪詢遠程主機，而且在N次嘗試後都沒有收到ARP應答時刪除緩衝中的記錄。一樣，超時值應該約爲1分鐘，一般N值取2。

(3) 鏈路層建議—若是鏈路層驅動檢測到了一個發送問題，則刷去ARP緩衝區中的記錄。

(4) 高層建議—從網絡層到鏈路層若是有發送問題就提請一個調用。這個調用的做用是使相應的緩衝記錄無效。這個調用應該相似於傳輸層到網絡層的調用"ADVISE_DELIVPROB()"的形式(見3.4部分)而且實際上"ADVISE_DELIVPROB()"例程可能會調用鏈路層建議來使ARP緩衝記錄無效。

對於處理ARP超時時用的方法(1)和(2)設定的時間應該應該約一分鐘應該

或更短的時間。若是沒有ARP代理，沒有時延控制在很大的以太網上會出現高負荷的狀況。所以對主機進行ARP緩衝進行超時設置是必要的。 2.3.2.2 ARP分組隊列

鏈路層應該保留(而不是丟棄)至少一個(根據最新的研究狀況來看) IP地址未解析的目的地相同的分組，並在地址已經被解析後發送這個分組。

討論： 沒有按照這個推薦會使得每次交換中第一個分組的丟失。雖然高層協議能夠經過重傳來處理分組丟失的狀況，可是分組丟失影響了工做的性能。好比一個TCP打開請求的丟失將會致使往返時間的初始值的膨脹。像域名系統此類的基於UDP的應用程序會有更嚴重的影響。 2.3.3 以太網和IEEE802封裝

對於以太網的IP封裝在RFC894中進行了描述[LINK：4]，RFC1042[LINK：4]描述了IEEE802網絡的IP封裝。RFC1042 [INTRO：2]的3.4部分進行了詳細的闡述。

每一個因特網主機鏈接到10Mbps的以太網網絡： 1. 必須使用RFC894的封裝來發送和接收分組 必須

2. 應該可以接收RFC1042分組，並與RFC894分組混合，而且 應該3. 能夠可使用RFC1042封裝來發送分組

實現了發送RFC894和RFC1042封裝的因特網主機必須必須提供一個配置必須選擇要發送哪個，這個可選擇的必須必須的默認值在RFC894裏描述了。 必須

RFC1042的標準IP封裝並無使用IEEE爲IP保留的協議ID值(K1=6)，而是使用了在拓展的 「SNAP」中指出了用以填充以太網字段的值(K1=170)。因特網系統必定不可使用802分組中的值 (K1=6)。

將因特網地址轉換成以太網或者IEEE802網絡的鏈路層地址必須必須由地必須址轉換協議(ARP)。

以太網的MTU是1500字節而802.3是1492。 討論：

IEEE802.3的規程提供了10Mbps的以太網的操做，這樣以太網和IEEE802.3幀能夠在物理層混合。接收者能夠經過802.3的長度字段來區分以太網和802.3的幀。這兩個字節的字段與以太網幀的以太網類型字段相同。特別地，802.3的長度字段必須不大於1500，而全部的以太網類型有效值應該大於1500。

另外一個兼容性問題是在鏈路層廣播出現的。僅發送一種幀的廣播可能不會被只接受另外一種幀的主機接收。
對於這個部分設計的建議是在相同的網絡中實現支持894和支持1042的系統間最大程度的直接合做。現今的狀況是894系統佔統治地位，但支持1042的系統有可能在未來普及開來，所以也要提供一個簡單的轉變。

應該認識到只支持894的系統並不能直接與支持1042的系統交互工做。若是兩種系統類型在相同的網絡中是使喲了可以兩種不一樣的邏輯網絡，那麼它們只能經過IP網關來通訊。進一步看，想要一臺雙格式的主機自動地選擇發送格式是不可行的甚至是不可能的，由於在鏈路層上存在廣播問題。

2.4 鏈路層與網絡層的接口

IP層和鏈路層之間的分組接收接口必須指出接收的分組是否一個鏈路層廣播。 討論：

雖然IP曾並不知道鏈路層的地址(由於每種不一樣的網絡媒介有不一樣的地址格式)，廣播地址在容許廣播的媒介上是一個重要的問題。參見3.2.2關於廣播風暴的討論內容。

IP層和鏈路層之間的分組發送接口必須必須包括一個5比特的TOS字段(見必須3.2.1.6)。

鏈路層必定不能必定不能僅向IP層發送一個目的地不可達的錯誤，由於目的地沒必定不能有ARP緩存記錄。
2.5 鏈路層要求概要

|       | | | |S| |
                                              |       | | | |H| |F
                                              |       | | | |O|M|o
                                              |       | |S| |U|U|o
                                              |       | |H| |L|S|t
                                              |       |M|O| |D|T|n
                                              |       |U|U|M| | |o
                                              |       |S|L|A|N|N|t
                                              |       |T|D|Y|O|O|t

FEATURE	SECTION				T	T	e
Trailer encapsulation	2.3.1			x
Send Trailers by default without negotiation	2.3.1					x
ARP	2.3.2
Flush out-of-date ARP cache entries	2.3.2.1	x
Prevent ARP floods	2.3.2.1	x
Cache timeout configurable	2.3.2.1		x
Save at least one (latest) unresolved pkt	2.3.2.2		x
Ethernet and IEEE 802 Encapsulation	2.3.3
Host able to:	2.3.3
Send & receive RFC-894 encapsulation	2.3.3	x
Receive RFC-1042 encapsulation	2.3.3		x
Send RFC-1042 encapsulation	2.3.3			x
Then config. sw. to select, RFC-894 dflt	2.3.3	x
Send K1=6 encapsulation	2.3.3					x
Use ARP on Ethernet and IEEE 802 nets	2.3.3	x
Link layer report b'casts to IP layer	2.4	x
IP layer pass TOS to link layer	2.4	x
No ARP cache entry treated as Dest. Unreach.	2.4					x