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

[Mark Smith <[e-mail]>]

Hi,

On Sun, 12 Nov 2023 at 21:55, Ted Lemon <[e-mail]> wrote:
>
> I agree that in this scenario, you have a problem, but I think the case where GUA-> GUA doesn’t work is a misconfiguration.  We shouldn’t try to address every possible misconfiguration because that will lead to useless complexity. Rather, misconfigurations should fail.

I generally agree with this. It's also best if the party who
misconfigured something directly suffers the greatest consequences of
their misconfiguration, which motivates them to fix it.

I think there is however some value in tolerating to an extent
misconfiguration. This is Postel's "be liberal with what you accept".
However, liberally accepting everything is also not good. The thing to
think about and decide on is where to draw the line between a
tolerable misconfiguration and one that should fail hard. I'd say
tolerable means an acceptable end-user experience, however one that
would be improved fairly significantly if the misconfiguration is
fixed.

(More text below, have kept it all to preserve Ole's summary of my
case rather than snipping it)

> Jen’s experience with this that she shared with us last week suggests that this is a better path to function than wallpapering over every possible problem.
>
> Op zo 12 nov 2023 om 10:50 schreef Ole Trøan <[e-mail]>
>>
>> Hi Ted,
>>
>> Mark’s case:
>> Destination host B has ULA+GUA.
>> Source host A has ULA+GUA also.
>>
>> 6724 will give two SA, DA pairs.
>>
>> {ULA A, ULA B}
>> {GUA A, GUA B}
>>
>> Now, if the only path working is:
>> {ULA A, GUA B}
>>
>> Then that SA, DA combination will not be “found” by 6724.
>>
>> If I understood Mark’s case correctly.
>> Eg if ULA A and ULA B were in different domains.

No, in my scenario both of the Host A and Host B's ULA addresses were
within the same network/same ULA/48 prefix.

Normally, Host A's ULA address should have a path through the local
network to Host B's ULA address and vice versa, so Host A and B's ULA
addresses should be preferred over Host A and Host B's GUA addresses.

However, there could be a routing fault such that H.A ULA to H.B ULA
temporarily isn't working. H.A GUA to H.B. GUA would then be he fall
back in that situation until the ULA routing problem is fixed.

Regards,
Mark.


>>
>> I didn’t think HE would find other SA, DA pairs than what 6724 gives.
>>
>> I am definitely not asserting anything here. But asking if this is also your understanding. :-)
>>
>> Cheers,
>> Ole
>>
>> On 12 Nov 2023, at 11:26, Ted Lemon <[e-mail]> wrote:
>>
>> 
>>
>> Sorry, you’ll have to walk me through how happy eyeballs fails here.  I’m not seeing it.
>>
>> Op zo 12 nov 2023 om 09:00 schreef Ole Trøan <[e-mail]>
>>>
>>> Since the RFC6724 algorithm picks a single SA for a DA, in Mark’s example the algorithm will not find a working SA/DA at all.
>>>
>>> (A solution to that would be to return an ordered list of SAs for a DA.)
>>>
>>> I am not sure HE would help either, as it’s using what it gets from 6724.
>>>
>>> Did I understand that correctly?
>>>
>>> Cheers
>>> Ole
>>>
>>>
>>>
>>> On 12 Nov 2023, at 08:31, Ted Lemon <[e-mail]> wrote:
>>>
>>> 
>>>
>>> Optimizing for weird internal network outages seems rather pessimistic. Do we really think this is a likely situation, such that we need to make sure the user doesn’t experience any delay at all in this case, at the risk of breaking all internal connections when we need to renunber the GUA?
>>>
>>> Op zo 12 nov 2023 om 05:14 schreef 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
>>>>> ===============================================
>>>>
>>>> --------------------------------------------------------------------
>>>> 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
>>> --------------------------------------------------------------------
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops