-
反向地址轉換協議
鎖定
- 中文名
- 反向地址轉換協議
- 外文名
- Reverse Address Resolution Protocol
- 簡 稱
- RARP
- 領 域
- 信息科學
反向地址轉換協議產生原因
ARP(地址解析協議)是設備通過自己知道的IP地址來獲得自己不知道的物理地址的協議。假如一個設備不知道它自己的IP地址,但是知道自己的物理地址,網絡上的無盤工作站就是這種情況,設備知道的只是網絡接口卡上的物理地址。這種情況下應該怎麼辦呢?RARP(逆地址解析協議)正是針對這種情況的一種協議。
RARP以與ARP相反的方式工作。RARP發出要反向解析的物理地址並希望返回其對應的IP地址,應答包括由能夠提供所需信息的RARP服務器發出的IP地址。雖然發送方發出的是廣播信息,RARP規定只有RARP服務器能產生應答。許多網絡指定多個RARP服務器,這樣做既是為了平衡負載也是為了作為出現問題時的備份。
反向地址轉換協議工作原理
- 發送主機發送一個本地的RARP廣播,在此廣播包中,聲明自己的MAC地址並且請求任何收到此請求的RARP服務器分配一個IP地址;
- 本地網段上的RARP服務器收到此請求後,檢查其RARP列表,查找該MAC地址對應的IP地址;
- 如果存在,RARP服務器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用;
- 如果不存在,RARP服務器對此不做任何的響應;
反向地址轉換協議工作過程
RARP的工作過程如下:
1、網絡上的每台設備都會有一個獨一的硬件地址,通常是由設備廠商分配的MAC地址。PC1從網卡上讀取MAC地址,然後在網絡上發送一個RARP請求的廣播數據包,請求RARP服務器回覆該PC的IP地址。
2、RARP服務器收到了RARP請求數據包,為其分配IP地址,並將RARP迴應發送給PC1。
反向地址轉換協議服務器
雖然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服務器同時應答,這樣會增加以太網發生衝突的概率。
[2]
反向地址轉換協議報文格式
反向地址轉換協議RARP服務器
RARP在原理上很簡單但是實現比較複雜,由於RARP的請求是在硬件層上的廣播這因此這不能通過路由轉發,因此在每個網絡都要實現一個RARP服務器。另外在同一網絡中不同主機可能會同時進行RARP請求,增大了衝突的概率。
[1]
反向地址轉換協議解決方法
解決RARP迴應問題的兩種方法。
- 為每一個做 RARP 請求的主機分配一主服務器,正常來説,只有主服務器才會做出 RARP 迴應,其它主機只是記錄下接收到 RARP 請求的時間。假如主服務器不能順利做出迴應,那麼查詢主機在等待逾時再次用廣播方式發送 RARP 請求,其它非主服務器假如在接到第一個請求後很短時間內再收到相同請求的話,才會做出迴應動作。