Re: [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames

[Nick Buraglio <[e-mail]>]

A quick recap of this draft:

* It changes the preference for ULAs to be above IPv4
* It leaves all labels intact, allowing for proper IPv6 to IPv6 behavior
* It performs a deliberate tactical change, aimed at demoting IPv4 below
all IPv6 enabling consistent behavior, and continuing to leverage the
aforementioned existing labels
* The newest version adds the section 5.5 MUST adjust back in, per IETF 118
input
* The draft is deliberately as simple as we could make it because the topic
is fairly complex. It does not address any signaling or other changes to
the address selection mechanics that would need to be executed in some new
version of getaddrinfo(), and that is by design - see bullet 3.

118 comments are already in the working copy, we will address David's great
input this week and submit a new version. At that time we will humbly
request that it be considered for WGLC.

nb

On Sat, Nov 11, 2023 at 1:55 PM Brian E Carpenter <
[e-mail]> wrote:

> On 12-Nov-23 07:25, Ted Lemon wrote:
> > You can’t deprecate ULAs. We’re using them. They work really well. What
> we are discussing here is if there are things we can do that make them work
> even better.
>
> Exactly. The problem is not ULAs, which work as intended. The problems are:
>
> a) Split-horizon DNS, while widely used, is somehow regarded as suspect.
>
> b) The RFC3484/6724/getaddrinfo() model is fundamentally inadequate.
>
> a) is also behind the answer to Lorenzo's question. It's wrong to put
> a ULA in public DNS, because it's a private address. It's fine to put
> a ULA in private DNS, because it's a private address.
>
> RFC 4193 says this:
>
> >    At the present time, AAAA and PTR records for locally assigned local
> >    IPv6 addresses are not recommended to be installed in the global DNS.
>
> That should probably have used RFC2119 language, but it's clear enough.
>
>     Brian
>
> >
> > Op za 11 nov 2023 om 16:36 schreef Mark Smith <[e-mail]
> <mailto:[e-mail]>>
> >
> >     I'm starting to believe it is better to deprecate ULAs.
> >
> >     People can't seem to get past default address selection being a
> static starting point, and that it can't be made to cope with all
> situations because it is a static mechanism which can never cope with the
> normal dynamic situations of occasional unreachability and human error.
> >
> >     If GUAs are preferred over ULAs, then ULAs aren't of any use in
> networks with GUAs.
> >
> >     So much for, from RFC 4193,
> >
> >     4.2 <https://datatracker.ietf.org/doc/html/rfc4193#section-4.2>.
> Renumbering and Site Merging
> >
> >         The use of Local IPv6 addresses in a site results in making
> >         communication that uses these addresses independent of
> renumbering a
> >         site's provider-based global addresses.
> >
> >
> >
> >
> >
> >     On Sat, 11 Nov 2023, 20:57 Lorenzo Colitti, <lorenzo=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >         Why is is a misconfiguration to put a ULA AAAA record in the
> DNS? Because it is never preferred over anything, adding it won't break
> anything, and it will work on IPv6-only networks when global IPv6
> connectivity is down. I could totally see someone doing the following:
> >
> >         server.smallcompany.com <http://server.smallcompany.com> AAAA
> fd73:4899:2a7f:a93a::53
> >         server.smallcompany.com <http://server.smallcompany.com> AAAA
> 2001:db8:4923::1
> >         server.smallcompany.com <http://server.smallcompany.com> A
> 192.0.2.1
> >
> >         This would work well today. The server would be reached:
> >
> >         - over global IPv6, if the client has it
> >         - over ULA, if the client is v6-only and is within small
> company's network but there is no global connectivity (e.g. ISP link down
> and addresses deprecated)
> >         - over IPv4, otherwise
> >
> >         People might well have done this today because it works for
> them. If we change the rules as proposed in this draft, it will stop
> working for any home network that has a ULA and IPv4, but no IPv6 (and
> there are lots of these).
> >
> >         This is a fundamental property of ULA: it doesn't provide
> reachability. If we give all of ULA the same label, and prefer it over
> other addresses, we'll always end up with problems.
> >
> >         What happened to the idea of treating "same /48" ULA differently
> from "rest of ULA space"?
> >
> >         On Fri, 10 Nov 2023, 15:57 David Farmer, <farmer=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >             In this scenario, a ULA source with a non-local ULA
> destination can only occur from a misconfiguration that includes both a ULA
> and Global IPv4 addresses in the Global DNS, contradicting Section 4.4 of
> RFC4193.
> >
> >             Nevertheless, even if this misconfiguration happens, Happy
> Eyeballs, if implemented, will try the non-local ULA destination with the
> ULA source and the IPv4 destination and source pairings. The likely result
> is IPv4 being used in practice since the ULA source will typically fail to
> communicate with the non-local ULA destination, and IPv4 will succeed if
> IPv4 Internet connectivity is available.
> >
> >             If Happy Eyeballs is not implemented, the non-local ULA
> destination with the ULA source is preferred, and the ULA source will
> typically fail to communicate with the non-local ULA destination; however,
> if the operational guidelines in Section 4.3 of [RFC4193] are followed. In
> that case, recognizing this failure can be accelerated, and transport layer
> timeouts (e.g., TCP) can be avoided. These guidelines will cause a
> Destination Unreachable ICMPv6 Error to be received by the source device,
> signaling the next address in the list to be tried, as discussed in Section
> 2 of RFC 6724;
> >
> >                 Well-behaved applications SHOULD NOT simply use the
> first address returned from an API such as getaddrinfo() and then give up
> if it fails. For many applications, it is appropriate to iterate through
> the list of addresses returned from getaddrinfo() until a working address
> is found. For other applications, it might be appropriate to try multiple
> addresses in parallel (e.g., with some small delay in between) and use the
> first one to succeed.
> >
> >
> >             Should this also be discussed in the draft?
> >
> >             Thanks
> >
> >             On Fri, Nov 10, 2023 at 3:35 AM Lorenzo Colitti <lorenzo=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >                 I don't know how common this is, but it's probably worth
> thinking about.
> >
> >                 Many home routers assign ULAs, even if they don't have
> native IPv6. On such networks, a hostname that has ULA and IPv4 (or ULA and
> global and IPv4) will currently work using IPv4.
> >
> >                 If hosts update to follow the new rules in
> draft-ietf-6man-rfc6724-update, that will break because new hosts will
> prefer ULA over IPv4. This won't work, because the ULA is actually a
> different ULA and the home router will drop the packets.
> >
>  --------------------------------------------------------------------
> >                 IETF IPv6 working group mailing list
> >                 [e-mail] <mailto:[e-mail]>
> >                 Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >
>  --------------------------------------------------------------------
> >
> >
> >
> >             --
> >             ===============================================
> >             David Farmer Email:[e-mail] <mailto:
> [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] <mailto:[e-mail]>
> >         Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >
>  --------------------------------------------------------------------
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> >     --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>