IPv6 移行技術：デュアルスタック・トンネル・変換
IPv4とIPv6を同居させる移行技術が一望できます。デュアルスタック・6rdトンネル・NAT64/464XLATの内部動作と、どの状況でどれを選ぶかを原理から整理します。
- 1.移行戦略は大きく3系統：両方を並走させる デュアルスタック、IPv4網を越えてIPv6を運ぶ トンネル（6in4/6rd）、IPv6専用網からIPv4へ橋渡しする 変換（NAT64/DNS64・464XLAT）。
- 2.NAT64+DNS64 はIPv6専用クライアントをIPv4サーバーへ届けるが、IPv4リテラルやIPv4専用ソケットを使うアプリは壊れる。464XLAT はその穴を端末側のCLATで埋める。
- 3.デュアルスタックは互換性が高い反面、IPv4を温存し2系統を二重運用するコストが残る。最終形はIPv6単一スタックで、変換技術はそこへ至る橋渡し。
なぜ「スイッチ一発」では切り替えられないのか
IPv6 は IPv4 と互換性がありません。IPv6 だけのホストは、そのままでは IPv4 だけのサーバーと通信できず、その逆も成り立ちません。全世界のホストとコンテンツを同時に切り替えることは不可能なので、両者が何年も共存することを前提に「移行技術」が設計されました。手段は大きく3系統です。デュアルスタック（両方を喋る）、トンネル（一方の網にもう一方を内包して運ぶ）、変換（プロトコルそのものを翻訳する）。それぞれ解決する問題と限界が違います。アドレス体系そのものは IPv6 のアドレス体系と近隣探索 を前提とします。
デュアルスタック：両方を同時に喋る
最も素直な方式が デュアルスタック です。ホストとルータが IPv4 と IPv6 の両方のスタックを実装し、それぞれ独立したアドレス・ルーティングテーブルを持ちます。通信相手が IPv6 を持てば IPv6 で、IPv4 しか持たなければ IPv4 で話します。
どちらを選ぶかを実際に左右するのは 名前解決と接続試行のロジック です。クライアントは DNS に AAAA（IPv6）と A（IPv4）の両方を問い合わせ、結果に基づいて接続先を選びます。素朴に「AAAA を最優先」とすると、IPv6 経路が壊れているとき長いタイムアウトを待たされます。これを避けるのが Happy Eyeballs（RFC 8305） で、IPv6 と IPv4 へほぼ同時に接続を試み、先に確立した方を採用します。DNS 側の挙動は DNS 名前解決の内部動作 と合わせて捉えると分かりやすくなります。
両方が通る限り互換性の問題は起きません。ただし IPv4 を温存したままなので、グローバル IPv4 アドレスの枯渇は解決せず、2系統のアドレッシング・ファイアウォール・監視を二重に運用するコストが残ります。最終目標である IPv6 単一化には到達していない、という割り切りが要ります。
トンネル：IPv4 網の上で IPv6 を運ぶ
移行初期は IPv6 対応の島が IPv4 の海に点在する状態でした。島と島をつなぐのが トンネル で、IPv6 パケットを IPv4 パケットの ペイロードとしてカプセル化して運びます。考え方の土台は プロトコルのカプセル化 と同じです。
- 6in4（RFC 4213）：IPv6 パケットを IPv4 ヘッダ（プロトコル番号 41）で包む静的トンネル。両端のアドレスを手で設定する。確実だが拠点が増えるとフルメッシュ設定が破綻する。
- 6rd（IPv6 Rapid Deployment, RFC 5969）：ISP が自網内で IPv6 を素早く配るための方式。加入者の IPv4 アドレスを 6rd プレフィックス に埋め込むことで、宛先 IPv6 から対向の IPv4 終端アドレスを 計算で導出でき、トンネルを動的に張れる。6to4 が使った公開アンカー
2002::/16の不安定さを、ISP 管理下のプレフィックスに置き換えて実用化した。
トンネルの本質的な弱点は MTU です。外側 IPv4 ヘッダのぶん有効ペイロードが縮むため、考慮しないと過大なパケットが途中で落ちます。Path MTU Discovery が ICMP フィルタで効かないと「特定サイトだけ開かない」典型障害になります。詳細は MTU とフラグメンテーション を参照してください。
6in4/6rd が運ぶのは IPv6 トラフィックです。加入者にグローバル IPv4 を配れない枯渇問題そのものは解決しません。そこで近年の主役は、IPv4 を捨てて IPv6 専用網に寄せる「変換」系へ移っています。
変換：IPv6 専用網から IPv4 へ橋渡しする
加入者網を IPv6 のみで組み、IPv4 通信は変換で吸収する——これがモバイル網などの現実的な最終構成です。中心が NAT64 と DNS64 の組です。
NAT64 + DNS64
NAT64（RFC 6146） は、IPv6 専用クライアントと IPv4 サーバーの間でアドレスとプロトコルを変換するステートフルな装置です。IPv4 宛先 203.0.113.9 は、既知プレフィックス（標準は 64:ff9b::/96）に埋め込んだ IPv6 アドレス 64:ff9b::203.0.113.9 として表現されます。クライアントがこの IPv6 宛てに送ると、NAT64 が IPv4 パケットへ翻訳して送り出し、戻りも逆変換します。動作の骨格は NAT（アドレス変換） のステートフル変換と同型です。
問題は「クライアントはどうやってその合成 IPv6 を知るか」です。ここで DNS64（RFC 6147） が働きます。IPv6 専用クライアントが AAAA を問い合わせたとき、相手に IPv6（AAAA）が無ければ、DNS64 リゾルバが A レコードの IPv4 アドレスを NAT64 プレフィックスに埋め込んだ 合成 AAAA をその場で生成して返します。クライアントは普通の IPv6 通信をしているつもりで、実体は NAT64 経由で IPv4 に届きます。
| 役割 | コンポーネント | やること |
|---|---|---|
| 翻訳 | NAT64 | IPv6↔IPv4 のヘッダ・アドレスをステートフル変換する |
| 発見 | DNS64 | AAAA不在時にAを合成AAAAへ変換し、変換経路へ誘導する |
| 前提 | クライアント | IPv6のみ。普通のAAAA問い合わせと通常のIPv6通信だけを行う |
DNS64 は名前解決を横取りする方式なので、DNS を介さない通信を救えません。具体的には、URL に IPv4 を直書きする IPv4 リテラル（例 http://203.0.113.9/）、IPv4 アドレスを引数に取る古い API、IPv4 専用ソケットを直に開くアプリが該当します。さらに DNS64 は応答を改変するため、署名検証する DNSSEC と本質的に衝突します。
464XLAT：端末側で穴を塞ぐ
NAT64/DNS64 の弱点（IPv4 リテラルや IPv4 専用アプリ）を埋めるのが 464XLAT（RFC 6877） です。発想は「翻訳を2回行い、端末から見ると IPv4 が生きているように見せる」ことです。
- CLAT（Customer-side translator）：端末側にあり、アプリが出した IPv4 パケットをステートレスに IPv6 へ変換する（IPv4→IPv6）。
- PLAT（Provider-side translator）：網側にあり、その IPv6 を再び IPv4 へ戻す。実体は NAT64（IPv6→IPv4）。
アプリは CLAT 専用に確保された IPv4 範囲（464XLAT では 192.0.0.0/29＝RFC 7335 の IPv4 サービス継続プレフィックス）を使い、CLAT が IPv6 化して網へ流し、PLAT=NAT64 が IPv4 化して外へ出します。これにより、AAAA を引けない IPv4 リテラルアプリでも CLAT がローカルで IPv4 を受けるため動作します。Android のモバイルデータが IPv6 専用網で IPv4 アプリを問題なく動かせるのは、この CLAT が端末に組み込まれているからです。
| 方式 | クライアント前提 | IPv4リテラル/IPv4専用アプリ | 状態管理 |
|---|---|---|---|
| デュアルスタック | IPv4+IPv6 両方 | そのまま動く | なし（各々独立） |
| 6rd トンネル | IPv6（IPv4網内） | IPv6通信のみ対象 | ステートレス導出 |
| NAT64+DNS64 | IPv6のみ | 壊れる（DNS依存） | NAT64がステートフル |
| 464XLAT | IPv6のみ | CLATが救済し動く | CLATステートレス＋PLATステートフル |
どれを選ぶか
選択は「自網で IPv4 をどこまで残せるか」で決まります。十分なグローバル IPv4 が確保でき互換性を最優先するなら デュアルスタック。IPv4 アクセス網しか無いが IPv6 サービスを早く出したい ISP なら 6rd。スマホ網のように加入者を IPv6 単一で運用しつつ IPv4 到達性も保証したいなら 464XLAT（基盤として NAT64/DNS64）。共通する到達点は IPv6 単一スタックで、変換技術はそこへ至る期間限定の橋です。NAT 越え一般の難しさは NAT 越えとホールパンチング も合わせて捉えると、変換系の制約が立体的に見えてきます。
「デュアルスタック＝両方喋る・互換性高いがIPv4枯渇は未解決」「トンネル＝カプセル化でIPv6を運ぶ・MTU注意」「NAT64＝ステートフル翻訳・DNS64が合成AAAAで誘導」「464XLAT＝CLAT(端末/ステートレス)＋PLAT(網/NAT64)でIPv4リテラルを救済」。この対応関係が定番の出題ポイントです。
つまずきポイント
- DNS64 は DNSSEC と相性が悪い：応答を改変するため、検証可能なリゾルバとは別系統が要る。
- IPv4 リテラルは NAT64 単独では救えない：救うには端末側 CLAT（464XLAT）が必要。
- トンネルは MTU を必ず詰める：ICMP フィルタで PMTUD が死ぬと「一部サイトだけ開かない」障害になる。
- デュアルスタックは“終わり”ではない：IPv4 を残す限り運用は二重化したまま。最終形は IPv6 単一であることを忘れない。
# DNS64 が合成した AAAA か確認（64:ff9b:: で始まれば NAT64 経由）
dig AAAA example.com
# 端末に CLAT 用インターフェース/経路があるか（Linux の例）
ip -4 addr show
ip -6 route show
# NAT64 プレフィックスを RA/PCP から学習しているか確認（RFC 7050 の検出名）
dig AAAA ipv4only.arpa
ネットワーク Article
IPv6 移行技術：デュアルスタック・トンネル・変換を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
IPv6
比較で見る軸
難易度: advanced / カテゴリ: ネットワーク / タグ数: 5
導入後に効く点
NAT64+DNS64 はIPv6専用クライアントをIPv4サーバーへ届けるが、IPv4リテラルやIPv4専用ソケットを使うアプリは壊れる。464XLAT はその穴を端末側のCLATで埋める。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- ネットワーク
- タグ数
- 5
判断チェックリスト
- 自社の用途が「IPv6 / 移行技術」に近いか確認する。
- 強みである「移行戦略は大きく3系統：両方を並走させる デュアルスタック、IPv4網を越えてIPv6を運ぶ トンネル（6in4/6rd）、IPv6専用網からIPv4へ橋渡しする 変換（NAT64/DNS64・464XLAT）。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。