rfc3021.txt

RFC 的详细文档！


RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000


         to-point link with a 31-bit mask.  A router MAY originate
         Network Directed Broadcast packets.  A router MAY have a
         configuration option to allow it to receive directed broadcast
         packets, however this option MUST be disabled by default, and
         thus the router MUST NOT receive Network Directed Broadcast
         packets unless specifically configured by the end user.

   The text above includes the update made by [RFC2644].

   A new section (numbered 4.2.2.11 (f)) is added:

      (f)  { <Network-number>, <Subnet-number>, 0 }

         Subnetwork number.  SHOULD NOT be used as a source address,
         except when the originator is one of the endpoints of a point-
         to-point link with a 31-bit mask.  For other types of links, a
         packet with such a destination SHOULD be silently discarded.
         If these packets are not silently discarded, they MUST be
         treated as IP broadcasts.

   Sections 4.2.3.1 (1), (2) and (4) are replaced with:

      (1) MUST treat as IP broadcasts packets addressed to
      255.255.255.255 or { <Network-prefix>, -1 }.

      In a point-to-point link with a 31-bit mask, a packet addressed to
      { <Network-prefix>, -1 } corresponds to one of the endpoints of
      such link, it MUST be treated as directed to the router on which
      the address is applied.

      (2) SHOULD silently discard on receipt (i.e., do not even deliver
      to applications in the router) any packet addressed to 0.0.0.0 or
      { <Network-prefix>, 0 }.  If these packets are not silently
      discarded, they MUST be treated as IP broadcasts (see Section
      [5.3.5]).  There MAY be a configuration option to allow receipt of
      these packets.  This option SHOULD default to discarding them.

      In a point-to-point link with a 31-bit mask, a packet addressed to
      { <Network-prefix>, 0 } corresponds to one of the endpoints of
      such link, it MUST be treated as directed to the router on which
      the address is applied.

      (4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or {
      <Network-prefix>, 0 }.  There MAY be a configuration option to
      allow generation of these packets (instead of using the relevant
      1s format broadcast).  This option SHOULD default to not
      generating them.




Retana, et al.              Standards Track                     [Page 6]

RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000


      In a point-to-point link with a 31-bit mask, the configuration of
      such a mask SHOULD allow for the generation of datagrams addressed
      to { <Network-prefix>, 0 }.

   The following text is added to section 4.3.3.9:

      The 255.255.255.255 IP broadcast address MUST be used for
      broadcast Address Mask Replies in point-to-point links with 31-bit
      subnet masks

4. Operational Experience

   The recommendations presented in this document have been implemented
   by several router vendors in beta code.  The implementation has been
   tested by at least three ISPs with positive results (i.e., no
   problems have been found).  Among the routing protocols tested
   successfully are OSPF, IS-IS, BGP and EIGRP.

   It is expected that the implementation will be officially released
   within the next few months and that other vendors will adopt it.

5. Deployment Considerations

   The intent of this document is to discuss the applicability and
   operation of 31-bit prefixes on point-to-point links.  The effects
   (if any) on other types of interfaces are not considered.  Note that
   a point-to-point link in which only one end supports the use of 31-
   bit prefixes may not operate correctly.

6. Security Considerations

   In the light of various denial of service (DoS) attacks on various
   networks within the Internet, security has become a major concern.
   The use of 31-bit subnet masks within the core of the Internet will
   reduce the number of physical links against which a DoS attack
   relying on packet replication through the use of directed broadcasts
   can be launched [RFC2644, SMURF].

   Overall, implementation of this document recommendation will improve
   the Internet's resilience to these types of DoS attacks.

7. Acknowledgements

   The authors of this document do not make any claims on the
   originality of the ideas described.  Among other people, we would
   like to acknowledge Alex Zinin for his comments, and the many people
   who have tested 31 bit subnet masks in their labs and networks.




Retana, et al.              Standards Track                     [Page 7]

RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000


8. References

   [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













Retana, et al.              Standards Track                     [Page 8]

RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000


9. Authors' Addresses

   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]



















Retana, et al.              Standards Track                     [Page 9]

RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000


Full Copyright Statement

   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.

Acknowledgement

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



















Retana, et al.              Standards Track                    [Page 10]