(Wikipedia IPv6より)

Internet Protocol Version 6（インターネット プロトコル バージョン6）、IPv6（アイピーブイ6、アイピーバージョン6）は、Internet Protocolの一種で、OSI参照モデルにおいてネットワーク層に位置付けられるプロトコルである。

現在、主流のIPv4にかわるものとして、それまで約 2³²（= 約42億）個であったIPアドレスを約 2¹²⁸（= 約340澗）個まで使えるようにしたのが大きな特徴の一つである。340澗個のアドレスとは、340兆の1兆倍の1兆倍（340京の1京倍）のアドレス空間があるということである。

実際の運用では、回線事業者がエンドユーザのルーターに提供する最小単位は/64ブロックのことが多い。また、アドレスの下位の64ビットであるインタフェースIDは、一意性を得るためにMACアドレス等から生成されるEUI-64フォーマットが使用されることが多い。（/64でなければならないわけではない）

また、Webブラウザのアドレスバーに入力する場合など、URLのホストパートをIPv6アドレスで指定したいときは、例えば::1ならば[::1]のように半角の角括弧でくくる。[RFC 3986]

現在の状況

日本国内では、一部のISP（接続業者、ホスティングサーバ業者）によって商用・実験サービスが開始されているほか、NTT東日本及びNTT西日本によって、一部のフレッツ網で利用されている。また、日本国内におけるISP各社の対応については、でまとめられている。

なお、アメリカでのアメリカ国防総省によるIPv6化宣言により、アメリカにおいてもIPv6化が進むことが期待されている。

また今後、IP放送、IPテレビ電話及びIP電話等のエンドユーザサービスにIPv6を採用することが進むとも考えられ、そのようなIP上の専用サービスがIPv6の普及の牽引役となることも期待される。

なお、IPv6のプロトコルを有効にしているWindowsを使用しているユーザの場合、Microsoftが無償提供するTeredoサービスを利用する形で、通信速度に問題があるものの、既にデフォルトでIPv6で通信可能な状態になっている場合がある（ただし、Teredoサービスを利用している場合には、DNSクライアントの仕様のため、事実上IPv6が使用できない）。

2011年2月3日にIANAにプールされていたIPv4アドレスが「在庫切れ」となったため、日本でのIPv4アドレスは2011年4月に枯渇した。今後は、IPv6を使用しなければ新規にグローバルIPアドレスを取得できなくなる。

2012年6月6日にWorld IPv6 Launchとして、主なインターネットサービスを一斉にIPv6に完全移行させるイベントが実行された。参加したノードやプロバイダーは今後IPv6も対応してインターネットサービスを提供し続ける。

背景

概要

IPv6が誕生した背景には、IPアドレス枯渇問題がある。

1980年代までは、アメリカ国内を中心に、Class A (/8)、Class B (/16)、Class C (/24) などの単位で各組織にIPアドレスを割り振っていた。1990年代に入り、インターネットの国際化と、参加組織の増大によって、Class BのIPv4アドレスが不足する恐れが出てきた。IPアドレスの数が有限である以上、根本的な解決策が必要となることは自明であり、その解決策として検討された最終成果がIPv6である。

しかし、新しいプロトコルであるIPv6を開発し普及させるには時間がかかる。そのため、当面の短期的な対策として、プライベートアドレス (RFC 1918) の導入やCIDR (RFC 4632)、NAT (RFC 2663) などにより、IPv4アドレスを節約および有効活用することで枯渇を回避しているのが現状である。

一部には、IPv4アドレス枯渇には、既存の回避策で対応可能であるとIPv6の必要性を疑問視する声もあった。しかし、国際的なインターネットの爆発的な普及と、携帯電話やスマートフォンなどのインターネット利用機器が急速に増加したことにより、新たなIPアドレスの需要が、運用の改善や新たな回避策によるIPアドレスの供給を上回っており、限界に達しようとしている。また、回避策による弊害も顕著になってきており、インターネットの新たな利用形態の普及を阻害している。

現在は、IPv6の運用に目途がたったことから、IPv4との共存方法やIPv6への移行方法が課題になっている。

IPv6開発の推移

• 1981年9月 RFC 791として、現在のIPv4のもととなる仕様が公開される。
• 1991年7月 「IPv4アドレスが不足する」という研究を受けてIETFが調査を開始した。
• 1992年11月 RFC 1380という形で調査結果をまとめ、次世代ネットワークの議論が始まる。
• 1993年12月 RFC 1550としてIPngの名称で機能要求をまとめる。
• 1995年1月 RFC 1752としてSIPPをベースにアドレスを128bit化、同時に名称をIPngからIPv6に正式に改名。
• 1995年12月 RFC 1884 IPv6 Addressing ArchitectureとしてIPv6の最初の仕様を決定。
• 1998年7月 RFC 2373として仕様を大幅修正。同時期にIPv6関係RFCも大幅に改定。
• 1998年12月 RFC 2460 Internet Protocol, Version 6 (IPv6) Specificationとして主な仕様が確定する。
• 1999年07月 IANAによるIPv6アドレスの割り振りが開始される。
• 1998年以降、、、、などにより、UNIX系OSへの実装とテスト運用が行われ、2006年頃までに主要部分の実装が完了した。Windowsに関しては、1998年3月Windows NT 4.0用にMSRIPv6を、2000年3月Windows2000用に技術プレビューを、2001年10月にWindowsXP用に評価版を提供したのち、WindowsXP SP1およびWindows Server 2003からサポートが行われるようになった。
• 2011年2月3日にIANAにプールされていたIPv4アドレスは枯渇した。
• 2011年4月15日にAPNICのIPv4アドレスの在庫は、/8ブロック換算で1ブロック未満になり、アジア太平洋地域では、事実上IPv4アドレスは枯渇した。各RIRの最後の1ブロックについては、自由に取得することはできず、IPv4の安定運用とIPv6への移行のために限定的な割り振りが行われる。
• 2011年6月8日にWorld IPv6 dayとして、主なインターネットサービスのDNSのAAAAレコードを有効にすることで、インターネット環境でIPv6を並行運用した場合の問題点を見つけ出すテストを行うイベントが実施された。
• 日本国内については、NTTのフレッツ光ネクストにおいて、IPv6 PPPoE接続が2011年6月1日に、IPv6 IPoE 接続が2011年7月21日に提供され、他社のサービスを含めると、IPv6が一般に普及するための基盤が整った状態になった。
• 2012年6月6日にとして、主なインターネットサービスを一斉にIPv6に完全移行させるイベントが企画されている。World IPv6 dayでは、一時的なものだったが、World IPv6 Launchでは、それ以後も継続的にIPv6でインターネットサービスを提供し続ける点が異なる。

IPv6導入による得失

メリット

一般に言われているIPv6導入によるメリットとしては以下のようなものが挙げられている。

• 事実上無限の数のIPアドレス
  • アドレス枯渇の心配がほぼ解消される。実際には非常に大きな有限の数（2¹²⁸個 = 340,282,366,920,938,463,463,374,607,431,768,211,456個 = 約340澗個 = 約340兆×1兆×1兆個）であるが、「その辺の石ころにも個別に割り当てることができる」ぐらいあり余っている。
  • 仮に、地球の全人類（約7,000,000,000 = 70億人）へ均等に割り当てられるとしても、1人あたり約48垓6,000京個 = 4.86×10²¹個という天文学的な数になり、一生かけても使い尽くせないほど巨大な数になる。
  • 同時に、IPマスカレード（NAT/NAPT等）を使わずに済むので、全ノードがグローバルな接続性を持ち、直接接続が可能になる。これによって、P2Pアプリケーション（IP電話、インスタントメッセンジャー及びネットワークゲーム等）の利用が容易になり、またNATの設定等に気を遣わなくて済むようになる。
  • 実際にOCNによるIPv6サービスでは、月額300円で/64のネットワークブロックを2ブロック提供するサービスを実施している。このサービスを受けることで、理論的には300円の月額で、一人あたり約43億の2乗（2の64乗、IPv4におけるIPアドレスの総数の2乗）ものアドレス空間をもつネットワークブロックを2つ取得することができる。
• IPsecによるIPレイヤでのend to endセキュリティの確保にあっては、ユーザ認証、パケットの暗号化及びなりすまし防止等がサポートされた。これらはIPv4を使う環境では上位レイヤ (TLS) 等で補完しなければならなかった機能である。
  • 一部で「IPv6の実装にはIPSecが必須である」と言われているが、これは規格上 (RFC) の話で、IPSecをサポートしないIPv6の実装は多数存在している。
• 管理者に負担をかけないIPアドレスの自動設定
  • DHCPサーバがなくても、ホストには自動的にIPアドレスとデフォルト経路が設定される。
• アドレスの集約による基幹ルータでの経路表サイズの抑制
  • 新たにIPv6の接続を持つとき、ISPの持っているIPv6アドレス（プリフィックス）を切り出してユーザーに渡す。これによって、新しいIPv6サイトが増えたとしてもバックボーンに対して公告する経路情報は増えず、基幹ルータで保持する経路表の大きさが抑えられる。その一方で、アドレスブロックの可搬性がなくなる、複数のISPと契約した時にどのアドレスをどのように使うかを考慮しなければならない「マルチホーム」問題も発生する。
• 固定長ヘッダ
  • IPv6の基本的なヘッダは固定されているため、ルータの負荷を低減できるなどATM等の固定長パケットネットワークに共通な利点を享受しつつ、また拡張性も保つ。
• エラー検出
  • IPv4ではレイヤ3 (IP) で各ルータのホップ毎に行われていたエラー検出をIPv6では廃止し、レイヤ4（TCPv6/UDPv6等）以上の上位層で、エンドツーエンド (end-to-end) でエラー検出を行うこととされた。これにより前項と同じくルータの負荷低減等が期待される。

デメリット

既存のIPv4と共存させる必要があることから、次のようなデメリットや課題が発生する。

• IPv4と似たプロトコルではあるものの、互換性がないため、ルータの取替えや新しいソフトウェアの開発・導入などで追加投資を免れない。また、並行運用期間（IPv4が淘汰され消滅するまで）は両方のプロトコルをサポートしなければならない。
• そもそも、汎世界的なネットワークとなったインターネットが、遍くIPv6に移行するのかどうか、するとしてそれが何時になるのかは、（短期的には）全くの見通しが立っていない。これは、古い機材やOS、ファームの更改により徐々にIPv4/IPv6併存環境が広がっていくことである程度緩和されうる。IPv6は2010年現在では、まだに至っていない。
• IPv6のバックボーンはまだIPv4ほど充実していない。また、末端ユーザー/サイトのIPv6接続は、2011年4月時点ではほとんどの場合IPv4によるトンネリングである。そのため、IPv6で接続するとかえって通信性能が低下する場合が多い。また、IPv6での接続に失敗することもままあり、その場合IPv4にフォールバックすることになるが、最初からIPv4で接続していれば不要であったはずのタイムラグが生じてしまう。
• 前項とも関連するが、現状のIPv6ネットワークはトンネリングやDNSなどをIPv4に依存しているため、IPv6を導入しても管理の手間が増えこそすれ、耐障害性が増すわけではない（IPv4がダウンすればIPv6もダウンしてしまう）。
  • 今後はIPv6メインとしてIPv4をトンネリングしたネット構成の増加が見込まれている。
• アドレス空間が広いことと、MACアドレスによる自動設定のため、逆引きの管理が困難であり、逆引きを要求されるケースで困ることがある（逆引きできないホストからの接続を拒否するサーバなど）。
• 技術面や運用面でまだ不確定な要素が多い（サイトローカルアドレスの廃止、エニーキャストアドレスの見直しとDHCPv6の再検討、逆引きの問題など）。
• IPv4では、NATやIPマスカレードの必要性から中継機を介して間接的にインターネットと接続した結果、「インターネット側から具体的なホストが見えない」という点（= 匿名性）がセキュリティおよびプライバシー上都合が良い場合も多い。IPv6において後述のEUI-64で生成したアドレスを静的に割り当てる場合にはユーザの追跡が可能になるなど特にプライバシーの面で問題が発生する。これに対処するためRFC 3041でPrivacy Extensions for Address Configuration in IPv6が定められ、Windows XP等がこれをサポートしている。
• ユーザーのインターネットプロトコルに対する認識度が低く、IPv6に移行するメリットが見出だしにくい。マーケティング手法の観点からは、エンドユーザーが選択するのは、内部プロトコルではなくエンドサービスであり、内部プロトコルの相違をエンドユーザーに訴求する必要性は低い。
  • ただ、冒頭に記したように2011年4月に日本でのIPv4アドレスの在庫が払底したこともあり、サーバやVPN開設など何らかの理由で固定IPアドレスを必要とする場合、今後はISPやホスティング業者の保有するアドレス空間の使用状況にもよるが、いずれにせよIPv6でのIPアドレスの取得を検討せざるを得なくなる可能性が大きい。

IPv6 のアドレス

IPv6 のアドレス構造

IPv4とIPv6の最も大きな違いは、そのネットワークアドレスの長さにある。従来までのIPv4が32ビットであったのに対し、IPv6は128ビットである。

IPv6のアドレスは、前半部（プレフィックス,ネットワークID）と後半部（インタフェースID）に分けられて管理される。インタフェースIDは一意性を得るためにMACアドレス等から生成されるEUI-64フォーマットが使用されることが多いが、必ずこの形式を使わなければならないということではない（特に、サーバでは手動で静的に設定されることが多い）。

アドレスの一意性は最終的にはDuplicate Address Detection (DAD) という仕組みで保証される。

IPv6 のアドレス表記

従来のIPv4では、アドレスの値を8ビット単位でドット（.）で区切り、十進法で表記する。
[例] 192.0.2.1
IPv6では、128ビットを表記する際、IPv4と同様の表記では冗長になりすぎるため、アドレスの値を16ビット単位でコロン（:）で区切り、十六進法で表記する。
[例] 2001:0db8:bd05:01d2:288a:1fc0:0001:10ee
この方法でも、まだ冗長であるため、以下のルールが適用される場合がある。

• あるセクションが "0" で始まる場合、当該先行する "0" を省略することができる。

[例] 2001:0db8:0020:0003:1000:0100:0020:0003 = 2001:db8:20:3:1000:100:20:3

• 16ビット単位の記述で "0" が連続するところは "::" で省略することができる。ただし、"::" は可変長なので、1箇所だけ使用できる。

[例1] 2001:0db8:0000:0000:1234:0000:0000:9abc = 2001:db8::1234:0:0:9abc
[例2] 2001:0db8:0000:0000:0000:0000:0000:9abc = 2001:db8::9abc
上記のルール ([RFC 4291]) では同じIPv6アドレスに複数の表記が許容されることになる。

アドレスの表記を唯一に統一し単純化するためのルール ([RFC 5952]) も存在し、同RFCの§4に従うと、以下のようになる。

• あるセクションが "0" で始まる場合、当該先行する "0" は必ず省略する。
• 16ビット単位の記述で "0" が2回以上連続するところは、連続する "0" がいちばん長いフィールドを必ず "::" で省略する。
  • 連続する "0" の長さが同じ箇所が複数個ある場合は、最初（上位側）を省略する。
  • 連続しない1回だけの "0" は省略してはならない（RFC 4291ではこの省略は許容されている）。
• 英字部分は必ず小文字を使用する。

その他、アドレスの種類によっては、以下のような特殊な表記が用いられることがある。

• IPv4互換アドレスやIPv4射影アドレスでは、下位32ビットにIPv4アドレスが埋め込まれる。そのため、その部分だけIPv4の表記にすることが多い。
  • [例] ::ffff:192.0.2.1
• リンクローカルアドレスは一つのリンク（サブネット）内でしか一意でない。そのため、ホストから見た場合、何らかの方法でネットワークインターフェースを指定してリンクを特定しなければならない。アドレス末尾に % 記号を介してインターフェースの番号や名称を付加するのが一般的である。
  • [例] fe80::0123:4567:89ab:cdef%4, fe80::0123:4567:89ab:cdef%fxp0

また、サブネットマスクは2001:0db8:9abc::/48のように表記される。この場合、先頭から48ビット (2001:0db8:9abc) がネットワークアドレス部である。ただし、IPv4と異なり、グローバルアドレスのエンドユーザーへの割り当て単位が通常は /48 か /64 であることから、通常目にするサブネットマスクは /48 か /64 であり、あまり意識することはない。これより大きい単位（/32 や /16 など）のサブネットマスクは、IPv6のアドレス体系、ルーティング及びISPに対する割り振り等の議論の際に登場する。

IPv6アドレスの種類

IPv6には、以下のような3種類のアドレスがある。

ユニキャストアドレス

一つのインタフェースに付与されているIPアドレス。一つのインタフェースを認識する。一つのコンピュータに多くのインタフェース（LANボード等）が実装されている場合は、インタフェースの数だけユニキャストアドレスを持つことになる。

マルチキャストアドレス

複数のノードに割り当てられるアドレス。このアドレスあてに送信されたパケットは、複製されてこのアドレスに参加しているノードに配送される。ffxx:: で始まるアドレス。返信にはユニキャストアドレスが指定される。送信元がマルチキャストアドレスのパケットをルータは中継してはならない。

なお、IPv6にはブロードキャストアドレスというものは存在しないが、必要な場合は、オールノードマルチキャストアドレス (ff02::1) を使う。

エニーキャストアドレス

一つのアドレスが複数のノードに割り当てられているという点ではマルチキャストと似ているが、エニーキャストの場合は「そこに属しているノードの中で、ネットワーク上で一番近いノードのどれか一つのみに配送される」という点が異なる。返信にはユニキャストアドレスが指定される。送信元がエニーキャストアドレスのパケットをルータは中継してはならない。

さらに、パケットの到達範囲（スコープ）によって、上記のアドレスそれぞれに対しリンクローカルスコープとグローバルスコープのアドレスが存在する。

リンクローカルスコープ

あるリンクでのみ一意なアドレス。このスコープあてのパケットはルータを越えて配送されることはない。

グローバルスコープ

全IPv6で一意なアドレス。

以前はサイトローカルスコープというものもあったが、ほとんど使われないまま廃止された。

特殊なアドレス

0:0:0:0:0:0:0:0

未指定アドレス (Unspecified Address) として定義されている。0 を省略して 0::0 や :: とも表記される。このアドレスはノードにまだアドレスが割り当てられていないことを意味し、ノードに割り当てられることはない。ノードの初期化段階において、アドレスの重複をチェックする場合などに送信元アドレスとして使用される。

0:0:0:0:0:0:0:1

ループバックアドレスとして定義されている。0 を省略して 0::1 や ::1 とも表記される。IPv4では 127.0.0.0/8 の範囲の任意のアドレスをループバックアドレスとして使用できるが、IPv6 ではこのアドレスに限られる。ループバックアドレスであるため、このアドレスをインターフェイスに割り当てることはできない。

使用されているアドレス

IPv6を利用していて通常目にするアドレスは、グローバルユニキャストアドレスかリンクローカルユニキャストアドレスである。IPv6のアドレス空間については、#IPv6アドレス空間参照。

グローバルユニキャストアドレス

ルータを超えて、インターネット上で通信可能なアドレスで、グローバルアドレスとも呼ばれる。IANAが割り振りを管理しており、RIR単位での割り振りは、で公開されている。現在は、RFC 3587により、アドレスの先頭3bitが001であるアドレスのみIANAが割り振りを行っている。

128ビットの内訳

（グローバル・ルーティング・プリフィックスは、IANA、RIRおよびNIRからISPなどのLIRに割り振られたものの中から、ISPなどのLIRがエンドユーザに割り当てられたものを使用する。）

このうち、特定の用途に使用されているものとしては、以下のものがある。

リンクローカルユニキャストアドレス (RFC 1884)

各ネットワークインターフェース毎に、初期化時に自動生成し、LANの同一セグメント内でのみ有効なアドレス。IPv6のルータでは中継されないため、インターネット上では使用できない。プレフィックスは常に fe80::/64となる。

128ビットの内訳

ユニークローカルユニキャストアドレス (RFC 4193)

IPv4におけるプライベートアドレスと同様に、ローカルでの使用向けに使われるアドレス。

fd00::/8 アドレスの一部をランダムに生成して使用する。完全な一意性は保証されないものの、異なる組織でアドレスが重複する可能性は低い。

128ビットの内訳

（グローバルIDは、各ネットワーク単位で乱数を用いて決定することになっている。国際機関で一意に管理されている値ではないため、ユニークローカルユニキャストアドレスはローカルアドレスであってグローバルアドレスとしては運用できない。）

プロトコル

ヘッダ

IPv6のヘッダはIPv4ではあまり使われなかったものが廃止されるなど簡略化されているが、アドレス長が長くなっているので、ヘッダ長はIPv4の20バイトから40バイトに増加している。

また、様々なオプションがエクステンションヘッダとして定義され、これは前のヘッダが次のヘッダのタイプを示すことで数珠つなぎにすることが可能となっている。
また使用する順番がほぼ固定されている。主に送信元や中継のルータが使用するオプションは前の方に、到着したルータやノードに対してのオプションは最後の方に定義される。

IPv6で定義されているエクステンションヘッダは次の通り。

ホップバイホップオプション

途中通過するルータで処理されるオプションが格納されているヘッダ。

宛先オプション

最終あて先ノードで処理されるオプションが格納されているヘッダ。

経路ヘッダ

途中通過する経路のIPアドレスを格納したヘッダ。ソース・ルーティングに使用される。IPv4のルーティングヘッダとほぼ同じ。

フラグメントヘッダ

フラグメント情報を格納するヘッダ。IPv6では途中のルータがフラグメントを分割・再構成することはなく、送信元でのみ行われる。送信・受信の各ホストで経路MTU探索 (Path MTU Discovery) を行い、MTUを制御する。

認証ヘッダ

IPsec AHの認証データを格納するヘッダ

ペイロード暗号化ヘッダ

IPsec ESPの情報を格納するヘッダ。暗号化されたパケットは、IPヘッダとこのESPヘッダ以外は暗号化される。

近隣探索 (Neighbor Discovery)

IPv4 では通信相手の IP アドレスからその MAC アドレスを取得するために ARP を用いていたが、IPv6 では近隣探索 (Neighbor Discovery) という方法が用いられる。

これは、ICMP の IPv6 版である ICMPv6 を用いてアドレス解決するもので、アドレス解決をしたいノードはペイロードに解決したいアドレスを格納して、全ノード宛マルチキャストアドレスに IPv4 の ARP request に相当する Neighbor Solicitation (NS) パケットを送信し、それに答えるべきノードは、Target linklayer address option に自ノードの MAC アドレスを格納した Neighbor Advertisement (NA) を送信してアドレス解決を行う。
RFC 4861 で規定されている。

アドレス自動設定

IPv6ではDHCPを用いなくてもルータさえあればアドレスの自動設定が可能となっている (RFC 4862)。

IPv6ノードのネットワークインタフェースには、必ず linklocal address というそのリンクだけに到達性のあるアドレスがつく。これは fe80:: というプリフィックスと、MACアドレスから生成されたインタフェースIDとから生成されるのが通常であるが、そのリンク内で一意であれば手動で設定してもかまわない。最終的にはアドレスの一意性はDADに基づいて解決される。

また、ルータは自分の接続しているネットワークに対し、定期的にあるいは要請に基づいて、そのネットワークに関する情報（Router advertisement; RA）を送信している。この情報に含まれるプリフィックス情報と一意のインタフェースIDを用いて、IPv6ホストはグローバルアドレスを生成する。同時に、そのIPv6ホストは受信したRAを送信したルータをデフォルト経路に設定することで、グローバルIPv6ネットワークへの接続性も確保できる。

しかし、この仕組みでは名前解決のためのDNSサーバのアドレスを取得することはできないため、それにはDHCPv6など別の仕組みが必要になる。

IPv6をサポートするプログラムの書き方

IPv6を使うためには、OSの他、アプリケーションでもサポートしなければならないが、それはIPv4上でのプログラムと比べても大きな違いがあるものではない。

ネットワークを利用するプログラムではソケットを利用することが多く、通常のIPv4プログラミングでsocketを作成するときには

s = socket(AF_INET, SOCK_STREAM, 0);

のように、アドレスファミリ部をIPv4固定で指定することが多いが、一つのサイトがIPv4とIPv6の両プロトコルに対応している場合や、どちらに対応しているのか事前にはわからないことを考慮すると、DNSで一つの名前を検索した後、列挙された複数のプロトコルのアドレスに対して順番にconnectを試みる必要がある。

アドレスを検索する際は、IPv4のみを前提としているgethostbyname() や、socket同様にアドレスファミリ固定であるgethostbyname2() などではなく、getaddrinfo() を利用する。

以上をまとめると、典型的なソケットを作成するCのコードは以下のようになる。

int error, s;
struct addrinfo hints, *res, *res0;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;    /* TCPの場合 */
if ((error = getaddrinfo("ホスト名", "サービス名", &hints, &res0)))
    return (-1);
for (res = res0; res; res = res->ai_next) {
    if ((s = socket(res->ai_family, res->ai_socktype, res->ai_protocol)) < 0)
        continue;
    if (connect(s, res->ai_addr, res->ai_addrlen) == 0)
        break;
    close(s);
    s = -1;
}
freeaddrinfo(res0);
if (s < 0) {
    /* Could not connect */
} else {
    /* Success */
}

この手法はIPv6のみならず、別のIPプロトコルが登場した場合にも有効な手法で、プロトコル独立プログラミングなどと呼ばれる。

なお、ここで示した方法は、getaddrinfo() によって返されるアドレスファミリの順に接続を試みるので、AAAAレコードより先にAレコードを返すようなgetaddrinfo() では、IPv6による通信が行われない可能性もある。

IPv4との相互運用

IPv4との互換性

概念的にはIPv4とIPv6はほぼ同等と言えるが、実際のパケットフォーマットは完全に異なる上、IPアドレス空間の大きさも違うため、一対一対応はできない。そのため、IPv6ノードとIPv4ノードが互いに直接通信することはできない。そのため、IPv6とIPv4との通信用にいくつかの仕組み、プロトコルが提案されている。

• デュアルスタック
  • ルータやサーバなどの機器にIPv4とIPv6の両アドレスを割り当て、 どちらの方式でも通信できるようにする仕組み。
• TCP Relay (faith)

また、IPv6/IPv4トランスレータと呼ばれる装置によって、プロトコル変換を行う方法がある。例えば、Proxy方式では、OSI参照モデルで上位層であるアプリケーション層でプロトコル変換を行うことで、ネットワーク層であるIPプロトコルの違いを隠蔽している。これにより、利用者からみた場合、IPv4のプライベートアドレスが使用されているLAN内から、IPv4/IPv6に関係なくURLで、インターネット上のサイトにアクセスできるように見える。

トンネリング

IPv6のネイティブな接続を提供しているISPはまだ極めて少ない。そのため、ほとんどのIPv6ユーザーはIPv4上にIPv6をトンネリングして利用している（商用のIPv6サービスもその多くはトンネリングである）。

トンネリングに用いられる技術には以下のようなものがある。

1. IPv4のネットワーク上でIPv6のパケットを搬送するためのトンネリング
   • 6over4 (RFC 2529)
   • 6to4 (RFC 3056) : 品質が保証されない、パケット盗聴などのセキュリティ問題が起こりやすいという理由で、
   • Teredo (RFC 4380)
   • ISATAP (RFC 5214)
   • 6rd (RFC 5569)
   • 6in4 (RFC 4213)
2. IPv6のネットワーク上でIPv4のパケットを搬送するためのトンネリング
   • IPv4 over IPv6 (RFC 2473)

Windowsでの留意事項

Windowsでは、6over4、Teredo、ISATAP、6to4のみがOSとしてサポートされている。他の方式を使用するには、サードパーティ製のソフトウェアを追加する必要がある。

Windowsでは、IPv6のグローバルアドレスが設定されていない場合、Microsoftが無償提供しているTeredoによる接続サービスによるトンネリングを自動設定する。

Windowsでは、IPv4のグローバルアドレスが設定されている場合、Microsoftが無償提供している6to4による接続サービスによるトンネリングを自動設定する。

Windows Vista以降による接続では、ホスト名で通信相手を指定した場合にIPv6で通信できない場合がある。これは、ホスト名のアドレス解決においてホストにリンク ローカル アドレスまたは Teredo アドレスしか割り当てられていない場合、DNSクライアントサービスはIPv4用のAレコードに関するクエリだけを送信するためIPv6アドレスが取得できないためである。この場合、ホスト名では通信対象のIPv6アドレスを特定できず、URLで直接IPv6アドレスを指定したりしない限り、指定した相手にIPv6で通信することはない。

UNIX系OSでの留意事項

基本的にカーネルの版数やディストリビューション、パッケージの構成に依存するため、どの方式のトンネリングが使用できるかは明示できない。Linuxの場合、ディストリビュータによるサポート範囲では、6over4、ISATAP、6to4程度である場合がある。

実際の導入と方式

実際にIPv6を導入する場合、既存のIPv4空間との通信も両立させるために、対応した設備の追加または変更が必要となる。

エンドユーザ向けのルーターなどのCPEについては、既存のルーターが持っていることが多いIPv6ブリッジ機能だけでは対応できない方式が多く、ルーターの変更が必要になる可能性が高い。

サーバー側についても、対応した設備の追加または変更が必要となる。OSやミドルウェア（サーバソフト）については、IPv6対応のものが増えてきているので対応が容易である。しかし、サービスを提供するアプリケーションや、コンテンツについては、IPv6対応を考慮していないものが多く、対応が困難な場合がある。

なお、IPv6とIPv4を共存させる方式として、以下のようなものがある。ただし、どの方式によるかは接続するプロバイダや通信環境などに依存する部分が多い。

6rd方式、および、その派生方式

6rd (IPv6 rapid deployment) は、RFC 3056で標準化されているIPv6/IPv4トンネリング技術である6to4を土台として設計された方式である。基本的には途中のIPv4空間にIPv6の信号を流すためのトンネルを設定する形である。2011年4月時点で「IPv6接続サービス」として提供されているものは、この方式が多い。

流れとしてはエンドユーザ (v6) →6rd対応ルータ（v4トンネル入口）→v4網→リレールータ（v4トンネル出口）→v6網 となる

導入は比較的容易であり、エンドユーザ側については、設定変更やIPv6の接続用アプリケーションの追加のみで対応できる。しかし、IPv4網内にIPv6信号をトンネリングさせる関係上、各端末にIPv4のグローバルアドレスを割り当てるため、使用するIPv4のIPアドレスの数は減らず、IPv4のIPアドレス枯渇問題を解決することにはならない。ISPが用意しているIPv4のIPアドレスの在庫が枯渇した時点で、新規にユーザを増やすことができなくなる。

類似の方式としては、RFC 4380で標準化されているTeredoがある。Teredoについては、Microsoftが、Windowsのユーザ向けに無償提供しているIPv6接続サービスをデフォルトで使用できるようにしていることから、潜在的普及率は高い。ただし、Windows Vista以降による接続では、ホスト名のアドレス解決においてホストにリンク ローカル アドレスまたは Teredo アドレスしか割り当てられていない場合、DNSクライアントサービスはIPv4用のAレコードに関するクエリだけを送信するためIPv6アドレスが取得できず、URLで直接IPv6アドレスを指定したりしない限り、指定した相手にIPv6で通信することはない。

IPv6とIPv4のデュアルスタック (DS) +NAT444方式、および、その派生方式

IPv6については、そのまま接続し、IPv4については複数階層のNAPT (NAT444 : ()) を経由する方式である。イメージとしては、現在のルータなどを使った複数端末のIPv4接続で使用しているNAPTを複数回行って、接続に使用するIPv4のIPアドレスを節約しようとするものである。

IPv4についての流れはエンドユーザ（v4プライベート）→ユーザNAPT（v4グローバル共有）→ISPNAPT（v4グローバル単独）→v4網 となる

複数の端末で、IPv4のグローバルアドレスを共有する関係上、端末当たりのセッション数が制限され、アプリケーションが正常に利用できない場合がある。また、プロバイダ側で管理する通信ログの扱いが煩雑であり、負担が大きい。IPv4による通信では、多段NATとなるため、エンドユーザー間でのP2Pによる直接通信は不可能となる。

導入に関しては、比較的容易である。特に、IPv6ブリッジ機能があるルーターを使用している場合には、エンドユーザ側については、設定変更やIPv6の接続用アプリケーションの追加のみで対応できる場合がある。

DS-lite (Dual-stack lite) 方式や、SAM () 方式、および、それらの派生方式

IPv4/IPv6トンネリング技術であるIPv4 over IPv6トンネルを土台として設計された方式である。イメージは6rd方式とは逆に、途中のIPv6空間にIPv4の信号を流すためのトンネルを設定しする形である。大雑把には、ユーザ側で行うIPv4のプライベート⇔グローバルアドレス変換をISP側に移し、さらにIPv6も共存させる形になる。

DS-liteの場合、IPv4についての流れはエンドユーザ（v4プライベート）→ユーザ接続装置（v6トンネル入口）→v6網→ISPNAPT（v6トンネル出口・v4グローバル共有変換）→v4網 となる。

SAMの場合、IPv4についての流れはエンドユーザ（v4プライベート）→ユーザ接続装置（v6トンネル入口・v4グローバル共有変換）→v6網→ISPNAPT（v6トンネル出口）→v4網 となる。

v4グローバル共有変換部分で、ユーザ単位で使用可能なポートの範囲を制限することで、IPv4アドレスの共有を行う。NAPTの階層を複数にする代わりに、単段のNAPTを分割使用するイメージになる。そのため、エンドユーザ向けのルーターなどのCPEは既存のものが使用できず、該当する方式に対応したものに変更する必要がある。前記DS+NAT444方式同様、複数の端末で、IPv4のグローバルアドレスを共有するため、端末当たりのセッション数が制限され、アプリケーションが正常に利用できない場合がある。プロバイダ側で管理する通信ログの扱いが煩雑であり、負担が大きい。しかしながら、IPv4による通信では、NAPTが単段であるため、通信相手に制限があるが、UPnPなどを利用したP2Pによる直接通信は可能になる。

利用できるシステム

以下のように、現在家庭や企業で利用されている多くのシステムがIPv6に対応している。

• UNIX系のオペレーティングシステム（BSD、Linux、Solaris、Androidなど）
• Windows XP以上
• Windows Server 2003以上
• Pocket PC 2003
• Windows Mobile 5.0
• 一部のルータ
• 一部のインターネットサービスプロバイダ

Windows関連の追加情報

• - Windows8は、厳密にはRFC 3484に準拠していない。30日毎にIPv6/IPv4の到達性を確認し、IPアドレスの優先度を変更する。
• Windows 2000にも実験的なIPv6の実装が提供されたことがあるが、その後のサービスパックとの整合性が考慮されていないため、不具合が出る可能性がある。

利用できるアプリケーション

FreeBSD, NetBSD, OpenBSD, Linuxなど

ほぼ全てのアプリケーションがIPv6対応を終えている。

Windows

OS付属のアプリケーションではInternet Explorer, Microsoft 管理コンソール, Windows Media Player, Windows PowerShell, リモートデスクトップ接続等のほか、telnet, ftpなどのコマンドラインアプリケーション。サードパーティ製品では、Mozilla FirefoxやOperaのほか、Apache HTTP Server、Meadow、Tera Term、PuTTY、FFFTP、NextFTPなど。詳しくはを参照。

Mac OS X

Mac OS X標準のネットワークライブラリを使用していれば、多くのアプリケーションでIPv6が利用可能。10.3まではSafariは独自のネットワークライブラリを利用しているため、IPv6の対応は不完全であったが、10.4以降は完全に動作している。

日本のNTTのフレッツ網におけるIPv6

NTTのフレッツ網は、実運用されているIPv6のネットワークとしては2011年現在で約1390万回線を有する世界最大級のネットワークである。NTTのフレッツ網では、IPv6のグローバルユニキャストアドレスで構築されている。グローバルユニキャストアドレスである理由は、

1. NTTがIPv6の採用を検討していた時点では、ユニークローカルユニキャストアドレスやとサイトローカルユニキャストアドレスに関する仕様変更が議論の的になっており確実に使用できる保証が無かったこと。
2. 今後NTTが予定している回線すべてにIPv6プレフィックスを配布するにはユニークローカルユニキャストアドレスではIPv6プレフィックスの数が足りないこと。
3. フレッツ網でユニークローカルユニキャストアドレスを使用してしまうと、ユーザ側でユニークローカルユニキャストアドレスを使用できなくなるためである。
4. また、マルチキャストによるコンテンツ配信のインフラ整備も計画されていた。

しかし、日本電信電話株式会社等に関する法律により、日本国外との通信業務が制限されていることから、グローバルユニキャストアドレスを使用していても、IPv6のインターネットに対する接続サービスをNTTが提供することができない。そのため、IPv6-IPv4フォールバック問題や、IPv6マルチプレフィックス問題が発生している。

IPv6接続サービス

NTTのフレッツ網では、NGNであるフレッツ光ネクストについては、インターネット (IPv6 IPoE) 接続とインターネット (IPv6 PPPoE) 接続の2つの方法により、ISPがIPv6のインターネットに対する接続サービスを提供している。

IPv6のインターネット接続サービスを提供していないBフレッツや光プレミアムの既存ユーザについては、フレッツ網内の通信用にIPv6が提供されている場合があるが、IPv6のインターネット接続サービスは提供されておらず、フレッツ光ネクストへの変更が推奨されている。フレッツ光ネクストに変更しないでIPv6のインターネットを使用する場合には、IPv4のインターネット上で提供されているIPv6接続用のトンネリング接続サービスを別途契約する必要がある。

インターネット (IPv6 IPoE) 接続

ISPがVNE接続事業者（BBIX株式会社、日本ネットワークイネイブラー株式会社 、インターネットマルチフィード株式会社）と契約して、ユーザはVNE接続事業者が振り当てるIPv6プリフィックスを使用してフレッツ網からVNE接続事業者を介して直接インターネットに通信する方式。

ユーザは、フレッツ・v6オプションを契約することが前提となるが、IPv6ブリッジ機能付きブロードバンドルータかフレッツ光ネクストでひかり電話を使用する際にレンタルされる光回線終端装置一体型のひかり電話対応HGW（ルータ機能内蔵）を使用していれば、追加機器なしでIPv6で通信できるようになる。また、フレッツ・v6オプションにより同じフレッツ網に接続されているユーザ間であれば、ISPやVNE接続事業者を介さずに直接に通信を行うことも可能となる。

ただし、VNE接続事業者が限定されており、ユーザが利用しているISPがそれらのVNE接続事業者と契約していない場合には、この方式を利用することができない。VNE接続事業者を増やすことも検討されているが、現在のVNE接続事業者の数の制限は、フレッツ網内のルーターに定義できるルーティング規則の数とルーターの性能によるものであるため、ネットワークの増強に伴うルーターの増強が一巡する数年後のことになると見込まれている。

ISPにとっては、IPv6接続を特定のVNE接続事業者に委託する形になるため、将来IPv6の通信量が増加していった場合に収益率が低下する恐れがある。そのため、利用状況や経済状況によっては、利用しているVNE接続事業者の単位でISPが整理統合される可能性もある。

インターネット (IPv6 PPPoE) 接続

IPv6トンネル対応アダプタ (MA-100) などにより、IPv4のPPPoE接続の場合と同様に、ISPとユーザー側ルーターをPPPoEのトンネリングで接続することにより、IPv6接続サービスを提供する方式。認証など細かな点に違いがあるが、ユーザーの視点で見ると、IPv4のPPPoE接続の場合にはトンネリング接続とNATが合わせて使用されるが、IPv6のPPPoE接続はフレッツ網に対してはNATが使用されるものの、インターネットに対しては単純にトンネリング接続してルーティングのみを行う点が異なる。なお、ISPとのPPPoE接続に失敗した場合でも、ISPが配布するIPv6プリフィックスの代わりにLAN上の機器にユニークローカルユニキャストアドレスのプレフィックスを広報することで、NAT機能によりNGN内の機器と通信可能になっている。

フレッツ光ネクストでひかり電話を使用する際にレンタルされる光回線終端装置一体型のひかり電話対応HGW（ルータ機能内蔵）や、既存のIPv4トンネル対応アダプタ付きブロードバンドルータでは、IPv6用のPPPoE接続機能がないため、新規にIPv6トンネル対応アダプタを導入する必要がある。

ISPにとっては、IPv6用に新規に設備を追加する必要があるものの、直接フレッツ網に接続できるメリットがある。しかし、ユーザに追加の負担をかけるIPv6トンネル対応アダプタが必要であるため、IPv6の普及が妨げられたり、追加の負担が少ないIPv6 IPoE接続のISPにユーザが移行してしまう危険性がある。

IPv6-IPv4フォールバック問題

NTTのフレッツ網においてフレッツ網のIPv6アドレスがクライアントに割り振られている場合に、DNSによる名前解決でAAAAレコードによるIPv6アドレスの返答をクライアントが受け取った場合に、IPv4によるアクセスが遅延する問題。

フレッツ網でクライアントに割り振られているIPv6アドレスは、グローバルユニキャストアドレスであるが、通常のIPv6のインターネットには接続されていない。そのため、IPv6のインターネット上のIPv6アドレスとIPv4のインターネット上のIPv4アドレスの両方をDNSから受け取ってしまうと、まずIPv6でアクセスを試みたのち、不到達になって、IPv4でのアクセスを試みるという動作になる。この再試行により、アクセス待ち時間の増大することが問題となる。
なお、フレッツ網以外の一般のIPv6のネットワークでも、ファイアーウォールでICMPv6の宛先不達(Destination Unreachable)をフィルタしていたり、インターネットに接続されていないLANであったりした場合には同じ問題が発生する。

最近は、アプリケーションによるRFC 6555 - Happy Eyeballs: Success with Dual-Stack Hosts の実装により、IPv6でのアクセスとIPv4でのアクセスとを同時に試みることで、緩和されつつあるが、根本的解決には、IPv6のインターネットへの接続サービスの契約が必要である。

また、Microsoft Windows 8では、RFC 6724(旧版 RFC 3484)の実装を変更することで、IPv6-IPv4フォールバック問題に対応している。具体的には、30日おきにMicrosoft によりホストされた IPv6 のみのサーバーに対する簡単な HTTP GETによるネットワーク接続テストを実行し、IPv6で実際に到達できるときにはIPv6を優先的に使用する。逆にIPv6で到達できない場合には、IPv4を優先する。Microsoftは、このアプローチによりブラウザーのエクスペリエンスだけでなく、標準 Windows API を使ってデュアル スタックの接続先に接続するアプリのエクスペリエンスが改善されるとしている。

IPv6マルチプレフィックス問題

NTTのフレッツ網においてフレッツ網のIPv6アドレスがクライアントに割り振られていて、かつ、IPv6のインターネットへの接続サービスの契約をしている場合に、それぞれからIPv6プレフィックスが配布されるために、一つのクライアントが複数のIPv6プレフィックスを持つことにより発生する問題。NTTのフレッツ網以外のネットワークであっても、複数のIPv6プレフィックスが配布される環境であれば、同じ問題が発生する。

この問題により、アプリケーションが通信を行う際に選択した送信元アドレスによって、通信相手先によって通信ができたり、できなかったりするトラブルが発生する。これは、フレッツ網のIPv6アドレスがグローバルユニキャストアドレスであるにも関わらずIPv6のインターネットと接続されていないことにより、致命的な問題となる。例えば、通常のIPv6のインターネット上のホストと通信したいのに、送信元アドレスとしてフレッツ網のIPv6アドレスを選択してしまうと、IPv6のインターネット上のホストとのルートを確保できないため通信を行うことができない。

解決策としては、RFC 6724（旧版 RFC 3484）のポリシーテーブルでネットワークを仮想的に分離するものと、ルーターによる解決策がある。ポリシーテーブルによる対応について、Microsoftは、として設定方法を公開する一方で、総務省の研究会に提出した資料において問題が発生する可能性があるため少なくともWindowsマシンでは設定しないように勧告している。ルーターによる解決策としては、ユーザ側ルーターからクライアントに広報するIPv6プレフィックスをISP側のIPv6プレフィックスに限定し、ユーザ側ルーターで正しい送信先に振り分ける方法がとられる。ユーザ側ルーターの方式には、ISPとのネットワークの接続形態によって、上記のインターネット (IPv6 IPoE) 接続またはインターネット (IPv6 PPPoE) 接続を用いる。

なお、Bフレッツや光プレミアムのユーザにフレッツ網のIPv6アドレスが割り振られていて、かつ、IPv4のインターネット上で提供されているIPv6接続用のトネリング接続サービスを契約している場合にも、IPv6マルチプレフィックス問題が発生する。Bフレッツや光プレミアムについては一部地域を除き新規申し込みを中止して暫時縮小していく方針であることから、フレッツ網のIPv6アドレスをユーザ側ルーターで遮断する以外には具体的な対策がなく、NGNであるフレッツ光ネクストに移行することが推奨される理由ともなっている。

IPv4/IPv6二重投資問題

ISPにとっては、既存のIPv4接続とIPv6接続の2つのネットワークを個別に維持していく必要があり、二重投資によるコストアップが問題になっている。現在、IPv4 over IPv6 (RFC 2473) によりネットワークの一元化を行う検討が行われている。ただし、インターネット (IPv6 PPPoE) 接続と同じく、IPv4 over IPv6に対応したルータが必要となる。コスト削減のために、IPv4 over IPv6やインターネット(IPv6 PPPoE)接続に対応した新型の光回線終端装置一体型のひかり電話対応HGW（ルータ機能内蔵）の開発も検討されている。