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

[David Farmer <[e-mail]>]

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.

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
===============================================