IETF Last Call Review of draft-ietf-v6ops-rfc6146-bis-07
review-ietf-v6ops-rfc6146-bis-07-opsdir-lc-li-2026-06-26-00

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.

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.

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.

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.