Re: Network merge [Re: RFC6724-bis?]

[Ted Lemon <[e-mail]>]

On Tue, Sep 27, 2022 at 6:34 PM Mark Smith <[e-mail]> wrote:

> On Wed, 28 Sept 2022 at 07:21, Ted Lemon <[e-mail]> wrote:
> >
> > The point of this is not to mitigate a non-problem—that of ULA prefixes
> in the DNS. That's not a problem. The point of this is to make things that
> don't currently work but are valid configurations work.
> >
>
> So RFC 6724 uses RFC 5220 sections 2.1.4, 2.2.2, and 2.2.3 to justify
> the position of FC00::/7 in the destination address order (10.6.
> Configuring ULA Preference). Those issues would usually occur when
> non-local and therefore non-reachable ULA AAAAs are in global DNS and
> is then returned in the set of DAs in the getaddrinfo() call.
>

Right, this makes sense.


> How common is this valid configuration you're referring to?
>

We'd like it to be common in cases where it's needed. Specifically, right
now if two enterprises merge, they generally will have disjoint RFC1918
address spaces per org, and the merge is typically done with a NAT between
the two networks, which is an utterly crappy solution. ULA provides a way
for orgs to do internal numbering so that if a merge like this happens, the
need for a NAT66 between the two orgs is vanishingly unlikely.

So in this case you would have two orgs, both with their own independent
ULA prefixes, and you'd like to prefer those prefixes when communicating
between orgs. That's the use case. I'd say it's pretty uncommon at present,
but it's a valid use case that we'd prefer to see over what we are seeing
now, so we need to address it (I think).

Default DA/SA selection is static, and therefore should be a best
> guess based on the likely most common case scenario. It is static in
> the sense that it doesn't adapt to the state of the network, where one
> moment an IPv4 DA might be better than all of IPv6 DAs, another moment
> a GUA DA would be better than ULA DA, and then another moment a ULA DA
> would be better than all other IPv4 and IPv6 DAs.
>
> That's why there is this advice in RFC 6724, that adapts to different
> default selected DAs being better or worse at any particular time:
>
> 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.
>
> I think the fundamental problem is people think the first DA returned
> by getaddrinfo() must always be the address that successfully
> connects.
>

I don't think that's the case. Unless you are racing connections, which
isn't ideal, there is a cost to guessing wrong, even if it's not total
failure. So e.g. in an IoT situation with battery-operated devices, you'd
really like to guess the right SA/DA pair the first time, not try fifteen
different combinations.

They probably think that because they want to avoid the huge and very
> unuser-friendly connection timeouts that are the default for transport
> layer protocols today.
>
> I doubt IPv6 multi-addressing is going to go away, so static default
> DA/SA selection will always have the possibility of the statically
> selected first DA in the set not being the ideal one at the time.
>

Yup. This isn't about achieving perfection. It's about doing better.


> So I think the real solution is to fix what the real problem with
> being provided with a set of DAs to connect to is - in the transport
> layer protocol initial connection timeouts.
>
> Looking at the new TCP RFC, RFC 9293, it seems the default RTO for the
> 3 way handshake is 100 seconds (I've seen much larger in other places
> e.g. Stevens' TCP/IP Illustrated says up to 9 minutes!). I think it
> should be much lower than that, in the order of no more than something
> like 1 or 2 seconds, and the common case of walking through and
> attempting to connect and then successfully connecting to a DA in the
> set returned by getaddrinfo() should be about 10 seconds (Response
> Times: The 3 Important Limits -
> https://www.nngroup.com/articles/response-times-3-important-limits/ )


Maybe if we can get rid of bufferbloat. I often find the more rapid
connection timeouts that are typical in web servers to be problematic
though e.g. in an airplane: even though the network is congested and has
bad bufferbloat, if you allow the connection to survive for longer times,
you can make progress. If you just give up after ten seconds or whatever,
then you may never succeed in fetching the resource. So I'm really not in
favor of this approach—even if it works fine in the networks we are
privileged to use most of the time, it's going to suck for users who aren't
as fortunate as we are.