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

[Sebastian Moeller <[e-mail]>]

Hi Zafar,



> On 30. Apr 2025, at 15:33, Zafar Ali (zali) <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.

So, I might miss  something here, but I think the issues are as follows:

A) tickling a destination unreachable/port unused message out of an end-point:
Pro: 
A.1.1) wide spread support in operating systems and routers (with the size of the reflected header being best effort and the returned value always starting from the beginning of the heder)
Cons: 
A.2.1: the reflected headers are subject to (reverse) NAT transformations for excellent reasons, as this is the only way how the end point can figure out which flow/connection the ICMP error belongs to.
A.2.2: the size of the returned packet can be quite small, as the goal is to avoid fragmentation, so for deep headers the tail end can be lost.

B) creating a new ICMP based method to have an endpoint reflect the header of the probe packet
Pro:
B.1.1: Not subject to reverse NAT transformations, so this will show the veridical header as received by the end point.
B.1.2: No ambiguity about flow/connection, as the reflector's address/port tupel will obviously be reverse NAT transformed and hence the sender knows the flow
B.1.3: Can use larger packets, might even allow path MTU discovery to go as large as possible
B.1.4: With the proposed sub-set selection, even with deep headers and small return packet size the likelihood of being able to extract any individual header field of interest is increased
Cos:
B.2.1: No support in existing gear
B.2.2: ATM IPv6 only, I understand that due to new technology like segment routing IPv6 this feature is more interesting for IPv6, but personally I believe that as long as IPv4 is used in the field, we should not introduce IPv6 only techniques that are conceptually just as applicable to IPv4.


One might think that there is no guarantee that middle boxes do not also modify payloads of ICMP information messages like they do with icmp error messages, but if that be the case than we would already expect wide spread issues with ICMP types that use meaningful information payloads, like echo request/replay ans IPv4 ICMP timestamps, where such a payload manipulation would show as either errors or as insane time values. So while the draft can not magically change how middle boxes behave, it looks like at least the majority of middle boxes already behave as required. As expected, the reverse NAT transformation is a somewhat costly operation, that not all NAT gateways seem to perform, so probing each ICMP payload for potential data to transform would seem to be quite some extra work.

Regards
	Sebastian

P.S.: I will try to comment upon the draft in detail in another message, but I thought the "middle box" behaviour issue is mostly conceptually relevant and decoupled from the draft text.





>  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 OnlyFrom: 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 OnlyFrom: 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$
> [2]: 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$
> [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$
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------