Hi Rolf, I agree that a new type is not necessarily required for every case, however a new type is probably the cleanest solution for Loopback.
Here is an alternative solution that does not require a new type: - The Loopback requester sends an Echo Request with code=X (newly allocated to indicate Loopback Request). - The Loopback responder replies with an Echo Reply with code=X+1 (newly allocated to indicate Loopback Reply). - The requester can distinguish a Loopback reply (code=X+1) from a reply received from a legacy device (which reflects code=X). While this solution should work, it assumes a certain behavior from legacy devices (reflecting code=X as-is) that is not compliant with RFC 4443. Therefore, I believe using a new type would be cleaner. Cheers, Tal. On Wed, Jun 21, 2023 at 12:39 PM Rolf Winter <rolf.win...@hs-augsburg.de> wrote: > > Hi Tal, > > I don't think your assessment that a new type is required really holds > for every case. I think the key point is, the requests get _reflected_. > So if you expect something else in you response (e.g. Echo Request would > expect a different type in the Echo Response), then you can distinguish > a reflecting host from a host that actually understands this "new ICMP > thing". The real good news is in both measurement cases are that a) most > tested NATs let those packets through (both request and response) and b) > mostly, they cross the internet unmodified as can be seen in the > unmodified code inside the ICMP reply (for v4 at least). > > Best, > > Rolf > > Am 21.06.23 um 06:53 schrieb Tal Mizrahi: > > Hi Valentin, > > > > Thanks for this valuable data. > > Based on your findings, the good news is that new codes will most > > likely traverse NATs, and the bad news is that most hosts will respond > > according to the "old" behavior without checking the code value. In > > light of the latter observation, I would say that new behavior *from > > the responder* requires a new ICMP type. However, more feedback about > > this assessment is welcome. > > > > Cheers, > > Tal. > > > > On Tue, Jun 20, 2023 at 8:45 PM 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. > >> > >> 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 > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
