Re: [v6ops] ULA precedence [Thoughts about wider operational input]

[Mark Smith <[e-mail]>]

On Fri, 25 Mar 2022, 07:04 Brian E Carpenter, <[e-mail]>
wrote:

> (Trying, far too late, to change the Subject to be the actual subject...)
>
> I wasn't paying enough attention when RFC6724 was done.


Neither was I.

I assumed it was swapping site-locals for ULAs, because the issue with
site-locals was their lack of uniqueness. Otherwise, preference over GUAs
etc. was all fine.

RFC6724 now preferrs GUAs over ULAs, which defeats the use of ULAs to
provide internal connectivity while performing a GUA renumber, which is one
of the ULA use cases mentioned in RFC4193, and I think one of the main
reasons to have a parallel internal/local address space.

The justification for that change in RFC6724 is that GUAs seems to be that
they may be more reliably reached than ULAs (section 10.6). I don't agree,
I think in general local addressing will inherently be more reliable than
global addressing.

However, a GUA address could be more reliably reached than the equivalent
ULA for the destination at the time any particular connection is attempted.

So I've been thinking we should:

- change the preference of ULAs to over GUAs (and IPv4), to facilitate GUA
renumbering per RFC4193.

- recommend the use of Happy Eyeballs v2 at the time of the connection
attempt to address the issue of a GUA DA being available when the
equivalent ULA DA might not be, addressing the situation that caused ULAs
to be put below GAUs.

- suggest and possibly recommend multi-path transport protocols like MPTCP
that would connect to both (all) available GUAs and ULAs, providing
robustness against either GUA or ULA addresses going away during the
connection.

Regards,
Mark.

I think it's even
> more wrong each time I look at it. For example, it has the consequence that
> if a pair of hosts have both RFC1918 and ULA addresses, the default for
> communication between them is RFC1918. D'Oh. If two hosts have ULAs in the
> same /64, they will nevertheless try IPv4 first. D'Oh. And the default
> table
> in RFC6724 is sticky in practice, even if configurable in theory.
>
> I think this needs serious work (in 6MAN most likely).
>
> Regards
>     Brian Carpenter
>
> On 25-Mar-22 00:29, Philip Homburg wrote:
> >> (Dual-stack cannot be the answer anyway - it will have all the issues
> >> of IPv4, plus the added complications of dual-stack.  Services need to
> >> be dual-stack, but for all the rest, single-stack IPv6 needs to be
> >> the end goal - see facebook etc)
> >
> > Obviously, on an IPv6-only system, there is no IPv4, so the relative
> > priority of ULA compared to IPv4 does not matter.
> >
> > I'm curious what IPv4aaS we want to deploy. I consider NAT64 a complete
> > disaster (even if the form of 464xlat). Given how the internet works,
> > we will probably end up with NAT64 everywhere until the end of times.
> >
> >> This is not what I had in mind.  If "we" decide that ULA is a good
> >> way forward, IETF can update RFCs, and vendors will eventually
> >> update their base OS.  It might take 5 years, but so will everything
> >> else in Big Enterprise land.
> >
> > The problem with ULA is that we have lots of installations where hosts
> with
> > a ULA address don't have access to the IPv6 internet. Often, CPEs
> announce
> > a ULA when the CPE doesn't have an IPv6 uplink.
> >
> > In contrast, where RFC 1918 was meant for local IPv4 communication, it is
> > now on a very large scale the primary method for a host to reach the IPv4
> > internet.
> >
> > So to avoid the situation where we say that ULA is local and then use it
> > to connect to the IPv6 internet, we should just allocate a new space. And
> > explicitly give it the property to connect to the IPv6 internet through
> > through some sort of address translation.
> >
> > There is also a nice tie-in with PI. Obviously, putting millions of PI
> > prefixes in BGP does not scale.
> >
> > On the other hand, there is no such limit if the PI space is used behind
> NAT.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> > .
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>