1.介紹
有些網(wǎng)絡主機，例如無盤工作站，在啟動的時候通常不知道協(xié)議地址，它們只知道
硬件接口地址。為了使用象ip這樣的高層協(xié)議進行通訊，它們必須從外部來發(fā)現(xiàn)它們的
協(xié)議地址。我們的問題是沒有標準機制來做這些。
Plummer的“地址轉換協(xié)議”（ARP）[1]被設計用來解決一個相關的問題：給定主機
的協(xié)議地址得到它的硬件地址。這篇RFC提出了“反向地址轉換協(xié)議”。和ARP一樣，
我們假設一種廣播介質，例如以太網(wǎng)。
2.設計考慮
以下的考慮指導我們對RARP協(xié)議的設計。
A. ARP和RARP是不同的操作。ARP假設每一個主機都知道它的硬件地址和協(xié)
議地址間的映射。一個小緩存存放了收集到的關于其他主機的信息。所有的主機在
狀態(tài)上是平等的，沒有客戶機和服務器的區(qū)別。
另一方面，RARP需要一個或者更多的服務器主機來維護一個存有從硬件地址
到協(xié)議地址的映射的數(shù)據(jù)庫，并對客戶機的請求作出應答。
B. 前面提到RARP需要維護大數(shù)據(jù)庫的服務器主機，這并不是所希望的，在某
些情況下不可能在操作系統(tǒng)的內(nèi)核中維護這樣一個數(shù)據(jù)庫。因此，大多數(shù)實現(xiàn)需要
和內(nèi)核外的程序做某種形式的互操作。
C. 實現(xiàn)的簡單和對已存在主機軟件影響最小是重要的，設計一個需要改變每一個
主機的軟件（而不管其是否參與）的協(xié)議是錯誤的。
D. 為了最小化開發(fā)成本和費用，希望考慮和已有軟件共享代碼的可能性。
3.推薦協(xié)議
我們建議RARP作為數(shù)據(jù)鏈路層單獨的協(xié)議。例如，假如介質使用以太網(wǎng)，RARP
包和ARP包將有不同的以太網(wǎng)類型。這意味著ARP和RARP是兩種不同的操作，所有
的主機并不平等地支持它們。對已存在系統(tǒng)的影響也最小，已有的ARP服務器不會被
ARP包弄糊涂。它把RARP看作一個能把硬件地址映射到任何高層協(xié)議地址的常用工
具。
這個方法使RARP客戶端主機的實現(xiàn)最簡單，但同時也使得RARP服務器端主機的
實現(xiàn)很困難。然而這種困難是沒辦法的，從附錄A中描述的4.2BSDUnix下兩種可能的
實現(xiàn)就可以看出。
RARP使用和ARP相同的包格式。
ar$hrd（硬件地址空間）16比特
ar$PRo（協(xié)議地址空間）16比特
ar$hln（硬件地址長度）8比特
ar$pln（協(xié)議地址長度）8比特
ar$op（操作碼）16比特
ar$sha（源硬件地址）n比特，n來自ar$hln字段
ar$spa（源協(xié)議地址）m比特，m來自ar$pln字段
ar$tha（目的硬件地址）n比特
ar$tpa（目的協(xié)議地址）m比特
ar$hrd、ar$pro、ar$hln和ar$pln與ARP相同（見[1]）。
例如，假設硬件地址是48比特以太網(wǎng)地址，協(xié)議地址是32比特Internet地址，我
們希望決定對應已知的以太網(wǎng)地址的Internet地址，那么在每個RARP包中，ar$hrd=1
（以太網(wǎng)），ar$pro=2048（IP包的以太網(wǎng)類型），ar$hln=6，ar$pln=4。
有兩個操作碼：3（請求）和4（應答）。1或2在[1]中有相同的意義，帶有這樣操
作碼的包被當作ARP包通過。帶有其它操作碼的包并沒有定義。和ARP一樣，RARP
沒有“找不到”和“錯誤”的包，因為許多RARP服務器可自由地應答請求。假如經(jīng)過
一段時間后，沒有收到應答，RARP請求的發(fā)送者將超時。
RARP包中ar$sha、ar$spa、ar$tha和ar$tpa字段的解釋如下：
當操作碼是3（請求）：
ar$sha是發(fā)送者的硬件地址
ar$spa未定義
ar$tha是目的硬件地址
當發(fā)送者希望知道自己的協(xié)議地址的情況下，和ar$sha一樣將是發(fā)送者
的硬件地址。
ar$tpa未定義
當操作碼是4（應答）：
ar$sha是響應者的硬件地址（應答包的發(fā)送者）
ar$spa是響應者的協(xié)議地址（見下面的注重）
ar$tha是目的硬件地址，必須和請求包中得到的相同
ar$tpa是目的協(xié)議地址，即需要得到的地址。
注重：在操作碼為4的包中ar$spa字段填響應者的協(xié)議地址，只是為了方便。例如，
系統(tǒng)同時使用ARP和RARP，有效的協(xié)議-硬件對（ar$spa，ar$sha）會減少以后發(fā)ARP
請求的需要。
4.參考
[1] Plummer,D.,"AnEthernetAddressResolutionProtocol",RFC826,MIT-LCS,
November1982.
附錄A.4.2BSDUnix下的兩個實現(xiàn)例子
下面的實現(xiàn)描述概括了4.2BSDUnix下實現(xiàn)RARP服務器的兩種不同方法。
A. 提供在內(nèi)核外訪問數(shù)據(jù)鏈路層包。RARP服務器完全在內(nèi)核外實現(xiàn)，只在收發(fā)RARP
包時和內(nèi)核進行互操作。內(nèi)核被修改成能提供接口來訪問這些包，目前4.2內(nèi)核只
答應訪問IP包。CMU的“包過濾”偽驅動是提供這種功能的現(xiàn)有機制。它在CMU
和斯坦福實現(xiàn)“用戶級”網(wǎng)絡服務器排序上，使用的很成功。
B. 在內(nèi)核里維護一個數(shù)據(jù)庫表項的緩存。整個RARP服務器數(shù)據(jù)庫通過一個用戶進程
在內(nèi)核外維護。RARP服務器本身直接在內(nèi)核中實現(xiàn)，并為應答維護一個小的數(shù)據(jù)
表項緩存。這個緩存和傳輸ARP的相同。這個緩存通過兩個新的輸入輸出控制從實
際的RARP數(shù)據(jù)庫得到（這像SIOCIFADDR，因為他們不直接和具體的套接字相關）。
一種是：“睡眠直到需要進行地址轉換，然后把請求直接輸出到用戶進程”；另一種
是：“把地址轉換輸入內(nèi)核表”。因此，當內(nèi)核不能在緩存中發(fā)現(xiàn)一個表項的時候，
把這個請求放到隊列中，然后調用wakeup()。第一個輸入輸出控制的實現(xiàn)是sleep()，
從隊列中取出第一項返回給用戶進程，因為內(nèi)核不能在中斷級等待直到用戶進程回
應，它或者放棄（假設請求主機一定時間后會重傳請求包），或者假如第二個輸入輸
出控制把請求拷貝到內(nèi)核，在那個時候應答。