介紹
反向地址轉換協定就是將區域網路中某個主機的物理地址轉換為IP位址，比如區域網路中有一台主機只知道物理地址而不知道IP位址，那么可以通過RARP協定發出徵求自身IP位址的廣播請求，然後由RARP伺服器負責回答。RARP協定廣泛用於獲取無盤工作站的IP位址。
反向地址轉換協定（RARP）允許區域網路的物理機器從網關伺服器的 ARP 表或者快取上請求其 IP 地址。網路管理員在區域網路網關路由器里創建一個表以映射物理地址（MAC）和與其對應的 IP 地址。當設定一台新的機器時，其 RARP 客戶機程式需要向路由器上的 RARP 伺服器請求相應的 IP 地址。假設在路由表中已經設定了一個記錄， RARP 伺服器將會返回 IP 地址給機器，此機器就會存儲起來以便日後使用。RARP 可以使用於乙太網、光纖分散式數據接口及令牌環LAN 。
產生原因
ARP(地址解析協定)是設備通過自己知道的IP位址來獲得自己不知道的物理地址的協定。假如一個設備不知道它自己的IP位址，但是知道自己的物理地址，網路上的無盤工作站就是這種情況，設備知道的只是網路接口卡上的物理地址。這種情況下應該怎么辦呢?RARP(逆地址解析協定)正是針對這種情況的一種協定。
RARP以與ARP相反的方式工作。RARP發出要反向解析的物理地址並希望返回其對應的IP位址，應答包括由能夠提供所需信息的RARP伺服器發出的IP位址。雖然傳送方發出的是廣播信息，RARP規定只有RARP伺服器能產生應答。許多網路指定多個RARP伺服器，這樣做既是為了平衡負載也是為了作為出現問題時的備份。
協定結構
RARP 協定頭結構和 ARP 相同：
RARP協定Hardware Type ― 指定一種硬體接口類型，為傳送方請求回響所用。
Protocol Type ― 指由傳送方提供的高級協定地址類型。
Hlen ― 硬體地址大小。
Plen ― 協定地址大小。
Operation ― 各個值如下表所示：
RARP協定Sender Hardware Address ― HLen二進制大小
Sender Protocol Address ― PLen二進制大小
Target Hardware Address ― HLen二進制大小
Target Protocol Address ― PLen二進制大小
伺服器
雖然RARP在概念上很簡單，但是一個RARP伺服器的設計與系統相關而且比較複雜。相反，提供一個ARP伺服器很簡單，通常是TCP/IP在核心中實現的一部分。由於核心知道IP位址和硬體地址，因此當它收到一個詢問IP位址的ARP請求時，只需用相應的硬體地址來提供應答就可以了。作為用戶進程的RARP伺服器的複雜性在於:伺服器一般要為多個主機(網路上所有的無盤系統)提供硬體地址到IP位址的映射。該映射包含在一個磁碟檔案中(在Unix系統中一般位於/etc/ethers目錄中)。由於核心一般不讀取和分析磁碟檔案，因此RARP伺服器的功能就由用戶進程來提供，而不是作為核心的TCP/IP實現的一部分。
更為複雜的是，RARP請求是作為一個特殊類型的乙太網數據幀來傳送的(幀類型欄位值為0x8035)。這說明RARP伺服器必須能夠傳送和接收這種類型的乙太網數據幀。由於傳送和接收這些數據幀與系統有關，因此RARP伺服器的實現是與系統捆綁在一起的。
每個網路有多個RARP伺服器實現的一個複雜因素是RARP請求是在硬體層上進行廣播的。這意味著它們不經過路由器進行轉發。為了讓無盤系統在RARP伺服器關機的狀態下也能引導，通常在一個網路上(例如一根電纜)要提供多個RARP伺服器。當伺服器的數目增加時(以提供冗餘備份)，網路流量也隨之增加，因為每個伺服器對每個RARP請求都要傳送RARP應答。傳送RARP請求的無盤系統一般採用最先收到的RARP應答。另外，還有一種可能發生的情況是每個RARP伺服器同時應答，這樣會增加乙太網發生衝突的機率。
解決方法
解決RARP回應問題的兩種方法
第一種方法:為每一個做RARP請求的主機分配一主伺服器，正常來說，只有主伺服器才會做出RARP回應，其它主機只是記錄下接收到RARP請求的時間。假如主伺服器不能順利做出回應，那么查詢主機在等待逾時再次用廣播方式傳送RARP請求，其它非主伺服器假如在接到第一個請求後很短時間內再收到相同請求的話，才會做出回應動作。
第二種方法:正常來說，當主伺服器收到RARP請求之後，會直接做出回應;為避免所有非主伺服器同時傳回RARP回應，每台非主伺服器都會隨機等待一段時間再做出回應。如果主伺服器未能做出回應的話，查詢主機會延遲一段時間再進行第二次請求，以確保這段時間內獲得非主伺服器的回應。當然，設計者可以精心的設計延遲時間至一個合理的間隔。
