要約

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 は、使用中であるとの通知を受けなければアドレスを利用可能とみなす。mDNSのフィルタ、リフレクターの欠落、ネットワーク分断は、「存在しない」のではなく「見えない」競合を作る。
  • 永続化したグループIDは再選択の揺れを減らすだけで、プローブ、アナウンス、継続クエリ、防御を省略する権限にはならない。分断復旧後の敗者は送信を止め、新IDを選んで保存し直さなければならない。

第12版は2026年9月22日付で公開された。凍結したDatatracker記録では、PIMワーキンググループの現行Internet-Draftであり、IESGへ提出済み、10月6日までIETF Last Call中である。目標はProposed Standardだが、RFCでも、IANA手続き完了でも、相互接続性の実証でもない。

提案は中央の割当サーバーを置かず、IPv6マルチキャストのグループIDをリンク上で調整する。アプリケーションは初回送信時、または競合後に、提案中の範囲 0x90000000–0x9FFFFFFF からランダムな値を選ぶ。その値と送信元インターフェース識別子からリンクスコープのIPv6マルチキャストアドレスを作り、対応するEthernetマルチキャストアドレスを導く。

さらにEthernetアドレスのニブルを逆順にして .eth-addr.arpa 配下の名前を組み立てる。草案の例では、グループID 9abc:def0 から 33:33:9A:BC:DE:F0 が得られ、名前は 0.f.e.d.c.b.a.9.3.3.3.eth-addr.arpa になる。アプリケーションは固有のPTRレコードを作り、mDNSでプローブし、アナウンスし、問い合わせに応答し、継続的に競合を探し、レコードを防御する。

第12版が明記した核心は「暗黙の可用性」だ。使用中との通知を何も受けなければ、自分が使えると仮定する。ホストまたはネットワークがmDNSをフィルタすれば、アプリケーション同士の調整は成立せず、アドレス競合が起こり得ると草案自身が警告する。

ここで、無応答は普遍的な事実ではない。プローブが示すのは、その時点で到達したインターフェース、リンク、リフレクター経路の中で矛盾が見えなかったということだけだ。草案が示す n / 2^28 という衝突確率はランダム選択の評価であり、観測範囲の完全性を保証しない。

分断はこの弱点を具体化する。スイッチ障害で一つのネットワークが二つに割れたとする。一方では保存済みIDを持つストリームが再開し、もう一方では別の送信者が同じIDを選ぶ。双方がプローブしても、相手のPTRは切断点を越えない。各側では「競合なし」という正しい局所結果が得られる。

接続が復旧すると、二つの局所結果は両立しない。草案はこのためにPTRの継続クエリを必須とする。競合が検出されればmDNSの規則で勝敗を決め、敗者は当該ストリームの送信を停止し、新しいグループIDを選び、保存値を上書きする。

問題は検出までの時間である。草案はmDNSが低帯域を意図した仕組みであり、分断修復後にリソースレコードの競合を見つけるまで相当の時間がかかり得ると述べる。標準的な上限時間は示さない。ストリームが任意の時点で新設される環境では、分断前に全IDが固定されている環境より懸念が大きい。

その間、二つの送信者はどちらも正常に見えるかもしれない。同じ宛先Ethernetマルチキャストアドレスに、異なる宛先IPv6マルチキャストアドレスが重なる可能性がある。「PTR登録済み」という一つの表示だけでは、この状態を説明できない。

第12版は任意の補助検出も用意する。ホストのネットワークスタックが、同じ宛先マルチキャストMACと異なる宛先IPv6アドレスの組み合わせを見つけた場合、アプリケーションは送信を止めてIDを選び直す。片方だけが動けば解消するが、双方が動いてもよい。どちらが譲るかをホスト間で調整する方法は規定されていない。

ネットワーク機器にはvetoレコードという強制手段がある。解消できない競合を検知した機器は、元のPTRターゲットの先頭ラベルに -veto を付ける。これによりmDNSの辞書順比較で常に後になり、常に競合に勝つ。機器はプローブせずにvetoを公開し、アプリケーション側が新しいIDへ移る。

ただしvetoは恒久状態ではない。原因となったPTRがgoodbyeまたは期限切れで無効になったら、veto送信側は5秒間問い合わせる。該当PTRを含む応答がなければ、20～120ミリ秒のランダム待機後にgoodbyeを送り、vetoを無効にする。新IDはアプリケーション側に保存されるため、vetoそのものを永続化する必要はない。

決定的な優先順位は攻撃にも使える。悪意ある参加者はプローブへの偽の競合応答で新規割当を妨げたり、使用中のアドレスへvetoを繰り返してストリームを止めたりできる。mDNSを遮断できる者は競合防止そのものを無効化できる。協力的なホストという前提を、プロトコルが検証してくれるわけではない。

保存済みIDにも権限の境界がある。同じストリームでは以前の値を再利用することが求められ、安定したネットワークでの収束と衝突低減に役立つ。しかし第12版は、保持しているからといって前段の手順を一つも省略してはならないと明記した。オフライン中のネットワーク変化を取り込むため、再プローブ、再アナウンス、継続クエリ、防御が必要である。

Running-Code Primacyの観点では、信用すべき対象は「割当済み」という静止した印ではなく、実行された手順である。ID選択、アドレス生成、プローブ、アナウンス、監視、防御、停止、再選択を別々の証拠として扱う。永続値は過去の利用を示すが、現在の観測領域が過去と同じだとは示さない。

また、この仕組みはサービス発見ではない。草案は一つのPTRでアドレス利用を調整するが、ストリームのIPv6アドレスを受信者へ広告する方法を規定しない。DNS-SDの _udp サービスとTXTレコードは自然な選択肢として挙げられるだけだ。発見できても、受信者の参加、転送状態、パケット到達、アプリケーション処理までは証明しない。

複数サブネットへ広げる場合、PTRをサブネット間で配布する必要があり、mDNSリフレクターが例示される。草案はこの配布を継続的な研究課題とする。他サブネットへ転送するストリームには、リンクスコープではなくユニキャストプレフィックスベースのIPv6マルチキャストアドレスが必要だ。協力ホスト前提のため、グローバルインターネットには不向きとも明記される。

共通層は薄く保つべきである。相互に聞こえる参加者間のアドレス調整には役立つが、発見、参加、転送、配信、業務成果まで同じPTRに背負わせてはならない。後段にはそれぞれ別のレシートが要る。

運用台帳には、グループID、送信元インターフェース、導出したIPv6とEthernetアドレス、ストリーム識別子、保存世代を残す。さらに、プローブと継続クエリが覆ったインターフェースとサブネット、フィルタ、リフレクター到達性、分断世代、競合またはveto、停止した側、新IDと再プローブ結果を記録する。受信者参加、転送表、パケット、アプリケーション結果は別段階だ。

問うべきは「mDNSが動いていたか」ではない。「誰が答えられたのか」である。時間、経路、インターフェース、フィルタを記録しなければ、昨日の沈黙は、ネットワークが再び一つになった日に衝突として戻ってくる。

情報源