[IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection

["Zafar Ali (zali)" <[e-mail]>]

Hi Ron

Thanks for your follow up – much appreciated!

This comment was related to the normative text related to middleboxes for handing the Extended Echo Reply. Specifically, “The payload of Extended Echo Reply messages (like almost all other payloads) MUST NOT be modified by middleboxes.”

Given the thread Bob forked off for the middleboxes, I do not think we can add normative text for Extended Echo Reply messages either. Hence the middleboxes discussion is a moot point.

As one of the justifications for the draft-ietf-6man-icmpv6-reflection: the middleboxes (for NAT) manipulate the ICMP error message, can you please update the text in the draft that document the alternative (used today). I.e., can you please remove the following text from the draft:

“Additionally, the payload of ICMP error messages such as Destination Unreachable might be modified by middleboxes (e.g. [RFC3022]), whereas ICMPv6 Reflection is intended to reflect parts of the request message as received by the probed node.”

Thanks

Regards … Zafar

From: Ron Bonica <[e-mail]>
Date: Thursday, May 15, 2025 at 12:07 PM
To: Zafar Ali (zali) <zali=[e-mail]>, Tal Mizrahi <[e-mail]>
Cc: Sebastian Moeller <[e-mail]>, 6man Chairs <[e-mail]>, [e-mail] <[e-mail]>, draft-ietf-6man-icmpv6-reflection <[e-mail]>, Zafar Ali (zali) <[e-mail]>
Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
Zafar,

I think that it would be best to make the statement that you propose in a separate document. The following are rationale:


  *   I assume that you want the statement to apply to both ICMPv6 and ICMPv4. If so, the statement would be out of scope for the 6man WG. It would have to be made in an INTAREA WG document.

  *   Draft-ietf-6man-icmpv6-reflection does not rely on or modify ICMP error messages. Therefore, the statement doesn't seem relevant to the rest of the document.

Furthermore,  Section 4.3 of RFC 3022 says:


  "Changes to ICMP error message ([ICMP<https://www.rfc-editor.org/rfc/rfc3022#ref-ICMP>] will include changes to IP and

   ICMP headers on the outer layer as well as changes to headers of the

   packet embedded within the ICMP-error message payload."



RFC 5508 is consistent with RFC  3022.



Do we really want to contradict or UPDATE RFCs 3022 and 5508 from this document? If so, would be overstepping the charter of the WG.



The chairs may want to weigh in.



                                                                                   Ron









Juniper Business Use Only

________________________________
From: Zafar Ali (zali) <zali=[e-mail]>
Sent: Thursday, May 15, 2025 12:47 AM
To: Tal Mizrahi <[e-mail]>
Cc: Ron Bonica <[e-mail]>; Ron Bonica <[e-mail]>; Sebastian Moeller <[e-mail]>; 6man Chairs <[e-mail]>; [e-mail] <[e-mail]>; draft-ietf-6man-icmpv6-reflection <[e-mail]>; Zafar Ali (zali) <[e-mail]>
Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection

[External Email. Be cautious of content]


Hi Tal, Ron, et al.



The suggested text looks fine to me.



I have one question regarding the following text.

“The payload of Extended Echo

   Reply messages MUST NOT be modified by middleboxes.”



While we are at this, can you please also document that the middleboxes should not modify the payload of the ICMP error messages, as well.



Thanks



Regards … Zafar



From: Tal Mizrahi <[e-mail]>
Date: Thursday, May 15, 2025 at 12:33 AM
To: Zafar Ali (zali) <[e-mail]>
Cc: Ron Bonica <[e-mail]>, Ron Bonica <rbonica=[e-mail]>, Sebastian Moeller <[e-mail]>, 6man Chairs <[e-mail]>, [e-mail] <[e-mail]>, draft-ietf-6man-icmpv6-reflection <[e-mail]>
Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection

Hi Zafar,

A kind reminder: would you say that the text below addresses your main
comment from WG last call, and if the answer is no, how would you
suggest to rephrase the text?

Thanks,
Tal.

On Mon, May 12, 2025 at 6:48 PM Tal Mizrahi <[e-mail]> wrote:
>
> Hi Zafar,
>
> Many thanks for the feedback.
> I re-read all your comments from working group last call, and I
> believe the following comment you sent summarizes them (correct me if
> I am wrong):
> "the main point is that adding description of the use of existing
> tools and compare it with reflection functionality will help the
> reading of draft-ietf-6man-icmpv6-reflection"
>
> In order to address this comment we added a description of the UDP
> probe and ICMP error message (quoted at the end of this message).
>
> Would you say that the new text addresses your feedback about
> describing existing tools and comparing them to ICMP reflection? If
> the answer is no, how would you suggest to change this text?
>
> Cheers,
> Tal.
>
> Quoting the new text from draft-ietf-6man-icmpv6-reflection:
>
>    An alternative approach that could be considered involves the probing
>    node sending a UDP packet with an unused destination port to the
>    probed node, causing the probed node to send an ICMPv6 Destination
>    Unreachable message, which includes "As much of invoking packet as
>    possible without the ICMPv6 packet exceeding the minimum IPv6 MTU"
>    [RFC4443].  The benefit of ICMPv6 Reflection is that it enables the
>    probing node to selectively request specific parts of the request
>    message to be included in the reply.  Additionally, the payload of
>    ICMP error messages such as Destination Unreachable might be modified
>    by middleboxes (e.g. [RFC3022]), whereas ICMPv6 Reflection is
>    intended to reflect parts of the request message as received by the
>    probed node.
>
>
>
> On Wed, Apr 30, 2025 at 4:33 PM Zafar Ali (zali) <[e-mail]> wrote:
> >
> > Hi Ron,
> >
> >
> >
> > I also do not see how text in your draft can influence the middle boxes.
> >
> > Hence, the gain against sending UDP probes to an unused destination remains:
> >
> > Only about requesting “specific” parts of the invoking packet vs. copy of the (as much as possible) invoking packet.
> >
> > Can you please document, accordingly.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Regards … Zafar
> >
> >
> >
> > From: Zafar Ali (zali) <[e-mail]>
> > Date: Monday, April 28, 2025 at 8:34 PM
> > To: Ron Bonica <[e-mail]>, Ron Bonica <rbonica=[e-mail]>, Erik Auerswald <[e-mail]>
> > Cc: Sebastian Moeller <[e-mail]>, 6man Chairs <[e-mail]>, [e-mail] <[e-mail]>, draft-ietf-6man-icmpv6-reflection <[e-mail]>, Zafar Ali (zali) <[e-mail]>
> > Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
> >
> > Hi Ron
> >
> >
> >
> > I think this is not a big limitation.
> >
> > When someone is running a traceroute outside of a limited domain, in which NAT is deployed, having some address mapping done on the invoking packet can be reasoned. I would suggest the limitation with the specifics.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Regards … Zafar
> >
> >
> >
> > From: Ron Bonica <[e-mail]>
> > Date: Monday, April 28, 2025 at 2:30 PM
> > To: Zafar Ali (zali) <[e-mail]>, Ron Bonica <rbonica=[e-mail]>, Erik Auerswald <[e-mail]>
> > Cc: Sebastian Moeller <[e-mail]>, 6man Chairs <[e-mail]>, [e-mail] <[e-mail]>, draft-ietf-6man-icmpv6-reflection <[e-mail]>
> > Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
> >
> > Zafar,
> >
> >
> >
> > If we were to do this, would we need to add a note that saying that the utility may yield unreliable results when run outside of a limited domain, in which NATs are known to be absent? SHOULD we add a note saying that running the utility outside of such a limited domain is NOT RECOMMENDED?
> >
> >
> >
> >                                                                                                            Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> >
> > From: Zafar Ali (zali) <[e-mail]>
> > Sent: Monday, April 28, 2025 12:17 PM
> > To: Ron Bonica <rbonica=[e-mail]>; Erik Auerswald <[e-mail]>
> > Cc: Sebastian Moeller <[e-mail]>; 6man Chairs <[e-mail]>; [e-mail] <[e-mail]>; draft-ietf-6man-icmpv6-reflection <[e-mail]>; Zafar Ali (zali) <[e-mail]>
> > Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
> >
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> >
> > Hi Ron
> >
> >
> >
> > Documenting "traceroute method" as an alternative to ICMPv6 reflection's core functionality with the NAT specifics would be the right thing to do (given large set of implementations).
> >
> >
> >
> > Thanks
> >
> >
> >
> > Regards … Zafar
> >
> >
> >
> > From: Ron Bonica <rbonica=[e-mail]>
> > Date: Monday, April 28, 2025 at 9:41 AM
> > To: Erik Auerswald <[e-mail]>
> > Cc: Sebastian Moeller <[e-mail]>, 6man Chairs <[e-mail]>, [e-mail] <[e-mail]>, draft-ietf-6man-icmpv6-reflection <[e-mail]>
> > Subject: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
> >
> > Erik,
> >
> >
> >
> > Thanks for this good research.
> >
> >
> >
> > You say, "For IPv6, as long as no NAT is involved, the "traceroute method" seems promising as an alternative to ICMPv6 reflection's core functionality. NAT66 would most likely affect this negatively." I think that this statement is absolutely correct.
> >
> >
> >
> > But how does the user know if NAT is involved? Given that the user cannot know this, I conclude that ICMPv6 Reflection is the best solution. While it requires more work than the "traceroute method", its results are more reliable.
> >
> >
> >
> >                                                        Ron
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > ________________________________
> >
> > From: Erik Auerswald
> > Sent: Monday, April 28, 2025 8:16 AM
> > To: Ron Bonica
> > Cc: Sebastian Moeller; 6man Chairs; [e-mail]; draft-ietf-6man-icmpv6-reflection
> > Subject: Re: [IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection
> >
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Ron,
> >
> > On Fri, Apr 25, 2025 at 05:00:40PM +0000, Ron Bonica wrote:
> > > [...]
> > > I have also done some research with a popular platform. I found that:
> > >
> > >   * It complies with RFC 792 and 4443 regarding the number of bytes
> > >     in the invoking packet field.
> > >   * It does not modify the invoking packet field.
> > >
> > > However, your finding that a LINUX-based NAT box modifies the invoking
> > > packet field is significant. [...]
> >
> > RFC 5508[1] (NAT Behavioral Requirements for ICMP), currently BCP 148,
> > requires NAT to modify the embedded packet's addresses according to the
> > matching NAT mapping that is also used to translate the ICMP packet's
> > addresses (REQ-4 and REQ-5).
> >
> > Section 5.3 of RFC 6145[2] (IP/ICMP Translation Algorithm) also describes
> > the translation of the invoking packet (called "packet in error").
> >
> > RFC 6296[3] (IPv6-to-IPv6 Network Prefix Translation) does not describe
> > translation of ICMPv6 error messages.
> >
> > If I were to speculate, I would expect NAT66 to also translate invoking
> > packet field addresses, if not now, then after deployment experience.
> >
> > Section 3.8 of the expired Internet-Draft
> > draft-bctb-6man-rfc6296-bis-02[4] (RFC 6296bis IPv6-to-IPv6 Network
> > Prefix Translation) requires translation of the invoking packet field:
> >
> >    "For an ICMPv6 error, both the addresses in the outer IPv6 header
> >     and the embedded IPv6 header in the ICMPv6 error message must be
> >     translated."
> >
> > For IPv6, as long as no NAT is involved, the "traceroute method" seems
> > promising as an alternative to ICMPv6 reflection's core functionality.
> > NAT66 would most likely affect this negatively.
> >
> > ICMPv6 reflection does not address IPv4, but the "traceroute method"
> > seems to be more limited for IPv4, because (1) RFC 792 specifies that
> > only the IP (version 4) header and the 8 bytes following this header
> > are included in ICMP error messages, and (2) NAT44 is prevalent.
> >
> > > [...]
> >
> > Best regards,
> > Erik
> >
> > [1]: https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5508__;!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhaKVw6FEg$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc5508__;!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhaKVw6FEg$>
> > [2]: https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6145*section-5.3__;Iw!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhakGJfyO8$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc6145*section-5.3__;Iw!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhakGJfyO8$>
> > [3]: https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6296__;!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhaKxV-p-A$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc6296__;!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhaKxV-p-A$>
> > [4]: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bctb-6man-rfc6296-bis-02.html*name-icmpv6-error-forwarding__;Iw!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhabcv-pZk$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bctb-6man-rfc6296-bis-02.html*name-icmpv6-error-forwarding__;Iw!!NEt6yMaO-gk!EXQDayNijAz4qi0p1B4eh1p_gAylhXnL4qkhOdZeJneujeEno1k8DLAe8lhRjG-KKSoefsH9Ii8VZg3I7xhabcv-pZk$>