[v6ops] Re: draft-ietf-v6ops-rfc6146-bis-07 ietf last call Opsdir review

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

Hi Tony,

Tks a lot for the review.

Let me clarify why we did a bis and we decided that path in v6ops.

The main intent of the effort was to advance RFC6146 to Internet Standard (https://datatracker.ietf.org/doc/draft-palet-v6ops-nat64-std/) According to RFC6410, that means:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

-> This is why we have the new section 6

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

-> There were two erratas, which have been corrected, but none of them affect the interoperability.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

-> This is the case.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

-> Nothing changed vs the original RFC6146.

So, having a -bis to advance the document to IS and then another document to update the actual new usages of the protocol, which doesn’t change the protocol itself, seems avoidable if we can just do the bis, that is obsoleting the original RFC6146. Anyway, I’m happy to understand if this is not the correct path and we should do it in a different way.

Again thanks a lot for your detailed review. I’m ok with almost all the proposed changes, see below in-line.


Regards,
Jordi

@jordipalet

> El 26 jun 2026, a las 22:17, Tony Li via Datatracker <[e-mail]> escribió:
> 
> Document: draft-ietf-v6ops-rfc6146-bis
> Title: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
> Reviewer: Tony Li
> Review result: Not Ready
> 
> OPSDIR Last Call Review of draft-ietf-v6ops-rfc6146-bis
> 
> Reviewer: Tony Li
> Status: 
> 
> Disclaimer: I loathe IPv6.  I know that this is not news to anyone,
> but it will undoubtedly bias my review despite my best attempts to be
> objective and it would be inappropriate to not disclose it.
> 
> Overall: Not ready.
> 
> This document should be reconsidered. A bis is intended to correct
> significant errors in a specification. It is not an opportunity to
> tweak the document to reflect additional details. This content should
> be a separate document that updates 6146.
> 
> Details:
> 
> Section 1:
> 
> OLD
> 
> 	which is commonly implemented, for example, following the same approach as	
> 	for Explicit Address Mappings for Stateless IP/ICMP Translation	
> 	[RFC7757].
> 
> NEW
> 
> 	which is commonly implemented following the same approach as	
> 	for Explicit Address Mappings for Stateless IP/ICMP Translation	
> 	[RFC7757].
> 
> I suggest removing ", for example," as this just makes the sentence
> awkward and adds no semantics. If the point is to suggest that 7757 is
> not mandatory and "commonly" feels too strong, then how about
> "usually"?
> 
> OLD
> 
> 	This DNS64 synthesis can also be done in the IPv6 clients (self-synthesis).
> 
> NEW
> 
> 	This synthesis can also be done in the IPv6 clients (self-synthesis).
> 
> In fact, once the synthesis is done by the client, it is no longer
> DNS64 at all.
> 
> OLD
> 
> 	*  an IPv6-only-strict client (i.e., a host with a networking
>           stack that only implements or uses IPv6)
> 
> NEW
> 
> 	*  an IPv6-only-strict client (i.e., a host with a networking
>           stack that only implements IPv6)
> 
> What does it mean to use IPv6 if you don't implement it? Is that even
> possible? The proposed wording is unneessarily confusing.


We can have a client that implements both IPv4 and IPv6, however, is actually using IPv6. IPv4 is implemented (it is a dual-stack client), but is only using IPv6.

Note that I’m not a native english speaker, so may be the wording is not correct.

> 
> OLD
> 
> 	   *  a dual-stack client willing to use only IPv6 connectivity	
> 	      (IPv6-Mostly [RFC8925] case)
> 
> NEW
> 
> 	   *  a dual-stack client willing to use only IPv6 connectivity	
> 	      (IPv6-Mostly [RFC8925])
> 
> You're already dealing with one case per bullet, so explicitly calling
> this a case is redundant.
> 
> OLD
> 
>           Note that in some	
> 	   cases, when using NAT64 together with other machanisms (such as a	
> 	   464XLAT [RFC6877] customer side translator - CLAT), this may be	
> 	   possible even just using NAT64, without the need of DNS64.
> 
> NEW
> 
>           Note that in some	
> 	   cases, when using NAT64 together with other mechanisms (such as a	
> 	   464XLAT [RFC6877] customer side translator - CLAT), this may be	
> 	   possible just using NAT64, without the need of DNS64.
> 
> This fixes a typo and removes a redundancy.  Please proof-read and run
> a grammar check on your documents before requesting external review. 
> 
> OLD
> 
>           Across the rest of this document, for short, IPv6-only client or	
> 	   node, unless explicitly stated, will apply for any of the cases	
> 	   enumerated in the preceding paragraph.
> 
> NEW
> 
> 	   For the remainder of this document, an IPv6-only client or
> 	   node refers to one of the cases enumerated in the preceding
> 	   paragraph, unless explicitly stated otherwise.
> 
> OLD
> 
>   	   These mechanisms are playing a critical role in IPv4-IPv6 transition	
> 	   and coexistence.
> 
> NEW
>   	   These mechanisms play a critical role in IPv4-IPv6 transition	
> 	   and coexistence.
> 
> OLD
> 	   As a result of public IPv4 address depletion and	
> 	   the limited size of [RFC1918] addressing space (in hyperscale data	
> 	   centers or mobile networks, for example), new clients are IPv6-only	
> 	   and still need to connect to the existing IPv4-only
> 	   servers.
> 
> NEW
> 	   Due to public IPv4 address depletion and	
> 	   the limited size of the [RFC1918] address space (in hyperscale data	
> 	   centers or mobile networks, for example), new clients are IPv6-only	
> 	   and still need to connect to the existing IPv4-only servers.
> 
> OLD
> 
> 	   Main changes are listed in Appendix "Appendix: Changes
> 	   since RFC6146".
> 
> NEW
> 
> 	   The primary changes are listed in the Appendix.
> 
> OLD
> 
> 	   Since the original NAT64 [RFC6146] specification was published in	
> 	   2011, NAT64 has been widely and succesfully deployed across many	
> 	   networks, with great success.
> 
> Please reconsider this.  Is this really necessary?  At this point,
> this seems self-congratulatory.

I think is key as justification of multiple implementations successfully deployed in order to advance it to IS.

One possibility is to move this text to the implementation status section.

> 
> Section 1.1:
> 
> OLD
> 	  This helps with the IPv4 address exhaustion. The NAT64 can
> 	  even be operated as a service by other parties, not
> 	  necessarily the service provider providing the Internet
> 	  connectivity.
> 
> NEW
> 	  This helps with IPv4 address exhaustion. NAT64 can
> 	  even be operated as a service by other on-path parties, not
> 	  necessarily the service provider providing the Internet
> 	  connectivity.
> 
> Section 5:
> 
> OLD
> 
>          Since [RFC6146] was published, there have been a notable
> 	  number of specifications that, making use or working
> 	  together NAT64, have allowed very relevant improvements
> 	  towards the deployment of IPv6, greatly facilitating the
> 	  transition.
> 
> NEW
> 
>          Since [RFC6146] was published, there have been a notable
> 	  number of specifications that, in conjunction with NAT64,
> 	  have made significant improvements in the deployment of
> 	  IPv6, greatly facilitating the transition.
> 
> OLD
> 	  NAT64 does not make an assumption about whether WPK or
> 	  Network Specific Prefix (NSP) is used.  Such decision is
> 	  deployment-specific.  However, [RFC6052] used to have a
> 	  deployment constraint for the use of WKP and includes a
> 	  guard against the use of non-global IPv4 addresses.  This
> 	  guard is relaxed in [I-D.ietf-v6ops-nat64-wkp-1918].
> 
> NEW
> 
> 	  NAT64 does not make an assumption about whether the WPK or
> 	  a Network Specific Prefix (NSP) is used.  Such a decision is
> 	  deployment-specific.  However, [RFC6052] used to have a
> 	  deployment constraint for the use of the WKP and includes a
> 	  restriction against the use of non-global IPv4 addresses.  This
> 	  restriction is relaxed in [I-D.ietf-v6ops-nat64-wkp-1918].
> 
> OLD
> 
> 	  Further, [RFC8215] specify a Local-Use IPv4/IPv6 Translation Prefix,	
> 	  adjacent to the WKP, facilitating the coexistence of multiple IPv4/	
> 	  IPv6 translation mechanisms in a single network domain.
> 
> NEW
> 
> 	  Further, [RFC8215] specifies a Local-Use IPv4/IPv6 Translation Prefix,	
> 	  adjacent to the WKP, facilitating the coexistence of multiple IPv4/	
> 	  IPv6 translation mechanisms in a single network domain.
> 
> Section 5.2
> 
> OLD
> 
> 	   [RFC7050], updated by [RFC8880], defines a best effort method for	
> 	   clients to discover the Pref64::/n being used by the NAT64.
> 
> NEW
> 
> 	   [RFC7050], updated by [RFC8880], defines a best effort method for	
> 	   clients to discover the IPv6 prefix being used by the NAT64.
> 

I’m fine with the change, we used Pref64::/n as it was the notation being used across the document. You don’t think is much clear keeping the same notation. Same in the following comment.

> OLD
> 	  In order to improve the discovery of the Pref64::/n, [RFC8781]	
> 	   specifies a ND option to be used in RAs.  [RFC9872] further provides	
> 	   a recommendation for using [RFC8781] instead of [RFC7050].
> 
> NEW
> 
> 	  In order to improve the discovery of the IPv6 prefix, [RFC8781]	
> 	   specifies an ND option to be used in RAs.  [RFC9872] further provides	
> 	   a recommendation for using [RFC8781] instead of [RFC7050].
> 
> OLD
> 
> 	  Section 3 of "Analysis of Solution Proposals for Hosts to Learn NAT64	
> 	   Prefix" [RFC7051] already exposed the issues of the NAT64 prefix	
> 	   discovery, most of them resolved by [RFC8781], nonetheless it is	
> 	   important for operators to review that in order to ensure a proper	
> 	   deployment.
> 
> NEW
> 
> 	  Section 3 of [RFC7051] already exposed the issues of NAT64 prefix	
> 	   discovery, and most of them are resolved by [RFC8781], but it is	
> 	   important for operators to review that in order to ensure a proper	
> 	   deployment.
> 
> Section 5.3
> 
> OLD
> 
> 	   [RFC8585] added information about the steps needed to	
> 	   configure CLAT in a CE in order to facilitate the deployment of	
> 	   stateful NAT64 in broadband networks.	
> 	
> NEW
> 
> 	   [RFC8585] added information about the steps needed to
> 	   configure CLAT in a Customer Edge device (CE) in order to
> 	   facilitate the deployment of stateful NAT64 in broadband
> 	   networks.
> 
> OLD
> 
> 	   Taking advantage of 464XLAT, and the IPv6-Only Preferred Option for	
> 	   DHCPv4 [RFC8925], [I-D.ietf-v6ops-claton] further specify the CLAT	
> 	   and usage of CLAT in hosts and routers.
> 
> NEW
> 
> 	   Taking advantage of 464XLAT and the IPv6-Only Preferred Option for	
> 	   DHCPv4 [RFC8925], [I-D.ietf-v6ops-claton] further specifies CLAT	
> 	   and the usage of CLAT in hosts and routers.
> 
> Section 5.4
> 
> OLD
> 
> 	   The Port Control Protocol (PCP) [RFC6887], provides a mechanism to	
> 	   control how incoming packets are forwarded by upstream devices, such	
> 	   as in this case the stateful NAT64, avoiding the need for keepalive	
> 	   traffic.
> 
> NEW
> 
> 	   The Port Control Protocol (PCP) [RFC6887], provides a mechanism to	
> 	   control how incoming packets are forwarded by upstream devices, such	
> 	   as the stateful NAT64, avoiding the need for keepalive	
> 	   traffic.
> 
> Section 5.5
> 
> OLD
> 
> 	   Similar to NAT44, NAT64 shares many of the issues described in	
> 	   [RFC6269].
> 
> NEW
> 
> 	   Similarly to NAT44, NAT64 shares many of the issues described in	
> 	   [RFC6269].
> 
> Section 5.6
> 
> OLD
> 
> 	   As many operators have extensively deployed NAT64 in different	
> 	   environments, there are extensive recommendations based on that	
> 	   experience.  Two complementary documents provide advices, from	
> 	   slightly different perspectives, "NAT64 Deployment Options and	
> 	   Experience" [RFC7269] and "Additional Deployment Guidelines for	
> 	   NAT64/464XLAT in Operator and Enterprise Networks"
> 	   [RFC8683].
> 
> NEW
> 	   Many operators have deployed NAT64 in different	
> 	   environments, and there are extensive recommendations based on that	
> 	   experience.  Two complementary documents provide advice from	
> 	   slightly different perspectives: [RFC7269] and [RFC8683].
> 
> Section 5.7
> 
> OLD
> 
> 	   For the dimensioning of NAT64 deployments, "Benchmarking Methodology	
> 	   for Stateful NATxy Gateways" [RFC9693] provides useful	
> 	   considerations.  In addition some benchmarking results for NAT64	
> 	   implementations are provided by [Len2023] and [Len2024].	
> 
> NEW
> 
> 	   For dimensioning NAT64 deployments, [RFC9693] provides useful	
> 	   considerations.  In addition, some benchmarking results for NAT64	
> 	   implementations are provided by [Len2023] and [Len2024].	
> 
> Section 5.8
> 
> OLD
> 
> 	   This is one of the advantages of NAT64 compared with other
> 	   transition mechanisms, as described "Pros and Cons of IPv6
> 	   Transition Technologies for IPv4-as-a-Service (IPv4aaS)"
> 	   [RFC9313] (sections 3.4 and 4.7).
> 
> NEW
> 
> 	   This is one of the advantages of NAT64 compared to other
> 	   transition mechanisms, as described in [RFC9313] (sections
> 	   3.4 and 4.7).
> 
> Section 5.9
> 
> OLD
> 	   "Common Requirements for Carrier-Grade NATs (CGNs)" [RFC6888]	
> 	   analyzes common requirements for translators, applicable also to	
> 	   NAT64.  
> 
> NEW
> 
> 	   [RFC6888] analyzes common requirements for translators and
> 	   is also applicable to NAT64.  
> 
> OLD
> 	   Operators also may need to configure alarms and events reporting,	
> 	   which can be done by using "IP Flow Information Export (IPFIX)	
> 	   Information Elements for Logging NAT Events" [RFC8158] to monitor	
> 	   address consumption, in particular.
> 
> NEW
> 
> 	   Operators also may need to configure alarms and event reporting,	
> 	   which can be done by using [RFC8158] to monitor address
> 	   consumption, in particular.
> 
> 
> Section 7:
> 
> If you do not publish this as a bis, this section should be removed.
> 
> 

It was requested by IANA.

> 
> 
> 
> _______________________________________________
> 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.