要約

  • RFC 10019は、中央サーバー、外部接続、管理者設定に依存しない将来のZeroconfマルチキャスト割り当て方式に対し、ネットワーク層とリンク層の双方で一意性を求める。
  • 異なるIPグループが同じEthernet宛先へ写像されることがあり、分断された区画は同一グループを独立に割り当て、再接続まで衝突を発見できない。
  • 解決の完了には、存続側と移行側の決定、新グループへの受信者移動、スイッチとNICの収束、旧グループの停止、アプリケーション内容の確認が必要である。

一台のスイッチから見れば、二つのアプリケーションが使う別々のIPv6グループも、同じ33:33宛先かもしれない。一方、割り当て側の台帳には重複がない。どちらか一方だけが「正しい」のではなく、見ている識別空間が違う。

RFC 10019は、この食い違いをZeroconfマルチキャストの中心問題として扱う。2026年7月にIETF Informational RFCとして公開された問題記述と要件文書であり、完成したプロトコルではない。パケット形式、勝者の選び方、認証方式、実装済み製品を定めてはいない。

文書のREQ-1は、割り当て結果がIP層だけでなくリンク層でも一意でなければならないとする。REQ-8は両層の衝突を検出して解消し、分断された区画の再結合で同じグループが現れた場合には、競合するストリームを一意なアドレスへ移すことを求める。ここで割り当て成功は最終権限ではなく、観測時点に限定された主張になる。

32個のIPグループが一つのMACになる

RFC 1112では、IPv4マルチキャストの下位23ビットをEthernet宛先へ組み込む。IPv4マルチキャストには28ビットの可変部分があるため、32個の異なるIPグループが同じMACアドレスへ写像され得る。

IPv6でも圧縮は残る。RFC 2464は33:33にIPv6宛先の下位32ビットを続ける。大きなアドレス空間は候補選択を容易にするが、Ethernet機器が見る情報量は増えない。上位ビットだけが異なる二つのグループを、MAC宛先だけのフィルターは区別できない。

影響は受信機で現れる。アプリケーションがグループへ参加すると、NICは通常、必要なマルチキャストだけを通すハードウェアフィルターを設定する。同じMACへの衝突があれば不要フレームも入り、ソフトウェアで捨てる必要が生じる。RFC 1112はフィルター容量が足りない場合に全マルチキャストを受ける実装も認める。正しいデータを最終的に選べても、CPU負荷と受信面は同じではない。

RFC 4541が扱うIGMP/MLD snoopingにも実装差がある。完全なIPグループではなくリンク層宛先に基づいて転送する機器では、別グループの高帯域ストリームが低速ポートへ流れ込む。有限の転送表やハッシュ領域は、別の衝突によってエントリ拒否やフラッディングを起こし得る。

割り当て関数の戻り値から、これらは証明できない。IP候補とMAC導出は割り当て側が示せる。実際の識別はNIC、スイッチ、パケット、受信アプリケーションがそれぞれ観測する。

分断は二つの正しい時系列を作る

一時的なネットワーク分断では、区画Aと区画Bが同じグループを別々に選び、互いの主張を聞かないまま使用を開始できる。再接続後に古い時刻だけで所有者を決めることは危うい。時計は比較できないかもしれず、分断中の「先着」は相手に観測可能ではなかった。重要度の高い後発ストリームを移すべきでない場合もある。

RFC 10019は、最古のリース、最小アドレス、機器優先度などの決着規則を指定しない。したがって運用記録には、アドレス族、完全なグループ、スコープ、導出MAC、SSMの送信元、割り当て実装と規則版、ローカルインスタンス、アプリまたはストリーム、要求の時代、観測ドメイン、交換記録のハッシュが要る。

リンク復旧、ブリッジ追加、VLAN統合、インターフェース移動、発見ドメイン変更は、観測ドメインが結合した合図である。完全一致するIPだけでなく、異なるIPと同一MACの組み合わせを調べる。応答がないことだけでは安全を証明できない。参加者が休止中かもしれず、snoopingが未収束で、NICが既に広い受信へ落ちている可能性もある。

解消では、存続する主張と移動する主張を明記する。移動側へ両層で一意な置換を与え、発見情報を更新し、受信者を移し、転送状態を収束させ、内容を確認し、旧送信を止める。新旧を一定期間併記する段階移行は有効だが、RFCが定めたアルゴリズムではなくローカル設計である。

中央を置かないことと、責任を消すことは違う

RFC 10019は単一障害点を最小化し、利用者設定なし、外部接続なし、単一サブネットで動作し、一台のホスト上の複数アプリを扱うことを求める。可能な場合は手動割り当てや他方式と共存し、低オーバーヘッド、発見、複数プラットフォーム、トポロジー変化への耐性を推奨する。

RFC 2730のMADCAPはクライアントとサーバーによるリース方式である。サーバーを利用できる環境には意味があるが、インフラ不要の目標を単独では満たさない。必須のローカルコントローラーへ全権を移すだけでも、障害点は残る。

一方、分散方式にも衝突ポリシーは必要だ。観測可能な古さ、アプリ優先度、決定的ID、運用者判断などを用い得るが、いずれもRFCの命令ではない。何を採用したかを明示し、後から同じ入力で判断を再現できなければならない。

安全面では、偶発的または悪意ある衝突がサービス妨害やトラフィック誤配送を起こすとされる。検出と解消は必須、無許可利用の防止は推奨だが、具体方式は範囲外である。衝突通知は存在するだけで本物にならない。主張者との結び付け、強制移動の回数制限、根拠保存がなければ、解消機能が再番号付け攻撃になる。

IPv6の余裕は、実行証拠ではない

RFC 10019は新しい動的設計にIPv6を推奨する。IPv4を使う必要がある場合は、RFC 5771の管理スコープ領域から慎重に選ぶ。複数方式の共存が不可能なら、方式を限定するか手動設定を残す方が、根拠のない自動互換より正直である。

RFC 4291のIPv6スコープは伝播の境界を示すが、リースや利用権を与えない。RFC 3307の旧来のグループID構成は、RFC 10028によってMADCAP、ホスト割り当てSSM、Private Use、Experimental Use、Solicited-Nodeの範囲へ分離された。この規則更新は一種類の重複を減らすが、分断後の発見や移行を実装しない。

SSMはチャネルを送信元とグループの組として扱う。RFC 8815はSSMを運用上優先する理由とASMの限定用途を示す。送信元を証拠に残すことは重要だが、MAC写像の衝突やハードウェアが送信元を実際に適用したかという問題は残る。

RFC 10019は割り当て後のグループ利用を範囲外とする。IGMP/MLD報告は関心を示すが、受信者の権限や内容を証明しない。転送エントリは設定状態、カウンターは量を示すだけである。

閉じるべき証拠鎖は、割り当て意図、観測ドメイン、IP一意性、リンク一意性、受信参加、スイッチとNIC状態、パケット指紋、アプリ結果、旧時代の撤回まで続く。Heng LuのRunning-Code Primacyは実行観測を台帳の象徴より上に置くが、台帳自体を不要にはしない。Minimum Initial Specificationは共通要件を薄く保ち、局所的な調停まで中央集権化しない。Reality Layersは、形式上正しいアドレスと、有限な装置が実際に見た宛先を分離する。