RFC 9778：登録済みでもファイアウォールは未検証

要約

RFC 9778 は IGMP の Type と Code、拡張フラグの登録を Standards Action に置き、審査の可視性を高めるが、導入済み機器の対応を保証しない。
未知の値を解析器が拒否すれば接続性が失われ、意味を検査せず転送すればセキュリティが失われ得る。
標準上の権限、IANA 公開、実装版、解析結果、段階的相互接続、通信影響、切り戻しは、別々の証跡として残す必要がある。

IANA の表は共同利用する番号空間に秩序を与える。番号、名称、参照 RFC が一行に並ぶため、運用準備まで完了したように見えやすい。しかし、その行は現場のパケットを一度も読んでいない。

2025 年 3 月に BCP 57 として公開され、RFC 3228 を置き換えた RFC 9778 は、IGMP Type の方針を Standards Action に変更した。IGMP Code も同じ方針となり、新しい Type を定義する文書は、その Type に属する Code の方針も定めなければならない。Query flags では bit 0 を E、bit 1〜3 を未割り当てとし、Report flags では bit 0 を E、bit 1〜15 を未割り当てとする二つの登録簿も設けられた。

一方、MLD の Type と Code は ICMPv6 Parameters の IETF Review に残る。IGMP と MLD を一つの曖昧な承認にまとめず、フィールドごとの権限を守る設計である。

高い審査は配備試験ではない

RFC 8126 の Standards Action は、IESG が承認した Standards Track RFC または BCP を要求する。提案の意味を広く見せ、実装者とセキュリティ審査者が早く検討できる点に価値がある。ただし証明するのは割り当て手続きであり、特定のファームウェア、ルールセット、IDS やデコーダの挙動ではない。

RFC 9778 は、未知値に対する二方向の故障を明記する。古い装置が拒否すれば、正当な membership report が失われ、マルチキャストの到達性が崩れる。逆に通常どおり転送しても、新しい意味を検査していなければ攻撃の経路になり得る。通信が通ることは、検査が成立した証拠ではない。

RFC 6709 が扱う未知拡張、かつて zero を要求されたビット、部分実装、silent discard は、この危険が一般的であることを示す。RFC 9279 では、整形式だが未対応の extension TLV と、形式自体が不正な構造を区別する。基本メッセージを読めるという宣言だけでは、この分岐を正しく実装したかは分からない。

七枚の証跡を混ぜない

権限は標準文書と手続きを示す。公開は IANA 登録簿の状態と取得時刻を示す。実装はソフトウェア、ファームウェア、デコーダ、規則の正確な版を示す。解析は既知・未知・不正・混在ベクトルへの実際の verdict を示す。相互接続は新旧の送受信者と中継制御の組合せを示す。影響は join、leave、損失、遅延、警報、資源消費を示す。切り戻しは無関係な通信を止めずに変更を除去できることを示す。

IANA 公開済みでも実装は欠け得る。構文解析が成功してもポリシーは旧来の default に落ち得る。ラボの新しい二端点が動いても途中の古い装置は拒否し得る。Heng Lu の running-code primacy と reality layers は、登録簿を否定するのではなく、調整層の記録を実行層の事実へ無断で昇格させないための規律になる。

安全に失敗できる順序

次は仮想的な試験設計であり、実在製品の結果ではない。まず IGMP/MLD を読む host stack、switch、router、firewall、sensor、packet broker、collector、診断 tool を列挙し、版と設定 hash を保存する。既存 traffic を基準に、新しい値、未割り当て値、整形式の未知拡張、長さや checksum の不正、新旧 peer の混在を一つずつ追加する。

各 hop で、認識、明示規則による無視、拒否、警報、意味判定なしの転送を区別する。その結果を membership state と data-plane の変化に結び付ける。限定 canary の前に、拒否増加、report 欠落、fallback、資源圧力、状態不一致、説明不能な損失を停止条件として定義する。送信側の旧挙動と制御側の旧 policy は、独立した二つの切り戻し手段として保つ。