IPv6 における NAT66 再考 – ULA、GUA、Prefix 設計主権、IPv4 NAT の設計抽象

IPv6 では長らく「NAT は不要」と説明されてきました。IPv6 には十分なアドレス空間があり、各端末に GUA を割り当て、NAT なしで end-to-end の通信を行うことが理想とされてきたためです。

この理想は間違っていません。十分な prefix と経路設計の権限を持つネットワークでは、IPv6 は NAT なしで設計した方がきれいです。

しかし、企業ネットワーク、自宅データセンター、小規模拠点、ISP 依存の環境では、この理想だけでは処理できない問題があります。それは、内部ネットワークの prefix 設計主権 です。

IPv6 の NAT66 を考えるとき、本質は「NAT が良いか悪いか」ではありません。問題は、内部 prefix 設計を誰が支配するのかです。

この記事の主張

この記事の主張は、NAT66 を IPv6 の標準解にすることではありません。

主張したいのは、prefix 設計主権を持たない環境では、内部設計を外部 prefix から切り離すための境界抽象が必要になる ということです。

• prefix 設計主権を持つ環境では、GUA-only routing が自然であり、NAT66 は基本的に不要です。
• prefix 設計主権を持たない環境では、ULA を内部正本にし、外部到達性を別の出口機構で処理する設計が現実的になります。
• その出口機構の候補として、NAT66、NPTv6、Proxy、ULA + GUA 併用があります。
• IPv4 NAT が持っていた価値は、単なるアドレス節約ではなく、内部空間と外部空間を分離する設計抽象でした。

IPv6 の理想論

IPv6 の理想は明快です。

• 各端末に GUA を割り当てる。
• NAT を使わない。
• routing によって到達性を確保する。
• 通信制御は firewall、ACL、routing policy、identity、host policy で行う。

この考え方は、通信モデルとして非常にきれいです。NAT によるアドレス変換がないため、経路が透明になり、ログの解釈も単純になります。ポート変換や stateful NAT による副作用も避けられます。

特に、キャリア網、ISP バックボーン、クラウド事業者、大規模データセンター、PI prefix を持つ組織では、この理想は成立しやすいです。十分な prefix を持ち、自分で経路設計を制御できるため、各 L3 セグメントに GUA /64 を正しく割り当てればよいからです。

このような環境では、NAT66 は基本的に不要です。むしろ NAT66 を入れることで、IPv6 の透明な routing model を壊す可能性があります。

問題は prefix 設計主権を持たない側にある

一方で、すべてのネットワークが自由に prefix を設計できるわけではありません。

一般家庭、自宅データセンター、小規模企業、ISP 依存の拠点ネットワークでは、次のような制約が発生します。

制約	設計上の問題
ISP から十分な prefix が委任される保証がない	各 L3 セグメントへ /64 を割り当てられない
/64 しか払い出されない場合がある	複数セグメント設計と矛盾する
prefix が動的に変わる場合がある	内部アドレス設計が不安定になる
上位ルーターを制御できない場合がある	正しい routing / PD 設計ができない
PI prefix を持てない	provider prefix への依存が残る
内部に複数の L3 セグメントが存在する	単一 LAN 前提の RA / SLAAC では足りない

この状態で GUA-only 設計を採用すると、内部ネットワーク設計が ISP の prefix に依存します。

回線契約を変える。ISP を変える。上位ルーターを変える。delegated prefix が変わる。そのたびに、内部で使用している IPv6 address、DNS、ACL、監視、IaC、ログ分析、許可リストが影響を受けます。

これは設計として重いです。

IPv4 NAT は単なるアドレス節約ではなかった

IPv4 NAT は、一般にはアドレス枯渇対策として説明されます。それは事実です。

しかし、企業ネットワーク設計の観点では、IPv4 NAT はそれ以上の価値を持っていました。

IPv4 NAT が提供していたもの	意味
内部アドレス空間の自由設計	RFC1918 により、組織が内部 IP を自由に設計できる
provider 依存の遮断	ISP 変更が内部設計へ波及しにくい
境界制御点の集約	NAT / FW / Proxy / LB に制御を集められる
公開点の限定	外部公開する対象を明確にできる
監査点の集約	出口ログ、FW ログ、Proxy ログを集約できる
責任分界の明確化	内部、境界、外部を分けて扱える

つまり、IPv4 NAT は単なる通信変換ではなく、内部空間と外部空間を分離する設計抽象でした。

この抽象は、アドレスが潤沢な IPv6 になっても消えません。なぜなら、問題はアドレス数ではなく、組織が内部ネットワークを自由に設計できるかどうかだからです。

ULA の存在が示していること

IPv6 には ULA があります。

ULA は、global Internet で routing されることを期待しない local address です。IPv4 の RFC1918 と似た位置づけを持ちます。

ULA が存在する時点で、IPv6 は内部専用アドレス空間を認めています。内部専用アドレス空間を認める以上、外部到達性との接続問題が発生します。

ULA を内部ネットワークの正本として使う場合、外部通信には次のいずれかが必要になります。

方式	内容
ULA + GUA 併用	内部通信は ULA、外部通信は GUA
ULA + NAT66	内部 ULA を外部 GUA へ stateful に変換
ULA + NPTv6	内部 prefix と外部 prefix を 1:1 で変換
ULA + Proxy	HTTP / HTTPS などをアプリ層で中継

ここで重要なのは、ULA を本気で内部正本にする場合、NAT66 / NPTv6 / Proxy 的な出口機構が自然に設計候補になるという点です。

ULA + GUA 併用は最初に検討すべき解決策

ULA と GUA を両方持たせる設計は、有力な解決策です。

内部通信は ULA を使い、外部通信は GUA を使う。内部 DNS、監視、ACL、認証基盤、IaC は ULA を正本にする。一方、Internet への通信は GUA を使う。

この構成では、内部設計と外部到達性を分離できます。

ただし、この設計が成立するには条件があります。各 L3 セグメントに GUA /64 を割り当てられるだけの delegated prefix が必要です。

ISP から /56 や /48 が来る場合、各 VLAN や L3 セグメントに /64 を割り当てられます。この場合、ULA + GUA 併用はかなりきれいに成立します。

/64 しか来ない場合、L3 分離と矛盾する

問題は、ISP や上位ルーターから /64 しか来ない場合です。

IPv6 の RA / SLAAC は、基本的に link ごとに /64 を配る前提で使われます。複数の L3 セグメントがある場合、それぞれの link に /64 が必要です。

しかし、上位から 1 個の /64 しか来ない場合、mgmt、core、int、ext、IoT、guest といった複数の L3 セグメントへ正しく GUA を割ることができません。

この状態で GUA を全端末に配ろうとすると、1 個の /64 を複数の L3 セグメントへ無理に延ばすことになります。それは、L3 分離されたネットワークを作っているにもかかわらず、実質的には単一 link を広げるような構造になります。

RA は「その link で使う prefix」を通知する仕組みであって、複数 L3 セグメントへの prefix 分配問題を解決する仕組みではありません。

NDP proxy は根本解ではない

/64 しかない状態で複数セグメントに IPv6 を通そうとすると、NDP proxy が候補に出てくることがあります。

しかし、NDP proxy は本質的には、同一 link 内の Neighbor Discovery を L3 境界越しに代理応答する仕組みです。

これは、prefix が足りないという本質問題を、Neighbor Discovery の代理応答で隠しているだけです。

問題	内容
prefix 設計が壊れる	link ごとに /64 を割るという前提が崩れる
責任分界が曖昧になる	L2 的な近隣探索と L3 境界が混ざる
障害解析が複雑化する	NDP、RA、routing、proxy の問題が絡む
セキュリティ制御が歪む	L3 分離したいのに同一 link 的な扱いが入る
IaC 化しづらい	設計資産として扱いにくい状態依存が増える

複雑な L3 分離環境において、NDP proxy を設計の正本に置くのは不自然です。

NAT66 / NPTv6 / Proxy を分けて考える

ここで NAT66 と呼ばれるものは、議論の中で混ざりやすいです。実際の設計では、stateful NAT66、NPTv6、Proxy を分けて考えた方がよいです。

方式	向いている条件	注意点
stateful NAT66	内部 ULA を出口で集約し、外部 GUA へ変換したい場合	NAT 状態、ログ、戻り通信、トラブルシュートを設計する必要がある
NPTv6	内部 prefix と外部 prefix を 1:1 に近い形で変換したい場合	prefix 長や checksum neutral など、純粋な NAT66 とは違う制約がある
Proxy	HTTP / HTTPS など、アプリケーション単位で出口を制御したい場合	対象プロトコルが限定される
ULA + GUA 併用	各 L3 セグメントに十分な GUA /64 を配れる場合	十分な delegated prefix と安定した配布設計が必要

つまり、この記事の主張は「常に stateful NAT66 を使うべき」という話ではありません。内部設計主権を守るために、境界変換または境界中継という設計抽象が必要になる、という話です。

NAT66 に帰結する条件

ここまでの条件を固定すると、NAT66 に帰結する理由は明確です。

前提	帰結
内部 L3 分離を維持したい	各セグメントに安定 prefix が必要
内部 IP 設計を安定させたい	provider prefix に依存できない
十分な GUA prefix が来る保証がない	GUA-only は不安定
/64 しか来ない場合がある	RA / SLAAC だけでは複数 L3 セグメントを扱えない
NDP proxy は設計として不自然	別の出口機構が必要
ULA は内部正本として使える	内部設計主権を確保できる
ULA はそのまま Internet に出られない	NAT66 / NPTv6 / Proxy が必要

この条件では、内部は ULA で自由に設計し、境界で NAT66 により外部 GUA へ変換する構成が自然になります。

NAT66 を「IP を隠すための仕組み」として見ると議論がずれます。ここでの NAT66 は、内部設計を外部 prefix から切り離すための 境界変換 です。

NAT66 が不要な環境

一方で、NAT66 が常に必要という話ではありません。

prefix 設計主権を持つ側では、NAT66 は不要です。

環境	NAT66 の必要性
キャリア網	低い
ISP バックボーン	低い
クラウド事業者内部	低い
大規模データセンター	低い
PI prefix を持つ組織	低い
十分な固定 PD を受けられる企業	低〜中
一般家庭・自宅データセンター	中〜高
/64 しか来ない環境	高い
ISP prefix が変わる環境	高い
内部 ULA を正本にしたい環境	高い

自由に prefix を設計できる側では、IPv6 の GUA-only routing は合理的です。NAT なしで設計した方が、経路もログも通信モデルもきれいです。

問題は、prefix 設計主権を持たない側にあります。

IPv6 が迷走して見える理由

IPv6 が迷走して見える理由は、GUA-only の理想と、ULA-based internal model の現実が同居しているからです。

IPv6 の理想は、各端末に GUA を割り当て、NAT なしで routing し、制御は firewall / policy で行うことです。

しかし、現実の組織ネットワークでは、内部アドレスを自由に設計したい、provider prefix から独立したい、L3 分離を維持したい、境界制御点を集約したい、監査点を集約したい、ISP 変更の影響を局所化したい、という要件があります。

そのため ULA が必要になります。ULA を使うと、外部到達には NAT66 / NPTv6 / Proxy / GUA 併用が必要になります。

結果として、IPv6 は NAT を否定して始まったにもかかわらず、現実の運用では NAT66 / NPTv6 / NAT64 / Proxy 的な境界機構を抱え込んでいます。

ここに、IPv6 が迷走して見える理由があります。

結論

IPv6 の GUA-only 理想は、通信モデルとしては正しいです。十分な prefix と経路設計主権を持つネットワークでは、NAT なしの IPv6 は自然です。

しかし、企業ネットワーク、自宅データセンター、小規模拠点、ISP 依存環境では、問題はアドレス数ではなく 内部ネットワーク設計主権 です。

内部 IP 設計を外部 provider prefix に依存させると、ISP 変更、回線変更、prefix 変更が内部構成全体へ波及します。これは設計として扱いにくいです。

そのため、内部は ULA を正本として設計し、外部到達は NAT66 / NPTv6 / Proxy / GUA 併用で処理する構成が現実解になります。

prefix 設計主権	適した IPv6 設計
持っている側	GUA-only routing。NAT は基本的に不要
持っていない側	ULA を内部正本にし、NAT66 / NPTv6 / Proxy を出口機構にする

IPv4 NAT は、単なるアドレス節約技術ではありませんでした。

それは、内部空間と外部空間を分離し、内部設計主権、境界集約、監査点集約、責任分界を提供する優れた設計抽象でした。

IPv6 でも、この要件は消えていません。

そのため NAT66 は、IPv6 の理想に対する敗北ではありません。prefix 設計主権を持たない環境で、L3 分離と内部設計を維持するための現実的な境界変換です。