組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：15222775@61. (15222775@61.  hbzzx2001@yahoo.com.cn) 
譯文發(fā)布時間：2001-11-24
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，
但必須保留本文檔的翻譯及版權(quán)信息。


Network Working Group                                          J. Postel
Request for Comments: 925                                            ISI
                                                            October 1984

多局域網(wǎng)地址解析
（RFC925——Multi-LAN Address Resolution）

備忘錄狀態(tài)

此備忘錄受Jeffery Mogul 在關于“互聯(lián)網(wǎng)自網(wǎng)”的RFC917觸發(fā)而作。在那個備
忘錄中，Mogul創(chuàng)建了一個多局域網(wǎng)環(huán)境下的“顯式子網(wǎng)”應用案例。本備忘錄中，
我力求建造一個“透明子網(wǎng)”的案例。這個RFC建立了一個由ARP網(wǎng)組織提交的協(xié)
議，并請求討論和提交意見以便進一步改善。本備忘錄的發(fā)行不受約束。
目錄
介紹	1
概論	1
總結(jié)	6
術(shù)語表	6
參考文獻：	8

介紹
將一組局域網(wǎng)（LAN）作為單個互聯(lián)網(wǎng)處理的問題已經(jīng)引起廣泛關注和興趣。在
同一地點內(nèi)的局域網(wǎng)都給與一個截然不盒子同的網(wǎng)絡號，這是不妥當?shù)摹Ａ钊藵M意的
做法是，對人員，網(wǎng)關和外部主機而言，地點內(nèi)各局域網(wǎng)間的細節(jié)是隱蔽的。面臨的
問題是最好怎么做，甚至上究竟怎么做。一個建議是使用“顯式子網(wǎng)[1]"。顯式子網(wǎng)方
案是一個把互聯(lián)網(wǎng)用于管理多個網(wǎng)絡的機制應用到在一個網(wǎng)絡內(nèi)的各局域網(wǎng)的管理問
題上的一個叫法。請注意，我強烈推薦另一個方法：使用一個由多局域網(wǎng)地址解析協(xié)
議擴展所支持的“透明子網(wǎng)”。
概論
迅速復習一下地址解析協(xié)議（ARP）。廣播型局域網(wǎng)上的每個主機不但知道它的局
域網(wǎng)物理地址（HA）同時還知道它的互聯(lián)網(wǎng)地址（IA）。當主機A得到主機B的IA
地址并向他發(fā)送一個數(shù)據(jù)報時，主機A必需知道與主機B相對應的HA。為了達到這
個目的，ARP包A產(chǎn)生一個ARP包，其中含有它自身的IA和HA地址以及目標主機
（主機B）的IA。主機A廣播這個ARP包。收到此ARP包的主機檢查此包，以確定
它們是否為被尋主機。如果是，他們（實際只有主機B）發(fā)送一個地址指向發(fā)出請求
者（主機A）的提供所需的HA地址的應答。現(xiàn)在，主機A已經(jīng)取得了目的地（主機
B）的所有IA,HA地址了。為了將來使用，主機A將這條消息加到它的緩存中。

注意，ARP實際上比這個簡要概述更為概括。此備忘錄的觀點是擴展ARP，使得
它能夠在一個局域網(wǎng)互聯(lián)環(huán)境中工作。
為了弄明白他是怎樣工作的，我們試想有一個“魔盒”，他就像一個平常主機一樣
連在兩個或多個LAN上。

各主機的行為應該與在基本ARP中的行為嚴格一致。

當任何主機廣播一個ARP請求時，盒子讀取它（如同局域網(wǎng)上所有主機一樣），
盒子檢查它的緩存，緩存中保存了每個局域網(wǎng)的IA:HA地址映射，然后判斷它是否為
正在尋找的那個（是，就給以答復）。

情況1：要是在發(fā)出請求的局域網(wǎng)所對應的緩存中找到了這個主機映射時，盒子
不應答。

情況2：要是在非發(fā)出請求的局域網(wǎng)所對應的緩存中找到了這個主機映射時，盒
子發(fā)出一個應答，給出他自己在發(fā)出請求的局域網(wǎng)內(nèi)的HA地址。盒子作為目的主機
的一個代理。

情況3：要是任何緩存中都找不到那個映射，盒子必須盡力找出這個地址，然后
象情況1或情況2那樣做出反應。

在情況3中，盒子不得不表演一些魔術(shù)：

盒子保持一張被尋主機搜索表。每個表項包含被尋主機的HA地址以及原始請求
主機的源地址和接收此ARP的接口。當情況3發(fā)生時，就檢查這個搜索列表。如果被
尋主機已經(jīng)列入此搜索列表中，就結(jié)束；否則，傳播此表。
為了傳播此搜索列表，先把一個表項寫在這個搜索列表上，然后組織并在除了收
到“引起搜索的ARP”包的接口之外的所有接口上發(fā)出這個ARP包。如果收到一個應
答，信息會被輸入到相應相應緩存中，相應表項在搜索列表中刪除，然后象情況1或
情況2那樣給那個“引起搜索的ARP”一個回答。

如果沒有收到響應，停止并且不作任何事情——沒有回答發(fā)給那個“引發(fā)”主機
（表項仍然留在搜索列表中）。
為了終止搜索，停止并且不作任何事情——沒有回答發(fā)給那個“引發(fā)”主機（表
項仍然留在搜索列表中）。
緩存和搜索列表中的表項很可能超時
。
對于收到的每一個ARP請求，盒子還必須把發(fā)送主機的IA:HA地址映射放入接
收它的局域網(wǎng)所對應的緩存中。
多局域網(wǎng)地址解析

這個計劃使用的還是ARP,新的成分不過是“魔盒”（“基于ARP 的橋"）,它將ARP
請求中繼到相鄰局域網(wǎng)，以便將數(shù)據(jù)報中繼到其他局域網(wǎng)上的主機而充當代理。
細節(jié)
    主機的行為應該與在基本ARP中的行為嚴格一致。

    局域網(wǎng)由“魔盒”（一些象主機一樣連到局域網(wǎng)上的與兩個或更多局域網(wǎng)連接
的計算機）。盒子執(zhí)行一下程序。
    各個盒子為它所連接的每個局域網(wǎng)（或每個局域網(wǎng)接口）保持一個列表。因
為表項回超時，所以表項應當是近期信息的緩存。這些表項是各個局域網(wǎng)的
IA:HA地址對。

    當一個ARP請求被任意一個主機廣播時，盒子讀取它（如同局域網(wǎng)上所有主
機所作的那樣）。另外，還要進行檢查，看看他是否為被尋找機（如果是就應
答）。盒子檢查它為每個所連局域網(wǎng)保持的IA:HA地址映射表的緩存。

    情況1：要是在發(fā)出請求的局域網(wǎng)所對應的緩存中找到了這個主機映射時，
盒子不應答（讓被尋主機自己響應）。表項超時不再重置。

    情況2：要是在非發(fā)出請求的局域網(wǎng)所對應的緩存中找到了這個主機映射時，
盒子發(fā)出一個應答，給出他自己在發(fā)出請求的局域網(wǎng)內(nèi)的HA地址。表項超
時不再重置。

          在這種情況下，盒子作為目的主機的一個代理。當一個IP數(shù)據(jù)報道打
這個盒子時，盒子必須盡力用地址映射緩存中的信息去轉(zhuǎn)發(fā)它。

        情況3：要是任何緩存中都找不到那個映射，盒子必須盡力找出這個地址，
然后象情況1或情況2那樣做出反應。
          盒子保持一張被尋主機（但沒找到）搜索表。每個表項包含被尋主機
的HA地址以及原始請求主機的源地址和接收此ARP的接口。當情況
3發(fā)生時，就檢查這個搜索列表。如果被尋主機已經(jīng)列入此搜索列表
中，就結(jié)束；否則，傳播此表。
       
為了傳播此搜索列表，先把一個表項寫在這個搜索列表上，然后組織
并在所有接口上發(fā)出這個ARP包。這些ARP請求含有盒子的HA,IA
地址，被尋主機的IA地址以及對被尋主機HA地址的請求。如果收到
此ARP應答，此信息會被輸入到相應緩存中，將相應表項在搜索列表
中刪除，然后象情況1或情況2那樣給那個“引起搜索的ARP”主機
一個回答。如果沒有收到響應，停止并且不作任何事情——沒有回答
發(fā)給那個“引發(fā)”主機（表項仍然留在搜索列表中）。

注意：盒子必須用它的ARP請求進行適當次數(shù)的嘗試，如果普通
主機ARP請求通常進行5次嘗試，那么它也應為此ARP進行5
次嘗試。

          為了終止搜索，停止并且不作任何事情——沒有回答發(fā)給那個“引發(fā)”
主機（表項仍然留在搜索列表中）。不存在發(fā)送給ARP請求的否定性
反饋信息，所以除了超時手段以外沒法判斷搜索的成功情況。
對于收到的每一個ARP請求，盒子還必須把發(fā)送主機的IA:HA地址映射放
入接收它的局域網(wǎng)所對應的緩存中。
緩存和搜索列表中的表項可能超時。

為了維護搜索列表而必須遵循的終止原則是：避免為一個沒有響應的主機無
窮盡地中繼ARP請求。一旦主機列入搜索列表，ARP請求講不被中繼。如
果一個停機的（或其他不響應ARP請求的）主機開機（或開始響應ARP請
求），那末，在表項超時之前，對其他網(wǎng)絡上的主機而言它一直是不可用的。

對此問題有兩個辦法：第一是搜索列表表項超時周期變短。第二是讓盒
子為搜索列表表項周期性的發(fā)送ARP。

        方案中有幾個超時。

            首先，主機盡力用ARP來進行地址解析。如果主機沒有被響應，他們可
能在得到之前進行多次嘗試。我們還必須給主機在嘗試其間的時間長度
（把它稱為時間T1）建立一個好的評估方法。

其次，還有表項停留在列表中的時間或從盒子產(chǎn)生ARP道地址得到解析
這段時間。稱為時間T2。

注意：這個時間段T2必須大于局域網(wǎng)最大回路中的T1時間之和。

再次，表項在每個局域網(wǎng)的緩存中停留時間，稱為時間T3。

他們之間的關系必須滿足：T!<T2<T3。

    一個建議是T1小于1分鐘，T2小于10分鐘，T3小于1小時。

如果環(huán)境非常穩(wěn)定，使T3變長可以導致搜索次數(shù)變少（ARP流量的開
銷變小）。如果環(huán)境不很穩(wěn)定，使得T3變短能更快的適應變化。

另外一個方案是，每次引用時緩存中表項的計時器，并建立一個較
小的T3值。這會導致頻繁使用的表項停留在緩存中，但很少使用的表項
很快就會被丟掉。不幸的是，頻繁使用和正確性之間不存在必然聯(lián)系。
它還會導致緩存中的一個過時表項保存很長一段時間表項，如果今已經(jīng)
收到地址映射ARP請求正好小于超時周期。處理定期的數(shù)據(jù)報時，盒子
回消耗IP數(shù)據(jù)包的生存時間（TTL）和更新IP數(shù)據(jù)包的頭部校驗和。如
果TTL變成0，數(shù)據(jù)包就會被丟棄（不轉(zhuǎn)發(fā)）。

ARP（按照當前的定義）最好能得到最多的近期的和過時的信息。（存在
連通回路的）復雜的多局域網(wǎng)環(huán)境中一個位于其他局域網(wǎng)上的主機可能
得到兩個（或更多）ARP請求的回答。第一個回答可能來自盒子，這是
最有效的一個路徑。

這里暗示了一個ARP主機信息的改變，防止更遲的信息替代了第一個回
答。
可能出現(xiàn)的問題
    不合法的緩存表項

    如果錯誤的信息進入了緩存表項，它將逗留一些時間（T3）。舊信息的存在會
阻止通信（一會兒），如果主機改變了它的HA：IA地址映射。
    取代緩存中的非法或超時表項的方法是，讓盒子明確的把廣播的ARP應答解
釋為請求一個已經(jīng)用較新的HA:IA映射替換了原有的HA:IA映射的一個表
項。還要一個重要的服務器，用于在他們出現(xiàn)時發(fā)送（廣播ARP應答）。

非ARP主機

    在同一局域網(wǎng)上全部為ARP主機或非ARP主機是不太實際的，所以只好寄
希望于他們能夠相互通信。所有主機為非ARP主機的情形將在下一個標題中
得到考察。
    不能實現(xiàn)ARP的主機必須使用其它的地址映射方法。他們要末保存一個所有
主機的完整表，要么通過某個協(xié)議訪問服務器中的上述表，要么指望根據(jù)地
址域中的分析所做的路由判斷。

非廣播局域網(wǎng)

    如果盒子所連接的局域網(wǎng)不具備廣播能力或者局域網(wǎng)上的主機不能響應
ARP，那么，為那個局域網(wǎng)（或可以從另一個地址算出的地址）建立一個靜
態(tài)或動態(tài)的HA:IA地址表。域網(wǎng)上的主機必須全部列于表內(nèi)。
    當盒子可以找到地址映射并將另外發(fā)送一個ARP請求進入非廣播局域網(wǎng)（只
有在所有主機都列入表內(nèi)而被尋主機位于非廣播局域網(wǎng)上時才有可能發(fā)生）
時，它改為專門給那個局域網(wǎng)上的每個盒子發(fā)送一個ARP類型請求。

表的尺寸

    盒子中最壞的表尺寸是一個表為所有局域網(wǎng)中的主機數(shù)。即，為每個局域網(wǎng)
接口所維護的表可能（在最壞的情況下）
增大到位整個局域網(wǎng)上的每個主機建立一個表項。然而，這些表實際上滿足
當前通訊活動所需的表項的緩存，并且這個典型化的情況遠遠不是最壞的。
大多數(shù)主機主要與他們局域網(wǎng)的主機通信而很少跟其他局域上的主機通信。
局域網(wǎng)上的大部分通信是工作站主機和服務器主機之間的通信。我們期望包
括主服務器主機和其他服務器主機的高頻通信放入大部分盒子的列表中。

無窮傳輸回路

        貫穿局域網(wǎng)互連集合的無窮傳輸回路的可能性可以通過維護盒子中的搜索列
表和當一個地址請求收到而已列入列表中時終止搜索來避免。
    周期性數(shù)據(jù)包的傳輸回路不可能持續(xù)，因為盒子必然消耗TTL，當數(shù)據(jù)包的
TTL為0時就會被丟棄。為了進行調(diào)試，
對一個盒子來說向其實現(xiàn)程序報告所有數(shù)據(jù)報被丟棄的原因是十分有用的。

廣播

    請注意廣播實際上沒有對透明子網(wǎng)或顯式子網(wǎng)做任何事情。在[1]中已經(jīng)討論
過，這里將再一次討論。在[1]中指出的三個廣播功能中的兩個與這里的完全
一致而且具有相同的結(jié)果。第三個也給于支持。
對于IA地址解析的廣播已經(jīng)討論過，顯式子網(wǎng)和透明子網(wǎng)也是個較大的爭論
點，應當分別對待。
它還暗示實際上我們并不需要廣播技術(shù)，相反，多點播送技術(shù)具有跟好的功
能。在接受廣播技術(shù)之前了解一下互聯(lián)網(wǎng)多點播送是如何工作的是明智之舉。

IP網(wǎng)絡

    如果使用了IA網(wǎng)絡號且主機號全為1（如，36.255.255.255）,IP將向這個網(wǎng)
絡（即，本地局域網(wǎng)）的所有主機進行廣播，這已經(jīng)被預定好了。盒子將轉(zhuǎn)
發(fā)這個數(shù)據(jù)報。盒子將檢查這個數(shù)據(jù)報，看它是否具有潛在的意義。