Many thanks to John Levine for the ARTART review.

Thanks to John Levine for his ARTART review and to the authors for addressing the concerns raised. I think it would be helpful to update Figure 1 as recommended by John in his subsequent review. This seems an improvement over using the one inherited from RFC 6146.

I have only one additional comment:  

Section 8.2, 'without filtering' para:  There is a hanging 'However,' at the end.

# Thank you for Joerg Ott his review, and the questions raised concerning rev-07. 

# Thank you also, I see you have addressed the set of DISCUSS comment that I raised. 

# I have some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

## Please describe what happens when packets that contain other encapsulations work encounter this translation, including tunnels.

## To complete the point about other protocols, is it possible to add a line of text at least to identify that explicit support and state is required for each transport protocol, before stating other protocols are out of scope for the current document?

## The following definition seems weirdly undefined: "Session:  The flow of packets between two different hosts." Is this associated with a specific transport and ports, or the entire IP aggregate or something else? Likely this is linked to the 5-Tuple or 3-Tuple for the corresponding transport protocol, but needs to be explicitly defined.


## Please see my DISCUSS question on the support for extension headers:
   "If the incoming packet is an IPv6 packet that contains a protocol
   other than TCP, UDP, or ICMPv6 in the last Next Header, then the
   packet SHOULD be discarded and, if the security policy permits, the
   stateful NAT64 SHOULD send an ICMPv6 Destination Unreachable error
   message with Code 4 (Port Unreachable) to the source address of the
   received packet."
- Please could you clarify the intent here when extension headers are encountered

NiTs:
* "The actual extensions to support IPsec" could be: "Extensions to support IPsec".
* The document states: "Only TCP, UDP, and ICMP are supported", but I assume this can be clarified to be only "unicast UDP".

Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-v6ops-rfc6146-bis-09

# Many thanks for resolving my set DISCUSS's and considering all comments.

Original ballot: https://mailarchive.ietf.org/arch/msg/v6ops/Y-QJDHdJduJInia1Zgsd7OZkOJg/
Responses for updated ballot: [1] https://mailarchive.ietf.org/arch/msg/v6ops/rUD3mRhHvWpmOcguNEsXld9glxU/
Final Response: [2] https://mailarchive.ietf.org/arch/msg/v6ops/-yR7LWVId_keuTqXv96XYVB_504/

[DISCUSS#1] closed - WG and Shepherding AD confirmed that the original text was correct
[DISCUSS#2] closed with proposed change [1]
[DISCUSS#3] closed - WG and Shepherding AD confirmed that the existing text is sufficient
[DISCUSS#4] closed with proposed change [2]
[DISCUSS#5] closed with proposed change [2]

Kind Regards,
Gunter Van de Velde
Routing Area Director

Thanks to the authors, contributors and the WG for the work on this document,
and for taking a fifteen-year-old specification through a bis carefully enough
that the changes are as contained as Appendix A shows them to be.

My review was largely focussed on the diff from the base: 
https://author-tools.ietf.org/iddiff?url1=rfc6146&url2=draft-ietf-v6ops-rfc6146-bis-10&difftype=--html

I have the following comments/suggestions to offer. I debated whether some
of the major ones should be elevated to DISCUSS, but settled on offering
them as comments and hope the authors consider them.

1) Section 5 (Operational Considerations) does not cover the routing that
stateful NAT64 depends on, and I would like to understand whether that was
deliberate.

The only statement in the document about how traffic actually reaches the
translator is in Section 1.2.2, which the document marks as non-normative: "The
routing is configured in such a way that the IPv6 packets addressed to a
destination address in 64:ff9b::/96 are forwarded to the IPv6 interface of the
stateful NAT64 function." Section 5 covers how hosts discover the prefix,
dimensioning, and port allocation, but nothing on the routing side.

Was it a deliberate decision to leave out how Pref64::/n is routed to the
translator in the IPv6 domain, and how the IPv4 pool is routed back to it in the
IPv4 domain? These are prerequisites for the function to work at all.

More substantially: the function is per-flow stateful and that state is local to
the device. Where Pref64::/n and the IPv4 pool are reachable via more than one
translator - which is the usual answer to resilience and scale, whether by ECMP,
by anycast, or by two translators in two sites - every packet of a flow has to
land on the same device. Routing reconvergence, an ECMP set change on a link
failure or a member addition, or a rehash will move flows onto a translator that
holds no matching BIB or session entry. Against the TCP_EST lifetime in
Section 4, the window in which established sessions are dropped is not a
short one. Was there any discussion on the list about whether the document
should say so?

I do appreciate that stateful NAT64 has always had this property and that this
document does not introduce it. If the WG's position is that RFC 7269 and
RFC 8683 already cover this ground, would a pointer from Section 5 to that
material be worth adding, so that a reader of Section 5 (that was newly 
introduced in this document) is at least sent somewhere? I raise it partly 
because the document now cites service functions and hyperscale data centres 
among its motivating cases in Section 1, and that is precisely where 
multi-instance and multi-path designs are the default rather than the exception.

2) Was consideration given to whether the privacy consequences of address
sharing, and of the mapping logs, belong in Section 8 or in a separate Privacy
Considerations section?

The document establishes that a deployment shares one public IPv4 address across
a large number of subscribers (Sections 1.1 and 5.9), that the resulting logs
are large (Section 5.9), that the RFC 6888 Section 4 logging requirements apply
(Section 5.10), and it points at RFC 6269 for the problems of address sharing
generally (Section 5.6). Section 8 does not address the sensitivity of the
mapping logs that are the only means of attributing activity to a subscriber, or
the misattribution risk that address sharing creates. I note that the
operational material which makes the logging necessary is new in this revision,
and it looks as though Section 8 was not revisited alongside it.

3) Please find below some further comments inline in the idnits output of v10 of
this document. Lookout for the <EoRv10> tag at the end to ensure you are seeing
the full review.

208	1.1.  Features of Stateful NAT64
210	   The features of NAT64 are:

<nit> s/The features of NAT64/The features of stateful NAT64 - to match the
section heading. The same applies at line 989 in Section 3.5.1 ("The NAT64
searches for a UDP BIB entry"), which looks like the one place in the
procedural text where the qualifier was not carried over.


243	      nodes to share a single IPv4 address to access the IPv4 Internet.
244	      This help address some of the problems of IPv4 address exhaustion.

<nit> s/This help address/This helps address


524	2.  Terminology
526	   This section provides a definitive reference for all the terms used
527	   in the document.

<minor> This claims more than the section delivers, and the sentence that
follows it ("The following additional terms are used in this document")
already says the useful part. WKP, NSP, Pref64::/n and STE are all
introduced elsewhere in the document rather than here, and "external
interface" (line 2242) is not defined at all. Perhaps just delete this
sentence?


810	   of the packets will be described next.  In the case that the
811	   processing is common to all the aforementioned types of packets, will
812	   refer to the packet as the incoming IP packet in general.  In the
813	   case that the processing is specific to IPv6 packets, will explicitly
814	   refer to the incoming packet as an incoming IPv6 packet; analogous

<nit> Missing subject - "will refer to the packet" and then "will
explicitly refer". Perhaps s/will refer/this document refers/ and
similarly for the following sentence. There a few of those.


966	   silently discard all incoming IPv6 packets containing a source
967	   address that contains the Pref64::/n.  This is required in order to
968	   prevent hairpinning loops as described in Section 8.  In addition,

<nit> s/as described in Section 8/as described in Section 8.4 - the
hairpinning loop discussion is specifically in Section 8.4, and that
section points back at Section 3.5.


1662	      In contrast to the TCP and UDP specifications in previous
1663	      sections, the definition of the ICMP Query session do not have
1664	      transport ports and therefore do not have an analogous Address-
1665	      Dependent Filtering case at that stage.

<nit> Number agreement. How about the following?

CURRENT
the definition of the ICMP Query session do not have transport ports and
therefore do not have an analogous Address-Dependent Filtering case at that
stage.

SUGGEST
ICMP Query sessions have no transport ports and therefore there is no
analogous Address-Dependent Filtering case at that stage.


1897	   [RFC7050], updated by [RFC8880], defines a best effort method for
1898	   clients to discover the Pref64::/n being used by the stateful NAT64.
1900	   In order to improve the discovery of the Pref64::/n, [RFC8781]
1901	   specifies a ND option to be used in RAs.  [RFC9872] further provides
1902	   a recommendation for using [RFC8781] instead of [RFC7050].

<editorial> The subsection leads with RFC 7050 and only then mentions that
RFC 9872 recommends RFC 8781 in preference to it. For a document being
republished now, leading with the currently recommended mechanism would
serve the reader better. I will leave it to the authors' call.


1912	   It should be noticed that the DHCPv6 OPTION_V6_PREFIX64, defined in
1913	   [RFC8115], is not a stateful NAT64 prefix discovery mechanism and
1914	   should not be used for that purpose.  This is remarked to ensure
1915	   avoiding confusion for implementers who notice the option name or the
1916	   uPrefix64 field.

<major> This is a constraint on implementations, not an operational
consideration, and Section 5 is both titled "Operational Considerations"
and declared non-normative at its start. An operator cannot act on this;
only an implementer can. So the audience that needs this statement is not
the audience the section addresses, and because the section is
non-normative the constraint ends up with no normative force anywhere in
the document - this being the only place it is stated.

I would suggest moving this into Section 3 as a normative requirement,
leaving any deployment-facing explanation here. If the WG would rather
Section 5 stayed a survey of adjacent work, then the implementation-directed
material needs its own home and the document should say plainly whether it
is normative. I am not making a case for which way the keyword itself
should go - that is the authors' and WG's call.

It may be worth a pass over the rest of Section 5 for the same thing.
Section 5.10's invocation of the RFC 6888 requirements reads as though it
may also be implementation-directed rather than operational - I have
only skimmed through RFC 6888.


1945	   QUIC [RFC9000] is carried over UDP, so it works when QUIC packets are
1946	   translated by a stateful NAT64.  However, QUIC/HTTP/3 traffic depends
1947	   on reasonable UDP session lifetimes, and stateful NAT64
1948	   implementations should not use QUIC Connection IDs as NAT state keys.
1949	   Refer to [RFC9312], which provides relevant guidance.

<major> Same as the previous comment, and here the point is sharper because
the sentence addresses "implementations" in its own words while sitting in
a section that says it is non-normative and is addressed to operators. This
is also the only place in the document that states this constraint.


2148	   IPv6 side to the IPv4 side.  In accordance with the procedures
2149	   defined in this document following the guidelines defined in
2150	   [RFC4787], a stateful NAT64 MUST offer "Endpoint-Independent
2151	   Mapping".  This means:

<major> This is a specification requirement rather than a security
consideration. Would it not be better placed in Section 3.1, with
Section 8.2 retaining the security discussion and pointing at it?


2161	   Implementations MAY also provide support for "Address-Dependent
2162	   Mapping" as also defined in this specification and following the
2163	   guidelines defined in [RFC4787].

<major> "as also defined in this specification" does not hold - there is no
definition of "Address-Dependent Mapping" anywhere in this document. Was it
meant to be Address-Dependent Filtering? Am I missing something here?

2172	      stateful NAT64, once a binding is created in the IPv6 ---> IPv4
2173	      direction, packets from any node on the IPv4 side destined to the
2174	      IPv6 transport address will traverse the stateful NAT64 gateway

<nit> s/stateful NAT64 gateway/stateful NAT64 function - "gateway" is not a
defined term; Section 2 defines "Stateful NAT64" and "Stateful NAT64
device".


2230	   requirement to also store the data packets for a given amount of
2231	   time, requiring more memory from the stateful NAT64 device.  Stateful
2232	   NAT64 devices MUST implement proper protection against such attacks,
2233	   for instance, allocating a limited amount of memory for fragmented
2234	   packet storage as specified in Section 3.4.

<major> "proper protection" gives an implementer nothing to build to and a
reviewer nothing to test against. The one concrete measure named here, the
limit on memory for fragmented packet storage, is already a normative
requirement in its own right in Section 3.4 - so as drafted this MUST adds
an obligation without adding any content, and its only substance is a
cross-reference to a requirement that exists elsewhere. This is also a
normative requirement placed in the Security Considerations rather than in
the specification sections, same as my comment on line 2150 above.

Either the required protections should be enumerated normatively in
Section 3 with this reduced to a pointer, or the keyword should be dropped
and the text reworded as advice, on the basis that the enforceable
requirement already lives in Section 3.4. I leave it to the authors.


2240	   against such attacks, the stateful NAT64 MAY choose not to extend the
2241	   session entry lifetime for a specific entry upon the reception of
2242	   packets for that entry through the external interface.  As described

<major> "external interface" is not defined anywhere in the document, and
the sentences immediately following this one say that which side is the
Internet side depends on the deployment scenario. So the term is ambiguous
exactly where it carries the weight of the mitigation. Either define it in
Section 2 or perhaps s/through the external interface/through the interface
facing the Internet side, as configured


2284	8.5.  DNS64 and DNSSEC
2286	   If DNS64 is used, also see the Security Considerations of [RFC6147].

<minor> The heading names DNSSEC and the body does not mention it, so a
reader who navigates here by the title gets a cross-reference and nothing
else. Should the heading simply become "DNS64", and should the DNSSEC
interaction be covered in the body with clarifications on how RFC6147 covers
that interaction?

<EoRv10>

I support the DISCUSS positions of Gorry Fairhurst.

I see this document as an excellent thing to have refreshed, but the document contains a number of inconsistencies right now due to many fixes issued from reviews. I'll only note that I support Éric and Mahesh in their DISCUSS ballots which enumerate these and that I do not have concerns that aren't already covered there.