Re: [IPv6] New Draft - ICMPv6 Loopback

For FreeBSD it looks like code MUST be 0 or the packet is dropped:

(file netinet6/icmp6.c line 550: http://fxr.watson.org/fxr/source/netinet6/icmp6.c#L550)


       case ICMP6_ECHO_REQUEST:
                 icmp6_ifstat_inc(ifp, ifs6_in_echo);
                  if (code != 0)
                           goto badcode;


Ciao

L.
> -----Original Message-----
> From: Int-area <[email protected]> On Behalf Of Justin Iurman
> Sent: Wednesday, 7 June 2023 13:24
> To: Erik Kline <[email protected]>; Tal Mizrahi <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [Int-area] [IPv6] New Draft - ICMPv6 Loopback
> 
> On 6/7/23 08:06, Erik Kline wrote:
> > 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).
> 
> +1 ... tested and confirmed (pcap attached, code 0 for packets 1-2, code
> 1 for packets 3-4).
> 
> Cheers,
> Justin
> 
> > 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" <int-area-
> [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
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > 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