Re: New Draft - ICMPv6 Loopback

It would be nice if you consider IPv4/IPv6 traversal. What is IPv6 end 
going to expect when dealing with IPv4 on the other end. There is a 
draft https://datatracker.ietf.org/doc/draft-augustyn-intarea-ipref/ 
which makes such traversals possible and highly scalable.

On 6/20/23 21:53, Tal Mizrahi wrote:
> 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
> <[email protected]> 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) <[email protected]> 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" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
>>>>
>>>>
>>>>
>> _______________________________________________
>> Int-area mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area