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

[Antonis Chariton <[e-mail]>]

> On 25 Nov 2025, at 21:17, Brian E Carpenter <[e-mail]> wrote:
> 
> By the way, there is a difference between IPv4 and IPv6 that the draft doesn't mention. IPv4 addresses are assigned to the host. IPv6 addresses are assigned to a specific interface. There's a virtual loopback interface in IPv6 implementations, which presumably will "own" the whole proposed /96. That should be mentioned.
> 
> On 26-Nov-25 06:38, Warren Kumari wrote:
>> 
>> 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.


Thanks to the generosity and plentifulness of IPv4 addresses we also have > 16M more loopbacks at ::ffff:127.0.0.0/104 ! If anything IPv6 has more loopback addresses!

I’m only kidding of course but I support the effort of adding more than one loopback addresses as this is one of the points I had issues with in IPv6 adoption as well. I think there is a need, we certainly have the addresses for it, however I’d like to see this be clarified better for the application side.

As the main consumer of this document will likely be application developers, and we’ll need their adoption of IPv6 in their software, we have to find something that works out for them, including in a system of multiple loopbacks. I think ::1234%lo2 is a bit scary and not great user experience. Loopback interfaces aren’t even named the same in every OS.

Leaving it up to the vendor to decide how to split the /96 is also not great as the developers (like docker, systemd, etc.) usually hardcode things and they expect them to work universally. They will constrain themselves to the minimum viable range of addresses any system is guaranteed to have which is brittle and can change over time. This is a problem we’ll already face adding this extra range so late, but it’s better than never.

I don’t have a great idea that works with everything, but perhaps we can find something in the conversation here.

Thanks for taking the time to send this draft!

Antonis