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

[Ketan Talaulikar <[e-mail]>]

Hi Tal,

Thanks for the helpful discussion. I am beginning to correctly
understand the proposal now.

Please check inline below for KT3.


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

> Hi Ketan,
>
> Many thanks for yet another iteration. This is very helpful in
> improving the document.
> Please see below, marked [[TM]].
> If you are okay with these replies, we will post an updated version.
>

KT3> Yes, an updated version will help us get to closure. Please see
further below.


>
>
>
>
> On Thu, Dec 4, 2025 at 2:08 PM Ketan Talaulikar <[e-mail]>
> wrote:
> >
> > 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.
>
> [[TM]] Indeed, as you point out, the object payload in this example
> should be *at least* 52B long: "SHOULD be sufficient to carry the IPv6
> and ICMP header of the reflected request message". However, the object
> payload can be longer: "If the 'Reflect All' object is sufficiently
> long, the reply message includes the initial octets of the 'Reflect
> All' object." This is exactly the case in this example. The object
> payload in the reply includes the 56B of headers, followed by the
> *first* 44B of the object payload.
>

KT3> Please let me know if the following is correct. First, the size of the
reflect-all object is entirely determined by the initiator. Second, it MUST
be at least the size of the request packet from the start of the IPv6
header until the ICMP Extension header unless MTU considerations or
local policy require a smaller size. Third, the size MAY be larger up to
what can fit within the minimum IPv6 MTU. Then for the responder, it MUST
copy as much of the content of the request packet from the start of the
IPv6 header into the payload of the reflect-all object until the size
provided by the length of the reflect-all object in the request unless the
response would exceed the minimum IPv6 MTU or due to a local policy on the
responder. If this is correct, could you please incorporate something along
those lines? I believe it greatly simplifies the procedure?


>
> >
> > 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 ...
>
> [[TM]] Good catch. This sentence needs to be changed - the new text
> you suggested for this sentence in one of the comments down in this
> thread is excellent.
>

KT3> Ack.


>
> >
> > 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:
>
> [[TM]] Not exactly. As the draft says: "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". In the current example, since the object payload is
> 100B long, the probed node copies 100 bytes starting from the
> beginning of the IPv6 header of the request, and up to the end of the
> 44th byte of the request's object payload.
>

KT3> I guess I was confused by the somewhat contradicting text in different
sections and paragraphs. Could you please move all procedures into section
4 and check/review for consistency? Please consider simplification as
suggested above.


>
> >
> > 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?
>
> [[TM]] Not exactly. The reflected copy is not placed at the end of the
> object payload. First, the length of the reply's Reflect-All object is
> known from the object header. Then, the reply's object payload always
> begins with the request's IPv6 header, so the rest can be parsed by
> the probing node accordingly. Thus, the parsing by the probing node is
> pretty simple, and the number of bits of the "object payload" that are
> returned in the reply are derived from this parsing.
>

KT3> Ack - I understand this better now with your explanation, but this was
not clear to me from the text.


>
> >
> >>
> >> 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.
>
> [[TM]] Figure 1 is just an example. Would it resolve the issue (and
> previous issues) if we added a second example in which the extension
> header length on the reply and request are not the same, and also the
> object payload is long enough to include the beginning of the
> request's object payload in the reply?
>

KT3> Yes please. It would be very helpful.


>
> >
> > 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 ...
>
> [[TM]] This would be a pretty large structural change this late in the
> process. I hope that once we clarify the other issues this will not be
> necessary.
>

KT3> Of course, this was only an editorial suggestion. Please only
consolidate the procedures in section 4 for ease of the reader.


>
> >
> > 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.
>
> [[TM]] Yes, this change makes sense.
>

KT3> Thanks.


>
> >
> > 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.
>
> [[TM]] If these two comments are not blocking from your perspective,
> we hope that the rest of the changes should be enough in terms of
> clarity.
>

KT3> Yes, I am only seeking clarity and simplification.


>
> >
> >
> >>
> >>
> >> 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?
>
> [[TM]] In previous versions of the document we did not describe the
> timestamp use case, because, as you point out, it does not require
> interoperability. See, for example:
> https://datatracker.ietf.org/doc/draft-ietf-6man-icmpv6-reflection/07/
> However, in previous reviews we were asked to explain what the
> arbitrary data is used for. Hence this informative explanation. I
> believe the authors would not mind removing this text, but this would
> conflict with some of the previous reviews we had, and probably some
> readers find this text useful.
>

KT3> I had a quick look at the reviews from other ADs and found that their
concern was with the use of arbitrary data itself (as in why not make it
must-be-zero). Adding text saying timestamp could be one such arbitrary
data is likely not addressing their concerns. However, if the text (that we
discussed above) says that the responder MUST not put anything in the
object payload besides copying the data from the request packet then it at
least ensures that this extension is not a two-way communication channel
and is just a reflection function. Please let me know your views. I would
like the reference to timestamp removed as per the original document from
authors/WG and can check with the other ADs if you can point me to their
reviews.


>
> >
> >>
> >> 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.
>
> [[TM]] Notably, there is no "special handling" by the probed node. It
> just copies, starting from the IPv6 header of the request, as many
> bytes as fit into the object payload. The handling is rather simple,
> with the exception of verifying that the length does not exceed any
> policies or MTU.
>

KT3> Indeed. I was not able to understand correctly and the clarifications
will help.

Thanks,
Ketan


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