2．2 為支持子網，軟件所需的改動  
在大多數IP的實現中，處理向外發送數據包的模塊里常有類似下面的代碼：
         IF ip_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。
則上述的程序代碼變為：
         IF bitwise_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 決定子網字段的長度
一臺主機怎么知道該使用多長的子網字段呢？這個問題和幾個“引導程序”的問題
很相似：一臺主機怎么知道自己的地址以及怎么知道網關的地址。對這三個問題，有兩
個基本的解決辦法：“硬編碼”的信息和基于廣播的協議。
 “硬編碼”信息是指主機不通過網絡就能獲得的信息。可以是編譯好的，或者更
好的方法是存放在磁盤文件中。但對于不斷增加的無盤工作站來說，由于它是從網絡啟
動的，所以兩種“應編碼”的方法都不適用。而大多數的局域網技術都支持廣播，因此
另一個較好的方法是啟動的主機廣播所需要信息的要求。比如，為了知道自己的因特網
地址，可以使用“逆向地址解析協議”[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網關都是這樣的。因為每一臺主機都