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

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

Jen, Tommy, Lorenzo, and V6OPS WG,

Thanks for the -14 revised IETF draft and for the discussion so far. Out of my 4 blocking DISCUSS issues, two are solved by -14 (i.e., the ones related to section 6.1 and section 8, the SHOULD are now well explained).

Nevertheless, there are still 2 blocking DISCUSS points:

  *
Somewhere there must be text why this I-D did not select the PvD as a potential solution, it is obviously fair game to state that PvDs are not well implemented in hosts OS. I.e., this I-D must be clear that it does not preclude a future solution based on PvDs.
  *
The section 6.2.2. is still unclear whether it is layer-2 or layer-3 multicast packets.

About the non-blocking comments, please read below at EV> (text elided)

Regards and do not feel obligated to reply before next year! (And enjoy any party in the coming days)

-éric

From: Jen Linkova <[e-mail]>
Date: Thursday, 18 December 2025 at 13:38
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: Tommy Jensen <[e-mail]>, 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)

Hi Eric,

On Thu, Dec 18, 2025 at 7:24 PM Eric Vyncke (evyncke) <[e-mail]> wrote:
> I am also curious to read the next text as it seems that it may address all my DISCUSS points.

-14 has just been submitted.
The diff : https://author-tools.ietf.org/iddiff?url1=draft-ietf-v6ops-claton-13&url2=draft-ietf-v6ops-claton-14&difftype=--html

Please let us know what you think.

Re: the PVD...I do agree that PVDs are the right way to deal with
multihomed/multi-prefix scenarios.
However I have some reservations re: seeing PvD widely supported by
endpoint OSes any time soon, so we need to provide the guidance for
cases when the node is not PvD-aware.
Additionally, as this document defines the node behaviour, we do need
to cover a case when the routers do not include any PvD identification
in RAs, even if the node is PvD-aware.


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

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

EV> a matter of taste, so no worries

>
>
> s/compl*i*ments/compl*e*ments/ ;-)
>
>
> Thank you! Our compliments to the complementary feedback.
>

EV> as written in another email, you made my day, Tommy!
>
>
> ### 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.
>

EV> thanks for fixing it in -14

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

EV> fair enough

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

EV> I would still prefer to have more text, but this was and still is non-blocking

>
> s/the node is allowed to use other mechanisms/the node *MAY* use other
> mechanisms/ ?
>
>
> That makes sense (changed in next version).
>

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

EV> not convinced, let's hope that implementers will apply common sense

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

EV> thanks

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

EV> I disagree, I looked at RFC 7414 and there is no clear equivalence set between Internet Checksum and IP Checksum. Moreover, there is a checksum field in the IPV4 header, so, let's avoid confusion and be clear.

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

EV> fair enough (even if we do not agree 😉 )

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

EV> any feedback on the above point ?

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

EV> ☹️


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

EV> while not mandatory, I would have preferred to read some feedback from the authors/WG
>
> ### 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.
>



--
Cheers, Jen Linkova