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

[Ted Lemon <[e-mail]>]

I think the place to draw the line is where we make a misconfiguration
scenario work at the expense of a scenario where there is no
misconfiguration.

Op zo 12 nov 2023 om 11:19 schreef 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
>