要約

  • アプリは提案中の28ビット範囲からgroup IDを選び、IPv6とEthernetの宛先を作り、Ethernetアドレスを逆順のmDNS名にしてからprobe、announce、継続監視を行う。
  • ネットワーク機器は最初のアプリ識別ラベルに-vetoを付け、mDNSの比較で必ず勝つPTRレコードを発行できる。敗者は送信を止めて選び直す。
  • 文書はIETF Last Call中の草案であり、番号空間やドメイン名は未割り当てである。協調的な参加者を前提とし、拒否レコードの認証も定めない。

再起動した装置が、昨日使ったgroup IDを覚えていたとする。それでも送信を再開してよいわけではない。

これがdraft-ietf-pim-ipv6-zeroconf-assignment-12の考え方を最もよく表す。草案は2026年9月22日に公開され、10月6日までIETF Last Callにある。中央の割当サーバーなしにローカルなIPv6マルチキャストアドレスを決めるが、保存値を所有権としては扱わない。ネットワークは停止中にも変わるからだ。

草案はRFCではない。0x90000000-0x9FFFFFFF、eth-addr.arpa、9.3.3.3.3.eth-addr.arpa.はいずれもIANAへの要求で、DatatrackerのIANA状態もReview Neededである。DNS Directorateは第12版をReadyと評価したが、それは審査意見であって承認ではない。

選ぶのは数値、争うのはEthernet宛先

新しいストリームは、提案された範囲から28ビットのgroup IDを無作為に選ぶ。RFC 4489に従って送信元のinterface identifierと組み合わせ、link-local scopeのIPv6マルチキャストアドレスを作る。さらにRFC 2464の写像からEthernetマルチキャストアドレスを得る。

IPv6側で異なるアドレスでも、Ethernet側では同じ下位32ビットに畳み込まれ得る。そこで草案は、実際にNICやスイッチが扱うEthernet宛先を名前にする。33:33:9A:BC:DE:F0なら、各nibbleを逆順に並べた0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpaである。

このowner nameのPTRレコードは、アプリ固有の識別子とhost nameを指す。同一ホスト内の複数アプリも別々に主張できる。アプリはRFC 6762の手順で同名レコードをprobeし、同時競合で負ければ別のIDを選ぶ。競合がなければannounceし、問い合わせに答え、将来の衝突を見つけるcontinuous queryを開始する。その後で初めて送信できる。

許可を与えるのは返事ではなく、返事がないことである。これはimplicit availabilityだ。見えている範囲で異議が届かなかったことと、全関係者がprobeを受信したことは別である。

永続化は再利用のヒントにすぎない

group IDは永続ストレージに保存される。しかし再起動時にも、アドレス生成、probe、announce、continuous queryを省略できない。昨日の成功は昨日の観測範囲に属する。

オフラインの間にスイッチが交換され、分断が復旧し、別のアプリが同じIDを選んだかもしれない。新しいprobe transcriptがなければ、保存値はleaseでも権利でもない。

後から衝突が見つかれば、負けたアプリはまずストリームを止め、それから新しいIDを選んで保存値を書き換える。ホストのnetwork stackは、異なるIPv6宛先が同じEthernet宛先に写像された状況も監視できる。その場合もどちらかが移動する必要があるが、ホスト間の調整方法は規定されない。

-vetoは説明ではなく制御である

スイッチのアドレス表など、ネットワーク基盤が解消できない衝突を検出した場合、同じowner nameにveto PTRレコードを発行できる。元のPTRDNAMEの最初のアプリラベルへ-vetoを加える。

この5バイトには実行力がある。DNS RDATAの比較ではラベル長が先に現れ、長いvetoラベルが辞書順で後になる。そのためRFC 6762の競合解決では常にveto側が勝つ。草案が最初のラベルを58 octet以下に制限するのも、接尾辞の場所を確保するためだ。

基盤機器はprobeせずにvetoを送る。負けたアプリは停止し、再選択する。元PTRがgoodbyeまたは期限切れで無効になったら、veto発行者は5秒間問い合わせ、応答がなければ20〜120ミリ秒の乱数待ちを経てgoodbyeを送り、vetoを消す。

つまりゼロ設定には順序づけられた権限がある。アプリは提案する。peerは争う。基盤は上書きする。受信アプリは、それでもなおストリームが正しいかを判断する。

常勝のレコードは正しさを証明しない

この仕組みはmDNSと同じく、参加者が協調することを前提とする。悪意ある端末はprobeへ繰り返し衝突応答を返し、割当を妨害できる。稼働中のアドレスにvetoを発行し続ければ、送信停止と再選択を強制できる。逆にmDNSをfilterすれば、複数のアプリが同時に「誰も使っていない」と誤認する。

プロトコルは、veto発行者が本当にスイッチ表の衝突を観測したことを認証しない。announce成功も送信者の身元、コンテンツの権限、receiver join、アプリ処理を証明しない。

運用記録には、stream identity、group ID、source IID、IPv6/Ethernet宛先、PTR ownerとRDATA、probe、announce、continuous queryの世代、conflict/veto発行者、停止確認、置換ID、receiver移行、旧レコードの撤回を残すべきだ。対応するハードウェア事象のないvetoは、障害か攻撃として調べる必要がある。

分断が直っても履歴はすぐ一つにならない

continuous queryはpartition repair後の重複検出に役立つ。しかし低帯域を目指すmDNSでは、発見に相当な時間がかかり得る。分断中にも新規ストリームを作る環境では補助的な検出が必要だが、具体策は将来の課題とされた。

28ビットの乱数は、健全な一つの観測範囲で偶発衝突を減らす。filterされたpacketを見えるようにはせず、隔離中に成立した二つの履歴も統合しない。確率は発生頻度を変えるが、証拠の欠落を埋めない。

複数subnetへ拡張するならPTRレコードをreflectorなどで配布し、転送ストリームにはlink-localではなくunicast-prefix-basedのIPv6マルチキャストアドレスを使う。草案自身も、この協調モデルはglobal Internetには適さないとしている。

RFC 10019は二層の一意性、中央サーバーなしの動作、分断後の調停という要件を示したが、wire protocolや勝者を決めなかった。第12版は、その空白に具体的な手順と可視の拒否権を置いた。

Running-Code Primacyの読み方では、PTRは象徴的な主張、辞書順比較は制御、スイッチとNICは物理、受信アプリは結果である。どの層も他の層を代弁できない。設計の価値は権限を消したことではなく、重要な権限行使を記録可能なeventにしたことにある。

出典