[IPv6]Re: [v6ops] Why not add loopback semantics to 2001:db8::/32?

[Mark Smith <[e-mail]>]

Hi,

On Thu, 4 Dec 2025 at 13:18, Owen DeLong <[e-mail]> wrote:
>
>
>
> > On Dec 2, 2025, at 00:09, Mark Smith <[e-mail]> wrote:
> >
> > Hi,
> >
> > So I proposed a /32 in
> > draft-smith-v6ops-larger-ipv6-loopback-prefix-04 (specifically 1::/32)
> > because it facilitates many if not all testing scenarios - support for
> > multiple loopback interfaces, with each having a /64 to be consistent
> > with /64 subnet convention, allowing e.g. RFC7217 / RFC8981 IIDs to be
> > used if useful, in addition to human convenient 1:0:0:<subnet>::1 /64
> > addresses.
>
> I’m still trying to comprehend a testing scenario that would require this where GUA or ULA wouldn’t be a better choice.

Which would you prefer to manually type say 100 times during testing:

1::1, 1:0:0:2::1, 1:0:0:34:a:b:c:d

or

fd17:bf60:0865::1, fd17:bf60:0865:2::1, fd17:bf60:0865:34:a:b:c:d

?

Entries in /etc/hosts would avoid that issue, however sometimes you
don't want name resolution involved in your testing or perhaps it
might not be available.


 Loopback semantics imply addresses that are identical across all
machines, quasi-automatically configured, and not routable outside of
host scope. This is not to be confused with virtual interface
semantics (which loopback interfaces iare frequently (ab)used for in
IPv4) where a routable address is assigned to non-physical interface
to facilitate reachability regardless of which subset of physical
interfaces remain up. (e.g. the use of configured routable “loopback”
addresses on routers to terminate iBGP sessions).
>

You're conflating the properties of a loopback IP prefix with the
possible use of a loopback interface. Loopback interfaces can be
assigned addresses from a loopback IP prefix (the use cases I'm
talking about), keeping that traffic local to the host, or they could
be assigned addresses from a GUA or ULA prefix (the latter case you're
describing) and announced into the IGP or BGP.

That's actually where I originally got the idea of using multiple
loopback interfaces from - on routers with different addresses
assigned to different loopback interfaces (Cisco support that, just
'int loopback<number>' to create, last I checked, Juniper don't
support it) - one for the iBGP sessions, one for RADIUS client, one
for L2TP tunnel end point, one to ssh to etc.

If I needed to move a function (say an L2TP tunnel end point) to a
different router I just picked up the address assigned to the function
and moved the address to a function specific loopback interface on a
different router, without disrupting any of the others e.g. iBGP
sessions etc.,  because they're using different addresses.

A unicast IP address per function or service is quite useful, and you
can easily make it an anycast function/service if you want to by
duplicating somewhere else in the network.

You can also assign DNS A, AAAA, PTR and TXT RRs to the
function/service specific addresses to document them and refer to
them.

> I remain confused as to how the former would be useful and/or how having a dedicated prefix or expanded loopback semantic addresses would facilitate the latter or, frankly, what combination of the two you’re seeking in your testing scenarios.
>
> > Geoff and Warren's alternative proposal is currently suggesting a /96.
> >
> > If a /96 ended up being the choice, then I've thought I'd use
> > 2001:db8::/32 for any host-local loopback testing, since it too would
> > satisfy the scenarios that 1::/32 would.
>
> You don’t need an RFC or an ID to do whatever you want on your own local hosts. I certainly think it would be ill advised to suggest that as common practice or condone doing so in any way, but your hosts are your hosts.
>
> > That's a questionable use of a documentation prefix, however if
> > packets too and from it didn't leak from the host, and with an
> > additional defence that they shouldn't leak from the network per the
> > filtering advice in RFC3849, then I don't think it would cause any
> > harm to use the documentation prefix this way. It would also mean that
> > any testing documentation would match what is configured on the host,
> > rather than the test prefix and documentation prefixes having to be
> > different.
>
> Isn’t the whole point of the documentation prefix to make sure that any instance where it appears in an actual machine configuration can be immediately and automatically assumed to be erroneous and should be corrected? It seems to me that you are intentionally changing that semantic in ways that I would, again, consider ill-advised.
>
> > Thinking about it a bit more, why not officially add loopback
> > semantics to the 2001:db8::/32 prefix?
>
> Because 2001:db8::/32 (and any expanded documentation prefixes) should already have “this won’t work in the wild” semantics associated with them and frankly, I’d argue that in an ideal world, machines should reject these prefixes out of hand unless overridden with some sort of “this configuration being used to produce documentation only” flag.
>
> In short, I think doing so would create unnecessary confusion while not offering any tangible benefit to the community at large.
>
> Can you elaborate on what kind of testing scenario would require 4 billion /64 loopback interfaces on a single machine?
>

I think that's basically IPv4 thinking.

IPv6 addressing is about convenience, not necessity (just like 48 bit
ethernet addresses - they too were sized for convenience, rather than
necessity, so that the factory assigned address was likely globally
unique and didn't need to be configured. See the paper "48-bit
Absolute Internet and Ethernet Host Numbers" by Yogan K. Dalal and
Robert S. Printis.)

A /48 would do. However, a /32 is 1 x 4 billionth of the IPv6 address
space. We've just allocated a /20 for documentation! Quite frankly I
think that's pretty excessive for documentation scenarios (unless you
want literal 1:1 addressing documentation for your entire network and
then 's/3fff/<GUA>/g' for deployment) but reality is there are 1
million /20s, so 1 x 1 millionth of the IPv6 address space for
documentation isn't objectively excessive.

No need to make loopback addressing any less convenient than 127/8
addressing has been for some of us who have found it useful, and the 1
x 4 billionth price is much lower than the 1 x 256th cost to IPv4 that
127/8 has eventually imposed.

Regards,
Mark.

> Owen
>