[v6ops] Re: New Version Notification for draft-link-v6ops-claton-03.txt

["[e-mail]" <[e-mail]>]

Hi Jen,

Very good document. Some inputs from my side, hopefully useful.

0) Abstract
   464XLAT ([RFC6877]) defines an architecture for providing IPv4
   connectivity across an IPv6-only network.  The solution contains two
   key elements: provider-side translator (PLAT) and customer-side
   translator (CLAT).  This document provides recommendations on when a
   node shall enable or disable CLAT.
I will say:

   464XLAT ([RFC6877]) defines an architecture for providing IPv4
   connectivity across an IPv6-only network.  The solution contains two
   key elements: provider-side translator (PLAT) and customer-side
   translator (CLAT), and optionally a DNS64.  This document provides recommendations on when a
   node shall enable or disable CLAT.
1) Intro
   464XLAT is widely deployed in 3GPP networks (as described in
   Section 4.2 of [RFC6877]) where a mobile phone performs the CLAT
   function, providing a private IPv4 address and IPv4 default route for
   the applications and tethered devices.  Enabling 464XLAT allowed
   mobile operators to migrate User Equipment (UE) devices (also known
   as mobile phones) to IPv6-only mode, where those devices are only
   assigned IPv6 addresses.
I will not use migrate (in general in any IETF IPv6 transition document), in many languages the “translation” or “reading” has the implication to fully disable IPv4, which is not the case (you migrate from Windows 10 to Windows 11, because Windows 10 is not longer running, but you transition from IPv4 to IPv6, because they still coexist). We keep confusing people when we use migration. One of the “IPv4” I think can be removed to make it shorter. I will say that the common case is mobile phone or CE (mobile router, a router with a 3GPP interface) Also, the IPv6 addresses are assigned on the WAN, just for clarity. So, I will say:

   464XLAT is widely deployed in 3GPP networks (as described in
   Section 4.2 of [RFC6877]) where a mobile phone performs the CLAT
   function, providing a private IPv4 address and the default route for
   the applications and tethered devices.  Enabling 464XLAT allowed
   mobile operators to transition User Equipment (UE) devices (typically
   mobile phones and CEs) to IPv6-only mode, where those devices, in the WAN interface, are only
   assigned IPv6 addresses, however still providing IPv4aaS (IPv4 as a Service) inside the device.
I think the only form of PLAT is NAT64, so 
	Even if the network provides PLAT in the form of NAT64
make it just shorter such as:
	Even if the network provides PLAT (NAT64)
It can be other kind of devices, so instead of:
   hosts like desktops and laptops still need the
   network to provide IPv4 addresses, as otherwise IPv4-only
   applications fail
use:
   hosts like desktops, laptops or other devices still need the
   network to provide IPv4 addresses, as otherwise IPv4-only
   applications and devices will fail

I think is still important to keep mentioning IPv4aaS so people don’t believe they loose IPv4:

   it becomes possible to
   migrate those devices to IPv6-only mode
So:

   it becomes possible to
   transition those devices to IPv6-only mode with IPv4aaS
Could be not just public Wi-Fi, so instead of:
   Networks such as public Wi-
   Fi, enterprise networks
use:
   Networks such as Wi-Fi hotspots, enterprise networks

Then, instead ensure that is well understood that the CLAT can be also in a CE:
   *  CLAT is performed by the host itself.
So:
   *  CLAT is performed by the host itself or a CE.
or
   *  CLAT is performed by the node (host or router).

Use CE across all the document instead of CPE, for consistency with previous documents? (7084, 8585, ...)

So instead of:

   Another 464XLAT deployment model is a Wireline one (section 4.1 of
   [RFC6877]), when a CPE router is connected to an IPv6-only network
 
Would be:
   Another 464XLAT deployment model is a Wireline one (section 4.1 of
   [RFC6877]), when a CE router is connected to an IPv6-only network
 
Actually in
This document complements [RFC6877] by providing
I think your document is complementing RFC8585 (or both of them)?

5) Enabling CLAT
I think it must be "CLAT MUST NOT” be enabled if.
and 
IPv6-only node MUST enable

I think here 8585 should be cited as well:
   If RAs received by the node do not contain a PREF64 option, the node
   MAY use other mechanisms to detect the PLAT presence and obtain the
   NAT64 prefix (such as [RFC7050], see also RFC8585). 

Instead of:
	has already obtained an IPv4 address.
may be:
	has already obtained an IPv4 address by other means.

Typo (extra coma, space) or something missing after 108: DHCP Option 108, 

May be we need to consider defining a maximum delay instead of "The delay is implementation specific”.

and "the node MUST disable CLAT"

I think this is not clear:
   The node MUST follow recommendations from Section 4 of [RFC7335] to
   avoid IPv4 address space conflicts.
You mean for the internal (LANs) IPv4 addressing, or for the translation if the CLAT don’t have a translation-reserved /64 obtained from the WAN prefix (so the CLAT performs first stateful NAT44 and then a stateless NAT46, instead of a stateless NAT46) ?

6) Disabling CLAT
so CLAT MUST NOT be enabled
The node
   MUST disable CLAT

7.1) CLAT IPv4 Addresses
We may need to clarify for what are those addresses used in a 1st paragraph in this section, as it may be confused with translation addresses … see my comment above.
Typo: Use 464XLAT instead of 464xlat
Same as in intro, replace public Wi-Fi networks, with Wi-Fi hotspot
Actually the comment that you do about “despite the word wireless” … is also applicable (reversed) in the dedicated prefix model, as you can use that model for an UE (tethering) or 3GPP router, etc. So I will say some more text is needed there similar to the one in the single-address model, so the reader get that. May be:
The dedicated prefix model, can be also used in wireless and 3GPP networks, and in that case there may be different possible architectures, such as as UE turns itself into a router providing one or multiple RFC1918 prefixes for different subnets, and using different IPv6 prefixes for different downstream networks, or shares a single prefix (RFC7278).

7.2) CLAT IPv6 Addresses
I don’t think this is right:
   However, deployments where each node can obtain a
   dedicated /64 just for CLAT are rather uncommon, to say the least.

For example, I recall (hopefully not wrong) that VPP implementation does that (Ole could confirm).
I’ve seen also some CE implementations doing that. A CE should receive in the WAN a /48 prefix, then uses one of the them for the translation. This allows a stateless NAT46 instead of stateful NAT44 + stateless NAT46. Clearly should be the preferred and recommended way. This document should “push” for that as well.

Instead of:
	The CLAT instance SHOULD obtain a dedicated IPv6
should be:
	The CLAT instance MUST obtain or reserve a dedicated IPv6
(case when the host is getting a single /64 instead of a single /128)

7.2.1) CLAT and Multiple Prefixes per Interface
Same reason as above:
 The CLAT instance MUST obtain or reserve a dedicated 

8) Updated to RFC8585
Unless I missed something, 464XLAT-5 has no changes? if that’s the case, I don’t think that paragraph need to be neither in the old/new text?



One last comment. Because at the beginning of the document its already said that the PLAT is a NAT64, may be for clarity/simplicity, in the rest of the document we can avoid using NAT64, and then use always just PLAT?






Regards,
Jordi

@jordipalet


> El 24 may 2024, a las 18:10, Jen Linkova <[e-mail]> escribió:
> 
> Hello,
> 
> Here is the updated version of the CLAT recommendations draft.
> The key changes:
> - some sections are reordered to improve readability
> - the draft now recommends disabling CLAT as soon as IPv4 connectivity
> becomes available (not doing so would have not just performance
> implications but security ones as well)
> - a (simplified) diagram is added to illustrate the logic of enabling
> and disabling CLAT.
> 
> Comments are appreciated.
> 
> 
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Sat, May 25, 2024 at 1:54 AM
> Subject: New Version Notification for draft-link-v6ops-claton-03.txt
> To: Jen Linkova <[e-mail]>, Tommy Jensen <[e-mail]>
> 
> 
> A new version of Internet-Draft draft-link-v6ops-claton-03.txt has been
> successfully submitted by Jen Linkova and posted to the
> IETF repository.
> 
> Name:     draft-link-v6ops-claton
> Revision: 03
> Title:    464 Customer-side Translator (CLAT): Node Recommendations
> Date:     2024-05-24
> Group:    Individual Submission
> Pages:    14
> URL:      https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.txt
> Status:   https://datatracker.ietf.org/doc/draft-link-v6ops-claton/
> HTML:     https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-link-v6ops-claton
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-link-v6ops-claton-03
> 
> Abstract:
> 
>   464XLAT ([RFC6877]) defines an architecture for providing IPv4
>   connectivity across an IPv6-only network.  The solution contains two
>   key elements: provider-side translator (PLAT) and customer-side
>   translator (CLAT).  This document provides recommendations on when a
>   node shall enable or disable CLAT.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> Cheers, Jen Linkova
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.