Re: [Int-area] New Draft - ICMPv6 Loopback

[Rolf Winter <[e-mail]>]

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
> <[e-mail]> 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) <[e-mail]> 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" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>>>>
>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area