IPv4/IPv6 変換技術の重要性と価値

IPv4/IPv6 変換技術は、IPv4 から IPv6 へ移行する過程で必要になる技術です。以前の私は、これを「あくまで一時的な移行技術」と見ていて、学ぶモチベーションがあまり高くありませんでした。

理由は単純です。変換技術は複雑です。NAT64、DNS64、SIIT、464XLAT、MAP-T、MAP-E など似た名前の技術が多く、それぞれ適用範囲も違います。しかも IPv6 は IPv4 と互換性を持つように設計されたものではないため、変換はどうしても IP 層の外側や境界で追加の仕組みとして扱う必要があります。

ただ、現在の観点では少し見方が変わりました。IPv4/IPv6 変換技術は、単なる一時しのぎではありません。IPv4 が長く残り続ける以上、IPv6-only network、IPv4-only service、dual stack network の間をつなぐ境界技術として、かなり長期間必要になると考えています。

この記事の結論

IPv4/IPv6 変換技術は、できれば避けたい複雑な技術です。しかし、ネットワーク設計では避けて通れない技術でもあります。

• 理想は end-to-end の dual stack です。IPv4 と IPv6 をそれぞれ純粋な IP 通信として扱えるためです。
• 現実には、すべての端末、サーバー、アプリケーション、回線、クラウド、拠点が同時に dual stack へ移行するわけではありません。
• そのため、IPv6-only 側から IPv4-only 資産へ到達する技術、IPv4 over IPv6 の共有技術、IPv4/IPv6 の stateless translation が必要になります。
• 変換技術は、IPv6 移行の失敗を意味するものではなく、IPv4 が残り続ける現実に対する境界設計です。

なぜ変換技術を学ぶ必要があるのか

IPv6 が普及しても、IPv4 は簡単には消えません。既存システム、古いアプリケーション、運用監視、クラウドサービス、組み込み機器、閉域網、家庭用機器など、IPv4 前提の資産は非常に多いからです。

一方で、アクセス網、モバイル網、クラウド内部、Kubernetes、サービス基盤では、IPv6-only や IPv6 優先の設計が現実味を帯びています。

このとき、問題は「IPv6 を知っているか」だけではありません。IPv4-only と IPv6-only の境界で、どの変換方式を使うべきかを理解していないと、設計会話ができません。

状況	必要になる考え方
IPv6-only client から IPv4-only server へ接続したい	NAT64 / DNS64 / 464XLAT
IPv4 service を IPv6 network 上で運びたい	MAP-E / MAP-T / DS-Lite などの IPv4 over IPv6
IPv4 address と IPv6 address を規則的に対応させたい	SIIT / stateless translation
dual stack を維持できる環境	変換より dual stack を優先しやすい
IPv4 address を共有したい	port sharing や CGN 系の設計が必要

理想は dual stack だが、現実は混在する

私見としては、可能であれば end-to-end の dual stack が最も理解しやすいです。IPv4 は IPv4 として、IPv6 は IPv6 として通信するため、変換による副作用が少なくなります。

しかし、dual stack は万能ではありません。すべての network、server、application、security policy、monitoring、load balancer、DNS、firewall が IPv4/IPv6 の両方に対応している必要があります。

また、IPv4 address の枯渇や運用コストを考えると、IPv6-only network を作り、必要なときだけ IPv4 へ到達させる構成も合理的になります。

つまり、dual stack は理想的な移行形態ですが、変換技術を不要にするものではありません。

代表的な IPv4/IPv6 変換・共存技術

IPv4/IPv6 変換技術は、名前だけで理解しようとすると混乱します。まずは、何を変換する技術なのかで分類した方が分かりやすいです。

技術	大まかな位置づけ	代表 RFC
SIIT	IPv4 packet と IPv6 packet を stateless に変換する基本技術	RFC 6145
Stateful NAT64	IPv6 client から IPv4 server へ到達するための stateful translation	RFC 6146
DNS64	IPv4-only name に対して IPv6 用の合成 AAAA record を返す	RFC 6147
464XLAT	CLAT と PLAT を組み合わせ、IPv6-only network から IPv4 application を動かす	RFC 6877
MAP-E	IPv4 over IPv6 encapsulation と port sharing	RFC 7597
MAP-T	IPv4/IPv6 translation と port sharing	RFC 7599
DS-Lite	IPv4 packet を IPv6 tunnel で運び、AFTR 側で NAT する	RFC 6333

SIIT

SIIT は、IPv4 packet と IPv6 packet を stateless に変換する基本的な技術です。以前の記事では RFC 番号や変換内容をかなり雑に理解していましたが、整理すると SIIT は RFC 6145 の stateless IP/ICMP translation です。

SIIT は state を持たないため、変換器が通信ごとのセッション状態を管理しません。その分、address mapping の設計が重要になります。

• state を持たないため、変換器の状態管理に依存しにくい
• IPv4 address と IPv6 address の対応関係を設計する必要がある
• ICMP / ICMPv6 の変換も含めて考える必要がある
• 単独で万能というより、他の方式の部品として理解すると分かりやすい

Stateful NAT64 と DNS64

Stateful NAT64 は、IPv6 client から IPv4 server へ接続するための代表的な変換技術です。IPv6 側の通信を NAT64 translator が IPv4 側へ変換し、戻り通信を state に基づいて戻します。

DNS64 は、IPv4-only の名前に対して合成 AAAA record を返す仕組みです。IPv6 client は合成された IPv6 address へ接続し、その宛先を NAT64 translator が IPv4 address へ変換します。

要素	役割
DNS64	IPv4-only host に対する合成 AAAA record を作る
NAT64	IPv6 packet と IPv4 packet を stateful に変換する
IPv6 client	IPv6-only でも IPv4-only server へ到達できる
IPv4 server	IPv6 を意識せずに既存 IPv4 service として動く

注意点は、NAT64 は主に IPv6 client から IPv4 server へ到達するための技術だということです。IPv4 側から IPv6-only client へ自由に inbound 接続する仕組みではありません。

464XLAT

464XLAT は、IPv6-only network 上で IPv4 application を動かすための技術です。mobile network などで重要な位置づけを持ちます。

構成要素としては、client 側の CLAT と network 側の PLAT があります。CLAT は client 側で IPv4 packet を IPv6 packet へ stateless に変換し、PLAT は NAT64 として IPv6 と IPv4 の境界変換を行います。

要素	役割
CLAT	端末または CPE 側で IPv4 packet を IPv6 側へ変換する
PLAT	network 側で NAT64 として IPv4 Internet へ接続する
IPv4 application	IPv6-only network 上でも IPv4 を使っているように動作できる

464XLAT の価値は、IPv6-only network を作りつつ、IPv4 前提の application を動かせる点です。IPv6 移行において、これはかなり現実的な妥協点になります。

MAP-E と MAP-T

MAP-E と MAP-T は、IPv6 network 上で IPv4 service を提供するための方式です。どちらも IPv4 address や port set を複数ユーザーで共有する発想を持ちます。

方式	特徴
MAP-E	IPv4 packet を IPv6 packet に encapsulate する。変換ではなく tunnel に近い
MAP-T	IPv4 packet と IPv6 packet を stateless に translate する

以前の記事では MAP-T を stateful として整理していましたが、MAP-T は stateless mapping を前提にした方式です。ここは重要な修正点です。

MAP-E / MAP-T は、家庭向け ISP の IPv4 over IPv6 サービスや、IPv4 address 共有の文脈で理解すると分かりやすいです。

DS-Lite

DS-Lite は、IPv4 packet を IPv6 tunnel で運び、事業者側の AFTR で IPv4 NAT を行う方式です。利用者側では B4 element、事業者側では AFTR が登場します。

MAP-E / MAP-T と同じく、IPv6 access network 上で IPv4 connectivity を提供するための方式として理解できます。

変換技術の価値

変換技術の価値は、IPv4 と IPv6 をきれいに統合することではありません。むしろ、両者が互換ではないという事実を受け入れた上で、境界を明確に作ることにあります。

価値	意味
IPv6-only network を作れる	内部や access network を IPv6 中心に設計できる
IPv4-only 資産を残せる	既存 server、application、service を段階的に扱える
IPv4 address 消費を抑えられる	共有、集約、port set などで延命できる
移行期間を現実的に扱える	全員が同時に dual stack 化しなくてもよい
境界設計を明確にできる	どこで変換するか、どこから責任が変わるかを定義できる

これは、NAT66 の記事で書いた「境界抽象」の話とも近いです。変換技術は、純粋な IP 通信を壊すものというより、異なるアドレス体系・異なる運用段階をつなぐ境界装置として見ると理解しやすくなります。

それでも学習ハードルは高い

IPv4/IPv6 変換技術は、学習ハードルが高いです。IP address、prefix、port、DNS、ICMP、MTU、fragmentation、state、logging、security policy が絡むためです。

さらに、方式ごとに「client 側で変換するのか」「network 側で変換するのか」「encapsulation なのか translation なのか」「stateful なのか stateless なのか」が違います。

このため、最初からすべてを暗記しようとするより、次の軸で分類すると理解しやすくなります。

分類軸	見るべき点
方向	IPv6 client から IPv4 server か、IPv4 service を IPv6 network 上で運ぶのか
方式	translation か encapsulation か
状態	stateful か stateless か
場所	client / CPE / provider / data center のどこで処理するか
DNS 依存	DNS64 のように名前解決と連動するか
運用影響	logging、troubleshooting、security policy をどう扱うか

現在の私の見方

以前は、IPv4/IPv6 変換技術を「あまり学びたくない一時的な技術」と見ていました。今でも、可能なら dual stack で素直に設計したいという考えは変わりません。

しかし、IPv4 が長く残り、IPv6-only network が現実的になるほど、変換技術は避けられない設計要素になります。

つまり、変換技術は IPv6 移行の脇役ではありますが、脇役だから不要なのではありません。むしろ、移行期間が長くなるほど重要になる技術です。

ネットワークエンジニアだけでなく、サーバー、アプリケーション、クラウド、セキュリティを扱うエンジニアも、NAT64 / DNS64 / 464XLAT / MAP-E / MAP-T の名前と役割くらいは理解しておいた方がよいと思います。

まとめ

IPv4/IPv6 変換技術は、複雑で、できれば避けたい技術です。end-to-end の dual stack が成立するなら、それが最も分かりやすい構成です。

しかし、IPv4-only 資産が残り、IPv6-only network が増えていく現実では、変換技術は長く必要になります。

重要なのは、変換技術を「一時的な面倒な例外」としてだけ見るのではなく、IPv4 と IPv6 の非互換性を受け止める境界設計として理解することです。

SIIT、NAT64、DNS64、464XLAT、MAP-E、MAP-T、DS-Lite は、それぞれ目的も場所も違います。まずは、どの方式がどの境界をつなぐためのものなのかを整理するところから始めるのがよいと思います。

参考

• RFC 6145 – IP/ICMP Translation Algorithm
• RFC 6146 – Stateful NAT64
• RFC 6147 – DNS64
• RFC 6877 – 464XLAT
• RFC 7597 – MAP-E
• RFC 7599 – MAP-T
• RFC 6333 – Dual-Stack Lite
• IPv6 における NAT66 再考
• IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る