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

[Vasilenko Eduard <[e-mail]>]

Hi all,

Mark’s proposal fixes ULA+NPT case.
I would like to talk about the case of choosing from 2 sources GUAs. (ULA may not exist at all). It is the strategic direction, right?

For every problem, RFC 6724 should be analyzed twice:

1.       If the destination address is chosen 1st (more typical situation)

2.       If the source address is chosen 1st (I hope we do not have the intention to deprecate such possibility – it is needed for prefixes unequally accepted by 3rd parties)

For 1: (more typical situation)
Section6: DNS would probably return GUA (not ULA). Hence GUA would be chosen as the destination.
Then
Section5: rule8 (longest match) would probably choose GUA as the source
Conclusion: fine, even after Mark's proposal.

For 2: (advanced functionality for the future)
Section 5: no one rule is applicable. Why not choose ULA, especially if it is prioritized by precedence (that is, in reality, applicable only for destination address selection)
ULA choice as the source would probably break connectivity because DNS would probably return GUA, but it would be checked later.

I mean: the second approach that was promised
“
Another implementation strategy is to call down to the network layer
   to retrieve source address information and then sort the list of
   addresses directly in the context of getaddrinfo()
”
Is not really implemented in RFC 6724.
It is not possible to choose a source (from a few GUAs) that would not be filtered on the Internet.

Is it possible to fix this problem too? Or is it a too big change?
If we would not fix this problem then ULA+NPT would become a must.
More on the problem in section 5.1 https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02#page-13
But this draft fixes only the ND part of the problem.
“Default address selection” for many unequal GUAs is not touched yet.
And of course, home networking (HNCP or DHCP-PD) is needed to distribute prefixed inside site routed network.
The problem of proper choice for source GUA, in reality, is distributed in 3 places that must be fixed.

PS: this thread is more applicable to 6man – on copy.

Eduard
From: v6ops [mailto:[e-mail]] On Behalf Of Mark Smith
Sent: Saturday, March 26, 2022 3:32 AM
To: Brian E Carpenter <[e-mail]>
Cc: v6ops list <[e-mail]>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]


On Fri, 25 Mar 2022, 07:04 Brian E Carpenter, <[e-mail]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
> .
>

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops