Summary

  • IETF草案の第10版は、NAT64の周知プレフィックスで私設・共有IPv4アドレスを表すことを提案した。2026年11月23日までIESGの最終意見募集が続く。
  • 管理されていない端末側のCLATは原則として変換し、管理下のPLATには無効化できる設定を求める。既存の遮断動作は更新時に維持するよう勧めている。
  • 一つのプレフィックスは設計を簡単にする。その代わり、どの端末がどの私設サービスへ進めるかを経路とアクセス規則で示す必要がある。

社内サーバーへの通信を守っているのは、必ずしもファイアウォールとは限らない。RFC 6052には、NAT64の周知プレフィックスに非グローバルなIPv4アドレスを埋め込んではならず、変換器はそのパケットを捨てなければならないと書かれている。この一文を頼りに、明示的な遮断規則を置かずに済ませた運用現場もある。IETFは今、その一文を緩めようとしている。

旧規則が警戒した曖昧さは現実にある。RFC 1918の私設アドレスは組織ごとに再利用できる。二つの拠点に同じ 10.0.0.1 があっても、それぞれ別の機械だ。周知のIPv6プレフィックスが付いたからといって、どちらの機械を指すかは決まらない。だが一律破棄の代償もある。IPv6専用端末が必要な社内IPv4サービスに届かず、別の変換プレフィックスや特別なDNS設定に頼ることになる。RFC 6598の共有アドレスもこの議論に入る。

二本立てでは宛先を選べない

公開IPv4には周知プレフィックス、社内IPv4にはネットワーク固有プレフィックス。設計図では整然としている。DNS64が応答を合成するなら、サーバー側で宛先ごとに使い分けられる。ところがアプリケーションがIPv4アドレスを直接指定し、CLATが端末内でIPv6宛先を合成すると、DNS64の選択は通らない。

草案によれば、広く使われるRFC 7050とRFC 8781の仕組みはプレフィックスを知らせても、「このIPv4範囲にはこのプレフィックス」という対応表は知らせない。端末が二つとも覚えれば、同じ公開IPv4宛てに二種類のIPv6宛先を作り得る。アクセス制御、監視、障害解析は二本の経路を追う羽目になる。RFC 8215のローカル用プレフィックスを併用しても、選択表は生まれない。

そこで第10版はRFC 6052の禁止そのものを変える。周知プレフィックスで非グローバルIPv4を表してよい。管理されていないCLATは既定で変換する。管理下のPLATは設定で止めない限り変換し、止める設定手段を備える。標準が一括して門前払いしていた判断が、各ネットワークの設定へ移る。

ソフトの更新で通行証を配らない

草案は重要な運用上の癖を認める。RFC 6052に従うPLATの破棄を、私設網の暗黙の防壁として使っている管理者がいる。そのため既存の管理下機器では、更新だけで既定の破棄を変えないよう勧める。開放するなら管理者が設定を選び、ACL、ファイアウォール、NATフィルターで許可する送信元と宛先を定める。戻り経路まで含めて確認しなければならない。

同じ番号の私設アドレスが複数の事業部にある場合、変換に成功しても誤った事業部へ運ぶことができる。機器はパケットの形式を直せるが、サービスの所有者や利用者の権限までは判定しない。技術的な到達可能性と、組織として認めたアクセスは別の台帳に載るべきだ。

草案は既存CLATの振る舞いがばらつくとも記す。旧規則どおり捨てる実装も、すでに変換する実装もある。ただし台数は示さない。各運用者に必要な調査は具体的だ。端末がどこで宛先を合成するか、管理下の翻訳器が何を捨てるか、各私設アドレスがどの経路領域で何のサービスを指すか。欠けた一行は、規格文書から補充できない。

第10版はまだ意見募集段階で、発効したRFCではない。それでも争点は明快だ。IPv6移行を楽にする一つのプレフィックスは、私設網への扉も同じ経路に置く。扉を開けるなら、設定した人の名前と理由が残る形で開けるべきだ。

IETF草案 · RFC 6052 · RFC 1918 · RFC 6598