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 128


This 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 129


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

  Ron


Message: 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

Attachment: 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

Reply via email to