組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：沈進（simon_shen   shen_jin@263.net）
譯文發布時間：2001-8-14
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。





Network Working Group								Finlayson, Mann, Mogul, Theimer
Request for Comments: 903							Stanford University 
												June 1984


反向地址轉換協議
（RFC903——A Reverse Address Resolution Protocol）

Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer 
Computer Science Department
Stanford University
June 1984
本備忘錄狀態：
	本RFC文檔講述了當工作站只知道硬件地址（例如：它們的物理網絡地址）時，動態
發現協議地址（例如：Internet地址）的一種方法。
	本RFC文檔講述了ARPA網絡社區的一種建議協議，需要討論和建議去加強。
目錄
1.介紹	1
2.設計考慮	2
3.推薦協議	2
4.參考	3
附錄A. 4.2BSD Unix下的兩個實現例子	3

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


1
RFC文檔中文翻譯計劃