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

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

Hello Jen,

Thanks for the -15, I will shortly update my ballot, and I am trusting you and the responsible AD to fix the two remaining issues:

  *
RFC 8415 (DHCPv6) is now obsoleted by RFC 9915
  *
The PvD reference should probably rather be RFC 8801

Regards

-éric


From: Jen Linkova <[e-mail]>
Date: Monday, 2 March 2026 at 01:26
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,

My apologies for the delayed response.

We have just submitted -15.
https://author-tools.ietf.org/iddiff?url1=draft-ietf-v6ops-claton-14&url2=draft-ietf-v6ops-claton-15&difftype=--html

In addition to addressing your comments, the following changes have been made:
1. Fixing the conflicting text between section 4 ("the node SHOULD
disable CLAT if native IPv4 is available") abd Section 5 ("must
disable unless configured otherwise).
2. Explicitly stating that obtaining IPv4 connectivity is for the same
interface the CLAT instance is running on (it was implicit in Section
5 but mentioned in Section 4...)

On Mon, Dec 22, 2025 at 11:20 PM Eric Vyncke (evyncke)
<[e-mail]> wrote:
> 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.

-15 now includes the following text in the Section 7:

"
The Provisioning Domain (PvD) architecture [RFC7556] provides a
mechanism for a PvD-aware node to operate correctly in such
scenarios. However, at the time of writing PvD support is uncommon
for host operating systems, and PvD support is not widely deployed by
network operators. Therefore this document focuses on scenarios when
the node is not PvD-aware."

Please let us know if this text doesn't address your concern.

> The section 6.2.2. is still unclear whether it is layer-2 or layer-3 multicast packets.

Actually it is intentional. This statement applies for both L2 and L3 multicast.

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

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

There is a risk of overspecifying here. The logic of selecting the
IPv4 route might be OS-specific and, ideally, that logic should be the
same for CLAT and non-CLAT (native) routes - so it's not specific for
the CLAT.

If we start defining a behavior in this document, we might introduce a
conflict between our text and reality.

> > 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 the node is not doing optimistic DAD,  there is a pretty good
chance for DHCPv4 to be faster than SLAAC, actually.  Also, an initial
RS is sent after a random delay (between 0 and 1 sec). DHCP defines
randomized wait for DHCPDISCOVER (RFC 2131 Section 4.4.1) and
randomized backoff for retransmissions (RFC 2131, Section 4.1).

Anyway the operational experience hasn’t revealed any issues with such
behavior so far…


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

We changed the text to "Internet Checksum".

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

New text:

"The node that has the address registration using DHCPv6 [RFC9686]
enabled MUST register the CLAT addresses the same way as non-CLAT
addresses, if the network supports the registration."

I hope it addresses your concern.

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

 Sending PREF64 w/o adding 108 is useless (from CLAT perspective), and
to require sending 108 unconditionally is risky, hence this text.



--
Cheers, Jen Linkova