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, RolfJuniper Business Use Only
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
