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

Valentin, > On Jun 20, 2023, at 10:45 AM, Valentin Heinrich > 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? > > W

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

Hi Tal, don't get me wrong. Of course a new type is technically an equally valid solution and I do not want to talk you into using new codes under an existing type instead. I just wanted to point out that I believe generally speaking working with new codes is equally valid and feasible, which

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

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

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

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 distinguis

Re: [Int-area] 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 Mizrah

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

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

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

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 o

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

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 existin

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

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" mailto:int-area-boun...@ietf.org> on behalf of bob.hin...@gmail.com > wrote: Tal, I did a quick r

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

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 si