Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-00.txt

[Nick Buraglio <[e-mail]>]

On Tue, Oct 24, 2023 at 5:04 AM Ted Lemon <[e-mail]> wrote:
>
> I hadn't had a time to read the new document until just now. Thanks for
pointing this issue out, Ole—I had thought that the plan was to require the
ULA/48<->ULA/48 automation suggested in 6724, not to just modify the table
to assume that any ULA <-> any ULA will always work. I agree that this is
incorrect.

IIRC, we had discussed making this a MUST and it was not a popular option.
I don't have the thread here in front of me but if I remember it was on the
v6ops list and was not well received. The issue is as Ole pointed out, the
wording is "Since ULAs are defined to have a /48 site prefix, an
implementation *might* choose to add such a row automatically on a machine
with a ULA.”, which as we detailed in
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula/ is an operations
non-starter in a non-trivial percentage of implementations. This makes that
design option exceedingly hard to implement and support, specifically on
kit that needs it (such as cameras, IOT, OT, and other embedded systems).
This approach was seen as a best case, short term given that ULA is by
design meant to be local. ULA to ULA that is outside of the /48 scope
perhaps *should* fail, by the current definition of how use is intended.
Then there is, of course, the fact that applications can still do whatever
they'd like (for example, older versions of Java disable IPv6 by default
and could, in theory, disable or require ULA use).

>> Ordered SA, DA pairs (winner at bottom):
>> 192.168.10.10 -> 198.51.100.121
>> fd00::1 -> fd00:dead:beef::1

>> Which isn’t necessarily going to work. For outside the ULA zone,
wouldn’t it be better to use global?

Probably. That feels to me like a caveat in the happy eyeballs section. In
the cases that a network is dual stacked and only has ULA, ULA will win but
fail, and in some cases HE will force IPv4 use (without the presence of an
IPv6 translator).
If we add that caveat, which is probably more of an edge case than a
typical deployment, would that be sufficient?

>
> On Tue, Oct 24, 2023 at 11:56 AM Ole Troan <otroan=
[e-mail]> wrote:
>>
>>
>>
>> > On 24 Oct 2023, at 04:09, Brian E Carpenter <
[e-mail]> wrote:
>> >
>> > On 24-Oct-23 10:46, Ole Troan wrote:
>> >>>>> On Mon, Oct 23, 2023 at 4:29 PM Brian E Carpenter <
[e-mail]> wrote:
>> >>>>> On 24-Oct-23 05:32, Kyle Rose wrote:
>> >>>>>> Just to clarify one thing in my previous email (and in so doing
to further demonstrate how complex address selection is even without Happy
Eyeballs):
>> >>>>>>
>> >>>>>> Given an IPv6 destination address, SAS as currently formulated
*irrespective of any changes we make to the default policy table* will
return a ULA if that is the only v6 address the client has. As it should!
>> >>>>>>
>> >>>>>> My *preference* is for the combined DAS/SAS address selection
algorithm examining all the (source,dest) pairs for all of a host's A/AAAA
records to put the (v4,v4) pair before the (ULA,GUA) pair because I expect
the former to work and the latter to fail, for the reasons I mentioned.
>> >>>>>
>> >>>>> And that's *exactly* why we need a "NPTv6 present" flag that
defaults to False.
>> >>>>>
>> >>>>> With some mechanism for turning it on. As suggested elsewhere,
putting it in the router advertisement would be a good spot, because I'm
not sure deriving it empirically is the right approach either (since some
networks might enable NAT66 as fallback but with severe performance
penalties).
>> >>>>>
>> >>>>> But, to Nick's plea, also not for 6724bis.
>> >>>> We have a separate draft on NTPv6-bis.
>> >>>> I’m not at all convinced we need a flag for NTPv6.
>> >>>
>> >>> I'm totally convinced that we do, from trying to write code without
it.
>> >> Well, this email uses it as transport without the flag…
>> >
>> > I'm sure we can make anything work; my implementation of the flag
works by attempting a connection. The point of the flag is to ensure that
ULA->GUA is excluded from the choices unless it actually works. True, HE
will exclude it anyway but not all apps use HE. The more of HE's logic that
we can move to the kernel, the better.
>> >
>> > (Hmm. Being honest, I haven't actually tested the ULA->GUA success
path, because I don't have NPTv6 installed. But I do have NAT44 installed,
and the logic for RFC1918->Global IPv4 is identical.)
>>
>> Trying to read 6724 + 6724-update and deduce behaviour turned out to be
so tricky that I wrote a little 6724/update implementation.
>>
>> ULA -> GUA works the same for both 6724 and 6724-update:
>>
>> Sources:
>> [fd00::1, fe80::1, ::ffff:c0a8:a0a, ::ffff:a9fe:d4e]
>>
>> Destinations:
>> 2a02:26f0:4300:289::b33
>> 2a02:26f0:4300:28e::b33
>> 104.110.1.61
>>
>> Ordered SA, DA pairs (winner at bottom):
>> fd00::1 -> 2a02:26f0:4300:28e::b33
>> fd00::1 -> 2a02:26f0:4300:289::b33
>> 192.168.10.10 -> 104.110.1.61
>>
>> Both prefers v4 in this case. But HE takes care of that, so that’s fine.
>> With or without a flag, you’d like the implementation to try.
>>
>> With 6724-update, ULA to ULA will be preferred. And in the below example
since you are exiting the site, you’d also expect the implementation to
probe.
>>
>> Sources:
>> [2001:db8::1, fd00::1, fe80::1, ::ffff:c0a8:a0a, ::ffff:a9fe:d4e]
>> Destinations:
>> fd00:dead:beef::1
>> 198.51.100.121
>>
>> Ordered SA, DA pairs (winner at bottom):
>> 192.168.10.10 -> 198.51.100.121
>> fd00::1 -> fd00:dead:beef::1
>>
>> Which isn’t necessarily going to work. For outside the ULA zone,
wouldn’t it be better to use global?
>>
>> Which brings me to the main point:
>> "Since ULAs are defined to have a /48 site prefix, an implementation
>> might choose to add such a row automatically on a machine with a ULA.”
>>
>> Is from RFC6724. Why wouldn’t have this implemented be enough?
>> And push implementations to do this instead of respinning 6724.
>>
>> O.
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------