The IPv6 Loopback Address Prefix
draft-ietf-6man-loopback-01

6MAN                                                           G. Huston
Internet-Draft                                                     APNIC
Updates: 4291, 4007 (if approved)                              W. Kumari
Intended status: Standards Track                            Google, Inc.
Expires: 12 April 2027                                    9 October 2026

                    The IPv6 Loopback Address Prefix
                      draft-ietf-6man-loopback-01

Abstract

   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

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://wkumari.github.io/draft-kumari-ipv6-loopback/draft-ietf-6man-
   loopback.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-6man-loopback/.

   Source for this draft and an issue tracker can be found at
   https://github.com/wkumari/draft-kumari-ipv6-loopback.

Status of This Memo

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

Huston & Kumari           Expires 12 April 2027                 [Page 1]
Internet-Draft            IPv6 Loopback Prefix              October 2026

   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/.

   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 12 April 2027.

Copyright Notice

   Copyright (c) 2026 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  The Need for Expanded Host-Internal Space . . . . . . . .   3
     1.2.  Terminology and Functional Semantics  . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Loopback address background . . . . . . . . . . . . . . . . .   4
   4.  The IPv6 Loopback / Node-Local Unicast Prefix . . . . . . . .   5
     4.1.  Update to RFC 4291  . . . . . . . . . . . . . . . . . . .   5
     4.2.  Update to RFC 4007 (IPv6 Scoped Address Architecture) . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Huston & Kumari           Expires 12 April 2027                 [Page 2]
Internet-Draft            IPv6 Loopback Prefix              October 2026

1.  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.

1.1.  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.

Huston & Kumari           Expires 12 April 2027                 [Page 3]
Internet-Draft            IPv6 Loopback Prefix              October 2026

1.2.  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).

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Loopback address background

   The IPv4 network 127.0.0.0/8 was reserved by the IANA in [RFC791]
   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.  [RFC990] 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
   [RFC1122].

Huston & Kumari           Expires 12 April 2027                 [Page 4]
Internet-Draft            IPv6 Loopback Prefix              October 2026

   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.

   [RFC1884], 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 ([RFC2373], [RFC3513], [RFC4291]).

   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.

4.  The IPv6 Loopback / Node-Local Unicast Prefix

   The IANA IPv6 Address registry denotes the address prefix ::/8 as
   being reserved by the IETF in [RFC3513] [RFC4291].  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.

4.1.  Update to RFC 4291

   This RFC replaces section 2.5.3 of [RFC4291] 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.

Huston & Kumari           Expires 12 April 2027                 [Page 5]
Internet-Draft            IPv6 Loopback Prefix              October 2026

      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.

4.2.  Update to RFC 4007 (IPv6 Scoped Address Architecture)

   Section 11.1 of [RFC4007] ("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 [RFC4007] 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.

5.  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.

6.  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.

Huston & Kumari           Expires 12 April 2027                 [Page 6]
Internet-Draft            IPv6 Loopback Prefix              October 2026

   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.

7.  References

7.1.  Normative References

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

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              DOI 10.17487/RFC4007, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4007>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/rfc/rfc4291>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

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

   [RFC990]   Reynolds, J. and J. Postel, "Assigned numbers", RFC 990,
              DOI 10.17487/RFC990, November 1986,
              <https://www.rfc-editor.org/rfc/rfc990>.

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

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

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
              <https://www.rfc-editor.org/rfc/rfc2373>.

Huston & Kumari           Expires 12 April 2027                 [Page 7]
Internet-Draft            IPv6 Loopback Prefix              October 2026

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513,
              DOI 10.17487/RFC3513, April 2003,
              <https://www.rfc-editor.org/rfc/rfc3513>.

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 :-)

Authors' Addresses

   Geoff Huston
   APNIC
   Email: gih@apnic.net

   W. Kumari
   Google, Inc.
   Email: warren@kumari.net

Huston & Kumari           Expires 12 April 2027                 [Page 8]