Re: [IPv6] New Draft - ICMPv6 Loopback

Poking around the Linux kernel source, my reading of net/ipv6/icmp.c's
icmpv6_rcv() is that it checks the type byte before dispatching to
icmpv6_echo_reply(), and inside icmpv6_echo_reply() I'm not seeing any
checking of the code byte, so I'd assume (without testing) that it
just constructs a normal echo reply.  I also suspect that it just
copies the incoming code value into the reply.

The only differentiation I see being made is between echo request
(4443) and extended echo request (8335).

Should be easy enough to test (after I get a few other things done).

On Tue, Jun 6, 2023 at 9:30 PM Tal Mizrahi <[email protected]> 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>
> >
> >
> >
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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