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

[Tal Mizrahi <[e-mail]>]

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