反向地址轉換協定

反向地址轉換協定（RARP：Reverse Address Resolution Protocol） 反向地址轉換協定（RARP）允許區域網路的物理機器從網關伺服器的 ARP 表或者快取上請求其 IP 地址。網路管理員在區域網路網關路由器里創建一個表以映射物理地址（MAC）和與其對應的 IP 地址。當設定一台新的機器時，其 RARP 客戶機程式需要向路由器上的 RARP 伺服器請求相應的 IP 地址。假設在路由表中已經設定了一個記錄，RARP 伺服器將會返回 IP 地址給機器，此機器就會存儲起來以便日後使用。 RARP 可以使用於乙太網、光纖分散式數據接口及令牌環 LAN

基本介紹

• 中文名：反向地址轉換協定
• 外文名：Reverse Address Resolution Protocol
• 簡稱：RARP
• 領域：信息科學

產生原因

ARP（地址解析協定）是設備通過自己知道的IP位址來獲得自己不知道的物理地址的協定。假如一個設備不知道它自己的IP位址，但是知道自己的物理地址，網路上的無盤工作站就是這種情況，設備知道的只是網路接口卡上的物理地址。這種情況下應該怎么辦呢？RARP（逆地址解析協定）正是針對這種情況的一種協定。

RARP以與ARP相反的方式工作。RARP發出要反向解析的物理地址並希望返回其對應的IP位址，應答包括由能夠提供所需信息的RARP伺服器發出的IP位址。雖然傳送方發出的是廣播信息，RARP規定只有RARP伺服器能產生應答。許多網路指定多個RARP伺服器，這樣做既是為了平衡負載也是為了作為出現問題時的備份。

工作原理

1. 傳送主機傳送一個本地的RARP廣播，在此廣播包中，聲明自己的MAC地址並且請求任何收到此請求的RARP伺服器分配一個IP位址；
2. 本地網段上的RARP伺服器收到此請求後，檢查其RARP列表，查找該MAC地址對應的IP位址；
3. 如果存在，RARP伺服器就給源主機傳送一個回響數據包並將此IP位址提供給對方主機使用；
4. 如果不存在，RARP伺服器對此不做任何的回響；
5. 源主機收到從RARP伺服器的回響信息，就利用得到的IP位址進行通訊；如果一直沒有收到RARP伺服器的回響信息，表示初始化失敗。

工作過程

RARP的工作過程如下：

1、網路上的每台設備都會有一個獨一的硬體地址，通常是由設備廠商分配的MAC地址。PC1從網卡上讀取MAC地址，然後在網路上傳送一個RARP請求的廣播數據包，請求RARP伺服器回復該PC的IP位址。

2、RARP伺服器收到了RARP請求數據包，為其分配IP位址，並將RARP回應傳送給PC1。

3、PC1收到RARP回應後，就使用得到的IP位址進行通訊。

伺服器

雖然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伺服器同時應答，這樣會增加乙太網發生衝突的機率。

報文格式

類似於ARP的報文格式主要差別在於幀類型代碼為0x8035（ARP為0x0806），操作碼為3請求（ARP為1），4應答（ARP為2）。

RARP伺服器

RARP在原理上很簡單但是實現比較複雜，由於RARP的請求是在硬體層上的廣播這因此這不能通過路由轉發，因此在每個網路都要實現以個RARP伺服器。另外在同一網路種不同主機可能會同時進行RARP請求，增大了衝突的機率。

解決方法

解決RARP回應問題的兩種方法。

1. 為每一個做 RARP 請求的主機分配一主伺服器，正常來說，只有主伺服器才會做出 RARP 回應，其它主機只是記錄下接收到 RARP 請求的時間。假如主伺服器不能順利做出回應，那么查詢主機在等待逾時再次用廣播方式傳送 RARP 請求，其它非主伺服器假如在接到第一個請求後很短時間內再收到相同請求的話，才會做出回應動作。
2. 正常來說，當主伺服器收到 RARP 請求之後，會直接做出回應；為避免所有非主伺服器同時傳回 RARP 回應，每台非主伺服器都會隨機等待一段時間再做出回應。如果主伺服器未能做出回應的話，查詢主機會延遲一段時間再進行第二次請求，以確保這段時間內獲得非主伺服器的回應。當然，設計者可以精心的設計延遲時間至一個合理的間隔。