



Internet Area Working Group                                   J. Gilmore
Internet-Draft                            Electronic Frontier Foundation
Updates: 2827, 6890 (if approved)                               D. Taeht
Intended status: Best Current Practice                          TekLibre
Expires: April 6, 2020                                   October 4, 2019


                        IPv4 Unicast Extensions
                     draft-gilmore-taht-v4uniext-01

Abstract

      Editor's note: This draft has not been submitted to any formal
      process.  It may change significantly if it is ever submitted.
      You are reading it because we trust you and we value your
      opinions.  Feel free to link, but please do not recirculate it.
      Please join us in testing patches and equipment!

   Unicast addresses are the most successful and most useful kind of
   addresses in the Internet Protocol (IP).  Non-unicast portions have
   been allocated greater space than their usage requires, including
   some unused portions that have been "reserved for future use" for
   decades.  Meanwhile, rapid uptake of unicast IPv4 throughout the
   world has exhausted the supply of unicast addresses.  New IPv4 users
   are now regularly charged US$15 or more per address to reclaim them
   from older users.

   To reduce the barrier to new entrants, keeping the Internet's
   evolution open to all, this document extends the unicast address
   space to include several hundred million more unicast IPv4 addresses,
   worth billions of dollars to end users.  It updates [RFC6890] to
   reclassify these addresses as globally reachable unicast address
   space.

   Global implementation of these changes requires reprogramming some
   fraction of the IPv4-compatible equipment worldwide, a multi-year
   project that is not centrally funded nor organized.  We also discuss
   that transition.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.



Gilmore & Taeht           Expires April 6, 2020                 [Page 1]

Internet-Draft                v4unicast-ext                 October 2019


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 6, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  A brief history of the Internet Addressing models . . . . . .   3
     3.1.  ARPANET -> IPv4 . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Subnetting and broadcast extensions . . . . . . . . . . .   6
     3.3.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  CIDR and NAT  . . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  IPv6 address extension  . . . . . . . . . . . . . . . . .   7
     3.6.  IPv4 Address exhaustion . . . . . . . . . . . . . . . . .   8
   4.  Unicast use of address space formerly reserved for future use   8
     4.1.  Unicast use of Class-E address space  . . . . . . . . . .   9
     4.2.  Unicast use of 0/8  . . . . . . . . . . . . . . . . . . .  10
   5.  Unicast use of address spaces formerly reserved for other
       functions . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Unicast use of 127/8  . . . . . . . . . . . . . . . . . .  11
     5.2.  Unicast re-use of former Class D (multicast) address
           space . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Unicast use of formerly reserved per-network node addresses .  14
     6.1.  Unicast use of the zero node address in each network or
           subnet  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Unicast use of the all-ones node address in each point-
           to-point network  . . . . . . . . . . . . . . . . . . . .  15
   7.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Long Deployment Tail  . . . . . . . . . . . . . . . . . .  15



Gilmore & Taeht           Expires April 6, 2020                 [Page 2]

Internet-Draft                v4unicast-ext                 October 2019


     7.2.  Interoperation with un-extended nodes . . . . . . . . . .  15
     7.3.  Martians lists, bogons and BCP38  . . . . . . . . . . . .  16
   8.  Implementation status . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Address Range: 0/8  . . . . . . . . . . . . . . . . . . .  17
     8.2.  Address Range: 127/8  . . . . . . . . . . . . . . . . . .  18
     8.3.  Address Range: 225/8 through 231/8  . . . . . . . . . . .  18
     8.4.  Address Range: 240/4  . . . . . . . . . . . . . . . . . .  18
     8.5.  Routing to extended unicast networks  . . . . . . . . . .  19
     8.6.  Zeroth and final addresses in subnets . . . . . . . . . .  19
   9.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     13.2.  Informative References . . . . . . . . . . . . . . . . .  22
     13.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Introduction

   Unicast traffic has been the primary use of IPv4.  Broadcast,
   multicast, and reserved IP addresses are only used in tiny niches by
   comparison.  If IPv4 should evolve in small ways to better meet
   modern requirements, it should evolve to provide better support for
   unicast traffic.

   The largest issue with IPv4 unicast traffic today is caused by the
   shortage of IPv4 addresses.  This document specifies that all
   formerly "reserved for future use" addresses, plus some other non-
   unicast addresses that can most easily be reclaimed, should be
   dedicated for globally reachable unicast use.

3.  A brief history of the Internet Addressing models

   The Internet Protocol version 4 addressing model started off simple
   and has evolved over 40 years.  This Internet-Draft briefly
   summarizes that evolution, and proposes that as IPv4 approaches the
   end of its design life, significant benefits to the Internet
   community can ensue from simplifying a few of the vestigial choices
   made during that evolution.




Gilmore & Taeht           Expires April 6, 2020                 [Page 3]

Internet-Draft                v4unicast-ext                 October 2019


3.1.  ARPANET -> IPv4

   The Internet Protocol (IP version 4, IPv4) was designed from scratch
   as a replacement for the ARPANET [RFC6529] protocols.  Rather than
   enforcing uniformity, it followed the "Catenet Model" [IEN48] of a
   concatenated network of diversely implemented underlying networks,
   connected by simple and relatively memoryless gateways.

   The IP address, then expressed in x.x.x.x notation, could be used to
   specify both a particular network and a Host address on that network.
   There were several different classes of IP address, each having
   different numbers of bits allocated for the network # and address
   within that network.  Class A networks used 8 bits for network # and
   allowed 24 bits for address-on-that-network.  The ARPANET addresses
   could be encoded into 24 bits.  So, for ARPANET (and some of its
   clones), an IP address like 10.2.0.5 would mean network #10, Host #2
   on IMP #5.  Host #2 identified a specific physical connector on the
   back of the IMP cabinet.

   Routers (then known as gateways), hosts, and anybody else could take
   an IP address, and figure out the network address on that particular
   network by simple algorithm.  This worked for ARPANET, SATNET, and
   PRNETs.

   LANs broke this scheme.  In particular, Ethernet addresses were too
   big to be stuffed into even the 24 bits of a class-A IP address.  So
   algorithmic translations were not possible with those types of
   networks.  That ultimately led to the creation of ARP, and the use of
   broadcast capabilities of Ethernets, to implement a mechanism for
   doing translations.

   By the year 1981, IPv4 had landed as a simple and well-edited
   specification in [RFC0791], [RFC0792].

   The designers improved on ARPANET's addressing [RFC0635], and the
   addressing of several other common networks, with IPv4's 32-bit
   address space in [RFC0760].  The 32-bit address space was chosen as a
   compromise; its inability to address all the nodes that would likely
   want to use it was known from the start, but resource limitations in
   early routers, and development timelines, discouraged the use of
   longer addresses, and the IPv4 Internet was considered experimental
   and temporary.

   The initial IPv4 design designated almost 7/8ths of the possible
   addresses as ordinary unicast addresses.  These addresses identified
   individual nodes, routers, and interfaces, and could be used as
   source and destination addresses of packets designed to be forwarded




Gilmore & Taeht           Expires April 6, 2020                 [Page 4]

Internet-Draft                v4unicast-ext                 October 2019


   with full global reachability, and/or for packets on local area
   networks.  [RFC0791][RFC0796]

   Early standards do not use the term "unicast" because it only came to
   be used by contrast to multicast and broadcast, which came later in
   Internet protocol evolution.  [RFC0966] is the first to use the word
   "unicast", stating: "In this paper, we describe a model of multicast
   service we call host groups and propose this model as a way to
   support multicast in the DARPA Internet environment.  We argue that
   it is feasible to implement this facility as an extension of the
   existing 'unicast' IP datagram model and mechanism."

   1/8th of the 32-bit address space was left as "reserved for future
   use", and a few other 256ths were reserved for simple protocol
   functions or for future use in [RFC0791] (section 3.2) and [RFC0796].

   1/256th of the address space initially reserved for protocol
   functions was "network 0".  The IPv4 address 0.0.0.0 was reserved for
   use only as a source address by nodes that do not know their own
   address yet in [RFC1122] (section 3.2.1.3).  Addresses of the form
   0.x.y.z were initially defined only as a source address in an ICMP
   datagram, indicating "node number x.y.z on this IPv4 network", by
   nodes that know their address on their local network, but do not yet
   know their network prefix, in [RFC0792] (page 19).  This usage of
   0.x.y.z was later repealed in [RFC1122] (section 3.2.2.7), because
   the original ICMP-based mechanism for learning the network prefix was
   unworkable on many networks such as Ethernet (which have longer
   addresses that would not fit into the 24 "node number" bits).  Modern
   networks use reverse ARP [RFC0903] or BOOTP ([RFC0951])/DHCP
   ([RFC2131]) to find their full 32-bit address and CIDR netmask (and
   other parameters such as default gateways).  Eliminating this usage
   of 0.x.y.z left 16,777,215 addresses in 0.0.0.0/8 unused and reserved
   for future use.

   The other 1/256th of the address space initially reserved for
   protocol functions was network 127.  The entire set of 16 million
   addresses of the form 127.x.y.z were reserved in [RFC1122](section
   3.2.1.3) for "internal host loopback addresses" and "should never
   appear as a source or destination address on a network outside of a
   single node".  When IPv6 was designed in the 1990s, this was seen as
   excessive.  In [RFC1884] the single IPv6 loopback address was
   defined, but in IPv4, this reservation has continued to the present
   day.

   The remaining 1/16th of the "EXPERIMENTAL" portion of the address
   space has remained reserved and unused [RFC1112] (section 4) in the
   38 years since 1981.  This portion is now called 240/4 in CIDR
   notation and contains 268,435,455 addresses.



Gilmore & Taeht           Expires April 6, 2020                 [Page 5]

Internet-Draft                v4unicast-ext                 October 2019


3.2.  Subnetting and broadcast extensions

   In 1984, subnets were made part of the IP protocol by [RFC0917] and
   [RFC0922].

   Initially, subnets were only used "locally".  The global Internet
   routing infrastructure still only knew how to route to Class A, B,
   and C networks.  Local equipment in each such network could route
   locally to any local subnets, such as multiple Ethernets on a
   university campus.

   Also in 1984, broadcast addresses were added to IPv4 by [RFC0919],
   and [RFC0922].  This required reserving one IPv4 address within each
   and every network or subnet (the final address in that network or
   subnet, the "all-ones" host address).  The address 255.255.255.255
   was also reserved to make it easier to broadcast on "a local hardware
   network" without knowing the details of those networks.  This made
   broadcast a useful mechanism for discovering a node's own address on
   the network.

   The 1984 broadcast extension also reserved the initial (zero) address
   in each network or subnet, with [RFC0919] stating that "There is
   probably no reason for such addresses to appear anywhere", with a
   now-obsolete exception.  It also, apparently by coincidence,
   documented a human writing convention of designating a "network
   number" with the zero address, such as 36.0.0.0.  This convention has
   confused subsequent protocol users into thinking that the initial
   (zero) address in a network or subnet cannot be used as an ordinary
   unicast node address.

   Before those standards were finalized, one popular IPv4
   implementation, 4.2 BSD, used the zero node address for broadcast,
   rather than the all-ones node address.  When these mismatched
   implementations tried to interoperate on an Ethernet, it was easy to
   produce "broadcast storms" that would consume all available network
   bandwidth until manually stopped.  The offending implementation was
   upgraded in the subsequent 4.3 BSD release to meet the standards.
   The problem has not recurred for decades, but a remnant of the gaffe
   exists in the prohibition in [RFC1122] (section 3.2.2.7) on using the
   zero node address in a network or subnet.

3.3.  Multicast

   Later (1988) designers chose to allocate 1/16th of the total space
   (half of the formerly reserved space) for multicast use in [RFC1112].
   While multicast was a much better idea than the sole similar former
   option (broadcast), its use on anything besides local area networks
   has remained a tiny niche, in retrospect clearly not worth



Gilmore & Taeht           Expires April 6, 2020                 [Page 6]

Internet-Draft                v4unicast-ext                 October 2019


   designating 1/16th of the entire address space for.  This address
   space is called 224/4 in Phil Karn's more modern CIDR [RFC4632]
   notation.

   By 1989, the revisions to the basic Internet Protocol suite required
   reading dozens and dozens of documents.  The basic requirements for
   Internet hosts and gateways were then consolidated into
   [RFC1022][RFC1023][RFC1024].

3.4.  CIDR and NAT

   By 1992, the original network addressing and routing architecture was
   straining at the seams.  The problems were "the lack of a network
   class of a size which is appropriate for mid-sized organization[s]",
   growth of routing tables beyond available capacities, and the
   "eventual exhaustion of the 32-bit IP address space" as documented in
   [RFC1338].  After a convincing extrapolation that Class-B space would
   be exhausted by mid-1994 [IETF-13], the ROAD working group was
   formed.

   Their proposed fixes involved an extension of subnetting to
   "supernetting" multiple Class C networks, deploying classless routing
   protocols, and generally deprecating the concept of "network address
   classes".  Each network address would be represented by a "pair": an
   address and a mask.  This proposal reserved the address 0.0.0.0 with
   mask 0.0.0.0 as the "default route" with special rules.  This was
   adopted in 1993 as Classless Inter-Domain Routing (CIDR) for Class C,
   and half of Class A (a quarter of the entire Internet address space)
   was reserved for future subnetting after deployment of more capable
   routing protocols by [RFC1466], [RFC1518], [RFC1519].

   In 1994, NAT [RFC1631] also appeared as an interim solution to
   address depletion.

   By 1995, the implementation of subnetting for "Class A" addresses
   proved sufficiently buggy that the IANA began a global experiment by
   allocating 256 subnetted Class A addresses to _every_ existing
   address space user, and encouraging them to be used to verify correct
   operation of their gateways and hosts, in [RFC1797].  Even in 1996,
   [RFC2036] described that large parts of the Internet could not
   correctly subnet Class A addresses.

3.5.  IPv6 address extension

   IPv6 was first standardized in 1995 [RFC1883], and refined by many
   successive RFCs, currently culminating in [RFC8200].  It has an 128
   bit address space.




Gilmore & Taeht           Expires April 6, 2020                 [Page 7]

Internet-Draft                v4unicast-ext                 October 2019


3.6.  IPv4 Address exhaustion

   In 2011, IPv4 address exhaustion happened, on schedule.  Demand for
   IPv4 and IPv6 to IPv4 translation technologies spiked, leveraging
   [RFC1918], with CGNS ([RFC7289]), DS-Lite ([RFC6333]), and 464XLAT
   ([RFC6877]) becoming widely adopted.  While each of these solutions
   is inadequate in their own way, and pure IPv6 is superior, the need
   for IPv4 address space appears unslakeable for the next 20 years.

   Although a market has appeared for existing IPv4 allocations, and
   small amounts of address space returned to the global pools, demand
   for IPv4 addressing continues unabated.  New edge and data center
   technologies are creating new demands, and internet-accessible
   servers will need to be dual stacked for a long time to come.

   In 2008 [I-D.fuller-240space], and 2010 [I-D.wilson-class-e] first
   proposed that the 240/4 address space become usable - the first draft
   mandating no explicit use; the second, as "private" RFC1918-like
   addresses.  Neither of these drafts became Internet Standards, yet
   the network community generally implemented them in major operating
   systems anyway.  Few people have noticed, since there was and still
   is no straightforward way to have such an IPv4 address block globally
   allocated for your network.

   Treating 240/4 as globally reachable unicast is now a de facto
   standard, with support in all the major operating systems except
   Microsoft Windows, and only a few edge cases left to fix.

   240/4 and the additional address blocks outlined in this document can
   become viable unicast address blocks.

   This Internet-Draft proposes that all implementers should make the
   small changes required to receive, transmit, and forward packets that
   contain addresses in these blocks as if they were within any other
   unicast address block.

   It is envisioned that the utility of these blocks will grow over
   time.  Some devices may never be able to use them as their IP
   implementations have no update mechanism.

4.  Unicast use of address space formerly reserved for future use

   The attributes of blocks of address space are described by the IANA
   and in IETF publications by structured, boxed tables; see [RFC6890].
   This document proposes replacing the former description tables of
   these blocks, with those included in this document.





Gilmore & Taeht           Expires April 6, 2020                 [Page 8]

Internet-Draft                v4unicast-ext                 October 2019


4.1.  Unicast use of Class-E address space

   These new unicast addresses, 240.0.0.0 through 255.255.255.254,
   replace the Class E address space, which was formerly reserved (by
   [RFC1112]).  This document updates [RFC6890], table 15.

          +----------------------+----------------------------+
          | Attribute            | Value                      |
          +----------------------+----------------------------+
          | Address Block        | 240.0.0.0/4                |
          |                      | (except 255.255.255.255)   |
          | Name                 | Ordinary Unicast Addresses |
          | RFC                  | This Internet-Draft        |
          | Allocation Date      | 2019                       |
          | Termination Date     | N/A                        |
          | Source               | True                       |
          | Destination          | True                       |
          | Forwardable          | True                       |
          | Globally Reachable   | True                       |
          | Reserved-by-Protocol | False                      |
          +----------------------+----------------------------+

                                 Figure 1

   The broadcast address, 255.255.255.255, still must be treated
   specially: it is invalid as a source IP address, and it is invalid as
   a network interface address.  When used as the destination in a
   datagram sent by a node, it causes the packet to be broadcast on one
   of the hardware networks directly accessible to the node.  This
   behavior is unchanged from previously specified behavior in
   [RFC6890], table 16, e.g.:

         +----------------------+----------------------------+
         | Attribute            | Value                      |
         +----------------------+----------------------------+
         | Address Block        | 255.255.255.255/32         |
         | Name                 | Limited Broadcast          |
         | RFC                  | RFC919                     |
         | Allocation Date      | 1984                       |
         | Termination Date     | N/A                        |
         | Source               | False                      |
         | Destination          | True                       |
         | Forwardable          | False                      |
         | Globally Reachable   | False                      |
         | Reserved-by-Protocol | True                       |
         +----------------------+----------------------------+

                                 Figure 2



Gilmore & Taeht           Expires April 6, 2020                 [Page 9]

Internet-Draft                v4unicast-ext                 October 2019


4.2.  Unicast use of 0/8

   These new unicast addresses, 0.0.0.1 through 0.255.255.255, replace
   the obsolete "This host on this network" concept from [RFC0791],
   replacing table 1 of [RFC6890].

          +----------------------+----------------------------+
          | Attribute            | Value                      |
          +----------------------+----------------------------+
          | Address Block        | 0.0.0.0/8                  |
          |                      | (except 0.0.0.0)           |
          | Name                 | Ordinary Unicast Addresses |
          | RFC                  | This Internet-Draft        |
          | Allocation Date      | 2019                       |
          | Termination Date     | N/A                        |
          | Source               | True                       |
          | Destination          | True                       |
          | Forwardable          | True                       |
          | Globally Reachable   | True                       |
          | Reserved-by-Protocol | False                      |
          +----------------------+----------------------------+

                                 Figure 3

   The Unknown Local Address, 0.0.0.0, still must be treated specially:
   it is usable only as a source IP address, and only in nodes that do
   not know or have an IPv4 address on the network where the packet
   appears; it is invalid as a network interface address.  Typically,
   such an address is used as the source address in a UDP-based protocol
   like BOOTP or DHCP to ask another node to supply this node with a
   usable address.  This behavior is unchanged from previously specified
   behavior.

   (IGMP [RFC4541] also uses 0.0.0.0 in an address field in some of its
   payload, for unrelated functions; these are also unchanged.)
















Gilmore & Taeht           Expires April 6, 2020                [Page 10]

Internet-Draft                v4unicast-ext                 October 2019


         +----------------------+----------------------------+
         | Attribute            | Value                      |
         +----------------------+----------------------------+
         | Address Block        | 0.0.0.0/32                 |
         | Name                 | Unknown Local Address      |
         | RFC                  | This Internet-Draft        |
         | Allocation Date      | 1981                       |
         | Termination Date     | N/A                        |
         | Source               | True                       |
         | Destination          | False                      |
         | Forwardable          | False                      |
         | Globally Reachable   | False                      |
         | Reserved-by-Protocol | True                       |
         +----------------------+----------------------------+

                                 Figure 4

5.  Unicast use of address spaces formerly reserved for other functions

5.1.  Unicast use of 127/8

   These new unicast addresses, 127.1.0.0 through 127.255.255.255,
   replace more than 99% of the former reserved Loopback address space,
   updating table 4 of [RFC6890].

          +----------------------+----------------------------+
          | Attribute            | Value                      |
          +----------------------+----------------------------+
          | Address Block        | 127.0.0.0/8                |
          |                      | (except 127.0.0.0/16)      |
          | Name                 | Ordinary Unicast Addresses |
          | RFC                  | This Internet-Draft        |
          | Allocation Date      | 2019                       |
          | Termination Date     | N/A                        |
          | Source               | True                       |
          | Destination          | True                       |
          | Forwardable          | True                       |
          | Globally Reachable   | True                       |
          | Reserved-by-Protocol | False                      |
          +----------------------+----------------------------+

                                 Figure 5

   To the extent that any existing users had special uses for some small
   subsets of this space, those subsets may be allocated to those users
   by administrative action of IANA.





Gilmore & Taeht           Expires April 6, 2020                [Page 11]

Internet-Draft                v4unicast-ext                 October 2019


   A smaller set of Loopback Addresses, 127.0.0.0 through 127.0.255.255,
   still must be treated specially: they are usable only as a
   destination IP address; they are invalid as a network interface
   address; and when used as a destination address in a packet, the
   packet is received and consumed only by the current node.  Typically,
   such an address is used when communicating with another process on
   this particular node.  Multiple addresses are provided, and can be
   distinguished by recipient processes, to accommodate historical use
   patterns.  This behavior is unchanged from previously specified
   behavior, though it now only applies to 65,536 addresses rather than
   to 16,777,216 addresses.

         +----------------------+----------------------------+
         | Attribute            | Value                      |
         +----------------------+----------------------------+
         | Address Block        | 127.0.0.0/16               |
         | Name                 | Loopback Addresses         |
         | RFC                  | This Internet-Draft        |
         | Allocation Date      | 1981                       |
         | Termination Date     | N/A                        |
         | Source               | False                      |
         | Destination          | True                       |
         | Forwardable          | False                      |
         | Globally Reachable   | False                      |
         | Reserved-by-Protocol | True                       |
         +----------------------+----------------------------+

                                 Figure 6

5.2.  Unicast re-use of former Class D (multicast) address space

   These new unicast addresses, 225.0.0.0 through 231.255.255.255,
   replace more than 40% of the address space formerly reserved for
   future Multicast use.

















Gilmore & Taeht           Expires April 6, 2020                [Page 12]

Internet-Draft                v4unicast-ext                 October 2019


          +----------------------+----------------------------+
          | Attribute            | Value                      |
          +----------------------+----------------------------+
          | Address Block        | 225.0.0.0/8 - 231.0.0.0/8  |
          | Name                 | Ordinary Unicast Addresses |
          | RFC                  | This Internet-Draft        |
          | Allocation Date      | 2019                       |
          | Termination Date     | N/A                        |
          | Source               | True                       |
          | Destination          | True                       |
          | Forwardable          | True                       |
          | Globally Reachable   | True                       |
          | Reserved-by-Protocol | False                      |
          +----------------------+----------------------------+

                                 Figure 7

   The principal Multicast Addresses, 224.0.0.0 through 224.255.255.255,
   still must be treated specially.  They are only usable as a
   destination address; they are invalid as a network interface address;
   and when used as a destination address in a packet, the packet is
   sent to zero or more attached networks by using lower level network
   multicast capabilities that allow it to be received by multiple nodes
   on those networks.

   Multiple addresses are provided, and can be distinguished by
   recipient processes, to accommodate historical use patterns.  This
   behavior is unchanged from previously specified behavior, though it
   now only applies to 150,994,944 addresses rather than to 268,435,456
   addresses.

         +----------------------+----------------------------+
         | Attribute            | Value                      |
         +----------------------+----------------------------+
         | Address Block        | 224.0.0.0/8                |
         | Name                 | Multicast Addresses        |
         | RFC                  | RFC1112                    |
         | Allocation Date      | 1989                       |
         | Termination Date     | N/A                        |
         | Source               | True                       |
         | Destination          | True                       |
         | Forwardable          | True                       |
         | Globally Reachable   | True                       |
         | Reserved-by-Protocol | True                       |
         +----------------------+----------------------------+

                                 Figure 8




Gilmore & Taeht           Expires April 6, 2020                [Page 13]

Internet-Draft                v4unicast-ext                 October 2019


   Multiple other multicast address spaces have fallen into disuse, and
   a discussion of possibilities for their re-use will take place in
   another document.

6.  Unicast use of formerly reserved per-network node addresses

   In order to extend the usable unicast addresses in every existing
   subnet, this document redefines the zeroth address of each subnet,
   and also redefines the final address in subnets that do not support
   broadcasting.  These changes reduce the wastage of address space by
   allowing these formerly-reserved addresses to be used as ordinary
   unicast addresses.

   For example, a /29 network that formerly allowed 6 unique interface
   addresses on an Ethernet can now use 7.  A /31 network that formerly
   allowed no unique interface addresses at all can be used for the two
   interfaces in a point-to-point network as per [RFC3021].

6.1.  Unicast use of the zero node address in each network or subnet

   The zeroth network address of any given network MUST be a fully
   addressable, globally reachable, unicast, interface address on that
   network.

   As a minor exception, now that 0/8 is designated as global unicast
   space, it is possible to define a network whose zeroth address
   overlaps the reserved address 0.0.0.0.  Such a network does not have
   a fully addressable, globally reachable, unicast zeroth address,
   because 0.0.0.0 is always reserved and always has its reserved
   meaning.  For example, despite the preceding paragraph, network
   0.0.0.0/24 only includes 253 usable addresses, starting from 0.0.0.1
   and ending at 0.0.0.254.

   When configuring or describing the IPv4 address of an interface on a
   network, the full 32-bit interface address is traditionally used
   along with the CIDR network mask.  For example, interface 37 on a
   network with a 24-bit prefix could be configured as 198.51.100.37/24.
   When the zeroth address is in use at a host as a network interface,
   that interface should be configured in the identical way, as e.g.
   198.51.100.0/24.  This usage does not conflict with the informal
   usage of 198.51.100.0/24 to refer to the entire network whose
   addresses range from 198.51.100.0 through 198.51.100.255.









Gilmore & Taeht           Expires April 6, 2020                [Page 14]

Internet-Draft                v4unicast-ext                 October 2019


6.2.  Unicast use of the all-ones node address in each point-to-point
      network

   The final network address of any given network that supports
   broadcasting has traditionally been used as the broadcast address on
   that network.  (The final address is also referred to as the "all-
   ones" address, since all of the bits after the network prefix are all
   one-bits.)  This usage remains unchanged.

   This document clarifies that, on networks which do not support
   broadcasting, the final network address MUST be an ordinary, fully
   addressable, globally reachable unicast address.  In particular, on
   point-to-point networks that only contain two interfaces, such as one
   running the Point-to-Point Protocol ([RFC1331]), the zeroth address
   and the final address SHOULD be configured as the addresses of the
   two interfaces, thus only requiring a /31 network prefix.

   As a minor exception, now that 255/8 is designated as global unicast
   space, it is possible to define a network whose final address
   overlaps the reserved address 255.255.255.255.  Such a network does
   not have a final all-ones address, because 255.255.255.255 is
   reserved.  So, for example, there is no way to address a broadcast to
   the entire network 255.255.0.0/16; and the all-ones address on a
   point-to-point network at 255.255.255.252/30 does not refer to an
   interface on that network.  The address 255.255.255.255 MUST always
   be treated as the reserved "Local Broadcast" address, which could
   cause a broadcast packet to be sent on any interface on the local
   node (not necessarily on the network that includes the address
   255.255.255.254).

7.  Issues

   This document does not presently go into all the possible issues with
   these reallocations.  As with any specification change, there will be
   interoperability issues between nodes which follow the original
   specification, and nodes which follow the changed specification.

7.1.  Long Deployment Tail

   With sufficient thrust, [RFC1925], pigs can fly.

7.2.  Interoperation with un-extended nodes

   This document seeks to minimize the operational impact of those
   issues, by only allocating new unicast addresses from addresses that
   were not in use on the global Internet.





Gilmore & Taeht           Expires April 6, 2020                [Page 15]

Internet-Draft                v4unicast-ext                 October 2019


   In nearly all cases a node without support for these address spaces,
   will simply fail to assign, forward, or reach them.

   The most usual failure mode when these new unicast addresses are
   used, is simply a failure to communicate with nodes that follow the
   original specification, because the original nodes check for and
   refuse to allow such addresses.  As these nodes go out of service, or
   are gradually replaced or upgraded, these addresses will become
   usable in more and more applications.

   On the other hand, the new unicast addresses may be immediately
   usable in new applications, where interoperation with legacy nodes is
   not an issue.

   Reallocation of the former multicast addresses as unicast can cause
   unique issues, since unmodified nodes will transmit to such
   destination addresses by using link-level multicast packets, while
   extended nodes will use link-level unicast packets.  The full
   implications of this issue have not yet been explored.

7.3.  Martians lists, bogons and BCP38

   [RFC3704] states:

      [RFC2827] recommends that ISPs police their customers' traffic by
      dropping traffic entering their networks that is coming from a
      source address not legitimately in use by the customer network.
      The filtering includes but is in no way limited to the traffic
      whose source address is a so-called "Martian Address" - an address
      that is reserved [3], including any address within 0.0.0.0/8,
      10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
      224.0.0.0/4, or 240.0.0.0/4.

   ISPs that filter their customers' traffic based on source address
   MUST NOT discard traffic solely because it has a source addresses in
   the ranges 0.0.0.0/8, 240.0.0.0/4, 127.0.0.0/8, and 225.0.0.0/8
   through 231.0.0.0/8, except the addresses 0.0.0.0, 255.255.255.255,
   and the loopback addresses 127.0.0.0/16.  However, if a customer
   network has not been allocated a source address in these ranges, then
   they can be filtered out as attempts to spoof someone else's network.

   No ISP filter should ever discard datagrams based on destination
   addresses within these newly extended unicast ranges.

   The only remaining Martian addresses now include:

   o  0.0.0.0/32




Gilmore & Taeht           Expires April 6, 2020                [Page 16]

Internet-Draft                v4unicast-ext                 October 2019


   o  100.64.0.0/10

   o  10.0.0.0/8

   o  127.0.0.0/16

   o  172.16.0.0/12

   o  169.254.0.0/16

   o  192.0.0.0/24

   o  192.0.2.0/24

   o  192.168.0.0/16

   o  198.18.0.0/15

   o  198.51.100.0/24

   o  203.0.113.0/24

   o  224.0.0.0/8

   o  232.0.0.0/5

   o  255.255.255.255/32

   Firewalls [CBR03], packet filters, and intrusion detection systems,
   MUST be capable of monitoring and managing the newly extended unicast
   addresses.

   Routing protocols MUST treat the newly extended unicast addresses as
   unicast, globally reachable addresses.

8.  Implementation status

8.1.  Address Range: 0/8

   Linux now allows the unicast use of 0/8 as of version 5.3.

   Small FreeBSD kernel patches and routing daemon patches are now
   available.








Gilmore & Taeht           Expires April 6, 2020                [Page 17]

Internet-Draft                v4unicast-ext                 October 2019


8.2.  Address Range: 127/8

   All implementations currently allow the use of 127/8 for local
   traffic, however they do not allow its use for globally routable
   unicast traffic.  There are preliminary Linux and FreeBSD kernel
   patches to restrict the "local" requirement of the existing
   specification to 127.0/16 and permit globally routable unicast
   traffic in the rest of 127/8.  NTP uses 127.127 for the clock
   interface, and several chassis control systems have been found that
   use an address in the 127 range.

   In addition, system configuration scripts that configure the internal
   "loopback interface" probably need modification.

8.3.  Address Range: 225/8 through 231/8

   No implementation is currently known to allow the unicast use of
   225/8 - 231/8.  Some bridges (usually wifi) are known to convert
   multicast in all ranges to unicast.  Converting these spaces to
   unicast beforehand has thus far been observed to cause no problems.

   Small Linux and FreeBSD kernel patches provide this extension.

8.4.  Address Range: 240/4

   The following operating systems support the use of 240.0.0.0/4 as
   unicast, globally reachable address space: Solaris, Linux, Android,
   Apple OSX, Apple IOS, and FreeBSD.  This support has existed since
   approximately 2008.  There are some issues with parts of BSD network
   stack that treat Class-E addresses as "invalid".  There are also
   cases of translation (NAT64) where checks reject Class-E addresses
   and need small fixes.  In both cases we have the patches under review
   for FreeBSD.  Four out of the top 5 open source IoT stacks already
   treat 240/4 as unicast, with a 3 line patch awaiting submission for
   the fifth.

   Some deployments of the BIND Domain Name System implementation (e.g.
   Debian) override the reverse DNS for 255.in-addr.arpa. with a local
   empty domain, and do not forward requests for those addresses.  These
   packages will require revision.

   Recent versions of Microsoft Windows will not accept nor forward any
   packet with either a source or destination address in 240/4.  Nor
   will they assign an interface address in this range, if one is
   offered via DHCP.  No plans have been announced for modifications to
   any version of Microsoft Windows.  Windows developers are aware of
   the work required, and are considering it for a future version.




Gilmore & Taeht           Expires April 6, 2020                [Page 18]

Internet-Draft                v4unicast-ext                 October 2019


   Juniper routers block traffic for 240/4 by default, but there has
   been a simple configuration switch to disable that check since 2010,
   at which point they are fully functional.

   Some cisco routers can assign and route 240/4, most don't.

8.5.  Routing to extended unicast networks

   The reaction of free software routing applications to receiving
   routing updates that include the extended unicast addresses is as yet
   somewhat undetermined.

   Cisco and Juniper routers' reaction to seeing routing updates that
   include the extended unicast addresses is as yet undetermined.

   The [RFC6126] Babel routing protocol and its primary implementation
   fully supports unicast 240/4.

   Patches for allowing unicast 240/4 routes have been submitted to the
   BGP/OSPF/ISIS capable routing daemon projects, "Bird", and "FRR".
   However, there may be interoperability issues with unmodified
   daemons.

   All we have observed is an increase in logfile messages, no session
   drops, no crashes, for as-yet unpatched routing daemons.

8.6.  Zeroth and final addresses in subnets

   The specific configuration of a distant subnet is not generally known
   to a node that is sending traffic to an address in that subnet.  The
   sender does not know the network mask of the destination subnet, so
   it cannot prohibit sending packets to the zeroth or final addresses
   in that subnet.  Therefore, the main issue is not with distant nodes
   that communicate with these addresses, which should work without
   trouble, but with local area network equipment that does know the
   subnet address mask.

   Informally, most operating systems and networking equipment already
   supports the use of the zeroth address as a unicast address.

   Informally, most operating systems and networking equipment already
   supports the use of the final address in a point-to-point network as
   a unicast address.








Gilmore & Taeht           Expires April 6, 2020                [Page 19]

Internet-Draft                v4unicast-ext                 October 2019


9.  Related Work

   The last previous attempts at making more unicast IPv4 address space
   occurred in 2008-2010, with proposals for making 240/4 into pure
   public routable unicast [I-D.fuller-240space], or routable, but
   private, RFC1918 style unicast address space [I-D.wilson-class-e].
   Neither proposal gained rough consensus in the IETF.  However,
   "running code" - making 240/4 actually work - was almost universally
   adopted in the field.

   It is presently unknown if any organization is making local or global
   use on the network of 240/4, 0/8, 127/8, or any of the reserved
   portions of multicast now re-assigned to unicast.  A network
   telescope study of existing traffic is planned.

10.  IANA Considerations

   Although this document requires implementations to treat these
   addresses the same as any other unicast addresses, it does not
   determine how these addresses will be administratively allocated to
   Internet users.

   240.0.0.0/4 and 0.0.0.0/8 move from the "special purpose" registry
   (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
   ipv4-special-registry.xhtml [1]) and are added to the regular "ipv4-
   address-space" registry ( https://www.iana.org/assignments/ipv4-
   address-space/ipv4-address-space.xhtml) [2]

   0.0.0.0/32 and 127.0.0.0/16 should be added to the special purpose
   registry.

   In the ipv4-address-space registry, 240/4 should be moved from future
   use to unallocated, and 225/8 - 231/8 should be moved from multicast
   to unallocated. 127.1.0.0/16 and up should be added.

   IANA is also requested to prepare the these address spaces to be
   available as reverse DNS space in in-addr.arpa.

11.  Security Considerations

   Presently access to the 240/4 and 0/8 blocks are mostly assumed to be
   managed somewhere along the edge of the network, and wider
   availability merely requires removal of this space from common bogon
   lists and hard coded martian files.  In many other cases it will
   "just work", but thought needs to be given to any additional security
   exposures to existing firewalled networks.





Gilmore & Taeht           Expires April 6, 2020                [Page 20]

Internet-Draft                v4unicast-ext                 October 2019


   Address space in the localnet and multicast blocks are also primarily
   assumed to be managed elsewhere in the network, and subject to the
   same bogon filter and martian list fixes.

12.  Acknowledgements

   Jason Ackley, John Perry Barlow, Brian Carpenter, Vint Cerf, Kevin
   Darbyshire-Bryant, Vince Fuller, Stephen Hemminger, Geoff Huston, Rob
   Landley, Eliot Lear, Dan Mahoney, and Paul Wouters all made
   contributions to this document, directly or indirectly.  Thanks also
   to the members of the internet history mailing list [IHML] for
   helping get the early details straight.

13.  References

13.1.  Normative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3021]  Retana, A., White, R., Fuller, V., and D. McPherson,
              "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
              RFC 3021, DOI 10.17487/RFC3021, December 2000,
              <https://www.rfc-editor.org/info/rfc3021>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <https://www.rfc-editor.org/info/rfc6890>.






Gilmore & Taeht           Expires April 6, 2020                [Page 21]

Internet-Draft                v4unicast-ext                 October 2019


13.2.  Informative References

   [CBR03]    Cheswick, W., Bellovin, S., and A. Rubin, "Firewalls and
              Internet Security: Repelling the Wily Hacker, Second
              Edition", 2003.

   [I-D.fuller-240space]
              Fuller, V., "Reclassifying 240/4 as usable unicast address
              space", draft-fuller-240space-02 (work in progress), March
              2008.

   [I-D.wilson-class-e]
              Wilson, P., Michaelson, G., and G. Huston, "Redesignation
              of 240/4 from "Future Use" to "Private Use"", draft-
              wilson-class-e-02 (work in progress), September 2008.

   [IEN48]    Cerf, V., "The CATENET MODEL FOR INTERNETWORKING", 1978.

   [IETF-13]  Gross, P. and K. Bowers, "IETF Proceedings", 1989.

   [IHML]     Many, T., "Internet History Mailing list", 2019.

   [RFC0635]  Cerf, V., "Assessment of ARPANET protocols", RFC 635,
              DOI 10.17487/RFC0635, April 1974,
              <https://www.rfc-editor.org/info/rfc635>.

   [RFC0760]  Postel, J., "DoD standard Internet Protocol", RFC 760,
              DOI 10.17487/RFC0760, January 1980,
              <https://www.rfc-editor.org/info/rfc760>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC0796]  Postel, J., "Address mappings", RFC 796,
              DOI 10.17487/RFC0796, September 1981,
              <https://www.rfc-editor.org/info/rfc796>.

   [RFC0903]  Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
              Reverse Address Resolution Protocol", STD 38, RFC 903,
              DOI 10.17487/RFC0903, June 1984,
              <https://www.rfc-editor.org/info/rfc903>.





Gilmore & Taeht           Expires April 6, 2020                [Page 22]

Internet-Draft                v4unicast-ext                 October 2019


   [RFC0917]  Mogul, J., "Internet subnets", RFC 917,
              DOI 10.17487/RFC0917, October 1984,
              <https://www.rfc-editor.org/info/rfc917>.

   [RFC0919]  Mogul, J., "Broadcasting Internet Datagrams", STD 5,
              RFC 919, DOI 10.17487/RFC0919, October 1984,
              <https://www.rfc-editor.org/info/rfc919>.

   [RFC0922]  Mogul, J., "Broadcasting Internet datagrams in the
              presence of subnets", STD 5, RFC 922,
              DOI 10.17487/RFC0922, October 1984,
              <https://www.rfc-editor.org/info/rfc922>.

   [RFC0951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              DOI 10.17487/RFC0951, September 1985,
              <https://www.rfc-editor.org/info/rfc951>.

   [RFC0966]  Deering, S. and D. Cheriton, "Host groups: A multicast
              extension to the Internet Protocol", RFC 966,
              DOI 10.17487/RFC0966, December 1985,
              <https://www.rfc-editor.org/info/rfc966>.

   [RFC1022]  Partridge, C. and G. Trewitt, "High-level Entity
              Management Protocol (HEMP)", RFC 1022,
              DOI 10.17487/RFC1022, October 1987,
              <https://www.rfc-editor.org/info/rfc1022>.

   [RFC1023]  Trewitt, G. and C. Partridge, "HEMS monitoring and control
              language", RFC 1023, DOI 10.17487/RFC1023, October 1987,
              <https://www.rfc-editor.org/info/rfc1023>.

   [RFC1024]  Partridge, C. and G. Trewitt, "HEMS variable definitions",
              RFC 1024, DOI 10.17487/RFC1024, October 1987,
              <https://www.rfc-editor.org/info/rfc1024>.

   [RFC1331]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
              Transmission of Multi-protocol Datagrams over Point-to-
              Point Links", RFC 1331, DOI 10.17487/RFC1331, May 1992,
              <https://www.rfc-editor.org/info/rfc1331>.

   [RFC1338]  Fuller, V., Li, T., Yu, J., and K. Varadhan,
              "Supernetting: an Address Assignment and Aggregation
              Strategy", RFC 1338, DOI 10.17487/RFC1338, June 1992,
              <https://www.rfc-editor.org/info/rfc1338>.

   [RFC1466]  Gerich, E., "Guidelines for Management of IP Address
              Space", RFC 1466, DOI 10.17487/RFC1466, May 1993,
              <https://www.rfc-editor.org/info/rfc1466>.



Gilmore & Taeht           Expires April 6, 2020                [Page 23]

Internet-Draft                v4unicast-ext                 October 2019


   [RFC1518]  Rekhter, Y. and T. Li, "An Architecture for IP Address
              Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
              September 1993, <https://www.rfc-editor.org/info/rfc1518>.

   [RFC1519]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
              Inter-Domain Routing (CIDR): an Address Assignment and
              Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519,
              September 1993, <https://www.rfc-editor.org/info/rfc1519>.

   [RFC1631]  Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May
              1994, <https://www.rfc-editor.org/info/rfc1631>.

   [RFC1797]  Internet Assigned Numbers Authority (IANA), "Class A
              Subnet Experiment", RFC 1797, DOI 10.17487/RFC1797, April
              1995, <https://www.rfc-editor.org/info/rfc1797>.

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
              December 1995, <https://www.rfc-editor.org/info/rfc1883>.

   [RFC1884]  Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
              Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
              December 1995, <https://www.rfc-editor.org/info/rfc1884>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
              DOI 10.17487/RFC1925, April 1996,
              <https://www.rfc-editor.org/info/rfc1925>.

   [RFC2036]  Huston, G., "Observations on the use of Components of the
              Class A Address Space within the Internet", RFC 2036,
              DOI 10.17487/RFC2036, October 1996,
              <https://www.rfc-editor.org/info/rfc2036>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.





Gilmore & Taeht           Expires April 6, 2020                [Page 24]

Internet-Draft                v4unicast-ext                 October 2019


   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
              <https://www.rfc-editor.org/info/rfc4541>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
              2006, <https://www.rfc-editor.org/info/rfc4632>.

   [RFC6126]  Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
              DOI 10.17487/RFC6126, April 2011,
              <https://www.rfc-editor.org/info/rfc6126>.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <https://www.rfc-editor.org/info/rfc6333>.

   [RFC6529]  McKenzie, A. and S. Crocker, "Host/Host Protocol for the
              ARPA Network", RFC 6529, DOI 10.17487/RFC6529, April 2012,
              <https://www.rfc-editor.org/info/rfc6529>.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/info/rfc6877>.

   [RFC7289]  Kuarsingh, V., Ed. and J. Cianfarani, "Carrier-Grade NAT
              (CGN) Deployment with BGP/MPLS IP VPNs", RFC 7289,
              DOI 10.17487/RFC7289, June 2014,
              <https://www.rfc-editor.org/info/rfc7289>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

13.3.  URIs

   [1] https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
       ipv4-special-registry.xhtml

   [2] https://www.iana.org/assignments/ipv4-address-space/ipv4-address-
       space.xhtml)





Gilmore & Taeht           Expires April 6, 2020                [Page 25]

Internet-Draft                v4unicast-ext                 October 2019


Authors' Addresses

   John Gilmore
   Electronic Frontier Foundation
   PO Box 170608-ietf-id
   San Francisco, CA  94117
   USA

   Phone: +1 415 221 6524
   Email: gnu@ietf-id.toad.com
   URI:   http://www.toad.com


   David M. Taeht
   TekLibre
   20600 Aldercroft Heights Rd
   Los Gatos, CA  95033
   USA

   Phone: +1 831 205 9740
   Email: dave@taht.net
   URI:   http://www.teklibre.com





























Gilmore & Taeht           Expires April 6, 2020                [Page 26]
