Re: [v6ops] ULA precedence [Thoughts about wider operational input]

[Nick Buraglio <[e-mail]>]

In keeping with the theme of this thread, a few of us authored an
informational draft outlining the issues discussed here in some detail so
that we can use it as a guide in the future. It is submitted here
https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula/
As always, input, comments, and feedback welcome.

Thanks!
nb




ᐧ

On Sat, Mar 26, 2022 at 6:56 AM Vasilenko Eduard <vasilenko.eduard=
[e-mail]> wrote:

> Hi all,
>
>
>
> Mark’s proposal fixes ULA+NPT case.
>
> I would like to talk about the case of choosing from 2 sources GUAs. (ULA
> may not exist at all). It is the strategic direction, right?
>
>
>
> For every problem, RFC 6724 should be analyzed twice:
>
> 1.       If the destination address is chosen 1st (more typical situation)
>
> 2.       If the source address is chosen 1st (I hope we do not have the
> intention to deprecate such possibility – it is needed for prefixes
> unequally accepted by 3rd parties)
>
>
>
> For 1: (more typical situation)
>
> Section6: DNS would probably return GUA (not ULA). Hence GUA would be
> chosen as the destination.
>
> Then
>
> Section5: rule8 (longest match) would probably choose GUA as the source
>
> Conclusion: fine, even after Mark's proposal.
>
>
>
> For 2: (advanced functionality for the future)
>
> Section 5: no one rule is applicable. Why not choose ULA, especially if it
> is prioritized by precedence (that is, in reality, applicable only for
> destination address selection)
>
> ULA choice as the source would probably break connectivity because DNS
> would probably return GUA, but it would be checked later.
>
>
>
> I mean: the second approach that was promised
>
> “
>
> Another implementation strategy is to call down to the network layer
>
>    to retrieve source address information and then sort the list of
>
>    addresses directly in the context of getaddrinfo()
>
> ”
>
> Is not really implemented in RFC 6724.
>
> It is not possible to choose a source (from a few GUAs) that would not be
> filtered on the Internet.
>
>
>
> Is it possible to fix this problem too? Or is it a too big change?
>
> If we would not fix this problem then ULA+NPT would become a must.
>
> More on the problem in section 5.1
> https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02#page-13
>
> But this draft fixes only the ND part of the problem.
>
> “Default address selection” for many unequal GUAs is not touched yet.
>
> And of course, home networking (HNCP or DHCP-PD) is needed to distribute
> prefixed inside site routed network.
>
> The problem of proper choice for source GUA, in reality, is distributed in
> 3 places that must be fixed.
>
>
>
> PS: this thread is more applicable to 6man – on copy.
>
>
>
> Eduard
>
> *From:* v6ops [mailto:[e-mail]] *On Behalf Of *Mark Smith
> *Sent:* Saturday, March 26, 2022 3:32 AM
> *To:* Brian E Carpenter <[e-mail]>
> *Cc:* v6ops list <[e-mail]>
> *Subject:* Re: [v6ops] ULA precedence [Thoughts about wider operational
> input]
>
>
>
>
>
> On Fri, 25 Mar 2022, 07:04 Brian E Carpenter, <[e-mail]>
> wrote:
>
> (Trying, far too late, to change the Subject to be the actual subject...)
>
> I wasn't paying enough attention when RFC6724 was done.
>
>
>
> Neither was I.
>
>
>
> I assumed it was swapping site-locals for ULAs, because the issue with
> site-locals was their lack of uniqueness. Otherwise, preference over GUAs
> etc. was all fine.
>
>
>
> RFC6724 now preferrs GUAs over ULAs, which defeats the use of ULAs to
> provide internal connectivity while performing a GUA renumber, which is one
> of the ULA use cases mentioned in RFC4193, and I think one of the main
> reasons to have a parallel internal/local address space.
>
>
>
> The justification for that change in RFC6724 is that GUAs seems to be that
> they may be more reliably reached than ULAs (section 10.6). I don't agree,
> I think in general local addressing will inherently be more reliable than
> global addressing.
>
>
>
> However, a GUA address could be more reliably reached than the equivalent
> ULA for the destination at the time any particular connection is attempted.
>
>
>
> So I've been thinking we should:
>
>
>
> - change the preference of ULAs to over GUAs (and IPv4), to facilitate GUA
> renumbering per RFC4193.
>
>
>
> - recommend the use of Happy Eyeballs v2 at the time of the connection
> attempt to address the issue of a GUA DA being available when the
> equivalent ULA DA might not be, addressing the situation that caused ULAs
> to be put below GAUs.
>
>
>
> - suggest and possibly recommend multi-path transport protocols like MPTCP
> that would connect to both (all) available GUAs and ULAs, providing
> robustness against either GUA or ULA addresses going away during the
> connection.
>
>
>
> Regards,
>
> Mark.
>
>
>
> I think it's even
> more wrong each time I look at it. For example, it has the consequence that
> if a pair of hosts have both RFC1918 and ULA addresses, the default for
> communication between them is RFC1918. D'Oh. If two hosts have ULAs in the
> same /64, they will nevertheless try IPv4 first. D'Oh. And the default
> table
> in RFC6724 is sticky in practice, even if configurable in theory.
>
> I think this needs serious work (in 6MAN most likely).
>
> Regards
>     Brian Carpenter
>
> On 25-Mar-22 00:29, Philip Homburg wrote:
> >> (Dual-stack cannot be the answer anyway - it will have all the issues
> >> of IPv4, plus the added complications of dual-stack.  Services need to
> >> be dual-stack, but for all the rest, single-stack IPv6 needs to be
> >> the end goal - see facebook etc)
> >
> > Obviously, on an IPv6-only system, there is no IPv4, so the relative
> > priority of ULA compared to IPv4 does not matter.
> >
> > I'm curious what IPv4aaS we want to deploy. I consider NAT64 a complete
> > disaster (even if the form of 464xlat). Given how the internet works,
> > we will probably end up with NAT64 everywhere until the end of times.
> >
> >> This is not what I had in mind.  If "we" decide that ULA is a good
> >> way forward, IETF can update RFCs, and vendors will eventually
> >> update their base OS.  It might take 5 years, but so will everything
> >> else in Big Enterprise land.
> >
> > The problem with ULA is that we have lots of installations where hosts
> with
> > a ULA address don't have access to the IPv6 internet. Often, CPEs
> announce
> > a ULA when the CPE doesn't have an IPv6 uplink.
> >
> > In contrast, where RFC 1918 was meant for local IPv4 communication, it is
> > now on a very large scale the primary method for a host to reach the IPv4
> > internet.
> >
> > So to avoid the situation where we say that ULA is local and then use it
> > to connect to the IPv6 internet, we should just allocate a new space. And
> > explicitly give it the property to connect to the IPv6 internet through
> > through some sort of address translation.
> >
> > There is also a nice tie-in with PI. Obviously, putting millions of PI
> > prefixes in BGP does not scale.
> >
> > On the other hand, there is no such limit if the PI space is used behind
> NAT.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> > .
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>