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) <evyn...@cisco.com> 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-boun...@ietf.org <mailto:int-area-boun...@ietf.org> on behalf of > bob.hin...@gmail.com <mailto:bob.hin...@gmail.com>> 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 <tal.mizrahi....@gmail.com > > <mailto:tal.mizrahi....@gmail.com>> 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 > > Int-area@ietf.org <mailto:Int-area@ietf.org> > > https://www.ietf.org/mailman/listinfo/int-area > > <https://www.ietf.org/mailman/listinfo/int-area> > > > > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
