]> APNIC

gih@apnic.net

Google, Inc.

warren@kumari.net

Internet 6MAN IPv6 Loopback Node-Local Unicast Documentation This document updates the IP Version 6 Address Architecture to expand the size of the IPv6 loopback space from a single address to a /48 prefix, formally defined as Node-Local Unicast space. This change allows for a much larger number of loopback addresses and internal virtual networks within an IPv6 host, which can be used for inter-process communication, local virtualization, container networking, and diagnostics. This document updates RFC 4291 to define the prefix and its functional semantics, and updates RFC 4007 to specify how the prefix is integrated into the scoped address architecture. It also updates the IANA IPv6 Address registry, the IPv6 Special-Purpose Address registry, and the Locally-Served DNS Zone Registry. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction In the IPv4 addressing architecture, the entire 127.0.0.0/8 block is reserved for loopback routing purposes. This generous allocation allows developers and system administrators to utilize over 16 million distinct host-internal addresses. While historically viewed as a byproduct of classful network design, this large local address space has become fundamental to modern network operations, enabling complex local testing, containerization, and inter-process communication without port exhaustion. By contrast, the IPv6 Addressing Architecture allocates only a single address, ::1/128, for local loopback. While sufficient for basic localhost identification, this strict limitation creates significant operational friction in modern IPv6-only and dual-stack environments.

The Need for Expanded Host-Internal Space As application architectures have evolved, the restriction of a single IPv6 loopback address has become a tangible bottleneck. Below are some examples of use cases which would benefit from an expanded loopback space:

• Application Testing and Containerization: Developers frequently run multiple instances of a service locally. In IPv4, these instances can bind to the same port on different 127.x.x.x addresses. In IPv6, developers are forced to modify application port numbers, which breaks environment parity and complicates test scaffolding.
• Local Virtual Networks and Container Routing: Modern containerized runtimes and microservice setups require running multiple virtual network segments within a single machine. Utilizing a /48 prefix enables the creation of multiple internal subnetworks and simulated network topologies completely within a single physical node.
• Local Proxying and Service Meshes: Complex local routing paradigms (such as sidecar proxies) often require distinct IP assignments to securely isolate and route traffic locally without exposing services to the external network.
• Controlled Interruption and Name Collisions: Global infrastructure services occasionally rely on localized sinkholes to safely manage deprecation or name collisions. For example, ICANN has historically utilized 127.0.53.53 for name collision controlled interruption. Replicating this fail-safe behavior in IPv6 requires a dedicated, local-only prefix.

Terminology and Functional Semantics While historically referred to as "loopback" space, the functional requirement described in this document is a dedicated address block for host-internal virtual interfaces, referred to here as a Node-Local Unicast Prefix. The core semantic of this proposed space is strict isolation. Implementations MUST ensure that:

• Addresses from this block can be assigned to multiple internal virtual interfaces and virtual bridge networks simultaneously.
• Packets with a source or destination address drawn from this block MUST NOT be forwarded to any physical network interface.
• These packets MUST never be routed off the local host. If a router or switch receives a packet on a physical interface bearing one of these addresses, the packet MUST be dropped.

To support these operational realities, this document requests the allocation of a new, dedicated IPv6 prefix (e.g., a /48 drawn from the IANA IPv6 Special-Purpose Address Registry) to serve as expanded Node-Local Unicast space. This block will operate with the same fundamental constraints as the primary ::1/128 loopback address, without overlapping with the Unspecified Address (::/128).

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Loopback address background The IPv4 network 127.0.0.0/8 was reserved by the IANA in where the class-based address architecture was described. It is understood that it was the IANA's policy at the time to reserve the first and last network of each class, and the address prefixes 0.0.0.0/8 and 127.0.0.0/8 from the Class A space were reserved in accordance with this practice. listed the 127.0.0.0/8 address prefix as being used by the loopback function, and this function was listed as a requirement for all Internet hosts in . The "loopback" function is defined such that an outbound packet whose destination address triggers this loopback function should loop the packet back to the packet ingress queue for processing by the same host. No packet that is addressed to a loopback address should ever be passed to any physical network. , the original IPv6 Addressing Architecture document, allocates a single local loopback address, ::1. This single address allocation has been preserved in all subsequent revisions to the IPv6 addressing specification (, , ). Loopback addresses enable localhost communication, network diagnostics, and inter-process connections, making them essential for various local functions. Multiple loopback addresses can increase the number of distinct sockets that can be used for inter-process communication within a host. A larger Node-Local Unicast prefix in IPv6 can permit large numbers of distinct concurrent loopback TCP connections and complete virtualized subnets within a single host, which is comparable to and extends the functionality supported by the IPv4 loopback address prefix.

The IPv6 Loopback / Node-Local Unicast Prefix The IANA IPv6 Address registry denotes the address prefix ::/8 as being reserved by the IETF in . This range of addresses has been partially allocated with the prefix ::FFFF:0:0/96 being used in the context of an IPv6 transition technology to map IPv4 addresses into IPv6 addresses. This document expands the set of IPv6 loopback addresses by adding an additional Node-Local Unicast prefix: TBD/48.

Update to RFC 4291 This RFC replaces section 2.5.3 of as follows:

• The unicast addresses 0:0:0:0:0:0:0:1 and the prefix TBD/48 are defined for loopback and node-local unicast functions. These may be used by a node to send IPv6 packets to itself, or to communicate across local virtual interfaces within the same host. They must not be assigned to any physical interface. They are treated as having Link-Local scope, and may be thought of as the Link-Local unicast addresses of a virtual interface (typically called the "loopback interface" or local virtual bridges) to an imaginary link that goes nowhere.

• The loopback address and addresses within the TBD/48 prefix must not be used as the source address in IPv6 packets that are sent outside of a single node. An IPv6 packet with a destination address in this prefix must never be sent outside of a single node and must never be forwarded by an IPv6 router. A packet received on an interface with a destination address of loopback or within the TBD/48 prefix must be dropped.

Update to RFC 4007 (IPv6 Scoped Address Architecture) Section 11.1 of ("Non-Global Addresses") specifies the zone-id treatment of scoped addresses. It explicitly dictates that the loopback address ::1 does not require and must not be qualified with a zone identifier. This document updates Section 11.1 of to extend this rule to the entire Node-Local Unicast prefix (TBD/48). Because addresses drawn from the TBD/48 prefix are strictly host-internal and do not associate with physical links, they MUST NOT be qualified with a zone identifier in user interfaces or socket APIs. Node implementations MUST treat the entire TBD/48 prefix as belonging to the default node-local loopback zone.

Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. However, system implementations MUST ensure strict isolation. Packets containing destination or source addresses from the TBD/48 block MUST be dropped if they appear on physical media, preventing leakage of host-internal IPC or virtual network communications to the public Internet, and mitigating any potential external spoofing or scanning vectors.

IANA Considerations The IANA is requested to assign a new IPv6 address prefix, TBD/48, to be used for the loopback and node-local unicast functions as described in this document. This prefix should be allocated from the IANA IPv6 Special-Purpose Address registry. The IANA is requested to amend the IPv6 Address registry and the IPv6 Special Purpose Address registry to record the designation of this address prefix. The IANA is also requested to add an entry to the IPv6 Locally-Served DNS Zone Registry for the new prefix, TBD/48, to ensure that reverse DNS lookups for addresses within this prefix are properly handled.

References Normative References 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] This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK] 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. 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] This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK] 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. [STANDARDS-TRACK]

Acknowledgments The authors would like to thank Alejandro Acosta, Brian Carpenter, Antonis Chariton, Owen DeLong, Gert Doering, Jeremy Duncan, Lorenzo Colitti, David Farmer, Steinar Haug, Gábor Lencse, Michael Richardson, Terry Sweetser, Ole Trøan, and Maciej Żenczykowski for their comments, discussions, and suggestions on this topic. Additional thanks to John Heasley for submitting Pull Requests. In addition we would like to thank Jen Linkova for presenting the proposal at IETF 125, as the authors were participating in other sessions at the time. We would also like to specifically thank Mark Smith for an earlier (2013) effort: draft-smith-v6ops-larger-ipv6-loopback-prefix-04, which proposed a /32 designation. The need for a loopback address prefix has long been a topic of discussion in various forums, and we would like to acknowledge the contributions of many individuals who have participated in these discussions over the years. Unfortunately, at least one of the authors has a terrible memory, and has lost track of all those who have contributed to this topic over the years, and will be more than happy to acknowledge their input if reminded of this :-)