From mellon@fugue.com Sun Nov 12 02:55:06 2023 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46D4C1705E1 for ; Sun, 12 Nov 2023 02:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVQHcnCg9FnO for ; Sun, 12 Nov 2023 02:55:02 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD89AC1705E2 for ; Sun, 12 Nov 2023 02:55:02 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id 6a1803df08f44-66fa16092c0so22609986d6.0 for ; Sun, 12 Nov 2023 02:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1699786501; x=1700391301; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=xrUYQzofswkb/AAUQUEDx8bwpXmEqva2H1Vql47KMUQ=; b=Hc1cEn3/zyGOE4J4HayYws+wvtpXhwoV4NyPqSuLXrquenZ0hyYJDiQbXLSPQYouG5 p9AVQGaFENz8FxSidG+HW9aNkp1+4S93rDgUnYaKweP5EuOZPTjy5XQCxFAq5TPigSLd WYyj/627wEMJJreAKbJJMBuQFNlQ27q4+JiCVXrV7Klb/ye7//C61KFLVlsHM3J/KRed iUxm89Vkh7PLpOZ+MUr6veuwIV7ZQd9lWa0SgFqjVyueRyvhfw1NclPjuKIBcx3fuMKT k12zBHz9h0W5CgqEG8K8lGUYN5PFR/PyikQOJCaiMY/7UQ8ZRYtUCttNbyARruoUYJMc Jx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699786501; x=1700391301; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xrUYQzofswkb/AAUQUEDx8bwpXmEqva2H1Vql47KMUQ=; b=tc1l/uUyA5R7WmnTbZ+CD7L2907qTKnAkrF83h+0p8M52HpoPllOjB7h1bmRPiuce6 +q6uqEpiNtXdPXdLEd6nw3Q9QqgeTzTUUM0VVA1Zw5QbeniPSqm3ZDHIgPgCMmaDkhfA mc85QXW2s/m9xtQ6PLLl1ILrjy9rBrNYIUcw+/pmndXQM8wfvQ7ErTSUn53qCTQYaFTX dBcMkAxd6D2yi5GZFn6VGySBmojgWzb4j2P4QazONZQCUpIcwun8LKjPylUQCSK3D1ny kPa3TzuVVT/oOTNjO6Xg8MvFAbcPU9wQv3LMqUXM1jS/pQAKlAEXdLVnRr4TLctp95kL HmCA== X-Gm-Message-State: AOJu0YyjHWxlVs3mtJHB+Vjm7ZPgEG+e5pT48AuIEM53exGqRO0105mF OYmo14x6MKUfNAQ4pl7jVNRtjswj+IqmfNHibWO0NMqRCOf9+ktlyYm9Ow== X-Google-Smtp-Source: AGHT+IE1Rj9W6PYDPslm+FUEo6qaBalQI510MdF76sLBDpTcLOK/crtD/IkmlPtLWs4mRL+YIOFGyem4LRyXN4CqN6k= X-Received: by 2002:ad4:53a3:0:b0:671:3493:61e5 with SMTP id j3-20020ad453a3000000b00671349361e5mr4357606qvv.31.1699786501032; Sun, 12 Nov 2023 02:55:01 -0800 (PST) MIME-Version: 1.0 References: <69565BC4-B955-4840-B407-39707C47DE3E@employees.org> In-Reply-To: <69565BC4-B955-4840-B407-39707C47DE3E@employees.org> From: Ted Lemon Date: Sun, 12 Nov 2023 10:54:49 +0000 Message-ID: To: IPv6 Ops WG , =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary="000000000000969eea0609f2625e" Archived-At: Subject: Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2023 10:55:06 -0000 --000000000000969eea0609f2625e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that in this scenario, you have a problem, but I think the case where GUA-> GUA doesn=E2=80=99t work is a misconfiguration. We shouldn=E2= =80=99t try to address every possible misconfiguration because that will lead to useless complexity. Rather, misconfigurations should fail. Jen=E2=80=99s 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=C3=B8an > Hi Ted, > > Mark=E2=80=99s 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 =E2=80=9Cfound=E2=80=9D by 6724. > > If I understood Mark=E2=80=99s case correctly. > Eg if ULA A and ULA B were in different domains. > > I didn=E2=80=99t think HE would find other SA, DA pairs than what 6724 gi= ves. > > 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 wrote: > > =EF=BB=BF > > Sorry, you=E2=80=99ll have to walk me through how happy eyeballs fails he= re. I=E2=80=99m > not seeing it. > > Op zo 12 nov 2023 om 09:00 schreef Ole Tr=C3=B8an > >> Since the RFC6724 algorithm picks a single SA for a DA, in Mark=E2=80=99= 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=E2=80=99s using what it gets f= rom 6724. >> >> Did I understand that correctly? >> >> Cheers >> Ole >> >> >> >> On 12 Nov 2023, at 08:31, Ted Lemon wrote: >> >> =EF=BB=BF >> >> 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=E2=80=99t 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 >> >>> Hi David, >>> >>> On Sun, 12 Nov 2023, 13:59 David Farmer, wrote: >>> >>>> Lorenzo and Mark, >>>> >>>> The reality is that most systems today would use IPv4 instead of ULA i= f >>>> 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 ULA= s >>> 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 usin= g >>>> 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 ab= ove >>>> 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 ke= y >>> 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 H= E >>>> will try ULA against IPv4 if there is no GUA. Otherwise, if there is G= UA, >>>> 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 U= LA >>>> 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 is= n'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 coupl= ed >>> 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% availa= ble >>> because now you're comfortable preferring ULA over GUA. (For completene= ss, >>> 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 car= d 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 t= o >>> 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 t= hen >>> optimise for the common and likely cases (via preferences such as ULA o= ver >>> 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=E2=80=AFAM Lorenzo Colitti >>> 40google.com@dmarc.ietf.org> 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 f= or 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 ove= r >>>>> 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, >>>> 40umn.edu@dmarc.ietf.org> 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 Glob= al 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 I= Pv4 >>>>>> being used in practice since the ULA source will typically fail to >>>>>> communicate with the non-local ULA destination, and IPv4 will succee= d 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 oper= ational >>>>>> guidelines in Section 4.3 of [RFC4193] are followed. In that case, >>>>>> recognizing this failure can be accelerated, and transport layer tim= eouts >>>>>> (e.g., TCP) can be avoided. These guidelines will cause a Destinatio= n >>>>>> Unreachable ICMPv6 Error to be received by the source device, signal= ing the >>>>>> next address in the list to be tried, as discussed in Section 2 of R= FC 6724; >>>>>> >>>>>> Well-behaved applications SHOULD NOT simply use the first address >>>>>> returned from an API such as getaddrinfo() and then give up if it fa= ils. >>>>>> For many applications, it is appropriate to iterate through the list= of >>>>>> addresses returned from getaddrinfo() until a working address is fou= nd. For >>>>>> other applications, it might be appropriate to try multiple addresse= s 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=E2=80=AFAM Lorenzo Colitti >>>>> 40google.com@dmarc.ietf.org> 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 glob= al 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 w= ill >>>>>>> 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 >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------= - >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> David Farmer Email:farmer@umn.edu >>>>>> Networking & Telecommunication Services >>>>>> Office of Information Technology >>>>>> University of Minnesota >>>>>> 2218 University Ave SE Phone: 612-626-0815 >>>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>> >>>> >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> David Farmer Email:farmer@umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> --000000000000969eea0609f2625e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that in this scenario, you have a problem, but I = think the case where GUA-> GUA doesn=E2=80=99t work is a misconfiguratio= n.=C2=A0 We shouldn=E2=80=99t try to address every possible misconfiguratio= n because that will lead to useless complexity. Rather, misconfigurations s= hould fail. Jen=E2=80=99s experience with this that she shared with us last= week suggests that this is a better path to function than wallpapering ove= r every possible problem.=C2=A0

Op zo 12 nov 2023 om 10:50 schreef Ole = Tr=C3=B8an <otroan@employees.org= >
Hi Ted,

Mark=E2=80=99s case:
Destination host B= has ULA+GUA.=C2=A0
Source host A has ULA+GUA also.= =C2=A0

6724 will give two = SA, DA pairs.=C2=A0

{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 =E2=80=9Cfound=E2=80=9D by 6724.=C2=A0
=

If I understood Mark=E2=80=99s = case correctly.=C2=A0
Eg if ULA A and ULA B were in d= ifferent domains.=C2=A0

I = didn=E2=80=99t think HE would find other SA, DA pairs than what 6724 gives.= =C2=A0

I am definitely not= asserting anything here. But asking if this is also your understanding. :-= )

Cheers,
Ole

On 12 Nov 202= 3, at 11:26, Ted Lemon <mellon@fugue.com> wrote:

=EF=BB=BF
Sorr= y, you=E2=80=99ll have to walk me through how happy eyeballs fails here.=C2= =A0 I=E2=80=99m not seeing it.=C2=A0

Op zo 12 nov 2023 om 09:00 schreef= Ole Tr=C3=B8an <otroan@employees.org>
Since the RFC6724 al= gorithm picks a single SA for a DA, in Mark=E2=80=99s 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 H= E would help either, as it=E2=80=99s using what it gets from 6724.

Did I understand that correctly?

Cheers=C2=A0
Ole



On 12 Nov 2023, at 08:31, Ted L= emon <mellon@fugue= .com> wrote:

=EF=BB=BF
Optimizing for weird in= ternal network outages seems rather pessimistic. Do we really think this is= a likely situation, such that we need to make sure the user doesn=E2=80=99= t experience any delay at all in this case, at the risk of breaking all int= ernal connections when we need to renunber the GUA?=C2=A0

Op zo 12 nov = 2023 om 05:14 schreef Mark Smith <markzzzsmith@gmail.com>
Hi David,

On Sun, 12 Nov 2023, 13:59 David Farmer, <farmer@umn.edu> 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 imple= mented the advice in Section 10.6 of RFC 6724, which is rare and why we nee= d this draft.

I understand comp= letely why we need a draft to fix the problem with ULAs being below IPv4. S= ince I think of ULAs as site-locals+a random number, I assumed=C2=A0RFC 672= 4 just effectively replaced site-locals with ULAs, preferring them over GUA= s, as site-locals had been.
=C2=A0

We could make= the advice in Section 10.6 mandatory, but RFC 4193 also anticipates=C2=A0m= erging ULA networks. Therefore, the advice in Section=C2=A010.6 needs to be= mandatory and expanded to allow for an=C2=A0arbitrary=C2=A0number 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.=C2=A0 However,= others felt such=C2=A0a=C2=A0dynamic table would be too complicated and pr= eferred the simplicity of raising the preference of the ULA label above IPv= 4 yet=C2=A0remaining below GUA in a static table.
<= div>
For an internal destination, that could be reached by ei= ther 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.=C2=A0 Renumbering and Site Merging

=C2= =A0 =C2=A0The use of Local IPv6 addresses in a site results in making
= =C2=A0 =C2=A0communication that uses these addresses independent of renumbe= ring a
=C2=A0 =C2=A0site's provider-based global addresses."

=C2=A0
This is relatively safe as long as Happy Eyeba= lls is implemented, as HE will try ULA against IPv4 if there is no GUA. Oth= erwise,=C2=A0if there is GUA, HE will try it against IPv4 instead.

As Mark points out, this still leaves GUA preferred=C2=A0o= ver ULA. However, raising all ULA above GUA in a static table is unsafe, as= any remote ULA would be preferred=C2=A0over GUA.
=

Yes.

=C2=A0
Then, Happy Eyeb= alls would try the remote ULA against IPv4 instead of GUA,

Which is why HE should prefer ULA over GUA (an= d 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.


=C2=A0
with the likelihood of using IPv4 instead=C2=A0of GUA as expecte= d.=C2=A0 A dynamic table that prefers known local ULAs above GUA is the onl= y safe way to prefer ULA over GUA.

<= div>I disagree.

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

So imagine your "sa= fe" 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 sayi= ng 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 "unsa= fe" mean encountering long TCP connection timeout delays?)
<= br>
That may not be the case. Perhaps the ULA address of a host i= s on one network card, and the GUA address of the host is on a different ne= twork card (i.e. it's a multihomed host), and the link to the ULA netwo= rk card is down. The ULA address is now unreachable, whereas the GUA is rea= chable. I think that would be an "unsafe" result in your "sa= fe" scenario.

DNS does not provide an assuran= ce of current reachability. Hosts have to test reachability by actively try= ing to reach the DNS supplied DAs, and move on quickly to the next DA in th= e set somehow (e.g., via HEv2) when the current DA is determined to be unre= achable.

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


<= div>Regards,
Mark.
=C2=A0
Therefore, the advice in Section 10.6 is = still valid and should be expanded to allow for an=C2=A0arbitrary=C2=A0numb= er of /48s. With a static table, ULA should have a lower preference than GU= A to remain safe.

Mark's agreement, based on s= ite-local, is valid as far as it goes, but since there is only one site-loc= al prefix, there is no such thing as a remote site-local, where there can b= e unreachable remote ULAs.

Thanks.

<= /div>
On Sa= t, Nov 11, 2023 at 3:57=E2=80=AFAM Lorenzo Colitti <lorenzo=3D4= 0google.com@dmarc.ietf.org> wrote:
Why is is a misconfiguration to= put a ULA AAAA record in the DNS? Because it is never preferred over anyth= ing, adding it won't break anything, and it will work on IPv6-only netw= orks when global IPv6 connectivity is down. I could totally see someone doi= ng the following:

server.= smallcompany.com AAAA fd73:4899:2a7f:a93a::53
server.smallcompany.com AAAA 2001:db8:4923::1

This would work well today. The server would be reach= ed:

- 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 conn= ectivity (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 c= hange the rules as proposed in this draft, it will stop working for any hom= e 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 UL= A the same label, and prefer it over other addresses, we'll always end = up with problems.

What h= appened to the idea of treating "same /48" ULA differently from &= quot;rest of ULA space"?

On Fri, 10 Nov 2023, 15:57 David Farmer,= <farmer=3D40umn.edu@dmarc.ietf.org> wrote:
In this s= cenario, 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 th= e Global DNS, contradicting Section=C2=A04.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.=C2=A0The likely result is IP= v4 being used in practice since the ULA source will typically fail to commu= nicate with the non-local ULA destination, and IPv4 will succeed if IPv4 In= ternet connectivity is available.

If Happy Eyeball= s 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 n= on-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. Th= ese guidelines will cause a Destination Unreachable ICMPv6 Error to be rece= ived by the source device, signaling the next address in the list to be tri= ed, as discussed in Section 2 of RFC 6724;

Wel= l-behaved applications SHOULD NOT simply use the first address returned fro= m an API such as getaddrinfo() and then give up if it fails. For many appli= cations, it is appropriate to iterate through the list of addresses returne= d from getaddrinfo() until a working address is found. For other applicatio= ns, it might be appropriate to try multiple addresses in parallel (e.g., wi= th 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=E2=80= =AFAM Lorenzo Colitti <lorenzo=3D40google.com@dmarc.= ietf.org> wrote:
I don't know how common this i= s, 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 IPv= 4) 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 packe= ts.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www= .ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:far= mer@umn.edu
Networking & Telecommunication Services
Office of= Information Technology
University of Minnesota=C2=A0=C2=A0
2218 Uni= versity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapoli= s, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
------------------------------------------------------------= --------
--000000000000969eea0609f2625e--