组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：王安鹏（anpengwang&nbsp;&nbsp;&nbsp;&nbsp;anpengwang@263.net）<br />
译文发布时间：2001-4-24<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必<br />
须保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.&nbsp;Retana<br />
Request&nbsp;for&nbsp;Comments:&nbsp;3021&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;White<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V.&nbsp;Fuller<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;GTE&nbsp;Internetworking<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D.&nbsp;McPherson<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Amber&nbsp;Networks<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;December&nbsp;2000<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
在Ipv4点对点连接中使用31位前缀<br />
(RFC3021&nbsp;&nbsp;Using&nbsp;31-Bit&nbsp;Prefixes&nbsp;on&nbsp;IPv4&nbsp;Point-to-Point&nbsp;Links)<br />
<br />
本备忘录的状态<br />
<br />
本文档描述了用于一种Internet社区的Internet标准跟踪协议，需要进一步探讨和建议<br />
进行完善。请查询“Internet正式协议标准”（STD1）的当前版本了解本协议的标准化进程和<br />
状态。本备忘录的发布没有限制。<br />
<br />
版权公告<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
摘要<br />
<br />
随着节约Internet&nbsp;IP地址空间的压力的不断增加，实际运用相对较小的改进提高编号效率的<br />
看法越来越有意义。本文档提出的改进建议是把分配给点对点连接（普遍存在于Internet底层<br />
结构中）的地址空间平分成两部分，从而可以在非常有限的范围内使用31位字网掩码。<br />
<br />
目录<br />
1．简介与动机	2<br />
2.对31位前缀的深入思考	2<br />
2.1.地址（Addressing）	3<br />
2.2.&nbsp;广播和网络地址	3<br />
2.3.&nbsp;对当前路由协议的影响（Impact&nbsp;on&nbsp;Current&nbsp;Routing&nbsp;Protocols）	4<br />
3.&nbsp;建议（Recommendations）	4<br />
3.1."对Internet主机的要求——通信层（Communication&nbsp;Layers）"&nbsp;[RFC1122]	4<br />
3.2.&nbsp;"分配号（Assigned&nbsp;Numbers）"&nbsp;[RFC1700]	4<br />
3.3.&nbsp;"对IPv4路由器的要求"&nbsp;[RFC1812]	5<br />
4.&nbsp;操作试验（Operational&nbsp;Experience）	5<br />
5.&nbsp;应用考虑	6<br />
6.&nbsp;安全考虑	6<br />
7.&nbsp;鸣谢	6<br />
8.&nbsp;引用	6<br />
9.&nbsp;作者地址	7<br />
版权声明	8<br />
<br />
1．简介与动机<br />
&nbsp;&nbsp;&nbsp;&nbsp;认识到Internet地址短缺的问题，已经出现了几种对地址空间使用的改进和解决之一问题<br />
的不同办法：<br />
<br />
&nbsp;&nbsp;&nbsp;-由IANA和地方的权威地址分配机构强制执行更加严格的地址空间分配政策[RFC2050]。<br />
<br />
&nbsp;&nbsp;&nbsp;-&nbsp;[RFC1631].使用网络地址转移器（NATs），许多用户联合起来共用少量的符合IANA的地<br />
址，NAT内部没有全球性的拓扑发送地址[RFC1631]。<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;-发布新的Internet协议，增加地址空间。IPv6就是此类协议中的一个，已经通过IEIF程<br />
序，但是还没有出现相应的产品。及时发布了这样的产品，也还要面临着多年的转变过程。<br />
<br />
在可以使用更大的地址空间之前，有机会更加有效地利用现有的地址空间似乎是谨慎的看<br />
法。<br />
<br />
此类改进的一个（很小的）的机会是点对点连接编号已达到极限。一种选择是——目前在<br />
Internet的某些部分正是用着——简单地把路由器之间的连接不作为点对点编号。尽管初看起<br />
来这种方法很方便地解决了问题，但是本身也带来了几个问题，包括不能一致地处理未编号的<br />
连接或者经过这样的连接访问路由器、管理和调试这些连接的困难性，以及标准的缺乏<br />
[RFC1812]。<br />
<br />
当前的实际应用中，Internet子网编号（大多数情况下）使用不超过30位的子网掩码，<br />
每个连接需要4个地址——两个主机地址，一个全0的网络地址和一个全1的广播地址。不幸<br />
的是点对点连接只能有两个不同的端点，而且也不支持广播——一端发出的任何包只能由连接<br />
的另一端接收。<br />
<br />
第三种选择是使用点对点连接的两端地址。这种方法可以节约与使用31位子网掩码同样的<br />
地址空间，但是只能用于使用PPP包装的连接[RFC1332]。使用主机地址允许为连接的两端分配<br />
属于不同网络的IP地址，这样会造成连接和网络管理是间接的。<br />
<br />
本文基于这样一种观点，即在点对点连接中节约IP地址（使用超过30位的子网掩码），<br />
而同时保持可维护性和标准的交互是可能的。现存的文档[RFC950]已经暗示了使用1位宽的主<br />
机号码域的可能性。<br />
<br />
这种改进带来的地址空间的节约是显而易见的——大型网络中的每个点对点连接都是用2<br />
个地址而不是4个。比方说，在一个包含500个点对点连接的网络中，这种方法可以节约1000<br />
个地址（与C类地址空间相同）<br />
2.对31位前缀的深入思考<br />
本节讨论在点对点连接中使用31位前缀对Internet路由和操作可能带来的影响。这里的<br />
斟酌还会在第三节反映处来。<br />
<br />
&nbsp;&nbsp;&nbsp;For&nbsp;the&nbsp;length&nbsp;of&nbsp;this&nbsp;document,&nbsp;an&nbsp;IP&nbsp;address&nbsp;will&nbsp;be&nbsp;interpreted<br />
&nbsp;&nbsp;&nbsp;as:按照本文描述的长度，IP地址可以被认为是：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;网络号&gt;&lt;主机号&gt;<br />
<br />
&nbsp;&nbsp;&nbsp;其中&lt;主机号&gt;是地址的非掩码部分，应至少有1位宽。&nbsp;符号“-1”用来表示这个域的所有<br />
位均为1。根据这个讨论，路由系统可以被认为支持类型无关的路由CIDR&nbsp;[RFC1519]。<br />
<br />
2.1.地址（Addressing）<br />
&nbsp;&nbsp;&nbsp;&nbsp;如果为点对点连接分配了31位字网掩码，就只剩下一位留给&lt;主机号&gt;，因此只能有两个地<br />
址：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{&lt;网络号&gt;,&nbsp;0}&nbsp;和&nbsp;{&lt;网络号&gt;,&nbsp;-1}<br />
&nbsp;&nbsp;&nbsp;&nbsp;这些地址在原来已经被用于网络和广播地址（见节2.2）。在应用31位字网掩码的点对点<br />
连接中，这两个地址必须被解释为主机地址。<br />
2.2.&nbsp;广播和网络地址<br />
在IP地址段中原来有几个公认的广播地址：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(a)&nbsp;直接广播<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{&lt;网络号&gt;,&nbsp;-1}<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{&lt;网络号&gt;,&nbsp;0}<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;网络地址{&lt;网络号&gt;,&nbsp;0}是直接广播的过时形式&nbsp;，但可能还用于老式主机。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(b)本地（或有限的）广播<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{-1,&nbsp;-1}<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{0,&nbsp;0}<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;有限广播的{0，0}形式已经过时了，但还可以在网络上见到。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;使用31位长度的前缀只留下两种编号的可能性（见节2.1），从而排除了连接中直接广播<br />
的使用（见节2.2.1）。分配了31位字网掩码的点对点连接必须使用有限广播进行所有的广播<br />
通信。<br />
<br />
&nbsp;&nbsp;&nbsp;&lt;网络号&gt;由网络管理员分配，在本地路由域中是唯一的&nbsp;。目标IP地址是否进行直接广播取<br />
决于与目标段直接相连的路由器。当前的转发方案和算法不会在远程路由器受到影响。<br />
<br />
&nbsp;&nbsp;&nbsp;本文的目的在于探讨点对点连接31位前缀的实用性和操作。没有考虑对其它类型接口的影<br />
响（如果有的话）。<br />
<br />
2.2.1.直接广播（Directed&nbsp;Broadcast）<br />
<br />
如果一个设备需要访问某个给定子网（远程的，不是直接相连的）的所有主机，可能需要把包<br />
的目的地址设为连接子网的广播地址。这样的操作对于使用31位前缀的点对点连接是不可能<br />
的。<br />
<br />
正如第六节所讨论的，直接广播功能的损失可能事实上是一种有益的副效应，因为它稍微加强<br />
了网络对某些类型的DoS攻击的抵抗力[RFC2644,&nbsp;SMURF]。<br />
<br />
2.3.&nbsp;对当前路由协议的影响（Impact&nbsp;on&nbsp;Current&nbsp;Routing&nbsp;<br />
Protocols）<br />
<br />
31位前缀的网络对当前的路由协议没有影响。当前配置的大多数路由协议都支持无级寻路<br />
（classless&nbsp;routing）。况且对等通信是通过多点传送地址、有限广播地址或者单点传送地址<br />
实现的（都在局域网上），无论哪一种方式都不会受到使用31位字网掩码的影响。<br />
<br />
3.&nbsp;建议（Recommendations）<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;第二节提出的建议对发布的其他文献有影响。本节详细说明对其他文档的改变。<br />
<br />
3.1.“对Internet主机的要求——通信层（Communication&nbsp;<br />
Layers）”&nbsp;[RFC1122]<br />
<br />
&nbsp;&nbsp;&nbsp;节3.2.1.3&nbsp;(e)改为：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(e)&nbsp;&nbsp;{&nbsp;&lt;网络号&gt;,&nbsp;&lt;子网号&gt;,&nbsp;-1&nbsp;}<br />
对指定子网的直接广播。不可用作源地址，除非源端是使用31位掩码的点对点连接<br />
的一个端点。<br />
&nbsp;&nbsp;&nbsp;增加一个新的小节（编号3.2.1.3&nbsp;(h)）：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(h)&nbsp;&nbsp;{&nbsp;&lt;网络号&gt;,&nbsp;&lt;子网号&gt;,&nbsp;0&nbsp;}<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;子网号。不得用作源地址，除非源端是使用31位掩码的点对点连接的一个端点。对<br />
于其它类型的连接，带有此种目的地址的包应简单的抛弃。如果没有简单的抛弃，必<br />
须视做IP广播[RFC1812]。<br />
<br />
3.2.&nbsp;“分配号（Assigned&nbsp;Numbers）”&nbsp;[RFC1700]<br />
<br />
&nbsp;&nbsp;&nbsp;“简介”中“特殊地址”一节的(e)小节应该为：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(e)&nbsp;&nbsp;&nbsp;{&lt;网络号&gt;,&nbsp;&lt;子网号&gt;,&nbsp;-1}<br />
对特定子网的直接广播。仅能用于目的地址，不过如果源端是使用31位掩码的点对<br />
点连接的一个端点，也可以用做源地址。<br />
<br />
3.3.&nbsp;“对IPv4路由器的要求”&nbsp;[RFC1812]<br />
<br />
&nbsp;&nbsp;&nbsp;节4.2.2.11&nbsp;(d)改为：<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(d)&nbsp;{&nbsp;&lt;网络前缀&gt;,&nbsp;-1&nbsp;}<br />
直接广播——直接对指定网络前缀的广播。不得用作源地址，除非源端是使用31<br />
位掩码的点对点连接的一个端点。路由器可以发生网络直接广播（Network&nbsp;<br />
Directed&nbsp;Broadcast）包。路由器可以由一个接收直接广播包的配置选项，但必<br />
须关闭缺省值，这样除非最终用户专门设置路由器不得接收网络直接广播包。<br />
<br />
&nbsp;&nbsp;&nbsp;上述文字包含[RFC2644]所作的更新。<br />
&nbsp;&nbsp;&nbsp;增加一个新的小节（编号4.2.2.11&nbsp;(f)）：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(f)&nbsp;&nbsp;{&nbsp;&lt;网络号&gt;,&nbsp;&lt;子网号&gt;,&nbsp;0&nbsp;}<br />
子网号。不得用作源地址，除非源端是使用31位掩码的点对点连接的一个端<br />
点。对于其它类型的连接，带有此种目的地址的包应简单的抛弃。如果没有简单<br />
的抛弃，必须视做IP广播[RFC1812]。<br />
<br />
&nbsp;&nbsp;&nbsp;节4.2.3.1&nbsp;(1),&nbsp;(2)和(4)&nbsp;改为：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(1)必须视做地址为255.255.255.255或{&nbsp;&lt;网络前缀&gt;,&nbsp;-1&nbsp;}的IP广播包。&nbsp;<br />
在31位掩码的点对点连接中，对应其中一个端点的包地址{&nbsp;&lt;网络前缀&gt;,&nbsp;0&nbsp;}必<br />
须视做直接针对地址使用的路由器。<br />
<br />
(2)一旦接收到地址为0.0.0.0或者{&lt;网络前缀&gt;，0}的包应直接抛弃（甚至无需传递给路<br />
由器程序）。如果没有直接抛弃，这些包必须视做IP广播（参见节[5.3.5]）。可以由<br />
一个接收此类包的配置选项，这个选项的缺省设置必须是抛弃此类包。<br />
在31位掩码的点对点连接中，对应其中一个端点的包地址{&nbsp;&lt;网络前缀&gt;,&nbsp;0&nbsp;}必<br />
须视做直接针对地址使用的路由器。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(4)不得发生地址为0.0.0.0&nbsp;or&nbsp;{&lt;网络前缀&gt;,&nbsp;0&nbsp;}的数据包。&nbsp;可以由一个允许生成此<br />
类包的选项（而不是使用相应的全为1的广播）。该选项的缺省设置应该避免生成此<br />
类包。<br />
在31位掩码的点对点连接中，这种掩码的配置应允许生成地址为{&nbsp;&lt;网络前缀&gt;,&nbsp;<br />
0&nbsp;}的数据包。<br />
<br />
&nbsp;&nbsp;&nbsp;节4.3.3.9增加下述文字：<br />
<br />
在31位子网掩码的点对点连接中，255.255.255.255&nbsp;IP广播地址必须用作广播地址<br />
掩码回复。<br />
<br />
4.&nbsp;操作试验（Operational&nbsp;Experience）<br />
<br />
本文提出的建议已经在几个路由器提供商的beta版代码中使用。这些应用得到了至少3家<br />
ISP的测试，取得了肯定的结果（或者说没有发现问题）成功测试的路由协议包括OSPF,&nbsp;IS-IS,&nbsp;<br />
BGP和EIGRP。<br />
<br />
这些实现有望在今后几个月内正式发布，其他供应商可以使用。<br />
<br />
5.&nbsp;应用考虑<br />
本文的目的在于探讨点对点连接使用31位前缀的实用性和操作。没有考虑对其它类型接口<br />
的影响（如果有的话）。注意如果点对点连接中只有一端支持31位前缀，操作可能不会正确执<br />
行。<br />
<br />
6.&nbsp;安全考虑<br />
根据Internet上不同网络的各异的拒绝服务攻击（Denial&nbsp;of&nbsp;Service，DoS），安全性<br />
成为一个重要的问题。在Internet的核心使用31位子网掩码可以减少物理连接的数量，而依<br />
赖于使用直接广播进行包复制的DoS攻击通过物理连接发起攻击[RFC2644,&nbsp;SMURF]。<br />
<br />
总而言之，应用本文所提的建议可以提高Internet对这些类型的DoS攻击的防御力。<br />
<br />
7.&nbsp;鸣谢<br />
<br />
本文作者不就所述观点的窗已做任何声明。特别感谢Alex&nbsp;Zinin提出的建议，还有许多人在他<br />
们的实验室和网络上对31位子网掩码作了测试。<br />
<br />
8.&nbsp;引用<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC950]&nbsp;&nbsp;Mogul,&nbsp;J.&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Internet&nbsp;Standard&nbsp;Subnetting<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Procedure",&nbsp;STD&nbsp;5,&nbsp;RFC&nbsp;950,&nbsp;August&nbsp;1985.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1122]&nbsp;Braden,&nbsp;R.,&nbsp;"Requirements&nbsp;for&nbsp;Internet&nbsp;Hosts&nbsp;--<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Communication&nbsp;Layers",&nbsp;STD&nbsp;3,&nbsp;RFC&nbsp;1122,&nbsp;October&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1332]&nbsp;McGregor,&nbsp;G.,&nbsp;"The&nbsp;PPP&nbsp;Internet&nbsp;Protocol&nbsp;Control&nbsp;Protocol<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IPCP)",&nbsp;RFC&nbsp;1332,&nbsp;May&nbsp;1992.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1519]&nbsp;Fuller,&nbsp;V.,&nbsp;Li,&nbsp;T.,&nbsp;Yu,&nbsp;J.&nbsp;and&nbsp;K.&nbsp;Varadhan,&nbsp;"Classless<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Inter-Domain&nbsp;Routing&nbsp;(CIDR):&nbsp;an&nbsp;Address&nbsp;Assignment&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Aggregation&nbsp;Strategy",&nbsp;RFC&nbsp;1519,&nbsp;September&nbsp;1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1631]&nbsp;Egevang,&nbsp;K.&nbsp;and&nbsp;P.&nbsp;Francis,&nbsp;"The&nbsp;IP&nbsp;Network&nbsp;Address<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Translator&nbsp;(NAT)",&nbsp;RFC&nbsp;1631,&nbsp;May&nbsp;1994.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1700]&nbsp;Reynolds,&nbsp;J.&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Assigned&nbsp;Numbers",&nbsp;STD&nbsp;2,&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1700,&nbsp;October&nbsp;1994.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC1812]&nbsp;Baker,&nbsp;F.,&nbsp;"Requirements&nbsp;for&nbsp;IP&nbsp;Version&nbsp;4&nbsp;Routers",&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1812,&nbsp;June&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC2050]&nbsp;Hubbard,&nbsp;K.,&nbsp;Kosters,&nbsp;M.,&nbsp;Conrad,&nbsp;D.,&nbsp;Karrenberg,&nbsp;D.&nbsp;and&nbsp;J.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Postel,&nbsp;"Internet&nbsp;Registry&nbsp;IP&nbsp;Allocation&nbsp;Guidelines",&nbsp;BCP<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;12,&nbsp;RFC&nbsp;2050,&nbsp;November&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC2460]&nbsp;Deering,&nbsp;S.&nbsp;and&nbsp;R.&nbsp;Hinden,&nbsp;"Internet&nbsp;Protocol,&nbsp;Version&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IPv6)&nbsp;Specification",&nbsp;RFC&nbsp;2460,&nbsp;December&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC2644]&nbsp;Senie,&nbsp;D.,&nbsp;"Changing&nbsp;the&nbsp;Default&nbsp;for&nbsp;Directed&nbsp;Broadcasts&nbsp;in<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Routers",&nbsp;BCP&nbsp;34,&nbsp;RFC&nbsp;2644,&nbsp;August&nbsp;1999.<br />
<br />
&nbsp;&nbsp;&nbsp;[SMURF]&nbsp;&nbsp;&nbsp;Huegen,&nbsp;C.,&nbsp;"The&nbsp;Latest&nbsp;in&nbsp;Denial&nbsp;of&nbsp;Service&nbsp;Attacks:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'Smurfing':&nbsp;&nbsp;Description&nbsp;and&nbsp;Information&nbsp;to&nbsp;Minimize<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Effects",&nbsp;URL:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://users.quadrunner.com/chuegen/smurf.cgi<br />
9.&nbsp;作者地址<br />
<br />
&nbsp;&nbsp;&nbsp;Alvaro&nbsp;Retana<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;7025&nbsp;Kit&nbsp;Creek&nbsp;Rd.<br />
&nbsp;&nbsp;&nbsp;Research&nbsp;Triangle&nbsp;Park,&nbsp;NC&nbsp;27709<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;aretana@cisco.com<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Russ&nbsp;White<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;7025&nbsp;Kit&nbsp;Creek&nbsp;Rd.<br />
&nbsp;&nbsp;&nbsp;Research&nbsp;Triangle&nbsp;Park,&nbsp;NC&nbsp;27709<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;riw@cisco.com<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Vince&nbsp;Fuller<br />
&nbsp;&nbsp;&nbsp;GTE&nbsp;Internetworking<br />
&nbsp;&nbsp;&nbsp;3801&nbsp;E.&nbsp;Bayshore&nbsp;Rd.<br />
&nbsp;&nbsp;&nbsp;Palo&nbsp;Alto,&nbsp;CA,&nbsp;94303<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;vaf@valinor.barrnet.net<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;Danny&nbsp;McPherson<br />
&nbsp;&nbsp;&nbsp;Amber&nbsp;Networks<br />
&nbsp;&nbsp;&nbsp;2465&nbsp;Augustine&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Santa&nbsp;Clara,&nbsp;CA&nbsp;&nbsp;95054<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;danny@ambernetworks.com<br />
<br />
版权声明<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;translations&nbsp;of&nbsp;it&nbsp;may&nbsp;be&nbsp;copied&nbsp;and&nbsp;furnished&nbsp;to<br />
&nbsp;&nbsp;&nbsp;others,&nbsp;and&nbsp;derivative&nbsp;works&nbsp;that&nbsp;comment&nbsp;on&nbsp;or&nbsp;otherwise&nbsp;explain&nbsp;it<br />
&nbsp;&nbsp;&nbsp;or&nbsp;assist&nbsp;in&nbsp;its&nbsp;implementation&nbsp;may&nbsp;be&nbsp;prepared,&nbsp;copied,&nbsp;published<br />
&nbsp;&nbsp;&nbsp;and&nbsp;distributed,&nbsp;in&nbsp;whole&nbsp;or&nbsp;in&nbsp;part,&nbsp;without&nbsp;restriction&nbsp;of&nbsp;any<br />
&nbsp;&nbsp;&nbsp;kind,&nbsp;provided&nbsp;that&nbsp;the&nbsp;above&nbsp;copyright&nbsp;notice&nbsp;and&nbsp;this&nbsp;paragraph&nbsp;are<br />
&nbsp;&nbsp;&nbsp;included&nbsp;on&nbsp;all&nbsp;such&nbsp;copies&nbsp;and&nbsp;derivative&nbsp;works.&nbsp;&nbsp;However,&nbsp;this<br />
&nbsp;&nbsp;&nbsp;document&nbsp;itself&nbsp;may&nbsp;not&nbsp;be&nbsp;modified&nbsp;in&nbsp;any&nbsp;way,&nbsp;such&nbsp;as&nbsp;by&nbsp;removing<br />
&nbsp;&nbsp;&nbsp;the&nbsp;copyright&nbsp;notice&nbsp;or&nbsp;references&nbsp;to&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;other<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;organizations,&nbsp;except&nbsp;as&nbsp;needed&nbsp;for&nbsp;the&nbsp;purpose&nbsp;of<br />
&nbsp;&nbsp;&nbsp;developing&nbsp;Internet&nbsp;standards&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;procedures&nbsp;for<br />
&nbsp;&nbsp;&nbsp;copyrights&nbsp;defined&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Standards&nbsp;process&nbsp;must&nbsp;be<br />
&nbsp;&nbsp;&nbsp;followed,&nbsp;or&nbsp;as&nbsp;required&nbsp;to&nbsp;translate&nbsp;it&nbsp;into&nbsp;languages&nbsp;other&nbsp;than<br />
&nbsp;&nbsp;&nbsp;English.<br />
<br />
&nbsp;&nbsp;&nbsp;The&nbsp;limited&nbsp;permissions&nbsp;granted&nbsp;above&nbsp;are&nbsp;perpetual&nbsp;and&nbsp;will&nbsp;not&nbsp;be<br />
&nbsp;&nbsp;&nbsp;revoked&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;its&nbsp;successors&nbsp;or&nbsp;assigns.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;the&nbsp;information&nbsp;contained&nbsp;herein&nbsp;is&nbsp;provided&nbsp;on&nbsp;an<br />
&nbsp;&nbsp;&nbsp;"AS&nbsp;IS"&nbsp;basis&nbsp;and&nbsp;THE&nbsp;INTERNET&nbsp;SOCIETY&nbsp;AND&nbsp;THE&nbsp;INTERNET&nbsp;ENGINEERING<br />
&nbsp;&nbsp;&nbsp;TASK&nbsp;FORCE&nbsp;DISCLAIMS&nbsp;ALL&nbsp;WARRANTIES,&nbsp;EXPRESS&nbsp;OR&nbsp;IMPLIED,&nbsp;INCLUDING<br />
&nbsp;&nbsp;&nbsp;BUT&nbsp;NOT&nbsp;LIMITED&nbsp;TO&nbsp;ANY&nbsp;WARRANTY&nbsp;THAT&nbsp;THE&nbsp;USE&nbsp;OF&nbsp;THE&nbsp;INFORMATION<br />
&nbsp;&nbsp;&nbsp;HEREIN&nbsp;WILL&nbsp;NOT&nbsp;INFRINGE&nbsp;ANY&nbsp;RIGHTS&nbsp;OR&nbsp;ANY&nbsp;IMPLIED&nbsp;WARRANTIES&nbsp;OF<br />
&nbsp;&nbsp;&nbsp;MERCHANTABILITY&nbsp;OR&nbsp;FITNESS&nbsp;FOR&nbsp;A&nbsp;PARTICULAR&nbsp;PURPOSE.<br />
<br />
致谢<br />
<br />
&nbsp;&nbsp;&nbsp;Funding&nbsp;for&nbsp;the&nbsp;RFC&nbsp;Editor&nbsp;function&nbsp;is&nbsp;currently&nbsp;provided&nbsp;by&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;Society.<br />
<br />
RFC&nbsp;3021&nbsp;&nbsp;&nbsp;在Ipv4点对点连接中使用31位前缀		Using&nbsp;31-Bit&nbsp;Prefixes&nbsp;on&nbsp;IPv4&nbsp;Point-to-Point&nbsp;Links<br />
<br />
<br />
2<br />
RFC&nbsp;文档翻译计划<br />