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 Am 04.09.24 um 21:25 schrieb Ron Bonica:
Rolf,In Section 3, you say that the that the Traceroute Request has the following type values:* ICMPv4: Value 8 * ICMPv6: Value 128This means that the Traceroute Request *is* the ICMP Echo message, as defined in RFC 792.Likewise, you say that the that the Traceroute Response message has the following type values:* ICMPv4: Value 0 * ICMPv6: Value 129This means that the Traceroute Response *is* the ICMP Echo reply message, as defined in RFC 792.Sadly, neither of these messages are extensible. See Section 4 of RFC 4884 for details.You can avoid this problem by using the ICMP Extended Echo Request and Extended Echo Reply instead. See Sections 2 and 3 of RC 8335 for details.RonMessage: 1 Date: Wed, 28 Aug 2024 17:18:49 +0200 From: Rolf Winter <rolf.win...@hs-augsburg.de> Subject: [Int-area] v03 Stateless Reverse Traceroute To: "int-area@ietf.org" <int-area@ietf.org> Message-ID: <3a987ea2-b8fe-41a4-a474-36c1abd7b...@hs-augsburg.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040302020701060508000004" Dear Int-Area WG, we just updated the Stateless Reverse Traceroute document. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless-03__;!!NEt6yMaO-gk!HUAZjKrkcbREVu-ldPQN9adFNpehbEzzDNoQSQBdDW5cjAFM3ej7PtQjgmX7vtDWp6bzXNhxdPDJZ-cXygxHnz4Por0$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless-03__;!!NEt6yMaO-gk!HUAZjKrkcbREVu-ldPQN9adFNpehbEzzDNoQSQBdDW5cjAFM3ej7PtQjgmX7vtDWp6bzXNhxdPDJZ-cXygxHnz4Por0$> Juniper Business Use Only _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
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