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

[Philipp Tiesel <[e-mail]>]

Hi Jen,

> On 4. Nov 2024, at 19:12, Jen Linkova <[e-mail]> wrote:
> 
> On Tue, Nov 5, 2024 at 1:08 AM Philipp Tiesel <[e-mail] <mailto:[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.

This is even at least two problems:
1a) What if there are multiple routers on a given Interface provide PREF64 option and PIO with A=!
1b) What if there are multiple PIOs with A=1 from a single router.

In case 1a, I would expect that the OS may spin up multiple CLAT instances
In case 1b, I would expect that the OS may spin up one CLAT instance and use regular prefix-policy-table to select a source prefix for the CLAT address.

After doing all that setup, we assume a new flow through the CLAT… So we have the whole prefix-policy-table / Rule 5.5 magic deciding which CLAT to use and then no address selection as each CLAT is fixed to a CLAT address.
    
> 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.

We get that magically if each CLAT is tied to a router to begin with.
This results in having one time prefix-policy-table / Rule 5.5 magic before CLAT and a second time after CLAT… I guess no one wants this!
> 
> 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...

Again, this is trivial if we have a CLAT instance per router and a pain of not.

> 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/)

We can make our life even more miserable if we exercise 7050 for each (router) that has not provided a PREF64 and fire up CLAT instances for them…