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

[Nick Buraglio <[e-mail]>]

On Fri, Oct 20, 2023 at 9:22 PM David Farmer
<farmer=[e-mail]> wrote:
>
>
>
> On Fri, Oct 20, 2023 at 5:33 PM Brian E Carpenter <[e-mail]> wrote:
>>
>> 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:
>> >
>> >      > 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.)
>
>
> Actually, that only works with the Default Address Selection policy table of RFC3484, which doesn't have a separate label for ULA. With the Default Address Selection policy table of RFC6724, IPv4 will always be selected over ULA. Even with this update, increasing the preference for ULA, as has been discussed, IPv4 will be selected over a ULA Source with a GUA Destination because of the separate ULA label. Further, as discussed in the draft, changing the policy table can be almost impossible in many situations.
>
> I believe Ole is instead suggesting removing the ULA label from the policy table restoring NPTv6, NAT66, or NAPT66 functionality with ULA by default. Preferring IPv6 GUA and ULA equally and over IPv4 and only relying on Happy Eyeballs (HE) to determine reachability between IPv6 and IPv4.
>
>> > 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/
>
>
> In my opinion, removing the separate label for ULA pushes us into the abyss, and we will forever confuse the local and global domains. If we continue the local vs. global confusion we created in IPv4, in IPv6, there will be no hope for them to ever figure out how to handle the issue of locally scoped IP addresses.

I tend to agree with this, the label is an important part of the
deterministic process.
I would rather see some way, outside of the scope of this draft, to
signal to the host the presence of a NPTv6 service upstream. I've been
thinking about that quite a bit in the context of NPTv6, and more and
more I feel like that is a thought exercise worth going through.

>
> Thanks.
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------