いくつかの一般的なtraceroute実装がデフォルトでUDPプローブを使用するのはなぜですか？

特定の宛先が到達可能であることを知っているという点で、最近、ネットワーク接続のメタ問題をトラブルシューティングしていましたがtraceroute、特定のホップ数の後、パスが冷たくなったため、それを実証できませんでした。最後に観測されたホップが目的のノードのすぐ上流にあることを考えると、プローブが到達していることを確認し、どのフィルタールールがそれらをブロックしているかを確認することを期待して、トラフィックをスニッフィングしました。案の定、私は、プローブが、もちろん、着信トラフィックをブロックしていた、高い（そして変化する）ポート向けのUDPデータグラムであることを学びました。

traceroute応答はICMPであるため、すべてのプローブがICMPにデフォルト設定されると想定したため、これは驚きです。私はドキュメンテーション調査を行ったところ、さまざまな実装がさまざまな選択を行い、一部のユーザーはデフォルト以外の選択を許可していませんでした。

• UDP
  • シスコ
  • Linux
  • FreeBSD
• ICMP
  • ジュニパー
  • ブロケード
  • ウィンドウズ

Tracerouteプローブ方式とフォワードIPパス推論の要約は、ICMPプローブが宛先に到達することに成功することが多いという私の直感をサポートしています。

さまざまなプローブ方法を許可するのは素晴らしいアイデアのように思えますが、ICMP以外のデフォルトに設定することは悪いアイデアのようです。誰かがデフォルトでUDPを使用する方が良い理由の背後にある根拠を説明できますか？

の最初のバージョンはtracerouteVan Jacobsonによって書かれ、ICMPを使用しましたが、うまく機能しませんでした。RFC792のICMPのベンダーの解釈では、ルーターはICMPパケットに応答してICMPエラーメッセージを送信すべきではないというものでした（以下の編集ノートを参照）。そのため、ほとんどのルーターは、TTLが1または0のエコー要求への応答で「時間超過」メッセージを送信しませんでした。tracerouteLinuxおよびFreeBSD（および私はシスコと思われます）のツールはVan Jacobsonの研究に基づいています。

仕様は後に「ICMP エラーパケットに応じて」に変更されました。世界が進歩し、ベンダーはスタックに変更を加えて、エコー要求への応答としてICMPエラーメッセージを許可し、ファイアウォールとACLの登場により、UDPパケットがブロックされることがありましたが、ICMPエコー要求は通過できました。もちろん、今日のあなたの成功は大きく異なります。tracertICMPエコー応答の使用がそれほど問題にならなかったときに、他のツールが書かれたと思います。

最近では、UDPがICMPより優れているとは本当に言えません。または、これらのいずれかがTCPよりも優れていること。それは、あなたがたどる経路と適切なセキュリティポリシーに完全に依存します。1つ、両方、または3つすべての実装を試す必要があるかもしれません。

ソース：

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

編集：

イントロで述べているRFCをIP（RFC791）からICMP（RFC792）に変更しました。

メッセージなどに関するメッセージの無限回帰を回避するために、ICMPメッセージに関するICMPメッセージは送信されません。

これが、ベンダーがエコー要求に対して「時間超過」エラーを送信しなかった原因です。

RFC1122、インターネットホストの要件、セクション3.2.2。ホストがICMP エラーメッセージに応答してはならないと言う更新です。