ARP RFC

組織：中國互動出版網（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-9-6版權：本中文翻譯文檔版權歸中國互動出版網全部。能夠用於非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。Network Working Group                                   David C. Plummer Request For Comments:  826                                  (DCP@MIT-MC)                                                           November 1982以太網地址轉換協議或轉換網絡協議地址爲48比特以太網地址用於在以太網硬件上傳輸（RFC826——An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware）目錄1.摘要 12.說明 33.問題 54.動機 55.定義 56.包格式 67.發包 68.收包 79.爲何這麼作 710.網絡監控和排錯 811.一個例子 912.相關狀況 91.摘要 經過路由機制，協議P在發送主機S上的實現決定了S須要傳輸到目標主機T，而T連在和S相連的10兆以太網電纜上。實際傳輸以太網包必須產生一個48比特以太網地址。主機的協議P地址並不老是和相應的以太網地址兼容(長度或值不一樣)。如今這個協議容許動態地發佈信息，這些信息可用來構造轉換協議P地址空間內的地址A爲48比特以太網地址的一張表。 容許在非10兆以太網硬件使用的協議已經被綜合總結，無線電網絡就是這種硬件。 [這篇RFC的目的是提出一種轉換協議地址(例如IP地址)爲本地網絡地址(例如以太網地址)的方法。這個問題如今受到ARPA Internet社區的廣泛關注，這裏提出的方法僅供讀者參考，並非Internet標準的描述。]2.說明 這個協議起初是爲DEC/Intel/Xerox的10兆以太網設計的，如今已容許用在其它類型的網絡上。許多討論將直接針對10兆以太網。總之，合適的話將遵循以太網的特定討論。 DOD Internet協議將做爲Internet的規範被參考。 這裏用到的數字，在以太網標準中是高位字節在前的，這和例如PDP-11，VAX等機器的字節編址相反，所以對下面描述的操做字段(ar$op)必須特別當心。 須要處理硬件名字空間已達成一致。直到官方承認，請求可發送到 David C. Plummer Symbolics, Inc. 243 Vassar Street Cambridge, Massachusetts  02139 或發郵件到DCP@MIT-MC。3.問題 世界總的來講是雜亂的，同時網絡增長了這種雜亂。幾乎在網絡架構的每一層，都有幾個潛在的協議可使用。例如在高一點的層次有用於遠程登陸的TELNET和SUPDUP。低一點的有CHAOS，DOD TCP，Xerox，BSP或DECnet等可靠字節流協議。甚至在與硬件較接近的邏輯傳輸層也有CHAOS，DOD Internet，Xerox PUP，DECnet等協議。10兆以太網經過使用以太網包頭中的類型字段來使這些協議(並且更多)能在一根電纜上共存。然而，10兆以太網在物理電纜上須要48比特意址，而大多數協議地址不是48比特，它們並不須要與硬件的48比特以太網地址有什麼關係。例如CHAOS的地址是16比特，DOD Internet的地址是32比特，Xerox PUP的地址是8比特。這就須要一個協議來動態地區分一個<協議，地址>對和一個48比特以太網地址的對應關係。4.動機 隨着更多的製造商提供遵循DEC，Intel和Xerox發佈的規範的接口產品，10兆以太網的使用也在增長。隨着使用的增長，爲這個接口開發的軟件也愈來愈多。有兩個選擇：(1)每一個實現者用本身的方法作某種形式的地址轉換；(2)每一個實現者使用統一標準，這樣代碼能夠不加修改的移植到其它系統。這個建議試圖創建一個標準。5.定義 下面的定義是做爲對填在以太網包頭的類型字段的值的參考。 ether_type$XEROX_PUP, ether_type$DOD_INTERNET, ether_type$CHAOS,一個新的值 ether_type$ADDRESS_RESOLUTION再定義如下的值(後面討論) ares_op$REQUEST (= 1, 高位字節在前) 和 ares_op$REPLY   (= 2), 和 ares_hrd$Ethernet (= 1).6.包格式 爲了把<協議，地址>對映射到48比特以太網地址用於傳輸，須要一個體現地址轉換協議的包格式。包格式以下所示。 以太網傳輸層(並非用戶須要訪問的)： 48比特：目的以太網地址 48比特：源以太網地址 16比特：協議類型 = ether_type$ADDRESS_RESOLUTION 以太網包數據： 16比特：(ar$hrd)硬件地址空間(例如：Ethernet，Packet Radio Net。) 16比特：(ar$pro)協議地址空間。對於以太網硬件，它屬於類型字段ether_type$<協 議>的集合 8比特：(ar$hln)每種硬件地址的字節長度 8比特：(ar$pln)每種協議地址的字節長度 16比特：(ar$op)操做碼(ares_op$REQUEST | ares_op$REPLY) n字節：(ar$sha)源硬件地址，n從ar$hln字段獲得 m字節：(ar$spa)源協議地址，m從ar$pln字段獲得 n字節：(ar$tha)目的硬件地址(若是知道的話) m字節：(ar$tpa)目的協議地址。7.發包 當網絡層往下傳來一個包，路由將決定這個包下一跳的協議地址，並根據目的協議地址決定用哪一個硬件進行傳輸。在10兆以太網須要地址轉換。一些更低的層次(像硬件驅動層)必須諮詢地址轉換模塊(也許在以太網支持模塊中實現)把<協議類型，目的協議地址>對轉換成48比特以太網地址。地址轉換模塊試圖在一個表中尋找這個對。若是找到，則返回相應的48比特以太網地址給調用者(硬件驅動層)。若是找不到，也許應通知調用者這個包正在被丟棄(假定包會被高層重傳)，同時發出一個類型字段爲ether_type$ADDRESS_RESOLUTION的以太網包。地址轉換模塊在ar$hrd字段中填ares_hrd$Ethernet，在ar$pro字段中填要被轉換的協議類型，在ar$hln字段中填6(48比特以太網地址字節數)，在ar$pln字段中填該協議地址的字節數，在ar$op字段中填ares_op$REQUEST，在ar$sha字段中填本身的48比特以太網地址，在ar$spa字段中填本身的協議地址，在ar$tpa字段中填要訪問機器的協議地址。不能在ar$tha字段中填特殊的值，由於它的值正是要獲得的。若是實現上簡單的話，ar$tpa字段能夠填硬件的廣播地址(在10兆以太網上全部機器)。根據原先的路由機制，這個包將被廣播到全部在以太網電纜上的工做站。8.收包 當收到地址轉換包時，收包模塊把它送到運行相似下面算法的地址轉換模塊。條件不成立意味着處理結束，並丟棄包。 ？我用ar$hrd字段中的硬件嗎？ 是的：(幾乎確定) [檢查ar$hln的硬件地址長度(可選)] ？我用ar$pro字段中的協議嗎？ 是的： [檢查ar$pln的協議地址長度(可選)] Merge_flag := false 若是<協議類型，發送者協議地址>對在個人轉換表中，用包中的發送者硬件 地址更新表，並把Merge_flag設成true。 ？我是目的協議地址嗎？ 是的： 若是Merge_flag是false，在轉換表中加入三元組<協議類型，發送者協 議地址，發送者硬件地址>。 ？操做碼是ares_op$REQUEST嗎？(如今看操做碼) 是的： 交換硬件和協議字段，把本地硬件和協議地址填在發送者字段中。 在ar$op字段中填ares_op$REPLY。而後從收到包的硬件上把這個包 發送到目的硬件地址。 注意到在檢查操做碼以前，<協議類型，發送者協議地址，發送者硬件地址>三元組就被加入轉換表中。這是創建在通訊是雙向的假設上的，若是A有某種理由與B「交談」，B也會有某種理由與A「交談」。還注意到若是<協議類型，發送者協議地址>對已存在表項中，新的硬件地址將覆蓋舊的。相關狀況給出了這樣作的動機。 總結：ar$hrd和ar$hln字段使非10兆以太網可使用這個協議和包格式。對於10兆以太網，<ar$hrd, ar$hln>就是<1，6>。對於其它硬件網絡，ar$prozi字段也許再也不對應以太網類型字段，但會和地址轉換要看的協議有關。9.爲何這麼作 按期廣播並非所指望的，假設一個以太網上有100臺主機，每隔10分鐘廣播地址轉換信息(可能經過參數設置)，這樣每隔6秒鐘就有一個包。這徹底合理，但有用嗎？工做站通常不會互相通訊(所以轉換表中有100個沒用的表項)，它們主要和大型機，文件服務器或網橋通訊，而僅和不多數量的主機通訊(例如交互談話)。本文描述的協議只在須要時發送信息，而且每臺機器每次啓動時只發一次。 這種包格式不容許在一個包中進行多於一個的轉換。這是爲了簡單。若是複雜的話，包將較難被分析，而且不少信息是沒用的。想一想一個有四種協議的網橋告訴工做站四個協議地址，而其中三個工做站歷來都不會用到。 這種包格式容許應答包重用請求包的存儲空間，應答包和請求包具備相同的長度，有些字段也相同。 硬件字段(ar$hrd)的值來自一個列表。如今只有爲10兆以太網定義的一個值(ares_hrd$Ethernet = 1)。已經在討論在Packet Radio Networks上使用這個協議，這須要爲但願使用這個協議的其它硬件介質分配值。 對於10兆以太網，協議字段(ar$pro)的值來自集合ether_type$，這是對已分配的協議類型的天然重用。把它和操做碼(ar$op)結合起來，將有效地減半可以使用這個協議轉換的協議的數量，同時將對網絡監控和排錯形成更多的困難(見下面網絡監控和排錯)。但願不會有32768個協議，但Murphy製造了一些不容許咱們做這個假設的規則。 理論上，長度字段(ar$hln和ar$pln)是多餘的，由於經過硬件類型(在ar$hrd中)和協議類型(在ar$pro中)就能夠決定協議地址的長度。它們被包括是爲了可選的一致性檢查和網絡監控和排錯(見下面)。 操做碼決定了是請求(可能致使一個應答)仍是對先前請求的應答。16比特長了一些，但這個字段是必須的。 發送者的硬件地址和協議地址絕對是有用的，經過它們才能從轉換表中獲得結果。 在請求包格式中，目的協議地址是必須的，這樣機器才能決定是否把發送者信息放到轉換表中，是否發送應答。若是假設應答是由請求引發的，那麼在應答包中這個字段不是必須的。包括它是爲了完整性，網絡監控，和使上面描述的算法更簡單(把發送者信息放到轉換表中後纔去看操做碼)。 目的硬件地址被包括進來是爲了完整性和網絡監控。它在請求包中毫無心義，由於機器要問的就是這個數字。它在應答包中是處理請求機器的地址。在某些實現中(例如不檢察14比特的以太網頭)，把這個字段做爲包的目的硬件地址發送到硬件驅動器，存在寄存器或棧空間中。 地址間沒有填充字節。包數據被看做字節流，其中只有3個字節對可看做字(ar$hrd，ar$pro和ar$op)，它們在發送時高位字節在前。10.網絡監控和排錯 以上的地址轉換協議容許機器在以太網上得到高層協議活動(例如CHAOS，Internet，PUP，DECnet)的信息。它能決定哪一個以太網地址正在使用(經過值)，以及每一個協議類型的協議地址。事實上，監控者沒必要使用任何一種高層協議。它象下面這樣工做： 當收到地址轉換包，它老是把<協議類型，發送者協議地址，發送者硬件地址>存入轉換表。硬件和協議地址的長度可從包的ar$hln和ar$pln字段獲得。若是操做碼是應答，監控者能夠丟棄這個包。若是操做碼是請求，而且目的協議地址與監控者的協議地址相同，監控者一般會發應答包。監控者將只獲得一個映射，由於請求的應答將被直接發送到請求主機。監控者可試着發本身的請求，但要當心，這會形成兩個監控者陷入請求發送循環。 因爲沒有把協議和操做碼合併成一個字段，監控者沒必要知道每一個高層協議的請求操做碼對應的應答操做碼。長度字段要帶有可「分析」協議地址的足夠信息，雖然它並不帶有協議地址的意義。 地址轉換協議的一個成功實現還可爲不成功的實現排錯。假設一個硬件驅動者成功地廣播了以太網類型爲ether_type$ADDRESS_RESOLUTION的包。因爲實現的錯誤或維護表的複雜性，包格式可能不正確。由於請求是廣播，監控者會收到這個包，若是須要可顯示出來進行排錯。11.一個例子 假設在同一根10兆以太網電纜上有機器X和Y。它們有以太網地址EA(X)和EA(Y)，DOD Internet地址IPA(X)和IPA(Y)。假設Internet的以太網類型爲ET(IP)。機器X剛啓動，而且它早晚都會向機器Y發包。X知道要發包給IPA(Y)，並把IPA(Y)告訴硬件驅動者(這裏是以太網驅動者)。驅動者讓地址轉換模塊把<ET(IP)，IPA(Y)>轉換成48比特以太網地址，但由於X剛啓動，它沒有這些信息。它先不發包，生成一個地址轉換包， (ar$hrd) = ares_hrd$Ethernet (ar$pro) = ET(IP) (ar$hln) = EA(X)的長度 (ar$pln) = (IPA(X)的長度 (ar$op)  = ares_op$REQUEST (ar$sha) = EA(X) (ar$spa) = IPA(X) (ar$tha) = 任意值 (ar$tpa) = IPA(Y)並廣播到電纜上的全部機器。 機器Y收到這個包，判斷本身是否懂這種硬件類型(以太網)，是否理解這種協議(Internet)，包是不是給本身的((ar$tpa)=IPA(Y))。而後把<ET(IP), IPA(X)>映射到EA(X)的信息記下來(可能會覆蓋已有表項)。而後又意識到是請求，因而就交換字段，把EA(Y)填入發送者以太網地址字段(ar$sha)，把操做碼設爲應答，再把包直接發送(不是廣播)到EA(X)。這個時候，Y已經知道怎樣向X發送，而X還不知道怎樣向Y發送。s 機器X收到Y發送的包，生成<ET(IP)，IPA(Y)>到EA(Y)的映射，意識到是個應答包，因而丟棄。下次X的Internet模塊試圖向Y發送包，地址轉換就會成功了，而且包也能到達。若是Y的Internet模塊要向X發送，它也會成功，由於Y已經從X的地址轉換請求中記住了須要的信息。12.相關狀況 也許但願轉換表會過時，這些的實現超出本協議的範圍。這裏有一個較詳細的描述(感謝MOON@SCRC@MIT-MC)。 當主機移動時，假設移動時清除了地址轉換表，那麼從該主機發起的任何鏈接均可以工做。可是發起過到該主機鏈接的其它主機並無任何理由會知道去丟棄它們的舊地址。而48比特以太網地址是惟一的，任什麼時候候都是固定的，不會變。若是主機名(和其它協議地址)在不一樣物理硬件上被從新分配，主機就「移動」了。並且從經驗來講，總會存在因爲硬件或軟件錯誤產生的錯誤路由信息，但這種錯誤不容許永遠存在。也許發起某個鏈接的失敗，會使地址轉換模塊認爲因爲對方當機或轉換表項錯誤等緣由而不可到達對方。從而刪除這個信息。也許收到一個來自某個主機的包，會更新用來向該主機發送的轉換表項的時鐘。若是必定時間沒有收到來自某個主機的包，這條轉換表項會被刪除。這將產生爲每一個收到的包掃描轉換表的額外負擔。或許使用散列或索引會快一些。 收到地址轉換包的建議算法試圖縮短主機移動之後的恢復時間。若是<協議類型，發送者協議地址>已經在轉換表中，那麼發送者的硬件地址將覆蓋這個表項。所以在良好的以太網上，當請求廣播到達後，每一個工做站都將獲得這個新的硬件地址。 另外一種方法是有一個守護進程在處理超時。通過必定時間，守護進程考慮刪除一個表項。它先用表裏的以太網地址直接發送地址轉換請求包(若是須要可重傳幾回)。若是在一段短期內，沒有收到應答，則刪除表項。這個請求是直接發送的，不會影響以太網上的每一個工做站。刪除表項就是把必須從新得到的有用信息刪除。 由於主機只發送關於它們自身的信息，而不會發送任何其它主機的信息，重啓動一個主機會使它的地址映射表成爲最新的。經過機器間的傳輸，錯誤信息不會永遠存在。機器中惟一可存在的錯誤信息是不知道其它機器已經修改了48比特以太網地址。也許手工更新(或清除)地址映射表就夠了。 若是認爲重要的話，這篇文檔須要更多地思考。任何地址轉換類型的協議都用的到。RFC826——An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware                 以太網地址轉換協議或轉換網絡協議地址爲48比特以太網地址用於在以太網硬件上傳輸1RFC文檔中文翻譯計劃