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

[Ted Lemon <[e-mail]>]

This topic came up during SNAC today. It’s actually possible for the
GUA/ULA combination to be the best combination in a stub network situation
where there is only a GUA on-link prefix on the northbound interface of the
stub router, and the stub router has to use a ULA on the stub network
because it can’t get a prefix delegation.

This is a bit of an edge case, but not technically a misconfiguration in
all cases. I don’t think there’s an issue here other than that the
assertion that this is always a misconfiguration may be going too far.

Op vr 10 nov 2023 om 15:57 schreef David Farmer <farmer=
[e-mail]>

> 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]> 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]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
> ===============================================
> 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
> --------------------------------------------------------------------
>