可以維護非局域網通訊的路由表，這就隱藏了大部分的子網結構。對子網和非子網都適
用的主機軟件的‘最少調整模型’就是位掩碼。
由于其自治性和已安裝的軟件的關系，以及沒有一個優秀的工業標準的原因，麻省
理工學院不計劃馬上使用這個協議，而是使用一套單一的物理連接和包交換機制，和在
這套機制上的幾個虛擬協議網絡。麻省理工學院曾經試圖在不同的協議間交換路由信
息，以及將一個協議包含在另一個協議中，從中得到一些教訓。除了基本的硬件，協議
因該是嚴格獨立的。使用ARP隱藏子網結構不是非常好，在一個復雜的系統（有環路
和不同的連接速率）中，ARP使地址操作過載。網關間需要一個更復雜的信息互換方
法。

   4．3 卡內基-梅隆大學（CMU）
卡內基-梅隆大學使用一個B類網絡，網絡被分為11個物理子網，2個3M的實驗
以太網，7個10M以太網和2個ProNET環。雖然分配主機地址時，使第三個8位字
節相同的地址在同一個子網上，但這只是為了管理方便，而不是必須的。軟件不知道這
個分配機制。
卡內基-梅隆大學使用一個基于ARP的網橋方案。當一臺主機發出ARP請求，收
到的網橋將原來的地址映射放入緩存，并將請求傳遞給其它的電纜。當網橋收到一個有
目標地址的ARP回復時，從緩存中尋找將這個回復送到哪條電纜上。這樣，網橋嘗試
將ARP協議透明的擴展到不同類的多電纜環境中。這就要求網橋將一條電纜上的廣播
變成所有連接著的電纜上的廣播。所以這個算法只在沒有連接環路的網絡上可行。將這
個簡單算法替換為支持冗余路徑和減低廣播負載的算法的工作正在進行中。
卡內基-梅隆大學使用支持3M以太網和10M proNET環的RFC-826 地址解析協
議。
因為卡內基-梅隆大學沒有冗余的連接電纜，因此不用關心網橋的崩潰問題。網絡
上150臺主機也使網橋有足夠的緩存，ARP廣播使用的帶寬也不大。
但卡內基-梅隆大學的網絡會從單一連接的小網絡發展成為有5000-10000臺主機
的連接整個校園的大網絡。基于ARP的網橋方案不再使用，需要一個有明確子網的系
統。中期的目標是建立一個可以引入沒有修改的IP實現的環境。其目的是盡可能的的
保持對主機透明的路由機制。

5．地址格式因特網信報控制協議（ICMP）
5．1 描述
地址格式請求或地址格式回復
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     類型      |      代碼     |          校驗和               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           標識                |         序列號                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP字段：
地址
地址格式請求消息的源地址就是地址格式回復消息的目的地址。為了
構成回復消息，請求的源地址成為回復的目標地址，回復消息的源地
址就設成回復者的地址。“類型”設成“A2“，“編碼”字段設為子
網字段的長度，然后計算校驗和。如果請求的源地址是0，那么回復
的目標地址就設成廣播地址。
因特網信報控制協議（ICMP）字段
類型
A1 表示地址格式請求消息
A2 表示地址格式回復消息
編碼
0 代表地址格式請求消息
非0代表地址格式回復消息的子網字段長度
校驗和
從因特網信報控制協議“類型”字段開始的16位的和的余數。計算
時，校驗和應為0。其值以后可能被改變。
標識
匹配請求和回復的標識，可以是0。
序列號
匹配請求和回復的序列號，可以是0。

收到地址格式請求的網關要回復這個請求。它需要將“編碼”字段置為請求的目表
地址網絡的子網字段的長度。如果請求是廣播的，其目標地址就是“這個網絡”。
子網字段的長度可以是0-（31-N）， N是IP網絡字段的長度（8，16或24）。
如果請求的主機不知道自己的地址，就可能把請求中的源地址置為0，回復則是廣
播的。因為一個網絡自由一種地址格式，所有就沒有必要匹配請求和回復。這種方
式應盡量避免，因為它會增加不必要的網絡流量。
類型A1可能從網關和主機收到
類型A2可能從網關和起網關作用的主機收到。


5．2 例子
下面例子中，我們假設請求主機的地址是36.40.0.123，網關是36.40.0.62，處于
網絡36.0.0.0中，使用8位子網。
首先，假設廣播是允許的，主機發送如下數據包：
源地址:          36.40.0.123
目標地址:        36.255.255.255
協議:            ICMP = 1
類型:            Address Format Request = A1
編碼:            0
36.40.0.62將收到這個數據包，并回復如下：
源地址:          36.40.0.62
目標地址:        36.40.0.123
協議:            ICMP = 1
類型:            Address Format Reply = A2
編碼:            8


下面的例子假設地址255.255.255.255 表示“廣播到這個物理網絡”。上面的例子
就無能為力了。因為這樣的廣播可能要廣播到多個子網。我們建議的最有效的方法
是，主機首先找到自己的地址（可以使用在參考[4]中描述的“反向地址解析協議”），
然后將ICMP請求發送到255.255.255.255。
源地址:          36.40.0.123
目標地址:        255.255.255.255
協議:            ICMP = 1
類型:            Address Format Request = A1
編碼:            0
網關就可以直接回復給請求主機。


假設36.40.0.123是無盤工作站，并不知道自己的主機號。它可以發送下面數據：
源地址:          0.0.0.0
目標地址:        255.255.255.255
協議:            ICMP = 1
類型:            Address Format Request = A1
編碼:            0
36.40.0.62將收到這個數據包，并回復：
源地址:          36.40.0.62
目標地址:        36.40.255.255
協議:            ICMP = 1
類型:            Address Format Reply = A2
編碼:            8


注意，網關使用最小的廣播范圍回復（發送到36.255.255.255將會在許多子網中
廣播，而并不單單是需要的子網）。即使這樣，這個廣播也造成不必要的網絡負載。
因此我們建議盡量少的使用“匿名（0.0.0.0）”源地址。
如果不允許廣播，假設主機有鄰接網關的硬編碼信息，則36.40.0.123會發送：
源地址:          36.40.0.123
目標地址:        36.40.0.62
協議:            ICMP = 1
類型:            Address Format Request = A1
編碼:            0
36.40.0.62 的回復和上例一樣

注意
有些A類網絡中的主機分配的主機號就是其以太網硬件地址的低24位。
我們討論的因特網廣播是基參考[6]的。
如果不支持廣播，則假設有主機知道鄰接網關地址，并發送ICMP到這個網關。
這就是前面提到的在同一個網絡中，透明子網和顯式子網的并存。

參考
D.R. Boggs, J.F. Shoch, E.A. Taft, 和 R.M. Metcalfe著，《Pup：一種因特網結構》， 
IEEE通訊學報， COM-28，4， 612-624頁， 1980年4月
David D. Clark著《名字，地址，端口和路由》，RFC-814，MIT-LCS，1982年7月
Yogan K. Dalal 和 Robert M. Metcalfe著，《廣播數據包的反向傳遞》，Comm. ACM 21, 
12,1040-1048頁，1978年12月
Ross Finlayson, Timothy Mann, Jeffrey Mogul和 Marvin Theimer著，《逆向地址解析
協議》，RFC-903，斯坦福大學，1984年6月
R.M. Metcalfe 和 D.R. Boggs著，《以太網：分布式的局域網包交換》，Comm. ACM 
19,7, 395-404頁， 1976年7月
Jeffrey Mogul著， 《廣播數據包》， RFC-919，斯坦福大學， 1984年10月
Da Jeffrey Mogul 著，《一種以太網地址解析協議》，RFC-826，1982年9月
Jon Postel著，《因特網協議》，RFC-791， USC-ISI， 1982年9月。
Jon Postel著，《因特網信報控制協議》，RFC-792， USC-ISI，1981年9月


RFC917——INTERNET SUBNETS                                    因特網子網


1
RFC文檔中文翻譯計劃