図2.2-1 ルータ広告
1981年に発表されたIP version 4は1990年代に入って民間利用が始まり、急速に普及した。
IPアドレスはネットワークアドレス部、ホストアドレス部の組になっている。IPv4ではクラスA、クラスB、クラスCというユニキャストと、クラスDというマルチキャストアドレスに別けられる。このうち、2万弱しかないクラスBの割り当て在庫が早くから無くなると予想されたため、1995年にIPv4よりも更に多くのIPアドレスを使用できるIPv6が新たに定義された。
IPv4のIPアドレス（以下、IPv4アドレス）の枯渇問題は解消されぬまま、IPv6の普及は進まず、遂には2011年にAPNICで割り当て在庫が無くなった。さらに、2012年にRIPE-NCCが、2015年にARINが割り当て在庫の枯渇を発表した。
IPv6の規格は発表当時からアップデートが継続的に行われ、近年になってもアップデートが進んでいる。
近年のアップデートの話題はモバイル端末に対応するため無線通信における通信特性への対応や省電力化がある。また、IPv4アドレス枯渇問題に対応するためのネットワーク共有技術である。トンネリングやアドレス変換についてである。
本研究では、いよいよ全世界的にIPv4アドレスが枯渇してきた2016年時点におけるIPv6のアップデートの話題を追い、トピック毎にまとめた。これによりIPv6技術の最先端の話題をまとめ、IPv4からIPv6への移行の道しるべとなることを目指す。
インターネットの処理は階層構造となっている。おおまかに分けると次の4階層からなる。
インターネットでネットワーク層を構成するのはデータ転送を司るIPと、それをコントロールするICMPである。
ネットワーク層でパケットを宛先アドレスまで送信するプロトコル。アドレスにはIPアドレスが用いられる。
インタフェースまたはインタフェース集合のIP層での識別子。
通信に使用されるデータを送る単位。ここでは宛先アドレスなど通信に必要な情報が含まれるIPヘッダと通信されるデータを入れるペイロードの組。パケット長は最大値が決められている。
ネットワーク内に存在するただひとつの特定のノードを表すアドレス。
特定のノード集合を表すアドレス
ネットワークに属する全ノードを表すアドレス。
IPパケットの配送中に異常が発生してパケットを転送できなくなった場合やIPに関する通知を行う際に使用される。
データリンク層でノードのインタフェースに原則一意に割り当てられるアドレス。データリンクに接続するノードを識別するために利用される。物理アドレスとも呼ばれる。
パケット送信先のMACアドレスをIPアドレスから取得するデータリンク層のプロトコル。
ネットワークの通信単位。これはホストやルータが含まれる。
2つ以上のインタフェースを持ち、別々のネットワークに接続し、通信を中継するノード。経路計算（ルーティング）とパケット転送（フォワーディング）を行う。
データを送受信するノード
重複アドレス検出。生成したアドレスを利用する前に、そのアドレスが他のノードと重複していないかを確認する手続きのこと。ARPやPING（ICMPエコー）が用いられる。
データリンク層において1回の転送で送信可能なデータの最大値を示す伝送単位。
ノードのネットワーク層制御としてIPv4とIPv6の両方を用いること。
URIから、それに対応するIPアドレスを見つけること。一般にはDNS問い合わせを行う。
ドメイン名やホスト名とIPアドレスとの対応づけを管理するシステム。ホストはDNSサーバへURIを問い合わせることにより名前解決を行う。
IPv4[Internet Protocol version 4]は2016年現在広く使用されている、ネットワーク層で使用されるプロトコルである。これはIPアドレスを用いて、指定された宛先へデータを配送することを司る。
IPアドレスはネットワークアドレス部とホストアドレス部の組によって構成される。IPv4では32[bit]のアドレス空間を持ち、5つのクラスに分類され、クラスA、クラスB、クラスCというユニキャストと、クラスDというマルチキャストアドレス、クラスEという未使用領域に別けられる。
IPアドレスの特徴は、アドレスの中にネットワークアドレスとホストアドレスを含むことである。IPv4ではクラスAは上位8[bit]、クラスBは上位16[bit]、クラスCは上位24[bit]がネットワークアドレスにあたる。各ネットワーク組織は通常1つずつネットワークアドレスが割り当てられるので、IPv4では約211万個のネットワーク組織が接続できる。
IPv4アドレスは32[bit]の正整数値で表されるが、見やすくするために8[bit]毎に「.」で区切り10進数で表現する方法がとられる。
例えば、IPv4アドレス「11000000 00000000 00000010 00000000」は「192.0.2.0」と表される。
クラスA、B、Cのネットワークを組織用でさらに細かく区切って利用するため、ネットワークアドレスを拡張するサブネットという概念が導入された。これを実現するためにサブネットマスクと呼ばれる識別子が導入されている。クラスごとに決まるホスト部の一部をサブネットワークアドレス部として使用することにより複数のネットワークに分割が可能である。
サブネットを表すには2つの表記がある。IPアドレスが192.0.2.0で2つのサブネット空間がある場合、192はクラスCなのでネットワークアドレス長は24[bit]なので上位26[bit]がサブネットになる。つまりなお、ホストアドレス部が全て0であるアドレスはネットワークアドレスを全て1であるアドレスはブロードキャストアドレスを表す255.255.255.255はリンクローカルブロードキャストを表す。以下のように表される。
IPアドレス192.0.2.0 サブネットマスク255.255.255.192
もしくはIPアドレス192.0.2.0 /26
IPv6[IP version 6]はIPv4アドレス枯渇問題により1995年に定義された。128[bit]のアドレス空間を持つが、プレフィックスにより、いくつかの機能別に分類され、ユニキャストアドレス、マルチキャストアドレス、エニーキャストアドレスが挙げられる。IPv6でのネットワークアドレス長は上位48[bit]に固定されている。
IPv6アドレスはグローバルルーティングプレフィックス48[bit]、サブネットID 16[bit]、インタフェース識別子（IID[Interface Identifier]）64[bit]によって構成される。IPv4アドレスとは違い、128[bit] のアドレスを16[bit]毎に「:」で区切り、16進数で表記される。よってIPv6アドレスは「2001:db8:1111:2222:0000:0000:0abc:0def」と表される。また、4桁の16進数表記の内上位の0は省略でき、連続する場合には1回だけ「::」で省略することができるため、このアドレスは「2001:db8:1111:2222::abc:def」とも表される。
IPv6においてもサブネットワークが導入されている。IPv6ではクラスは無くネットワークアドレス長48[bit]サブネットアドレス長16[bit]ホストアドレス長[64bit]となっている。
また、プレフィックスの表記方法はIPv4アドレス同様で、プレフィックスのビット長を10進数で記述する。例えば「2001:db8:1111:2222::abc:def」においてネットワークアドレスは「2001::db8:1111::/48」で表される。サブネットアドレスを含めると「2001:db8:1111:2222::/64」と表記できる。
IPv6において近隣探索（Neighbor Discovery）は、アドレスを自動設定するために用いる（2.2.2. IPv6アドレスの自動生成SLAAC参照）。近隣探索はIPv4におけるARP、ICMPルータ発見、ICMPリダイレクトに相当する機能をもち、さらに追加の機能としてノードのアドレス自動生成、経路の自動生成がある。
近隣探索の基本的な機能としては次の項目がある。
パケット送信先のIPv6アドレスに対応するデバイスがどれかを特定するためにリンク層識別子が使用される。そこで、近隣広告メッセージ、近隣要請メッセージを使用することにより近隣（同一リンク上）ノードのIPv6アドレスとリンク層識別子（例えばMACアドレス）の対応表（近隣キャッシュと呼ぶ）を作成し、保持しておくことでアドレス解決を行うようにする。
送信パケットの経路決定のために、ルータ発見機能、プレフィクス発見、次ホップ決定、リダイレクト機能を提供する。
アドレス自動生成とは、ノードが自動的にIPv6アドレスを生成する機能のことで、ステートレスアドレス自動生成機能（SLAAC[Stateless Address Auto configuration]）と呼ばれる。（2.2.2.IPv6アドレスの自動生成参照）
重複アドレス検出とは、使用しようとするアドレスが同一リンク上ですでに使用されていないかを確認するための機能で、DAD[Duplicate Address Detection]と呼ばれる。（2.2.3.IPv6アドレスの重複検出参照）
送信するパケットに必要な情報（例えばリンクMTUや最大ホップ数）を通知、検出する機能である。
以上のような機能により、IPv6ノードはIPv6リンクに接続するだけでアドレス自動生成、デフォルト経路の決定、パケット送信のためのパラメータを自動設定することができる。
これらの機能を利用するために同一リンク上に流すメッセージのことを近隣探索メッセージという。これにはICMPv6メッセージを使用する。
使用するICMPv6メッセージには大きくルータ要請／ルータ広告／近隣要請／近隣広告／リダイレクトに分別される。
| 種類 | 意味 |
|---|---|
| ルータ要請（RS） | リンク上のルータの探索時に使用 |
| ルータ広告（RA） | ルータがホストに自分の存在を知らせるために使用。SLAAC、経路設定、パラメータ発見に必要な情報が含まれる |
| 近隣要請（NS） | リンク層の問い合わせ、到達可能確認、DADに使用 |
| 近隣広告（NA） | ノードが近隣要請に対して応答時に使用。リンク層アドレスの変化の通知に使用 |
| リダイレクト（Redirect） | より適切な次ホップを通知する |
近隣探索はマルチキャストを利用して効率的な情報伝達・要求を実現する。マルチキャストにはいくつかの種類があり以下に示す。
ノードはインタフェース起動時にこのマルチキャストアドレスに参加しなければならない。
ルータは自分の存在を通知するためにルータ広告（RA）を定期的に全ノードマルチキャストアドレス宛に送信し、リンクのデフォルトルータの通知、SLAACに必要な情報などを通知する。
ノードが早急にプレフィクスなどの情報を必要とする場合、ルータ要請（RS）メッセージを送信してルータ広告を催促することができる。（図2.2-2）
IPv6リンクに接続したノードは全ルータマルチキャストアドレス宛てにルータ要請を送信する（図2.2-2①）。ルータがルータ要請メッセージを受信した場合、ルータ広告メッセージをリンクローカルユニキャストで即座に返信する。（図2.2-2②）
ルータ広告のメッセージフォーマットを図2.2-3に示す。
このICMPv6パケットがルータ広告メッセージであることを示すためのもので、134を指定する。
0を指定。
パケットに設定するデフォルトの最大ホップ数を0〜255の範囲で指定する。
管理対象アドレス設定を示し、0か1を指定する。1の場合、DHCPv6が利用可能であることを意味する。0の場合、後述のOフラグともに0の場合はDHCPv6が利用できないことを意味する。
その他の設定情報を示し、0か1を指定する。1の場合はアドレス以外の設定情報がDHCPv6によって入手可能であることを意味する。Mフラグが1の場合、Oフラグは無視される。
0で初期化する。
デフォルトルータとして利用可能な時間を0〜9000秒で指定する。ルータ広告を送信するルータがデフォルトルータとして利用できない場合は0を指定する。
ルータ広告メッセージには送信元リンク層アドレス、プレフィックス情報、MTUの3種類のオプションを付加することができる。
MTUはリンクで推奨されるMTUを32[bit]の符号無し整数で指定できる。
プレフィックス情報はアドレス自動生成に使用するプレフィックスをノードに通知することを目的とする。このオプションフォーマットを図2.2-4に示す。
同一リンクフラグ。1の場合は、プレフィックスを同一リンク上にあるかどうかの判定に利用できる。0の場合は利用できない。
自動アドレス設定フラグ。1の場合はプレフィックスをグローバルアドレスの自動生成に利用できる。
プレフィックスが同一リンク上にあるかどうかの判定に利用できる期間を秒単位で指定する。全てのビットが1の場合は期限なし。
このプレフィックスを使用してアドレス自動生成を行ったアドレスが有効なアドレスである期間を秒単位で指定する。
アドレス自動生成などで使用するプレフィックスを指定する。
ルータ要請のメッセージフォーマットを図2.2-5に示す。
このICMPv6パケットがルータ要請メッセージであることを示すためのもので、133を指定する。
ルータ要請メッセージには送信元リンク層アドレスオプションのみが付加することができる。送信元アドレスが決まっている場合、ルータ要請メッセージにはこのオプションを指定することが推奨されている。アドレスが決まっていない場合はこのオプションを指定してはいけない。
IPv6においてネットワークアドレス、サブネットアドレスは近隣探索により取得できる。そしてホストアドレスを書くノードで唯一になるように生成できれば、IPv6アドレスを自動生成できる。初期のIPv6においてホストアドレスをMACアドレスから生成する方法を以下に示す。
インタフェース識別子はネットワークインタフェースカードのMACアドレスから生成される。しかし、MACアドレスは48[bit]なので、64[bit]のEUI-64形式を元とした構造に変形させるために3つの手順が必要である。1つ目はMACアドレス24[bit]ずつに分ける。2つ目に分割した間に0xFFFEを挿入する。3つ目にuビットを反転させる。結果として図2.2-6(c)下部の状態となる。
この方法で生成されたインタフェース識別子はMACアドレスを元に生成されているため、他のネットワークで接続してもインタフェース識別子は不変である。それにより、インタフェース識別子から逆算して特定のノードを追跡することが可能となってしまう。このため、ランダムに生成したインタフェース識別子を使用して生成した一時アドレスの使用が許されている（RFC4941）。一時アドレスのインタフェース識別子はハッシュアルゴリズムであるMD5というアルゴリズムを使用して生成される。
このようにしてインタフェース識別子が生成されプレフィクスと組み合わされることでIPv6アドレスとなる。この際に重複アドレス検出（2.2.3IPv6アドレスの重複検出参照）が行われ、重複していないことがわかった時点で初めて使用可能になる。
IPv6ホストは生成したアドレスを使用する前に、そのアドレスが他のノードで既に使用されていないかを必ず確認する。この手続きを重複アドレス検出と呼び、他のノードと重複していないことが確認されるまで生成したアドレスを実際に使用することができない。
生成されたアドレスはいくつかの状態を遷移する（図2.2-7）。
重複アドレス検出の手順を説明する前に、使用される近隣要請（NS）メッセージと近隣広告（NA）メッセージについて説明する。
近隣要請メッセージでは相手ノードのリンク層アドレス情報を要請する時や自ノードのリンク層アドレスを通知する時に使用される。近隣要請メッセージフォーマットを図2.2-8に示す。
このICMPv6パケットが近隣要請メッセージであることを示すためのもので、135を指定する。
重複アドレス検出などの対象となるIPv6アドレスを指定する。
近隣要請メッセージには送信元リンク層アドレスのみが付加することができる。
近隣広告メッセージはノードが自分のリンク層アドレスを通知したり近隣要請に対する応答として使用される。近隣広告メッセージフォーマットを図2.2-9に示す。
このICMPv6パケットが近隣広告メッセージであることを示すためのもので、136を指定する。
ルータフラグを示し、0か1を指定する。1の場合はこのノードがルータであることを示す。
要請フラグを示し、0か1を指定する。到達不能検出に用いる。
上書きフラグを示し、0か1を指定する。1の場合は、近隣広告を受け取ったノードはこの情報を基にして近隣キャッシュのエントリを上書きするべきであることを示す。0の場合は、受け取ったノードはこのメッセージが渡す情報を新たに追加する。ただし既に近隣キャッシュに載っている場合は更新しない。
近隣広告の対象となるIPv6アドレスを指定する。近隣要請に対する応答の場合は近隣要請メッセージと同じターゲットアドレスを指定する。
近隣要請メッセージには送信元リンク層アドレスのみが付加することができる。
アドレス重複検出の流れを図2.2-10に示す。
アドレスを生成したノードはインタフェースにアドレスを割り当てる前に要請ノードマルチキャストアドレス宛に近隣要請メッセージを送信する。近隣要請メッセージのターゲットアドレスには生成したアドレスを指定する。
アドレスが重複している場合、送信した近隣要請メッセージの応答として、アドレスを既に使用しているノードから近隣広告メッセージが送信されてくる。この近隣広告メッセージのターゲットアドレスには近隣要請で指定したアドレスが指定されている。
新しくアドレスを使用とするノードが近隣広告メッセージを受信すると、ノードはアドレスが重複しているとみなしアドレス重複検出は失敗してアドレスはインタフェースへ割り当てられない。
決められた回数近隣要請メッセージを送信しても重複を示す近隣広告メッセージが返信されてこない場合、アドレス重複検出は成功したとみなされインタフェースへアドレスが割り当てられる。
DHCPはTCPIPネットワークに接続するホストに、デフォルトルータなどの接続に必要な構成パラメータを提供し、さらにホストへIPアドレスを割り当てる役割を持つ。
IPアドレスの割り当て、パラメータの提供するホストをDHCPサーバと呼び、IPアドレスの割り当てられるホストをクライアントと呼ぶ。
DHCPサーバは予めクライアントに割り当てるためのIPアドレスを用意する、これをアドレスプールという。DHCPクライアントの要求に応じてアドレスプールから1つのIPアドレスを割り当てる。
クライアントがIPアドレスを割り当てられるまでの過程を図5.1-1に示す。
もし割り当てられるIPアドレスが使用できない場合はDHCPサーバにDHCPDECLINEメッセージを送信し、構成プロセスを再度行う。
IPアドレスでは特別な用途のために使用されるアドレスがあり、RFC6890に定義されている。特別用途アドレスの定義は更新され、RFC6890はRFC3330、RFC5735を経て最新のものとなっている。この更新の間に特別用途であまり使用されていないアドレス割り当てを廃止して開放することでIPv4アドレスの枯渇に対応していた。
RFC6890によるとIPv4では
が新たに予約されている。
IPv6アドレスも特別用途アドレスが同文書で定義されており、IPv4アドレスをIPv6アドレスに置き換えるための技術
トンネリングとは、離れたローカルネットワーク同士を接続するために、中間のネットワークを介して通信を可能にするための技術である。
本来通信を行うプロトコルのパケットを別のプロトコルのパケットで包んで通信を行う。この別のプロトコルで包むことをカプセル化、カプセリングといい、カプセル化とその解除はトンネルの両端の機器が自動的に行う。トンネルの両端以外の機器は途中のプロトコルや経路を気にする必要はない。
図2.5-1 のようにネットワークA、B、Cが存在し、ネットワークA、CではIPv6が使用され、ネットワークBがIPv4しかサポートされていない場合、ネットワークA、CはIPv6で通信することができない。このような状況でIPトンネリングは利用される。
トンネリングの流れを以下に示す（図2.5-2参照）。
アドレス変換技術としてNAT[Network Address Translator]が開発された。更にTCPなどのポート番号も変換するNAPT[Network Address Ports Translator]が開発された。NAT（NAPT）対応ルータの内部で変換テーブルが作成され、このテーブルを元に変換を行う。例えば、ローカルネットワークでプライベートアドレスを使用して、インターネットへ接続する時にグローバルアドレスへ変換することで多数のノードが同時に１つのグローバルアドレスを利用することができる。
IPv4のIPアドレスとIPv6のIPアドレスとをアドレステーブルによってアドレス変換するものをNAT-PT[Network Address Translation-Protocol Translation]といい、NAT64と呼ばれる。
IPv4アドレス枯渇問題を解決するために、プロバイダ内にISP共有ネットワーク（ISP Shared Network）を構成して、更にNATを行うLSN[Large Scale NAT]という技術が近年確立された（図2.5-1）。家庭内のプライベートネットワークは顧客側の終端装置CE[Customer Edge]でNATが行われ、ISP共有ネットワークに接続される。さらにLSNでもNATが行われる。ISP共有ネットワークではグローバルアドレスもプライベートアドレスも使用できず、先述のISP Shared Address 100.64.0.0/10が割り当てられる。
IPv6への移行はIPv6導入期、IPv6普及期、IPv4衰退期の3段階に分別される。
IPv6普及期では、IPv6の製品やサービスが手頃に利用できるようになりIPv6とIPv4が共存している環境のことを表す。ここでは数種の接続体系が考えられている（図3.1-1）。
(a)ではIPv6専用の回線を設け、直接他のIPv6ネットワークに接続する。
(b)では、IPv4インターネット上にトンネルを構築することにより離れたIPv6ネットワーク同士を接続する。この技術には6to4があげられる。
(c)では、IPv6とIPv4の両方の接続を1つの接続回線を使用して接続する。そのためルータなどのネットワーク機器は両方のプロトコルをサポートしている必要がある。
(d)では、IPv6インターネット上にトンネルを構築することにより離れたIPv4ネットワーク同士を接続する。この技術には後述のDS-Lite、MAP-Eがあげられる。
(e)では、IPv4、IPv6が混在するネットワークからそれぞれ別々にトンネルを構築する。
(f)では、アドレス変換の技術を利用する。IPv4パケットをIPv6パケットに変換しIPv6インターネットを通過させた後、再びIPv6パケットからIPv4パケットへ変換する。この技術には後述のMAP-T、464XLATがあげられる。
IPv4アドレス枯渇に対してIPv6への移行が急がれる中、同時にIPv4延命策がとられている。その一つに、LSNがあげられる。これは、従来ISPが契約世帯ごとに1つのグローバルアドレスを割り当てていたのに対し（図3.2-1）、複数の契約で1つのグローバルアドレスを共有させる仕組みである（図3.2−2）。
図3.2-1では、Cutomer側はプライベートネットワークで構成され、CEでNATを行いインターネットへ接続している。
図3.2-2では新たにISP内にLSNを設け、そこに複数のCustomerと接続することでCEとの間にISP共有ネットワークを構成する。LSNのインターネット側にグローバルアドレスを割り当てる。そのため、CEで顧客側のプライベートアドレスからISP共有ネットワークアドレスへNATが行われ、さらにLSNでもISP共有ネットワークアドレスからグローバルアドレスへNATが行われることになる。
このISPネットワーク内では、IPアドレス100.64.0.0/10が予約されていて、これを使用する。
LSNと組み合わせて使用する技術としてDS-Lite [Dual-Stack Lite]が考案された。これはトンネリングを使用した技術で、LSNを組み合わせて使用することで複数回のNATから1回のNATへ抑えられる。
図3.2−3のように、CEとLSNの間にトンネルを構築する。そこでは、IPv4のデータパケットをIPv4のヘッダでカプセリングを行いISP網に流す。こうすることにより、CEでNATを行わずにLSNまで到達できるので、NATは1回で抑えられる。
IPv6網の普及が初期段階である導入期の頃では6to4と呼ばれる、トンネリング技 術を利用してIPv6通信をしていた。6to4はIPv6網とIPv4網との境界で6to4リレ ー、6to4ルータを介してIPv6パケットをIPv4パケットでカプセル化することで IPv6通信を実現する仕組みである。但し、6to4でのIPv6網は専用アドレスを用い るため通常のIPv6ユニキャストアドレスと共存できなかった。
さて、IPv6網へと移行していくことで、今度はIPv6網でIPv4の通信を通すことが必要になってくる。さらに、実装方法として、アドレスの数の制限があるが、実装が容易なステートレスと、アドレスの数に制限が無い代わりに実装が複雑になるステートフルな実装がある。
前述したDS-Liteはステートフルなトンネリングである。Customer側のCEからISP内のアドレス変換ルータ（AFTR）までトンネルを構築し、AFTRでNATを行うことによりIPv4通信を実現する。
図3.3-1 DS-Liteの適用例
IPv6網でIPv4通信を通す方法はこれ以外にも考案されており、MAP[Mapping Address and Port]を利用するMAP-E[Mapping of Address and Port with Encapsulation]、MAP-T[Mapping of Address and Port with Translation]があり、前者はステートレスなトンネリング、後者はステートレスなアドレス変換である。
MAP-E（RFC7597）はIPv4アドレスとIPv6アドレスをマッピングする方法である。顧客側の終端装置MAP CEでIPv4パケットはNATによりグローバルIPv4アドレスに変換される。また、ISP側の境界ルータBR宛のIPv6パケットにカプセリングされ、BRに送信される。BRでカプセル化が解除されIPv4パケットとしてインターネットへ送信される。
MAP-EはMAP CEでNAPTとカプセリングを行うのに対し、MAP-T（RFC7599）では、MAP CEでNAPTとアドレス変換を施す。MAP CEにてIPv4プライベートアドレスからNATによりIPv4グローバルアドレスへ変換される。更にIPv4ヘッダをIPv6ヘッダにアドレス変換される。IPv6ヘッダに変換されたパケットはIPv6ネットワークを介しBRまで到達する。BRでIPv6ヘッダから再びIPv4ヘッダに変換され、IPv4インターネットへ送信される。
これらMAP-EとMAP-T（トンネリングとアドレス変換）とを組み合わせた技術として4rd（RFC7600）が提案されている。
この他にもステートフルなアドレス変換として464XLAT（RFC6877）がある（図3.3-4）。これは、顧客側アドレス変換装置CLATでステートレスなIPv4/IPv6アドレス変換を行い、グローバルIPv6アドレスに変換される。ISP内のISP側アドレス変換装置PLATではステートフルなIPv6/IPv4アドレス変換が行われ、この時点でIPv4グローバルアドレスに変換される。
IPv6の方が先に定義されたのにも関わらず、IPv6が普及するよりも先にモバイル端末が普及したため、IPv6もモバイル端末への対応が必要になってきた。モバイル端末では電力を十分に使えないので、不要な通信を減らす必要がある。また、モバイル端末で主要なデータリンク層である無線LANでの通信状況下では有線通信よりもパケットロスしやすくなるため、パケットロスへの対応も必要となる。
ノートパソコンやタブレットなどバッテリー駆動の端末が多数接続するネットワークにおいて、ルータによる頻繁なルータ広告は受信側であるモバイル端末のバッテリーの電力消費に影響を与えてしまうことが問題となっている。2015年にワーキンググループv6opsのドラフトでルータ広告の送信頻度について議論されている。
このドラフトで、次のことが推奨された。スリープ状態でバッテリーの消費に影響がないようにするためにはルータ広告の頻度を最多でも1時間に7回とするべきである。更に、モバイルデバイスが多く接続するネットワークにおいては以下も推奨された。
但し、現在ドラフトの段階であるので更に改訂されるかもしくは破棄される可能性がある。
IPv6網にてホスト上のインタフェースが初期化されたとき、ホストはルータ広告をすぐに受信しようとするため、ホストはルータ要請を送信する。しかし無線LANのパケットロスなどの理由で、このルータ要請が途中で損失する場合がある。この損失についての対応策としてRFC7559「Packet-Loss Resiliency for Router Solicitations」が2015年5月に新たに定義された。
従来だと、ルータ要請が損失した場合、ホストはルータから定期的に送られてくるルータ広告を待たなければならない。このルータ広告の送信間隔は最長で1800秒であるため、最悪の場合だと30分間接続を確立することができない事態が発生する可能性があった。
しかし、パケットロスはネットワークの輻輳でも起きうる。そのため、ルータ要請を送るホストが多数存在してしまうとネットワークトラフィックが過剰に増大する可能性がある。これを防ぐため、トラフィック増大を防止するためにルータ要請の再送信の時間間隔として指数関数的なバックオフアルゴリズムが用いられる。これにはRFC3315の14節で指定されたアルゴリズムが採用される。
以下ではその詳細について記述する。
ルータ要請の再送メカニズムでは6個の変数が使用され制御される。
| RT | Restransmission timeout | 再送タイムアウト |
|---|---|---|
| IRT | Initial retransmission time | 初期再送時間 |
| MRC | Maximum retransmission count | 最大再送カウント |
| MRT | Maximum retransmission time | 最大再送時間 |
| MRD | Maximum retransmission duration | 最大再送持続時間 |
| RAND | Randomization factor | ランダム化要因 |
RTはメッセージ伝達もしくは再送のために設定される。もしRTが、メッセージ交換が終わる前に期限切れになる場合、ホストはメッセージを再送してRTを以下の規則で再計算する。複数のホストが同時にメッセージを送信してしまうことを避けるため、RTの再計算にはランダム化要因（RAND）を使用し、乱数は-0.1~+0.1の間の一様分布で選択される。
最初のメッセージ伝達のRTはIRTに基づいて以下の式で計算される。
RT = IRT + RAND * IRT ・・・（１）
再送メッセージのRTはそれまでのRTの値に基づいて以下の式で計算される。
RT = 2 * RTprev + RAND * RTprev ・・・（２）
MRTはRTの値に上限を指定する。MRTが0である場合、RT値に上限は無いとする。RTがMRTよりも大きい場合以下の式で再計算が行われる。
if(RT > MRT) RT = MRT + RAND * MRT ・・・（３）
MRCはホストがメッセージを再送できる回数の上限を指定する。メッセージをMRC回伝達したら失敗とみなされる。
MRDはホストがメッセージを再送してもよい時間の長さの上限を指定する。ホストが最初のメッセージを送信してからMRD秒経過すると失敗とみなされる。
MRCとMRDが共に値が0である場合、ホストは送信に対する応答を受信するまでメッセージを送信し続ける。
ルータ要請の再送の場合、IRTはデフォルトで1秒、MRTはデフォルトで120秒、MRCとMRDは0秒と設定される。
最初のルータ要請を送信してから式（１）で計算されたRT秒待機してルータ広告の返信がない場合、ルータ要請を再送信する。それ以降式（２）で計算されたRT秒待機しても返信がない場合さらにルータ要請を再送信する。
この手順をMRCとMRDが0秒に設定されているためルータ要請に対する返信を受信するまでルータ要請を送信し続ける。
元来重複しないようなアドレスを生成するための方法としてMACアドレスが使用されてきたが、セキュリティとプライバシーの観点からインタフェース識別子はどこのネットワークへ移動しても不変であるということが問題視されている。インタフェース識別子が不変なことへの問題として、ロケーショントラッキングが挙げられる。ロケーショントラッキングとは、IPv6アドレスがプレフィクスとインタフェース識別子で分離されているのでホストが別のリンクへ接続した時、攻撃者がホストの動きを追跡することである。モバイルホストを対象としたパッシブアタックとしてサーバが同じホストからの接続時にプレフィクスの変化に応じてホストの動きを決定することができる。その他にもアドレススキャンの問題がある。これはよく使用される製品の製造会社識別IDを把握することで、個々のアドレススキャンにかかる時間を更に短くしてしまう。
このような問題を回避するために、IETFのワーキンググループ6manにおいてMACアドレス由来のインタフェース識別子の生成スキーマの使用を廃止し、RFC7217にて定義されるMACアドレスに由来しないインタフェース識別子の生成スキーマを使用することを推奨とするドラフト文書が議論されており、今現在も継続中である。RFC7217が定義する生成スキーマでは、擬似的なランダム関数を用いてインタフェース識別子を生成する。但し、各サブネット内で使用されるプレフィックスごとに同じインタフェース識別子を生成し、異なるプレフィックスで設定される場合には違うインタフェース識別子を生成するようなアルゴリズムを使用する。
IPv6とIPv4のデュアルスタック環境で大きな問題とされていたのがフォールバック問題である。多くのOSでは、IPv6アドレス、IPv4アドレスが割り当てられている場合、IPv6接続を優先して通信を開始するように実装されている。フォールバックとはIPv6で接続を試みて失敗した場合にIPv4での接続へ切り替えることを言う。
フォールバックはIPv6、IPv4両方でアドレスが割り当てられており、IPv6接続がインターネットアクセスの無い状態の時にフォールバックでの遅延が発生する。
例として、TCP通信の手順を図3.6-1 に示す。
この状態では、ホストにIPv6アドレス、IPv4アドレス両方が割り当てられている。しかし、IPv4でのインターネット接続は有るが、IPv6でのインターネット接続が無い状態である。
IPv6でのTCP接続がタイムアウトしてIPv4での通信が開始されるまでに数秒以上かかることある。この数秒の遅延がウェブページなどの表示の遅れとして影響する。
ウェブサーバはアクセスの負荷分散のために複数のサーバを導入していることがある。この場合、ホストがそのサーバへアクセスするために名前解決を行うと、複数のIPアドレスが応答として返答される。Internet Explorer(IE7,IE8)ではフォールバックの上限回数が5回までとデフォルトで設定されている。そのためDNSサーバから5個以上のIPv6アドレスが返答されてくると、IPv4へのフォールバックが行われずに通信が終了してしまい、ウェブページにアクセスすらできなくなる。
この遅延を削減するために2012年に「Happy Eyeballs（RFC6555）」が定義された。
従来はIPv6接続を優先して接続していたのに対して、これはIPv6、IPv4両方の接続を同時に開始する。こうすることによってたとえIPv6接続に不具合がある場合でも短時間で接続ができることになる。
Happy Eyeballsを実装した場合のホストの動作について図3.6−2、図3.6−3に示す。
図3.6-2では、IPv4にはインターネットアクセスが有り、IPv6のインターネットアクセスが無い状態での通信の例である。
＜IPv6のインターネットアクセスが無い場合（図3.6-2）＞
図3.6-3では、IPv4、IPv6どちらもインターネットアクセスが有る状態での通信の例である。
＜IPv6のインターネットアクセスがある場合（図3.6-3）＞
ホストはIPv6アドレスへの接続が成功／失敗かをキャッシュすることで後続の通信の際に、同じ手順を繰り返さないようにする。これらのキャッシュは最長10分で消去される。
以上がHappy Eyeballsの動作概要である。この仕様は実装依存性が高く、複数のインタフェースを利用する場合やIPv6アドレスが複数ある場合などは定義されていない。また、無駄なトラフィックを増加させている点も指摘されている。
2015年9月にAppleは、iOS9とX EI CapitanのOSアップデートに伴い、このHappy Eyeballsの改良版を実装することを発表した。Happy EyeballsにてAレコード、AAAAレコードを問い合わせた時、AAAAレコードが先に応答すればIPv6で接続を試み、Aレコードが先に応答した場合、AAAAレコードが遅れて応答することを期待して、25[ms]待機する。その間にAAAAレコードの応答があればIPv6で接続を試み、この時間を過ぎても応答がなかった場合にはIPv4で接続を試みる。
FirefoxやGoogle Chromeでは既にHappy Eyeballsが実装されており、こちらはDNS問い合わせで先に応答した方で通信を試みるという方法を採っている。また、もしこれが300[ms]経過してもACKが返ってこない場合は通信失敗とみなして次の候補アドレスで通信を試みる。
ここまでIPv6の一部技術について説明してきた。IPv6自体は真新しいものではなく、1995年にはRFC1884で最初の仕様が決定されており1998年にRFC2460「Internet Protocol, Version 6 Specification」で主な仕様が確定した。
IPv4アドレス枯渇の影響をうけて00年代から、OSのIPv6対応、NTT NGN(Next Generation Network)としてIPv6ネットワーク導入がされはじめた。
IPv6が本格的に導入され始めた最近になっても新しい問題が露見している。当初、バッテリー駆動のモバイル端末に対してはあまり考慮されていない実装が見受けられており、IETFではIPv6の技術仕様が日々更新、改訂されていて、改訂案（ドラフト）も少なくない。
総務省では2015年の「IPv6によるインターネットの利用高度化に関する研究会」にてIoT時代への開拓を謳っている。IPv6当初の仕様は無線LANノード、モバイル機器に対しては考慮されていないことが考えられる。そのため現在でもIETFのワーキンググループではバッテリー駆動のデバイスにとって無駄な電力を消費させないようなメカニズムについて議論している。その一つにはBluetoothLE[Bluetooth low energy]という技術が新しく定義されており、IPv6低消費電力無線パーソナルネットワーク（6LoWPAN[IPv6 over Low-power Wireless Personal Area Network]）に使用される。
IPv6の普及が進んでいるが、未だにIPv4のみでサービスを提供するところは多く、当分の間は没することはないだろう。
各個人の所有するパソコンや携帯端末ではデュアルスタックノードでIPv6に対応しており、ISP方面もIPv6接続サービスを開始しているところが多く、10年代にはKDDIを筆頭に、家庭向けのIPv6接続サービスの提供を開始した。現在ではIPv6デフォルト提供が基本となっている。大手携帯キャリア3社も、auは2012年、docomoは2011年、softbankは2014年3G／LTE／4G-LTE回線でIPv6接続サービスを提供開始している（デフォルト提供ではない）。しかし、企業ネットワーク、企業サイトなどはまだIPv4接続のみの提供に留まっているところが多く完全なIPv6への移行はまだまだ先であるだろう。
今後IPv6の移行のために技術者が多く必要になってくると思われるが、そのためには最新のIPv6技術、特にこれから数年はデュアルスタックに関する技術に注視していく必要がある。