[v6ops] Re: 464XLAT in Multi-interface environments (was: I-D Action: draft-ietf-v6ops-claton-02.txt)

[Jen Linkova <[e-mail]>]

On Tue, Nov 5, 2024 at 1:08 AM Philipp Tiesel <[e-mail]> wrote:
> I found two other issue:
>
>
> First, Section 7.1 states the following:
> > If the node runs multiple CLAT instances (see Section 4), the node
> > SHOULD use different local IPv4 addresses for each CLAT instance.
>
> MacOS is doing that differently and uses 192.0.0.2 on all interfaces,
> which is fine unless the OS was unable to select an output interface
without binding to the interface IP
> or would not support the same IP on multiple interfaces.
>
> —> Can we replace that should with a MAY or better explain it?

I'd love to hear what the implementers think. I assumed - apparently
incorrect - that it's easier to use different addresses. But if it doesn't
provide benefits, we can drop that requirement.

> Second, draft-ietf-v6ops-claton does not talk about source address
selection for CLAT.

I believe it does:
https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-02.html#name-clat-and-multiple-prefixes-

> I only stumbled over this issue as macOS, if there a multiple prefixes in
the same RA as the PREF64 option, prefers ULA over GUA as CLAT IP address,
which broke some things at home for me.
>
> If we follow the source address selection in rfc6724 or
draft-ietf-6man-rfc6724-update, the well-know prefix or any non-ULA custom
prefix would match ::/0 , the same-label rule would require the source for
the packages leaving the v6 side of the CLAT should be a GUA.
> On the other hand, the CLAT address is not chosen per flow, but on
creation of the CLAT, so what does not apply directly.
>
> A way around this issue is following the model in draft-link-v6ops-gulla,
so by putting the PREF64 only on the GUA or ULA RA would allow the operator
to choose.
>
> I suspect we should talk about how we expect this to behave…

I believe there are multiple problems here:
1. What to do if the network provides the host with multiple PIOs with A=1.
Our experience confirms that  MacOS only picks up one prefix to form the
CLAT address. This is clearly an issue, as it means that CLAt might not
work very well in a multihoming scenarios or if the network was
flash-renumbered. This is explicitly described in the draft: all PIOs with
A=1 shall be used for PREF64.

2. What to do if there are multiple routers, and only some of them includes
a PREF64 option. So you are suggesting that PIOs SHOULD only be used to
form a CLAT address, if the same RA contained PREF64? That's an interesting
suggestion.
Especially if we imagine for a second that the host might get multiple
PREF64.
As per Section 3 of RFC7050:
"The node MUST use all learned Pref64::/n
   when performing local IPv6 address synthesis and use the prefixes in
   the order received from the DNS64 server.  That is, when the node is
   providing a list of locally synthesized IPv6 addresses to upper
   layers, IPv6 addresses MUST be synthesized by using all discovered
   Pref64::/n prefixes in the received order."

So we might have the following cases:
2.1 all routers provide the same PREF64. Easy: as per the current version,
CLAT addresses are formed from all PIOs. and rule 5.5 is used to select an
address.
2.2 all routers provide PREF64 but those prefixes are different. The only
way to make it work is to track {PIO, PREF64, router} mapping, form
addresses from all PIOs, use Rule 5.5 and use the correct PREF64 for
translation. Complicated but, I guess, doable.

2.3 only *some* routers provide PREF64, some don't. As I do not think we
can - for any foreseeable future - expect IPv6-only networks w/o NAT64, I
guess we can assume that even if a router doesn't send PREF64 on an
IPv6-only segment, that network must still provide NAT64. However, things
could get badly broken if the prefix is different to one provided in
PREF64. So there is no guarantee that the same prefix can be used for
routers which do not advertize pref64. So yes, maybe only addresses from
PIOs received together with PREF64 shall be used...

2.4 No routers advertizes PREF64. Then, as per the draft, the node MAY use
other mechanisms. If it's the same prefix, then Rule 5.5 ensures that the
correct source is used. However if there are multiple prefixes, it's going
to be a disaster - another argument in favour of not using 7050 (This might
need to be mentioned in
https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ and
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6mops/)