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

[[e-mail]]

Hi Eric,

Tks a lot for all the inputs!

I’m already providing edited versions (or done), below in-line, so we can agree before publishing version -12.

Regards,
Jordi

@jordipalet

> El 4 ago 2026, a las 13:37, Éric Vyncke via Datatracker <[e-mail]> escribió:
> 
> É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.

This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a stateful NAT64 translator are shared among several IPv6-only clients. Stateful NAT64 translation also supports IPv4-initiated communications to a subset of the IPv6 hosts through statically configured bindings in the stateful NAT64 translator. When stateful NAT64 translation is used in conjunction with DNS64, no changes are required in either the IPv6 client or the IPv4 server

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

What about inserting this:

     <t>This document specifies stateful NAT64 translation, a mechanism for IPv4-IPv6 transition and coexistence. Together with DNS64 <xref target="RFC6147"/>, these two mechanisms enable an IPv6-Only client to initiate communications to an IPv4-Only server. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated when either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive Connectivity Establishment (ICE) <xref target="RFC8445"/> <xref target="RFC8839"/>.</t>

     <t>The stateful NAT64 translation, can also be used in combination with a 464XLAT <xref target="RFC6877"/> customer-side translator (CLAT), in order to further increase and facilitate the deployment of IPv6, by supporting applications that do not use DNS (e.g., when using literal IPv4 addresses, code-embedded IPv4 addresses, etc.).</t>

     <t>Stateful NAT64 translation also supports IPv4-initiated communications to a subset of the IPv6 hosts through statically configured bindings in the stateful NAT64 translator, which is usually implemented, following the same approach as for Explicit Address Mappings for Stateless IP/ICMP Translation <xref target="RFC7757"/>.</t>


> 
> ### 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

Actually I now realize that provisioning is probably not correct here neither it was in the RFC6146, as RFC6052 is only the address format.

> 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

In fact, I’ve a possible RFC6052-bis in the works to become IS … waiting for draft-ietf-v6ops-nat64-wkp-1918 to move on.

> draft-ietf-v6ops-claton would be useful. These drafts are mentioned way too

While I agree that in the intro we need the reference to the RFC6052 and a short explanation, as well as references to other related protocols such as 464XLAT, etc that I already have, I don’t see the need to enter into the details of how we provision the Pref64 neither a reference to how CLAT is configured.

> late in the document in a wrongly-named "operational considerations" section.
> 

Let’s discuss the “operational considerations” section issue below.

In my opinion, having too much text in the intro, which already seems too long, is not a good idea, if instead, we can just use references to section 5 or whatever we decide later. Anyway, open to suggestions on this.

How about replacing
> `The provisioning of the Pref64::/n as well as the address format are defined
> in [RFC6052].`


with

The address format of the Pref64::/n is defined in <xref target="RFC6052"/>. Pref64::/n provisioning protocols are described in "5.2.  Stateful NAT64 Prefix Discovery".</t>



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

What about:

When DNS64 <xref target="RFC6147"/> is used, to allow an IPv6 initiator to do a DNS lookup, in order to learn the address of the responder, the DNS64 function will synthesize AAAA RRs from the A RRs.


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

Agreed.

> 
> 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)"`

Either I’m confused here or it is correct. ICMP Query sessions are a mapping between 3-tuples, we need to use the IPv6 and IPv4 source and destination address, as well as ICMP identifiers (instead of port numbers). May be the problem is the example in section 3 is good for the BIB, not for the session table, but reading the paragraph after (X',Y',i1) <--> (T,Z,i2) is clear enought? Also clear if you follow after section 3.5.3.

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

Agreed.

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

Agreed.

> ### 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).`.

You mean both sentences aren’t properly linked? What about:

If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. In this case, 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.

I’m not sure to understand here what do you mean, as those come from RFC4787 requirements section 12.

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

Agreed (2 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.

Ok, let’s see if this may work for you.

Move "5.1. Stateful NAT64 Prefix”  and “5.2.  Stateful NAT64 Prefix Discovery” to its own section after 2. Terminology., it will become something like:

2. Terminology
3. Stateful NAT64 Prefix Considerations
	3.1 Stateful NAT64 Prefix
	3.2 Stateful NAT64 Prefix Discovery
4. Stateful NAT64 Translator Normative Specification

Then, keep the rest of the existing "5.  Operational Considerations” (which now will become 6. and so on with the rest). I think the rest fits well as “Operational Considerations”, or “Other Operational Considerations” (“other", because the document already have many), but if you don’t agree, I’m happy to use “Other Considerations”.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> ## COMMENTS (non-blocking)
> 
> ### Abstract
> 
> s/This document describes/This document *specifies*/

Done

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

Done

> 
> ### 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/ ?

Done

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

Done

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

What about:

Once the flow stops, and based on a timer, the relevant IPv4 address and port are released, so they can be reused for other communications.

> ### Section 1.2.2
> 
> Suggest using port 443 rather than 80 in the example ;-)

Done

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

The packet exchange between H1 and H2 continues, and packets are translated in the different directions as previously described, until the flow stops, and based on a timer, the IPv4 address 203.0.113.1, port 2000 and relevant mappings are released.

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

A stateful NAT64 translator is a device with at least one IPv6 interface and at least one IPv4 interface. Note these two interfaces can actually be 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.

Done

> 
> ### Section 3.1
> 
> No need to re-expand `Binding Information Bases (BIBs)`
> 

Done

> ### 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?

This is implementation specific. We have this text in s. 3 to clarify that the data structures are to describe the behaviour, but they should contain all the required info:

   These tables contain information needed for the stateful NAT64
   translator processing.  The actual division of the information into
   six tables is done in order to ease the description of the stateful
   NAT64 translator behaviour.  Stateful NAT64 translator
   implementations are free to use different data structures but they
   MUST store all the required information, and the externally visible
   outcome MUST be the same as the one described in this document.

Actually is the same for ICMP. You may have pre-defined ones.

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

I see where this comes from. If you look at RFC2460, the “should be discarded” is not there.

RFC8200 was published *after* RFC6146 and this part was not updated.

If we now set a SHOULD instead of the existing MAY, it may create interoperability issues.

So may be just adding a reference to that section of RFC8200, like:

The stateful NAT64 translator MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero. Note that <xref target="RFC8200"/> Section 4.5 states "If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded and an ICMP Parameter Problem, Code 3, message should be sent to the source of the fragment, with the Pointer field set to zero"

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

Done

> ### Section 3.5
> 
> When discarding such weird (looping) packets, should there be ICMP generated ?
> 

If we do so, it will be a may or should, to avoid interoperability issues (right now the text is silently discard). Then, use code 4 (port unreachable)?

   Irrespective of the transport protocol used, the stateful NAT64
   translator MUST discard all incoming IPv6 packets containing
   a source address that contains the Pref64::/n, and if the security policy
      permits, the stateful NAT64 translator SHOULD send an ICMPv6
      Destination Unreachable error message with Code 4 (Port
      Unreachable) to the source address of the received packet.

> ### 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` ?

An ICMP error message with Type 3 (Destination Unreachable) with Code 3 (Port 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/ ?

Done

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

No change from original RFC6146.

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

Done

> 
> ### 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*)/ ?
> 

Done

> ### 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)

RFC7915 section 4.1 is Translating IPv4 Headers into IPv6 Headers and no mention about traceroute, so not sure if you meant a different document or section?

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

Yes, but see as well my proposed change for 5.1 and 5.2.

> ### 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 ;-)
> 
> 

Will try … I’m using plain xml.

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