Hi Tal,don't get me wrong. Of course a new type is technically an equally valid solution and I do not want to talk you into using new codes under an existing type instead. I just wanted to point out that I believe generally speaking working with new codes is equally valid and feasible, which is what reverse traceroute (https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute) is suggesting.
Using different codes was just one example to distinguish a request from a response given the reflective behavior of hosts on the internet. The same would apply if the ICMP payload or something else in the header would differ in the response.
Best, Rolf Am 21.06.23 um 13:49 schrieb Tal Mizrahi:
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. BobOn 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
