要約

  • 報告側LSRは、到達不能なMPLSカプセル化データグラムについて、選択されたICMPv4またはICMPv6のマルチパートエラーにMPLS Label Stack Objectを付加できる。
  • この拡張はRFC 4884の拡張構造とオブジェクトヘッダーを使い、Time ExceededおよびDestination Unreachableに伴うことがある。元のIPヘッダーと先頭のペイロードオクテットは保持される。
  • ラベルスタックは診断証拠であり、修復コマンド、ルートまたはLSPの認可、認証、アクセス許可、暗号学的証明ではない。

仕組みの要点は、通常のICMPが露出したIPデータグラムを報告しても、転送判断に関係したMPLSラベルスタックを省く場合があるという診断上の空白を埋めることにある。報告LSRが対象となるエラーを生成すると、RFC 4950はそのルーターに到着した完全な受信ラベルスタックを追加する形式を定める。強化されたtracerouteは、応答したノードだけでなく、元のデータグラムが各ノードに到着した時点のMPLSカプセル化状態も報告できる。

ラベルスタックの各エントリーは正確に4オクテットである。RFC 4950の2007年テキストでそう命名された3つの実験用途ビット、20ビットのLabel、1ビットのBottom-of-Stackフラグ、8ビットのTTLが含まれる。実装者はこのビット配置を証拠の構造として解析すべきであり、ラベル値から転送変更の許可、所有権、意図、ポリシー遵守を推論してはならない。メッセージには元のIPヘッダーと先頭のペイロードオクテットもなお必要であるため、ラベル文脈だけを切り離して解釈する設計は適切ではない。

RFC 4950はMPLSとICMPの一般的な関係や、カプセル化固有のTTL操作を定義しない。RFC 3032の符号化情報から、全MPLS経路が同じTTLモデルで見えるとは言えない。基本的なtracerouteを無効にできるTTL手順は、強化版も無効にし得る。また、RFCにある「広く展開されている」という記述は2007年当時の歴史的記述であり、現在の普及範囲、ベンダー間の一貫性、現在の開示既定値を証明しない。

検証用の具体的なフィクスチャは、Time Exceededを発生させる管理されたテストパケット、Destination Unreachableを発生させる別のテストパケット、ICMP原文を保存するキャプチャ点、そしてRFC 4884の拡張ヘッダーとRFC 4950オブジェクトをバイト単位で検査するパーサーである。各応答について、ICMPv4かICMPv6か、元のIPヘッダーと先頭ペイロードの有無、オブジェクト長、4オクテット境界、Label、3つの実験用途ビット、Bottom-of-Stack、TTL、応答ノードを記録する。オブジェクトあり、なし、フィルタリング、TTLで不可視を別々に記録し、「MPLSなし」にまとめない。

運用者の判断手順は、まず選択されたエラー種別とRFC 4884構造を確認する。次に元のIP断片とオブジェクトの完全性を確認し、ラベルスタックを装置側記録や別のテレメトリーと照合する。その後、宛先アドレス、グローバル設定、受信スタック深度などのポリシーに従い、完全なスタックを開示するか、制限するか、開示しないかを決める。最後に、独立した証拠がある場合だけ、通常の認可されたルート、LSP、転送変更手順へ進む。ICMPオブジェクト自体はLSPを作成せず、ルートを検証せず、送信者を認証せず、アクセスを与えず、他のルーターへ命令しない。

ラベルスタックオブジェクトがないことは、パケットがMPLSでカプセル化されなかった証明ではない。実装サポート、開示ポリシー、フィルタリング、互換性、TTLの挙動が観測を抑制し得る。報告されたスタックだけでエンドツーエンド経路、根本原因、全ホップの同等な応答を証明することもできない。拡張がなければ、通常のICMPとtracerouteはエラーと通過ノードを示せる一方、受信MPLSスタックは省略され、運用者は内部テレメトリーと装置記録により依存する。

出典