要約

  • RFC 9872 は、RFC 8781 の PREF64 Router Advertisement オプションから NAT64 合成プレフィックスを取得することを推奨する。
  • この方法は値だけでなく、有効期間、接続ネットワーク、上流の変換経路という文脈を保持する。

問題は最初の変換パケットより前に生じる。端末は IPv6 のみのネットワークに接続し、IPv4 の宛先を知っていても、ローカルで IPv6 アドレスを合成するには、そのネットワークの NAT64 が認識するプレフィックスが必要だ。別の環境で得た正しい形式の値では、到達不能な宛先を作り得る。

RFC 9872 はこの設定を接続時の情報に戻す。端末は RFC 8781 に従って Router Advertisement から PREF64 を先に取得し、NAT64 を運用する側もそこに情報を載せるべきだ。オプションがない、または端末が処理できない場合に限り、RFC 7050 の DNS 方式が予備となる。

有効期間とネットワーク範囲も運ぶ

RFC 8781 は PREF64 に Neighbor Discovery オプションタイプ 38 を割り当てる。オプションはプレフィックス、長さコード、8 秒単位の有効期間を含む。有効期間 0 は使用停止を示す。PREF64 がデフォルトルーターより先に失効すると経路だけが有効に見えるため、そのような設定は推奨されない。

端末は PREF64 を受信したネットワーク固有の情報として扱う。Provisioning Domain に対応する端末は該当する PvD と関連付けなければならない。非ゼロの複数プレフィックスから選択できる一方、複数の発見方式を無秩序に混ぜず、一つの情報源を選ぶことが推奨される。

マルチホーム環境では、プレフィックスと上流経路の関係が決定的になる。ある上流から得た PREF64 で合成した通信は、そのプレフィックスを扱う変換器へ送らなければならない。値だけを保存してインターフェースを失えば、正しい転送判断はできない。

DNS の観測点は別の場所へ移り得る

RFC 7050 は特別な IPv4 専用名を DNS64 リゾルバーへ問い合わせ、合成 AAAA 応答から PREF64 を抽出する。しかし暗号化 DNS、VPN、手動設定により、実際のリゾルバーがアクセス網の外へ移ることがある。遠隔リゾルバーがローカル NAT64 の情報を持つ保証はない。

DNS キャッシュは変更にも遅延を与える。DNS で得た値は TTL に従うが、Router Advertisement なら新しい値や有効期間 0 の撤回をリンク上で直接通知できる。

中心となる勧告は RFC 9872、オプション仕様は RFC 8781、DNS 方式は RFC 7050 にある。RFC 6052 と RFC 7915 はアドレス形式と変換を定義する。文書の発行自体は導入状況や変換器の正常性を示さない。

PREF64 の発見は、Router Advertisement の真正性、変換器への到達性、導入の事実、性能を証明しない。また RFC 6052 の Well-Known Prefix がすべての NAT64 ネットワークで有効だとも示さない。この五つには別の証拠が必要である。