如果<協議類型，發送者協議地址>對在我的轉換表中，用包中的發送者硬件
			地址更新表，并把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)。已經在討論在Packet Radio Networks上使用這個協議，這需要為希望使
用這個協議的其它硬件介質分配值。
	對于10兆以太網，協議字段(ar$pro)的值來自集合ether_type$，這是對已分配的協議
類型的自然重用。把它和操作碼(ar$op)結合起來，將有效地減半可使用這個協議轉換的協
議的數量，同時將對網絡監控和排錯造成更多的困難(見下面網絡監控和排錯)。希望不會
有32768個協議，但Murphy制造了一些不允許我們作這個假設的規則。
	理論上，長度字段(ar$hln和ar$pln)是多余的，因為通過硬件類型(在ar$hrd中)和協
議類型(在ar$pro中)就可以決定協議地址的長度。它們被包括是為了可選的一致性檢查和
網絡監控和排錯(見下面)。
	操作碼決定了是請求(可能導致一個應答)還是對先前請求的應答。16比特長了一些，
但這個字段是必須的。
	發送者的硬件地址和協議地址絕對是有用的，通過它們才能從轉換表中得到結果。
	在請求包格式中，目的協議地址是必須的，這樣機器才能決定是否把發送者信息放到
轉換表中，是否發送應答。如果假設應答是由請求引起的，那么在應答包中這個字段不是
必須的。包括它是為了完整性，網絡監控，和使上面描述的算法更簡單(把發送者信息放到
轉換表中后才去看操作碼)。
	目的硬件地址被包括進來是為了完整性和網絡監控。它在請求包中毫無意義，因為機
器要問的就是這個數字。它在應答包中是處理請求機器的地址。在某些實現中(例如不檢察
14比特的以太網頭)，把這個字段作為包的目的硬件地址發送到硬件驅動器，存在寄存器或
棧空間中。
	地址間沒有填充字節。包數據被看作字節流，其中只有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比特以太網地址是唯一的，任何時候都是固定的，不會變。如果主機名(和其它協議地
址)在不同物理硬件上被重新分配，主機就“移動”了。而且從經驗來說，總會存在由于硬
件或軟件錯誤產生的錯誤路由信息，但這種錯誤不允許永遠存在。也許發起某個連接的失
敗，會使地址轉換模塊認為由于對方當機或轉換表項錯誤等原因而不可到達對方。從而刪
除這個信息。也許收到一個來自某個主機的包，會更新用來向該主機發送的轉換表項的時
鐘。如果一定時間沒有收到來自某個主機的包，這條轉換表項會被刪除。這將產生為每個
收到的包掃描轉換表的額外負擔。或許使用散列或索引會快一些。
	收到地址轉換包的建議算法試圖縮短主機移動以后的恢復時間。如果<協議類型，發送
者協議地址>已經在轉換表中，那么發送者的硬件地址將覆蓋這個表項。因此在良好的以太
網上，當請求廣播到達后，每個工作站都將得到這個新的硬件地址。
	另一種方法是有一個守護進程在處理超時。經過一定時間，守護進程考慮刪除一個表
項。它先用表里的以太網地址直接發送地址轉換請求包(如果需要可重傳幾次)。如果在一
段短時間內，沒有收到應答，則刪除表項。這個請求是直接發送的，不會影響以太網上的
每個工作站。刪除表項就是把必須重新獲得的有用信息刪除。
	因為主機只發送關于它們自身的信息，而不會發送任何其它主機的信息，重啟動一個
主機會使它的地址映射表成為最新的。通過機器間的傳輸，錯誤信息不會永遠存在。機器

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


1
RFC文檔中文翻譯計劃