要約

  • IESGは2026年8月17日、draft-ietf-mpls-mna-ps-hdr-19をProposed Standardとして出版することを承認した。Pビット、オフセット、基本ヘッダー、長さ検査によりPost-Stack MPLS Headerを発見できるが、承認は実装・導入・処理成功の証明ではない。
  • 草案は、Readable Label Depthが完全なスタック後ヘッダーに届かない中継ノードについて、処理を単に飛ばすと定める。正しい符号化と到着確認だけでは、経路上の実行を立証できない。

正常な到着が隠すもの

冒頭は実在の障害報告ではなく、仕様を運用へ移す際の想定例である。パケットは壊れていない。Pビットも、開始位置も、長さも整合し、出口まで届く。それでも一台の中継ノードだけがスタック後処理を実行しないことがある。

この場合、草案が要求するのは一律の破棄ではなく、PSMH処理のスキップである。したがって「パケットが落ちなかった」と「各ノードが処理した」は同じではない。出口の構文検査は途中の実行履歴を復元しない。

監査では、処理がパケットに符号化されたこと、作用範囲から見てあるノードが対象だったこと、そのノードが実際に処理したことを分ける必要がある。順に、形式、経路判断、ノード証拠の問題である。

承認されたのは容器を見つける方法である

8月17日のProtocol Actionは、第19版のMPLS Network Action Post-Stack Header草案をProposed Standardとして進めた。RFC Editorが発行するまではInternet-Draftであり、割当値の一部はTBAのままだ。これは標準化上の到達点であって、特定製品や本番網の対応表ではない。

MNA Sub-StackはMPLSラベルスタック内に残る。Format BのPビットが、Bottom of Stackの後ろに対応するPost-Stack MPLS Headerがあることを示す。基本ヘッダーには先頭ニブル、長さ、種別が入り、後ろに一つ以上の処理と補助データが続く。

PSMHがBoS直後にあるとは限らない。Pseudowire Control WordやGeneric Associated Channelなどが先行し得る。開始オフセットはBoSから四オクテット単位で位置を示す。最初のNASで省略された場合はゼロが既定だが、後続のPビット付きNASには位置情報が要る。任意の終了オフセットがあれば、PSMHを読み始める前に全体の深さを算出できる。

基本ヘッダー後の長さは一から255ワードで、各処理の長さの合計と一致しなければならない。先頭ニブル、オフセット、開始・終了の整合、長さ計算に誤りがあればmalformedとなり、未知処理の方針にかかわらず破棄される。

ここで仕様が強くしたのは発見可能性である。場所が分かることと、その場所まで各装置が読めることは別だ。

RLDは経路選択の入力になる

草案はこの用途のReadable Label Depthを、ラベル項目数から、ラベルスタック先頭を起点とする四オクテットワード数へ改める。BoSを越えた領域まで、読み取り可能範囲として表現するためだ。

経路を選ぶノードは、対象となる中継・出口ノードのスタック後MNA能力、path MTU、そして作用範囲に入る各ノードのRLDを知る必要がある。出口が未対応ならPSMHを追加してはならない。関連NASを除去する中継ノードがPビットに対応しない場合も同様で、MTU内に収める義務もある。

ただし、それらの情報をどう取得するかは本草案の範囲外だ。設定、管理プロトコル、制御プロトコルが候補として挙げられるにとどまる。パケット形式が整っても、能力情報の鮮度や所有者までは整わない。

運用側は、RLDが測定・設定・推定のどれか、いつ取得したか、どのハードウェアとソフトウェアに対応するかを残さなければならない。ラインカード交換、機能のロールバック、ラベルスタックの増加で古くなった値を使えば、形式上は正しいのに一部だけ処理されない経路が生まれる。

「読めない」は一種類ではない

malformed、unknown、RLD不足を一つの「非対応」にまとめると、必要な対処を誤る。

構造検査に失敗したPSMHはmalformedで、破棄が必須である。Pビット対応ノードが特定の処理を知らない場合はunknown-action方針に従う。Pビット自体を知らないノードはPSMHを解析しないため、NASから導く方針で見えていない内容を扱うこともできない。

完全なPSMHまでRLDが届かない場合は、処理をスキップする。深度または開始オフセット未対応のため関連PSMHを除去できないなら、Pビットを持つNASも除去してはならない。表示と容器を一体のまま後続ノードへ渡すためである。

最後から二番目のノードは、露出したhop-by-hopまたはingress-to-egressのNASとPSMHを出口向けに保持する。出口はNASを除去する際に対応するPSMHを除去する。これは状態を切り離さない規則であって、途中の実行証明ではない。

作用範囲は予定表であり受領証ではない

MNAにはhop-by-hop、ingress-to-egress、selected-nodeの作用範囲がある。どこで処理されるべきかは示すが、処理済みの印ではない。

hop-by-hopなら、実際の転送経路、各ノードのPビット対応、個別処理対応、RLD、ローカル方針、呼び出し結果を結び付ける必要がある。selected-nodeでは、選定が現行のトポロジーと能力に基づくことも要る。ingress-to-egressでも、容器を出口まで保持した事実は出口処理の成功とは異なる。

草案は、受信PSMH、RLD超過、未知処理の破棄・スキップ、malformed破棄、処理別の成功・失敗などのカウンターを推奨する。経路、処理ID、パケット種別、ソフトウェア状態、時刻と関連付けて初めて証拠になる。

管理境界は内部より深く読めなければならない

スタック後処理の意味は拡張可能で、ローカル定義の処理は他の管理域では危険になり得る。草案のセキュリティ節は、別の管理域から入るPost-Stack MNAパケットを導入前に境界でフィルターできることを求める。しかも境界ノードのRLDは、域内の全ノードより大きくなければならない。

これは単なる性能目標ではない。外部の危険な処理を拒む責任者は、内部ノードが見得る範囲をすべて見なければならない。内部より浅い境界装置は、自分が読めた先頭部分しか保証できない。

中間ノードがスタック後データを変更する可能性もあるため、重要機能は別のネットワーク全体検証なしに依存すべきではない。機微な補助データは暗号化するか、この仕組みで送らない。性能と規模、BIER転送ルーターでの処理は本草案の対象外である。

正確に言えるのは、承認された形式が容器の表示、位置、整合検査、ライフサイクルを定めたことまでだ。現実の経路で安全かつ一貫して実行できるかは、能力管理、観測、責任分担の課題として残る。

出典