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

[Mark Smith <[e-mail]>]

Hi David,

On Sun, 12 Nov 2023, 13:59 David Farmer, <[e-mail]> wrote:

> Lorenzo and Mark,
>
> The reality is that most systems today would use IPv4 instead of ULA if
> they didn't have GUA unless they implemented the advice in Section 10.6 of
> RFC 6724, which is rare and why we need this draft.
>

I understand completely why we need a draft to fix the problem with ULAs
being below IPv4. Since I think of ULAs as site-locals+a random number, I
assumed RFC 6724 just effectively replaced site-locals with ULAs,
preferring them over GUAs, as site-locals had been.


>
> We could make the advice in Section 10.6 mandatory, but RFC 4193 also
> anticipates merging ULA networks. Therefore, the advice in Section 10.6
> needs to be mandatory and expanded to allow for an arbitrary number of
> /48s, not just the /48 covering the PIO used for ULA. I suggested using
> PIOs to add additional ULA prefixes to the policy table dynamically.
> However, others felt such a dynamic table would be too complicated and
> preferred the simplicity of raising the preference of the ULA label above
> IPv4 yet remaining below GUA in a static table.
>

For an internal destination, that could be reached by either a ULA or GUA
address, ULA should be preferred over GUA. Otherwise, one of the key
benefits and uses of ULAs disappears:

RFC 4193:

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




> This is relatively safe as long as Happy Eyeballs is implemented, as HE
> will try ULA against IPv4 if there is no GUA. Otherwise, if there is GUA,
> HE will try it against IPv4 instead.
>
> As Mark points out, this still leaves GUA preferred over ULA. However,
> raising all ULA above GUA in a static table is unsafe, as any remote ULA
> would be preferred over GUA.
>

Yes.



> Then, Happy Eyeballs would try the remote ULA against IPv4 instead of GUA,
>

Which is why HE should prefer ULA over GUA (and all IPv6 is preferred over
all IPv4).

Note that it needs to be Happy Eyeballs version 2, which works differently
and better to HEv2 regarding IPv6 verses IPv4.




> with the likelihood of using IPv4 instead of GUA as expected.  A dynamic
> table that prefers known local ULAs above GUA is the only safe way to
> prefer ULA over GUA.
>

I disagree.

Hosts have to be able to cope with DNS providing unreachable destinations
regardless of ULA/GUA/IPv4 etc. preference, because DNS isn't normally
tightly coupled to the state of reachability of the network. (DNS caching
would be hard if not impossible to do if DNS records were coupled to the
state of OSPF, BGP and ultimately ND/ARP reachability for DAs.)

So imagine your "safe" scenario where a host has a dynamic table such that
the host knows of the local ULA /48.

DNS returns the ULA and GUA DAs for an internal host.

I think you're saying with your dynamic table that is a safe scenario,
which I think means you're assuming then ULA will always be 100% available
because now you're comfortable preferring ULA over GUA. (For completeness,
does "unsafe" mean encountering long TCP connection timeout delays?)

That may not be the case. Perhaps the ULA address of a host is on one
network card, and the GUA address of the host is on a different network
card (i.e. it's a multihomed host), and the link to the ULA network card is
down. The ULA address is now unreachable, whereas the GUA is reachable. I
think that would be an "unsafe" result in your "safe" scenario.

DNS does not provide an assurance of current reachability. Hosts have to
test reachability by actively trying to reach the DNS supplied DAs, and
move on quickly to the next DA in the set somehow (e.g., via HEv2) when the
current DA is determined to be unreachable.

Once you accept that DNS may return unreachable DAs, and hosts will and
have to deal with it in a user friendly manner (HEv2 or similar), you then
optimise for the common and likely cases (via preferences such as ULA over
GUA), not error and uncommon cases like remote and unreachable ULAs in
global DNS.


Regards,
Mark.


> Therefore, the advice in Section 10.6 is still valid and should be
> expanded to allow for an arbitrary number of /48s. With a static table, ULA
> should have a lower preference than GUA to remain safe.
>
> Mark's agreement, based on site-local, is valid as far as it goes, but
> since there is only one site-local prefix, there is no such thing as a
> remote site-local, where there can be unreachable remote ULAs.
>
> Thanks.
>
> On Sat, Nov 11, 2023 at 3:57 AM Lorenzo Colitti <lorenzo=
> [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 AAAA fd73:4899:2a7f:a93a::53
>> server.smallcompany.com AAAA 2001:db8:4923::1
>> 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]>
>> 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]> 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
>>> ===============================================
>>>
>>
>
> --
> ===============================================
> 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
> ===============================================
>