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.
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.
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) 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
