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

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

É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
range [RFC7335]` ? I.e., why not a MUST

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

### Section 7

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

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


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

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

### Section 3

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

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

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

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

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

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 ?

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

### Section 6.1

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

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

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

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 ?

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

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.

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.

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

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