RFC903_反向地址轉(zhuǎn)換協(xié)議

1、RFC903A Reverse Address Resolution Protocol 反向地址轉(zhuǎn)換協(xié)議組織：中國互動出版網(wǎng)（/）RFC文檔中文翻譯計劃（/compters/emook/aboutemook.htm）E-mail：譯者：沈進（simon_shen shen_）譯文發(fā)布時間：2001-8-14版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權信息。Network Working G

2、roupFinlayson, Mann, Mogul, TheimerRequest for Comments: 903Stanford University June 1984反向地址轉(zhuǎn)換協(xié)議（RFC903A Reverse Address Resolution Protocol）Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer Computer Science DepartmentStanford UniversityJune 1984本備忘錄狀態(tài)：本RFC文檔講述了當工作站只知道硬件地址（例如：它們的物理網(wǎng)絡地址）時，

3、動態(tài)發(fā)現(xiàn)協(xié)議地址（例如：Internet地址）的一種方法。本RFC文檔講述了ARPA網(wǎng)絡社區(qū)的一種建議協(xié)議，需要討論和建議去加強。目錄1.介紹12.設計考慮23.推薦協(xié)議24.參考3附錄A. 4.2BSD Unix下的兩個實現(xiàn)例子31.介紹有些網(wǎng)絡主機，例如無盤工作站，在啟動的時候通常不知道協(xié)議地址，它們只知道硬件接口地址。為了使用象IP這樣的高層協(xié)議進行通訊，它們必須從外部來發(fā)現(xiàn)它們的協(xié)議地址。我們的問題是沒有標準機制來做這些。Plummer的“地址轉(zhuǎn)換協(xié)議”（ARP）1被設計用來解決一個相關的問題：給定主機的協(xié)議地址得到它的硬件地址。這篇RFC提出了“反向地址轉(zhuǎn)換協(xié)議”。和ARP一樣，我們

4、假設一種廣播介質(zhì)，例如以太網(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)的簡單和對已

5、存在主機軟件影響最小是重要的，設計一個需要改變每一個主機的軟件（而不管其是否參與）的協(xié)議是錯誤的。D. 為了最小化開發(fā)成本和費用，希望考慮和已有軟件共享代碼的可能性。3.推薦協(xié)議我們建議RARP作為數(shù)據(jù)鏈路層單獨的協(xié)議。例如，如果介質(zhì)使用以太網(wǎng)，RARP包和ARP包將有不同的以太網(wǎng)類型。這意味著ARP和RARP是兩種不同的操作，所有的主機并不平等地支持它們。對已存在系統(tǒng)的影響也最小，已有的ARP服務器不會被ARP包弄糊涂。它把RARP看作一個能把硬件地址映射到任何高層協(xié)議地址的常用工具。這個方法使RARP客戶端主機的實現(xiàn)最簡單，但同時也使得RARP服務器端主機的實現(xiàn)很困難。然而這種困難是沒辦法

6、的，從附錄A中描述的4.2BSD Unix下兩種可能的實現(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)地

7、址，協(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$tp

8、a字段的解釋如下：當操作碼是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$sh

9、a）會減少以后發(fā)ARP請求的需要。4.參考1 Plummer, D., “An Ethernet Address Resolution Protocol”, RFC 826, MIT-LCS, November 1982.附錄A. 4.2BSD Unix下的兩個實現(xiàn)例子下面的實現(xiàn)描述概括了4.2BSD Unix下實現(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的“包過濾”偽驅(qū)動是提供這種功能的現(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，因為他們不直接和具體的套接字相關）。一種是：“睡眠直到需要進行地址轉(zhuǎn)換，然后把請求直接輸出到用戶進程”；另一種是：“把地址轉(zhuǎn)換輸入內(nèi)核表”。因此，當內(nèi)核不能在緩存中發(fā)現(xiàn)一個表項