IPv6

インターネット プロトコル バージョン 6
プロトコルスタック
IPV6ヘッダーの図
IPv6ヘッダー
略語IPv6
目的インターネットワーキングプロトコル
開発者インターネットエンジニアリングタスクフォース
導入1995年12月 （1995-12）
に基づくIPv4
OSI層ネットワーク層
RFC(s)2460,8200​​

インターネットプロトコルバージョン6（IPv6 ）は、ネットワーク上のコンピュータの識別と位置のシステムを提供し、インターネット上のトラフィックをルーティングする通信プロトコルであるインターネットプロトコル（IP）の最新バージョンです。IPv6は、長い間予想されていたIPv4アドレス枯渇の問題に対処するためにインターネット技術タスクフォース（IETF）によって開発され、 IPv4を置き換えることを目的としていました。[ 1 ] 1998年12月、IPv6はIETFのドラフト標準となり、[ 2 ]その後、2017年7月14日にインターネット標準として承認されました。 [ 3 ] [ 4 ]

インターネット上のデバイスには、識別と位置定義のために固有のIPアドレスが割り当てられます。1990年代の商用化後、インターネットが急速に成長したことで、デバイスを接続するには、IPv4で提供されていた40億（2の32乗）のアドレスよりもはるかに多くのアドレスが必要になることが明らかになりました。1998年までに、IETFは後継プロトコルであるIPv6を正式化しました。IPv6は128ビットのアドレスを使用し、アドレス空間は合計2の128乗、10の38乗、つまり340冪兆となります。IPv4とIPv6の相互運用を可能にするための移行メカニズムがいくつか考案されていますが、IPv6はIPv4と下位互換性がなく、両者は直接相互運用できません。

IPv6は、アドレス空間の拡大に加え、他の技術的な利点も提供します。特に、階層的なアドレス割り当て方式が可能になり、インターネット全体にわたる経路集約が容易になり、ルーティングテーブルの拡張が抑制されます。マルチキャストアドレスの使用が拡張・簡素化され、サービス配信の最適化がさらに強化されます。プロトコルの設計においては、デバイスのモビリティ、セキュリティ、および設定に関する側面が考慮されています。

IPv6アドレスは、4桁の16進数字をコロンで区切った8つのグループで表されます。完全な表現は、特定の規則に従って短縮される場合があります。例えば、2001:0db8:0000:0000:0000:8a2e:0370:7334は、2001:db8::8a2e:370:7334になります。

主な特徴

IPv6アドレスで使用される用語集

IPv6 は、パケット交換インターネットワーキング用のインターネット層プロトコルであり、プロトコルの前のバージョンであるインターネット プロトコル バージョン 4 (IPv4)で開発された設計原則に厳密に準拠して、複数の IP ネットワーク間でエンドツーエンドのデータグラム転送を提供します。

IPv6は、より多くのアドレスを提供するだけでなく、IPv4にはない機能も実装しています。アドレス設定、ネットワークのリナンバリング、そしてネットワーク接続プロバイダーの変更時のルーターアナウンスメントといった側面が簡素化されています。また、パケットのフラグメンテーションをエンドポイントに委ねることで、ルーターにおけるパケット処理も簡素化されています。IPv6のサブネットサイズは、アドレスのホスト識別子部分のサイズを64ビットに固定することで標準化されています。

IPv6のアドレスアーキテクチャでは、ユニキャスト、エニーキャスト、マルチキャストの3種類の伝送方法が可能です。[ 5 ] [ 6 ] :210 IPv6はブロードキャストを実装していないため、ブロードキャストアドレスの概念はありません。

動機と起源

IPv4アドレス枯渇

ドット10進法のIPv4アドレス表現を2進法に分解する

インターネット プロトコル バージョン 4 (IPv4) は、インターネット プロトコルの最初の公開バージョンでした。IPv4 は、インターネットとワールド ワイドウェブの基盤となる前に、米国防総省の機関である国防高等研究計画局(DARPA)による研究プロジェクトとして開発されました。IPv4 には、 32 ビットの数値識別子を使用するアドレス指定システムが含まれています。これらのアドレスは通常、0 から 255 までの各オクテット (数値あたり 8 ビット) の 4 つのオクテットの 10 進数値としてドット付き 10 進表記で表示されます。したがって、IPv4 は、2 の32 乗、つまり約 43 億アドレスのアドレス指定機能を提供します。このバージョンはもともと DARPA のネットワーク概念のテストであるとみなされていたため、アドレス枯渇は当初 IPv4 では懸念されていませんでした。[ 7 ]インターネットの運用の最初の 10 年間で、アドレス空間を節約する方法を開発する必要があることがわかりました。 1990年代初頭、クラスレスネットワークモデルを使用してアドレス体系が再設計された後でも、 IPv4アドレス枯渇を防ぐには不十分であり、インターネットインフラストラクチャのさらなる変更が必要であることが明らかになりました。[ 8 ]

最後の未割り当てトップレベルアドレスブロックである1600万のIPv4アドレスは、2011年2月にインターネット割り当て番号機関（IANA）によって5つの地域インターネットレジストリ（RIR）に割り当てられました。[ 9 ]ただし、各RIRにはまだ利用可能なアドレスプールがあり、/8クラスレスドメイン間ルーティング（CIDR）ブロックが1つ残るまで、標準のアドレス割り当てポリシーが継続されると予想されます。その後は、1,024アドレス（/22）のブロックのみがRIRからローカルインターネットレジストリ（LIR）に提供されます。 2025年4月現在、アジア太平洋ネットワーク情報センター（APNIC）、Réseaux IP Européensネットワーク調整センター（RIPE NCC）、ラテンアメリカおよびカリブ海ネットワーク情報センター（LACNIC）、アフリカネットワーク情報センター（AFRINIC）、およびアメリカインターネット番号レジストリ（ARIN）のすべてがこの段階に達しています。[ 10 ] [ 11 ] [ 12 ] [ 13 ]

RIPE NCCは2019年11月25日にIPv4アドレスが完全に不足したことを発表し[ 14 ]、IPv6の導入をさらに進めるよう求めた。

IPv4との比較

インターネットでは、データはネットワークパケットの形で送信されます。IPv6は、ルーターによるパケットヘッダー処理を最小限に抑えるように設計された新しいパケット形式を規定しています。 [ 2 ] [ 15 ] IPv4パケットとIPv6パケットのヘッダーは大きく異なるため、両プロトコルは相互運用性がありません。しかし、ほとんどのトランスポート層およびアプリケーション層プロトコルは、IPv6上で動作するためにほとんど、あるいは全く変更を加える必要がありません。ただし、ファイル転送プロトコル（FTP）やネットワークタイムプロトコル（NTP）など、インターネット層アドレスを埋め込むアプリケーションプロトコルは例外で、新しいアドレス形式が既存のプロトコル構文と競合する可能性があります。

より大きなアドレス空間

IPv6がIPv4に対して持つ主な利点は、アドレス空間の広さです。IPv6アドレスのサイズは128ビットで、IPv4では32ビットです。[ 2 ]そのため、アドレス空間には2の128乗（340冪乗、約3.4 × 10 38）。この空間の一部のブロックと特定のアドレスは特別な用途のために予約されています。

このアドレス空間は非常に広大ですが、IPv6の設計者は、使用可能なアドレスが地理的に飽和状態になることを意図していませんでした。むしろ、アドレスが長くなったことで、アドレスの割り当てが簡素化され、効率的な経路集約が可能になり、特殊なアドレス指定機能の実装が可能になりました。IPv4では、この小さなアドレス空間を最大限に活用するために、複雑なクラスレス・インタードメイン・ルーティング（CIDR）方式が開発されました。IPv6のアドレスのネットワーク識別子部分は通常2の64乗アドレスで、これはIPv4のアドレス空間全体の約40億倍の大きさです。したがって、IPv6では実際のアドレス空間の利用率は低くなりますが、広大なサブネット空間と階層的な経路集約によって、ネットワーク管理とルーティングの効率が向上します。

マルチキャスト

IPv6におけるマルチキャスト構造

マルチキャスト（単一の送信操作で複数の宛先にパケットを送信する機能）は、IPv6の基本仕様の一部です。IPv4では、これはオプション（ただし一般的に実装されている）機能です。[ 16 ] IPv6マルチキャストアドレス指定は、IPv4マルチキャストと共通の機能とプロトコルを備えていますが、特定のプロトコルの必要性を排除することで変更や改善が加えられています。IPv6は、従来のIPブロードキャスト（特別なブロードキャストアドレスを使用して接続リンク上のすべてのホストにパケットを送信する機能）を実装していないため、ブロードキャストアドレスを定義していません。IPv6では、アドレスff02::1のリンクローカル全ノードマルチキャストグループにパケットを送信することで同じ結果が得られます。これは、アドレス224.0.0.1へのIPv4マルチキャストに類似しています。IPv6は、ランデブーポイントアドレスをIPv6マルチキャストグループアドレスに埋め込むなど、新しいマルチキャスト実装も提供しており、これによりドメイン間ソリューションの導入が簡素化されます。[ 17 ]

IPv4では、組織がグローバルにルーティング可能なマルチキャストグループの割り当てを1つでも取得するのは非常に困難であり、ドメイン間ソリューションの実装は難解です。[ 18 ] IPv6のローカルインターネットレジストリによるユニキャストアドレスの割り当ては、少なくとも64ビットのルーティングプレフィックスを持ち、IPv6（これも64ビット）で利用可能なサブネットサイズが最小になります。このような割り当てにより、ユニキャストアドレスプレフィックスをIPv6マルチキャストアドレス形式に埋め込むことが可能になり、同時に32ビットブロック（アドレスの最下位ビット）、つまり約42億のマルチキャストグループ識別子を提供できます。したがって、IPv6サブネットの各ユーザーは、マルチキャストアプリケーション用に、グローバルにルーティング可能な送信元固有のマルチキャストグループのセットを自動的に利用できるようになります。[ 19 ]

ステートレスアドレス自動構成（SLAAC）

IPv6ホストは自動的に構成されます。すべてのインターフェースは自己生成のリンクローカルアドレスを持ち、ネットワークに接続されると競合解決が行われ、ルータはルータ広告を介してネットワークプレフィックスを提供します。[ 20 ]ルータのステートレス構成は、特別なルータリナンバリングプロトコルによって実現できます。[ 21 ]必要に応じて、ホストはダイナミックホスト構成プロトコルバージョン6 （DHCPv6）または静的アドレスを介して追加のステートフルアドレスを手動で構成できます。

IPv4と同様に、IPv6はグローバルに一意なIPアドレスをサポートします。IPv6の設計は、ネットワークアドレス変換を廃止することで、初期のインターネット確立時に考案されたネットワーク設計のエンドツーエンド原則を再強調することを目的としています。そのため、ネットワーク上のすべてのデバイスは、他のどのデバイスからもグローバルに直接アドレス指定できます。

安定した、一意の、グローバルにアドレス指定可能なIPアドレスは、ネットワークをまたいでデバイスを追跡することを容易にします。そのため、このようなアドレスは、ノートパソコンや携帯電話などのモバイルデバイスにとって特にプライバシー上の懸念事項となります。[ 22 ]こうしたプライバシー上の懸念に対処するため、SLAACプロトコルには、一般的に「プライバシーアドレス」、より正確には「一時アドレス」と呼ばれるアドレスが含まれています。[ 23 ]一時アドレスはランダムで不安定です。一般的な消費者向けデバイスは、毎日新しい一時アドレスを生成し、1週間後には古いアドレス宛のトラフィックを無視します。一時アドレスは、WindowsではXP SP1以降、[ 24 ] macOSでは（Mac OS X）10.7以降、Androidでは4.0以降、iOSではバージョン4.3以降でデフォルトで使用されています。Linuxディストリビューションによる一時アドレスの使用は様々です。[ 25 ]

異なるルーティングプレフィックスを持つ新しい接続プロバイダーのために既存のネットワークを再番号することは、IPv4では大きな作業です。[ 26 ] [ 27 ]しかし、IPv6では、ホスト識別子（アドレスの最下位64ビット）をホストが独立して自己構成できるため、いくつかのルーターによってアナウンスされたプレフィックスを変更すると、原理的にはネットワーク全体の番号を再番号化できます。[ 20 ]

SLAACのアドレス生成方法は実装に依存します。IETFは、アドレスは決定論的でありながら意味的には不透明であることを推奨しています。[ 28 ]

IPsec

インターネット プロトコル セキュリティ(IPsec) は、もともと IPv6 用に開発されましたが、最初に広く導入されたのは IPv4 で、IPv4 用に再設計されました。IPsec はすべての IPv6 プロトコル実装の必須部分であり[ 2 ]、インターネット キー エクスチェンジ(IKE) が推奨されていましたが、RFC 6434 では、IPv6 実装への IPsec の組み込みは推奨事項に格下げされました。これは、IPv6 を使用する可能性のあるすべての種類のデバイスに完全な IPsec 実装を要求することは非現実的であると考えられたためです[ 29 ] 。ただし、RFC 4301 の時点では、IPsec を実装する IPv6 プロトコル実装は IKEv2 を実装し、最小限の暗号化アルゴリズムセットをサポートする必要があります。この要件により、異なるベンダーのデバイス間での IPsec 実装の相互運用性が向上します。IPsec 認証ヘッダー (AH) とカプセル化セキュリティ ペイロード ヘッダー (ESP) は、IPv6 拡張ヘッダーとして実装されています[ 30 ]

ルータによる簡素化された処理

IPv6 のパケット ヘッダーは IPv4 ヘッダーよりも単純です。めったに使用されないフィールドの多くは、オプションのヘッダー拡張に移動されました。 IPv6 パケット ヘッダーにより、ルータによるパケット転送プロセスが簡素化されました。 IPv6 パケット ヘッダーは IPv4 パケット ヘッダーの少なくとも 2 倍のサイズですが、ルーターによる基本 IPv6 ヘッダーのみを含むパケットの処理は、ヘッダーが共通のワード サイズに合わせて配置されているため、ルーターでの処理が少なくて済むため、場合によっては効率的です。[ 2 ] [ 15 ]ただし、多くのデバイスは IPv6 サポートをハードウェアではなくソフトウェアで実装しているため、パケット処理のパフォーマンスが非常に悪くなります。[ 31 ]さらに、多くの実装では、拡張ヘッダーを使用するとパケットがルーターの CPU で処理されるため、パフォーマンスが低下したり、セキュリティ上の問題が発生することがあります。[ 32 ]

さらに、IPv6 ヘッダーにはチェックサムが含まれません。IPv4 ヘッダー チェックサムは IPv4 ヘッダーに対して計算され、存続時間( IPv6 プロトコルではホップ リミットと呼ばれる) が 1 つ減るたびにルータによって再計算される必要があります。 IPv6 ヘッダーにチェックサムがないことで、ネットワークのほとんどの処理がリーフ ノードで発生するというインターネット設計のエンドツーエンド原則が促進されます。IPv6 パケットにカプセル化されるデータの整合性保護は、リンク層または上位層プロトコル (つまり、トランスポート層の伝送制御プロトコル(TCP) とユーザ データグラム プロトコル(UDP))のエラー検出の両方によって保証されると想定されています。したがって、IPv4 では UDP データグラムヘッダーにチェックサムがないこと (ヘッダー フィールドの 0 で示される) が許可されていましたが、IPv6 では UDP ヘッダーにチェックサムが必要です。

IPv6 ルーターはIP フラグメンテーションを実行しません。IPv6 ホストは、パス MTU 検出を実行するか、エンドツーエンドのフラグメンテーションを実行するか、デフォルトの最大転送単位(MTU) である 1280オクテットを超えないパケットを送信するかのいずれかを実行する必要があります。

モビリティ

モバイルIPv4とは異なり、モバイルIPv6は三角ルーティングを回避するため、ネイティブIPv6と同等の効率性を実現します。IPv6ルータは、サブネット全体を再番号付けすることなく新しいルータ接続ポイントに移動することを許可する場合もあります。[ 33 ]

拡張ヘッダー

IPv6拡張ヘッダーのいくつかの例

IPv6パケットヘッダーの最小サイズは40オクテット（320ビット）です。オプションは拡張機能として実装されています。これにより、コアパケット構造に影響を与えることなく、将来的にプロトコルを拡張することが可能になります。[ 2 ]ただし、RFC 7872では、一部のネットワーク事業者が、中継自律システムを通過する際に拡張ヘッダー付きのIPv6パケットを破棄することが指摘されています。

ジャンボグラム

IPv4では、パケットのペイロードサイズは65,535 （2の16乗− 1）オクテットに制限されています。IPv6ノードは、この制限を超えるパケット（ジャンボグラムと呼ばれる）をオプションで処理できます。ジャンボグラムは最大4,294,967,295 （2の32乗− 1）オクテットまで可能です。ジャンボグラムの使用は、高MTUリンクにおけるパフォーマンスを向上させる可能性があります。ジャンボグラムの使用は、ジャンボペイロードオプション拡張ヘッダーによって示されます。[ 34 ]

IPv6パケット

IPv6パケットヘッダー

IPv6 パケットには、ヘッダーとペイロードの2 つの部分があります。

ヘッダーは、すべてのパケットに必要な最小限の機能を持つ固定部分で構成され、特別な機能を実装するためのオプションの拡張機能が続く場合があります。

固定ヘッダーは、  IPv6パケットの最初の40オクテット（320ビット）を占めます。このヘッダーには、送信元アドレスと宛先アドレス、トラフィッククラス、ホップカウント、そしてヘッダーに続くオプションの拡張機能またはペイロードの種類が含まれます。この「次ヘッダー」フィールドは、受信側に対し、ヘッダーに続くデータの解釈方法を指示します。パケットにオプションが含まれている場合、このフィールドには次のオプションのオプションタイプが含まれます。最後のオプションの「次ヘッダー」フィールドは、パケットのペイロードで伝送される上位層プロトコルを指します。

IPv6トラフィッククラスフィールドの現在の使用法では、これを6ビットの差別化サービスコードポイント[ 35 ]と2ビットの明示的輻輳通知フィールド[ 36 ]に分割しています。

拡張ヘッダーには、ルーティング、フラグメンテーション、 IPsecフレームワークを使用したセキュリティなど、ネットワーク内のパケットの特別な処理に使用されるオプションが含まれます。

特別なオプションがない場合、ペイロードは64 KB未満である必要があります。ジャンボペイロードオプション（ホップバイホップオプション拡張ヘッダー内）を使用する場合、ペイロードは4 GB未満である必要があります。

IPv4とは異なり、ルーターはパケットをフラグメント化しません。ホストは、 Path MTU Discovery（パスMTU探索）を使用して、フラグメント化することなく宛先に到達できるサイズにパケットを縮小することが期待されます。IPv6パケットのフラグメント化を参照してください。

アドレッシング

IPv6ユニキャストアドレスの一般的な構造

IPv6アドレスは128ビットです。IPv6アドレス空間の設計は、サブネット化によって小さなアドレス空間の利用効率を高めたIPv4とは異なる設計思想に基づいています。IPv6では、アドレス空間は当面の間は十分に大きいと考えられており、ローカルエリアサブネットでは、アドレスのホスト部分に常に64ビット（インターフェース識別子として指定）が使用され、最上位の64ビットはルーティングプレフィックスとして使用されます。[ 5 ]：9 IPv6サブネットはスキャン不可能であるという神話が存在していましたが、RFC 7707では、一部のIPv6アドレス構成手法とアルゴリズムから得られるパターンにより、多くの実際のシナリオでアドレススキャンが可能になると述べられています。  

住所表現

IPv6アドレスの128ビットは、16ビットずつの8つのグループで表現されます。各グループは4つの16進数（ヘクステット[ 37 ] [ 38 ]、より正式にはヘキサデクテット[ 39 ]、非公式にはクィブルまたはクワッドニブル[ 39 ]と呼ばれることもあります）で表され、グループはコロン (:) で区切られます。この表現の例は、2001:0db8:0000:0000:0000:ff00:0042:8329です。

利便性と明確さのために、IPv6 アドレスの表現は次の規則に従って短縮される場合があります。

  • 16進数の任意のグループから1つまたは複数の先頭のゼロが削除されます。通常、先頭のゼロはすべて削除されます。例えば、0042というグループは42に変換されます。0000というグループは0に変換されます。
  • 連続するゼロの部分は、2つのコロン (::) に置き換えられます。これは住所の中で1回のみ使用できます。複数回使用すると住所が不確定になります。省略されたゼロの部分が1つだけあることを示すために、2つのコロンを使用するべきではありません。[ 40 ] : §4.2.2

これらのルールの適用例:

初期アドレス: 2001:0db8:0000:0000:0000:ff00:0042:8329。
各グループの先頭のゼロをすべて削除すると、次のようになります: 2001:db8:0:0:0:ff00:42:8329。
連続するゼロのセクションを省略した後: 2001:db8::ff00:42:8329。

ループバックアドレスは0000:0000:0000:0000:0000:0000:0000:0001 [ 41 ]と定義され、両方の規則を使用して::1に省略されます。

IPv6アドレスは複数の表現方法を持つ可能性があるため、IETFはそれらをテキストで表現するための標準案を発行しました。[ 40 ]

IPv6アドレスにはコロンが含まれており、URLではコロンを使用してホストとポート番号を区切るため、URLのホスト部分として使用されるIPv6アドレスは角括弧で囲む必要があります。[ 42 ]例：http://[2001:db8:4006:812::200e]またはhttp://[2001:db8:4006:812::200e]:8080/path/page.html。

IPv6のリンクローカルユニキャストアドレス構造

IPv6ホストのすべてのインターフェースには、プレフィックスfe80:: / 10を持つリンクローカルアドレスが必要です。このプレフィックスの後に、サブネット化に使用可能な54ビット（通常は0に設定）と、64ビットのインターフェース識別子が続きます。ホストは、DHCPサーバーなどの外部ネットワークコンポーネントの存在や協力なしに、リンクローカルアドレスの自動設定と呼ばれるプロセスによって、インターフェース識別子を自ら計算して割り当てることができます。

リンクローカルアドレス（サフィックス）の下位64ビットは、元々は基盤となるネットワークインターフェースカードのMACアドレスから派生していました。このアドレス割り当て方法では、故障したネットワークカードを交換した際に望ましくないアドレス変更が発生する可能性があり、またセキュリティとプライバシーに関する多くの問題もあったため、RFC 8064では、従来のMACベースの方式をRFC 7217で規定されたハッシュベースの方式に置き換えました。   

アドレスの一意性とルータ要請

IPv6は、IPv4のアドレス解決プロトコル（ARP）の機能の基盤となっているブロードキャストアドレス方式をサポートしていないため、 IPv6ではIPアドレスをリンク層アドレス（ MACアドレスなど）にマッピングするための新しいメカニズムを採用しています。IPv6は、 ICMPv6とマルチキャスト伝送を利用する近隣探索プロトコル（NDP、ND）をリンク層に実装しています。[ 6 ]：210 IPv6ホストは、IPアドレスのリンク層アドレスを要求する近隣要請メッセージを送信することにより、ローカルエリアネットワーク（LAN）内でのIPv6アドレスの一意性を検証します。LAN内の他のホストがそのアドレスを使用している場合は、そのホストが応答します。[ 43 ]

新しいIPv6インターフェースを構築するホストは、まず、一意のアドレスを生成するために設計された複数のメカニズムの1つを使用して、一意のリンクローカルアドレスを生成します。一意でないアドレスが検出された場合、ホストは新しく生成されたアドレスで再試行できます。一意のリンクローカルアドレスが確立されると、IPv6ホストは、このリンク上でLANがIPv6をサポートするルータインターフェースに接続されているかどうかを判断します。これは、リンクローカルアドレスを送信元として、全ルータ[ 44 ]マルチキャストグループにICMPv6ルータ要請メッセージを送信することによって行われます。所定の回数試行しても応答がない場合、ホストはルータが接続されていないと判断します。ルータからルータ広告と呼ばれる応答を受け取った場合、その応答には、適切なユニキャストネットワークプレフィックスを持つグローバルに一意なアドレスを確立するためのネットワーク構成情報が含まれます。[ 45 ]また、ホストがDHCPを使用してさらに情報とアドレスを取得する必要があるかどうかを指示する2つのフラグビットがあります。

  • 管理ビットは、ホストがルータ広告からの自動構成されたアドレスに依存するのではなく、DHCP を使用して追加のアドレスを取得する必要があるかどうかを示します。
  • その他ビットは、ホストがDHCPを介してその他の情報を取得するかどうかを示します。その他の情報は、ホストが接続されているサブネットの1つ以上のプレフィックス情報オプション、プレフィックスの有効期間、および2つのフラグで構成されます。[ 43 ]
    • オンリンク: このフラグが設定されている場合、ホストは特定のサブネット上のすべてのアドレスをオンリンクとして扱い、指定された有効期間中、パケットをルーターに送信するのではなく、それらのアドレスに直接送信します。
    • アドレス: このフラグは、ホストに実際にグローバル アドレスを作成するように指示します。

グローバルアドレス指定

IPv6のグローバルユニキャストアドレス構造

グローバルアドレスの割り当て手順は、ローカルアドレスの構築手順と同様です。プレフィックスはネットワーク上のルータ広告から提供されます。複数のプレフィックス広告は、複数のアドレスを設定することにつながります。[ 43 ]

ステートレスアドレス自動構成（SLAAC）では、/ 64のアドレスブロックが必要です。[ 5 ]ローカルインターネットレジストリには少なくとも/ 32ブロックが割り当てられ、下位ネットワークに分配されます。[ 46 ] 2001年9月の最初の勧告では、エンドユーザーサイトに/ 48サブネットを割り当てることが規定されていました。 [ 47 ] 2011年3月にこの勧告は改訂されました。[ 48 ] IETFは「ホームサイトに単一の/ 64よりも大幅に多くのアドレスを割り当てることを推奨しますが、すべてのホームサイトに/ 48を割り当てることも推奨しません」と述べています。/56ブロックが特に考慮されています。ISPがこの勧告を尊重するかどうかはまだ不明です。例えば、初期の試験運用では、Comcastの顧客には単一の/ 64ネットワークが割り当てられました。[ 49 ]

ドメインネームシステムにおける IPv6

ドメインネームシステム（DNS）では、ホスト名はAAAA（「quad-A」）リソースレコードによってIPv6アドレスにマッピングされます。逆引き解決のために、IETFはip6.arpaというドメインを予約しました。このドメインでは、名前空間はIPv6アドレスのニブル単位（4ビット）を1桁の16進数で表現することによって階層的に分割されます。[ 50 ]

デュアルスタックホストがDNSサーバーに完全修飾ドメイン名（FQDN）を解決するためにクエリを実行すると、ホストのDNSクライアントは2つのDNS要求を送信します。1つはAAAAレコードを、もう1つはAレコードを、デフォルトでこの順序でクエリします。DNSから両方の種類のアドレスが返され、そのルートが存在する場合、IPv6アドレスがIPv4アドレスよりも優先されます。ただし、ホストオペレーティングシステムは、アドレス選択に関して別の優先順位を設定することができます。[ 51 ] [ 52 ]

IPv6向けの初期のDNS実装では、ネットワークのリナンバリングを容易にするために、代替レコードタイプが使用されていました。A6リソースレコードは前方参照に使用され、ビット文字列ラベルやDNAMEレコードといった他の多くの革新的な機能が追加されました。[ 53 ]両方の方式の長所と短所に関する議論の後、[ 54 ] ) A6リソースレコードの使用は非推奨となり、実験的な段階となりました。[ 55 ]

移行メカニズム

IPv6がIPv4を瞬時に置き換えることは想定されていません。両プロトコルはしばらくの間、同時に運用され続けるでしょう。そのため、 IPv6ホストがIPv4サービスにアクセスできるようにし、孤立したIPv6ホストとネットワークがIPv4インフラストラクチャを介して相互にアクセスできるようにするために、 IPv6移行メカニズムが必要です。[ 56 ]

シルビア・ハーゲン氏によると、デバイス上でIPv4とIPv6のデュアルスタック実装を行うことが、IPv6への移行における最も簡単な方法です。[ 57 ]他の多くの移行メカニズムでは、トンネリングを用いてIPv6トラフィックをIPv4ネットワーク内でカプセル化し、その逆も行います。これは不完全な解決策であり、リンクの最大転送単位（MTU）を減少させ、パスMTU検出を複雑にし、遅延を増加させる可能性があります。[ 58 ] [ 59 ]

デュアルスタックIP実装

デュアルスタックIP実装は、イーサネットなどの共通の物理層実装の上に、コンピュータまたはネットワークデバイスのオペレーティングシステムに完全なIPv4およびIPv6プロトコルスタックを提供します。これにより、デュアルスタックホストはIPv6ネットワークとIPv4ネットワークに同時に参加できます。[ 60 ]

オペレーティングシステムにデュアルスタック実装されたデバイスは、IPv4アドレスとIPv6アドレスを持ち、LANまたはインターネット上の他のノードとIPv4またはIPv6のいずれかを使用して通信できます。DNSプロトコルは、両方のIPプロトコルによって完全修飾ドメイン名とIPアドレスの解決に使用されますが、デュアルスタックでは、解決元のDNSサーバーが両方の種類のアドレスを解決できることが条件となります。このようなデュアルスタックDNSサーバーは、AレコードにIPv4アドレスを、AAAAレコードにIPv6アドレスを保持します。解決先の宛先に応じて、DNSネームサーバーはIPv4、IPv6、またはその両方のIPアドレスを返します。デフォルトのアドレス選択メカニズム、つまり優先プロトコルは、ホストまたはDNSサーバーのいずれかで設定する必要があります。IETFは、デュアルスタックアプリケーションを支援するためのHappy Eyeballsを公開しています。これにより、アプリケーションはIPv4とIPv6の両方を使用して接続できますが、利用可能な場合はIPv6接続を優先します。ただし、DNSサーバーがIPv6アドレスを返すホストとサービス間のすべてのルーターにもデュアルスタックを実装する必要があります。デュアルスタッククライアントは、ネットワークがIPv6バージョンのルーティングプロトコルを使用してIPv6パケットを転送できる場合にのみ、IPv6を優先するように設定する必要があります。デュアルスタックネットワークプロトコルが導入されている場合は、アプリケーション層をIPv6に移行できます。[ 61 ]

デュアルスタックは主要なオペレーティング システムおよびネットワーク デバイス ベンダーによってサポートされていますが、従来のネットワーク ハードウェアおよびサーバーは IPv6 をサポートしていません。

パブリックIPv6を利用するISP顧客

IANA、RIR、ISPによるIPv6プレフィックス割り当てメカニズム

インターネットサービスプロバイダー（ISP）は、企業や個人の顧客に対し、パブリック向けのIPv6グローバルユニキャストアドレスの提供を増やしています。しかし、ローカルエリアネットワーク（LAN）でIPv4が依然として使用されており、ISPがパブリック向けのIPv6アドレスを1つしか提供できない場合、IPv4 LANアドレスはNAT（ネットワークアドレス変換）メカニズムであるNAT64を使用してパブリック向けのIPv6アドレスに変換されます。一部のISPは、グローバルにルーティング可能なIPv4アドレスプールを使い果たしているため、パブリック向けのIPv4アドレスとIPv6アドレスの両方を顧客に提供できず、デュアルスタックネットワークをサポートできません。一方、ISPの顧客は依然としてIPv4ウェブサーバーやその他の宛先へのアクセスを試みています。[ 62 ]

すべての地域インターネットレジストリ（RIR）ゾーンにおいて、かなりの割合のISPがIPv6アドレス空間を取得しています。これには、 Verizon Wireless、StarHub Cable、Chubu Telecommunications、Kabel Deutschland、Swisscom、T-Mobile、Internode、Telefónicaなど、世界の主要なISPやモバイルネットワーク事業者の多くが含まれます。[ 63 ]

一部のISPは依然として顧客にIPv4アドレスのみを割り当てていますが、多くのISPは顧客にIPv6またはIPv4とIPv6のデュアルスタックアドレスのみを割り当てています。ISPは、自社ネットワーク上の顧客からのIPv6トラフィックの割合が20%から40%の間であると報告していますが、2017年半ばの時点で、いくつかの大規模インターネットエクスチェンジポイント（IXP）では、IPv6トラフィックは依然としてトラフィック全体のごく一部を占めるに過ぎませんでした。AMS -IXは2%、SeattleIXは7%と報告しています。2017年の調査では、デュアルスタックISPのサービスを利用している多くのDSL顧客が、DNSサーバーに完全修飾ドメイン名をIPv6アドレスに解決するよう要求していないことがわかりました。この調査ではまた、IPv6対応ウェブサーバーリソースからのトラフィックの大部分は、依然としてIPv4経由で要求され、処理されていることもわかりました。これは主に、ISPの顧客がISPが提供するデュアルスタック機能を使用していないためであり、IPv4のみのISPの顧客もそれほど多くありません。[ 64 ]

トンネル工事

トンネリング、つまり IPv6 パケットを IPv4 パケットにカプセル化する技術の基礎は、RFC 4213 で概説されています。インターネット バックボーンが IPv4 のみだった頃、よく使われていたトンネリング プロトコルの 1 つが6to4でした。[ 65 ] Teredo トンネリングも、IPv6 LAN を IPv4 インターネット バックボーンと統合するためによく使われていました。Teredo は RFC 4380 で概説されており、IPv6 パケットを UDP 内にカプセル化することで、IPv6ローカル エリア ネットワークがIPv4 ネットワーク上でトンネリングできるようにします。Teredo リレーは、Teredo サーバーとネイティブ IPv6 ネットワークの間を仲介する IPv6 ルーターです。ISP ネットワークがネイティブ IPv6 に切り替えるまでは 6to4 と Teredo が広く導入されると予想されていましたが、2014 年までに Google Statistics によると、両方のメカニズムの使用はほぼ 0 にまで減少しました。[ 66 ]

IPv4マップされたIPv6アドレス

IPv4互換のIPv6ユニキャストアドレス
IPv4マップされたIPv6ユニキャストアドレス

ハイブリッドデュアルスタックIPv6/IPv4実装は、IPv4マップIPv6アドレスという特別なクラスのアドレスを認識します。[ 67 ]：§2.2.3 [ 5 ]これらのアドレスは通常、標準IPv6形式の96ビットプレフィックスで記述され、残りの32ビットはIPv4の慣習的なドット10進表記法で記述されます。

このグループのアドレスは、80ビットの0のプレフィックス、次の16ビットの1、そして残りの最下位32ビットにIPv4アドレスが含まれます。例えば、::ffff:192.0.2.128はIPv4アドレス192.0.2.128を表します。以前の形式は「IPv4互換IPv6アドレス」と呼ばれ、::192.0.2.128でしたが、この方法は非推奨です。[ 5 ]

IPv4とIPv6のプロトコルスタックには内部的に大きな違いがあるため、プログラマがIPv6スタックで利用できる低レベル機能の一部は、IPv4射影アドレスでは同じように動作しない。一般的なIPv6スタックの中には、IPv6スタックとIPv4スタックが別々に実装されているため（Microsoft Windows 2000、XP、Server 2003など）、またはセキュリティ上の懸念（OpenBSD）から、IPv4射影アドレス機能を実装していないものもある。[ 68 ]これらのオペレーティングシステムでは、プログラムは使用するIPプロトコルごとに別々のソケットを開く必要がある。Linuxカーネル、NetBSD、FreeBSDなどの一部のシステムでは、この機能はソケットオプションIPV6_V6ONLYによって制御される。[ 69 ] : 22

アドレスプレフィックス64:ff9b::/96は、 NAT64移行方式で使用されるIPv4埋め込みIPv6アドレスのクラスです。[ 70 ]たとえば、64:ff9b::192.0.2.128はIPv4アドレス192.0.2.128を表します。

安全

IPv6の使用により、セキュリティ上の様々な影響が生じる可能性があります。その一部はIPv6プロトコル自体に関連するものであり、その他は実装上の欠陥に関連するものです。[ 71 ] [ 72 ]

影のネットワーク

ソフトウェア製造元によって IPv6 がデフォルトで有効になっているノードを追加すると、意図せずシャドウ ネットワークが作成され、IPv4 セキュリティ管理のみが実装されているネットワークに IPv6 トラフィックが流入する可能性があります。また、オペレーティング システムのアップグレードで、新しいオペレーティング システムでは IPv6 がデフォルトで有効になっているのに、古いオペレーティング システムでは IPv6 がデフォルトで有効になっていない場合にも、この問題が発生する可能性があります。セキュリティ インフラストラクチャを更新して IPv6 に対応させないと、IPv6 トラフィックが IPv6 をバイパスする可能性があります。[ 73 ]シャドウ ネットワークは、企業がデフォルトで IPv6 スタックが有効になっていないWindows XPシステムを、有効になっているWindows 7システムに置き換えているビジネス ネットワークで発生しています。[ 74 ]そのため、一部の IPv6 スタック実装者は、IPv4 にマップされたアドレスを無効にして、代わりに IPv4 と IPv6 の両方をサポートする必要がある場合はデュアル スタック ネットワークを使用することを推奨しています。[ 75 ]

IPv6パケットの断片化

研究により、IPv4と同様に、フラグメンテーションの利用はネットワークセキュリティ制御を回避するために利用される可能性があることが示されています。その結果、IPv6パケットの最初のフラグメントにはIPv6ヘッダーチェーン全体が含まれていることが要求され、[ 76 ]非常に異常なフラグメンテーションのケースが禁止されています。さらに、RAガードの回避に関する研究の結果、近隣探索ではフラグメンテーションの使用は非推奨となり、[ 77 ]セキュア近隣探索（SEND）では推奨されません。[ 78 ]

RFCによる標準化

ワーキンググループの提案

IPv6を規定する標準のタイムライン

インターネットの世界的な成長が見込まれたため、インターネット技術タスクフォース（IETF）は1990年代初頭に次世代IPプロトコルの開発に着手した。[ 6 ] : 209 1992年の初めまでに、インターネットアドレスシステムの拡張に関する提案がいくつか出され、1992年末にはIETFはホワイトペーパーの募集を発表した。[ 79 ] 1993年9月、IETFはこのような問題を特に扱うために臨時のアドホックIP次世代（IPng）領域を創設した。新しい領域はアリソン・マンキンとスコット・ブラドナーが率い、方向性を定め、予備的な文書のレビューを行うために、多様な背景を持つ15人のエンジニアからなる局が設けられた。[ 8 ] [ 80 ]ワーキンググループのメンバーは、 J・アラード（マイクロソフト）、スティーブ・ベロビン（AT&T）、ジム・バウンド（デジタル・イクイップメント・コーポレーション）、ロス・キャロン（ウェルフリート）、ブライアン・カーペンター（CERN ） 、デイブ・クラーク（MIT）、ジョン・カラン（NEARNET）、スティーブ・ディーリング（ゼロックス）、ディノ・ファリナッチ（シスコ）、ポール・フランシス（NTT）、エリック・フライシュマン（ボーイング）、マーク・ノッパー（アメリテック）、グレッグ・ミンシャル（ノベル）、ロブ・ウルマン（ロータス）、リシア・チャン（ゼロックス）であった。[ 81 ]

インターネットエンジニアリングタスクフォースは1994年7月25日にIPngモデルを採用し、いくつかのIPngワーキンググループが結成されました。[ 8 ] 1996年までに、 RFC 1883から始まる一連のRFCがインターネットプロトコルバージョン6（IPv6）を定義してリリースされました。（バージョン5は実験的なインターネットストリームプロトコルで使用されました。）  

RFC標準化

IPv6を標準化した最初のRFCは1995年のRFC 1883でした。 [ 82 ] 1998年にRFC 2460がIPv6のRFCになりました。[ 6 ] : 209 2017年7月、 RFC 2460はRFC 8200に置き換えられ、IPv6は「インターネット標準」（IETFプロトコルの最高の成熟度レベル）に昇格しました。[ 3 ]。RFC 8201は関連するIPv6標準であり、 IPパケットの断片化を回避し、パケットの伝送パフォーマンスを維持するために許可される最大パケットサイズを持つ、送信元から宛先への最も効率的なネットワークパスを検出する方法を説明しています。    

展開

地域インターネットレジストリ（RIR）ごとの月間 IPv6 割り当て

1993 年にインターネットのルーティングと IP アドレスの割り当てにクラスレス インター ドメイン ルーティング(CIDR) が導入され、ネットワーク アドレス変換(NAT) が広く使用されるようになったことで、IPv4 アドレスの枯渇が遅れ、2000 年代半ばに開始された IPv6 の導入が可能になりました。

大学はIPv6を早期に導入した機関の一つです。バージニア工科大学は2004年に試験的にIPv6を導入し、その後、キャンパスネットワーク全体にIPv6の導入を拡大しました。2016年までに、同大学のネットワークトラフィックの82%がIPv6を使用しています。インペリアル・カレッジ・ロンドンは2003年に試験的なIPv6導入を開始し、2016年までに同大学のネットワークにおけるIPv6トラフィックは平均20%から40%に達しました。このIPv6トラフィックの大部分は、 IPv6に完全に依存するCERNとの高エネルギー物理学共同研究を通じて生成されました。[ 83 ]

ドメインネームシステム（DNS）は2008年からIPv6をサポートしています。同年、2008年北京夏季オリンピックという世界的な主要イベントでIPv6が初めて使用されました。[ 84 ] [ 85 ]

2011年までに、パーソナルコンピュータやサーバーシステムで使用されている主要なオペレーティングシステムはすべて、製品品質のIPv6を実装していました。携帯電話サービスが3Gから4G技術に移行し、音声がIPv6拡張機能を活用したVoIP（ Voice over IP）サービスとして提供されるようになったため、携帯電話システムはインターネットプロトコル（IP）デバイスの大規模な導入分野となりました。2009年、米国の携帯電話事業者であるVerizonは、自社の「次世代」ネットワークで動作するデバイスの技術仕様を発表しました。[ 86 ]この仕様では、3GPPリリース8仕様（2009年3月）に従ったIPv6の動作が義務付けられ、IPv4はオプション機能として廃止されました。[ 86 ]

インターネットバックボーンにおけるIPv6の導入は続いた。2018年には約54,000の自律システムのうち、グローバルなボーダーゲートウェイプロトコル（BGP）ルーティングデータベースでIPv4とIPv6の両方のプレフィックスをアドバタイズしたのはわずか25.3％だった。さらに243のネットワークがIPv6プレフィックスのみをアドバタイズした。アフリカ、中東、中国の一部を除く世界中のすべての国に、IPv6サポートを提供するインターネットバックボーントランジットネットワークが存在した。[ 87 ]：6 2018年半ばまでに、ヨーロッパの大手ブロードバンドISPの一部が、顧客の大多数にIPv6を導入した。Sky UKは顧客の86％以上にIPv6を提供し、Deutsche Telekomは56％のIPv6導入率を達成し、オランダのXS4ALLは73％の導入率を達成し、ベルギーではブロードバンドISPのVOOとTelenetがそれぞれ73％と63％のIPv6導入率を達成した。[ 87 ] : 7 米国のブロードバンドISPであるXfinityのIPv6導入率は約66%です。2018年にはXfinityは推定3,610万人のIPv6ユーザーを報告し、AT&Tは2,230万人のIPv6ユーザーを報告しました。[ 87 ] : 7–8

2025年12月現在、Googleの統計によると、約44%のユーザーがIPv6ネイティブ接続を介してGoogleサービスにアクセスしています。[ 88 ]採用率は地域によって大きく異なり、インド、フランス、ドイツなどの国では70%を超える採用率が報告されていますが、他の国では遅れをとっています。[ 89 ]

ピアリングの問題

ハリケーン・エレクトリックとコージェント・コミュニケーションズの間では、IPv6に関するピアリング紛争が発生しており、両ネットワークプロバイダーはピアリングを拒否している。[ 90 ]

参照

参考文献

  1. ^ 「FAQ」 . ニュージーランドIPv6タスクフォース. 2019年1月29日時点のオリジナルよりアーカイブ。2015年10月26日閲覧。
  2. ^ a b c d e f S. Deering ; R. Hinden (1998年12月).インターネットプロトコルバージョン6（IPv6）仕様. ネットワークワーキンググループ. doi : 10.17487/RFC2460 . RFC 2460 .廃止。RFC 8200  により廃止。RFC 1883を 廃止。RFC 5095、5722、5871、6437、6564、6935、6946、7045、7112 により更新。​​​​​​​​​​​​​
  3. ^ a b S. Deering ; R. Hinden (2017年7月).インターネットプロトコルバージョン6（IPv6）仕様.インターネット技術タスクフォース. doi : 10.17487/RFC8200 . STD 86. RFC 8200 .インターネット標準 86。 RFC  2460 は廃止されます。
  4. ^ Siddiqui, Aftab (2017年7月17日). 「RFC 8200 – IPv6が標準化されました」 .インターネット協会. 2023年10月23日時点のオリジナルよりアーカイブ。 2018年2月25日閲覧。
  5. ^ a b c d e R. Hinden; S. Deering (2006年2月). IPバージョン6アドレスアーキテクチャ. ネットワークワーキンググループ. doi : 10.17487/RFC4291 . RFC 4291 .ドラフト 標準。RFC 3513は 廃止。RFC 5952、6052、7136、7346、7371、8064 により更新。​​​​​​​
  6. ^ a b c d Rosen, Rami (2014). Linuxカーネルネットワーク：実装と理論. ニューヨーク: Apress. ISBN 9781430261971. OCLC  869747983 .
  7. ^ Google IPv6 Conference 2008: What will the IPv6 Internet look like?。イベントは13:35に発生。2021年12月11日時点のオリジナルよりアーカイブ。
  8. ^ a b c Bradner, S.; Mankin, A. (1995年1月). IP次世代プロトコル勧告. IETF . doi : 10.17487/RFC1752 . RFC 1752 .
  9. ^ 「IPv4アドレス空間の無料プールが枯渇」 NRO.netモンテビデオ：The Number Resource Organization. 2011年2月3日. 2024年1月18日時点のオリジナルよりアーカイブ。 2022年1月19日閲覧。
  10. ^ Rashid, Fahmida (2011年2月1日). 「IPv4アドレス枯渇は、IPv6導入に伴う懸念材料にはならない」 . eWeek. 2024年1月20日時点のオリジナルよりアーカイブ。 2012年6月23日閲覧。
  11. ^ Ward, Mark (2012年9月14日). 「欧州、旧インターネットアドレス制限に達する」 . BBCニュース. 2023年11月5日時点のオリジナルよりアーカイブ。 2012年9月15日閲覧。
  12. ^ Huston, Geoff. 「IPV4アドレスレポート」。2024年1月10日時点のオリジナルよりアーカイブ。
  13. ^ AFRINIC (2020年1月13日). 「AFRINIC、IPv4枯渇フェーズ2に突入」 . afrinic.net . 2025年4月20日閲覧。
  14. ^ 「RIPE NCCのIPv4アドレスが不足」（プレスリリース）RIPE NCC 2019年11月25日。 2024年1月19日時点のオリジナルよりアーカイブ。2019年11月26日閲覧。
  15. ^ a b C. Partridge; F. Kastenholz (1994年12月). IP The Next Generation (IPng) を選択するための技術基準. ネットワークワーキンググループ. doi : 10.17487/RFC1726 . RFC 1726 .情報提供。
  16. ^ S. Deering (1989年8月). IPマルチキャストのためのホスト拡張. ネットワークワーキンググループ. doi : 10.17487/RFC1112 . STD 5. RFC 1112 .インターネット標準5。RFC 988 および1054は 廃止。RFC 2236 により更新。
  17. ^ P. Savola; B. Haberman (2004年11月). IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み. ネットワークワーキンググループ. doi : 10.17487/RFC3956 . RFC 3956 .提案 された標準。RFC 7371 によって更新されました。RFC 3306を 更新しました。
  18. ^ D. Thaler; M. Handley; D. Estrin (2000年9月).インターネットマルチキャストアドレス割り当てアーキテクチャ. ネットワークワーキンググループ. doi : 10.17487/RFC2908 . RFC 2908 .廃止。RFC 6308  により廃止されました。
  19. ^ B. Haberman; D. Thaler (2002年8月).ユニキャストプレフィックスベースのIPv6マルチキャストアドレス. ネットワークワーキンググループ. doi : 10.17487/RFC3306 . RFC 3306 .提案された標準。RFC 3956、4489、7371  によって更新されました。
  20. ^ a b S. Thomson; T. Narten; T. Jinmei (2007年9月). IPv6ステートレスアドレス自動設定. ネットワークワーキンググループ. doi : 10.17487/RFC4862 . RFC 4862 .ドラフト 標準。RFC 2462を 廃止。RFC 7527 により更新。
  21. ^ M. Crawford (2000年8月). IPv6におけるルータのリナンバリング. ネットワークワーキンググループ. doi : 10.17487/RFC2894 . RFC 2894 .提案された標準。
  22. ^ T. Narten、R. Draves、S. Krishnan (2007年9月). 「IPv6におけるステートレスアドレス自動構成のためのプライバシー拡張」 www.ietf.org . 2017年3月13日閲覧。
  23. ^ F. Gont; S. Krishnan; T. Narten; R. Draves (2021年2月). IPv6におけるステートレスアドレス自動設定のための一時アドレス拡張.インターネット技術タスクフォース. doi : 10.17487/RFC8981 . ISSN 2070-1721 . RFC 8981 . 提案された標準。RFC 4941を  廃止します。
  24. ^ 「Windows XP用Advanced Networking Packの概要」。Microsoft 。 2017年9月7日時点のオリジナルよりアーカイブ。2019年4月15日閲覧。
  25. ^ 「IPv6 SLAACのプライバシー拡張」インターネット協会、2014年8月8日。2023年10月23日時点のオリジナルよりアーカイブ。2020年1月17日閲覧。
  26. ^ Ferguson, P.; Berkowitz, H. (1997年1月). 「ネットワークリナンバリングの概要：なぜ必要なのか、そしてそもそも何なのか？」 IETF . doi : 10.17487 / RFC2071 . RFC 2071. 2024年1月7日時点のオリジナルよりアーカイブ。 
  27. ^ Berkowitz, H. (1997年1月). 「ルータリナンバリングガイド」 . IETF . doi : 10.17487/RFC2072 . RFC 2072. 2023年6月8日時点のオリジナルよりアーカイブ。 
  28. ^ Cooper, Alissa; Gont, Fernando; Thaler, Dave.安定IPv6インターフェース識別子に関する勧告. doi : 10.17487/RFC8064 . RFC 8064 .
  29. ^ E. Jankiewicz; J. Loughney; T. Narten (2011年12月). IPv6ノード要件.インターネット技術タスクフォース. doi : 10.17487/RFC6434 . ISSN 2070-1721 . RFC 6434 . 廃止。p . 17。RFC 8504により廃止。RFC 4294を廃止。以前は、 IPv6 は IPsec の実装を義務付け、IKE による鍵管理アプローチを推奨していました。本文書では、IPsec アーキテクチャ RFC4301 のサポートをすべての IPv6 ノードで推奨とすることで、この推奨事項を更新します。
  30. ^シルビア・ハーゲン (2014). IPv6 Essentials: IPv4 ネットワークへの IPv6 の統合(第 3 版). セバストポル, カリフォルニア州: オライリーメディア. p. 196. ISBN 978-1-4493-3526-7. OCLC  881832733 .
  31. ^ Zack, E. (2013年7月). 「IPv6セキュリティ評価とベンチマーク」 .
  32. ^ Gont, F. (2016年3月). 「拡張ヘッダー付きIPv6パケットの運用上の意味」 IETF . 2023年10月27日時点のオリジナルよりアーカイブ。
  33. ^ V. Devarapalli; R. Wakikawa; A. Petrescu; P. Thubert (2005年1月).ネットワークモビリティ（NEMO）基本サポートプロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC3963 . RFC 3963 .提案された標準。
  34. ^ D. Borman; S. Deering ; R. Hinden (1999年8月). IPv6 Jumbograms . Network Working Group. doi : 10.17487/RFC2675 . RFC 2675 .提案された標準。RFC 2147を  廃止します。
  35. ^ K. Nichols; S. Blake; F. Baker ; D. Black (1998年12月). IPv4およびIPv6ヘッダーにおける差別化サービスフィールド（DSフィールド）の定義. ネットワークワーキンググループ. doi : 10.17487/RFC2474 . RFC 2474 .提案された標準。RFC 1455 および1349は 廃止されます。RFC 3168、3260、8436により更新 されます。
  36. ^ K. Ramakrishnan; S. Floyd; D. Black (2001年9月). IPへの明示的輻輳通知（ECN）の追加. ネットワークワーキンググループ. doi : 10.17487/RFC3168 . RFC 3168 .提案された標準。RFC 2481を  廃止。RFC 2474、2401、793を 更新。RFC 4301、6040、8311 により更新。​
  37. ^ Graziani, Rick (2012). IPv6の基礎：IPv6を理解するためのわかりやすいアプローチ. Cisco Press . p. 55. ISBN 978-0-13-303347-2。
  38. ^ Coffeen, Tom (2014). IPv6アドレス計画：将来を見据えたアドレス計画の設計. O'Reilly Media . p. 170. ISBN 978-1-4919-0326-1。
  39. ^ a b Horley, Edward (2013). Windows管理者のための実践IPv6 . Apress . p. 17. ISBN 978-1-4302-6371-5。
  40. ^ a b S. Kawamura; M. Kawashima (2010年8月). IPv6アドレステキスト表現に関する勧告. Internet Engineering Task Force . doi : 10.17487/RFC5952 . ISSN 2070-1721 . RFC 5952 . 提案された標準。RFC 4291 を 更新します。
  41. ^ M. Blanchet (2008年4月).特殊用途IPv6アドレス. ネットワークワーキンググループ. doi : 10.17487/RFC5156 . RFC 5156 .提案された標準。RFC 6890  によって廃止されました。
  42. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (2005年1月). Uniform Resource Identifier (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .インターネット標準66。RFC 2732、2396、1808を  廃止。RFC 6874、7320、8820 により更新。RFC 1738 を更新。​​​​
  43. ^ a b c Narten, T. (1999年8月). 「IPv6における近隣探索とステートレス自動設定」. IEEE Internet Computing . 3 (4): 54– 62. Bibcode : 1999IIC.....3d..54N . doi : 10.1109/4236.780961 .
  44. ^ Narten, T. (2007年9月). 「IPバージョン6（IPv6）の近隣探索」 . IETF . セクション6.3.7. doi : 10.17487/RFC4861 . RFC 4861. 2024年1月17日時点のオリジナルよりアーカイブ。 
  45. ^ Thomson, S. (2007年9月). 「IPv6 ステートレスアドレス自動設定 -セクション5.5.1」 . IETF . doi : 10.17487/RFC4862 . RFC 4862. 2024年1月11日時点のオリジナルよりアーカイブ。 
  46. ^ 「IPv6アドレスの割り当てと割り当てポリシー」RIPE NCC 2011年2月8日。2023年6月3日時点のオリジナルよりアーカイブ。 2011年3月27日閲覧。
  47. ^ IAB ; IESG (2001年9月).サイトへのIPv6アドレス割り当てに関するIAB/IESG勧告. ネットワークワーキンググループ. doi : 10.17487/RFC3177 . RFC 3177 .廃止。RFC 6177  により廃止されました。
  48. ^ T. Narten、G. Huston、L. Roberts (2011年3月).エンドサイトへのIPv6アドレスの割り当て.インターネット技術タスクフォース. doi : 10.17487/RFC6177 . ISSN 2070-1721 . BCP 157. RFC 6177 . 現在のベストプラクティス 157。RFC 3177を  廃止します。
  49. ^ Brzozowski, John (2011年1月31日). 「Comcast、DOCSIS経由のIPv6ネイティブデュアルスタックで最初のユーザーを有効化」（プレスリリース）. Comcast . 2023年10月23日時点のオリジナルよりアーカイブ。 2019年4月15日閲覧。
  50. ^ S. Thomson; C. Huitema ; V. Ksinant; M. Souissi (2003年10月). IPバージョン6をサポートするためのDNS拡張. ネットワークワーキンググループ. doi : 10.17487/RFC3596 . STD 88. RFC 3596 .インターネット標準 88。RFC 3152 および1886を 廃止します。
  51. ^ D. Thaler; R. Draves; A. Matsumoto; T. Chown (2012年9月). D. Thaler (編).インターネットプロトコルバージョン6 (IPv6) のデフォルトアドレス選択.インターネット技術タスクフォース. doi : 10.17487/RFC6724 . ISSN 2070-1721 . RFC 6724 . 提案された標準。RFC 3484を  廃止します。
  52. ^シルビア・ハーゲン (2014). IPv6 Essentials: IPv4 ネットワークへの IPv6 の統合. O'Reilly Media, Inc. p. 176. ISBN 9781449335267。
  53. ^ M. Crawford; C. Huitema (2000年7月). IPv6アドレスの集約と再番号付けをサポートするためのDNS拡張. ネットワークワーキンググループ. doi : 10.17487/RFC2874 . RFC 2874 .歴史的 。RFC 3152、3226、3363、3364  により更新。RFC 1886を更新。​​​
  54. ^ R. Austein (2002年8月).インターネットプロトコルバージョン6 (IPv6) におけるドメインネームシステム (DNS) サポートのトレードオフ. ネットワークワーキンググループ. doi : 10.17487/RFC3364 . RFC 3364 .情報。RFC 2673 および2874を 更新します。
  55. ^ R. Bush、A. Durand、B. Fink、O. Gudmundsson、T. Hain編（2002年8月）。「ドメインネームシステム（DNS）におけるインターネットプロトコルバージョン6（IPv6）アドレスの表現」。ネットワークワーキンググループ。doi ：10.17487/ RFC3363。RFC 3363。情報。RFC 2673 および2874を 更新します。
  56. ^ 「IPv6移行メカニズム/トンネリングの比較」 . Sixxs.net. 2023年10月23日時点のオリジナルよりアーカイブ。 2012年1月20日閲覧。
  57. ^シルビア・ハーゲン (2014). IPv6 Essentials: IPv4 ネットワークへの IPv6 の統合. O'Reilly Media, Inc. pp.  222– 223. ISBN 9781449335267。
  58. ^ Carpenter, B. (2011年8月). 「6to4導入に関する勧告ガイドライン」 . IETF . doi : 10.17487/RFC6343 . RFC 6343. 2023年1月28日時点のオリジナルよりアーカイブ。2012年8月20日閲覧。 
  59. ^ 「IPv6: デュアルスタックは可能な場合、トンネルは必須」 . networkworld.com. 2007年9月5日. 2024年1月20日時点のオリジナルよりアーカイブ。2012年11月27日閲覧。
  60. ^ E. Nordmark; R. Gilligan (2005年10月). IPv6ホストおよびルータの基本移行メカニズム. ネットワークワーキンググループ. doi : 10.17487/RFC4213 . RFC 4213 .提案された標準。RFC 2893を  廃止します。
  61. ^シルビア・ハーゲン (2014). IPv6 Essentials: IPv4 ネットワークへの IPv6 の統合. O'Reilly Media, Inc. p. 222. ISBN 9781449335267。
  62. ^ 「IPv4とIPv6ユニキャストアドレスのデュアルスタッキングについて」 Juniper.net 、 Juniper Networks、2017年8月31日。 2022年1月19日閲覧。
  63. ^ "IPv6" . NRO.net . 2017年1月12日時点のオリジナルよりアーカイブ。2017年3月13日閲覧。
  64. ^ Pujol, Enric (2017年6月12日). 「デュアルスタックISPでIPv6トラフィックを停止するものは何ですか？」 . APNIC.net . APNIC . 2023年3月27日時点のオリジナルよりアーカイブ。 2017年6月13日閲覧。
  65. ^ Vaughan-Nichols, Steven J. (2010年10月14日). 「IPv6とIPv4が平和的に共存するための5つの方法」 . ZDNET . 2023年12月5日時点のオリジナルよりアーカイブ。 2017年3月13日閲覧。
  66. ^シルビア・ハーゲン (2014). IPv6 Essentials: IPv4 ネットワークへの IPv6 の統合. O'Reilly Media, Inc. p. 33. ISBN 9781449335267。
  67. ^ M. Cotton、L. Vegoda、B. Haberman (2013年4月). R. Bonica (編).特殊用途IPアドレスレジストリ.インターネット技術タスクフォース. doi : 10.17487/RFC6890 . ISSN 2070-1721 . BCP 153. RFC 6890 . 現在 のベストプラクティス153。RFC 4773、5156、5735、5736は  廃止。RFC 8190により更新。​
  68. ^inet6(4)  –  OpenBSDカーネルインターフェースマニュアル
  69. ^ R. Gilligan; S. Thomson; J. Bound; J. McCann; W. Stevens (2003年2月). IPv6の基本ソケットインターフェース拡張. ネットワークワーキンググループ. doi : 10.17487/RFC3493 . RFC 3493 .
  70. ^ C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (2010年10月). IPv4/IPv6トランスレータのIPv6アドレス指定. Internet Engineering Task Force . doi : 10.17487/RFC6052 . ISSN 2070-1721 . RFC 6052 . 提案された標準。RFC 4291 を 更新します。
  71. ^ Gont, Fernando (2019年3月10日)、「IPv4エンジニアのためのIPv6セキュリティ」 (PDF) 、 2019年8月30日閲覧
  72. ^ Gont, Fernando (2019年1月10日)、IPv6セキュリティに関するよくある質問（FAQ）（PDF） 、 2019年8月30日閲覧
  73. ^ Mullins, Robert (2012年4月5日)、「Shadow Networks: an Unintended IPv6 Side Effect」、Network Computing 、 2013年4月11日時点のオリジナルよりアーカイブ、 2013年3月2日閲覧。
  74. ^ Cicileo, Guillermo; Gagliano, Roque; O'Flaherty, Christian; 他 (2009年10月). IPv6 For All: さまざまな環境でのIPv6の利用と適用に関するガイド(PDF) . p. 5. 2013年3月2日閲覧.
  75. ^伊藤淳一郎・萩野（2003年10月）「有線上のIPv4マップアドレスは有害と考えられる」。
  76. ^ F. Gont、V. Manral、R. Bonica (2014年1月).過大なIPv6ヘッダーチェーンの影響.インターネット技術タスクフォース. doi : 10.17487/RFC7112 . ISSN 2070-1721 . RFC 7112 . 提案さ れた標準。RFC 2460 を更新します。
  77. ^ F. Gont (2014年2月). IPv6ルータ広告ガード（RA-Guard）の実装に関するアドバイス.インターネット技術タスクフォース. doi : 10.17487/RFC7113 . ISSN 2070-1721 . RFC 7113 . 情報 提供。RFC 6105 を更新します。
  78. ^ F. Gont (2013年8月). IPv6近隣探索によるIPv6フラグメンテーションのセキュリティへの影響.インターネット技術タスクフォース. doi : 10.17487/RFC6980 . ISSN 2070-1721 . RFC 6980 . 提案された標準。RFC 3971 および4861を 更新します。
  79. ^ Bradner, S.; Mankin, A. (1993年12月). 「IP: 次世代 (IPng) ホワイトペーパー募集」 . RFC 1550 . 
  80. ^ 「IPngの取り組みの歴史」 The Sun。 2014年5月23日時点のオリジナルよりアーカイブ。
  81. ^ Bradner, Scott O.; Mankin, Allison J. (1995年1月). 「IP次世代プロトコルに関する勧告 - 付録B」 . RFC 1752 . 
  82. ^ Wang, Tao; Gao, Jiaqiong (2019年1月1日). 「IPv6の欠点とIPv4のアップグレード」 . International Journal of Advanced Network, Monitoring and Controls . 4 (1): 1– 9. doi : 10.21307/ijanmc-2019-029 .
  83. ^ IPv6導入状況2018、インターネット協会、2018年、3ページ
  84. ^ 「Beijing2008.cn、次世代ネットへ飛躍」（プレスリリース）. 第29回北京オリンピック競技大会組織委員会. 2008年5月30日. 2009年2月4日時点のオリジナルよりアーカイブ。
  85. ^ Das, Kaushik (2008). 「IPv6と2008年北京オリンピック」 . IPv6.com . 2008年8月1日時点のオリジナルよりアーカイブ。2008年8月15日閲覧。
  86. ^ a b Morr, Derek (2009年6月9日). 「Verizon、次世代携帯電話にIPv6サポートを義務化」 . CircleID.
  87. ^ a b c「2018年のIPv6導入状況」(PDF) . InternetSociety.org .インターネット協会. 2022年1月19日閲覧。
  88. ^ 「IPv6の採用」 。 2025年12月15日閲覧。
  89. ^ 「State of the Internet / IPv6 Adoption Visualization」 Akamai. 2020年11月11日時点のオリジナルよりアーカイブ。2025年12月15日閲覧。
  90. ^ 「ハリケーン・エレクトリックとコージェントの事件」BGP.tools . 2024年9月10日閲覧。
Wikidata には次のプロパティがあります:
WikiversityにはIPv6に関する学習リソースがあります
無料辞書の Wiktionary でIPv6を調べてください。
「 https://en.wikipedia.org/w/index.php?title=IPv6&oldid=1333883429」から取得