Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D743C228AFA for ; Tue, 5 Nov 2024 09:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPO3L8r73n72 for ; Tue, 5 Nov 2024 09:31:00 -0800 (PST) Received: from einhorn-mail-out.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64176C1DA1E1 for ; Tue, 5 Nov 2024 09:30:58 -0800 (PST) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de ([IPv6:2a0a:4580:1018:0:5054:ff:feb2:aa6a]) by einhorn.in-berlin.de with ESMTPS id 4A5HUrHc3596568 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 5 Nov 2024 18:30:53 +0100 Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtp (Exim 4.94.2) (envelope-from ) id 1t8NOH-0005GV-5k; Tue, 05 Nov 2024 18:30:53 +0100 From: Philipp Tiesel Message-Id: <1BE056D7-EB63-4952-9FB5-94F9CB00E86F@tiesel.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2C735E4-35C4-430F-9BA6-8C5E8F7766D0" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Date: Tue, 5 Nov 2024 17:30:42 +0000 In-Reply-To: To: Jen Linkova References: <172954645439.2070596.1455805667911500824@dt-datatracker-78dc5ccf94-w8wgc> <5009F747-6459-4F9F-BF83-C1F3437B5CC4@tiesel.net> <50DAE53B-06D5-4331-9C86-2D1B4A80B9BF@tiesel.net> X-Mailer: Apple Mail (2.3826.200.121) Message-ID-Hash: HH7PQUE5U2UJA6ODQFI3YBFFLTKUEMJQ X-Message-ID-Hash: HH7PQUE5U2UJA6ODQFI3YBFFLTKUEMJQ X-MailFrom: philipp@tiesel.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: V6 Ops List , Tommy Jensen X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bv6ops=5D_Re=3A_464XLAT_in_Multi-interface_environments_=28was?= =?utf-8?q?=3A_I-D_Action=3A_draft-ietf-v6ops-claton-02=2Etxt=29?= List-Id: v6ops discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_B2C735E4-35C4-430F-9BA6-8C5E8F7766D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jen, > On 4. Nov 2024, at 19:12, Jen Linkova wrote: >=20 > On Tue, Nov 5, 2024 at 1:08=E2=80=AFAM Philipp Tiesel = > 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. > > > > =E2=80=94> Can we replace that should with a MAY or better explain = it? >=20 > 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. >=20 > > Second, draft-ietf-v6ops-claton does not talk about source address = selection for CLAT. >=20 > I believe it does: > = https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-02.html#name-clat-= and-multiple-prefixes- >=20 > > 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=E2=80=A6 >=20 > I believe there are multiple problems here: > 1. What to do if the network provides the host with multiple PIOs with = A=3D1. 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=3D1 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=3D! 1b) What if there are multiple PIOs with A=3D1 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=E2=80=A6= 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. =20 > 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. =20 > 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." >=20 > 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=E2=80=A6 I guess no one wants = this! >=20 > 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=E2=80=A6 =20 --Apple-Mail=_B2C735E4-35C4-430F-9BA6-8C5E8F7766D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jen,

On 4. Nov 2024, at 19:12, Jen Linkova = <furry13@gmail.com> wrote:

On Tue, Nov = 5, 2024 at 1:08=E2=80=AFAM Philipp Tiesel <philipp@tiesel.net> 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.
>
> =E2=80=94> 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=E2=80=A6<= br>
I believe there are multiple problems here:
1. What to do if the network provides the host with multiple PIOs with = A=3D1. 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=3D1 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=3D!
1b) = What if there are multiple PIOs with A=3D1 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=E2=80=A6 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=E2=80=A6 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-deprecat= e7050/ 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=E2=80=A6
 

= --Apple-Mail=_B2C735E4-35C4-430F-9BA6-8C5E8F7766D0--