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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Tommy, for your message.

While I do not agree always with your reply to my non-blocking comments, there are not blocking anyway :-)

I am also curious to read the next text as it seems that it may address all my DISCUSS points.

Finally, it was a nice start of my European day to read `Our compliments to the complementary feedback`about my `s/compl*i*ments/compl*e*ments/ ;-)`

Regards, I am confident that the DISCUSS ballot will be solved quickly

-éric

From: Tommy Jensen <[e-mail]>
Date: Thursday, 18 December 2025 at 09:04
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-v6ops-claton-13: (with DISCUSS and COMMENT)

Thank you for the comments, Éric. Some responses in-line. Unanswered items were left that way as a trade-off to get partial answers to you in time for the telechat review, rather than waiting for time for the editors to meet to discuss the remaining.

Thanks,
Tommy

On Tue, Dec 16, 2025 at 6:57 AM Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-claton-13: 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-claton/



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


# Éric Vyncke INT AD comments for draft-ietf-v6ops-claton-13
CC @evyncke

Thank you for the work put into this document. While my current ballot is a
blocking DISCUSS, I am a big supporter of this work, so, take the length list
of the points below as a way to help the authors improving their document.

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

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

Other thanks to Nicolai Leymann, the DNS directorate reviewer, and Nicolai
confirmed that all its comments were implemented by the authors.

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.

### Section 6.1

In which case does the SHOULD not apply in `A node providing CLAT functions to
local applications SHOULD use IPv4 addresses from the dedicated 192.0.0.0/29<http://192.0.0.0/29>
range [RFC7335]` ? I.e., why not a MUST

Since the IPv4 address in question is never used on the network (in fact, it's forbidden), there's no interoperational harm from a protocol perspective to not do so, hence we felt SHOULD was better. We have updated text coming in the next revision (coming soon!) that makes this more in line with IESG guidance, explaining what harm results if an implementor doesn't use this range (i.e. apps may assume no CLAT is in place because it expects to see 192.0.0.0/29<http://192.0.0.0/29>).


### Section 6.2.2

I have also seen mcast IP over ucast layer-2, so, the text in the second bullet
should really qualify ucast and mcast by the layer.

We've attempted a rephrase here too. New text incoming.


### Section 7

Please explain why PvDs (RFC 8801) do not help in this case.

The editors didn't have time to sync before the telechat and want to discuss this further. This comment remains open.


### Section 8

Why not a MUST in `the CLAT instance SHOULD present IPv4-only applications with
an IPv4 MTU which is 28 bytes smaller` ? If SHOULD is kept, then follow the
IESG guidance at
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/



We thought we had provided the needed format, but the new text restructures this to make alignment with the IESG guidance clearer.

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


## COMMENTS (non-blocking)

### Section 1

While I understand why the I-D means by `which require IPv4 would fail`, the
wording seems a little 'fuzzy', perhaps adding '(e.g., having a remote peer
hardcoded IPv4 addresses preventing the use of DNS64/NAT64)' could help (even
if the sentence is heavier) ?

I may perhaps be too strict about the use of "host" vs. "node" in `CLAT
functions are performed by the host itself` because the host can be used for
tethering 'downstream' devices, i.e., not really a 'host' anymore. I.e.,
suggest s/host/node/. Later in the I-D, "node" seems to be used more often than
"host", so, let's be consistent.

This bullet is in the context of Section 4.2 of RFC 6877, which is the use of CLAT by endpoints that do not provide downstream connectivity, for which the editors feel “host” is more accurate. The rest of the document tends to use “node” to be generic when CLAT is discussed without specifying whether it is for the node itself as a host or for devices connected to/through the node.


s/compl*i*ments/compl*e*ments/ ;-)

Thank you! Our compliments to the complementary feedback.


### Section 3

I find the definition of `IPv6-only network` a little confusing with the use of
2 similar but not identical sentences.

Agreed; these sentences have been merged in the new text to avoid duplication.


About the `native IPv4`, why not using "IPv4-only network" even if only for
symmetry with "IPv6-only network" ?

Because "native IPv4" is not defined to be the IPv4 equivalent of "IPv6-only network". The intent is to refer to the use of IPv4 "on the wire" (sorry) rather than inside of IPv6, meaning that both IPv4-only networks and dual-stack networks have "native IPv4" available.


### Section 4

Why not a "MUST" in `Therefore an IPv6-only node SHOULD enable CLAT `? Even if
the "MUST" is conditioned with "Therefore an IPv6-only node with CLAT features
MUST enable CLAT as soon as it receives a PREF64 option from the network and if
local policy allows it." or something similar. Nevertheless I appreciate the
"Discussion" as it matches
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/


We felt SHOULD was most appropriate given the context (glad you like our added discussion). It needs more than one sentence, hence it isn't exactly in the format described by the IESG for SHOULDs, but our reasoning is the same as the text. It doesn't make sense to have to try and decide when this MUST needs to be SHOULD as IPv4 becomes less common whereas the conditions of the SHOULD remain the same and the reader can evaluate the conditions themselves.

About the multi-interface with CLAT on, should this specific use case be more
detailed ? E.g., by explaining how the selection of the default IPv4 route
should work ? (I note that there is text about using "ipv4only.arpa" in
multi-interface, which is good).

We tried to avoid getting too into the weeds on how address selection should work, given we don't want to change that logic for the platform.


s/the node is allowed to use other mechanisms/the node *MAY* use other
mechanisms/ ?

That makes sense (changed in next version).


I fear that `Unless configured otherwise, the node MUST enable CLAT if the node
has not already obtained a non-link-local IPv4 address by the time it discovers
the NAT64 prefix.` is probably too aggressive as DHCPv4 is typically slower (as
it relayed and requires a permanent storage write operation) than IPv6 RA by a
local router. I.e., CLAT could end up being enabled 10 msec before DHCPv4
especially with text later saying `If native IPv4 connectivity becomes
available later for a given interface, the node SHOULD disable CLAT for that
interface `. Should there be a minimum delay before enable CLAT ?

We do not think so, because this is a trade-off with waiting too long to start and unnecessarily delaying IPv4 connectivity when we know there is IPv4 connectivity available (via 464XLAT). We have guidance for allowing delay in the next sentences to address the shortcomings of RFC 7050 in that specific case, however.


`If native IPv4 connectivity becomes available later for a given interface, the
node SHOULD disable CLAT for that interface ` while the next section has a
"MUST" (although with a "unless"). This reads weird.

You are correct that it is a weird flow, but it was the best spot we could find for that guidance the last time section ordering was challenged in review. Open to suggestions.


### Section 6.1

`on the wire` in a Wi-Fi world looks strange ;-)

Fair point! Changed to "to the network"


### Section 6.2.1

Please note that RFC8415 will soon be RFC9915 (it is in AUTH48) so using the
I-D draft-ietf-dhc-rfc8415bis rather RFC 8415 will ensure that the RFC editor
picks up the right RFC for DHCPv6.

Good point, updated.


You may add that the examples are using the Well-Known Prefix for NAT64.

Should there be some text confirming that the CLAT node can obtain *two* IPv6
addresses by DHCPv6 and use one for CLAT ? Of course at the expense of checksum
recomputation (it would be nice to have an DHCPv6 option to request a checksum
neutral IPv6 address...)

Definitely possible to add. The current state reflects us trying not to iterate valid ways network administrators could handle this and rather focus on what the client needs (separate addresses/prefixes for native IPv6 and CLAT traffic).


Really unsure what is meant by `If a protocol uses the standard IP checksum,`
as there is no checksum in any IP header ;-) and is there any TCP or UDP
protocols not using the standard checksum ?

“IP checksum” is commonly used as shorthand for “Internet checksum” (and arguably easier to recognize given IP is no longer expanded usually) as defined in RFCs 1071, 1141, and 1624, which are legacy but most recently referenced by RFC 7414 which also uses the two phrases interchangeably.

The safe approach is to assume some protocols might behave differently so the current text says may rather than boldly claim it will always work because no protocols do anything but the expected IP checksum.


### Section 6.2.2

Should there be another term instead of `native IPv6 addresses`, e.g.,
"non-CLAT addresses" or simply "their other IPv6 addresses" ?

We prefer this term because it uses the same paradigm as “native IPv4” to mean something about addresses that have nothing to do with translation (see "native IPv4" discussion above).


Hummm, the 1st paragraph clearly (and rightfully) states that all IPv6
addresses (CLAT & non-CLAT) MUST have the same behavior, then the bulleted list
only specifies the CLAT behavior, e.g., allow non-DAD for some addresses as
long as CLAT addresses do DAD... This is not correct, I suggest removing the
CLAT-specific text in the bulleted list.

We want to limit specificity to CLAT because if this section provides normative behavior for the treatment of IPv6 addresses outside the context of CLAT, this document’s scope is much wider than originally intended. This document is only intended to update CLAT-related RFCs rather than define new requirements that would apply to use of IPv6 without CLAT in place.


About the DHCP registration, like written above, what if the other addresses
are not registered ?

### Section 7

A small but nice graphics would help some readers who are not aware of the
issue.

We explicitly tried to avoid architecture diagrams knowing there's no way to come close to being comprehensive here and moreso now in light of the pushback the flow diagram received in other reviews.


### Section 9.2

I was expecting a MAY rather than `SHOULD implement [RFC7050] ("Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis")` as this document clearly
prefers (rightfully) the RA method.

This was our original intention, but then it became clear that there are networks where 8781 is not feasible as raised by those with 3GPP experience. Leaving 7050 as a MAY would regress the state of interoperability. That said, we do have text in the fifth paragraph of Section 4 that addresses this by illustrating both the preference order and the heightened considerations around using 7050 versus 8781.


`The router SHOULD have a configuration knob to disable DHCP Option 108
processing.` has little to do with 464XLAT though and more about IPv6-mostly.

### Section 10

`For non-mobile environments, ... the operational considerations are documented
in [I-D.ietf-v6ops-6mops].` is rather succint as having 2 IPv6 addresses (and
the whole discussion of multi-prefixes) really belongs to this document IMHO.

### Section 11

The link to I-D.ietf-pquip-pqc-engineers does not bring a lot as the discussion
about ""Harvest Now, Decrypt Later" as it is not specific to this I-D. Consider
removing this part, else a LOT of I-D will end-up referring to this PQC draft.

That draft getting a lot of references makes sense given it’s the way the rest of us can define why it is important in a threat model to avoid exposing encrypted data to an unintended recipient. Otherwise, it is difficult for us to explain why an attacker moving traffic to their PLAT on what is supposed to be an IPv4-only network matters when most of it is encrypted anyway.