要約

  • RFC 10028 は、RFC 3307 で重なっていた動的範囲を、MADCAP、ホストによる SSM 割当、Private Use、Experimental Use、Solicited-Node に分離した。
  • この分離が衝突を防ぐのは、同じスコープで動く全割当器が新しい規則を実装した場合だけである。範囲適合は、割当の由来、アドレスの一意性、受信参加、転送、正しいストリームの到達を証明しない。

運用チームは本番の MADCAP サーバーを更新し、プールの上限が 0x8FFFFFFF になったことを確認した。新しいホスト割当器は 0xF0000000 から始まる SSM 用範囲を使う。移行票は完了になった。

数か月後、本番機が故障する。冷待機していた旧サーバーが起動し、RFC 3307 の設定を読み込む。そこでは 0x80000000 から 0xFFFFFFFF までが MADCAP の動的プールである。旧サーバーは、すでにホストが SSM 用に選んだ値を別のクライアントへ貸し出す。

本番更新の証拠は真実だった。システム全体の移行という結論だけが誤っていた。

RFC 10028 は 2026 年 8 月に IETF Standards Track として公開され、この種の重複を規則上解消した。だが RFC は待機ノードを起動して設定を検査しない。IANA の表も、どの実行ファイルがライブな ID を発行したかを記録しない。新しい標準が作るのは共通境界であり、採用の証拠ではない。

RFC 3307 では異なる方式が同じ範囲を共有した

RFC 3307 は、IPv6 マルチキャスト・アドレスの下位 32 ビットをグループ ID とし、リンク層への対応にも用いた。ところが動的割当では、サーバー方式とホスト方式の双方に 0x800000000xFFFFFFFF を与えた。上位部分は Solicited-Node の ID とも重なっていた。

つまり、二つの割当器がそれぞれ旧仕様に従って同じ値を選び得た。完成したアドレスだけを保存すると、その値を MADCAP、ホスト、Solicited-Node のどれが生んだのか後から判定できない。

RFC 10028 と現在の IANA IPv6 Multicast Address Space は、次の区分を示す。

  • 0x800000000x8FFFFFFF：MADCAP
  • 0x900000000xEFFFFFFF：未割当
  • 0xF00000000xFCFFFFFF：ホストによる SSM グループ割当
  • 0xFD0000000xFDFFFFFF：Private Use
  • 0xFE0000000xFEFFFFFF：Experimental Use
  • 0xFF0000000xFFFFFFFF：Solicited-Node

未割当部分の将来変更には Standards Action が必要である。RFC 8126 は、レジストリ方針と変更管理、私用・実験用といった分類を説明する。この表は方式間の調整に必要な最小限の約束である。

しかし、IANA は現場の個別グループを貸し出す主体ではない。値の所属範囲は、使用できる割当方式を示す。実際の割当者、設定、リース、受信者を示すものではない。

RFC の運用条件は「更新か隔離」

RFC 10028 は MADCAP の範囲を縮小し、実装を新しい範囲へ更新するよう求める。既存配備は、更新した実装を使うか、他の IPv6 マルチキャスト割当プロトコルが共存しない環境で動かすべきだとする。

運用側に残る選択は明確である。更新を実証するか、隔離を実証するか。

RFC は執筆時点で既知の MADCAP 実装を一つ、既知の大規模配備をゼロと記した。この限定された観察は、現在の市場調査でも、組織内の資産台帳でもない。古い実装が少ないと推測することは、冷待機、組込み機器、長期稼働設備の確認を省く根拠にならない。

RFC 2730 の MADCAP はクライアント・サーバー方式である。クライアントはサーバーを発見し、アドレスを要求し、OFFER、ACK、NAK を受ける。管理者はローカル方針を設定できる。ACK はそのサーバーの判断を示すが、プールが RFC 10028 に適合することまでは示さない。

必要な記録は、ソフトウェアとビルド、設定ハッシュ、実効プール、クライアント、スコープ、リース ID、開始・更新・終了時刻である。冗長系や災害復旧用イメージも同じ台帳に含めなければならない。

グループ ID は Ethernet の宛先になる

RFC 4291 は IPv6 マルチキャストの形式、スコープ、グループ ID を定義する。非恒久グループの意味はスコープに依存する。隔離中に安全だった同一値も、ネットワーク統合後には衝突し得る。

RFC 2464 は Ethernet 上で、IPv6 宛先の最後の四オクテットを 33:33 に続けてマルチキャスト MAC を作る。割当器が選んだ下位 32 ビットは、NIC フィルターやスイッチ表へ到達する。正しい変換は一意性の証明ではない。

RFC 10019 は、ゼロ構成ネットワークでのリンク層衝突を具体化した。不要なトラフィックを CPU で処理させ、snooping の効果を失わせ、低速リンクを圧迫し、有限の転送表を消費する可能性がある。船舶のセンサー、制御、レーダー、映像は一例であり、産業制御や AV、センサーネットにも同じ構造がある。

分断した二つの区画が同じ ID を独立に選び、再接続時に初めて衝突することもある。RFC 10019 は将来の分散型解決策に検出と移行を要求するが、それ自体は完成した割当プロトコルではない。RFC 10028 はその方式が他方式と共存するための範囲を用意する。

SSM の (S,G) も経路全体を証明しない

RFC 4607 では SSM チャネルを送信元とグループの組 (S,G) で表す。送信元が異なれば同じ G を再利用できる。RFC 8815 が述べるように、SSM 空間では G の世界的な一意性を調整する必要がない。

それでも S は必要であり、アプリケーション、ホスト、ルーター、スイッチが対応しなければならない。RFC 10028 は SSM が普遍的にサポートされていないと明記する。

低価格のスイッチには宛先 MAC しか表現できないものがある。RFC 4541 は、IGMP/MLD snooping の版や能力が合わないと、必要な流を誤って刈り込んだり、未登録トラフィックを広げたりすることを示す。アプリケーションが (S,G) を要求しても、L2 が S を見ているとは限らない。

したがって、送信元、MLD/IGMP 参加報告、snooping、マルチキャスト経路、期待するパケット内容を別々に検証する必要がある。

私用・実験用は運用責任を免除しない

Private Use は隔離環境での手動割当に使える。中央調整なしに値を選べる一方、別組織も同じ値を選べる。拠点統合、臨時接続、冗長回線復旧の前には衝突評価が必要である。

Experimental Use は新方式の試験用で、RFC 10028 は公開インターネット上の実験も排除していない。しかしラベルは安全性、許可、非衝突、製品適性を保証しない。責任者、スコープ、終了日、撤去記録が要る。

未割当範囲は自由利用ではなく将来の Standards Action のために残される。Solicited-Node は IPv6 の固有機能であり、動的プールの余白ではない。

割当記録に「規則の世代」を入れる

各割当について、標準の版、割当方式、実装版、設定ハッシュ、選択またはリースのイベントを保存する。完全な IPv6 アドレス、スコープ、グループ ID、Ethernet 対応、アプリケーション、ストリーム、開始・更新・期限も必要である。SSM では S をチャネル識別子に含める。

さらに、同一スコープの他割当器、衝突検査、MLD/IGMP 参加、snooping と転送表、最初と最後のパケット、予期しない送信元、再番号付け、旧状態の撤去までつなぐ。

「現行範囲内」「割当済み」「重複なし」「参加済み」「転送済み」「アプリケーション受信済み」は六つの異なる状態である。一つの緑色に畳んではならない。

Heng Lu の稼働コード優先は、証拠をレジストリの記号ではなく実行経路に置く。最小初期仕様と将来判断のローカル化は、共通範囲を狭く保ち、採用判断を現場に残す。データ主権の形式と実態の区別は、IETF と IANA が空間を定義しても、実装・スイッチ・受信結果を支配しない理由を示す。

新しい地図は完成した。移行の成否は、稼働中の設備でしか証明できない。