要約

  • traceroute は送信元が IP の TTL を変え、プローブを一つ先のホップで順番に失効させ、ICMP Time Exceeded の送信元を並べて転送経路の一断面を作る。
  • ルーター側には既存の動作を利用できたが、最初の4BSD版では送信元OSがTTL設定を許す必要があり、Jacobsonはカーネル修正が必要な場合を明記した。
  • 結果は一地点・一時刻・一方式の観測である。応答なしは装置なしを意味せず、応答アドレスは所有権を示さず、復路も直接は分からない。

地図ではなく、行方不明の調査から

1988年12月20日、Van Jacobson は IETF と end-to-end-interest のメーリングリストに4BSD用の診断プログラムを知らせた。問題は大げさではない。パケットがどこへ行っているのか分からず、一週間悩んだという。

仕組みは簡潔だった。TTLを一にしたUDPパケットを送り、ICMP Time Exceeded を待つ。返事があれば、その送信元アドレスを表示し、TTLを一つ増やす。Jacobsonは発想を自分だけのものにせず、end-to-endの会合で Steve Deering が口にした案を聞いたと記した。ソースはFTPで公開した。

同時に、実装上の摩擦も隠さなかった。ユーザープログラムがTTLを指定できるよう、生のIP出力を直す必要があるかもしれない。つまり、途中のルーターが必要な反応を持っていても、端点のOSがプロトコルのつまみを渡さなければ、観測は始まらない。

TTLは本来、ループを止める装置だった

RFC 791 における Time to Live は経路表示機能ではない。送信者がデータグラムの生存上限を設定し、IPヘッダーを処理する各地点が値を減らす。実時間が分からなくても最低一は減らし、宛先に届く前にゼロなら破棄する。

目的は、誤ったルーティングでパケットが永久に循環する事態を抑えることだった。RFC 1812 は後に、このホップ数としての働きが、ループするパケットによるネットワーク崩壊を防ぐうえで重要だと説明した。

traceroute は安全装置を目盛りとして読んだ。TTL一なら最初の転送点、二なら次の転送点で失効する。測っているのは地理的距離でも物理リンク数でもない。そのプローブが何回のTTL減算に耐えたかである。

ここには最小仕様の強さがある。共通層は寿命を確実に制限する。後の用途を中央で列挙しなくても、端点はその意味を壊さずに新しい質問を組み立てられる。

消えたことを知らせるICMP

破棄だけでは経路は沈黙したままだ。RFC 792 の ICMP は、通信環境で起きた問題を送信元へ知らせるためにある。ゲートウェイがTTLゼロを見つければデータグラムを捨て、Time Exceeded で通知できる。

古典的 traceroute はその応答元アドレスを一つの観測点として扱う。終点を判別するため、サービスのない高位UDPポートへ送る。途中ではTTL失効、宛先では Port Unreachable が返る。エラーの種類が変わることで終了を知る。

RFC 1739 が示す一般的な表示では、各TTLで複数回試し、応答の往復時間を並べる。しかし、その値は直前リンクの片道遅延ではない。プローブの往路、ルーター処理、別経路かもしれないICMPの復路が合わさる。

さらに RFC 792 は、制御メッセージの返送自体を保証していない。星印は「この条件で返事を得なかった」という意味に限られる。フィルタ、レート制限、輻輳、損失、応答方針のどれかを単独で証明しない。

全ルーターの同時更新を待たない

1993年の RFC 1393 は、専用のIPオプションとICMPメッセージを使う新方式を提案した。パケット数を減らし、復路情報も扱える構想だった。一方で、各ルーターに新しい traceroute 機能が必要になる。

既存方式の利点は、TTL超過を知らせる能力がすでにルーターにあったことだ。送信側でプログラムを動かせば、全事業者や全機種の更新を一日に合わせなくても、最初の観測が得られた。

専用方式が無価値だったわけではない。近いホップへの反復負荷、測定中の経路変化、復路の不可視性は本物の欠点である。歴史が示すのは、既存の小さな動作を端点で合成すると、協調更新への依存を減らせるという限定的な事実だ。

運用者だけの画面ではなくなった

RFC 1470 は traceroute を監視・デバッグ道具の一覧に載せ、RFC 1739 は管理者だけでなく利用者もインターネット構造の一部を学べると述べた。内部ルーティング表を持たない端点でも、障害前後の差や予想外の中継点を記録できるようになった。

これは観測可能性の分散であって、運用権限の移転ではない。経路を選ぶのは各ネットワークであり、ICMPを返すか、どのアドレスを使うかも現場の設定に左右される。逆引き名は古いかもしれず、トンネルは内部を隠し、複数アドレスが一台を指すこともある。

したがって、一行のアドレスは応答の証拠ではあっても、機器所有者の登記ではない。回線契約者、経路方針の決定者、修復責任を一行から決めることもできない。

一本の線に見える複数の実験

通常の出力は連続した道に見えるが、実体は異なるパケットの集合だ。測定中に経路が変われば、別時点の断片が一列に並ぶ。RFC 1393 はこの点と、往路と復路が異なり得る点を早くから記録していた。

ロードバランシングはさらに錯覚を生む。ルーターがヘッダー情報でフローを識別し、等コスト経路へ振り分けるとき、フィールドを変える古典的プローブは別々の経路へ送られ得る。表示上のループ、サイクル、ひし形が、実際に一個のパケットが通った形とは限らない。

2006年の Paris traceroute 研究は、フローハッシュに関わるフィールドを制御し、多くの測定上の人工物を取り除いた。Reverse traceroute の研究は、見えない復路を往路と同じだと仮定せず、別の測定問題として扱った。

改良の積み重ねは、最初の道具を否定しない。観測条件を厳密にするほど、言える範囲が明確になる。正確な表現は「これが経路だ」ではなく、「この地点から、この時刻、このプローブ群がこの応答列を得た」である。

証拠を権威へ膨らませない

稼働するネットワークの測定は、事業者の説明や古い地図を反証できる。しかし、反証能力は統治権ではない。障害原因を帰属させるには、BGP情報、運用テレメトリー、設定変更、インターフェース統合、別地点の測定と照合する必要がある。

traceroute が残したのは世界唯一の地図ではない。誰でも端点から繰り返せる、小さく境界のある問いである。空白も誤差も画面に残り、より良い実装が結果を修正できる。

期限切れパケットの地図が長く役立った理由は、永久の真実を名乗らなかったからだ。インターネットは中央の地図作成者を得たのではなく、転送中の現実へ局所的な質問を投げる方法を得た。

情報源と限界

TTLは RFC 791、ICMPと応答非保証は RFC 792 に基づく。初期方式、Deeringへの言及、カーネル制約は 1988年の告知記録 による。

当時の道具としての位置づけは RFC 1470 と RFC 1739、代替案と限界は RFC 1393、後年のルーター要件は RFC 1812 にある。ロードバランシングの人工物は Paris traceroute論文、復路問題は Reverse traceroute を参照した。