IETF Last Call Review of draft-ietf-v6ops-rfc6146-bis-07
review-ietf-v6ops-rfc6146-bis-07-intdir-lc-matsushima-2026-06-30-00

I have reviewed this document as part of the IntArea directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the internet area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

I found no blocking Internet Area issues. The comments below are
non-blocking nits or clarification suggestions.


Result: Ready with Nits

The document does not mention QUIC. This does not affect the normative
NAT64 behavior, since QUIC is carried over UDP. Still, Section 5 could
usefully note that QUIC/HTTP/3 traffic depends on reasonable UDP session
lifetimes, and that NAT64 implementations should not use QUIC Connection
IDs as NAT state keys. A pointer to the QUIC manageability guidance in 
RFC 9312 may be useful for that operational note.

The draft changes many instances of "NAT64 device" from RFC 6146 to
"NAT64 function". This is a useful modernization, but the intended meaning
could be clearer, especially because Section 7 updates the SFC Service
Function Types registry. Please clarify that "NAT64 function" means the
logical translation function, whether implemented in a device, VNF, or
SFC service function, and that this document defines no SFC-specific
behavior.

Section 5.2 could explicitly state that DHCPv6 OPTION_V6_PREFIX64,
defined in RFC 8115, is not a NAT64 prefix discovery mechanism and should
not be used for that purpose. This would help to avoid confusion for
implementers who notice the option name or the uPrefix64 field, while
keeping the section focused on the PREF64 discovery mechanisms intended
for NAT64 deployments.