Unicast Use of the Formerly Reserved 0/8

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 allow the use of more than 16 million historically reserved addresses at the bottom of the IPv4 address space. This document provides history and rationale to change the status of the "0/8" or "zeroth" region of the IPv4 address space (historically known as "unspecified network" or "this network") from reserved to unreserved. These addresses are already usable for unicast traffic in some popular TCP/IP 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 The early Internet reserved many kinds of IPv4 addresses for special purposes. One important such designation involves every IPv4 address beginning with the octet 0 (now "0/8"); all these addresses were designated for use in potential device autoconfiguration features that were to use ICMP messages. This function was eventually entirely supplanted by other protocols, which, in IPv4, now use only the single address 0.0.0.0. Autodiscovery of a network-provided configuration came to be handled for IPv4 by DHCP, and formerly by its predecessors BOOTP and RARP. In modern practice, the source address of a device seeking an IPv4 configuration from the local network is indicated with a link-layer broadcast in which the network-layer source address 0.0.0.0 and the network-layer destination address is 255.255.255.255. The reservation of 0/8, despite its obsolescence, has been reiterated in all subsequent IPv4 address allocation RFCs and IANA documents. By 1989, , section 3.2.2.7, for example, noted that this mechanism was already obsolete, even as section 3.2.1.3 continued to expressly prohibit the use of network number 0 for other purposes. The single special address 0.0.0.0(/32) acquired a variety of related meanings including "unspecified address", "unknown address", "address not set", "address not applicable", etc., while 0.0.0.0/0 means "the default route", which contains every IPv4 host. This single address has remained sufficient for these purposes.

Present situation Today, 0/8 addresses (except for the special address 0.0.0.0) are no longer used in any autoconfiguration protocols. All of this functionality is handled using other distinctly-specified mechanisms and address space, both in IPv4 and IPv6. The designation of 0/8 as reserved address space is tracked by IANA in the IPv4 Special-Purpose Address Registry, as provided for by RFC 6890. No known software makes use of this address space in the headers of IPv4 packets transmitted over the wire. While some software already treats it as a potentially valid address, the most common behavior by host and router software when encountering any address within 0/8 is to reject it as a Martian address. These and all other known uses are discussed in the sections "Other Existing Uses of 0/8" and "Compatibility and Interoperability", below. Since this address space has no existing widespread practical use or interpretation, it can be used for other purposes and help alleviate the shortage of IPv4 addresses. This memo therefore unreserves it, redesignating it as unassigned unicast addresses, available for potential global unicast or other allocation.

Change in Status of 0/8 The purpose of this document is to make addresses in the range 0/8 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. As an exception, the address 0.0.0.0 retains its existing special meanings, as described in the subsection "No Change to Interpretations of 0.0.0.0". Host and router software SHOULD treat addresses in the 0/8 range, except the host address 0.0.0.0, 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 0/8, except the host address 0.0.0.0, whenever the underlying operating system is capable of accepting it.

No Change to Interpretations of 0.0.0.0 The unqualified address 0.0.0.0 or the individual host address 0.0.0.0/32 has many special meanings which are described in a section "Other Existing Uses of 0/8", below. This document does not make this all-zero address an individually valid unicast address, and it should still not be taken to identify an individual device. As described in prior Internet standards, the address 0.0.0.0 MUST NOT be assigned to an individual interface. This address is valid to appear in both source and destination addresses, with special meanings, in protocols already defined or to be defined in the future. The network identifier 0.0.0.0/0 also continues to be used to refer to an IPv4 default route (a route which matches any Internet host). This is not inconsistent with the use of explicit routes to individual networks within 0.0.0.0/8. Existing CIDR-based routing logic is readily capable of distinguishing an object like 0.0.0.0/8 (a route referring to a specific /8 whose leftmost octet is always 0) from one like 0.0.0.0/0 (a route including to any IPv4 host); in current routing practice, the default route 0.0.0.0/0 already always overlaps every more-specific route, regardless of how many zero bits appear at the beginning of a more-specific route's destination. For avoidance of doubt, we note that all routing implementations MUST permit routes to overlap, and MUST distinguish the default route 0.0.0.0/0 from a more-specific CIDR route such as 0.0.0.0/8 or 0.0.0.0/10, as well as from a leading-zero-octet route such as 0.1.0.0/16. These distinctions are already implied by , section 3.1 (since neither "n" nor "x" is ever stated to be nonzero), and sections 5.1 and 5.2 (describing and requiring generality in the treatment of arbitrary routes, including the default route).

Other Existing Uses of 0/8 There are a handful of other uses of 0/8 with special meanings in existing Internet protocols and standards. A large number of protocols and environments use the special address 0.0.0.0 to mean "unspecified", "unknown", "unset", "not applicable", "any address", "no address", or, as 0.0.0.0/0, the default route containing every IPv4 network. (Two examples, among dozens, are 's use of 0.0.0.0 in DHCP packets to mean "my IP source address is unknown" and 's use of 0.0.0.0 to mean "proxied IGMP membership report from a non-Querier".) All these uses of the address 0.0.0.0 are unchanged by this memo. Due to its variety of special meanings, the address 0.0.0.0 MUST NOT be allocated exclusively to a specific organization or network. Existing standards significantly constrain, but do not preclude, circumstances in which it may appear on the wire. There are three known non-unicast uses of the 0/8 block as a whole in the RFC series.

RFC 3338 (an IPv6 transition mechanism) used 0/8 addresses as synthetic addresses representing surrogate IPv6 addresses, but this practice has already been deprecated by , which indicated that this transition mechanism should switch to RFC 1918 private addresses.
RFC 7453 (an MPLS-related SNMP MIB definition) overloads the meaning of addresses in 0/8 by designating them as local identifiers, contrasting with IPv4 addresses. Before production use of 0/8 on the global Internet occurs, this MIB should be updated to provide a separate field for local identifiers and to deprecate the old semantics.
RFC 6235 and RFC 8932 both provide mechanisms for anonymizing network flow datasets that can map addresses into 0/8 in order to obscure them. Implementers SHOULD take into account that source addresses in the future may already lie in this range and will still require anonymization; an IPv4 address SHOULD NOT be assumed to have been anonymized already merely because it is within 0/8.

Compatibility and Interoperability Older Internet standards counseled implementations in varying ways to reject packets from, and not to generate packets to, addresses within 0/8. Among several standards calling for this behavior, RFC 1122, section 3.2.1.3, and RFC 1812, section 4.2.2.11, say that hosts and routers, respectively, MUST NOT send packets using these addresses, outside of configuration-discovery processes. RFC 1122 implies hosts MUST discard, and RFC 1812 implies routers SHOULD NOT forward, packets whose source address is within 0/8. 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.

Other RFCs such as 3964, 4380, and 6491 have reiterated specific lists of Martian ranges for other purposes, rather than referring to the subsequently-created IANA Special-Purpose Address Registry. We encourage future RFC authors and implementers to refer to the Special-Purpose Address Registry rather than explicitly providing or using a list of reserved addresses within their documentation. 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 0/8 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 0/8. Maintainers of lists of "Martian addresses" MUST NOT designate addresses from this range as "Martian". As noted elsewhere, the address 0.0.0.0 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 0/8 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 0/8 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 0/8 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.

Unofficial uses of 0/8 Some organizations may be using portions of 0/8 internally as RFC 1918-type private-use address space, for example for internal communications within datacenters. We currently have no publicly-documented examples of this practice. However, future allocations of 0/8 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 (since the address would then have two distinct interpretations with different addressing scopes). 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. Operators of networks that are making unofficial uses of portions of 0/8 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.

IANA Considerations This memo unreserves the address block 0/8. It therefore requests IANA to update the IANA IPv4 Special-Purpose Address Registry by removing the entry for 0/8, whose existing authority is RFC 791, Section 3.2. Additionally, it requests IANA to update the IANA IPv4 Address Space Registry by changing the entry for 000/8 from "IANA - Local Identification, 1981-09, RESERVED" to "Unallocated, Former IANA - Local Identification, [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 0.0.0.1 through 0.255.255.255. During a significant transition period, it would only be prudent for the global Internet to use those addresses for experimental purposes such as de-bogonization 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.

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 0/8. 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 and ought not to be sent over the wire. Disparate filtering processes and rules 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 0/8 addresses in the future. Network operators, firewalls, and intrusion-detection systems may need to take account of this change in various regards, including so as 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 0/8 source address indicates spoofing, an attack, or a new incompatible packet format. At the same time, they SHOULD NOT assume that the use of 0/8 is impossible or will be precluded by other systems' behavior. Since the Linux kernel has already defaulted to the specified behavior for two years (see "Implementation Status"), it is already possible for deployed systems to disagree about whether packets containing 0/8 may validly appear on the wire. This document offers an opportunity to move to a new consensus in which implementations widely agree that these packets are potentially valid, while giving implementers considerable advance notice ahead of any future deployment of these addresses on the public Internet.

Acknowledgements This document directly builds on prior work by Dave Täht and John Gilmore as part of the IPv4 Unicast Extensions Project. Acknowledgements of contributions to their drafts still need to be transposed here.

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. Internet Protocol Internet Control Message Protocol A Reverse Address Resolution Protocol This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies 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. 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] 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] 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. Recommendations for DNS Privacy Service Operators This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users. This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841. MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. Dual Stack Hosts Using "Bump-in-the-API" (BIA) IP Flow Anonymization Support This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community. Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK] 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. Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community. 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 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 Pollution in 1/8 RIPE Labs The Debogonisation of 2a10::/12 RIPE Labs The Curious Case of 128.0/16 RIPE Labs

Implementation Status The behavior specified by this document has been implemented by the Linux kernel since version 5.2, released in July 2019. Accordingly, it has been included in various operating system releases, including Ubuntu 19.10 and Fedora 31 from October 2019, and some Android 11 and 12 devices. This behavior has also been implemented by the OpenBSD kernel and userspace since May 6, 2022, and hence appears in OpenBSD 7.2, released on October 20, 2022. This behavior is disabled by default in FreeBSD, but enabled by "sysctl net.inet.ip.allow_net0=1", available in FreeBSD 14.0, released in November 2023. It has been available in development releases since July 13, 2022. We have prepared a patch which enables this behavior on NetBSD. It has not been merged as of December 2023. Routing of subnets in the 0/8 range is supported by the Gobgp routing daemon, as of release 3.0.0 in March 2022 (or earlier). Support for 0/8 addressing may be typical of many DHCP implementations (because the 0/8 address assignment special case has often been handled at the kernel level). If the underlying operating system supports 0/8 assignment to an interface, the final official ISC DHCP release (4.4.3) supports 0/8 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).