要約

  • 運用者はUniform、Pipe、Short Pipeを選び、新しくpushするラベルのTTLを設定する。RFC 3443はモデルを知らせるシグナリング機構を定義せず、コマンドラインまたは管理インターフェースによる運用設定に委ねている。
  • UniformはMPLSと運搬パケットのTTL状態を伝播し、トンネル内LSRを外部トラフィックから見える状態にする。Pipeはトンネルを外部から一つのホップに見せることを意図し、Short Pipeは出口で異なる処理を行う。
  • 通常の転送制約は残る。モデルが別途定めない限り出力TTLは入力TTLから1を引き、出力TTLの検査に失敗したパケットは転送しない。PipeやShort Pipeは暗号化、認証、アクセス制御、経路認可ではない。

核心はラベル境界での処理である。入口LSRはpush時に、ラベルの下にあるIP TTLをモデルに従って扱う。中継LSRはswap時にTTLの検査と減算を行い、出口LSRはpop時に運搬パケットを次の転送処理へ渡す。RFC 3032は複数ラベルを持つスタックの符号化を扱い、RFC 3443はそのpush、swap、popでホップ制限状態をどのように扱うかを整理する。「隠す」とは外部の観測から内部ホップが見えない可能性を意味するだけで、内部LSRがTTL制御を行わないという意味ではない。

Uniformではラベル境界を越えてホップ制限状態が伝播するため、外部のtracerouteがトンネル内の中継LSRを示し得る。Pipeでは新しいラベルに、下のヘッダーからコピーしたTTLではなく、運用者が設定したTTLを入れる。目的は、トンネル全体を外部から一ホップとして見せることである。RFC 3443は発行時点で多くの実装が255を使っていたと記しているが、255を普遍的な必須値にはしていない。Short Pipeも設定値をpushするが、出口では運搬パケットを通常の転送ホップを通ったものとして扱い、規定されたTTL減算を行う。PHPの有無にかかわらず、RFCは同等のエンドツーエンド減算結果を示している。

PHPは単なる最適化ではなく、正しさの境界である。ペヌルティメートホップが外側ラベルをpopすると、出口が受け取るスタックはPHPなしの場合と異なる。それでも出口は、実際に受け取ったパケットとラベルスタックに対応するTTL処理をしなければならない。階層ラベルスタックでは、各層のpush、swap、popが整合していなければならない。境界装置の設定が食い違うと、TTLを余計に、または不足して減算したり、誤った位置で検査したりし、説明しにくい廃棄やtraceroute結果を生む。RFCはベンダーの既定値、導入率、事故削減率、必須の監視しきい値を示していない。

検証用の試験では、既知のIP TTLを持つパケットを用意し、入口でのラベル追加後のTTL、各中継でのラベル交換後の減算と検査、出口でのラベル削除後のヘッダーTTLを記録する。PHPあり・なし、単一ラベル・階層スタックを分けて繰り返す。さらにUniform、Pipe、Short Pipeで経路追跡を行う。ただしトンネル内部のホップが表示されないことだけでは、モデル、実際の経路、すべての装置の一貫した実装を証明できない。RFC 3443の手順をRFC 3032のスタック符号化と照合し、RFC 3270は差別化サービスのラベル処理に関する運用文脈として扱う。TTLモデルが認可機構になるわけではない。

運用者の判断経路

  1. まず必要なのが可視性の選択であり、LSPの確立、経路の認可、peer認証、アクセス許可、転送ポリシー変更ではないことを確認する。
  2. 内部ホップを外部診断に見せたいならUniform、トンネルを一ホップに見せたいならPipe、出口で通常転送相当の処理を加えたいならShort Pipeを評価する。
  3. 初期ラベルTTLを明示的に設定し、255を普遍的要件として扱わない。
  4. ラベルの追加、交換、削除、PHP、階層スタックを試験で検証し、TTL検査失敗時の廃棄も確認する。
  5. tracerouteとTTL観測を証拠として保存し、一つの観測だけでモデルや経路を断定しない。

出典