因特網子網

1.介紹
Inte.net在開始時被視為兩層結構，高層是作為一個整體的鏈式網，其下是一系列
“網絡”的集合，每一個網絡都有各自的網絡號。（雖然Internet的拓撲結構其實是不
分層的，但Internet的地址解析是分層的。）
這種做法曾一度被證明是簡單而有效的，但許多機構發現并不過充分。因此，在對
Internet地址的解析中加入了第三層。從這個觀點出發，某一特定的網絡就需要（也可
能不需要）分層一系列的子網。
將Internet視為兩層的觀點是建立在這樣一個假設之上的，即：對一臺處于某網絡
中的主機而言，它所處的網絡只有一個邊界，也就是說，這個網絡可以被視為一個有許
多主機相連著的黑盒。這對Internet早期的ARPA網來說是對的。因為IMPs屏蔽了網
絡中的特殊連接的使用。對大多數局域網技術來說也是這樣，比如以太網和環網。
但這種假設在許多實踐中卻是不對的。在一個中等大小的機構中，比如有好幾個建
筑物的大學和公司，常常需要多條局域網網線將“局部地區”相連。在寫這篇文檔是，
斯坦福大學就有18條這樣的網線，而且更多的還在計劃中。
要用多條網線連接幾個區域的原因有幾個：
? 不同的技術的網絡：特別是在研究環境中，可能會有幾個不同的局域網，例如，
某個機構有一些設備支持以太網，而另一些則支持環網。
? 技術的限制：多數技術由于起電氣參數的限制，而對連接的主機數和網線的總
長度有限制。這些限制，特別是網線長度很容易達到。
? 網絡擁塞：在一個局域網中，一小部分的主機很可能獨占大部分的帶寬。通常
解決這個問題的方法是把主機根據相互間通信的多少分成幾部分，各部分使用
不同的網線。
? 點對點的連接：有時一個“局部區域”被分成幾個部分，而個部分之間的距離
對上述局域網技術來說太遠了。在這種情況下，高速的點對點連接可以用來連
接這些局域網。

對不得不使用多個局域網的機構來說，分配Internet地址有三種選擇：
1. 為每一條網線分配一個網絡號。
2. 為整個機構分配一個網絡號，并給主機分配地址，而不理會主機在哪個局
域網中。
3. 使用一個網絡地址，并分成幾個地址空間，從中給每個局域網分配一個子
網地址（顯式子網）。
每一種方法都有缺點。第一種方法雖然不需要修改和增加現有協議，但會導致路由
表的急劇增大，整個網絡的內部連通性信息傳播于整個Internet，而這些信息對這個機
構以外的世界沒有用處。特別是現在有些網關沒有很大的路由表空間。所以這樣的問題
應該避免。
第二種方法需要一定的協議把某些局域網的整合成一個單一的網絡。例如，在使用
地址解析協議（ARP）的局域網中，Internet地址被解析成為硬件地址，局域網間的網
橋會攔截ARP對非本地目標的請求。但不是所有的局域網技術都可以做到這一點，特
別是沒有使用ARP或不支持廣播協議的。一個更基本的問題是，網橋要知道每臺主機
在哪個局域網中（這些信息可以用廣播算法獲得），隨著主機的增多，廣播的代價也隨
之增大，轉換所需的緩沖也隨之增大。
第三種方法的關鍵問題是：校友的標準認為所有同一局域網上的主機都是用同一網
線相連的。解決方法是顯式的支持子網。這就需要改變現有的Internet協議，改變現在
正在使用的IP的實現方法。但我們認為，這樣的改動不是很大，而且只需修改一次，
就能得到一個簡單有效的解決方法。我們在本文檔中使用的方法會避免導致和現有的非
子網上的主機不兼容的修改。
當找到合適的方法，就有可能是子網內的主機并不知道自己處于子網中。這點在后
面會解釋。當不能修改主機以使其支持“顯式子網”時，這樣做是非常有用的。
1．1.術語
為了講述的清楚和簡潔，這里定義一些術語，并在以后的文中使用：
鏈式網：連接在一起的網絡的集合
網絡：Internet中的一個網絡（可以分成子網，也可以不分）
子網：網絡中的一部分
網絡號：見參考[8]
本地地址：Internet地址中沒有分配給網絡號使用的位，也叫“剩余位”
子網號：網絡中標識子網的號碼
子網位：Internet地址中分配給子網號使用的位
主機位：Internet地址中用于指明特定主機使用的位
網關：連接兩個或更多不同網絡或子網，傳遞數據的節點
網橋：連接兩個或更多物理上可分，但管理上不可分的子網，在必要使傳遞數據包
的節點，主機不知道其存在。
2子網地址分配標準
根據參考[2]中的描述，劃分子網也就是地址的分配問題。在這部分中，我們首先
提出一個支持子網的地址解析方案，然后討論這種地址格式和廣播之間的關系，最后給
出一個地址解析協議。
2．1Internet地址的解析
假設某機構分配到一個網絡號，并將之分成一系列子網，再分配給主機。如何進行
呢？因為對于Internet地址中本地地址部分的分配限制很少，因此對子網號的分配主要
有以下幾種方法：
a) 變長字段：本地地址部分任意位都可以給子網號使用，雖然這部分長度對
某一特定網絡是一定的，但各網絡間可以不同。如果長度是0，則說明沒
有使用子網。
b) 定長字段：指定長度的字段（比如8位）用語子網號（在使用子網的情
況下）。
c) 自編碼變長字段：網絡好的字段長度是由其高位決定，相似的，子網號的
字段長度也由其高位決定。
d) 自編碼定長字段：一定長度的字段給子網使用。如果最高位是1，則使用
子網，否則沒有使用。
用什么標準從這四個方案中選擇一個呢？首先，確定是否要選用自編碼方案，也就
是說能否通過檢測一個因特網地址就能得知這個地址是否用道子網？
自編碼的一個優點是，人們能知道一個非本地的網絡是否被劃分成子網。這是否
有用還不是很清楚。但主要的好處是不需要額外的信息來說明兩個地址是否在同一子
網上。然而，從另一個角度看，這也會是個缺點：對于非子網網絡，如果有主機在其
地址的本地地址字段中任意使用，則會導致問題（1）。也就是說，如果能夠獨立于主
機地址的分配而控制網絡是否子網，這會非常有用。另一個自編碼方案的缺點是，給主
機使用的地址空間會減少至少2位。
如果沒有使用自編碼方案，很明顯，變長子網字段方案是合適的。既然任何情況下
每個網絡都有“標志”顯示是否使用子網，使用整數型標志比使用布爾型標志所多的耗
費也就可以忽略。使用變長子網字段的好處是允許每個機構選擇最好的分配方案，以應
付給子網和主機使用的地址位數的相對不足。
因此，我們提議的因特網地址的解析是：
<網絡號><子網號><主機號>
網絡號使用的位在參考[8]中有述。主機號字段至少長1位。子網字段的長度在一
個網絡中是固定的。子網字段和主機字段不需要其他的數據。如果子網字段的長度是0，
則說明沒有使用子網。
例如，在一個A類網絡中的有8位長的子網字段，則它的地址如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|網絡|子網|主機號|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
為了實現的簡單和有效，我們希望所有的機構都使用8位或者8的倍數的子網字
段長度。但作為一個統一的實現方法，必須能夠其他可能的長度。
我們反對“遞歸子網”的使用，就是將主機號字段再分成子網和主機兩部分。因為：
- 沒有對四層結構的明顯的需求。
- IP地址中沒有足夠的位使這種方法有實用價值。
- 需要復雜的而外機制
2．2為支持子網，軟件所需的改動
在大多數IP的實現中，處理向外發送數據包的模塊里常有類似下面的代碼：
IFip_net_number(packet.ip_dest)=ip_net_number(my_ip_addr)
THEN
send_packet_locally(packet,packet.ip_dest)
ELSE
send_packet_locally(packet,
gateway_to(ip_net_number(packet.ip_dest)))
IF因特網網絡號（數據包的目標地址）=自己的網絡號
THEN
發送本地數據包
ELSE
發送本地數據包到網關
為了支持子網，需要另一個32位的值，成為網絡掩碼。這是一個位掩碼，各個位
的設置和IP網絡號以及子網號相對應。例如，一個A類網絡使用8位子網字段，則其
掩碼為255.255.0.0。
則上述的程序代碼變為：
IFbitwise_and(packet.ip_dest,my_ip_mask)
=bitwise_and(my_ip_addr,my_ip_mask)
THEN
send_packet_locally(packet,packet.ip_dest)
ELSE
send_packet_locally(packet,
gateway_to(bitwise_and(packet.ip_dest,my_ip_mask)))
當然，部分條件的表達式可以預先計算好。
函數"gateway_to"可能需要修改，以做類似的比較和判斷。
為支持連接在多個網絡上的主機，程序可以給每個網絡接口設置各自的
"my_ip_addr"和"my_ip_mask"，上述代碼中的比較和判斷也要對每個網絡接口進行。
2．3子網和廣播
在沒有子網的情況下，因特網協議中只可能有兩種廣播：廣播給指定網絡中的所有
主機，或者是廣播給本身網絡的所有主機。后一種方法在主機不知到自己在哪個網絡中
是很有用。
當使用了子網后，情況就變的復雜了。首先，產生了廣播給特定子網的可能性。第
二，廣播給子網中的所有主機需要附加的機制。最后，“廣播給本身網絡“的解釋變成
“廣播給本身子網”
這中的實現中必須認識3中廣播地址以及自己的主機地址：
本身的物理網絡
所有位都是1的目標地址（255.255.255.255）將使數據包在本地的物理網絡中進
行廣播，網關并不傳遞這些數據包。
指定的網絡
目標地址中有有效的網絡地址，而本地地址部分都是1（例如：36.255.255.255）。
指定的子網
目標地址中的網落地址和子網地址有效，而主機號字段都是1（比如：
36.40.255.255）。
因特網廣播的更深入的討論參看[6]。
一個有助于決定是否使用子網的因素是：某臺主機是否需要用一步操作就能給所有
主機廣播。如果兩臺主機不在同一網絡中，就不可能用一個步驟就給它們廣播。
2．4決定子網字段的長度
一臺主機怎么知道該使用多長的子網字段呢？這個問題和幾個“引導程序”的問題
很相似：一臺主機怎么知道自己的地址以及怎么知道網關的地址。對這三個問題，有兩
個基本的解決辦法：“硬編碼”的信息和基于廣播的協議。
“硬編碼”信息是指主機不通過網絡就能獲得的信息?？梢允蔷幾g好的，或者更
好的方法是存放在磁盤文件中。但對于不斷增加的無盤工作站來說，由于它是從網絡啟
動的，所以兩種“應編碼”的方法都不適用。而大多數的局域網技術都支持廣播，因此
另一個較好的方法是啟動的主機廣播所需要信息的要求。比如，為了知道自己的因特網
地址，可以使用“逆向地址解析協議”[4]。
我們建議將ICMP[9]協議（因特網信報控制協議）進行擴展，加入一對新的ICMP
消息類型：“地址格式請求”和“地址格式回復“，和“信息請求”和“信息恢復”消
息很相似。細節參看附錄1。
當一臺主機啟動時，廣播新加入的ICMP消息“地址格式請求“<3>.網關（或相當
于網關的主機）接收到后，回復以”地址格式回復“。如果請求中沒有說明是哪臺主
機發送的（源IP地址是0），則回復消息以廣播形式發出。發出請求的主機就能接收到
這個消息，從而知道自己的子網字段長度。
在“地址格式請求”中只可能有一個值，所以發出請求的主機就沒有必要去匹配請
求和回復：就是有多個網關回復也沒有關系。我們認為主機不會經常從新啟動，所以網
絡上這兩個消息的廣播負載是很小的。
如果主機連在好幾個局域網上，它需要對每個局域網使用這個協議，除非它能確定
（從其中一個網絡的回復）幾個局域網是在同一個網絡中的。在這種情況下，其地址會
有相同的子網字段長度。
一個潛在的問題是如果主機重復好多次都沒有收到對“地址格式請求”的響應時該
怎么辦。有三種原因可能導致這種情況：
1． 局域網沒有和其他的網絡相連（永久的）。
2． 沒有使用子網，而且沒有主機支持這兩個ICMP請求。
3． 所有的網關都沒有正常工作（暫時的）
第一、二種情況意味著子網字段長度是0。第三種情況下沒法知道其值會是什么：
最安全的選擇是0。雖然很可能是錯的，但這樣不會阻止原來可以成功的數據傳送。
當網關恢復工作以后，當它收到“地址格式請求”時，就會回復，主機就可以獲得正確
的信息，并將自身的數據相應的調整。主機和網關不應該發送基于“猜”出的“地址格
式回復”。
最后，要注意并不要求主機使用這兩個ICMP協議消息來獲得子網字段長度，特別
是對于有穩定存儲介質的主機。
3．子網路由方法
一個因特網所有主機都要面對的是怎么決定到另一臺主機的路由。在有子網的情況
下，這個問題只需要很小的改變。
使用子網后，路由過程就要處理兩個層次。如果目標主機和源主機在同一個網絡中，
只需要子網間的網關來決定路由。而如果目標主機和源主機在不同的網絡中，則需要網
絡間的網關和子網間的網關共同來決定路由。
幸運的是，許多主機可以使用“缺省”的網關作為所有路由的第一個目標，在回復
ICMP主機重定向消息時再定義更多的合適的路由。但這種方法對于網關和連在多個網
絡中的主機來說效率太低，而應該使用路由信息交換協議。這超出了本文檔的討論范圍，
在沒有子網的情況下也存在這個問題。
對于只連在一個網絡上的主機，需要找到至少一個鄰接的網關。同樣，也有兩個解
決辦法：硬編碼和廣播。鄰接網關的問題在不使用子網時也存在，用不用子網對次問題
沒有影響。
但還存在另一個問題：源主機必須知道數據包是直接發送給目標主機還是要通過網
關發送？也就是要知道目標主機和源主機是否在同一個物理網絡上。這是路由過程中唯
一一處需要知道子網的地方。事實上，如果不使用廣播，這也是因特網的實現中唯一需
要修改的地方。
所以，有可能不用修改就可以使用現有的方法使之支持子網<4>。這樣的實現方法
必須具備如下條件：
- 只給連接一個網絡的主機使用，也不給網關使用。
- 使用在有廣播的局域網中。
- 使用地址解析協議ARP，如[7]。
- 不需要維護和網關的連接。
在這種情況下，可以修改子網網關上的地址解析ARP服務模塊，當它接收到地址
解析請求時，檢查數據包是否正由最佳路由傳遞。如果是，則將自己的硬件地址回復給
源主機。源主機認為網關的地址就是目標地址，并將數據包發送給這個地址。實際上，
網關將接收到這些數據包，并將之傳遞到目標地址。
這種方法使網關中的處理層次不是很清楚，因為通常情況下，地址解析服務器和路
由表沒有聯系?？紤]到這點，這種方法不是非常令人滿意。但實現起來相當簡單，而且
沒有顯著的性能損失。問題是如果原來的網關出問題后，主機沒有辦法選擇另一個網關。
這樣，一條在其他方法下可以成功的連接就斷了。
不要混淆“基于地址解析協議的子網技術”和“基于地址解析協議的網橋”的簡單
使用。前者是基于網關能檢查IP地址從而推導出路由的能力，基于顯式的子網的拓撲
結構。一小部分的路由功能從主機轉移到網關上。而基于地址解析協議的網橋則在不知
道主機地址和網絡拓撲結構的條件下，知道各主機的位置。
注意：基于地址解析協議的子網技術由于廣播的使用而變的復雜。地址解析服務器
對目標地址是廣播地址的請求作出響應。這樣的請求只可能來自于不認識廣播地址的主
機。這將導致數據包的循環傳遞。如果在一個物理網絡中有N個不認識廣播地址的主
機，那么，生存時間是T的數據包將會被重復廣播T**N的時間。

4．例子
這部分我們簡要的介紹幾個機構的子網使用。
4．1斯坦福大學
在斯坦福大學，最初的子網是由于歷史原因而引入的。自979年以來（當時因特
網協議還沒有使用），斯坦福在幾個實驗性的以太網中使用Pup協議，使用了很多Pup
的網關，所有的主機和網關之間使用廣播協議相互交換路由表信息。
當引入因特網協議后，決定采用8位長的子網，以使因特網子網的數目和各個以
太網中的Pup網絡數目想匹配。Pup主機的字段長（也是8位）也被作為因特網的主
機地址字段的長度
只支持Pup的網關作了修改，使其可以根據Pup的路由表傳遞因特網數據包。這
種網關不對IP包中的‘生存時間’（Time-to-live）字段進行操作。當時傳遞環路的錯
誤沒有表現出來。
因特網主機做了修改以理解子網（有好幾種方法，效果都相同）。因為所有主機都
已經實現了Pup，所以因特網的路由表的維護過程和維護Pup的一樣，只要簡單的把
Pup網絡號變成因特網子網號就行了。
加入10M以太網后，網關修改為使用地址解析協議（ARP）的，這樣可以不用修
改主機。
因特網子網在1982年早期就開始使用了，當時有大約330臺主機，18個子網，
18個子網網關。當只支持Pup的網關換成真正的因特網網關后，會引入基于因特網的
路由信息交換協議，Pup逐漸停止使用。

4．2麻省理工學院（MIT）
麻省理工學院是第一個有大量局域網連接的使用因特網的地方。當時還沒有進行網
絡分類，如果每一條連接都分配一個網絡號的話，會用掉大量的可用地址空間。麻省理
工學院決定使用一個網絡號，并自己管理地址中余下的24位。這些位被分成3個8位
字段：子網字段，保留字段（其值為0）和主機字段。在此之前麻省理工學院使用的
CHAOS協議中使用8位長子網，所以兩個協議中可以使用同樣的子網號。而使用8位
主機地址是因為CHAOS協議中大多數的硬件都使用8位地址。保留的8位則是為以
后使用。
最初計劃在子網網關間使用動態路由協議，并有好幾個協議提出，但沒有人愿意去
實現一個，因此靜態路由表依然被使用。
為了解決引入軟件需要修改以使其能在子網環境中工作，麻省理工學院想找到一個
對IP軟件做最少修改的模型。這個模型就是IP網關發送ICMP主機重定向消息，而不
是網絡重定向消息。所有的麻省理工學院內部IP網關都是這樣的。因為每一臺主機都
可以維護非局域網通訊的路由表，這就隱藏了大部分的子網結構。對子網和非子網都適
用的主機軟件的‘最少調整模型’就是位掩碼。
由于其自治性和已安裝的軟件的關系，以及沒有一個優秀的工業標準的原因，麻省
理工學院不計劃馬上使用這個協議，而是使用一套單一的物理連接和包交換機制，和在
這套機制上的幾個虛擬協議網絡。麻省理工學院曾經試圖在不同的協議間交換路由信
息，以及將一個協議包含在另一個協議中，從中得到一些教訓。除了基本的硬件，協議
因該是嚴格獨立的。使用ARP隱藏子網結構不是非常好，在一個復雜的系統（有環路
和不同的連接速率）中，ARP使地址操作過載。網關間需要一個更復雜的信息互換方
法。

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

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

IP字段：
地址
地址格式請求消息的源地址就是地址格式回復消息的目的地址。為了
構成回復消息，請求的源地址成為回復的目標地址，回復消息的源地
址就設成回復者的地址?！邦愋汀痹O成“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
類型:AddressFormatRequest=A1
編碼:0
36.40.0.62將收到這個數據包，并回復如下：
源地址:36.40.0.62
目標地址:36.40.0.123
協議:ICMP=1
類型:AddressFormatReply=A2
編碼:8


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


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


注意，網關使用最小的廣播范圍回復（發送到36.255.255.255將會在許多子網中
廣播，而并不單單是需要的子網）。即使這樣，這個廣播也造成不必要的網絡負載。
因此我們建議盡量少的使用“匿名（0.0.0.0）”源地址。
如果不允許廣播，假設主機有鄰接網關的硬編碼信息，則36.40.0.123會發送：
源地址:36.40.0.123
目標地址:36.40.0.62
協議:ICMP=1
類型:AddressFormatRequest=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月
DavidD.Clark著《名字，地址，端口和路由》，RFC-814，MIT-LCS，1982年7月
YoganK.Dalal和RobertM.Metcalfe著，《廣播數據包的反向傳遞》，Comm.ACM21,
12,1040-1048頁，1978年12月
RossFinlayson,TimothyMann,JeffreyMogul和MarvinTheimer著，《逆向地址解析
協議》，RFC-903，斯坦福大學，1984年6月
R.M.Metcalfe和D.R.Boggs著，《以太網：分布式的局域網包交換》，Comm.ACM
19,7,395-404頁，1976年7月
JeffreyMogul著，《廣播數據包》，RFC-919，斯坦福大學，1984年10月
DaJeffreyMogul著，《一種以太網地址解析協議》，RFC-826，1982年9月
JonPostel著，《因特網協議》，RFC-791，USC-ISI，1982年9月。
JonPostel著，《因特網信報控制協議》，RFC-792，USC-ISI，1981年9月