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

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

Hi Jen,

Sorry, missed this email before.

My inputs below, in-line.

Regards,
Jordi

@jordipalet


> El 10 jun 2024, a las 16:03, Jen Linkova <[e-mail]> escribió:
> 
> Hi Jordi,
> 
> Thank you very much for your review and comments.
> 
> On Sat, May 25, 2024 at 8:44 PM [e-mail]
> <jordi.palet=[e-mail]> wrote:
> 
>> 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.
> 
> I do hope that we shall be able to get rid of DNS64 soon and this
> draft might outlive DNS64.
> How strongly do you feel about mentioning DNS64 here? As it’s a rather
> optional element, I have a slight preference to not overload the
> text..
> 

In my experience, DNS64 is good to have. I’ve not seen real impact on DNSSEC, in part because DNS64 servers handle it, in part because the deployment of DNSSEC (and host validation) is very low. If there is no DNS64 464XLAT still work, but it has the impact of unnecessary double translation.

I’m ok if not mentioned in the abstract, but keeping it in the relevant sections.

> 
>> 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.
> 
> How about this:
> 
> “464XLAT is widely deployed in 3GPP networks (as described in Section
> 4.2 of  RFC6877) where User Equipment (UE) devices (such as mobile
> phones and CE routers) perform the CLAT function, providing a private
> IPv4 address and default route for the applications and tethered
> devices. Enabling 464XLAT allowed mobile operators to transition UE
> devices (also known as mobile phones) to IPv6-only mode, where those
> devices are only assigned IPv6 addresses on their WAN interfaces.”
> 
> 
> I’m dropping IPv4aaS as the first sentence does say that applications
> and tethered devices get IPv4.
> 

I’m fine with that, but note that UE is not just a mobile phone, it may be a tablet, or a laptop with a SIM. May be just remove "(also known as mobile phones)”.

> 
>> 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)
> 
> I’ve realized that it’s the first time NAT64 is mentioned, so it would
> make sense to add a reference here. So to make it more readable I’d
> suggest keeping “in the form”:
> 
> “Even if the network provides PLAT in the form of NAT64 (RFC6146).."
> 
>> 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
> 
> How about:
> “hosts (desktops, laptops etc) still needed the network…”
> 
>> 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
>> 
> 
> Thanks, we'll update the text.
> 
>> 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).
> 
> This paragraph is describing the “Wireless” mode (CLAT on a host)
> outside of 3GPP - in Wi-Fi hotspots, enterprise networks etc. So in
> this scenario it’s important that CLAT is performed by a host, not a
> CE router.

The point is that there are UEs that are CE. For example, a well known case is T-Mobile that provided a CE with 464XLAT for broadband provisioning, as they don’t have GPON, etc.

> 
>> Use CE across all the document instead of CPE, for consistency with previous documents? (7084, 8585, ...)
> 
> At the same time RFC6877 uses ‘CPE’.  I’ve always assumed ‘CE’ and
> ‘CPE’ can be used as  synonyms...
> 
>> This document complements [RFC6877] by providing
>> I think your document is complementing RFC8585 (or both of them)?
> 
> Will change to “This document complements [RFC6877] and updates [RFC8585] “
> 
>> 5) Enabling CLAT
>> I think it must be "CLAT MUST NOT” be enabled if.
> 
> Yes, that was Jeremy's comment too. The next revision will have that change.
> 
>> and
>> IPv6-only node MUST enable
> 
> The full sentence:
> "Therefore an IPv6-only node SHOULD enable CLAT as soon as an Router
> Advertisement containing PREF64 option is received."
> To be honest I have some reservations re: changing this particular
> SHOULD to MUST.
> 
> If we say ‘MUST’ would it make any host which doesn’t do it
> non-compliant. However I, for example, have a significant number of
> devices which are IPv6-only but they do not have clat enabled, because
> they only need (allowed to) talk to a very limited set of destinations
> - and all those destinations are IPv6-enabled. So I do not want those
> devices to enable CLAT at all. So I think we shall allow
> implementations to be configured to have CLAT disabled.
> 
>> 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).
> 
> I do not think 8585 defines any new mechanisms to obtain/discover the
> NAT64 prefix.
> 
>> Instead of:
>>        has already obtained an IPv4 address.
>> may be:
>>        has already obtained an IPv4 address by other means.
> 
> With the proposed change the sentence will read:
> "The node SHOULD enable CLAT after discovering the NAT64 prefix,
> unless by that time the node has already obtained an IPv4 address by
> other means".
> I might be missing smth but "by other means" is a bit confusing here,
> as it's not clear what "other" refers to..
> 

other means, other methods … anyway I understand that there was also some other discussion on several of the SHOULDs vs MUSTs

> 
>> Typo (extra coma, space) or something missing after 108: DHCP Option 108,
> 
> Thank you, fixed.
> 
>> May be we need to consider defining a maximum delay instead of "The delay is implementation specific”.
> 
> If we want to do this, I’d rather specify the default value and let
> implementations choose whether they want to use it or not. I guess the
> delay shall be comparable with an RTT between the client and the DHCP
> server(s) - but I do not know what value to choose here. Any
> suggestions?

The reason why we needed HE was because the fallback delay from IPv6 to IPv4 was not predefined … I think we should avoid those type of situations. The problem is that the RTT to DHCP servers can vary a lot in different contexts.

> 
>> 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) ?
> 
> RFC7335 is very specific to 192.0.0.0/29.
> 
> Would it be more clear if we change the text to “If the node supports
> multiple IPv4 continuity solutions, the node MUST follow
> recommendations…”?

Yep

> 
>> 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.
> 
> We'll add some text to clarify that, thank you!
> 
>> 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).
> 
> How about adding the following text:
> "Despite the word "wireline", this architecture is applicable for
> wireless or 3GPP routers: such router can provide IPv4 connectivity to
> connected devices, performing CLAT functions for traffic sent/received
> via the IPv6-only uplink interface


Yep

> 
>> 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.
> 
> I agree, the text needs to be relaxed a bit - I was thinking about
> enterprise/public WiFi cases mostly, where CLAT nodes do not get
> prefixes, only addresses.
> 
>> Clearly should be the preferred and recommended way. This document should “push” for that as well.
> 
> I do not think it’s realistic. Please do not forget that this
> document is not just for CE or 3GPP cases, but for hosts like laptops
> and desktops. Obtaining /64 per each laptop would be only possible in
> networks which implement pd-per-device draft, and we can not expect it
> to happen everywhere. Also, there are networks which do not have
> scalability issues which would justify pd-per-device. If we make clat
> require /64 it might be seen as a reason not to deploy v6-mostly. In
> single-address model, the CLAT instance only needs a single IPv6
> address, not /64
> 

Understood, so just recommending it when possible.

> 
> However it just occurred to me that  we might want allow  that for
> each IPv4 address the instance obtain an IPv6 address - either via
> SLAAC on the upstream side, or - in case of PD-per-device - from the
> delegated /64
> 
> So I think we shall add smth like:
> "In a dedicated prefix model, the instance MAY obtain a dedicated IPv6
> address for each CLAT IPv4 address."

Yes, that will work.

> 
>> 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?
> 
> I was minimizing the number of “old/new” blocks, so I included XLAT-5
> as it’s located between XLAT-4 and -6, both of them being changed.
> I’ll split it in two, if it’s more readable.
> 
> 
>> 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?
> 
> Good point, we'll clean up the text a bit.
> 
>>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> 
> 
> -- 
> 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.