IPv6のロゴ Internet Protocol Version 6 (インターネット プロトコル バージョン6)、IPv6 (アイピーブイ6、アイピーバージョン6)は、Internet Protocol の一種で、OSI参照モデル においてネットワーク層 に位置付けられる通信プロトコル である。
これまで主流だったIPv4 では使用可能なIPアドレス が約 232 (約43億 = 4.3×109 )個であったが、IPv6では約 2128 (約340澗 = 3.4×1038 )個使用可能となっており、これが大きな特徴の一つである[ 1] 。実際、ISP の一般向けIPv4接続サービスはアドレスをひとつだけ割り当てるものが主流だったが、IPv6接続サービスでは/48〜/64の大きさのアドレスブロックが割り当てられることが多い。IPv4 のアドレス数はバケツ1個分の砂粒の数しかないが、IPv6のアドレス数は地球1個分の砂粒の数に相当するとの例えがあるほどであり、IPv6への移行により潤沢なアドレスが利用可能となった[ 2] 。
IPv6が誕生した背景には、IPv4 のIPアドレス枯渇問題 がある[ 3] 。
1980年代までは、米国 内を中心に、Class A (/8)、Class B (/16)、Class C (/24) などの単位で各組織にIPアドレスを割り振っていた。1990年代に入り、インターネットの国際化と、参加組織の増大によって、Class BのIPv4アドレスが不足する恐れが出てきた。IPアドレスの数が有限である以上、根本的な解決策が必要となることは自明であり、その解決策として検討された最終成果がIPv6である。
しかし、新しいプロトコルであるIPv6を開発し普及させるには時間がかかるため、短期的な対策であるIPv4の延命として、1994年のプライベートアドレス (RFC 1918 ) の導入と前後して、CIDR (RFC 4632 )・NAT (RFC 2663 ) ・Proxy(プロキシ )など、プライベートアドレスを使用するLANとグローバルアドレスを使用するWANとを使い分けることでIPv4アドレスを節約し有効活用する取り組みが行われた[ 4] 。
一部には、IPv4アドレス枯渇には、既存の回避策で対応可能であるとIPv6の必要性を疑問視する声もあった。しかし、国際的なインターネットの爆発的な普及と、携帯電話 やスマートフォン などのインターネット 利用機器が急速に増加したことにより、新たなIPアドレスの需要が、運用の改善や新たな回避策によるIPアドレスの供給を上回っており、限界に達しようとしている。また、回避策による弊害も顕著になってきており、インターネットの新たな利用形態の普及を阻害している。
現在は、IPv6は運用に目途が立って普及が進められており、IPv4とIPv6を併用 しつつIPv6へ移行することが課題になっている。この課題は、様々な製品がIPv4 への対応を前提として作られているため、既に普及しているIPv4 を容易に廃止することができないために発生している。
1981年9月RFC 791 としてIPv4の基本仕様が公開される。 1991年7月 「IPv4アドレスが不足する」という研究を受けてIETF が調査を開始した[ 5] 。 1992年11月RFC 1380 という形で調査結果をまとめ、次世代ネットワークの議論が始まる。 1993年12月RFC 1550 としてIPngの名称で機能要求をまとめる。 1995年1月RFC 1752 としてSIPPをベースにアドレスを128bit化、同時に名称をIPngからIPv6に正式に改名。 1995年12月RFC 1883 Internet Protocol, Version 6 (IPv6) SpecificationやRFC 1884 IPv6 Addressing ArchitectureとしてIPv6の最初の仕様を決定。 1998年7月RFC 2373 にてIPv6のアドレスに関する仕様を大幅に改訂した。 1998年12月RFC 2460 Internet Protocol, Version 6 (IPv6) Specificationとして主な仕様が確定する。 1999年07月IANA によるIPv6アドレスの割り振りが開始される。 1998年以降、TAHI Project 、WIDE Project 、KAME project 、USAGI Project などにより、UNIX系 OSへの実装とテスト運用が行われ、2006年頃までに主要部分の実装が完了した。Windows に関しては、1998年3月Windows NT 4.0 用にMSRIPv6を、2000年3月Windows 2000 用に技術プレビューを、2001年10月にWindows XP 用に評価版を提供したのち、Windows XP 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レコードを1日だけ有効にすることで、インターネット環境でIPv6を並行運用した場合の問題点を見つけ出すテストを行うイベントが実施された。 日本国内については、NTT のフレッツ 光ネクスト において、IPv6PPPoE 接続が2011年6月1日に、IPv6 IPoE 接続が2011年7月21日に提供され、他社のサービスを含めると、IPv6が一般に普及するための基盤が整った状態になった。 2012年6月6日にWorld IPv6 Launch として、主要なインターネットサービスをIPv6に対応させるイベントが実施された。1日限りのトライアルであった2011年のWorld IPv6 Dayとは異なり、この日以降も継続的にIPv6でサービスできる状態にすることを目的として開催された。 2017年7月RFC 2460 を廃止して、RFC 8200 Internet Protocol, Version 6 (IPv6) Specificationに更新[ 6] 。RFC 2460 に対する追加/修正として存在していた多くのRFCをまとめて再編成した。 IPv6は、ゆっくりながらも普及が進んでいる。Google の統計[ 7] によると、IPv6によるアクセス数は増加傾向にある。全体のアクセス数に対する割合として、2014年10月で5%程度、2016年10月で14%程度、2020年9月で30%程度(日本 では35%程度、最も普及しているベルギー で52%程度)になっている。日本での普及率は2024年に50%となった[ 8] 。
一般家庭でIPv6を利用するには、複数のレベルでIPv6対応がなされている必要があり、大きく分けると、ISP によりIPv6接続が提供されていること、利用するインターネット上のサービスがIPv6接続に対応していること、ルーター などのインターネット接続に利用する機器がIPv6に対応していること、そして通信するホストがIPv6接続に対応していること、などとなる[ 9] 。
このうちオペレーティングシステム (OS) やアプリケーションなどのソフトウェア[ 注 1] は、細かい差異こそあれ、既にIPv6への対応を終えているものが多い。
また、通信経路となるISPによるIPv6の対応は、NTT のフレッツ 光ネクスト IPv6 IPoE接続サービスの登場や、移動体通信事業者 によるモバイルインターネットサービスのIPv6化がなされたこと[ 10] により、普及が進んでいる。
インターネット上の各々のサービスサイト(ウェブ サイトなど)はGoogle など海外サービスを中心にIPv6対応が進みつつあるが、日本のサービスの多くは未だIPv6での接続に対応しておらず、提供が最も遅れている分野である。
ソフトウェアやインターネット上のサービスのIPv6対応は、IPv6と従来のIPv4の両方が利用可能という形で行われ、接続相手の利用可能なIPのバージョンにより、どちらを利用するか(自動的に)選択するようにするのが一般的である(IPv4との相互運用 を参照)。
今後は、IP放送 ・IPテレビ電話 ・IP電話 ・IoT などのエンドユーザサービスへのIPv6の採用が進むことが想定され(一部は展開されている)、そのようなIP上の専用サービスがIPv6の普及の牽引役となることも期待されている。一方で強力なキラーアプリケーション の不在も指摘されている。
日本国内では、一部のISP(接続業者、ホスティングサーバ 業者)によって商用・実験サービスが開始されているほか、NTT東日本 及びNTT西日本 によって、一部のフレッツ 網で利用されている。また、日本国内におけるISP各社の対応については、インターネットプロバイダー協会 (JAIPA)「ISPのIPv6対応について 」でまとめられている。
パソコンやサーバ向けのオペレーティングシステム (OS) は、Microsoft Windows やLinux をはじめとしてほとんどのものがIPv6に対応している。しかしIoT機器などで使われる組み込み向けのOSなど、一部にはIPv6に対応していないOSもある。
一般のユーザーが利用するアプリケーションは、IPv6への対応を完了しているものが多い。
Windowsでの例を挙げると、OS付属のアプリケーションではMicrosoft Edge ,Internet Explorer ,Microsoft 管理コンソール ,Windows Media Player ,Windows PowerShell ,リモートデスクトップ接続 など、また、telnet ,ftp などのコマンドラインアプリケーションで、サードパーティ製品では、Mozilla Firefox やOpera のほか、Apache HTTP Server 、Meadow 、Tera Term 、PuTTY 、FFFTP 、NextFTP などでIPv6が利用可能である。
macOSでは、標準のネットワークライブラリがIPv6に対応しており、これを使用している多くのアプリケーションでIPv6が利用可能である。10.3まではSafari は独自のネットワークライブラリを利用しているため、IPv6の対応は不完全であったが、10.4以降は完全に動作している。
IPv6をアプリケーションで利用するためのプログラムは、IPv4でのプログラムと比べて大きな違いがあるものではない。
ネットワークを利用するプログラムではソケット を利用することが多く、通常のIPv4プログラミングでsocketを作成するときには
s = socket ( AF_INET , SOCK_STREAM , 0 ); のように、アドレスファミリ部をIPv4固定で指定することが多いが、一つのサイトがIPv4とIPv6の両プロトコルに対応している場合や、どちらに対応しているのか事前にはわからないことを考慮すると、DNS で一つの名前を検索した後、列挙された複数のプロトコルのアドレスに対して順番にconnectを試みる必要がある。
アドレスを検索する際は、IPv4のみを前提としているgethostbyname () や、socket同様にアドレスファミリ固定であるgethostbyname2 () などではなく、getaddrinfo () を利用する。
以上をまとめると、典型的なソケットを作成するC のコードは以下のようになる。
struct addrinfo hints , * res , * res0 ; int error , s ; memset ( & hints , 0 , sizeof ( hints )); hints . ai_family = PF_UNSPEC ; hints . ai_socktype = SOCK_STREAM ; /* TCPの場合 */ if (( error = getaddrinfo ( "ホスト名" , "サービス名" , & hints , & res0 )) != 0 ) return -1 ; s = -1 ; for ( res = res0 ; res != NULL ; res = res -> ai_next ) { if (( s = socket ( res -> ai_family , res -> ai_socktype , res -> ai_protocol )) == -1 ) continue ; if ( connect ( s , res -> ai_addr , res -> ai_addrlen ) == 0 ) break ; close ( s ); s = -1 ; } freeaddrinfo ( res0 ); if ( s == -1 ) { /* Could not connect */ } else { /* Success */ } この手法はIPv6のみならず、別のIPプロトコルが登場した場合にも有効な手法で、プロトコル独立プログラミングなどと呼ばれる。
なお、ここで示した方法は、getaddrinfo () によって返されるアドレスファミリの順に接続を試みるので、AAAAレコードより先にAレコードを返すようなgetaddrinfo () では、IPv6による通信が行われない可能性もある。
一般に言われているIPv6導入によるメリットとしては以下のようなものが挙げられている。
事実上無限の数のIPアドレスアドレス枯渇の心配がほぼ解消される。実際には非常に大きな有限の数(2128 個 = 340,282,366,920,938,463,463,374,607,431,768,211,456個 = 約340澗個 = 約340兆×1兆×1兆個)であるが、「その辺の石ころにも個別に割り当てることができる」ぐらいあり余っている[ 注 2] 。 仮に、地球の全人類 (約8,000,000,000 = 80億人)へ均等に割り当てられるとしても、1人あたり約4穣 2,500𥝱 個 = 4京2,500兆×1兆個 = 4.25×1028 個という天文学的な数 になり、各個人が毎秒1兆個使い捨て続けたとしても、枯渇するまで約13億5000万年かかる[ 注 3] ほど巨大な数になる。 同時に、IPマスカレード (NAT/NAPTなど)を使わずに済むので、全ノード がグローバルな接続性を持ち、直接接続が可能になる。これによって、P2P アプリケーション(IP電話、インスタントメッセンジャー およびネットワークゲーム など)の利用やIoT の普及が容易になり、またNATの設定などに気を遣わなくて済むようになる。 実際にフレッツ によるIPv6サービス (IPoE)では、/64のネットワークブロックが1ブロック提供される(契約形態によっては異なる)。このサービスを受けることで、1人あたり約43億の2乗(2の64乗、IPv4におけるIPアドレスの総数の2乗)ものアドレス空間をもつネットワークブロックを取得できる。 管理者に負担をかけないIPアドレスの自動設定DHCP サーバがなくても、ホストには自動的にIPアドレスとデフォルト経路が設定される。 アドレスの集約による基幹ルータ での経路表サイズの抑制新たにIPv6の接続を持つとき、ISPの持っているIPv6アドレス(プレフィックス)を切り出してユーザーに渡す。これによって、新しいIPv6サイトが増えたとしてもバックボーンに対して公告する経路情報は増えず、基幹ルータで保持する経路表の大きさが抑えられる。その一方で、アドレスブロックの可搬性がなくなる、複数のISPと契約した時にどのアドレスをどのように使うかを考慮しなければならない「マルチホーム」問題も発生する。 ヘッダの簡略化IPv4のヘッダは多くの場合は20バイトだが、IPオプションの付加によってそれよりも長くなる可能性がある。一方、IPv6の基本的なヘッダは40バイトに固定されている[ 11] 。このため、ルータの負荷を低減できるなどATM などの固定長パケットネットワークに共通な利点を享受できる。なお、拡張ヘッダの利用により拡張性も保持している[ 11] 。 またIPv4では通過するルータ毎に行われていたIPヘッダのエラー検出は、IPv6では廃止された[ 12] 。これにより前項と同じくルータの負荷低減が期待される[ 12] 。
既存のIPv4と共存させる必要があることから、次のようなデメリットや課題が発生する。
IPv4と似たプロトコルではあるものの、互換性がないため、ルータの取替えや新しいソフトウェアの開発・導入などで追加投資を免れない。また、並行運用期間(IPv4が淘汰され消滅するまで)は両方のプロトコルをサポートしなければならない。 普及の目安としてBGPのルーティングテーブルのサイズ[ 13] を比較すると、2016年10月現在でプレフィックスがIPv4で632,483、IPv6で33,323と、IPv4の19.0%程度の規模でしかない。IPv4での教訓とIPv6の経路が新規に敷設された関係でIPv6の方が経路が集約されていてBGPで広告されている経路が少ないとしても、普及が進んでいないことがわかる。また、Googleによる統計[ 7] でも、IPv6によるアクセス数は2016年10月現在で全体の14%程度になっている。 そもそも、汎世界的なネットワークとなったインターネットが、あまねくIPv6に移行するのかどうか、するとしてそれがいつになるのかは、(短期的には)全くの見通しが立っていない。これは、古い機材やOS、ファームの更改により徐々にIPv4/IPv6併存環境が広がっていくことである程度緩和されうる。 IPv6のバックボーンはまだIPv4ほど充実していない。また端末やネットワークの要因のためIPv6での接続に失敗することがあるが、その場合IPv4にフォールバックすることになり、最初からIPv4で接続していれば不要であったはずのタイムラグが生じてしまう。(フレッツ網におけるIPv6#IPv6-IPv4フォールバック問題 ) アドレス空間が広いことと、MACアドレスによる自動設定のため、逆引き の管理が困難であり、逆引きを要求されるケースで問題が起きる(逆引きできないホストからの接続を拒否するサーバなど)。 技術面や運用面でまだ不確定な要素が多い(サイトローカルアドレスの廃止、エニーキャストアドレスの見直しとDHCPv6の再検討、逆引きの問題など)。 IPv4では、NAT/NAPTやIPマスカレードの必要性からルーターなどを介して間接的にインターネットと接続するのが一般的であるため、「インターネット側からは直接ローカルホストに接続できない」という点が結果的にセキュリティおよびプライバシーの向上に貢献している。IPv6においてはNAT/NAPTなどは一般的に行われず、さらに後述のModified EUI-64 (注意[ 注 4] )で生成したIPv6アドレスをそのままグローバルユニキャストアドレスとして使用すると、ユーザーが使用した端末を半永続的に[ 注 5] 追跡可能になるなど[ 注 6] 、プライバシーの面で問題が発生する[ 注 7] 。これに対処するためRFC 4941 (旧RFC 3041 )により、ランダム化されたインターフェイスIDを使い「一時アドレス」を生成、使用する[ 注 8] [ 14] 。Windows XP など以降でサポートされている。ただし、スマートフォン での運用[ 注 9] は2016年時点で未だ不透明である[ 注 10] [ 15] ただし、IPv6の接続サービスの形態では、接続網の形態[ 注 11] やISPによるプレフィックス割当運用にも依存するが、プレフィックスが契約毎(おおむね、ユーザーCPE ごと)に半固定されている場合が多い[ 16] 。そのような場合、一時アドレスを使用しても、プレフィックスに基づくネットワークアドレス単位で識別が可能であり、依然としてユーザーが接続しているネットワークの半永続的な識別、追跡が可能となる[ 注 12] [ 注 13] [ 14] 。 ユーザーのインターネットプロトコルに対する認識度が低く、IPv6に移行するメリットが見いだしにくい。マーケティング手法の観点からは、エンドユーザーが選択するのは、内部プロトコルではなくエンドサービスであり、内部プロトコルの相違をエンドユーザーに訴求する必要性は低い。ただ、冒頭に記したように2011年4月に日本でのIPv4アドレスの在庫が払底したこともあり、サーバやVPN 開設など何らかの理由で固定IPアドレスを必要とする場合、今後はISPやホスティング業者の保有するアドレス空間の使用状況にもよるが、いずれにせよIPv6でのIPアドレスの取得を検討せざるを得なくなる可能性が大きい。 IPv4とIPv6の最も大きな違いは、そのネットワークアドレスの長さにある。従来までのIPv4が32ビットであったのに対し、IPv6は128ビットである[ 17] 。
IPv6のアドレスは、前半部(プレフィックス,ネットワークID)と後半部(インタフェースID)に分けられて管理される[ 18] 。インタフェースIDは、一意性を得るためにMACアドレス などから生成されるModified EUI-64 フォーマットが使用されることが多いが、プライバシー上の懸念がある[ 注 4] ため、一意性およびプライバシーの双方を満たす仕様への変更が推奨されている(RFC 7217 、RFC 7721 、RFC 8064 )。サーバでは手動で静的に設定されることも多い[要出典 ] 。
アドレスの一意性は、最終的にはDuplicate Address Detection (DAD) という仕組みで保証される[ 19] 。
従来のIPv4では、アドレスの値を8ビット単位でドット(.)で区切り、十進法 で表記する[ 20] 。
[例] 192.0.2.1 IPv6では、128ビットを表記する際、IPv4と同様の表記では冗長 になりすぎるため、アドレスの値を16ビット単位でコロン(:)で区切り、十六進法 で表記する[ 21] 。
[例] 2001:0db8:bd05:01d2:288a:1fc0:0001:10ee この方法でも、まだ冗長であるため、以下のルールが適用される場合がある[ 22] 。
あるセクションが "0" で始まる場合、当該先行する "0" を省略することができる[ 23] 。 [例] 2001:0db8:0020:0003:1000:0100:0020:0003 = 2001:db8:20:3:1000:100:20:3 16ビット単位の記述で "0" が連続するところは "::" で省略することができる[ 23] 。ただし、"::" は可変長なので、1箇所だけ使用できる[ 24] 。 [例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 ) も存在し[ 25] 、同RFCのセクション4に従うと、以下のようになる。
あるセクションが "0" で始まる場合、当該先行する "0" は必ず省略する。 16ビット単位の記述で "0" が2回以上連続するところは、連続する "0" がいちばん長いフィールドを必ず "::" で省略する。連続する "0" の長さが同じ箇所が複数個ある場合は、最初(上位側)を省略する[ 26] 。 連続しない1回だけの "0" は省略してはならない[ 26] (RFC 3041 では許容されていなかったため)。 英字部分は必ず小文字を使用する[ 26] 。 その他、アドレスの種類によっては、以下のような特殊な表記が用いられることがある。
IPv4互換アドレスやIPv4射影アドレスでは、下位32ビットにIPv4アドレスが埋め込まれる。そのため、その部分だけIPv4の表記にすることが多い。 [例] ::ffff:192.0.2.1 [例1] fe80::0123:4567:89ab:cdef%4 [例2] fe80::0123:4567:89ab:cdef%fxp0 また、サブネットマスク は2001:0db8:9abc::/48 のように表記される。この場合、先頭から48ビット (2001:0db8:9abc) がネットワークアドレス部である。ただし、IPv4と異なり、グローバルアドレスのエンドユーザーへの割り当て 単位が通常は /48 か /64 であることから、通常目にするサブネットマスクは /48 か /64 であり、あまり意識することはない。これより大きい単位(/32 や /16 など)のサブネットマスクは、IPv6のアドレス体系、ルーティング およびISPに対する割り振り などの議論の際に登場する。
Webブラウザのアドレスバーへの入力など、URLのホストパートをIPv6アドレスで指定するときは、例えば::1ならば[::1]のように半角 の角括弧 でくくる。 (RFC 3986 )
IPv6には、以下の3種類のアドレスがある。
ユニキャスト アドレス一つのインタフェース に付与されているIPアドレス。一つのインタフェースを識別する。一つのコンピュータに多くのインタフェース(LANボード など)が実装されている場合は、インタフェースの数だけユニキャストアドレスを持つことになる。 マルチキャスト アドレス複数のノード に割り当てられるアドレス。このアドレス宛てに送信されたパケットは、複製されてこのアドレスに参加しているノードに配送される。ffxx:: で始まるアドレス。返信にはユニキャストアドレスが指定される。送信元がマルチキャストアドレスのパケットをルータは中継してはならない。 なお、IPv6にはブロードキャスト アドレスというものは存在しないが、必要な場合は、オールノードマルチキャストアドレス (ff02::1など) を使う。 エニーキャスト アドレス一つのアドレスが複数のノードに割り当てられているという点ではマルチキャストと似ているが、エニーキャストの場合は「そこに属しているノードの中で、ネットワーク上で一番近いノードのどれか一つのみに配送される」という点が異なる。 さらに、パケットの到達範囲(スコープ)によって、上記のアドレスそれぞれに対しリンクローカルスコープとグローバルスコープのアドレスが存在する。
リンクローカルスコープ あるリンクでのみ一意なアドレス[ 27] 。このスコープ宛てのパケットはルータを越えて配送されることはない。 グローバルスコープ 全IPv6で一意なアドレス。 以前はサイトローカルスコープというものもあったが、ほとんど使われないまま廃止された。
IPv6ノードのネットワークインタフェースには、必ずリンクローカルアドレス(link‐local address)が付与される[ 28] 。これは fe80:: というプレフィックスと、インタフェースIDとから生成されるのが通常であるが、そのリンク内で一意であれば手動で設定してもかまわない。
0:0:0:0:0:0:0:0 未定義アドレス (Unspecified Address) として定義されている[ 29] 。一般的には 0 を省略して:: と表記される。このアドレスはノード にまだアドレスが割り当てられていないことを意味し、ノードに割り当てられることはない[ 29] 。ノードの初期化段階において、アドレスの重複をチェックする場合などに送信元アドレスとして使用される。0:0:0:0:0:0:0:1 ループバックアドレス として定義されている[ 30] 。一般的には 0 を省略して::1 と表記される。IPv4では 127.0.0.0/8 の範囲の任意のアドレスをループバックアドレスとして使用できるが、IPv6 ではこのアドレスに限られる。ループバックアドレスであるため、このアドレスをインターフェイスに割り当てることはできない。IPv6を利用していて通常目にするアドレスは、グローバルユニキャストアドレス かリンクローカルユニキャストアドレス である。IPv6のアドレス空間については、#IPv6アドレス空間 参照。
グローバルユニキャストアドレス ルータ を超えて、インターネット上で通信可能なアドレスで、グローバルアドレス とも呼ばれる。IPv4 におけるグローバルIPアドレス に相当する。IANA が割り振りを管理しており、RIR 単位での割り振りは、IPv6 Global Unicast Address Assignments で公開されている。現在は、RFC 3587 により、アドレスの先頭3bitが001であるアドレスのみIANAが割り振りを行っている。128ビットの内訳 長さ 説明 nビット グローバルID(グローバル・ルーティング・プレフィックス) 64-nビット サブネットID 64ビット インターフェイスID
(グローバル・ルーティング・プレフィックスは、IANA、RIRおよびNIRからISPなどのLIRに割り振られたものの中から、ISPなどのLIRがエンドユーザに割り当てられたものを使用する。) このうち、特定の用途に使用されているものとしては、以下のものがある。 アドレス 説明 2001::/32 Teredo (RFC 4380 ) 2001:2::/48 BMWG (RFC 5180 ) ※ルータでは中継されない 2001:10::/28 ORCHID (RFC 4843 ) ※ルータでは中継されない 2002::/16 6to4 (RFC 3056 ) ※Historical (RFC 7526 ) 2001:db8::/32 文書作成用アドレス空間 (RFC 3849 ) ※ルータでは中継されない。マニュアルなどの文書中のみで利用するIPアドレス例示用で、実存のアドレスではない事が保証されている。なお、このアドレスを含むネットブロック2001:c00::/23はAPNIC に割り当てられている。
リンクローカルユニキャストアドレス (RFC 4291 ) 各ネットワークインターフェース毎に、初期化時に自動生成し、LAN の同一セグメント 内でのみ有効なアドレス。IPv6のルータでは中継されないため、インターネット上とのホストとの通信には使用できない。プレフィックスは常に fe80::/64となる。 128ビットの内訳 長さ 説明 10ビット プレフィックス (1111111010) 54ビット 0固定 64ビット インターフェイスID
ユニークローカルユニキャストアドレス (RFC 4193 )IPv4 におけるプライベートIPアドレス と同様に、ローカルでの使用向けに使われるアドレス。fd00::/8 アドレスの一部をランダムに生成して使用する。完全な一意性は保証されないものの、異なる組織でアドレスが重複する可能性は低い。 128ビットの内訳 長さ 説明 7ビット プレフィックス (1111110) 1ビット L(1=局所的な割り当て、0は現在未定義) 40ビット グローバルID(乱数) 16ビット サブネットID 64ビット インターフェイスID
(グローバルIDは、各ネットワーク単位で乱数を用いて決定することになっている。国際機関で一意に管理されている値ではないため、ユニークローカルユニキャストアドレスはローカルアドレスであってグローバルアドレスとしては運用できない。) IPv6 アドレス割当のまとめ[ 31] [ 32] アドレス 割り当て IPv4 の相当する割り当て :: (アドレス未定義を示す) 0.0.0.0 ::1 ループバック 127.0.0.0/8 ::/96 IPv4互換アドレス(廃止 ) ::ffff:0:0/96 IPv4射影アドレス 64:ff9b::/96 IPv6移行技術 (RFC 6052 )64:ff9b:1::/48 IPv6移行技術 (RFC 8215 )100::/64 Discard-Only Address Block (RFC 6666 ) 2000::/3 グローバルユニキャストアドレス グローバルアドレス 2001::/23 Protocol Assignments (RFC 2928 ) 2001::/32 Teredo 2001:1::1/128 Port Control Protocol Anycast (RFC 7723 ) 2001:1::2/128 Traversal Using Relaysaround NAT Anycast (RFC 8155 )
2001:2::/48 Benchmarking (RFC 5180 ) 2001:3::/32 Automatic Multicast Tunneling (RFC 7450 ) 2001:4:112::/48 AS112-v6 (RFC 7535 ) 2001:5::/32 EID Space for LISP (RFC 7954 )[ 注 14] 2001:10::/28 ORCHID(廃止 ) 2001:20::/28 ORCHIDv2 (RFC 7343 ) 2001:db8::/32 文書記述用アドレスプレフィックス 2002::/16 6to4 ※Historical[ 33] 2620:4f:8000::/48 RFC 7534 3ffe::/16 6bone - IPv6 の実装実験用(廃止 ) 3fff::/20 文書記述用アドレスプレフィックス (RFC 9637 ) fc00::/7 ユニークローカルユニキャストアドレス プライベートアドレス fc00::/8 集中管理 fd00::/8 ローカル管理 fe80::/10 リンクローカルユニキャストアドレス 169.254.0.0/16 (APIPA ) fec0::/10 サイトローカルユニキャストアドレス(廃止 ) プライベートアドレス ff00::/8 マルチキャストアドレス 224.0.0.0/4 ff01::/16 ノードローカル ff01::1 全ノード ff01::2 全ルーター ff02::/16 リンクローカル ff02::1 全ノード ff02::2 全ルーター ff02::4 DVMRP ルーター ff02::5 OSPF IGP ff02::6 OSPFIGP指定ルーター ff02::7 ST ルーター ff02::8 STホスト ff02::9 RIP ルーター224.0.0.9 (RIPv2) ff02::a EIGRP ルーター ff02::b 移動エージェント ff02::c SSDP (英語版 ) ff02::d 全PIM ルーター ff02::e RSVP カプセル化 ff02::1:1 リンク名 ff02::1:2 全DHCPエージェント ff02::1:3 LLMNR (英語版 ) 224.0.0.252 ff05::/16 サイトローカル ff05::2 全ルーター ff05::1:3 全DHCPサーバー ff05::1:4 全DHCPリレー ff05::1:c SSDP (英語版 ) 239.255.255.250 ff0e::/16 グローバル ff0e::c SSDP (英語版 )
アドレス先頭の空白の付加は非推奨であるが、分かりやすさ(或いはソート)のため付けている。 廃止されていても過去の実装では使用している場合がある。 廃止されたまたは表外のアドレス空間についても、ほぼIETFによって予約されているので自由に使用できる訳ではない。 IPv6のヘッダ構造 IPv6のヘッダはIPv4ではあまり使われなかったものが廃止されるなど簡略化されているが、アドレス長が長くなっているので、ヘッダ長はIPv4の20バイトから40バイトに増加している。
また、様々なオプションがエクステンションヘッダとして定義され、これは前のヘッダが次のヘッダのタイプを示すことで数珠つなぎにすることが可能となっている。また使用する順番がほぼ固定されている。主に送信元や中継のルータが使用するオプションは前の方に、到着したルータやノードに対してのオプションは最後の方に定義される。
IPv6で定義されているエクステンションヘッダは次の通り。
ホップバイホップオプション 途中通過するルータで処理されるオプションが格納されているヘッダ[ 34] 。 宛先オプション 最終あて先ノードで処理されるオプションが格納されているヘッダ[ 35] 。 経路ヘッダ 途中通過する経路のIPアドレスを格納したヘッダ。ソース・ルーティング に使用される。IPv4のルーティングヘッダとほぼ同じ。 フラグメントヘッダ フラグメント情報を格納するヘッダ。IPv6では途中のルータがフラグメントを分割・再構成することはなく、送信元でのみ行われる。送信・受信の各ホストで経路MTU探索 (Path MTU Discovery) を行い、送信するパケットのサイズを調整する。 認証ヘッダ IPsec AH の認証データを格納するヘッダペイロード暗号化ヘッダ IPsec ESP の情報を格納するヘッダ。暗号化されたパケットは、IPヘッダとこのESPヘッダ以外は暗号化される。 近隣探索 (Neighbor Discovery)[ 編集 ] IPv4 では通信相手のIPアドレス からそのMACアドレス を取得するためにARP を用いていたが、IPv6 では近隣探索 (Neighbor Discovery) という方法が用いられる[ 36] 。
これは、ICMP の IPv6 版であるICMPv6 の枠組み(NDP、Neighbor Discovery)を用いてアドレス解決する[ 36] 。アドレス解決をしたいノード はペイロード に解決したいアドレスを格納して、マルチキャスト アドレスに IPv4 の ARP request に相当する Neighbor Solicitation (NS) パケットを送信し、それに答えるべきノードは、Target linklayer address option に自ノードの MAC アドレスを格納した Neighbor Advertisement (NA) を送信してアドレス解決を行う。RFC 4861 で規定されている。
IPv6ではDHCPを用いなくてもルータさえあればアドレスの自動設定が可能となっている (RFC 4862 )。これをステートレスアドレス自動設定 (Stateless Address Autoconfiguration、SLAAC)と言う。
ルータは自分の接続しているネットワークに対し、定期的にあるいは要請に基づいて、そのネットワークに関する情報を送信している[ 37] 。これはルータ広告(Router advertisement; RA)と言い、近隣探索プロトコルの中で規定されている。ルータ広告に含まれるプレフィックス情報と一意のインタフェースIDを用いて、IPv6ホストはグローバルアドレスを生成する。同時に、そのIPv6ホストは受信したRAを送信したルータをデフォルト経路に設定することで、グローバルIPv6ネットワークへの接続性も確保できる。
しかし、この仕組みでは名前解決のためのDNSサーバのアドレスを取得することはできないため、それにはDHCPv6 など別の仕組みが必要になる。
DHCPv6サーバから自動的にIPが割り当てられるものは、どのPCがどのIPアドレスかがDHCPサーバに記録されているので、ステートフルアドレス自動設定と呼ばれる。一方、この「ステートレスアドレス自動設定」はルータからIPが割り当てられるが、どのPCにどのIPが割り当てられたかをルータ自身は知らない。状況を知らないのでステートレスなのである。
概念的にはIPv4とIPv6はほぼ同等と言えるが、実際のパケットフォーマットは完全に異なる上、IPアドレス空間の大きさも違うため、1対1対応はできない。そのため、IPv6ノードとIPv4ノードが互いに直接通信することはできない[ 38] 。そのため、IPv6とIPv4との通信用にいくつかの仕組み、プロトコルが提案されている。
また、IPv6/IPv4トランスレータと呼ばれる装置によって、プロトコル変換を行う方法がある[ 39] 。例えば、Proxy方式では、OSI参照モデルで上位層であるアプリケーション層でプロトコル変換を行うことで、ネットワーク層であるIPプロトコルの違いを隠蔽している。これにより、利用者からみた場合、IPv4のプライベートアドレスが使用されているLAN内から、IPv4/IPv6に関係なくURLで、インターネット上のサイトにアクセスできるように見える。
IPv6のネイティブな接続を提供しているISPはまだ少ない。そのため、IPv4パケット上にIPv6パケットをカプセル化して通すトンネリング 技術を使い、既存のIPv4インフラを利用してIPv6を提供するISPもある。トンネリングに用いられる技術には以下のようなものがある。
IPv4のネットワーク上でIPv6のパケットを搬送するためのトンネリング IPv6のネットワーク上でIPv4のパケットを搬送するためのトンネリング 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で通信することはない[ 40] 。 UNIX系OSでの留意事項 基本的にカーネルの版数やディストリビューション、パッケージの構成に依存するため、どの方式のトンネリングが使用できるかは明示できない。Linuxの場合、ディストリビュータによるサポート範囲では、6over4、ISATAP、6to4程度である場合がある。 実際にIPv6ネットワークを新たに導入する場合は、既存のIPv4空間との通信と併存両立させるために、ISPとユーザー側の双方でIPv6対応設備機器の追加、更新が必要となる。なお、端末、サーバー、OS 、アプリケーションなどの対応についてはIPv6への対応 を参照。
エンドユーザ向けのルーターなどのCPE については、既存のルーターが持っていることが多いIPv6ブリッジ機能[ 注 15] だけでは対応できない方式が多く、CPE機器の更新が必要になる場合も多い。
なお、IPv6とIPv4を共存させる方式として、以下のようなものがある。ただし、どの方式によるかは接続するプロバイダや通信環境などに依存する部分が多い。
6rd方式、および、その派生方式 6rd (IPv6 rapid deployment) は、RFC 3056 で標準化されているIPv6/IPv4トンネリング 技術である6to4を土台として設計された方式である。基本的には途中のIPv4空間にIPv6の信号を流すためのトンネルを設定する形である。2011年4月時点でのIPv6 over IPv4の文脈上で「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で通信することはない[ 40] 。 IPv6とIPv4のデュアルスタック (DS) +NAT444方式、および、その派生方式 IPv6については、そのまま接続し、IPv4については複数階層のNAPT (NAT444 : (NAT444 with ISP Shared Address )) を経由する方式である。イメージとしては、現在のルータなどを使った複数端末のIPv4接続で使用しているNAPTを複数回行って、接続に使用するIPv4のIPアドレスを節約しようとするものである。 IPv4についての流れはエンドユーザ(v4プライベート)→ユーザNAPT(v4グローバル共有)→ISPNAPT(v4グローバル単独)→v4網 となる 複数の端末で、IPv4のグローバルアドレスを共有する関係上、端末当たりのセッション数が制限され、アプリケーションが正常に利用できない場合がある。また、プロバイダ側で管理する通信ログの扱いが煩雑であり、負担が大きい。IPv4による通信では、多段NATとなるため、エンドユーザー間でのP2Pによる直接通信は不可能となる。 導入に関しては、比較的容易である。特に、IPv6ブリッジ機能があるルーターを使用している場合には、エンドユーザ側については、設定変更やIPv6の接続用アプリケーションの追加のみで対応できる場合がある。 DS-Lite (Dual-stack lite) 方式や、SAM (Stateless Address Mapping ) 方式、および、それらの派生方式 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による直接通信は可能になる。 NTT (東日本 、西日本 )のフレッツ 網は、実運用されているIPv6のネットワークとしては2023年現在で約2363万 回線[ 41] を有する世界最大級のネットワークである。フレッツ網におけるIPv6の適用の詳細については、上記項目を参照。
^ ミドルウェア やサービスコンポーネントを含む^ 石の定義は「2mm以上の岩石」であり、地球表面から人類が到達した最大深度約6000 mまでの体積は約31億 km3 なので、人類が地球上で観測しうる石の数は最大でも1.988× 10 27 個程度となり、IPv6アドレスの総数約3.40× 10 38 個よりも遥かに少ない。 ^ ユリウス年 (1年は正確に365.25日 = 3155万7600秒)で計算した場合。^a b Modified EUI-64の使用はセキュリティとプライバシーの観点からRFC 8064 にて非推奨とされた。 ^ NICを交換するか、あるいは利用端末を廃棄するまでの間 ^ 接続ネットワークを変えたとしても(なお、固定利用とモバイル利用で状況が相異なる)、インターフェイスIDが不変のため、追跡可能 ^ セキュリティについてはファイアウォール 、IPS 、UTM などで確保すべきであり、匿名性に頼るべきではないとの主張もある。 [要出典 ] ^ 匿名アドレスとも言う。生成した一時アドレスは数時間 - 数日程度の有効期限を定め、超過した場合は廃棄し新しいアドレスを生成する。使い捨ての一時的なアドレスと言う主旨である。 ^ 携帯電話ネットワーク(LTEなど)に接続した場合を言う。スマートフォンからWi-Fiアクセスポイントに接続した場合は、固定利用の場合に準ずる。 ^ 古い携帯端末では一時アドレスに対応していない場合がある。 ^ フレッツ光ネクスト (NGN) 経由、各種トンネル経由、フレッツ以外のネイティブ事業者、その他によって相異なる ^ 固定利用の場合には、プレフィックスが半固定となるため、ユーザーCPEを概ね識別、特定可能となる。プレフィックスが変動するタイミングは不定であり、周期的に変更される事もあれば、ISPを全面的に乗り換えするまで同一と言う事も有り得る。 ^ ただし、IPv4においても半固定のIPアドレスをユーザーに割り当てるISPにおいては同様の問題が生ずる。 ^ 2019年9月まで有効 ^ IPv6のパケットを解釈せず単に通過させるだけの機能を言う ^ 小川 2018 , pp. iii, 3–4.^ “インターネットのIPv4アドレス枯渇対応について ”. 総務省 . 2024年11月10日閲覧。 ^ 小川 2018 , p. 3.^ 小川 2018 , pp. 3–4.^ “The IP Addressing Issue ”. 2013年12月14日閲覧。 ^ 小川 2018 , p. 32.^a b “IPv6利用統計 ”. 2014年11月19日閲覧。 ^ “ついに国内のIPv6利用率が50%超え、IPv4のままでは何がまずい? ”. 日経BP. 2024年5月31日閲覧。 ^ 小川 2018 , pp. 40–43.^ 安力川幸司,伊藤孝史,泉川晴紀 (2017年11月13日). “スマートフォンへのIPv6導入に向けた取り組み ”. 2021年6月12日閲覧。 ^a b 小川 2018 , p. 39. ^a b 小川 2018 , p. 87. ^ “CIDR REPORT ”. 2014年10月12日時点のオリジナル よりアーカイブ。2014年10月28日閲覧。 ^a b https://www.nic.ad.jp/ja/newsletter/No54/0800.html ^ “国内スマホユーザーを“IPv6デフォルト化”する計画が明らかに、携帯キャリア大手3社が2017年夏ごろ対応開始 ”. 2017年4月11日閲覧。 ^ “IIJ: IIJ「フレッツ・シリーズ」対応サービス ”. 2017年4月11日閲覧。 ^ 小川 2018 , p. 37.^ 小川 2018 , p. 38.^ 小川 2018 , pp. 153–156.^ 小川 2018 , p. 56.^ 小川 2018 , p. 57.^ 小川 2018 , pp. 57–58.^a b 小川 2018 , p. 58. ^ 小川 2018 , p. 59.^ 小川 2018 , pp. 59–60.^a b c 小川 2018 , p. 60. ^ 小川 2018 , p. 66.^ 小川 2018 , p. 70.^a b 小川 2018 , p. 63. ^ 小川 2018 , p. 64.^ “Internet Protocol Version 6 Address Space ”. 2017年5月4日閲覧。 ^ “IANA IPv6 Special-Purpose Address Registry ”. 2017年5月4日閲覧。 ^ (RFC 7526 ) ^ 小川 2018 , p. 94.^ 小川 2018 , p. 95.^a b 小川 2018 , pp. 101, 122. ^ 小川 2018 , p. 114-116.^ 小川 2018 , p. 47.^ “IPv6/IPv4トランスレータとは ”. 2011年2月18日閲覧。 ^a b “Windows Vistaでのドメインネームシステムクライアントの動作 ”. 2011年2月26日閲覧。 ^ “FTTHの上期純増数は41.6万件、2003年度以降で過去最低 ≪ プレスリリース ”. 株式会社MM総研 . 2024年5月9日閲覧。