Rolf,
It might be interesting to see how many middleboxes block the extended echo
request.
Given that it has been around for six years and implemented in LINUX for three
years, you would think that many middleboxes have caught up. Do we have any
data?
Ron
Juniper Business Use Only
________________________________
From: Rolf Winter
Sent: Wednesday, October 2, 2024 3:15 PM
To: Ron Bonica; int-area@ietf.org
Subject: Re: [Int-area] Re: v03 Stateless Reverse Traceroute
Hey Ron,
please see inline:
Am 02.10.24 um 17:06 schrieb Ron Bonica:
> Rolf,
>
> Please keep in mind that we are not talking about a new ICMPv6 message.
> This message was defined in RFC 8335. RFC 8335 was published in 2018.
> There are multiple implementations
> <https://lkml.org/lkml/2021/4/28/1162>. It will also be used in
> Loopback6
> <https://www.ietf.org/archive/id/draft-he-6man-icmpv6-extensions-ipv6-ext-header-03.txt>.
>
> Moreover, I am not swayed by the argument that the IETF can never add a
> new ICMPv6 message. While there are some middleboxes that cannot cope
> with a new message, we cannot yield extensibility to middlebox ossification.
Sure we can add new ICMP messages. There is nothing wrong with it in
principle. But the IETF also can add new transport protocols such as
DCCP but still designed QUIC to run over UDP, which middleboxes
understand, thus making QUIC instantly deployable. Of course there are
also other reasons one might have such as control inside the app itself
and not having to wait for OS vendors to support it. And of course I am
not trying to compare HTTP/3 to reverse traceroute, but nevertheless, I
think it should be carefully considered. And as I said I am not
generally opposed to using Extended Echo, just that I personally would
prefer Echo. Maybe others would like to chime in.
>
> If you were to do Option 2 correctly, you would have to update RFCs 792
> and 4443 stating that the data field sometimes has special meaning. You
> might even want to create an IANA registry so that the next person who
> wants to assign special meaning to the data field won't conflict with
> your special meaning.
But do we really? We do use a different code, so actually we are not
changing the sematincs of the Type 8 Code 0 and Type 0 Code 0. So
everything in those two RFCs stay as they are.
Best,
Rolf
>
>
> Ron
>
> -------------------------------------------------------------------------
>
> Hi Ron, really sorry for the belated reply. You are absolutely right.
> Using Extended Echo is certainly one way of going forward. We did choose
> the "regular" Echo for a reason though, which Valentin presented in
> Prague (https://youtu.be/w7K_BT1UB1Q?feature=shared&t=2992
> <https://youtu.be/w7K_BT1UB1Q?feature=shared&t=2992>) and that is, it
> will probably go through most NAT implementations today. Therefore, I
> would like to present three alternatives to you and the WG: 1. As you
> suggest, use Extended Echo. This has the benefit of being able to use
> the extention mechanism as defined in RFC 4884 2. Keep using "regular"
> Echo. Here we could just not use the RFC 4884 mechanism but simply
> structure the payload some way either a) fixed or b) some type of TLV
> mechanism. The benefit here would be an improved deployability of
> reverse traceroute. And as RFC 4884 also says: "Many ICMP messages are
> extensible as currently defined. Protocol designers can extend ICMP
> messages by simply appending fields or data structures to them." That
> text is what point 2 above is describing. So I would encourage
> discussion on this, but my personal preference at this point would be 2.
> Best, Rolf
>
>
>
>
>
> Juniper Business Use Only
>
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
