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

[Tal Mizrahi <[e-mail]>]

Hi Ketan,

Thanks for reviewing the updated version and thanks for the comments.
Please see below, marked [TM].

On Wed, Dec 3, 2025 at 3:17 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.

[TM] The text in version 15 has been updated compared to previous versions:

   The total length of the ICMPv6 Extended
   Echo Reply message is equal to the total length of the corresponding
   request message, unless the probed node's policy restricts the reply
   length or the reply size would exceed the MTU, in which cases the
   reply might be shorter.

Thus, if necessary, the reply is shorter than the request, but not
longer to avoid amplification. Therefore, this text is not as strict
in this context as in previous versions of the document.

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

[TM] Right, that is how it works. The only limitation is that the
reply length does not exceed the request length. Within this
limitation, the probed node copies as much as possible from the
request, starting from the beginning of the IP header, into the
Reflect-All object. This includes as much of the object payload as
possible.

Here is an example:

Request:
- 40B IPv6 header
- 8B ICMPv6 header
- 4B ICMPv6 extension header
- 4B object header
- 100B object payload

Reply:
- 40B IPv6 header
- 8B ICMPv6 header
- 4B ICMPv6 extension header
- 4B object header
- 100B object payload, consisting of 56B of the request's headers
(40+8+4+4 bytes), and the first 44B of the request's object payload.

Notably, the probed node truncates as much as needed from the request
in order to prevent the reply from being longer than the request.

Please let us know if we missed something here.


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

[TM] It is important to emphasize that there is no requirement for
interoperability, since the timestamp in the example is generated and
used by the probing node. The timestamp use case is identical to how
existing ICMP Echo Request and Reply are used in common Ping
implementations. This use case in ICMP Echo was never standardized
because it does not require interoperability.

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

[TM] The probed node 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.


Please let us know if this makes sense.

Cheers,
Tal.