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, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [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, . 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, . [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, DOI 10.17487/RFC0760, January 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0796] Postel, J., "Address mappings", RFC 796, DOI 10.17487/RFC0796, September 1981, . [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, . 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, . [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, . [RFC0922] Mogul, J., "Broadcasting Internet datagrams in the presence of subnets", STD 5, RFC 922, DOI 10.17487/RFC0922, October 1984, . [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, DOI 10.17487/RFC0951, September 1985, . [RFC0966] Deering, S. and D. Cheriton, "Host groups: A multicast extension to the Internet Protocol", RFC 966, DOI 10.17487/RFC0966, December 1985, . [RFC1022] Partridge, C. and G. Trewitt, "High-level Entity Management Protocol (HEMP)", RFC 1022, DOI 10.17487/RFC1022, October 1987, . [RFC1023] Trewitt, G. and C. Partridge, "HEMS monitoring and control language", RFC 1023, DOI 10.17487/RFC1023, October 1987, . [RFC1024] Partridge, C. and G. Trewitt, "HEMS variable definitions", RFC 1024, DOI 10.17487/RFC1024, October 1987, . [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, . [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, . [RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, DOI 10.17487/RFC1466, May 1993, . 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, . [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, . [RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May 1994, . [RFC1797] Internet Assigned Numbers Authority (IANA), "Class A Subnet Experiment", RFC 1797, DOI 10.17487/RFC1797, April 1995, . [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, December 1995, . [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, December 1995, . [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, . [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, April 1996, . [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, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . 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, . [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, . [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, . [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, . [RFC6529] McKenzie, A. and S. Crocker, "Host/Host Protocol for the ARPA Network", RFC 6529, DOI 10.17487/RFC6529, April 2012, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 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]