要約

  • ICMPの通常のIP引用には、MPLSで転送判断に使われたラベルスタックが残らない場合がある。RFC 4950はその到着時の状態を別の情報として添える。
  • 追加されたのは報告内容であって、すべての中継点に応答させる能力ではない。TTLの扱いと開示方針は依然として観測を左右する。
  • ラベルの数値は局所的な意味を持つ。共通の拡張形式、完全な経路、応答元の認証は、それぞれ異なる問題である。

画面に出なかった情報は、どこで消えたのか

ある診断結果にはMPLSラベルが表示され、別の結果には表示されない。見た目だけを比較すると、ネットワークの構成が変わったように感じられる。

だが、少なくとも二つの問いを分けなければならない。ICMPの応答自体が届かなかったのか。それとも応答は届いたが、利用できるラベル情報がなかったのか。後者には、送信側が添えなかった場合だけでなく、受信側が読み取れなかった場合も含まれる。

2007年8月のRFC 4950は、MPLSの情報をICMPに追加する仕組みを定義した。同時に、その情報を選択的に開示する運用も述べている。たとえば、管理用のアドレスに返すエラーにはラベルを添え、外部へのエラーには添えない選択があり得る。

したがって、ラベルの行がないという観測から、そのままMPLSの不在へ進むことはできない。表示の欠落は、いくつもの段階をまとめた結果である。この拡張の歴史は、まずその段階を分けて読む必要を教えてくれる。

エラー処理に渡す前に外したもの

拡張が埋めた穴は、IPデータグラムの外側にあった。

配達できないMPLSカプセル化データグラムを受け取ったラベル交換ルーターは、ラベルスタック全体を外し、内側のIPデータグラムを露出させる。それをエラー処理に渡すと、生成されるICMPにはIPヘッダーと元のデータの先頭部分が引用される。

その引用は正確でもよい。しかし、外したラベルスタックは含まれない。ルーターが転送の判断に用いたはずの情報が、エラーの記録から抜け落ちるのである。

RFC 4950は、選ばれた種類のエラーに、報告元ルーターへ到着した時点のスタックを添えることを推奨した。元のIPヘッダーと先頭のペイロードは引き続き含めなければならない。追加情報で従来の引用を置き換える設計ではない。

これは重要な区別だ。IPの引用は、どの通信に対するエラーかを結び付ける。到着時のスタックは、その通信がある地点にどの転送文脈を伴って入ってきたかを示す。同じ報告に入っていても、担う役割は違う。

最初の引用が答えようとした問い

1981年9月のRFC 792を見ると、Time ExceededにはIPヘッダーと元のデータ部分の先頭64ビットが含まれていた。八オクテットのデータは、受信ホストがエラーを適切なプロセスへ対応付ける助けになる。上位プロトコルがポート番号を用いる場合、それがこの先頭部分にあることを想定していた。

これは経路全体の判断記録ではない。通信との対応をつけるための引用である。また、この古い形式から、後年のICMPが常に八オクテットしか引用しないという結論を出してはいけない。

MPLSでは、引用をIPデータの後方へ長くするだけでは問題を解けない。ラベルスタックはIPヘッダーより前にあったからだ。すでに取り外した外側の状態は、内側の引用を伸ばしても自然には戻らない。

2001年1月のRFC 3032は、スタックをリンク層ヘッダーとネットワーク層ヘッダーの間に置く。各エントリーは四オクテットで、先頭がスタックの一番上に当たる。最後のエントリーはSビットで示される。

一番上のラベルを調べることで、次の転送先やスタックの操作が決まる。先頭を別のラベルへ替える、取り除く、あるいは追加のエントリーを積むといった処理である。IPの内容が同じでも、引用の外に転送上の重要な状態があり得る。

数字の意味は、数字だけでは決まらない

RFC 3031が定義するラベルは、転送等価クラスを識別する、局所的な意味を持つ値である。IPの宛先アドレスを短く書き直したものではない。

異なるルーターの表示に同じ数字があっても、それだけで同じ接続や同じ恒久的な区間を表すとは言えない。どのラベル空間で、どの装置が、どの時点に使っていた値なのかが必要になる。

RFC 4950が共通にしたのは、その局所的な状態を報告する形式だ。オブジェクトのクラス番号1とC-Type 1は、入ってきたMPLSスタックとして内容を読むための約束である。個々のラベル値を世界共通の台帳から割り当てる仕組みではない。

共通形式には大きな価値がある。別の実装でも同じ構造を読めるからだ。ただし、読み方が共通になったことと、そこで読まれる数字の意味が世界中で一つになることは別である。

記録するのは出口ではなく入口

このオブジェクトは、ICMPv4とICMPv6のTime ExceededおよびDestination Unreachableに添えられる。あらゆるICMPメッセージに適用するという話ではない。

一つのオブジェクトで、到着時のスタック全体を、その順番のまま表す。オブジェクトの長さは四オクテットのヘッダーに、各エントリーの四オクテットを足したものだ。三エントリーなら十六オクテットになる。これは構造の計算例であり、実測したパケットではない。さらに前にある拡張全体のヘッダーは、この長さに含まれない。

各エントリーは二十ビットのラベル、三ビットの当時EXPと呼ばれた領域、一ビットのS、八ビットのTTLを持つ。2009年2月のRFC 5462は、EXPをTraffic Class、すなわちTCと呼び替え、その用途を明確にした。エントリーが大きくなったわけではない。

古い診断例のEXPという表記は、その時代の記述として読む必要がある。同時に、それを現在も自由な実験用ビットであるという根拠にはできない。

そして、入口の記録を出口の説明に変えてはいけない。このスタックは、処理が成功していればどのラベルで送信したかを直接示さない。後から調べた設定とも違う。報告は一つの到着状態を保存するのであって、装置の過去と未来をまとめて証明するものではない。

128オクテットの先にあった互換性

MPLSのオブジェクトは、2007年4月のRFC 4884が定めた複数部分から成るICMPに載る。元のデータグラムの引用に続いて、拡張ヘッダーが一つ置かれ、その後に一つ以上のオブジェクトが並ぶ。

引用と拡張の境界を示すため、従来予約されていた領域から八ビットの長さ属性を確保した。IPv4では四オクテット単位、IPv6では八オクテット単位で引用領域の長さを数える。拡張がある場合、引用領域は少なくとも128オクテットとし、元のデータが短ければゼロを詰める。

ただし、規格を読む前から動いているソフトウェアがあった。RFC 4884は、1999年から公表時点までの一部の実装が、長さを明記せず、ちょうど128オクテットの引用の後に拡張を置いていたと記す。

それを読む古いプログラムは、長さ属性ではなく固定位置に頼る。新しい送信側が引用をもっと長くすると、正しい長さを読む受信側には分かっても、固定位置を探す受信側には分からなくなる。新形式では最低値だった128が、旧実装との互換性のためには固定値になる。

従来のICMPしか知らないアプリケーションは、拡張を元の引用の続きと解釈する場合もある。RFCはその影響を検討しており、どんな旧プログラムにも影響がないと保証しているわけではない。

ゼロの扱いを勝手に変えない

仕様に準拠した受信プログラムは、長さ属性がゼロなら拡張なしと判断する。ところが、そうすると長さを入れずに拡張していた旧式の応答は見落とされる。

RFC 4884は、そのためにtracerouteへ非既定の互換モードを求めた。十分な長さの報文で属性がない場合、古い固定位置に拡張ヘッダーを探し、バージョンとチェックサムを確認するモードである。

既定動作と例外動作を分けたことには意味がある。表示されたラベルが、明示された境界をたどって読まれたのか、歴史的な配置を前提に読まれたのかを区別できる。互換性は無条件に得られるものではなく、条件を選んで得るものだった。

拡張ヘッダーはバージョン2を用いる。知らないオブジェクトがあるだけでメッセージ全体が不正になるわけではないが、長さや構文の確認は欠かせない。チェックサムも送信者の暗号学的な認証ではない。正しく読めることと、誰が本当に送ったかを立証することは別の作業である。

報告を運ぶラベルとの混同

RFC 3032には、エラー報告の帰り道に関する別の話もある。MPLSドメイン内部の装置が元の送信元への経路を知らない場合、生成したICMPをラベルで包み、いったん元の宛先方向へ運ぶ方法が記されている。送信元へ戻す経路を知るルーターに達してから、適切な方向へ進める。

その場合の外側のラベルは、実際にエラー報告を転送するために働く。値をコピーしても、TTLは新しい報告の旅に合わせて設定される。これはRFC 4950が報告の内側に保存する到着時の証拠とは違う。

両者を混同すると、引用された状態だけでなく往復時間も読み違えかねない。エラー報告が回り道をすれば、観測した往復時間にはその帰路も含まれる。ラベルの行を一つ増やしただけでは、時間を特定の前向き区間へ割り当てられない。

応答が生まれる条件は変わらない

2003年1月のRFC 3443は、MPLSのTTLモデルを整理した。Uniformモデルでは入口と出口で内外のTTLを同期させる。一方、Pipeなどのモデルでは外側の初期TTLが内側の値と無関係であり得る。

内側のIP TTLを変えたプローブを送っても、こうした処理のもとでは、経路内の各段階に期待どおりの超過エラーが発生するとは限らない。RFC 4950自身も、通常のtracerouteを妨げるTTL処理は拡張版にも同じ制約を与えると述べる。

これは外側のTTLが無限になるという意味ではない。PipeがすべてのICMPを禁止するという意味でもない。既に得られた応答へ情報を足す機能と、応答が発生する条件は独立しているということだ。

さらに、開示先アドレス、装置全体の設定、入ってきたスタックの深さなどによって、拡張を付けるかどうかが選ばれ得る。見えなかった一行は、こうした条件のどこかで説明されるかもしれない。

RFC 4950は公表時点で広く導入済みだと述べた。その記述を2007年の歴史的証言として扱うことはできる。しかし、現在の導入率や、すべてのネットワークが一斉に対応した日を示すものではない。

到着時のラベルを保存できるようになったことで、診断は確かに豊かになった。ただし、豊かな記録が必要とするのは、その限界を消すことではなく、読み手が限界まで一緒に保存することだった。