[IPv6]Re: Ketan Talaulikar's Discuss on draft-ietf-6man-icmpv6-reflection-15: (with DISCUSS)

[Tal Mizrahi <[e-mail]>]

Hi Ketan,

Please see inline, marked [TM].


On Wed, Dec 3, 2025 at 3:59 PM Ketan Talaulikar <[e-mail]> wrote:
>
> Hello Ron and Tal,
>
> Thanks for the updates that address most of my discussion points and
> comments. Only the following remain.
>
> Please check inline below for brief clarifications based on the latest text

On Wed, Dec 3, 2025 at 6:48 PM Ketan Talaulikar via Datatracker <
[e-mail]> wrote:

> Ketan Talaulikar 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:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for their work on this document.
>
> I have a few points that I would like to discuss with the authors/WG.
>
> Note: This ballot has been updated based on v15 of the document. The
> original
> numbering of points has been retained and points that are closed have been
> deleted.
>
> <discuss-2> I am a bit confused by the very strict and exact check for the
> message size against the payload size allowed in the Reflect-All object.
> What
> if (due to some reason), the extension header size were to change, or some
> extension headers inserted/removed in flight? Regardless of whether those
> things are allowed by RFC8200, they could be happening in the network. This
> strict check in the spec prevents the detection of such changes - there
> would
> only be an error reported and that is not very helpful to know what has
> changed. What would be the problem if the Reflect-All object carried space
> sufficient for the exact originated payload but the responder is allowed
> to put
> in as much information as required to carry the payload in the response?
> Am I
> missing something else that warrants such a strict check?
>

KT> In the following text, I assume this is the size from the start of the
ICMPv6 header until the end of the IPv6 packet. Is that correct?

[TM] Right.

The word
"total" perhaps seems odd. Then the figure 1 got me confused since it gives
the impression that the two IPv6 packets are of the same size which need
not be the case because the IPv6 header chain on them need not be the same.
E.g., the incoming packet may have some HBH and DOH but the response may or
may not have them.

[TM] If the word "total" is removed, would that clarify the issue?

The total length of the ICMPv6 Extended Echo Reply message is equal to the
total length of the corresponding request message, ...

KT> In short, the maths and the checks are being made super complicated.
Can't it be simplified such that the requester decides the size it wants
reflected back by setting that length value in the Reflect-All object
length and then the responder fills that space to the extent possible (less
than or equal to) starting from the IPv6 header and upto/until the start of
the Reflect-All object in the original request packet?

[TM] Would the following update resolve the concern?

OLD:
   The ICMPv6 Extended Echo Reply message also contains an ICMP
   Extension Structure.  The ICMP Extension Structure MUST contain the
   'Reflect All' object that the ICMPv6 Extended Echo Request message
   contained. The length of the ICMP Extension Structure in the reply
   message MUST be less than or equal to the length of the ICMP
   Extension Structure of the request message.  Specifically, the ICMP
   Extension Structure in the reply can be shorter if the probed node's
   policy restricts the reply length or the reply size would exceed the
   MTU.  Similarly, the length of the 'Reflect All' object in the reply
   message MUST be less than or equal to the length of the 'Reflect All'
   object in the request message.
NEW:
   The ICMPv6 Extended Echo Reply message also contains an ICMP
   Extension Structure.  The ICMP Extension Structure MUST contain the
   'Reflect All' object that the ICMPv6 Extended Echo Request message
   contained. The length of the 'Reflect All' object in the reply
   message MUST be less than or equal to the length of the 'Reflect All'
   object in the request message. Specifically, the 'Reflect All'
   object in the reply can be shorter if the probed node's
   policy restricts the reply length or the reply size would exceed the
   MTU.


>
> <discuss-5> Section 5 says:
>
> If the 'Reflect All' object is sufficiently long, the reply message
> includes
> the initial octets of the 'Reflect All' object. A notable use case for
> including arbitrary data in the object payload is the inclusion of a
> transmission timestamp, similar to how conventional Ping utilities
> incorporate
> timestamps into the ICMP payload. If the initial octets of the 'Reflect
> All'
> object payload contain a timestamp and the object is long enough, the
> timestamp
> is reflected back to the probing node, enabling round-trip time
> calculations.
>
> This kind of approach is a big problem for interoperability. If a
> timestamp is
> desired then it should be well specified as another ICMP Extension Header
> object with a proper format. Let us please not publish specs with such
> secret
> and private communication channel ideas.
>
> Also, the text on what the responder needs to do is not clear. I believe
> the
> intention is that it will form a new ICMPv6 packet (without any extension
> headers normally?) and in that encode the original IPv6 packet carrying the
> ICMPv6 reflection request in the Reflect-All object payload - in doing so,
> it
> will take the contents of the request only until the start of the
> Reflect-All
> object. Am I correct?
>

KT> Could you please point me to a reference that describes where/how
timestamp can be entered into the "arbitrary" data as indicated in the text
below?

 A notable use case for including arbitrary data in the object payload is
the inclusion of a transmission timestamp, similar to how conventional Ping
utilities incorporate timestamps into the ICMP payload. If the initial
octets of the 'Reflect All' object payload contain a timestamp and the
object is long enough, the timestamp is reflected back to the probing node,
enabling round-trip time calculations.


[TM] The timestamp use case is not described in the RFC series to the
best of my knowledge since it is an implementation issue that does not
require interoperability. For example, the Ping implementation in
iputils uses an 8 byte timestamp in Echo Request messages.
Notably, the probed node in the Reflection utility is not aware of
whether there is a timestamp in the request, and there is no specific
functionality that is required from the probed node in this context.
For example, if the timestamp is incorporated into the first 8 bytes
of the object payload of the request, then as long as the Reflect-All
object in the reply is long enough to include the first 8 bytes of the
request's object payload, the probing node will get the timestamp back
and will be able to use it as existing Ping utilities work today.


Thanks,
Ketan

[TM] Cheers,
Tal.