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

[Nick Buraglio <[e-mail]>]

Hit send too soon -

We will also re-perform some behavioral tests as suggested at 118.



On Sat, Nov 11, 2023 at 2:24 PM Nick Buraglio <[e-mail]>
wrote:

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