[IPv6]Re: Gorry Fairhurst's Discuss on draft-ietf-6man-icmpv6-reflection-12: (with DISCUSS and COMMENT)

[Tal Mizrahi <[e-mail]>]

Hi Gorry,

Thanks for the quick response.

Please see inline, marked [TM]



On Thu, Dec 4, 2025 at 11:40 AM Gorry Fairhurst <[e-mail]> wrote:
>
> On 04/12/2025 06:09, Tal Mizrahi wrote:
>
> Hi Gorry,
>
> Regarding the 3 DISCUSS points that you raised, we would like to
> confirm that you would be fine with the following:
>
> DISCUSS point 1: Rate limiting issue - as Ron suggested, we can
> rephrase the text to explain that rate limiting is as defined in
> RFC4443 and rfc8335bis. Please let us know if such an update addresses
> your concern.
>
> Thanks for contacting me.
>
> The current text reads:
>
> "
>
>    As specified in [I-D.ietf-intarea-rfc8335bis], in order to protect
>    local resources, implementations SHOULD rate-limit incoming ICMP
>    Extended Echo Request messages. "
>
> Given the importance of this, I was hoping the document would explicitly refer to the text in RFC4443, for example this text:
>
> In order to limit the bandwidth and forwarding costs incurred by originating ICMPv6 error messages, Section 2.4 of RFC 4443 requires that "an IPv6 node MUST limit the rate of ICMPv6 error messages it originates.

[TM] Since the current document does not use ICMPv6 error messages, I
would prefer not to explicitly mention error messages to avoid
confusion. Would the following text update work?
OLD:
    As specified in [I-D.ietf-intarea-rfc8335bis], in order to protect
    local resources, implementations SHOULD rate-limit incoming ICMP
    Extended Echo Request messages. "
NEW:
In order to limit the bandwidth and forwarding costs incurred by
processing and/or originating ICMPv6 messages, rate-limiting
mechanisms are employed in accordance with the requirements defined in
[I-D.ietf-intarea-rfc8335bis] and [RFC 4443].

>
> (This text could further refer to section 2.4 for more detail if you so wish.)
>
> Although, off-topic I plan to also note this as a comment to I-D.ietf-intarea-rfc8335bis.
>
> DISCUSS points 2,3: please let us know if Ron's clarifications below
> make sense to you.
>
> Point 2:  What is the value of the Hop Limit field in the returned packet header? - Please could the document explain whether the value would be decremented during the receiver packet processing at the probed node, or was it the value as received?
>
> This is clear, thank you for pointing me to this text:
>
> "
>
>    The reply message includes a copy of the request message, starting
>    from its IPv6 header, as it was when it arrived at the probed node."
>
> Point 3:  Are the received Extension Headers included in the returned packet header when receiving this message type: i.e., - is the EH Chain present in the returned packet header?
>
> (I was asking if it reflected copy of the packet included these headers, i.e., the copied packet is BEFORE it processed on reception). I now do understand.
>
> For me, it would be really helpful to add a sentence with a clarifying example that avoids people asking this "obvious" question as they read the text, e.g., "This copied message includes the IPV6 header (that has the node's address and the received value of the Hop Limit) and the extension header chain".

[TM] Does the following update make sense?
OLD:
   ...the reply includes the reflected request message starting from the IPv6
   header and up to and including the ICMP Extension Header, as shown in
   Figure 1.
NEW:
   ...the reply includes the reflected request message starting from the IPv6
   header and up to and including the ICMP Extension Header, as shown in
   Figure 1. This reflected message includes the IPv6 header as received
   by the probed node, including, for example, the received value of the
   Hop Limit and the received IPv6 extension headers.


Thanks,
Tal.

>
> Thanks,
> Tal.
>
> Thanks for also addressing my additional comments, I look forrward to finalising this,
>
> Best wishes,
>
> Gorry
>
> On Wed, Nov 19, 2025 at 5:33 PM Bonica, Ron <[e-mail]> wrote:
>
> Gorry,
>
> Thanks for the review. Comments inline....... RB>
>
>                                   Ron
>
>
> ________________________________
> From: Gorry Fairhurst via Datatracker <[e-mail]>
> Sent: Monday, November 17, 2025 5:30 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Gorry Fairhurst's Discuss on draft-ietf-6man-icmpv6-reflection-12: (with DISCUSS and COMMENT)
>
> Gorry Fairhurst has entered the following ballot position for
> draft-ietf-6man-icmpv6-reflection-12: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!GICYLiQ3amnoXQ0ZDsy3iLlE-5Z-R-g0zSTQjpS6V0eAnXsbawGeOTocyAnelLfORwI7iUQpoNlFIKs$
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-icmpv6-reflection/__;!!NEt6yMaO-gk!GICYLiQ3amnoXQ0ZDsy3iLlE-5Z-R-g0zSTQjpS6V0eAnXsbawGeOTocyAnelLfORwI7iUQpzLhS-iw$
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work that has been put into this document.This new variant of
> ICMP looks like it could have application to transport layer measurements of
> path traversal, and debugging network problems.
>
> Please find below some blocking DISCUSS points (that may be trivial to address):
>
> As noted in
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!NEt6yMaO-gk!GICYLiQ3amnoXQ0ZDsy3iLlE-5Z-R-g0zSTQjpS6V0eAnXsbawGeOTocyAnelLfORwI7iUQpaRUXr08$ ,
> 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.
>
> (1) This “document asserts “SHOULD rate-limit incoming ICMP Extended Echo
> Request messages“, whereas RFC 4443 requires “an IPv6 node MUST limit the rate
> of ICMPv6 error messages it originates”, albeit the RFC follows with some
> discussion of how to achieve that required rate limiting.
>
> RB> We would be happy to remove that sentence and replace it with the following:
>
> RB> This document complies with all RFC 4443 and [I-D.ietf-intarea-rfc8335bis] requirements. Network operators should do likewise as they deploy the features described in this document.
>
>
> (2) What is the value of the Hop Limit field in the returned packet header? -
> Please could the document explain whether the value would be decremented during
> the receiver packet processing at the probed node, or was it the value as
> received?
>
> RB> The document is clear on this point. See the following text in Section 1:
>
> "The reply message includes a copy of the request message, starting
>    from its IPv6 header, as it was when it arrived at the probed node."
>
>
> (3) Are the received Extension Headers included in the returned packet header
> when receiving this message type: i.e., - is the EH Chain present in the
> returned packet header?
>
> RB> First, let me make sure that I understand your question. Are you asking if the IPv6 header that carries the ICMP Extended Echo Reply will have extension headers?
>
> If so, the answer to that question is a matter of local policy and is beyond the scope of this document. This document's scope is limited to the contents of the ICMP Extended Echo Request and Reply messages.
>
> Local policy determines which extension headers are attached to every IPv6 message that the probed node sends. The same local policy applies to ICMP Extended Echo Response messages.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> These are non-blocking comments:
> * Please change the reference to RFC 3022, to minstead ention NAT66 rather than
> the IPv4 NAPT RFC [RFC 3022].
>
> RB> Ketan recommends that we remove the entire sentence. So the reference is also removed
>
> * Please say more about how to use the response received: The packet carrying
> the message (or the message itself) could  be modified in transit - despite the
> “MUST NOT” modify requirement, because this is required, but not enforceable,
> and therefore the interpretation of the response ought to consider this. Please
> also read and consider the TSV-ART review by Kyle Rose on manipulation in the
> network:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-6man-icmpv6-reflection-11-tsvart-lc-rose-2025-10-15/__;!!NEt6yMaO-gk!GICYLiQ3amnoXQ0ZDsy3iLlE-5Z-R-g0zSTQjpS6V0eAnXsbawGeOTocyAnelLfORwI7iUQpVEfDq2A$
> * I think in describing the expected usage, it would be very helpful to mention
> the use of IPv6 NAT64, and note that NAT64 the response expected from a probed
> destinationnode that is actually an IPv4 host.
>
> RB> Might it be helpful to add the following guidance: Middle-boxes MAY discard, but SHOULD NOT modify the ICMP Extended Echo Request / Response packets.
>
>