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

[Daryll Swer <[e-mail]>]

>
> Can you elaborate on what kind of testing scenario would require 4 billion
> /64 loopback interfaces on a single machine?
>

I've seen discussions in the past that argued for: A unique /128 (GUA) per
process on a host on the basis of port conflict avoidance +
'privacy/security' net positives.

All in all, a *single* /64 would suffice IMO. GUA is probably ideal for /64
loopback, but there may be use cases, which I can't imagine right now, that
may benefit from traditional non-global loopback (/64).

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.shortlink.es/l/d88aae2ef5216b5213c296d705b6c801adfc0577?u=2153471>


On Thu, 4 Dec 2025 at 07:48, Owen DeLong <owen=[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. 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).
>
> 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?
>
> Owen
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>