In this document, we address a topic that despite its simplicity reaches a surprising level of complexity: the IP loopback address prefix. We briefly examine the evolution, historical background, and context in which these addresses were defined in the past, before discussing the practical challenges that arise in today’s complex environments. We also explain a technical proposal that is being discussed at the IETF that seeks to solve an existing problem.
What is a loopback address?
A loopback address is a special IP address used to route traffic that does not leave your computer. When you direct something to a loopback address, you are essentially talking to yourself. Basically, it is a monologue within your computer. In fact, a message from your device to the loopback address never even reaches the network interface card. Loopback addresses are used by many developers and various applications (web servers, DNS, virtual machines, databases) to communicate locally.
From IPv4 to IPv6 loopback addresses – A bit of history
In 1995, when RFC 1884, the first RFC to specify the IPv6 architecture, was published, section 2.4.3 defined the IPv6 loopback address as 0:0:0:0:0:0:0:1. However, it was later clarified in RFC 2373 (IP Version 6 Addressing Architecture), which expressed it as ::1.
(Free access, no subscription required)
This means that in IPv6 only one IP address was reserved to be used for the loopback interface. In the realm of IPv4, the loopback prefix is defined as 127.0.0.0/8. This represents more than 16 million IP addresses. It’s hard to believe that in the world of IPv6, where the message has always been that there’s no need to ‘save’ IP addresses, that IP addresses are practically infinite, and that there are thousands of IP addresses per human being, a single IP address was designated for loopback (::1/128).
How did this happen?
To answer this question, we need to understand what the context looked like when the IPv6 protocol was being defined. These decisions were made in the 1990s, when the Internet was beginning to grow alongside the world of networking. Back then, not all operating systems came with TCP/IP preinstalled, virtual machines did not exist, and neither did other technologies that we now take for granted.
For many years, the only loopback address used was 127.0.0.1. When the engineers who designed IPv6 decided to create an equivalent to the IPv4 prefix, they created a single IPv6 address, the famous ::1 mentioned above. After all, why would you need more than one address in a monologue?
This means that in IPv6 only one IP address was reserved to be used for the loopback interface. In the realm of IPv4, the loopback prefix is defined as 127.0.0.0/8. This represents more than 16 million IP addresses. It’s hard to believe that in the world of IPv6, where the message has always been that there’s no need to ‘save’ IP addresses, that IP addresses are practically infinite, and that there are thousands of IP addresses per human being, a single IP address was designated for loopback (::1/128).
How did this happen?
To answer this question, we need to understand what the context looked like when the IPv6 protocol was being defined. These decisions were made in the 1990s, when the Internet was beginning to grow alongside the world of networking. Back then, not all operating systems came with TCP/IP preinstalled, virtual machines did not exist, and neither did other technologies that we now take for granted.
For many years, the only loopback address used was 127.0.0.1. When the engineers who designed IPv6 decided to create an equivalent to the IPv4 prefix, they created a single IPv6 address, the famous ::1 mentioned above. After all, why would you need more than one address in a monologue?
Why more than one loopback IP address?
For everyday use and simple scenarios, a single loopback address is more than enough. However, in virtualization environments, containers/Kubernetes, and complex networks where a single physical server must host and isolate multiple services and/or instances, many more are needed.
In practical terms, having more than one loopback address helps to better organize and separate internal tasks within a machine or server.
Additional reasons include:
Avoiding confusion between applications
Assigning each service its own “office”
IP-based security
Simulating large networks on a single machine
Improving usage and routing between containers
What does the draft propose?
In short, the Internet Draft (draft-kumari-ipv6-loopback-01), dated 16 November 2025, in its second version and authored by Geoff Huston and Warren Kumari, proposes updating the IPv6 address architecture to formally define the IPv6 address prefix ::/96 as the loopback address prefix.
The draft explicitly proposes ::/96. Would this work?
Anything is possible, but ::/96 has two conflicts with other well-known prefixes:
Conflict with the “Unspecified Address” (::/128). The ::/96 prefix necessarily includes the address ::/128 (0:0:0:0:0:0:0:0). To address this, the draft specifies that this address MUST NOT be assigned to any node, as it indicates the absence of an address.
::/96 was previously defined as the “IPv4-Compatible IPv6 address” prefix. It was deprecated by RFC 4291.
Everything has a solution
In summary, the ::/96 prefix is technically viable under this new proposal. However, it would require exception rules (implemented at the operating system level) for the unspecified address and strict delimitation to avoid interfering with IPv4/IPv6 transition technologies.
Another appealing idea
During the discussion of this document, one idea particularly caught my attention: the creation of a new type of unicast addressing. For example, a “Unicast Host Local” prefix, i.e., a prefix used only within a single “machine” that would not be sent outside from the network interface. Naturally, this isn’t as easy as it may seem: What would the machine be? What about the host? The guests? etc. Time will tell.
Conclusions
While IPv4 reserved a large block (127.0.0.0/8) with millions of addresses, IPv6 historically allocated a single address (::1), a decision that was logical in the 1990s but is now restrictive.
In the modern age of virtualization and containers, where a single server hosts multiple isolated services, the need for more than one loopback address has become critical. This has driven technical proposals and discussions in forums such as the IETF.
