What to do if the PREF64 changes on the fly while CLAT is running

[furry13]

e.g RA with PREF64 arrives and it's different from one discovered via 7050

[furry13]

Another cases:

• the only prefix got deprectaed
• lifetime expired
• renumbering

[mstojens]

Noting: another fun case is when one prefix channel (say, RA) sends a prefix valid for a long time, then while it's still valid, another channel (say, DNS) sends that same prefix with a 0 lifetime. We will stop using it right away, but it's worth calling out as "network misconfig" not "scenario we need to support"

[furry13]

fun case is when one prefix channel (say, RA) sends a prefix valid for a long time, then while it's still valid, another channel (say, DNS) sends that same prefix with a 0 lifetime. We will stop using it right away

nooooooo! ;)

First of all, unless I'm mistaken, there is no 'lifetime' in 7050 ;)

Secondly, https://datatracker.ietf.org/doc/html/rfc8781#name-handling-multiple-nat64-pre

"When different PREF64s are discovered using multiple mechanisms, hosts SHOULD select one source of information only. The RECOMMENDED order is:

1. PCP-discovered prefixes [RFC7225], if supported;
2. PREF64s discovered via the RA Option;
3. PREF64s resolving an IPv4-only fully qualified domain name [RFC7050] "

The host shall use one method at any given time, otherwise it will be such a mess!!

[mstojens]

We discussed this offline, but the DNS route does have a TTL, so we would treat that as a prefix validity lifetime. Ok, so it makes sense that we would switch from DNS to RA when they both present prefixes regardless of receive order.

What edge case concerns me is this:

• DNS gives us Prefix A with TTL of 86400
• <100 seconds pass>
• RA gives us Prefix A with lifetime of 0 and no other prefix

In this scenario, we could do two things, neither of which is obviously correct to me:

• Switch to RA because it takes precedence, leaving us with no valid prefix, and abandon CLAT
• Stay with DNS, continue using CLAT (assuming the prefix does in fact work), but appear to violate RA preference over DNS

In the first case, we have a regression of connectivity that may be avoidable, and in the second case we open ourselves up to attack (because the DNS avenue is more readily spoofed than the RA path).

[mstojens]

Discussed offline -- RA always takes precedence, and therefore in the scenario above, the CLAT node shall lose connectivity until another prefix is discovered.

I'm leaving this open because I'm thinking it might (or might not) be worth calling out this as an example that "we really mean that RA takes precedence".

[mstojens]

Ok, it does already say this, and this issue is now just a testament to me not internalizing what priority sorting data sources is. We can add clarifications if someone other than me sees the same confusion.'

(unless you disagree @furry13 but then I think we need to clarify what the scope of the needed change is)