[IPv6]Re: [v6ops] New draft: "The IPv6 Loopback Address Prefix"

[Arseny Maslennikov <[e-mail]>]

On Tue Nov 25, 2025 at 5:38 PM UTC, Warren Kumari wrote:
> Dear 6MAN and V6OPS,

(inline replies follow)

> Geoff Huston and I have just submitted draft-kumari-ipv6-loopback - "The
> IPv6 Loopback Address Prefix"
> <https://datatracker.ietf.org/doc/draft-kumari-ipv6-loopback/>
>
> We believe that it is within the 6MAN charter ("The 6man working group is
> responsible for the maintenance, upkeep, and advancement of the IPv6
> protocol specifications and addressing architecture."), but I have CCed
> V6OPS as well, as it is clearly operational as well.
>
> Abstract:
> "This document updates the IP Version 6 Address Architecture to define the
> IPv6 address prefix ::/32 as the Loopback address prefix."
>
> Basically, this document expands the single loopback address ::1/128 into a
> prefix.

Being late to the party I am surprised throughout the numerous mails in
this thread no one has suggested to use the link-local unicast range.
To cover use cases for additional host-local addresses, fe80::/10
coupled with a "loopback virtual interface" abstraction are sufficient
and plenty and do not deplete the address pool, and, with all due
respect, no further 6man work is needed here — we have all the tools
already.

IOW, we do not need more host-local addresses, since we can use
link-local addresses of a single host-local link, avoiding the
requirement to set up multiple loopback interfaces.

> There are a number of situations in which having more than a single address
> is helpful; an obvious example of this is Dockers/k8s use of 127.0.0.11 for
> the DNS resolver, SPAM RBL use of the last octet on 127.0.0.x to encode the
> type of SPAM. It is also relatively common it use this for inter-service
> communication in container environments.
>
> It is also a common practice to bind different services to
> different addresses in the IPv4 loopback space to allow for scaling
> (avoiding the "Port already in use" issue), testing, etc.  Yes, these can
> be somewhat emulated with ULAs and / or additional interfaces and scopes,
> but they are all more complicated, and much more likely to result in
> leakage or collision.

Binding a socket to a link-local address on a virtual host-local link
is not hard.
Since Docker and k8s were mentioned, it would not be distasteful of me
to give a Linux-specific example. The following code works on Linux
today, with a small nudge.

.. code-block:: c

  #include <netinet/in.h>

  const struct sockaddr_in6 local53 = {
          .sin6_family = AF_INET6,
          .sin6_addr.s6_addr = {
                  0xfe, 0x80, 0x0, 0x35,
                  0, 0, 0, 0,
                  0, 0, 0, 0,
                  0, 0, 0, 1,
          },
          .sin6_scope_id = 1,
          .sin6_port = 53,
  };

This makes use of the fact that the Linux kernel always sets up the
loopback interface (in each net namespace) so that it has an ifindex of 1.
A more portable way to construct such a sockaddr would be:

.. code-block:: c

  struct addrinfo * result;
  getaddrinfo("fe80:35::1%lo", "domain",
              { .ai_flags = AI_PASSIVE, .ai_socktype = SOCK_DGRAM, },
              &result);
  /* The sockaddr is at result->ai_addr, result->ai_addrlen */

The aforementioned nudge is, for the above to work, a route entry has to
be created in the system to the equivalent of::

  ip -6 r add local fe80::/10 dev lo proto kernel metric 1

This harmless action can be done at system init by default (or, with a
17-line patch to the kernel, by the kernel itself), just after ::1 is
assigned.

Yes, binding to such a sockaddr would likely require OS-specific
additional measures (e. g. setting IP_FREEBIND), just like both
127.0.0.11 and the ::1%lo2 proposal. This is no problem, since there is
no actual networking between disparate hosts, and IPv6 is used as
API/IPC within a host. Also, system software developers are already used
to this.

There were another two use cases for host-local addresses raised in this
thread: automated testing of application software and of networking
software (routing protocol impls, etc.). In case of application
software, the CI/testing environment can do whatever preparation steps
are required before running the tests, so I believe the above is
applicable here without any issues. To test networking software,
designated loopback interfaces aren't really fit (to my maybe limited
understanding), and we have the various GUA space carveouts, e. g. doc
prefixes.

As for the URI difficulties with fe80::%lo : if the sockaddr is resolved
from a name, this is not a problem at all. We are talking about
host-local communication here; no need to involve the DNS, the sockaddr
can be synthesized locally, just like "localhost" was locally resolved
to ::1 for decades. Chrome bugs are bugs of Chrome.

--
WBR,
an occasional lurker of v6ops