[v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-rfc6146-bis-11: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-rfc6146-bis-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6146-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-v6ops-rfc6146-bis-11
CC @evyncke

Thank you for the work put into this document. I sincerely welcome the effort
to make an Internet Standard of this widely deployed and critical component,
but let's try to also refresh it while keeping it backward compatible.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to XiPeng Xiao for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

Other thanks to Jim Reid, the DNS directorate reviewer, and I have read Jordi's
reply to the dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-rfc6146-bis-10-dnsdir-telechat-reid-2026-07-06/

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Abstract

`which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP,
or ICMP` but the section 1 also includes `Stateful NAT64 translation also
supports IPv4-initiated communications to a subset of the IPv6 hosts`...

The abstract should be clear that the clients can also be on the IPv4 side.

### Section 1

`Together with DNS64 [RFC6147], these two mechanisms enable an IPv6-only client
to initiate communications to an IPv4-only server` but what about 464XLAT (RFC
6877) ? AFAIK the CLAT part of 464XLAT also requires stateful NAT64 specified
in this I-D. The section provides later more text about 464XLAT but the quoted
statement at the beginning is too strong.

### Section 1.2.1

`The provisioning of the Pref64::/n as well as the address format are defined
in [RFC6052].` while this sentence is a verbatim copy from RFC 6146, it is not
really correct in 2026 as for the provisioning part as RFC 8781 (RA option) is
widely used and even the well-known prefix 'recommendation' is about to change
with draft-ietf-v6ops-nat64-wkp-1918. Informative reference to
draft-ietf-v6ops-claton would be useful. These drafts are mentioned way too
late in the document in a wrongly-named "operational considerations" section.

`To allow an IPv6 initiator to do a DNS lookup to learn the address of the
responder, DNS64 [RFC6147] is used to synthesize AAAA RRs from the A RRs.`
links the use of NAT64 to DNS64 and this is not always the case as the IPV6
client can do the mapping w/o DNS64 (notably in the case of CLAT in 464XLAT).
Please update this paragraph coming verbatim from RFC 6146.

### Section 3.1

Why not a "should" in `Stateful NAT64 translator implementations SHOULD support
manually configured BIB entries for any of the three BIBs` There is no
interoperation issue in the statement, so use of BCP14 terms is incorrect.

See also:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 3.2

Do not use the () notation for ICMP as in `(X',Y',i1) <--> (T,Z,i2)` as it is
incorrect per section 3 `IPv6 prefixes of length n are indicated by "P::/n";
mappings are indicated as "(X,x) <--> (Y',y)"`

### Section 3.4

Why not a "should" in `The time interval SHOULD be configurable` as it is not
linked to interoperation. See also the previously cited IESG statement.

### Section 3.5.1

I do not think that the use of BCP14 terms in `The maximum session lifetime MAY
be configurable, and the default SHOULD be at least UDP_DEFAULT.` are justified
for interoperation, consider using lower case verbs.

### Section 3.5.1.1

The SHOULD is missing the required guidance in `The stateful NAT64 translator
SHOULD send an ICMPv6 Destination Unreachable error message with Code 3
(Address Unreachable).`.

### Sections 3.5.1.1 and 3.5.2.3

A lot of "SHOULD" in these sections without the required guidance, which would
be very useful on this topic.

### Section 3.5.4

A lot of "SHOULD" without any impact on interoperation, so why not "should" ?

### Section 5.1

This section is important but it is not about "operational considerations" at
all. Consider creating a new section "Other considerations" or "Other IETF
work" containing this section 5.1.

This also applies to some other subsections of section 5.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Abstract

s/This document describes/This document *specifies*/

### Section 1

`Multicast packets and other protocols, ... and IPsec, are out of the scope of
this specification.` please add "IPsec without UDP encapsulation [RFC3948])"
like in section 1.1.

### Section 1.2.1

s/The packets are intercepted by the stateful NAT64 function/The packets are
*forwarded to and processed* by the stateful NAT64 function/ ?

`the usual practice for stateful NAT64 translators is likely to be` the use of
`usual` and `likely` seems redundant to me.

Unsure how to rewrite it but `the IPv4 transport address is returned to the
IPv4 address pool ` is somehow incorrect as a transport address (L3 address and
L4 port) cannot really be returned to an IPv4 address pool (only L3 addresses).

### Section 1.2.2

Suggest using port 443 rather than 80 in the example ;-)

Suggest adding some text about the removal of the translation state.

### Section 3

About `A stateful NAT64 translator is a device with at least one IPv6 interface
and at least one IPv4 interface` suggest adding some text that these 2
interfaces can actually a single layer-2 interface.

About `A stateful NAT64 translator MUST have one or more unicast IPv4 addresses
assigned to it` suggest adding "non link-local" for the address.

### Section 3.1

No need to re-expand `Binding Information Bases (BIBs)`

### Section 3.2

For the TCP/UDP session table, isn't there an additional column to indicate
whether the entry was dynamically or statically created?

### Section 3.4

Should text be added after `The stateful NAT64 translator MAY require that the
UDP, TCP, or ICMP header be completely contained` per `If the first fragment
does not include all headers through an Upper-Layer header, then that fragment
should be discarded` (section 4.5 of RFC 8200) ? It would provide more
information.

Please add informative references to RFC 6980 and 8900 after `Implementers of
stateful NAT64 translators should be aware that there are a number of
well-known attacks against IP fragmentation`.

### Section 3.5

When discarding such weird (looping) packets, should there be ICMP generated ?

### Section 3.5.1

Should the ICMP code also be suggested in `An ICMP error message with Type 3
(Destination Unreachable) MAY be sent to the original sender of the packet` ?

### Section 3.5.2.2

s/for the TCP session processing is depicted next/for the TCP session
processing is in Figure 2/ ?

To be honest, as this section is deep in TCP FSM, I did not review it in depth
as I trust the transport AD for his review.

### Section 3.5.3

Please use a separate bullet for `The packet is translated and forwarded as
described in the following sections.`

### Section 3.6.1

s/he protocol number in the protocol field of the IP header is set to 1
(ICMP)/he protocol number in the protocol field of the *IPv4* header is set to
1 (*ICMPv4*)/ ?

### Section 5

Adding some text about MTU discovery and traceroute (i.e., generating ICMP by
the translator itself) would be welcome (even if simply adding references,
e.g., to section 4.1 of RFC 7915)

### Section 5.2

Please add a reference to this section when discussing "provisioning" earlier
in the text (section 1.2.1).

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)