要約

  • RFC 9872は、利用できるならRFC 8781のRouter AdvertisementからPREF64を取得し、RFC 7050のDNS方式は信号不在時と旧端末向けの補完にするよう勧告する。
  • マルチホーム端末では、プレフィックス、広告ルーター、送信元、次ホップ、有効期限、翻訳結果を一組の証拠として扱う必要がある。

障害の原因は不正なプレフィックスとは限らない。回線Aから得たPREF64でIPv6宛先を合成し、回線Bの送信元アドレスとデフォルトルーターを選べば、各値は正しくてもAのNAT64には到達しない。欠けたのは値ではなく所属である。

RFC 9872は、2025年9月に公開されたIETFのInformational文書として、この所属問題に運用上の優先順位を与えた。端末はRFC 8781のPREF64 RAオプションを先に試し、NAT64運用者はそれを広告すべきである。RFC 7050のDNS発見は、RAに情報がない場合や旧実装のために残る。

PREF64はIPv4宛先をIPv6アドレスへ埋め込むためのプレフィックスで、形式はRFC 6052が定める。これによりRFC 6147のローカルDNS64、RFC 6877の464XLAT/CLAT、RFC 8305のIPv4リテラル処理が可能になる。しかし、能力と到達可能な出口は別の事実だ。

RFC 7050はipv4only.arpa.への合成AAAA応答からプレフィックスを抽出し、RFC 8880はその名前の特別処理を定義する。ネットワーク提供DNS64以外を使う端末や、DNSだけを企業側へ切り替えるスプリットトンネルVPNでは、ローカルPREF64を得られない、または得た値をローカル経路へ帰属できない場合がある。

複数のISPがそれぞれDNS64とPREF64を提供すると、DNS応答には、どのプレフィックスがどの上流、IPv6送信元、デフォルトゲートウェイに対応するかを確実に示す手段がない。端末が複数の正解を一つの誤った経路に組み立てる余地が生まれる。

RAは第一ホップの文脈を保つ。RFC 4861のNeighbor Discoveryは、ルーターの存在とリンク情報をもともと広告する。RFC 8781はそこへPREF64と寿命を加える。端末は広告元ルーターとの対応を保持し、寿命ゼロで利用をやめられる。ただしRAは証明書ではない。広告元の信頼性、経路、翻訳器の稼働は別に検証する。

更新権限にも差がある。DNS方式はスタック設定後に往復を要し、結果はTTLまで残る。外部DNS64なら接続事業者がTTLを制御できないこともある。RAなら新しい広告で即時に更新または撤回できる。重要なのは起動速度より、誤った状態を誰が止められるかだ。

DNS応答の偽装面を外しても、リスクは第一ホップへ移る。RFC 6105のRA-Guardは関連する防御だが、許可された広告の内容までは保証しない。RFC 9463による暗号化リゾルバーの指定も、DNS交換を保護するだけでPREF64と出口を自動的に結び付けない。

移行は端末台帳に従うべきである。RFC 8781対応端末はRAを優先する一方、旧端末にはRFC 7050が必要になり得る。さらにRFC 9872は、モバイルOSが対応済みでも、モバイル網設備がRAへオプションを入れられない場合を認める。公式記録は公開を示すが、特定網の実装を示さない。

Heng LuのRunning-Code Primacyに従えば、最終判断は経路とアプリケーション結果の再現可能な証拠に置く。その最小初期仕様は共通信号を細くし、採用をローカルに残す。恒久的dual-stack税という指摘は、二つの発見方式、第一ホップ防御、翻訳器、監視を同時に維持する費用を意思決定者へ戻す。

RFC 9872の価値は、発見を完了判定にしない点にある。プレフィックスの出所と期限を保持し、選んだ出口、翻訳器、アプリケーションの結果まで別々に確認して初めて通信事実になる。

情報源