Unicast Use of the Formerly Reserved 240/4

Introduction With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to redefine the "Experimental" or "Future Use" 240/4 region (historically known as "Class E" addresses) as ordinary unicast addresses. These 268 million IPv4 addresses are already usable for unicast traffic in many popular implementations today. Standardization as unicast addresses will eventually allow them to be later deployed by Internet stewardship organizations to relieve address space scarcity.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Background

History of IPv4 Address Types When the Internet Protocol was being designed, it was unclear whether it would be a success, or which of its features might be the key features that led to success. The bulk of its address space was dedicated to ordinary "host addresses". Other blocks and corners of the address space were reserved, either for particular protocol functions such as loopback, LAN broadcasting, or host bootstrapping, or for future definition. A major allocation of 268 million addresses was later made for multicasting, while leaving another 268 million reserved for "future use". After the invention of broadcast and multicast, the original ordinary host addresses were later described as unicast addresses, which is now the usual terminology. With decades of hindsight, we can now see that unicast has been the success story of the Internet. Trillions of unicast packets now move around the world daily. By contrast, the non-unicast addresses are seldom used. The use of routable broadcast packets in denial of service attacks has now limited broadcast packets to local-area networks, and to critical but highly-specialized protocol functions such as DHCP, routing updates, or neighbor discovery. Wide-area multicast packets had a brief research heyday, but never reached critical mass. Today, the overwhelming majority of multiply-replicated media streams (such as popular songs and videos, television programs, conference calls, and video meetings) are carried in unicast packets mediated by application-level replication rather than IP-protocol-level multicasting or broadcasting. The Internet became a rapid worldwide success. Partly due to the reduction in experimentation that accompanied that success, little effort has been paid to looking back at the historical allocations of reserved addresses. The success of unicast traffic has led to a huge demand for unicast addresses. By contrast, there is far more supply of reserved, ignored, loopback, and multicast addresses than any foreseeable IPv4 Internet will demand. Most of these historical accidents were not carried forward into the IPv6 protocol. We propose simple, compatible changes to existing IPv4 implementations that will increase the supply of unicast addresses by redesignating addresses that today are almost completely unused on the Internet. The best and easiest "future use" of many of today's formerly reserved IPv4 addresses is as ordinary unicast addresses.

Reserved IPv4 Addresses in the RFC Series The Assigned Numbers RFC series reserved various IP addresses or assigned them special meanings, starting in 1977 and continuing through the early 1990s. The detailed behavioral requirements for IPv4 implementations based on these designations are set out in October 1989's RFC 1122. As other special cases continued to be introduced on occasion, RFC 3232 announced that IANA would track such information in an online database; the present-day version of this mechanism is the IPv4 Special-Purpose Address Registry, as provided for by RFC 6890. A wide range of host and network software follows these designations by treating these Internet addresses specially. This document is concerned with the largest special case in RFC 1122: the designation of an entire /4 block for Future Use. In retrospect, the flexibility offered by keeping these addresses unused was insightful for its time, but since they ended up never being needed for any special purposes, they have become the least productive portion of the Internet address space. The largest block of original addresses reserved for future use in 1983 was called "Class D" in RFC 870, and contained what would now be called 224/3. This contained about 536 million addresses, about 12.5% of the total available address space. By 1986, RFC 988 split the former Class D in half, designating a multicast Class D block, now called 224/4, and a future-use Class E block, now called 240/4. Following the 1993 implementation of CIDR and its 2006 clarification, we no longer speak of any IPv4 address as having an "address class," but the reservations of these specific addresses that were made by RFC 1122, were unaffected by the CIDR change in terminology and routing technology.

Attempts to Use the "Future Use" Addresses Through the 1980s, there were many reasons to suppose that new forms of Internet addressing could emerge, so reserving a substantial number of addresses for them was prudent. One likely candidate for some time was protocol translation methods between IP and other protocols using special surrogate IP addresses. This possibility was particularly significant during the time frame when IP coexisted widely on heterogeneous networks with other protocols. Special number ranges could have been used to facilitate interoperability, protocol translation, or encapsulation between IP and non-IP protocols. This prospect received new salience with the adoption of IPv6, where some deployed or proposed transition mechanisms use special-purpose IPv4 addresses with a distinctive meaning in the context of IPv6 transition, such as NAT64 and the deprecated 6to4. While IPv6 transition mechanisms could conceivably have used portions of 240/4, they ended up instead using very small amounts of special address space from the IETF Protocol Assignments block 192.0.0.0/24 or elsewhere within the unicast space. Another form of addressing that was novel in 1989 is anycast addressing, in which the same address is used to identify servers at physically distinct locations and connected to the Internet at different points. It would have been possible to designate a new "class" of addresses for anycast operations. RFC 1546, which first defined anycast, concluded that this would be a possible and even desirable approach:

There appear to be a number of ways to support anycast addresses, some of which use small pieces of the existing address space, others of which require that a special class of IP addresses be assigned. [...] In the balance it seems wiser to use a separate class of addresses.

But anycast services turned out to work fine in most respects by using existing unicast routing protocols, existing unicast datagram delivery protocols, and ordinary unicast addresses. They are now widely used for specific applications such as the Internet's root nameservers.

Recent Use as Ordinary Unicast Addresses Overall, 30 years of experience have demonstrated that no new addressing mechanism requires the use of 240/4; nor is any likely to require it in the future, particularly in light of the IPv6 transition. Other explicit reservations such as the IETF Protocol Assignments block at 192.0.0.0/24 have been sufficient. While it was reasonable to plan for an unknown future, the reserved block at 240/4 did not ultimately aid Internet innovation or functionality. The future has arrived, and it wants IPv4 unicast addresses far more than it wants permanently unusable IPv4 addresses. The idea of making 240/4 addresses available for unicast addressing is not new. It was suggested by Lear on the influential TCP-IP mailing list in 1988 . It was formally proposed to IETF more than a decade ago, both by Fuller, Lear, and Mayer, and by Wilson, Michaelson, and Huston. While the idea of unicast use of 240/4 was merely being considered at IETF, the "running code" required was simple enough and compatible enough that this behavior change was implemented at that time in several operating systems. Then, when the protocol change was ultimately not standardized, those implementations remained, but were largely forgotten. (They are summarized in the "Implementation Status" section of this document.) The unicast support created in about 2008 in those implementations is now running in millions of nodes on the Internet, and has not caused any problems over the past decade. As a result, the 240/4 space has been attracting "wildcat" use in private networks; see . Although software support for unicast use of 240/4 is widespread, it is not yet universal. The present document moves this process further along by confirming the consensus that unicast is the preferred use for 240/4, documenting the exact behavior changes required for maximum interoperability, and calling on all vendors and implementers to adopt this behavior. Doing so will prepare for a future in which use of these addresses is anticipated and unsurprising, so that their allocation can be considered. Implementations generally treat public and private addresses identically, with the differences occurring only in how routes, firewalls, and DNS servers are configured. The earlier draft suggested designating the unreserved 240/4 range as -style private address space. Like the draft, this document does not attempt to decide or designate whether future allocations from this address range will be public or private addresses. Both options require that both hosts and routers be able to use these addresses, so the next section fully defines both host and router behavior.

Change in Status of 240/4 The purpose of this document is to make addresses in the range 240/4 available for active unicast use on the public Internet. This includes supporting them for numbering and addressing networks and hosts, like any other unicast address. Host and router software SHOULD treat addresses in the 240/4 range in the same way that they would treat other unicast IPv4 addresses. Software SHOULD be capable of accepting datagrams from, and generating datagrams to, addresses within this range. Clients for autoconfiguration mechanisms such as DHCP SHOULD accept a lease or assignment of an address within 240/4 whenever the underlying operating system is capable of accepting it. Other interoperability details related to address-based filtering are discussed in a separate section, below.

Continued Special Treatment for 255.255.255.255/32 The address 255.255.255.255/32 was given a special meaning as a local segment limited broadcast address by numerous prior Internet standards, starting with RFC 919 and continuing consistently up to the present day. For example, 255.255.255.255 is used as a network-layer destination address in BOOTP and DHCP for address autoconfiguration broadcasts by hosts that don't yet know anything about the networks to which they are connected. While some newer autoconfiguration or autodiscovery protocols use other addresses, the use of 255.255.255.255 remains widespread. The special meaning of 255.255.255.255 was never restricted or affected by the reservation of 240/4. Accordingly, the existing distinctive meaning of 255.255.255.255 is unchanged by this document. This single address MUST NOT be assigned to an individual host, or interpreted as the address of an individual host, even if it would otherwise be part of an allocated or announced network block.

Compatibility and Interoperability Merely implementing unicast treatment of addresses in 240/4 in routers and operating systems, as this document proposes, does not cause any compatibility nor interoperability issues. Hundreds of millions of IPv4 nodes currently contain this unicast treatment, and all are interoperating successfully with each other and with non-updated nodes. Compatibility and interoperability issues only arise if and when an address from 240/4 is assigned to an interface on a node, and then IPv4 packets are exchanged which use such an address as a source or destination address. This document does not recommend doing these things, except for testing purposes. Older Internet standards counseled implementations in varying ways to reject packets from, and not to generate packets to, addresses within 240/4. RFC 1122, section 3.2.1.3, states that a "host MUST silently discard an incoming datagram containing an IP source address that is invalid by the rules of this section." The same section states that Class E addresses are "reserved" (which might be taken, in context, to imply that they are "invalid"); the section further treats Class A, B, and C as the only possibly relevant address ranges for unicast addressing. RFC1812, section 5.3.7, states that a "router SHOULD NOT forward" a packet with such a destination address. (If section 4.2.2.11's reference to these addresses as "reserved" is taken to imply that they are "special," section 5.3.7 would also imply that a "router SHOULD NOT forward" a packet with such a source address.) RFC 3704 (BCP 84) cites RFC 2827 (BCP 38) in asking providers to filter based on source address:

RFC 2827 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, 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.

In this context, RFC 3704 specifies filtering of these addresses as source (not destination) addresses at a network ingress point as a countermeasure against forged source addresses, limiting forwarded packets' source addresses to only the set which have been actually assigned to the customer's network. The RFC's mention of these "Martian Addresses" is based on the assumption that they could never be legitimately in use by the customer network. Because the 240/4 address space is no longer reserved as a whole, an address within this space is no longer inherently a "Martian" address. Both hosts and routers MUST NOT hard-code a policy of always rejecting such addresses. Hosts and routers SHOULD NOT be configured to apply Martian address filtering to any packet solely on the basis of its reference to a source (or destination) address in 240/4. Maintainers of lists of "Martian addresses" MUST NOT designate addresses from this range as "Martian". As noted elsewhere, the address 255.255.255.255 retains its special meaning, but is also not a "Martian" address. The filtering recommended by RFC 3704 is designed for border routers, not for hosts. To the extent that an ISP had allocated an address range from within 240/4 to its customer, RFC 3704 would already not require packets with those source addresses to be filtered out by the ISP's border router. Since deployed implementations' willingness to accept 240/4 addresses as valid unicast addresses varies, a host to which an address from this range has been assigned may also have a varying ability to communicate with other hosts. Such a host might be inaccessible by some devices either on its local network segment or elsewhere on the Internet, due to a combination of host software limitations or reachability limitations in the network. IPv4 unicast interoperability with 240/4 can be expected to improve over time following the publication of this document. Before or after allocations are eventually made within this range, "debogonization" efforts for allocated ranges can improve reachability to the whole address block. Similar efforts have already been done by Cloudflare on 1.1.1.1, and by RIPE Labs on 1/8, 2a10::/12, and 128.0/16. The Internet community can use network probing with any of several measurement-oriented platforms to investigate how usable these addresses are at any particular point in time, as well as to localize medium-to-large-scale routing problems. (Examples are described in , , and .) Any network operator to whom such addresses are made available by a future allocation will have to examine the situation in detail to determine how well its interoperability requirements will be met.

IANA Considerations This memo unreserves the address block 240/4. It therefore requests IANA to update the IANA Special-Purpose Address Registry by removing the entry for 240/4, whose existing authority is RFC 1122, Section 4. Additionally, it requests IANA to update the IANA IPv4 Address Space Registry by changing the status of each /8 entry from 240/8 through 255/8 from "Future Use, 1981-09, RESERVED" to "Unallocated, [Date of this RFC], UNALLOCATED". Finally, IANA is requested to prepare for this address space to be addressed in the reverse DNS space in in-addr.arpa. This memo does not effect a registration, transfer, allocation, or authorization for use of these addresses by any specific entity. This memo's scope is to require IPv4 software implementations to support the ordinary unicast use of addresses in the newly unallocated range 240.0.0.0 through 255.255.255.254. During a significant transition period, it would only be prudent for the global Internet to use those addresses for experimental purposes such as debogonization and testing. After that transition period, a responsible entity such as IETF or IANA could later consider whether, how and when to allocate those addresses to entities or to other protocol functions such as private addresses.

Security Considerations The change specified by this document could create a period of ambiguity about historical and future interpretations of the meaning of host and network addresses in 240/4. Some networks and hosts currently discard all IPv4 packets bearing these addresses, pursuant to statements in prior standards that packets containing these addresses have no agreed-upon meaning. Such implementations have protected themselves from possible incompatible future packet formats that might have eventually used these addresses. Disparate filtering processes and rules, both at present, and in response to the adoption of this document, could make it easier for rogue network operators to hijack or spoof portions of this address space in order to send malicious traffic. Live traffic, accepted and processed by other devices, may legitimately originate from these addresses in the future. Network operators, firewalls, and intrusion-detection systems may need to take account of this change in various regards, to avoid permitting either more or less traffic from such addresses than they expected. Automated systems generating reports, and human beings reading those reports, SHOULD NOT assume that the use of a 240/4 source address indicates spoofing, an attack, or a new incompatible packet format. At the same time, they SHOULD NOT assume that the use of 240/4 is impossible or will be precluded by other systems' behavior. An important concern about the and drafts was that discrepant behavior between systems could create security problems, as when a middlebox fails to detect or report an attack or policy violation because it believes that an address involved cannot be used or cannot be relevant. Similarly, a logging system could fail to log traffic related to 240/4 addresses because it incorporates an assumption that no such traffic can ever occur. Such discrepancies between multiple systems' views of communication semantics are a common security antipattern. (Compare , exploiting discrepancies in telephony equipment's recognition and interpretation of DTMF signals.) Any change to the meaning or status of a group of addresses can introduce such a discrepancy. In this case, because 240/4 is already commonly supported by several widely-used implementations, and is already used for private network communications, such discrepancies are already a reality. If routers follow this document's request to cease filtering this address range, they will increase the variety of contexts in which implementations may receive ordinary unicast packets containing these addresses. (Such packets are still unlikely to arrive from distant hosts until some of these addresses are eventually allocated for experimental or production use, and until the global routing table receives announcements for subnets in this range.) The adoption of this document will converge on an explicitly shared understanding that implementations should prepare for this possibility. Since unofficial private use of 240/4 addresses is a reality today, while any public allocations from this range are still distant and contingent on further study, implementers are receiving considerable advance notice of this issue.

Existing Unofficial Uses of 240/4 Some organizations are using portions of 240/4 internally as RFC 1918-type private-use address space, for example for internal communications within datacenters. RIPE's ATLAS project experimentally detected the use of this address space in several large institutions in 2022. Amazon subsequently described its internal use of 240/4 at the NANOG88 conference in 2023. As an Amazon engineer explained:

[A]long the way, we actually ran out of RFC 1918, 3330, every piece of address space out there, so we did something that some people have noticed. [...] Some of those hops have class E addresses. Yeah, we did do that. We started numbering things out of Class E. Now that was very kind of deliberate in terms of doing that. We had no address space left.

Google has informally advised hosting customers for several years that they may use this address space this way, and in September 2024 made that advice more explicit, saying that customers

can use [240/4] for private use within Google Cloud VPCs, for both Compute Engine instances or Kubernetes pods/services in GKE. [...] [These] addresses offer a significantly larger pool of IP addresses compared to traditional RFC 1918 private addresses [...]

and providing technical details about how to do so, including some information about vendor support. The same document notes that Google cloud customer Snap Inc.'s use of 240/4 addresses

mitigated IP exhaustion and provided Snap with multiple years of IP address scale needed to support future growth and reduce operational overhead. In addition, this approach also aligned with Snap’s long-term strategy for migrating to IPv6.

A Snap engineering manager is quoted as saying that these address resources "doubled [Snap's] IP capacity [...] and eliminated address exhaustion and subnet management issues". These organizations' use of 240/4 address space provides further demonstration that this address space can actually be used in practice by many devices and operating systems today, but it also represents a failure to coordinate this use with the global Internet community. That failure may be harmful in the future. For instance, Google predicts that "adoption [of 240/4 addressing] is expected to grow as the need for more IP addresses increases", but now encourages customers to use them privately for internal data center communication without coordination, and confirms that large customers are already doing so as of 2024. Coordination could make it more likely that some or all of this address space can be used for interdomain or global communications in the future without renumbering. Future allocations of 240/4 could result in use of this space on the public Internet in ways that overlap these unofficial private-use addresses, creating ambiguity about whether a particular host intended to use such an address to refer to a private or public network. Among other unintended outcomes, hosts or firewalls that have extended greater trust to other hosts based on their use of a certain unofficial network number (that was considered to imply presence on a LAN or within an organization) may eventually receive legitimate traffic from an external network to which this address space has been allocated. On the other hand, unofficial private use may reduce the ability of networks to successfully communicate with each other in the future if the global Internet community publicly allocates address blocks from 240/4 in the future. Operators of networks that are making unofficial uses of portions of 240/4 may wish to plan to discontinue these uses and renumber their internal networks, or to request that IANA formally designate certain ranges as additional Private-Use areas.

Acknowledgements This document directly builds on prior work by Dave Täht and John Gilmore as part of the IPv4 Unicast Extensions Project. We thank our late colleague Michael J. Karels (1956-2024) for his comments on this draft and related FreeBSD implementation efforts.

References Normative References Assigned numbers This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Requirements for Internet Hosts - Communication Layers This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] Requirements for IP Version 4 Routers This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] Address Allocation for Private Internets This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ingress Filtering for Multihomed Networks BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Special-Purpose IP Address Registries This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. IANA IPv4 Special-Purpose Address Registry Internet Assigned Numbers Authority Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. Informative References Signaling vulnerabilities in wiretapping systems Fixing reachability to 1.1.1.1, GLOBALLY! Cloudflare Detecting IP Address Filters APNIC 10 Years of NLNOG RING NLNOG RING RIPE Atlas RIPE Network Coordination Centre 240/4 As Seen by RIPE Atlas RIPE Network Coordination Centre Broadcasting Internet Datagrams This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Bootstrap Protocol This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Host extensions for IP multicasting This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. ICMP Router Discovery Messages This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK] Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK] Host Anycasting Service This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Dynamic Host Configuration Protocol The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] Changing the Default for Directed Broadcasts in Routers This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. An Anycast Prefix for 6to4 Relay Routers This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS-TRACK] Assigned Numbers: RFC 1700 is Replaced by an On-line Database This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community. IP Version 6 Addressing Architecture This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Architectural Considerations of IP Anycast This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. Juniper Networks JUNOS 9.6 Software Release Notes Juniper Networks JUNOS OS: Protocol-Independent Routing Properties User Guide Juniper Networks EOS 4.28.1F User Manual Arista Networks Pollution in 1/8 RIPE Labs The Debogonisation of 2a10::/12 RIPE Labs The Curious Case of 128.0/16 RIPE Labs Virtual Private Cloud: Subnets overview: Valid IPv4 ranges Google Inc. Leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE Google Google On "Reclaiming" 240.0.0.0/4 Redesignation of 240/4 from "Future Use" to "Private Use" This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use. Dive Deep on AWS Networking Infrastructure (presentation) Amazon Web Services Amazon Web Services NANOG88 Reclassifying 240/4 as usable unicast address space Cisco Systems Cisco Systems Cisco Systems This memo reclassifies the address block 240.0.0.0/4 as usable address space. While the community has not concluded whether the block should be considered public or private, given the current consumption rate, it is clear that the block should not be left unused. This document also makes several recommendations on ways that current implementations of the IP protocol stack will need to be modified to make this address space usable. Re: Running out of Internet addresses? TCP-IP mailing list

Implementation Status The IPv4 protocol update proposed by this document has already been implemented in a variety of widely-used software platforms. In many cases, implementers were persuaded of the value of the suggestions contained in and . All known TCP/IP implementations either interoperate properly with packets with sources or destinations in the 240/4 range, or ignore these packets entirely, except FreeBSD and NetBSD, which have support for 240/4 for some purposes while blocking it for others.

Operating systems 240/4 has been supported for transmitting and receiving ordinary unicast packets in Linux kernels since linux-2.6.25 was released in January 2008. Creating interfaces in the 240/4 range also worked fine using the iproute2 api (as used by the "ip" command) in that release. A kernel patch that allows properly configuring interfaces in the 240/4 range using the busybox ifconfig command was released in linux-4.20 and linux-5.0 in December 2018. 240/4 as unicast was released in Fedora 9 in May 2008, and in Ubuntu 8.10 in October 2008. 240/4 has been supported as ordinary unicast in the Android mobile operating system since Android 1.5 Cupcake (April 2009, using linux-2.6.27). 240/4 has been supported as ordinary unicast in the OpenWRT router OS since OpenWRT 8.09 (September 2008, using linux-2.6.26). A December 2018 kernel patch that allows properly configuring interfaces in the 240/4 range using the ifconfig command was merged into OpenWRT 19.01, along with two other patches to netifd and bcp38 that improve support for 240/4. 240/4 has been supported as ordinary unicast in Apple's macOS (formerly OS X) operating system and iOS mobile operating system since about 2008. 240/4 has been supported as ordinary unicast in Sun's Solaris operating system since about 2008. 240/4 traffic has been partly supported in OpenBSD for many years and is substantially fully supported since OpenBSD 7.2 (released October 20, 2022). 240/4 traffic is partly supported for local interface assignment in the FreeBSD operating system. However, ICMP and packet forwarding are not supported by default. Full support for 240/4 addresses is disabled by default, but can be enabled by "sysctl net.inet.ip.allow_net240=1". This option is included in FreeBSD 14.0, released in November 2023, and was available in development versions since July 13, 2022. We have prepared a patch which enables 240/4 support this on NetBSD. It has not been merged as of December 2023. 240/4 traffic is blocked by default in all versions of the Microsoft Windows operating system. Windows will not assign an interface address in this range, if one is offered by DHCP.

Routers and Switches Unless otherwise noted, support in this section reflects interface assignment and packet-forwarding support, not BGP support, which may involve separate bogon logic. 240/4 has been tested to interoperate as ordinary unicast in 2019 in a Cisco router using IOS release-XR 6.5.2.28I, which was also released in 2019. Older and newer releases are also likely to work. Cisco also has two other router OS variants which have not been tested. 240/4 traffic is blocked by default in Juniper's router operating system, but can be enabled with a simple configuration switch, starting from the JUNOS 9.6 release in June 2010. See page 50 of . It notes, "The JUNOS Software now allows Class E addresses to be configured on interfaces. To allow Class E addresses to be configured on interfaces, remove the Class E prefix from the list of martian addresses by including the [edit routing-options martians 240/4 orlonger allow] configuration statement." See also chapter 5, "Martian Addresses" on page 129 through 136 of the 2022 documentation . It includes a completely worked example on "Removing the Class E Prefix on Martian Addresses". Arista switches running EOS 4.25.2F (from February 2021), and later releases, include the command "ipv4 routable 240.0.0.0/4" which enables the use of 240/4 addresses on interfaces and in packet routing. The default is to disable this ability. The Belkin AX3200 router (with firmware 1.0.01 build 101415 Oct 14, 2020) cannot use addresses from 240/4 locally, but is happy to route packets to such addresses elsewhere in the Internet. A 2024 presentation by Ben Cartwright-Cox reported on his experiments on support for 240/4 in several router environments (including BGP). According to Cartwright-Cox, RouterOS 7.7 and IOS XR fully support 240/4. Arista(v)EOS 4.29.0.2F allows opting in to 240/4 support and is believed to work when this is enabled, although it could not be fully tested in Cartwright-Cox's virtualized environment. JunOS 22.X similarly allows opting in to 240/4 support, and can properly use and route addresses in this range statically and dynamically, although its built-in DHCP server is not willing to assign them to other devices on a locally attached network. Finally, EXOS 31.1.1.6-1, IOS XE, Nokia SR-OS, and Huawei VRP generally did not support using or routing 240/4, while the latter three exhibited an apparent bug in which they would ostensibly accept dynamic routes within 240/4 but not actually apply these into the RIB or FIB. Huawei VRP 5.160 (released 2014) does not allow addresses from the 240/4 range to be manually applied to a router interface.

DHCP implementations Support for 240/4 addressing may be typical of many DHCP implementations (because the 240/4 address assignment special case has often been handled at the kernel level). If the underlying operating system supports 240/4 assignment to an interface, the final official ISC DHCP release (4.4.3) supports 240/4 allocation as both client and server, as do Busybox DHCP udhcpc/udhcpd (release 1.1.15), and ISC Kea (which currently includes only a DHCP server implementation).

Other implementations Routing of subnets in the 240/4 range is fully supported by the Babel routing protocol and by its main implementation, as of 2020 (or earlier). Routing of subnets in the 240/4 range is supported by the Gobgp routing daemon, as of release 3.0.0 in 2022-03 (or earlier). Routing of subnets in the 240/4 range is supported by the BIRD routing daemon, as of release 2.0.10 in 2022-06.

Internet of Things Popular embedded Internet-of-Things environments such as RIOT and FreeRTOS already support 240/4 as unicast.