ARP：地址解析協議
RARP：逆地址解析協議
這兩個協議都是鏈路層協議（圖1-4）
當一臺主機把以太網數據幀發送到位於同一局域網上的另一臺主機時,是根據 48 bit的以太網地址來確定目的接口的。設備驅動程序從不檢查 IP數據報中的目的 IP地址。
一、ARP分組格式
以太網報頭中的前兩個字段是以太網的源地址和目的地址。目的地址爲全 1的特殊地址是廣播地址。電纜上的所有以太網接口都要接收廣播的數據幀。
兩個字節長的以太網幀類型表示後面數據的類型。對於 A R P請求或應答來說,該字段的值爲0x0806。
硬件類型字段表示硬件地址的類型。它的值爲 1即表示以太網地址。
協議類型字段表示要映射的協議地址類型。它的值爲 0 x 0 8 0 0即表示 I P地址。它的值與包含 I P數據報的以太網數據幀中的類型字段的值相同,這是有意設計的(參見圖 2-1)。
硬件地址長度和協議地址長度分別指出硬件地址和協議地址的長度,以字節爲單位。對於以太網上 IP地址的ARP請求或應答來說,它們的值分別爲 6和4。
操作字段指出四種操作類型,它們是 ARP請求(值爲1) ，ARP應答(值爲 2)， RARP請求(值爲 3)和RARP應答(值爲 4)。這個字段必需的,因爲 A R P請求和ARP應答的幀類型字段值是相同的。
接下來的四個字段是發送端的硬件地址(在本例中是以太網地址)、發送端的協議地址(I P地址)、目的端的硬件地址和目的端的協議地址。注意,這裏有一些重複信息:在以太網的數據幀報頭中和 ARP請求數據幀中都有發送端的硬件地址。
二、ARP協議
A R P 請求是廣播的，而ARP應答卻是直接送到請求端主機的。
三、ARP代理
以太網與外網相連的主機會接收外網發送的且目的地址爲本以太網的ARP請求，併發送回復，回覆中mac地址爲自己的mac。
舉個例子：主機A,IP地址是192.168.0.11/24。主機B，IP地址是192.168.1.22/24。主機A和主機B通過路由器R相連接，並且路由器R啓用了Proxy ARP，並配置有路由。網絡拓撲如下：
四、免費 ARP (gratuitous ARP)
它是指主機發送 A R P查找自己的IP地址。通常,它發生在系統引導期間進行接口配置的時候。
免費ARP可以有兩個方面的作用:
1) 一個主機可以通過它來確定另一個主機是否設置了相同的 IP地址。主機b s d i並不希望對此請求有一個回答。但是,如果收到一個回答,那麼就會在終端日誌上產生一個錯誤消息“以太網地址: a : b : c : d : e : f發送來重複的 I P地址”。這樣就可以警告系統管理員,某個系統有不正確的設置。
2) 如果發送免費 A R P的主機正好改變了硬件地址(很可能是主機關機了,並換了一塊接口卡,然後重新啓動),那麼這個分組就可以使其他主機高速緩存中舊的硬件地址進行相應的更新。一個比較著名的ARP協議事實[Plummer 1982]是,如果主機收到某個IP地址的ARP請求,而且它已經在接收者的高速緩存中,那麼就要用 A R P請求中的發送端硬件地址(如以太網地址)對高速緩存中相應的內容進行更新。主機接收到任何
A R P請求都要完成這個操作( A R P請求是在網上廣播的,因此每次發送 ARP請求時網絡上的所有主機都要這樣做)。
五、RARP
具有本地磁盤的系統引導時,一般是從磁盤上的配置文件中讀取 I P地址。但是無盤機,如X終端或無盤工作站,則需要採用RARP來獲得 IP地址。無盤系統的R A R P實現過程是從接口卡上讀取唯一的硬件地址,然後發送一份 R A R P請求(一幀在網絡上廣播的數據),請求某個主機響應該無盤系統的 IP地址(在RARP應答中)
六、RARP 分組格式
R A R P分組的格式與 A R P分組基本一致(見圖 4 - 3)。它們之間主要的差別是 R A R P請求或應答的幀類型代碼爲 0x8035,而且RARP請求的操作代碼爲 3,應答操作代碼爲 4。
對應於ARP，RARP請求以廣播方式傳送,而 RARP應答一般是單播 (unicast)傳送的。
七、RARP服務器設計
RARP服務器的複雜性在於,服務器一般要爲多個主機(網絡上所有的無盤系統)提供硬件地址到 I P地址的映射。該映射包含在一個磁盤文件中(在 U n i x系統中一般位於 / e t c / e t h e r s目錄中)。由於內核一般不讀取和分析磁盤文件,因此 RARP服務器的功能就由用戶進程來提供,而不是作爲內核的 TCP/IP實現的一部分。
爲了讓無盤系統在 RARP服務器關機的狀態下也能引導,通常在一個網絡上(例如一根電纜)要提供多個 RARP服務器。發送RARP請求的無盤系統一般採用最先收到的RARP應答。另外，還有一種可能發生的情況是每個RARP服務器同時應答，這樣會增加以太網發生衝突的概率。這時候，我們有兩種方法來解決RARP 的迴應問題。
第一種方法：爲每一個做 RARP 請求的主機分配一主服務器，正常來說，只有主服務器纔會做出 RARP 迴應，其它主機只是記錄下接收到 RARP 請求的時間。假如主服務器不能順利做出迴應，那麼查詢主機在等待逾時再次用廣播方式發送 RARP 請求，其它非主服務器假如在接到第一個請求後很短時間內再收到相同請求的話，纔會做出迴應動作。
第二種方法：正常來說，當主服務器收到 RARP 請求之後，會直接做出迴應；爲避免所有非主服務器同時傳回 RARP 迴應，每臺非主服務器都會隨機等待一段時間再做出迴應。如果主服務器未能做出迴應的話，查詢主機會延遲一段時間再進行第二次請求，以確保這段時間內獲得非主服務器的迴應。當然，設計者可以精心的設計延遲時間至一個合理的間隔。