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

[Maciej Żenczykowski <[e-mail]>]

also put link local in dns...

On Thu, Feb 12, 2026 at 5:54 PM Brian E Carpenter
<[e-mail]> wrote:
>
> Mark,
>
> > Support for specifying LLA zone IDs/interface IDs may also not be available in applications
>
> More accurately, the support may also be either not available or available but broken. This is an area where Linux is actually inferior to Windows.
>
> This of course is why the treatment at https://wicg.github.io/local-network-access/#ip-address-space-section is incomplete, why all browsers mess up one way or another with link-local addresses, and why RFC 9844 is the way it is. It's best to steer clear of them except for their quite narrow intended purpose.
>
> Regards/Ngā mihi
>     Brian Carpenter
>
> On 13-Feb-26 13:13, Mark Smith wrote:
> > Hi,
> >
> > On Thu, 12 Feb 2026, 00:06 Arseny Maslennikov, <ar=[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     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/ <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.
> >
> >
> > The fundamental drawback of using link-locals as loopback addresses is that they always (going by the specs) require a zone id (commonly an interface I'd) to disambiguate one interface's link local prefix from another.
> >
> >   (Linux seems to allow you to not specify a LLA zone ID sometimes, I think it might be resorting to the default route to identity the interface to use. Of course, a loopback interface is probably never a default route interface, so you'll always have to specify a zone ID/interface ID to use an LLA address as a loopback address on Linux.)
> >
> > This is not the common case when using IPv6 addresses directly, the unique subnet and prefix information in an IPv6 address is what normally identifies an interface to use to reach an address, loopback address or otherwise. (Near globally unique link-local addresses anybody? That's how we effectively got rid of zone IDs from site-local addresses, resulting in unique local addresses.)
> >
> > Support for specifying LLA zone IDs/interface IDs may also not be available in applications also because specifying them is not the common case.
> >
> > Regards,
> > Mark.
> >
> >
> >     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
> >
> >     _______________________________________________
> >     v6ops mailing list -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------

--
Maciej Żenczykowski, Kernel Networking Developer @ Google