要約

  • RFC 5350 は IPv4 Router Alert 値の登録簿を作り、IPv6 側の不整合を直した。番号の一意性は示せても、個々のルーターがオプションを解析し、値を認識し、制御プレーンへ渡すことまでは示せない。
  • RFC 6398 が記録した実装は一様ではない。高速経路で処理する装置も、ほぼすべてを低速経路へ送る装置も、値を見ない装置も、フィルタ、レート制限、無視を選ぶ運用もある。処理コストを負担する側にローカルな判断権が残る。
  • RFC 9805 は 2025 年、IPv6 Router Alert を新しい標準プロトコルで使うことを禁じ、値の登録簿を閉じた。一方、列挙済みの既存利用は継続できる。閉鎖は将来の設計判断であり、既存トラフィックの消滅証明ではない。

登録簿が直したのは衝突だった

RFC 5350 より前、IPv6 には IANA 管理の値一覧があったが、IPv4 には RFC 2113 の値 0 と後続利用があるだけで、一般的な登録手続がなかった。RFC 3175 の集約レベルも加わり、二つのアドレス体系の値はきれいに対応せず、重複も生じていた。

RFC 5350 は IPv4 登録簿を新設し、初期割り当て、実験用範囲、予約範囲を定め、新規値を IETF Review に置いた。IPv6 では重複値を取り除いた。これにより仕様作成者は既存利用を確認でき、同じ番号に別の恒久的意味が付く事故を避けられる。

しかし、登録簿は転送装置ではない。値を登録しても、ASIC に解析処理は追加されない。制御用 CPU へのキューも広がらない。プロトコルは自動的に有効化されず、外部送信者との信頼関係も成立しない。

したがって「IANA に登録済み」は名前空間に関する証拠である。装置能力、インターフェース設定、許可された送信元、処理上限、プロトコル状態については別の証拠が要る。公開表をそのまま対応機能一覧として使えば、文書を実測値に変換したことになる。

高速経路と低速経路では一パケットの価格が違う

Router Alert の発想は、すべてのデータグラムを深く調べずに、ルーター自身が関心を持つパケットを見つけることだった。通常の転送を高速なまま保ち、必要なものだけを追加処理へ回す。

この追加処理の実装が重要である。RFC 6398 は、一部装置が高速経路内で処理できる一方、多くの実装が Router Alert 付きパケットの大半または全部を低速経路へ送ると述べる。IPv4 の Value を細かく見ず、Router Alert であれば一律に処理する実装も報告された。

転送用ハードウェアと汎用 CPU では処理能力が異なる。通常なら安価に通るパケットが、オプション一つで希少な CPU 時間を消費するなら、遠隔の送信者が装置内部のコストを選べてしまう。これは登録問題ではなく、資源への入場問題である。

そのため RFC 6398 は、事業者に強い保護を求める。フィルタ、レート制限、トンネル、エッジだけでの処理、単純に Router Alert を無視する設定は、標準違反を目的とするものではない。外部の印が内部資源への無条件チケットになるのを防ぐ。

監査では「あり／なし」だけでなく、どの経路を通ったかを残す必要がある。高速処理、保護された punt、レート制限、無視して転送、破棄、値は既知だが機能停止、上位プロトコルで拒否、という結果はすべて異なる。

“詳しく調べる”には参加条件があった

RFC 2113 の短い表現だけを見ると、Router Alert を持つパケットはすべてのルーターが調べるように読める。RFC 7126 は、Value が表す機能にそのルーターが参加する場合、という条件を明示する。

送信者は、経路上の全装置を一方的に参加者へ変えられない。装置がプロトコルを実装していない場合も、管理ドメイン内だけで有効にしている場合も、外部からの要求を拒む場合もある。値を理解していても、そのインターフェースでは処理しないという判断もできる。

登録値が伝えるのは要求の種類であって、送信者の身元や権限ではない。値 0 や別の割り当て値が正しくても、誰が、どの境界から、どの速度で、どのプロトコルに仕事を依頼しているかは分からない。

セキュリティ自動化では、この差をルールとして保持すべきだ。IANA 照合は意味を説明するために使い、許可判定には入口、送信元、信頼ゾーン、レート、機能設定、ポリシー版を使う。「既知の値」を「許可済み」に短絡させてはならない。

結果までには九つの境界がある

一つの Router Alert について、少なくとも次の事実を分ける。

  1. その時点で値が割り当て済み、または予約済みだった。
  2. 実際のパケットが正しい形式と値を持っていた。
  3. 対象ノードが特定インターフェースで受信した。
  4. パーサーが無視や事前破棄をせず、オプションを読んだ。
  5. ノードが値を認識し、示された機能に参加していた。
  6. ローカルポリシーが追加処理または保護された punt を許した。
  7. 上位プロトコルがメッセージを検証し、権限を認めた。
  8. 予約、メンバーシップ、シグナリングの状態が変わった。
  9. 転送または利用者が見るサービスに効果が現れた。

IANA の行は第 1 段階の証拠にすぎない。パケットキャプチャは第 2 段階を示すが、第 6 段階は示さない。CPU カウンターは仕事量を示しても、プロトコル受理を示さない。状態テーブルも最終サービスを保証しない。

障害時には、最初に欠けた受領証を探す。登録の有無だけで原因を決めると、入口フィルタ、未対応実装、ポリサー、検証失敗、状態作成失敗、後段転送障害が同じ箱に入ってしまう。

責任もこの順序で分かれる。IANA は番号の明確さ、実装者はコード、運用者はローカルな許可、プロトコルは検証、サービスは最終結果を担う。一つの表で全員の仕事を証明することはできない。

実験値は管理境界を越えると同じ意味を失う

RFC 5350 は実験用の範囲を設けたが、製品ネットワークが実験的 IP オプションを扱うとは限らないと警告した。複数ドメインにまたがる場合、同じ実験値が別の意味で使われる可能性もある。

単一ドメインなら、管理者が値、対象装置、制限、期間を統一できる。境界を越えれば、その合意はパケットに埋め込まれていない。相手は未知値として扱うか、別の実験だと解釈するか、一般的な防御規則で落とすかもしれない。

実験記録には、対象インターフェース、隣接関係、意味、レート、漏出防止、フォールバック、終了日が必要である。「実験用として有効な値」というだけでは、相手ネットワークの参加も、世界的な一意性も証明しない。

特に、無視されたときの振る舞いを決めておく必要がある。通常転送で機能を保てるのか、別の信号路があるのか。未合意の外部ドメインが低速処理してくれることを前提にすれば、実験は最初から他者の資源を無断で設計に組み込んでいる。

IPv6 の閉鎖は将来の設計を変えた

現在の IANA 記録では、IPv4 の値登録は IETF Review のままである。IPv6 の値登録簿は RFC 9805 を参照し、「Registry closed」と表示する。

RFC 9805 は、新しい標準プロトコルが IPv6 Router Alert を使うことを禁じる。一方、すでに列挙されているプロトコルは継続可能である。文書は MLDv2 と MRD を広く配備されたものとして挙げ、その他を限定的、実験的、または既知実装なしと整理した。

これは設計空間を閉じる規範であって、全ネットワークの実測調査ではない。古い装置の設定を消すものでも、すべてのパケットを落とす命令でもない。既存利用と将来の新規利用は別に扱われる。

したがって「deprecated」を「消滅」と訳して運用判断に使うのは危険である。同様に「既存利用可」を「どこでも到達可」と解釈してもいけない。登録簿の状態と経路上の処理は別々に確認する。

最小の共通仕様はローカル責任を消さない

Lu Heng の最小初期仕様に関するノートは、後世の分析レンズとしてだけ使える。共有層が必要最小限を定め、将来の採用判断を実行者に残すという考え方である。RFC 5350 の意図を証明する資料ではなく、IETF の見解でもない。

この場合、共有層は値、参照、割り当て手続を整える。装置で実装するか、どの入口で認めるか、どれだけ CPU を使わせるかは、損失を負う運用者が決める。中央の表を小さく保つことは、責任を曖昧にするのではなく、責任の所在を明確にする。

現実層に関するノートも同じ注意を与える。登録簿は記号の事実、パケットは観測の事実、ルーターの処置は実行の事実、サービスは結果の事実である。関係はあるが、代替できない。

経営上必要なのは、値から装置、インターフェース、キュー、プロトコル、サービスまでの依存図である。ハードウェア更新で既定処理が変わっても、IANA 表は変わらない。変化を見つけるのはローカルな証拠だけだ。