IPv6移行技術

**IPv6移行技術**（IPv6いこうぎじゅつ、）とは、インターネットにおいて使用するプロトコルの、1981年から使われているIPv4 (Internet Protocol version 4) から、その後継技術であるIPv6 (Internet Protocol Version 6) へのを促進するための技術である。**IPv4/IPv6共存技術**ともいう。

## 概要
IPv4とIPv6のネットワークは直接に相互運用可能でないため、IPv6移行技術はどちらのネットワークタイプに属するホストでも他のどのホストとも通信することが出来るように設計されている。

その技術的な基準を満たすために、IPv6には現在のIPv4からの直接の移行計画がなければならない。その目的に向けた移行技術を開発するために、Internet Engineering Task Force(IETF)はワーキンググループやインターネットドラフトやRFCを通じた議論を指揮している。いくつかの基本的なIPv6移行技術は  で定められている。

大きく分けて、IPv4ネットワーク下でIPv6通信を可能化する手法と、IPv6ネットワーク下でIPv4通信を可能化する手法がある。IPv6を推進する立場からは後者は「IPv4延命技術」とも呼ばれる。

IPv6ネットワーク下でIPv4通信を可能化する場合、トンネリング（カプセル化）やトランスレーション（ヘッダ書き換え）等の手法がある。トンネリングの場合、トンネル内ではIPv6のヘッダ分（標準 40bytes）オーバーヘッドが増える。トランスレーションでは、適用区間内で （IPv6ヘッダ - IPv4ヘッダ）分（標準 20 bytes）増加する。よって、ネットワークMTUとの関連で議論がある。またいずれの方式も、フラグメント化されたIPv4パケットの取扱いに難がある。

IPv4上のコネクション(L3)に対してしばしば、キャリアグレードNAT(CGN)が適用される。

## ステートレスIP/ICMP変換
**ステートレスIP/ICMP変換**(**SIIT**: Stateless IP/ICMP Translation)は、IPv6とIPv4の間でパケットのヘッダフォーマットを変換する。SIITでは、「IPv4変換アドレス」(IPv4-translated address)と呼ばれるIPv6アドレスの種類を定義する。IPv4変換アドレスはプリフィックスが*::ffff:0:0:0/96*で、IPv4アドレスが*a.b.c.d*のとき*::ffff:0:a.b.c.d*のように書き表す。このプリフィックスは、トランスポート層のヘッダのチェックサム値が変化しないよう、値が0のチェックサムを与えるために選ばれた。

このアルゴリズムは、固定的に割り当てられたIPv4アドレスを持たないIPv6ホストが、IPv4のみのホストと通信する場合に使用される。アドレスの割当てとルーティングの詳細は、仕様に記載されていない。SIITは、ステートレスなネットワークアドレス変換(NAT)の特別な例である。

仕様はNGTRANS IETFワーキンググループによるもので、最初にサン・マイクロシステムズのE.Nordmarkによる  として、2000年2月にドラフトが発表された。は、2011年に  によって廃止された。のアドレス・フォーマットの一部は、  で定められている。IPv4/IPv6変換の枠組みは、で定められている。

## トンネルブローカー
**トンネルブローカー**は、IPv6のトラフィックをIPv4による接続の中にカプセル化することによって、IPv6による接続を提供する。一般的にはが使用される。これは、IPv4ネットワークの中にIPv6トンネルを確立する方法である。トンネルは、(TSP)や(AYIYA)で管理される。初のトンネルブローカーは、1999年2月に公開された。

## 6rd

**6rd**は、インターネットサービスプロバイダ(ISP)がIPv4基盤を通してIPv6サービスを迅速に提供することを容易にする技術である。IPv4とIPv6の間でステートレスなアドレスマッピングを使用し、顧客ノードの間でIPv4パケットと同様に最適化されたルートをたどる自動的に生成されたトンネルを通してIPv6パケットを送る。

2007年の  によって定義され、ネイティブアドレスに対するIPv6サービスの初期の大規模な展開のために使われた。プロトコルの標準化過程の仕様は  である。

## Transport Relay Translation
 では**Transport Relay Translation** (**TRT**)が定められている。この方法は、NAT-PT/NAPT-PTとほぼ同一であるが、DNSのAAAAレコードとAレコードの変換に  で定められたDNS-ALGを使用する。

## NAT64

は、IPv6ホストがIPv4サーバーと通信することができるようにする技術である。NAT64サーバは、少なくとも1つのIPv4アドレスと、32ビット（例：*64:ff9b::/96*）のIPv6ネットワークセグメントを持つエンドポイントである( ,  )。

IPv6クライアントは、これらのビットを用いて通信することを望むIPv4アドレスを埋め、結果として生じるアドレスにパケットを送る。NAT64サーバーはIPv6とIPv4アドレスの間でNATマッピングを作成し、クライアントと相手先が通信できるようにする。

## DNS64
**DNS64**は、ドメインのAAAAレコードを要求されるためにDNSサーバーを記述するが、Aレコードだけしか見つけられなかった場合は、AレコードからAAAAレコードを合成する。合成されたIPv6アドレスの最初の部分はIPv6/IPv4トランスレータを指し、第2の部分はAレコードからIPv4アドレスで埋める。トランスレータは、通常NAT64サーバーである。DNS64の標準化過程の仕様は  である。

DNS64には、以下の2つの問題がある。
*DNSが遠隔ホストアドレスを見つけた場合にしか働かない。IPv4リテラルが使われるならば、DNS64サーバーは決して関与しない。
*DNS64サーバーがドメインのオーナーで特定されない記録を返す必要があるので、変換しているDNSサーバーがドメインのオーナーのサーバーでない場合、ルートに対するDNSSEC確認は失敗する。

## ISATAP

## 464XLAT
**464XLAT**()は、IPv6のみのネットワークの上のクライアントがIPv4のみのインターネットサービス（Skypeなど）にアクセスできるようにする。

クライアント（例えばSkypeクライアント）は、IPv6のみのネットワークを通してNAT64トランスレーター（上述）に送るために、SIITトランスレーター（上述）を使用してIPv4パケットをIPv6に変換する。NAT64トランスレーターは、IPv4が使用可能なネットワークを通してIPv4のみのサーバ（例えばSkypeサーバ）に送るために、IPv6パケットをIPv4に変換する。SIITトランスレーター(CLAT)は、（特別なソフトウェアとして）クライアントそのものとして、または中間のIPv4が使用可能なLAN（ただし、それにはIPv4インターネット接続性があるなら、464XLATは必要でない）として実装される。NAT64トランスレーター(PLAT)は、サーバーとクライアント（CLATを通して）に到達できなければならない。NAT64の使用は、UDP、TCP、ICMPを用いたクライアントサーバモデルの接続に制限される。

464XLATはトランスレーションであり、CPEあるいは端末に置かれるCLATはステートレス、PEに置かれるPLATはステートフルとなる。

;実装
*Android用のCLATの実装： Android CLAT
*AndroidネイティブのCLATの実装はバージョン4.3(Jelly Bean)で導入された。
*Windows PhoneネイティブのCLATの実装は2014年にWP 8.1で導入された。

## Dual-Stack Lite (DS-Lite)

**Dual-Stack Lite**（デュアルスタックライト、DS-Lite）は、  で定義されている。DS-Liteでは、インターネット接続を提供するためにグローバルIPv4アドレスをカスタマ構内設備(CPE)に割り当てる必要がない。

CPEは、ISPから割り当てられた範囲でLANクライアントにプライベートIPv4アドレスを配信する。CPEは、IPv6パケットの中にIPv4パケットをする。CPEはパケットをISPのキャリアグレードNAT(CGN)に届けるためにグローバルなIPv6接続を使用する。ISPのCGNにはグローバルなIPv4アドレスが割り当てられている。ISPのCGNは、元のIPv4パケットをデカプセル化し、IPv4パケットにNATを実行し、グローバルのIPv4インターネットに送信する。CGNは、セッションごとにCPEのグローバルIPv6アドレス、プライベートIPv4アドレス、TCPまたはUDPのポート番号を記録することにより、個々のトラフィックフローを識別する。

## MAP
(**MAP**)は、CiscoによるIPv6移行技術の提案で、 のポートアドレス変換と、ISP内部のIPv6ネットワークの上にIPv4のトンネリングを行う技術を複合させる。、MAPはInternet Draftの標準化過程(standards-track)の状態にあった。

IPv4パケットをIPv6にカプセル化しトンネリングする方式が**MAP-E** ()である。トンネリングではなく、NAT64によりトランスレーション（ヘッダ書き換え）を行う方式は**MAP-T** ()と呼ぶ。

いずれの方法も、CPE側 (CE)でNAPT実施（ステートフル）し、PE側 (BR:Border Relay) はステートレスとなる。

## 提案中の草案
以下の方法は、まだ議論中であるか、IETFによって放棄された。

### 4rd
4rd(IPv4 Residual Deployment)は、  で定義された、IPv6ネットワークを通してIPv4サービスの提供を容易にするための技術である。6rdのように、IPv6とIPv4の間でステートレスなアドレスマッピングを使用する。トランスポート層ポートに基づくIPv4アドレスの拡張をサポートする。これは、モデルのステートレスな変種である。

**4rd-U** (Unified) とは異なる。MAP-Eの原型。

## 非推奨の方法
以下の方法は、IETFによって非推奨とされた。

### NAT-PT
**ネットワークアドレス変換/プロトコル変換**(NAT-PT: Network Address Translation/Protocol Translation)は  で定められたが、多くの問題のために、  によって廃止された。一般的に、NAT-PTはDNS(DNS-ALG)実装とともに用いられる。

### NAPT-PT
**ネットワークアドレスポート変換/プロトコル変換**(NAPT-PT: Network Address Port Translation/Protocol Translation)は、  で定められた。NAT-PTとほとんど同じであるが、アドレスだけでなくポート番号の変換も行う。この方法は、  によって廃止された。

## その他の方法
* 
** 1:N

* 
** dIVI = double IVI。MAP-Tの原型
* 4rd-U
** ヘッダ情報のマッピング。MAP-EとMAP-Tの統合。4rdとは異なる。
* 
** 。MAP-Eとの相違点

## 実装
*stone (ソフトウェア) - WindowsとUnix系OSのポートトランスレータ
*faithd - BSDベースの固定TRTの実装（KAMEプロジェクトによる）
*TAYGA - Linux用のステートレスなNAT64の実装
*Jool - Linux用のステートフルなNAT64の実装
*naptd - ユーザレベルのNAT-PT
*Ecdysis - NAT64ゲートウェイ（DNS64を含む）
*Address Family Transition Router (AFTR) - DS-Liteの実装
*niit - IPv4ユニキャストトラフィックをIPv6ネットワークへ流せるようにするLinuxカーネルデバイス
*IVI - IPv4/IPv6パケット変換の実装（Linuxカーネルのパッチ）
* - DNS64・NAT64を実装するリバースプロキシ・VPN
*BIND - バージョン9.8からDNS64を実装
*PF (ファイアウォール) - OpenBSDのパケットフィルタ。バージョン5.1からNAT64を含むIPバージョン変換をサポートする。

## 脚注

### 注釈

### 出典

## 参考文献
**IPv6 in Practice*, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
*, *Bump-in-the-Stack*
*, *Bump-in-the-API*
*, *Socks-based Gateway*
*, *The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition*

## 外部リンク
*D. J. Bernstein - The IPv6 mess
*IPv6 - Prospects and problems: a technical and management investigation into the deployment of IPv6
*Network World: Understanding Dual-Stack Lite
* Framework for IPv4/IPv6 Translation
* IPv4 and IPv6 Transition and Coexistence, 6DEPLOY project, 2011
* IPv6: NAT-PT versus NAT64 Gianrico Fichera, 2012