Valentin, > On Jun 20, 2023, at 10:45 AM, Valentin Heinrich <v.heinric...@gmail.com> > wrote: > > we had similar questions when working on reverse traceroute > (https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute). > Should we use new ICMP types or extend existing ones with a new code? > > We actually conducted measurements to test deployability of those two choices. > One of the big question marks was whether new ICMP messages using a new type > are able to traverse common NAT middleboxes. > Unfortunately, as one would probably expect, new ICMP types are most commonly > filtered (or they just bypass the NAT, which is just as bad as they are > forwarded untranslated into the public internet). > We then sent ICMP Echo requests with the new codes 1 and 2 through those same > NAT boxes. > Only a single NAT box (out of 12) dropped the corresponding Echo response > message and in all other cases both requests and replies correctly traversed > the NAT. > In this regard, our measurements showed that extending existing ICMP Echo > messages with new codes is the way to go if immediate deployability is the > goal. > > We then also performed a measurement to assess the deployment of ICMP Echo > messages with new codes on the public Internet. > We probed over a million hosts that correctly responded to regular ICMP Echo > requests (code 0) with ICMP Echo responses. > To each of those hosts we sent ICMP Echo requests with code 1. Over 92% of > the probed hosts responded with an ICMP Echo response and reflected the new > code back in their response. > The fact that we received that many "reflective" responses shows us, that > ICMP Echo messages (both request and response) with a new code make it > through the Internet unfiltered and unaltered in the vast majority of cases. > About 3% of the probes were answered with a regular ICMP Echo response (code > 0), thus not reflecting the request's code back. > > For more details of the measurement study, you can have a look at this talk: > https://youtu.be/Y7NtqLEtfgjU?t=63 > > Or listen to this episode of the Ping Podcast: > https://blubrry.com/ping_podcast/94883480/reverse-traceroute-its-just-traceroute-but-the-other-direction/ > > One caveat is however that we conducted these measurements only on IPv4. > Results might or might not differ for IPv6. > For reverse traceroute, which itself implements both ICMP and ICMPv6, we have > however successfully tested our implementation across the public internet.
That is a major caveat. Testing with IPv4 ICMP is not very relevant for learning about the behavior of a new ICMPv6 message, specifically the proposed ICMPv6 loopback. Bob > > I hope this data point helps in this discussion. > > On 07.06.23 06:30, Tal Mizrahi wrote: >> Bob, Eric, >> >> Thanks for the feedback. >> Defining a new code for ICMPv6 Echo rather than defining a new type >> may be the right way to go. >> Our main concern with this is that RFC 4443 defines what to do with an >> unknown type, but does not define what to do with an unknown code. It >> is not clear what existing implementations do when receiving an Echo >> Request with an unknown code. That is why the current draft calls for >> a new type. However, we are open to more feedback about this, and it >> may end up being just a new code. >> >> Cheers, >> Tal. >> >> On Tue, Jun 6, 2023 at 8:33 PM Eric Vyncke (evyncke) <evyn...@cisco.com> >> wrote: >>> Without any hat, I agree with Bob. >>> >>> This I-D should eventually go to 6MAN WG though (with my AD hat) >>> >>> -éric >>> >>> On 06/06/2023, 08:34, "Int-area on behalf of Bob Hinden" >>> <int-area-boun...@ietf.org <mailto:int-area-boun...@ietf.org> on behalf of >>> bob.hin...@gmail.com <mailto:bob.hin...@gmail.com>> wrote: >>> >>> >>> Tal, >>> >>> >>> I did a quick read of your draft. >>> >>> >>> As noted in the draft this seems to be very similar to ICMPv6 Echo/Echo >>> Reply. The change is to include the request packet in the response, not >>> just the payload. >>> >>> >>> While I don’t have any real opinion on the need for this, I do think it >>> would be a lot simpler if the draft just defined a new Code field value for >>> Echo Request/Reply that specified this behavior. Currently the Code field >>> is set to zero, another value could specify this behavior. >>> >>> >>> Deployment might be easier as I suspect ICMPv6 types other than the current >>> definitions will be filtered in many places. >>> >>> >>> Bob >>> >>> >>> >>> >>> >>> >>>> On Jun 6, 2023, at 4:54 AM, Tal Mizrahi <tal.mizrahi....@gmail.com >>>> <mailto:tal.mizrahi....@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> New draft: >>>> https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/ >>>> <https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/> >>>> >>>> We have posted a new draft that proposes two new ICMPv6 message types: >>>> Loopback Request and Reply. >>>> ICMPv6 Loopback is very similar to Echo, except that after a Loopback >>>> Request is sent, its corresponding Reply includes as much of the IPv6 >>>> Loopback Request packet as possible, including the IPv6 header and >>>> IPv6 extension headers and options if they are present. >>>> >>>> We believe that ICMPv6 Loopback can be very useful for returning IPv6 >>>> options that were included in Request packet back to the sender, >>>> including for example sending IOAM [RFC 9197] data from the Request >>>> back to the sender, sending the SRH [RFC 8754] of the Request back to >>>> the sender, as well as for in-progress / future protocols such as >>>> draft-filsfils-spring-path-tracing and draft-kumar-ippm-ifa. >>>> >>>> We would be happy for feedback, as well as suggestions about whether >>>> the INT-AREA WG is the right place to discuss this draft. >>>> >>>> Cheers, >>>> Tal. >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org <mailto:Int-area@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/int-area >>>> <https://www.ietf.org/mailman/listinfo/int-area> >>> >>> >>> >>> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
