    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

               Using 31-Bit Prefixes on IPv4 Point-to-Point Links

    Status of this Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

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

    Abstract

       With ever-increasing pressure to conserve IP address space on the
       Internet, it makes sense to consider where relatively minor changes
       can be made to fielded practice to improve numbering efficiency.  One
       such change, proposed by this document, is to halve the amount of
       address space assigned to point-to-point links (common throughout the
       Internet infrastructure) by allowing the use of 31-bit subnet masks
       in a very limited way.

    1. Introduction and Motivation

       The perceived problem of a lack of Internet addresses has driven a
       number of changes in address space usage and a number of different
       approaches to solving the problem:

       - More stringent address space allocation guidelines, enforced by the
         IANA and the regional address assignment authorities [RFC2050].

       - Use of Network Address Translators (NATs), where a small number of
         IANA-compliant addresses are shared by a larger pool of private,
         non-globally routed addresses topologically behind a NAT box
         [RFC1631].

    Retana, et al.              Standards Track                     [Page 1]

    RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000

       - Deployment of a new Internet Protocol to increase the size of the
         address space.  One such protocol, IPv6 [RFC2460], has been through
         the IETF process but has yet to see production deployment.  Should
         it be, deployed, it will still face a many year transition period.

       Prior to the availability of a larger address space, it seems prudent
       to consider opportunities for making more efficient use of the
       existing address space.

       One such (small) opportunity is to change the way that point-to-point
       links are numbered.  One option, which is used today on some parts of
       the Internet, is to simply not number point-to-point links between
       routers.  While this practice may seem, at first, to handily resolve
       the problem, it causes a number of problems of its own, including the
       inability to consistently manage the unnumbered link or reach a
       router through it, difficulty in management and debugging of those
       links, and the lack of standardization [RFC1812].

       In current practice, numbered Internet subnets do not use longer than
       a 30-bit subnet mask (in most cases), which requires four addresses
       per link - two host addresses, one all-zeros network, and one all-
       ones broadcast.  This is unfortunate for point-to-point links, since
       they can only possibly have two identifying endpoints and don't
       support the notion of broadcast - any packet which is transmitted by
       one end of a link is always received by the other.

       A third option is to use host addresses on both ends of a point-to-
       point link.  This option provides the same address space savings as
       using a 31-bit subnet mask, but may only be used in links using PPP
       encapsulation [RFC1332].  The use of host addresses allows for the
       assignment of IP addresses belonging to different networks at each
       side of the link, causing link and network management not to be
       straight forward.

       This document is based on the idea that conserving IP addresses on
       point-to-point links (using longer than a 30-bit subnet mask) while
       maintaining manageability and standard interaction is possible.
       Existing documentation [RFC950] has already hinted at the possible
       use of a 1-bit wide host-number field.

       The savings in address space resulting from this change is easily
       seen--each point-to-point link in a large network would consume two
       addresses instead of four.  In a network with 500 point-to-point
       links, for example, this practice would amount to a savings of 1000
       addresses (the equivalent of four class C address spaces).

    Retana, et al.              Standards Track                     [Page 2]

    RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000

    2. Considerations of 31-Bit Prefixes

       This section discusses the possible effects, on Internet routing and
       operations, of using 31-bit prefixes on point-to-point links.  The
       considerations made here are also reflected in Section 3.

       For the length of this document, an IP address will be interpreted
       as:

            <Network-number><Host-number>

       where the <Host-number> represents the unmasked portion of the
       address and it SHOULD be at least 1 bit wide.  The "-1" notation is
       used to mean that the field has all 1 bits.  For purposes of this
       discussion, the routing system is considered capable of classless, or
       CIDR [RFC1519], routing.

    2.1. Addressing

       If a 31-bit subnet mask is assigned to a point-to-point link, it
       leaves the <Host-number> with only 1 bit.  Consequently, only two
       possible addresses may result:

            {<Network-number>, 0} and {<Network-number>, -1}

       These addresses have historically been associated with network and
       broadcast addresses (see Section 2.2).  In a point-to-point link with
       a 31-bit subnet mask, the two addresses above MUST be interpreted as
       host addresses.

    2.2. Broadcast and Network Addresses

       There are several historically recognized broadcast addresses
       [RFC1812] on IP segments:

          (a) the directed broadcast

               {<Network-number>, -1}

               {<Network-number>, 0}

             The network address itself {<Network-number>, 0} is an
             obsolete form of directed broadcast, but it may still be used
             by older hosts.

    Retana, et al.              Standards Track                     [Page 3]

    RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000

          (b) the link local (or limited) broadcast

               {-1, -1}

               {0, 0}

             The {0, 0} form of a limited broadcast is obsolete, but may
             still be present in a network.

       Using a 31-bit prefix length leaves only two numbering possibilities
       (see Section 2.1), eliminating the use of a directed broadcast to the
       link (see Section 2.2.1).  The limited broadcast MUST be used for all
       broadcast traffic on a point-to-point link with a 31-bit subnet mask
       assigned to it.

       The <Network-number> is assigned by the network administrator as
       unique to the local routing domain.  The decision as to whether a
       destination IP address should be a directed broadcast or not is made
       by the router directly connected to the destination segment.  Current
       forwarding schemes and algorithms are not affected in remote routers.

       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.

    2.2.1. Directed Broadcast

       When a device wants to reach all the hosts on a given (remote, rather
       than directly connected) subnet, it may set the packet's destination
       address to the link's subnet broadcast address.  This operation is
       not possible for point-to-point links with a 31-bit prefix.

       As discussed in Section 6, the loss of functionality of a directed
       broadcast may actually be seen as a beneficial side effect, as it
       slightly enhances the network's resistance to a certain class of DoS
       Attacks [RFC2644, SMURF].

    2.3. Impact on Current Routing Protocols

       Networks with 31-bit prefixes have no impact on current routing
       protocols.  Most of the currently deployed routing protocols have
       been designed to provide classless routing.  Furthermore, the
       communication between peers is done using multicast, limited
       broadcast or unicast addresses (all on the local network), none of
       which are affected with the use of 31-bit subnet masks.

    Retana, et al.              Standards Track                     [Page 4]

    RFC 3021             31-Bit Prefixes on IPv4 Links         December 2000

    3. Recommendations

       The considerations presented in Section 2 affect other published
       work.  This section details the updates made to other documents.

    3.1. "Requirements for Internet Hosts -- Communication Layers" [RFC1122]

       Section 3.2.1.3 (e) is replaced with:

          (e)  { <Network-number>, <Subnet-number>, -1 }

             Directed broadcast to the specified subnet.  It MUST 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.

       A new section (numbered 3.2.1.3 (h)) is added:

          (h)  { <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 [RFC1812].

    3.2. "Assigned Numbers" [RFC1700]

       Sub-section (e) of the "Special Addresses" section in the
       "Introduction" is replaced with:

          (e)   {<Network-number>, <Subnet-number>, -1}

             Directed broadcast to specified subnet.  Can only be used as a
             destination address.  However, in the case where the originator
             is one of the endpoints of a point-to-point link with a 31-bit
             mask, it can also be used as a source address.

    3.3. "Requirements for IP Version 4 Routers" [RFC1812]

       Section 4.2.2.11 (d) is replaced with:

          (d) { <Network-prefix>, -1 }

             Directed Broadcast - a broadcast directed to the specified
             network prefix.  It MUST NOT be used as a source address,
             except when the originator is one of the endpoints of a point-

    Retana, et al.              Standards Track                     [Page 5]

    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: aretana@cisco.com

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

       EMail: riw@cisco.com

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

       EMail: vaf@valinor.barrnet.net

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

       EMail: danny@ambernetworks.com

    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]