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

[Valentin Heinrich <[e-mail]>]

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>
>>
>>
>>
>>