[IPv6]Éric Vyncke's Discuss on draft-ietf-6man-icmpv6-reflection-15: (with DISCUSS and COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-icmpv6-reflection-15: 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-6man-icmpv6-reflection/



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

# Éric Vyncke, INT AD, comments for draft-ietf-6man-icmpv6-reflection-15
CC @evyncke

Thank you for the work put into this document, this utility could indeed be
really useful to check for extension headers modifications even if I still
wonder why plain UDP would not do the trick. Based on email exchange on the
list with the authors, I have reviewed the -15 version in the hope of clearing
my DISCUSS, but while several of my DISCUSS points are now addressed, others
remain. I.e., my ballot is still DISCUSS. For reference, the previous ballot is
at https://mailarchive.ietf.org/arch/msg/ipv6/TbT1ysZT9J0_hHHnwlpbvf6eT00/

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 Jen Linkova for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status.

Other thanks to Suresh Krishnan, the Internet directorate reviewer (at my
request), and I have read Ron's replies:
https://datatracker.ietf.org/doc/review-ietf-6man-icmpv6-reflection-12-intdir-telechat-krishnan-2025-11-18/

I hope that this review helps to improve the document,

Regards,

-éric

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

This section appears to be focused on sending a request to `a node` while it is
actually to "an IPV6 address" that could be anycast or multicast. The added
text in section 8 should also appear in this section and possibly in section 7;
noting that using 'unicast IPv6 address' instead or in addition to 'node' would
be clearer.

### Section 4

As discussed in other ballots, please drop `Middle boxes must not modify the
Reflect All extension object.` text as it is not enforceable. Even when using
'must' in lower case, it is normative.

### Section 7

Similar point as in section 1 above, what if the destination address is anycast
or multicast ? I.e., having an amplification potential.


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


## COMMENTS (non-blocking)

### Abstract

s/This document describes the ICMPv6 Reflection utility/This document
*specifies* the ICMPv6 Reflection utility/ as it is a proposed standard I-D.

### Section 4

Why not a MUST in `whose length SHOULD be sufficient` ?

Part of the text of this section seems repeating, e.g., `does not conflict with
its policy` and later `does not violate the probed node's security policy`.
Please consider trimming the text.

As the SEC ADs do not mind, I am moving this comment to the non-blocking part:
should/must the content of the sender 'object payload' be zero'ed ? See also my
point in section 5

### Section 5

As the SEC ADs do not mind, I am moving this comment to the non-blocking part:
`The object payload field in a request message MAY contain all zeros.` why not
a MUST ? Allowing other data is an open door for covert channel.

### Section 6

Please add a URI for `"ICMP Extension Object Classes and Class Sub-types"`
registry.

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)