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

[Brian E Carpenter <[e-mail]>]

Arseny,

I believe that your suggestion is a non-starter, as it would be very unwelcome for the Web security people.

https://wicg.github.io/local-network-access/ makes an important distinction between 'loopback' and 'local'. Please see https://wicg.github.io/local-network-access/#ip-address-space-section for details.

Regards/Ngā mihi
    Brian Carpenter

On 11-Feb-26 22:16, Arseny Maslennikov 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/>
>>
>> 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
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]