IP數據報通過IEEE802.3網絡傳輸的兩種方法

本備忘錄的狀態
本文檔講述了兩種在IEEE802.3網絡上封裝互聯網絡通訊協議(IP)[1]的方法[2]。這個
RFC為了給ARPA-Inte.net團體提出了一個推薦的協議。并且還需要討論和完善。本
備忘錄的發布不受任何限制。
目錄
介紹 2
以太網兼容模式 2
IEEE802.2/802.3兼容模式 2
結構形式 2
地址映像 3
靜態表 3
動態發現 3
廣播地址 3
追蹤格式 3
字節順序 4
結尾 4
參考 4

介紹
IEEE802方案定義了ISO開放式系統互聯參考模型（ISO/OSI）定義的局域網中處理
物理層和數據鏈路層的一系列標準。幾個物理層標準（802.3，802.4和802.5）[2，3，
4]和一個數據鏈路層標準（802.2）[5]已經被制定了。IEEE物理層標準詳細說明了
ISO/OSI物理層和ISO/OSI數據鏈路層的媒體訪問控制子層。802.2數據鏈路層標準詳
細說明了ISO/OSI數據鏈路層中邏輯鏈路控制子層。

802.3標準是以第二版以太網標準[6]為基礎的。以太網物理層和802.3的物理層在所有
的實際應用上是兼容的，然而，以太網數據鏈路層和802.2/802.3數據鏈路層是不兼容
的。

現存的許多以太網絡裝置使用在[7]里描述的以太網兼容標準傳輸ip數據報。IEEE802.3
物理層兼容連接能夠被增加到這些網絡，在不違反802.3標準的情況下使用一個以太網
數據鏈路層兼容模式傳輸IP數據報。二選一，使用一個802.2/803.3數據鏈路層兼容模
式傳送ip數據報。
以太網兼容模式
IEEE802.3網絡為了達到和以太網兼容必須使用48bit的物理地址和10M/s的帶寬。

IEEE802.3數據包的頭和以太網數據包的頭完全相同，除了頭中一段的分配含義。在一
個以太網數據包的頭里這段被用來作為協議類型段，在一個802.3數據包的頭里這段被
用來作為長度段。在10M/s的802.3網絡里允許的最大的長度段的值是1500。802.3標
準里說明數據包的長度段超過最大允許的長度段可能會被忽略，丟棄或者自定義使用。
因此，當協議類型被使用超過1500，長度段能夠被自定義模式使用作為協議類型段。
IP，ARP和追蹤概括的協議類型都超過1500。使用這個技術，在以太網絡描述上傳輸
IP數據報的方法能夠被用來在IEEE802.3網絡上在以太網兼容模式下傳輸IP數據報。
IEEE802.2/802.3兼容模式
結構形式
IP數據報在標準802.2/802.3邏輯鏈路控制層類型1下被傳送。無數802.2目的服務訪
問點和源服務訪問點格式的信息頭設置成96，IEEE為IP指定了全球訪問服務點的值。
數據段包括緊隨在IP頭后的IP數據。

IEEE802.3數據包的最小尺寸限制是以網絡帶寬為基礎的。當需要時，數據段會被填充
（用八進制的零）以適合802.3最小結構尺寸的要求。這些填充的零不屬于IP數據包，
不包括在IP頭的總長度范圍里。

IEEE802.3數據包的最大尺寸限制是以網絡帶寬為基礎的。鼓勵支持全長度數據包的執
行。
網關的執行必須準備接受全長度數據包并且在必需的時候粉碎它們。
主機的執行應該準備接受全長度數據包，然而主機不一定需要發送長度超過576
個八進制字節的數據報除非它們非常明確目的地準備接受它們。主機可以在TCP
應用基礎上通過TCP最大分段大小選項[9]傳達她的尺寸優先選擇。

注意：數據報在802.3網絡上可能超過普通因特網默認的最大數據報尺寸576個八進制
字節。主機連接到一個802.3網絡，當發送數據報到不在同一802.3網絡上的主機上時
應該緊記這點。也許合適發送小一點的數據報以避免不必要的中間網關分割。請看這點
進一步的信息。
地址映像
32bit的internet地址映像到16bit或48bit的802.3地址能夠有幾種實現的方法?？梢允?BR>用靜態表，也可以使用動態發現程序。
靜態表
每一個主機能夠提供一個所有其他在局域網上的主機的802.3地址和internet地址的表。
動態發現
通過一個類似以太網地址轉換協議(ARP)[10]的協議能夠實現32bitinternet地址和802.3
地址之間的映像。在一些internet網絡里，internet地址被隨意分配。每個主機的完成必
需知道他自己的internet地址，回復適合的802.3地址轉換數據包。它也能夠在需要時
使用ARP來轉換internet地址到802.3地址。
廣播地址
internet廣播地址（網絡地址的所有主機部分都為二進制的“１“）應該被映像到802.3
廣播地址（所有都是二進制“１”）。
強力推薦使用ARP動態發現程序。
追蹤格式
Unix4.2bsd的一些版本使用不同的封裝模式以便在VAX虛擬內存結構下得到更好的網
絡成績。在同一802.3網絡里這些系統內部采取這樣格式。追蹤封裝模式可以在[11]里
找到。
字節順序
附錄B里描述的和互聯網絡通訊協議詳細描述[1]的一樣，IP數據報是作為一系列的8bit
字節通過802.2/802.3網絡傳輸的。
結尾
兩種封裝模式能夠混合在同一局域網里；然而，這會把網絡分割成兩個不兼容的子網。
一個網絡上的主機能夠支持兩種模式并且就像網關一樣工作在兩個子網之間；然而，這
會引入一個重要的懲罰性的操作，它本應該被避免的。

IEEE802.2/802.3兼容封裝模式較以太網兼容模式好，因為IEEE802.2和IEEE802.3
標準已經被全美國和全世界所接受，而且同樣的封裝模式能夠被用在其他的IEEE802
物理層操作上。然而，有許多現存的設備必須使用以太網上的IP協議和從以太網到
IEEE802.2/802.3的控制轉換。

最后，所有新的操作應該允許封裝模式靜態選擇而且所有現存的操作為了保證這個靜態
選擇的正確應該做出修改。在傳輸期間，所有在同一網絡上的主機應該使用以太網兼容
模式。當做有的現存操作中都加入了802.2/802.3支持以后，IEEE802.2/802.3模式將
會被使用并且轉換將會完成。
參考
[1]Postel,J."InternetProtocol".RFC-791,USC/Information
SciencesInstitute,September1981.

[2]TheInstituteofElectronicsandElectronicsEngineers,Inc.
"IEEEStandardsforLocalAreaNetworks:CarrierSenseMultiple
AccesswithCollisionDetection(CSMA/CD)AccessMethodand
PhysicalLayerSpecifications".TheInstituteofElectronics
andElectronicsEngineers,Inc.,NewYork,NewYork,1985.

[3]TheInstituteofElectronicsandElectronicsEngineers,Inc.
"IEEEStandardsforLocalAreaNetworks:Token-PassingBus
AccessMethodandPhysicalLayerSpecifications".TheInstitute
ofElectronicsandElectronicsEngineers,Inc.,NewYork,New
York,1985.

[4]TheInstituteofElectronicsandElectronicsEngineers,Inc.
"IEEEStandardsforLocalAreaNetworks:TokenRingAccess
MethodandPhysicalLayerSpecifications".TheInstituteof
ElectronicsandElectronicsEngineers,Inc.,NewYork,NewYork,
1985.

[5]TheInstituteofElectronicsandElectronicsEngineers,Inc.
"IEEEStandardsforLocalAreaNetworks:LogicalLinkControl".
TheInstituteofElectronicsandElectronicsEngineers,Inc.,
NewYork,NewYork,1985.

[6]"TheEthernet,PhysicalandDataLinkLayerSpecifications,
Version2.0".DigitalEquipmentCorporation,IntelCorporation,
andXeroxCorporation,1982.

[7]Hornig,C."AStandardfortheTransmissionofIPDatagrams
overEthernetNetworks".RFC-894,SymbolicsCambridgeResearch
Center,April1984.

[8]Reynolds,J.,andPostel,J."AssignedNumbers".RFC-943,
USC/InformationSciencesInstitute,April1985.

[9]Postel,J."TheTCPMaximumSegmentSizeOptionandRelated
Topics".RFC-879,USC/InformationSciencesInstitute,
November1983.

[10]Plummer,D."AnEthernetAddressResolutionProtocol".
RFC-826,SymbolicsCambridgeResearchCenter,November1982.

[11]Leffler,S.,andKarels,M."TrailerEncapsulations".RFC-893,
UniversityofCaliforniaatBerkeley,April1984.

RFC948—TwomethodsforthetransmissionofIPdatagramsoverIEEE802.3networksoverIEEE802.3