要約

  • RFC 9790は、MPLSラベルスタック直後の4ビットだけでペイロード種別を判定する手法を非推奨にした。0x4と0x6はIPv4/IPv6に一致し得るが、非IPフレームやPost-Stack Headerの一部でもあり得る。
  • 解釈を与えるのは直前のラベルに結び付いた制御・管理プレーンの文脈である。負荷分散には、推測した形式のフィールドより、Entropy LabelやFAT Pseudowire Labelという明示的な材料が適している。
  • レジストリ登録も明示ラベルも意味の範囲を狭めるだけで、実装、選択経路、利用率、順序性、顧客成果までを一度に証明するものではない。

ある中継ルーターがラベルスタックの底を見つけ、その次の4ビット0100をIPv4のバージョン番号と見なす。IPv4ヘッダーにあるはずの位置からアドレスとポートを読み、ECMPの入力にする。

しかし、実体は擬似回線上のEthernetフレームだった。0100は宛先MACアドレスの冒頭にすぎない。機器はIPを検出したのではなく、似た形に意味を投影した。その推測が実際の経路を変える。

RFC 9790が扱うのは小さな値域だが、問いは普遍的である。見えるもの、解釈する根拠、起きた結果を同じ事実として扱ってよいのか。

ニブルが示すのは観測値まで

MPLSパケットでは、Layer 2ヘッダーの後に4オクテット単位のLabel Stack Entryが並ぶ。Bottom-of-Stackビットは最終エントリーを示す。その後ろには裸のIPv4/IPv6、非IPのLayer 2フレーム、あるいは埋め込みパケットに先行するPost-Stack Headerが置かれる。

PFN（Post-stack First Nibble）は、スタック直後の最初のオクテットの上位4ビットである。裸のIPv4なら値4、IPv6なら6と重なる。別の構造が始まるなら、その構造の4ビットにすぎない。

ラベルスタック自身には汎用のペイロード種別識別子がない。RFC 9790は、先行するLSEまたはLSE群に対して制御プレーンか管理プレーンが設定した文脈がなければ、PFNを正しく読めないとする。キャプチャは0x4の存在を証明できる。IPであることまでは証言しない。

便利なヒューリスティックが経路選択権を持った

旧方式には合理的な動機があった。IPの5タプルはフローを複数リンクへ分ける材料として優れている。PFNが4ならIPv4、6ならIPv6として所定のオフセットを読み、それ以外はラベルスタックだけでハッシュする。

裸のIPには機能する。しかしEthernetの宛先MACアドレスも4または6で始まり得る。RFC 8469は、正式に割り当てられたアドレスに加え、プライバシー目的のMACランダム化がこの衝突を現実的にすると説明する。PW Control Wordがなければ、中継機器はEthernetのデータをIPヘッダーとして読む可能性がある。

誤りは分類名にとどまらない。本来無関係なバイトをハッシュへ入れ、同じ順序付きフローを複数経路へ散らし、並べ替えを起こし得る。単一路でも、IPだという誤認から異なる転送処理を適用できる。4ビットの推測が、どのバイトを信じ、どのリンクを使うかという隠れたポリシーになっている。

意味は前方のラベル文脈にある

RFC 9790は判断の向きを逆にする。「4ビットが何に似ているか」ではなく、「先行ラベルの束縛では何が続くことになっているか」を先に問う。ペイロードがIPv4でもIPv6でもない場合、PFNが0x4でも0x6でもないPSHを用いなければならない。

PW Control Wordは、旧ルーターがIPパーサーへ誤進入するのを避ける区切りになる。ただし送信者の身元やフレームの正しさを保証するわけではない。消しているのは一つの曖昧さだけだ。

IANA表で同じ値が再利用されるのも、この文脈依存を前提とする。0x0はDetNet、NSH、PWの各形式で使われ、0x1も複数のAssociated Channelに現れる。どれかは先行サービスラベルで区別される。PFNを世界共通の一意な型番号とみなす方が誤りである。

共通層は必要最小限の値と参照を共有し、各ノードは手元の状態で検証する。Heng LuのMinimum Initial Specificationはこの配置を説明する。レジストリは意味を調整するが、実パケットを検査せず、転送結果を認定もしない。

IPバージョン表とPFN表は別物

IP Version NumbersはIPヘッダー中のバージョンを記録する。Post-Stack First NibbleはPSHの型を記録する。両者の交点は後方互換性のための4と6だけである。

PFNレジストリは16値すべてを扱い、新規登録にはStandards Actionを求める。利用の所在と参照文書は明確になる。ただし登録行が示すのは仕様上の割り当てであり、目の前のパケットがその形式であること、装置が実装済みであること、運用設定が有効であることではない。

「IANAに載っている」を「この転送は正しい」へ拡張するのは、記録から現実への無断の飛躍である。

文脈を持つ入口でエントロピーを作る

RFC 9790は、負荷分散用にRFC 6790のEntropy LabelまたはRFC 6391のFAT Pseudowire Labelのような専用ラベルを推奨する。入口LSRはMPLSで包む前の形式とサービスを知っているため、妥当なフローフィールドを選び、その結果をラベルへ載せられる。

RFC 6790では予約ラベル7のEntropy Label Indicatorが、Entropy Labelの直前に置かれる。中継LSRは埋め込みパケットを推測せず、ラベルスタックを材料にできる。情報を持つ端が抽出し、情報の少ないコアが明示値を使う役割分担である。

それでも性能保証にはならない。能力シグナリング、スタック深度、ハッシュ品質、大規模フローの偏りは残る。明示値は何を運んだかを示すが、均等化、遅延、順序、SLA達成を示さない。

FAT PWも任意機能で、単一路が既定である。動的PWでは送受信能力を伝え、静的PWでは両端を同一に設定する必要がある。一つのFlow Labelを観測しても、両端の合意や全中継点の利用までは確定しない。

非推奨は移行完了の報告ではない

RFC 9790はRFC 4928を更新し、新規実装と新規展開でPFNからペイロード種別を推測してはならないとする。一方、既存ルーターは従来どおり動き得る。完全な廃止には、市販・展開済み実装がまだヒューリスティックを使うかどうかの調査が必要だとも述べる。

規範は設計境界を変えるが、稼働中のASICを書き換えない。異なる世代のラインカードやソフトウェアが同じサービス経路に混在し得る。「非推奨」と書かれたことも、「古いから仕方ない」と諦めることも、現状の証拠にはならない。

確認すべきは、装置が受け取ったスタック、保持していたラベル文脈、実際のハッシュ入力、そして各フローが選んだメンバーである。これがrunning codeの側から見た採用である。

証拠を一足飛びにしない

監査可能な記録には、スタックとBoS位置、直後の生オクテット、当時のラベル束縛、適用仕様と登録値、装置・版・パーサー設定、Entropy/FATラベルまたはフォールバック入力、フローごとのメンバー選択、順序・損失・遅延・分布、顧客結果を別々に残す必要がある。

RFC 9790の成果は4ビットの権威を強くしたことではない。むしろ、そこから借りていた権威を返させたことにある。信頼できる運用では、記号の見た目ではなく、推論を支えた文脈と実行結果が証拠になる。

情報源

  1. RFC 9790 — IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
  2. RFC 4928 — Avoiding Equal Cost Multipath Treatment in MPLS Networks
  3. RFC 3032 — MPLS Label Stack Encoding
  4. RFC 4385 — Pseudowire Emulation Edge-to-Edge Control Word
  5. RFC 6790 — The Use of Entropy Labels in MPLS Forwarding
  6. RFC 6391 — Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
  7. RFC 8469 — Recommendation to Use the Ethernet Control Word
  8. IANA — Post-Stack First Nibble
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile