1.摘要
通過路由機制，協議P在發送主機S上的實現決定了S需要傳輸到目標主機T，而T連
在和S相連的10兆以太網電纜上。實際傳輸以太網包必須產生一個48比特以太網地址。主
機的協議P地址并不總是和相應的以太網地址兼容(長度或值不同)?，F在這個協議答應動態
地發布
信息，這些信息可用來構造轉換協議P地址空間內的地址A為48比特以太網地址的一張表。
答應在非10兆以太網硬件使用的協議已經被綜合總結，無線電網絡就是這種硬件。
[這篇RFC的目的是提出一種轉換協議地址(例如ip地址)為本地網絡地址(例如以太網地
址)的方法。這個問題現在受到ARPAInternet社區的普遍關注，這里提出的方法僅供讀者
參考，并不是Internet標準的描述。]

2.說明
這個協議起初是為DEC/Intel/Xerox的10兆以太網設計的，現在已答應用在其它類型的

網絡上。許多討論將直接針對10兆以太網?？傊?，合適的話將遵循以太網的特定討論。
DODInternet協議將作為Internet的規范被參考。
這里用到的數字，在以太網標準中是高位字節在前的，這和例如PDP-11，VAX等機器的
字節編址相反，因此對下面描述的操作字段(ar$op)必須非凡小心。

需要處理硬件名字空間已達成一致。直到官方認可，請求可發送到
DavidC.Plummer
Symbolics,Inc.
243VassarStreet
Cambridge,Massachusetts02139
或發郵件到DCP@MIT-MC。

3.問題
世界總的來說是雜亂的，同時網絡增加了這種雜亂。幾乎在網絡架構的每一層，都有
幾個潛在的協議可以使用。例如在高一點的層次有用于遠程登錄的TELNET和SUPDUP。低一
點的有CHAOS，DODTCP，Xerox，BSP或DECnet等可靠字節流協議。甚至在與硬件較接近的
邏輯傳輸層也有CHAOS，DODInternet，XeroXPUP，DECnet等協議。10兆以太網通過使用
以太網包頭中的類型字段來使這些協議(而且更多)能在一根電纜上共存。然而，10兆以太
網在物理電纜上需要48比特地址，而大多數協議地址不是48比特，它們并不需要與硬件的
48比特以太網地址有什么關系。例如CHAOS的地址是16比特，DODInternet的地址是32
比特，XeroxPUP的地址是8比特。這就需要一個協議來動態地區分一個<協議，地址>對和
一個48比特以太網地址的對應關系。

4.動機
隨著更多的制造商提供遵循DEC，Intel和Xerox發布的規范的接口產品，10兆以太網
的使用也在增加。隨著使用的增加，為這個接口開發的軟件也越來越多。有兩個選擇：(1)
每個實現者用自己的方法做某種形式的地址轉換；(2)每個實現者使用統一標準，這樣代碼
可以不加修改的移植到其它系統。這個建議試圖建立一個標準。

5.定義
下面的定義是作為對填在以太網包頭的類型字段的值的參考。
ether_type$XEROX_PUP,
ether_type$DOD_INTERNET,
ether_type$CHAOS,
一個新的值
ether_type$ADDRESS_RESOLUTION
再定義以下的值(后面討論)
ares_op$REQUEST(=1,高位字節在前)和
ares_op$REPLY(=2),和
ares_hrd$Ethernet(=1).

6.包格式
為了把<協議，地址>對映射到48比特以太網地址用于傳輸，需要一個體現地址轉換協
議的包格式。包格式如下所示。
以太網傳輸層(并不是用戶需要訪問的)：
48比特：目的以太網地址
48比特：源以太網地址
16比特：協議類型=ether_type$ADDRESS_RESOLUTION
以太網包數據：
16比特：(ar$hrd)硬件地址空間(例如：Ethernet，PacketRadioNet。)
16比特：(ar$PRo)協議地址空間。對于以太網硬件，它屬于類型字段ether_type$<協
議>的集合
8比特：(ar$hln)每種硬件地址的字節長度
8比特：(ar$pln)每種協議地址的字節長度
16比特：(ar$op)操作碼(ares_op$REQUESTares_op$REPLY)
n字節：(ar$sha)源硬件地址，n從ar$hln字段得到

m字節：(ar$spa)源協議地址，m從ar$pln字段得到
n字節：(ar$tha)目的硬件地址(假如知道的話)
m字節：(ar$tpa)目的協議地址。

7.發包
當網絡層往下傳來一個包，路由將決定這個包下一跳的協議地址，并根據目的協議地
址決定用哪個硬件進行傳輸。在10兆以太網需要地址轉換。一些更低的層次(像硬件驅動層
)必須咨詢地址轉換模塊(也許在以太網支持模塊中實現)把<協議類型，目的協議地址>對轉
換成48比特以太網地址。地址轉換模塊試圖在一個表中尋找這個對。假如找到，則返回相

應的48比特以太網地址給調用者(硬件驅動層)。假如找不到，也許應通知調用者這個包正
在被丟棄(假定包會被高層重傳)，同時發出一個類型字段為ether_type$ADDRESS_RESOLUTI
ON的以太網包。地址轉換模塊在ar$hrd字段中填ares_hrd$Ethernet，在ar$pro字段中填
要被轉換的協議類型，在ar$hln字段中填6(48比特以太網地址字節數)，在ar$pln字段中
填該協議地址的字節數，在ar$op字段中填ares_op$REQUEST，在ar$sha字段中填自己的48
比特以太網地址，在ar$spa字段中填自己的協議地址，在ar$tpa字段中填要訪問機器的協
議地址。不能在ar$tha字段中填非凡的值，因為它的值正是要得到的。假如實現上簡單的話，
ar$tpa字段可以填硬件的廣播地址(在10兆以太網上所有機器)。根據原先的路由機制，這
個包將被廣播到所有在以太網電纜上的工作站。

8.收包
當收到地址轉換包時，收包模塊把它送到運行類似下面算法的地址轉換模塊。條件不
成立意味著處理結束，并丟棄包。
？我用ar$hrd字段中的硬件嗎？
是的：(幾乎肯定)
[檢查ar$hln的硬件地址長度(可選)]
？我用ar$pro字段中的協議嗎？
是的：
[檢查ar$pln的協議地址長度(可選)]
Merge_flag:=false
假如<協議類型，發送者協議地址>對在我的轉換表中，用包中的發送者硬件
地址更新表，并把Merge_flag設成true。
？我是目的協議地址嗎？
是的：
假如Merge_flag是false，在轉換表中加入三元組<協議類型，發送者協

議地址，發送者硬件地址>。
？操作碼是ares_op$REQUEST嗎？(現在看操作碼)
是的：
交換硬件和協議字段，把本地硬件和協議地址填在發送者字段中。
在ar$op字段中填ares_op$REPLY。然后從收到包的硬件上把這個包
發送到目的硬件地址。
注重到在檢查操作碼之前，<協議類型，發送者協議地址，發送者硬件地址>三元組就
被加入轉換表中。這是建立在通信是雙向的假設上的，假如A有某種理由與B“交談”，B也
會有某種理由與A“交談”。還注重到假如<協議類型，發送者協議地址>對已存在表項中，
新的硬件地址將覆蓋舊的。相關情況給出了這樣做的動機。
總結：ar$hrd和ar$hln字段使非10兆以太網可以使用這個協議和包格式。對于10兆
以太網，<ar$hrd,ar$hln>就是<1，6>。對于其它硬件網絡，ar$prozi字段也許不再對應以
太網類型字段，但會和地址轉換要看的協議有關。

9.為什么這么做
定期廣播并不是所期望的，假設一個以太網上有100臺主機，每隔10分鐘廣播地址轉換
信息(可能通過參數設置)，這樣每隔6秒鐘就有一個包。這完全合理，但有用嗎？工作站一
般不會互相通信(因此轉換表中有100個沒用的表項)，它們主要和大型機，文件服務器或網
橋通信，而僅和很少數量的主機通信(例如交互談話)。本文描述的協議只在需要時發送信
息，并且每臺機器每次啟動時只發一次。
這種包格式不答應在一個包中進行多于一個的轉換。這是為了簡單。假如復雜的話，
包將較難被分析，并且很多信息是沒用的。想想一個有四種協議的網橋告訴工作站四個協
議地址，而其中三個工作站從來都不會用到。
這種包格式答應應答包重用請求包的存儲空間，應答包和請求包具有相同的長度，有

些字段也相同。
硬件字段(ar$hrd)的值來自一個列表。現在只有為10兆以太網定義的一個值(ares_hrd
$Ethernet=1)。已經在討論在PacketRadioNetworks上使用這個協議，這需要為希望使
用這個協議的其它硬件介質分配值。
對于10兆以太網，協議字段(ar$pro)的值來自集合ether_type$，這是對已分配的協議
類型的自然重用。把它和操作碼(ar$op)結合起來，將有效地減半可使用這個協議轉換的協
議的數量，同時將對網絡監控和排錯造成更多的困難(見下面網絡監控和排錯)。希望不會
有32768個協議，但Murphy制造了一些不答應我們作這個假設的規則。
理論上，長度字段(ar$hln和ar$pln)是多余的，因為通過硬件類型(在ar$hrd中)和協
議類型(在ar$pro中)就可以決定協議地址的長度。它們被包括是為了可選的一致性檢查和
網絡監控和排錯(見下面)。
操作碼決定了是請求(可能導致一個應答)還是對先前請求的應答。16比特長了一些，
但這個字段是必須的。
發送者的硬件地址和協議地址絕對是有用的，通過它們才能從轉換表中得到結果。
在請求包格式中，目的協議地址是必須的，這樣機器才能決定是否把發送者信息放到
轉換表中，是否發送應答。假如假設應答是由請求引起的，那么在應答包中這個字段不是
必須的。包括它是為了完整性，網絡監控，和使上面描述的算法更簡單(把發送者信息放到
轉換表中后才去看操作碼)。
目的硬件地址被包括進來是為了完整性和網絡監控。它在請求包中毫無意義，因為機
器要問的就是這個數字。它在應答包中是處理請求機器的地址。在某些實現中(例如不檢察
14比特的以太網頭)，把這個字段作為包的目的硬件地址發送到硬件驅動器，存在寄存器或
?？臻g中。
地址間沒有填充字節。包數據被看作字節流，其中只有3個字節對可看作字(ar$hrd，a
r$pro和ar$op)，它們在發送時高位字節在前。

10.網絡監控和排錯
以上的地址轉換協議答應機器在以太網上獲得高層協議活動(例如CHAOS，Internet，
PUP，DECnet)的信息。它能決定哪個以太網地址正在使用(通過值)，以及每個協議類型的
協議地址。事實上，監控者不必使用任何一種高層協議。它象下面這樣工作：
當收到地址轉換包，它總是把<協議類型，發送者協議地址，發送者硬件地址>存入轉
換表。硬件和協議地址的長度可從包的ar$hln和ar$pln字段得到。假如操作碼是應答，監
控者可以丟棄這個包。假如操作碼是請求，并且目的協議地址與監控者的協議地址相同，
監控者通常會發應答包。監控者將只得到一個映射，因為請求的應答將被直接發送到請求
主機。監控者可試著發自己的請求，但要小心，這會造成兩個監控者陷入請求發送循環。
由于沒有把協議和操作碼合并成一個字段，監控者不必知道每個高層協議的請求操作
碼對應的應答操作碼。長度字段要帶有可“分析”協議地址的足夠信息，雖然它并不帶有
協議地址的意義。
地址轉換協議的一個成功實現還可為不成功的實現排錯。假設一個硬件驅動者成功地
廣播了以太網類型為ether_type$ADDRESS_RESOLUTION的包。由于實現的錯誤或維護表的復
雜性，包格式可能不正確。因為請求是廣播，監控者會收到這個包，假如需要可顯示出來
進行排錯。

11.一個例子
假設在同一根10兆以太網電纜上有機器X和Y。它們有以太網地址EA(X)和EA(Y)，DOD
Internet地址IPA(X)和IPA(Y)。假設Internet的以太網類型為ET(IP)。機器X剛啟動，并
且它遲早都會向機器Y發包。X知道要發包給IPA(Y)，并把IPA(Y)告訴硬件驅動者(這里是
以太網驅動者)。驅動者讓地址轉換模塊把<ET(IP)，IPA(Y)>轉換成48比特以太網地址，但
因為X剛啟動，它沒有這些信息。它先不發包，生成一個地址轉換包，
(ar$hrd)=ares_hrd$Ethernet
(ar$pro)=ET(IP)
(ar$hln)=EA(X)的長度
(ar$pln)=(IPA(X)的長度
(ar$op)=ares_op$REQUEST
(ar$sha)=EA(X)
(ar$spa)=IPA(X)
(ar$tha)=任意值
(ar$tpa)=IPA(Y)
并廣播到電纜上的所有機器。
機器Y收到這個包，判定自己是否懂這種硬件類型(以太網)，是否理解這種協議(Inter
net)，包是否是給自己的((ar$tpa)=IPA(Y))。然后把<ET(IP),IPA(X)>映射到EA(X)的信
息記下來(可能會覆蓋已有表項)。然后又意識到是請求，于是就交換字段，把EA(Y)填入發
送者以太網地址字段(ar$sha)，把操作碼設為應答，再把包直接發送(不是廣播)到EA(X)。
這個時候，Y已經知道怎樣向X發送，而X還不知道怎樣向Y發送。s
機器X收到Y發送的包，生成<ET(IP)，IPA(Y)>到EA(Y)的映射，意識到是個應答包，
于是丟棄。下次X的Internet模塊試圖向Y發送包，地址轉換就會成功了，并且包也能到達。
假如Y的Internet模塊要向X發送，它也會成功，因為Y已經從X的地址轉換請求中記住了
需要的信息。


12.相關情況
也許希望轉換表會過期，這些的實現超出本協議的范圍。這里有一個較具體的描述(感
謝MOON@SCRC@MIT-MC)。
當主機移動時，假設移動時清除了地址轉換表，那么從該主機發起的任何連接都可以
工作。但是發起過到該主機連接的其它主機并沒有任何理由會知道去丟棄它們的舊地址。
而48比特以太網地址是唯一的，任何時候都是固定的，不會變。假如主機名(和其它協議地
址)在不同物理硬件上被重新分配，主機就“移動”了。而且從經驗來說，總會存在由于硬
件或軟件錯誤產生的錯誤路由信息，但這種錯誤不答應永遠存在。也許發起某個連接的失
敗，會使地址轉換模塊認為由于對方當機或轉換表項錯誤等原因而不可到達對方。從而刪
除這個信息。也許收到一個來自某個主機的包，會更新用來向該主機發送的轉換表項的時
鐘。假如一定時間沒有收到來自某個主機的包，這條轉換表項會被刪除。這將產生為每個
收到的包掃描轉換表的額外負擔?；蛟S使用散列或索引會快一些。
收到地址轉換包的建議算法試圖縮短主機移動以后的恢復時間。假如<協議類型，發送
者協議地址>已經在轉換表中，那么發送者的硬件地址將覆蓋這個表項。因此在良好的以太
網上，當請求廣播到達后，每個工作站都將得到這個新的硬件地址。
另一種方法是有一個守護進程在處理超時。經過一定時間，守護進程考慮刪除一個表
項。它先用表里的以太網地址直接發送地址轉換請求包(假如需要可重傳幾次)。假如在一
段短時間內，沒有收到應答，則刪除表項。這個請求是直接發送的，不會影響以太網上的
每個工作站。刪除表項就是把必須重新獲得的有用信息刪除。
因為主機只發送關于它們自身的信息，而不會發送任何其它主機的信息，重啟動一個
主機會使它的地址映射表成為最新的。通過機器間的傳輸，錯誤信息不會永遠存在。機器

中唯一可存在的錯誤信息是不知道其它機器已經修改了48比特以太網地址。也許手工更新
(或清除)地址映射表就夠了。
假如認為重要的話，這篇文檔需要更多地思考。任何地址轉換類型的協議都用的到。
RFC826——AnEthernetAddressResolutionProtocolorConvertingNetworkProtocol
Addressesto48.bitEthernetAddressforTransmissiononEthernetHardware
以太網地址轉換協議或轉換網絡協議地址為48比特以太網地址用于在以太網硬件上傳輸