要約

  • RFC 3307は、サーバー割当とホスト割当の双方に0x80000000-0xFFFFFFFFを与え、その上端はSolicited-Nodeマルチキャストの範囲とも重なっていた。別々の仕組みが規則どおりに同じGroup IDを選び得た。
  • RFC 10028はMADCAP、未割当、SSMホスト割当、私用、実験用、Solicited-Nodeの六範囲をIANAに登録した。防いだのは割当領域の衝突であり、すべてのネットワーク層・リンク層・機器内衝突ではない。
  • Mike McBrideはNate Karstens、Dino Farinacciとの共同著者である。レジストリが共通名前空間を分けても、実装の更新、SSMの前提、転送、送信元の正当性、受信権限は稼働中の証拠を要する。

衝突の原因が実装にあるとは限らない。実装が二つとも正しく、割当表のほうが同じ場所を指している場合がある。

RFC 3307の動的IPv6マルチキャストGroup IDは、その状態だった。サーバーが割り当てる方式と、ホスト自身が選ぶ方式が定義され、どちらにも0x80000000-0xFFFFFFFFが指定された。後半の0xFF000000-0xFFFFFFFFは、IPv6 Neighbor Discoveryで使われるSolicited-Nodeアドレスの領域でもある。

サーバーとホストは互いを知らず、規則違反もしないまま同じ値を選べる。これはローカルな不注意ではなく、共通仕様が選択権を分離していないという設計上の問題である。

2026年8月にIETF Standards Trackとして刊行されたRFC 10028は、この一点を修正した。著者はNate Karstens、Dino Farinacci、Mike McBrideの三人である。本稿はMcBrideを人物の入口にするが、単独発明者にも、IANAや運用者を指揮する人物にも仕立てない。

2026年8月31日に保存したIETF Datatrackerは、McBrideをPIM議長、MBONEDとANIMAの代表、Routing Area Directorateのレビュアー、9件のRFCの著者として掲載する。RFC 10028の所属はFutureweiである。Open Networking Foundationの2017年の記事は本人の職歴を当時の言葉で伝える。いずれも専門性の背景であり、特定ネットワークの導入証明ではない。

低位32ビットを二方式が共有した

IPv6マルチキャストアドレスの低位32ビットは、RFC 3307でGroup IDとして扱われる。Ethernetでは、そのビットがリンク層のマルチキャストアドレスに直接写される。したがって重複は、台帳上の同名にとどまらない。NICやスイッチが、本来別のグループに届くフレームを同じリンク宛先で受け取ることにつながる。

RFC 2730のMADCAPはクライアント・サーバー型である。ホストがマルチキャストアドレスをサーバーへ要求する。一方、RFC 10019が必要性を述べたzeroconf方式は、中央サーバーなしでホストが選べることを求める。調整モデルの異なる二方式が、同じ大きな範囲を自分のものと見なしていた。

ランダム選択は所有範囲の重複を解消しない。衝突確率を下げても、他方式が合法的に同じ値を選べる事実は残る。しかも古い動的範囲はSolicited-Nodeの建築済み区画まで含めていた。

RFC 10019は残る課題も明確にする。複数アプリケーションと方式の共存、ネットワーク層とリンク層の衝突検出、分断されたネットワークが再接続した際の解決が必要になる。RFC 10028は、こうしたアルゴリズムに入る前に除去できる重複を除去した。

六つの範囲は六つの主張である

IANAのDynamic Multicast Group IDsレジストリは、初期状態を次のように分ける。

  • 0x80000000-0x8FFFFFFF：MADCAP
  • 0x90000000-0xEFFFFFFF：未割当
  • 0xF0000000-0xFCFFFFFF：SSM Group IDのホスト割当
  • 0xFD000000-0xFDFFFFFF：私用
  • 0xFE000000-0xFEFFFFFF：実験用
  • 0xFF000000-0xFFFFFFFF：Solicited-Nodeマルチキャスト

未割当の通常領域を将来使うにはStandards Actionが要る。レジストリの項目は範囲、説明、参照文書だけである。製品名、導入率、転送成功率、利用者の権限は持たない。

この薄さは意図に合っている。共通層が保証すべきなのは、MADCAPとSSMホスト割当を同じ範囲に置かないことだ。アプリケーションの判断やネットワークの実装まで一枚の表に集めれば、表は検証できない権限を帯びる。

反対に、表の限界を忘れてはならない。IPv6アドレスの上位部分が異なっても低位32ビットが同じなら、Ethernet宛先は同じになり得る。スイッチの有限なテーブルやハッシュ方式も別の圧力を生む。ネットワーク分断中の独立選択や、不正な送信も残る。

RFC 10028が消すのは「異なる割当方式が公式に同じ範囲を与えられた」という衝突である。Group IDに関係する全障害を消したわけではない。だからRFC 10019の検出・解決要件は、レジストリ公開後も意味を失わない。

SSM範囲はSSM機能を実装しない

ホスト割当の範囲にはSSMという条件が付く。Source-Specific Multicastでは、チャネルはグループGだけでなく送信元を加えた(S,G)で識別される。RFC 4607は、送信元が異なれば同じGを再利用でき、グループ値を世界的に一意にする調整が減ると説明する。

しかしSは範囲表から自動的には供給されない。アプリケーションが送信元を知り、ホストがIGMPv3またはMLDv2で送信元指定の参加を表現し、指定ルーターとPIMドメインがその意味を維持しなければならない。RFC 8815がSSMを推奨する一方、アプリケーション対応を導入上の課題として扱うのはそのためである。

RFC 10028自身も、SSMは普遍的に対応されていないと記す。0xF0000000-0xFCFFFFFFから値を選ぶことは、古いOSを更新せず、MLDv2を設定せず、経路を作らず、送信元を認証しない。正しい番号と使えるチャネルは別の証拠である。

Heng LuのMinimum Initial SpecificationとRunning-Code Primacyは、この分離を保つために使える。共通仕様は相互運用に必要な最小境界を決め、その後の選択は現場に残す。変更が現実になったかは採用と稼働結果で判断する。IANAのプロトコル表をRIRと同一視する話ではなく、宣言を実装の代用にしないという証拠原則である。

古いMADCAPは新しい地図を読まない

RFC 10028はMADCAPの領域を大幅に縮小した。執筆時点で著者が把握していた実装は一つで、大規模導入は把握されていなかったという。これは世界全体の不存在証明ではない。「知られていない」は調査範囲を示す慎重な表現である。

既存実装は新範囲に更新するか、他のIPv6マルチキャスト割当方式が存在しない環境で動かす必要がある。IANAのWebページは古いバイナリを書き換えない。保守終了機器やコピーされた設定も自動では変わらない。

移行の記録には、どのallocatorが、どのバージョンと設定で、どのルールスナップショットに従い、いつGroup IDを生成したかが要る。完全なIPv6アドレスだけを残しても、後から旧MADCAP、現行SSMホスト、リンク写像、分断、悪意ある利用を区別できない。

新方式のほうがログを備え、変化として目立つこともある。古いサーバーとの衝突時に新方式だけが停止されれば、組織は現行仕様に従う側を罰し、技術的負債を温存する。生成元の証拠がなければ、この逆転を防げない。

レジストリと稼働結果を結ぶ

RFCはIETFの決定を証明する。IANAは現在公開する範囲を証明する。実装テストは一つのallocatorが範囲内に収まることを証明する。(S,G)の制御試験とパケット観測は、特定時点・経路のSSM動作を証明する。送信元の正当性と受信権限には別の記録が要る。

一つの証拠が他を包含することはない。

IANA行は導入率を示さず、SSMアドレスは経路対応を示さず、受信成功は送信者の権限を示さない。一度衝突しなかったことも、別scope、別トポロジー、機器限界を保証しない。

運用台帳は薄くてよい。allocator、バージョン、方式、Group ID、完全アドレス、RFC/IANA時点、SSM前提、衝突検出、転送観測、送信元検証、受信権限、ロールバック責任者を分ける。各欄が証明できる範囲だけを語ることが、RFC 10028の設計と同じ価値を持つ。

McBride、Karstens、Farinacciの共同作業は、大きな新アーキテクチャではない。規則が自ら作っていた曖昧さを一つ除去した。将来の方式が入る場所を、衝突する前に空けたのである。

レジストリは共存を可能にした。共存が実現したかは、稼働中のネットワークが答える。

出典