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

[Nick Buraglio <[e-mail]>]

On Sun, Nov 12, 2023 at 2:39 PM Brian E Carpenter <
[e-mail]> wrote:

> On 13-Nov-23 00:38, Ted Lemon wrote:
> > 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.
>
> I can't say this loudly enough in plain text: +1.


I agree.



>
>     Brian
>
> >
> > Op zo 12 nov 2023 om 11:19 schreef Mark Smith <[e-mail]
> <mailto:[e-mail]>>
> >
> >     Hi,
> >
> >     On Sun, 12 Nov 2023 at 21:55, Ted Lemon <[e-mail] <mailto:
> [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] <mailto:[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] <mailto:
> [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] <mailto:[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] <mailto:
> [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] <mailto:[e-mail]>>
> >      >>>>
> >      >>>> Hi David,
> >      >>>>
> >      >>>> On Sun, 12 Nov 2023, 13:59 David Farmer, <[e-mail]
> <mailto:[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] <mailto:[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 <http://server.smallcompany.com>
> AAAA fd73:4899:2a7f:a93a::53
> >      >>>>>> server.smallcompany.com <http://server.smallcompany.com>
> AAAA 2001:db8:4923::1
> >      >>>>>> server.smallcompany.com <http://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] <mailto:[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 f
> <https://www.google.com/maps/search/D+NOT+simply+use+the+f?entry=gmail&source=g>irst
> 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] <mailto:[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] <mailto:[e-mail]>
> >      >>>>>>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >      >>>>>>>>
> --------------------------------------------------------------------
> >      >>>>>>>
> >      >>>>>>>
> >      >>>>>>>
> >      >>>>>>> --
> >      >>>>>>> ===============================================
> >      >>>>>>> David Farmer Email:[e-mail] <mailto:
> [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] <mailto:
> [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] <mailto:[e-mail]>
> >      >>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >      >>>>
> --------------------------------------------------------------------
> >      >>>
> >      >>>
> --------------------------------------------------------------------
> >      >>> IETF IPv6 working group mailing list
> >      >>> [e-mail] <mailto:[e-mail]>
> >      >>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >      >>>
> --------------------------------------------------------------------
> >      >
> >      > _______________________________________________
> >      > v6ops mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>