組織：中國互動出版網（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) 
譯文發布時間：2001-11-24
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，
但必須保留本文檔的翻譯及版權信息。


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

多局域網地址解析
（RFC925——Multi-LAN Address Resolution）

備忘錄狀態

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        方案中有幾個超時。

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

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

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

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

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

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

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

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

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

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

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

非ARP主機

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

非廣播局域網

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

表的尺寸

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

無窮傳輸回路

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

廣播

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

IP網絡

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