rfc3021.txt

很多RFC的中文文档

点连接的一个端点，也可以用做源地址。

3.3. “对IPv4路由器的要求” [RFC1812]

   节4.2.2.11 (d)改为：

      (d) { <网络前缀>, -1 }
直接广播——直接对指定网络前缀的广播。不得用作源地址，除非源端是使用31
位掩码的点对点连接的一个端点。路由器可以发生网络直接广播（Network 
Directed Broadcast）包。路由器可以由一个接收直接广播包的配置选项，但必
须关闭缺省值，这样除非最终用户专门设置路由器不得接收网络直接广播包。

   上述文字包含[RFC2644]所作的更新。
   增加一个新的小节（编号4.2.2.11 (f)）：
      (f)  { <网络号>, <子网号>, 0 }
子网号。不得用作源地址，除非源端是使用31位掩码的点对点连接的一个端
点。对于其它类型的连接，带有此种目的地址的包应简单的抛弃。如果没有简单
的抛弃，必须视做IP广播[RFC1812]。

   节4.2.3.1 (1), (2)和(4) 改为：
      (1)必须视做地址为255.255.255.255或{ <网络前缀>, -1 }的IP广播包。 
在31位掩码的点对点连接中，对应其中一个端点的包地址{ <网络前缀>, 0 }必
须视做直接针对地址使用的路由器。

(2)一旦接收到地址为0.0.0.0或者{<网络前缀>，0}的包应直接抛弃（甚至无需传递给路
由器程序）。如果没有直接抛弃，这些包必须视做IP广播（参见节[5.3.5]）。可以由
一个接收此类包的配置选项，这个选项的缺省设置必须是抛弃此类包。
在31位掩码的点对点连接中，对应其中一个端点的包地址{ <网络前缀>, 0 }必
须视做直接针对地址使用的路由器。

      (4)不得发生地址为0.0.0.0 or {<网络前缀>, 0 }的数据包。 可以由一个允许生成此
类包的选项（而不是使用相应的全为1的广播）。该选项的缺省设置应该避免生成此
类包。
在31位掩码的点对点连接中，这种掩码的配置应允许生成地址为{ <网络前缀>, 
0 }的数据包。

   节4.3.3.9增加下述文字：

在31位子网掩码的点对点连接中，255.255.255.255 IP广播地址必须用作广播地址
掩码回复。

4. 操作试验（Operational Experience）

本文提出的建议已经在几个路由器提供商的beta版代码中使用。这些应用得到了至少3家
ISP的测试，取得了肯定的结果（或者说没有发现问题）成功测试的路由协议包括OSPF, IS-IS, 
BGP和EIGRP。

这些实现有望在今后几个月内正式发布，其他供应商可以使用。

5. 应用考虑
本文的目的在于探讨点对点连接使用31位前缀的实用性和操作。没有考虑对其它类型接口
的影响（如果有的话）。注意如果点对点连接中只有一端支持31位前缀，操作可能不会正确执
行。

6. 安全考虑
根据Internet上不同网络的各异的拒绝服务攻击（Denial of Service，DoS），安全性
成为一个重要的问题。在Internet的核心使用31位子网掩码可以减少物理连接的数量，而依
赖于使用直接广播进行包复制的DoS攻击通过物理连接发起攻击[RFC2644, SMURF]。

总而言之，应用本文所提的建议可以提高Internet对这些类型的DoS攻击的防御力。

7. 鸣谢

本文作者不就所述观点的窗已做任何声明。特别感谢Alex Zinin提出的建议，还有许多人在他
们的实验室和网络上对31位子网掩码作了测试。

8. 引用

   [RFC950]  Mogul, J. and J. Postel, "Internet Standard Subnetting
             Procedure", STD 5, RFC 950, August 1985.

   [RFC1122] Braden, R., "Requirements for Internet Hosts --
             Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
             (IPCP)", RFC 1332, May 1992.

   [RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
             Inter-Domain Routing (CIDR): an Address Assignment and
             Aggregation Strategy", RFC 1519, September 1993.

   [RFC1631] Egevang, K. and P. Francis, "The IP Network Address
             Translator (NAT)", RFC 1631, May 1994.

   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.

   [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
             1812, June 1995.

   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
             Postel, "Internet Registry IP Allocation Guidelines", BCP
             12, RFC 2050, November 1996.

   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in
             Routers", BCP 34, RFC 2644, August 1999.

   [SMURF]   Huegen, C., "The Latest in Denial of Service Attacks:
             'Smurfing':  Description and Information to Minimize
             Effects", URL:
             http://users.quadrunner.com/chuegen/smurf.cgi
9. 作者地址

   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709

   EMail: [e-mail]


   Russ White
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709

   EMail: [e-mail]


   Vince Fuller
   GTE Internetworking
   3801 E. Bayshore Rd.
   Palo Alto, CA, 94303

   EMail: [e-mail]


   Danny McPherson
   Amber Networks
   2465 Augustine Drive
   Santa Clara, CA  95054

   EMail: [e-mail]

版权声明

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

致谢

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC 3021   在Ipv4点对点连接中使用31位前缀		Using 31-Bit Prefixes on IPv4 Point-to-Point Links


2
RFC 文档翻译计划