組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王安鵬（anpengwang    anpengwang@263.net）
譯文發布時間：2001-4-24
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必
須保留本文檔的翻譯及版權信息。


Network Working Group                                          A. Retana
Request for Comments: 3021                                      R. White
Category: Standards Track                                  Cisco Systems
                                                               V. Fuller
                                                     GTE Internetworking
                                                            D. McPherson
                                                          Amber Networks
                                                           December 2000


           
在Ipv4點對點連接中使用31位前綴
(RFC3021  Using 31-Bit Prefixes on IPv4 Point-to-Point Links)

本備忘錄的狀態

本文檔描述了用于一種Internet社區的Internet標準跟蹤協議，需要進一步探討和建議
進行完善。請查詢“Internet正式協議標準”（STD1）的當前版本了解本協議的標準化進程和
狀態。本備忘錄的發布沒有限制。

版權公告

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

摘要

隨著節約Internet IP地址空間的壓力的不斷增加，實際運用相對較小的改進提高編號效率的
看法越來越有意義。本文檔提出的改進建議是把分配給點對點連接（普遍存在于Internet底層
結構中）的地址空間平分成兩部分，從而可以在非常有限的范圍內使用31位字網掩碼。

目錄
1．簡介與動機	2
2.對31位前綴的深入思考	2
2.1.地址（Addressing）	3
2.2. 廣播和網絡地址	3
2.3. 對當前路由協議的影響（Impact on Current Routing Protocols）	4
3. 建議（Recommendations）	4
3.1."對Internet主機的要求——通信層（Communication Layers）" [RFC1122]	4
3.2. "分配號（Assigned Numbers）" [RFC1700]	4
3.3. "對IPv4路由器的要求" [RFC1812]	5
4. 操作試驗（Operational Experience）	5
5. 應用考慮	6
6. 安全考慮	6
7. 鳴謝	6
8. 引用	6
9. 作者地址	7
版權聲明	8

1．簡介與動機
    認識到Internet地址短缺的問題，已經出現了幾種對地址空間使用的改進和解決之一問題
的不同辦法：

   -由IANA和地方的權威地址分配機構強制執行更加嚴格的地址空間分配政策[RFC2050]。

   - [RFC1631].使用網絡地址轉移器（NATs），許多用戶聯合起來共用少量的符合IANA的地
址，NAT內部沒有全球性的拓撲發送地址[RFC1631]。


   -發布新的Internet協議，增加地址空間。IPv6就是此類協議中的一個，已經通過IEIF程
序，但是還沒有出現相應的產品。及時發布了這樣的產品，也還要面臨著多年的轉變過程。

在可以使用更大的地址空間之前，有機會更加有效地利用現有的地址空間似乎是謹慎的看
法。

此類改進的一個（很小的）的機會是點對點連接編號已達到極限。一種選擇是——目前在
Internet的某些部分正是用著——簡單地把路由器之間的連接不作為點對點編號。盡管初看起
來這種方法很方便地解決了問題，但是本身也帶來了幾個問題，包括不能一致地處理未編號的
連接或者經過這樣的連接訪問路由器、管理和調試這些連接的困難性，以及標準的缺乏
[RFC1812]。

當前的實際應用中，Internet子網編號（大多數情況下）使用不超過30位的子網掩碼，
每個連接需要4個地址——兩個主機地址，一個全0的網絡地址和一個全1的廣播地址。不幸
的是點對點連接只能有兩個不同的端點，而且也不支持廣播——一端發出的任何包只能由連接
的另一端接收。

第三種選擇是使用點對點連接的兩端地址。這種方法可以節約與使用31位子網掩碼同樣的
地址空間，但是只能用于使用PPP包裝的連接[RFC1332]。使用主機地址允許為連接的兩端分配
屬于不同網絡的IP地址，這樣會造成連接和網絡管理是間接的。

本文基于這樣一種觀點，即在點對點連接中節約IP地址（使用超過30位的子網掩碼），
而同時保持可維護性和標準的交互是可能的。現存的文檔[RFC950]已經暗示了使用1位寬的主
機號碼域的可能性。

這種改進帶來的地址空間的節約是顯而易見的——大型網絡中的每個點對點連接都是用2
個地址而不是4個。比方說，在一個包含500個點對點連接的網絡中，這種方法可以節約1000
個地址（與C類地址空間相同）
2.對31位前綴的深入思考
本節討論在點對點連接中使用31位前綴對Internet路由和操作可能帶來的影響。這里的
斟酌還會在第三節反映處來。

   For the length of this document, an IP address will be interpreted
   as:按照本文描述的長度，IP地址可以被認為是：

        <網絡號><主機號>

   其中<主機號>是地址的非掩碼部分，應至少有1位寬。 符號“-1”用來表示這個域的所有
位均為1。根據這個討論，路由系統可以被認為支持類型無關的路由CIDR [RFC1519]。

2.1.地址（Addressing）
    如果為點對點連接分配了31位字網掩碼，就只剩下一位留給<主機號>，因此只能有兩個地
址：
        {<網絡號>, 0} 和 {<網絡號>, -1}
    這些地址在原來已經被用于網絡和廣播地址（見節2.2）。在應用31位字網掩碼的點對點
連接中，這兩個地址必須被解釋為主機地址。
2.2. 廣播和網絡地址
在IP地址段中原來有幾個公認的廣播地址：

      (a) 直接廣播
           {<網絡號>, -1}
           {<網絡號>, 0}

         網絡地址{<網絡號>, 0}是直接廣播的過時形式 ，但可能還用于老式主機。
      (b)本地（或有限的）廣播
           {-1, -1}
           {0, 0}

         有限廣播的{0，0}形式已經過時了，但還可以在網絡上見到。

    使用31位長度的前綴只留下兩種編號的可能性（見節2.1），從而排除了連接中直接廣播
的使用（見節2.2.1）。分配了31位字網掩碼的點對點連接必須使用有限廣播進行所有的廣播
通信。

   <網絡號>由網絡管理員分配，在本地路由域中是唯一的 。目標IP地址是否進行直接廣播取
決于與目標段直接相連的路由器。當前的轉發方案和算法不會在遠程路由器受到影響。

   本文的目的在于探討點對點連接31位前綴的實用性和操作。沒有考慮對其它類型接口的影
響（如果有的話）。

2.2.1.直接廣播（Directed Broadcast）

如果一個設備需要訪問某個給定子網（遠程的，不是直接相連的）的所有主機，可能需要把包
的目的地址設為連接子網的廣播地址。這樣的操作對于使用31位前綴的點對點連接是不可能
的。

正如第六節所討論的，直接廣播功能的損失可能事實上是一種有益的副效應，因為它稍微加強
了網絡對某些類型的DoS攻擊的抵抗力[RFC2644, SMURF]。

2.3. 對當前路由協議的影響（Impact on Current Routing 
Protocols）

31位前綴的網絡對當前的路由協議沒有影響。當前配置的大多數路由協議都支持無級尋路
（classless routing）。況且對等通信是通過多點傳送地址、有限廣播地址或者單點傳送地址
實現的（都在局域網上），無論哪一種方式都不會受到使用31位字網掩碼的影響。

3. 建議（Recommendations）
      第二節提出的建議對發布的其他文獻有影響。本節詳細說明對其他文檔的改變。

3.1.“對Internet主機的要求——通信層（Communication 
Layers）” [RFC1122]

   節3.2.1.3 (e)改為：

      (e)  { <網絡號>, <子網號>, -1 }
對指定子網的直接廣播。不可用作源地址，除非源端是使用31位掩碼的點對點連接
的一個端點。
   增加一個新的小節（編號3.2.1.3 (h)）：

      (h)  { <網絡號>, <子網號>, 0 }
         子網號。不得用作源地址，除非源端是使用31位掩碼的點對點連接的一個端點。對
于其它類型的連接，帶有此種目的地址的包應簡單的拋棄。如果沒有簡單的拋棄，必
須視做IP廣播[RFC1812]。

3.2. “分配號（Assigned Numbers）” [RFC1700]

   “簡介”中“特殊地址”一節的(e)小節應該為：

      (e)   {<網絡號>, <子網號>, -1}
對特定子網的直接廣播。僅能用于目的地址，不過如果源端是使用31位掩碼的點對