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

[Ketan Talaulikar <[e-mail]>]

Hi Tal,

Thanks for your response. Please check inline below for KT2 for some
follow-ups.


On Thu, Dec 4, 2025 at 1:32 PM Tal Mizrahi <[e-mail]>
wrote:

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

KT2> Let me take your example so I can ask some clarifying questions:

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

KT2> Why does the request have a 100B length Reflect-ALL object? My
impression from the text was that this would normally be 52B (40+8+4)
unless the requester wanted some additional buffer space. More importantly
the 4B Reflect-All object header is not considered.

The 'Reflect All' object contains an object payload field whose length
SHOULD be sufficient to carry the IPv6 and ICMP header of the reflected
request message.

If the probed node is able to process the 'Reflect All' object, it MUST
copy the request message starting from the IPv6 header and up to and
including the ICMP Extension Header into the 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.

KT2> Please see previous comment - only 52B are copied from the request
message into the reflect-all object payload. But more importantly, I am
missing where it is specified that the first 48 (44 in your working) is
left alone and the copy is done towards the end of the object payload. I
find this very odd. I would have expected the payload starts with the
copied data and the trailing portion is left untouched - at least that is
what I got from the following text:

In reply messages the object payload field MUST contain the received
request message starting from the beginning of the IPv6 header and
according to the length of the object payload, provided that the probed
node supports the 'Reflect All' object and that responding does not
conflict with its security policy.

KT2> There is also a problem with putting the reflected packet copy towards
the end of the object payload space. How does the initiator know where the
arbitrary data ends and the reflected packet begins in the payload since
the sizes of the objects are not always equal? What are the assumptions on
the initiator so it can figure out what the reflector has done (e.g., if it
has reduced the packet) or there has been some change in the extension
header chain in transit?


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

KT2> Yes, it would but there are other issues with clarity of the normative
text. What about if the request packet had IPv6 extension headers but the
response did not have it (i.e., no IPv6 extensions in the outer IPv6
packet) - or the other way around? The figure 1 gives the impression that
both IPv6 packets are equal, but are they always? The current picture could
mislead some.

KT2> Another issue is that text related to normative procedures are there
not just in section 4 but also section 5. I would suggest to swap the order
of these sections so the object is introduced before the procedures that
use it. However, the concern is section 5 has procedures ...

CURRENT:
If the probed node is able to process the 'Reflect All' object, it MUST
copy the request message starting from the IPv6 header and up to and
including the ICMP Extension Header into the object payload and update the
C-Type field to the 'Reply - No Error' value.
SUGGEST:
If the probed node is able to process the 'Reflect All' object, it MUST update
the C-Type field to the 'Reply - No Error' value.

KT2> The "MUST copy ..." can be covered in the procedures. This goes for
some other text that goes beyond describing the fields and starts to get
into procedures.

KT2> Please also consider structuring the procedures into sub-sections -
Originating of Echo Request for Reflection, Responding to Echo Request for
Reflection, Processing of Echo Response for Reflection at Originator. It
would improve the clarity and readability of the spec.



>
> 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.
>
>
KT2> This is better indeed.


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

KT2> Agree. So, if this is something that is leveraging arbitrary data in a
manner that is not interoperable , does this belong in a standard track
RFC? Why does this spec deviate from the convention of past ICMPv6 RFCs
that didn't talk about proprietary use of such arbitrary data?


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

KT2> Echo Request for Reflection fundamentally differs from the normal Echo
request. A node handling ping response is not bothered about where and what
arbitrary data is being carried. In the case of reflect, as I've described
in previous comments, there is special handling that is needed by the
responding to place the original packet copy in this arbitrary data which
is complicated. There is no issue with defining procedures normatively that
preserve some arbitrary data at the end of the reflection object - i.e., it
won't get touched because it is beyond the data to be copied. As long as
the document does not describe a proprietary timestamp use-case, there is
no issue.

Thanks,
Ketan


>
>
> Thanks,
> Ketan
>
> [TM] Cheers,
> Tal.
>