Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-00.txt

[Brian E Carpenter <[e-mail]>]

On 21-Oct-23 10:09, David Farmer wrote:
> 
> On Wed, Oct 18, 2023 at 2:03 PM Ole Troan <otroan=[e-mail] <mailto:[e-mail]>> wrote:
> 
>      > An IPv6 ULA address will only be preferred over an IPv4 address; IFF, both IPv6 ULA source and destination addresses are available. As discussed in this thread and section 7 of this update, with rule 5 of section 6 of RFC6724 and the ULA label added in RFC6724, an IPv4 source and destination will be preferred over an IPv6 ULA source and an IPv6 GUA destination address, even though generally IPv6 ULA addresses are preferred over IPv4 in the policy table as proposed in this update.
>      >
>      > Furthermore, in order for the scenario you describe, ULA used with NPTv6, NAT66, or NAPT66 and to be preferred over IPv4, the separate ULA label actually MUST be removed from the policy table.
>      >
>      > Therefore, the policy table, as proposed, discourages the use of ULA with NPTv6, NAT66, or NAPT66, which, if I'm understanding you correctly, is what you would like.
> 
>     The behaviour _I_ would like is for RFC1918 and ULA sources to be treated equally for global DA.
>     Expecting HE / host heuristics would deprioritize one or the other as the host learns the SAs actual reachability.
> 
>     I don’t think the answer to that problem is a separate block of IPv6 space for ULA with global reachability (how many address classes are we going to have) or to per-network modify the host SAS policy.
>     Operators are then instead solving it by using an address space that does behave that way. E.g. 2001:db8::/32.
> 
> 
> Using ULA for global communications and reachability conflicts with the very definition of ULA in RFC4193. From the Intro of RFC 4193, "This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPV6]... They are not expected to be routable on the global Internet."

That's true, but (Experimental) RFC 6296 explains how ULA<-->GUA can work. If a user chooses ULA<-->GUA and there is no NPTv6 or NAT66 present, the user loses. More rational address selection is possible if the host has access to a "NPTv6 (or NAT66) present" flag. (Actually, the same is true in IPv4 - if there was a "NAT44 present" flag, it could be tested before trying to use an RFC1918 source address. But it isn't needed in practice because NAT44 is so widespread.)

> 
> As currently defined, if the host only has a ULA source address, the host can expect only to have local connectivity. If the host also has a GUA source address, the host can expect global connectivity. Just because we blurred this distinction in IPv4 doesn't mean we should also blur the distinction in IPv6. We have plenty of IPv6 addresses to have separate local and global address formats, and that is why ULA was defined as a separate address format.
> 
> There is no good way to maintain the distinction between local names and global names in the DNS. If we can't maintain a clear distinction between local and global IPv6 addresses, then we are doomed to confuse the local and global domains forever. Let's not do that!

I think we're pretty close to that abyss already, and we can't pull back from it without replacing getaddrinfo(). This fix to RFC6724 is the best we can for current running code, however.

Also, it turns out that the IESG holdup on draft-ietf-6man-rfc6874bis-09 is closely related to this very question. Over in Webland, they really don't know how to handle the issue of locally scoped IP addresses. See https://wicg.github.io/private-network-access/

    Brian