Wikipedia

IPv6

IPv4アドレス枯渇問題を解決するために開発されたネットワーク層のプロトコル
（IPv6ヘッダから転送）

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

IPv6のロゴ
→「IPv6アドレス」も参照

現在主流の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へ移行することが課題になっている。

IPv6開発の推移

編集
  • 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のフレッツ 光ネクストにおいて、IPv6 PPPoE接続が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への対応

編集

現状と展望

編集

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のIPv6対応

編集
→「フレッツ網におけるIPv6」も参照

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

OSのIPv6対応

編集

パソコンやサーバ向けのオペレーティングシステム (OS) は、Microsoft WindowsやLinuxをはじめとしてほとんどのものがIPv6に対応している。しかしIoT機器などで使われる組み込み向けのOSなど、一部にはIPv6に対応していないOSもある。

アプリケーションのIPv6対応

編集

一般のユーザーが利用するアプリケーションは、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サポート

編集

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導入による得失

編集

メリット

編集

一般に言われている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アドレスの取得を検討せざるを得なくなる可能性が大きい。

IPv6 のアドレス

編集
→詳細は「IPv6アドレス」を参照

IPv6 のアドレス構造

編集

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]。

IPv6 のアドレス表記

編集

従来の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アドレスの種類

編集

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
::/96IPv4互換アドレス（廃止） 
::ffff:0:0/96IPv4射影アドレス 
64:ff9b::/96IPv6移行技術 (RFC 6052)
64:ff9b:1::/48IPv6移行技術 (RFC 8215)
100::/64Discard-Only Address Block (RFC 6666)
2000::/3グローバルユニキャストアドレスグローバルアドレス
 2001::/23Protocol Assignments (RFC 2928)
2001::/32Teredo 
2001:1::1/128Port Control Protocol Anycast (RFC 7723)
2001:1::2/128Traversal Using Relays

around NAT Anycast (RFC 8155)

2001:2::/48Benchmarking (RFC 5180) 
2001:3::/32Automatic Multicast Tunneling (RFC 7450)
2001:4:112::/48AS112-v6 (RFC 7535)
2001:5::/32EID Space for LISP (RFC 7954)[注 14]
2001:10::/28ORCHID（廃止） 
2001:20::/28ORCHIDv2 (RFC 7343)
2001:db8::/32文書記述用アドレスプレフィックス 
2002::/166to4 ※Historical[33] 
2620:4f:8000::/48RFC 7534
3ffe::/166bone - 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::4DVMRPルーター 
ff02::5OSPFIGP 
ff02::6OSPFIGP指定ルーター 
ff02::7STルーター 
ff02::8STホスト 
ff02::9RIPルーター224.0.0.9 (RIPv2)
ff02::aEIGRPルーター 
ff02::b移動エージェント 
ff02::cSSDP（英語版） 
ff02::d全PIMルーター 
ff02::eRSVPカプセル化 
ff02::1:1リンク名 
ff02::1:2全DHCPエージェント 
ff02::1:3LLMNR（英語版）224.0.0.252
ff05::/16サイトローカル 
 ff05::2全ルーター 
ff05::1:3全DHCPサーバー 
ff05::1:4全DHCPリレー 
ff05::1:cSSDP（英語版）239.255.255.250
ff0e::/16グローバル 
 ff0e::cSSDP（英語版） 
  • アドレス先頭の空白の付加は非推奨であるが、分かりやすさ（或いはソート）のため付けている。
  • 廃止されていても過去の実装では使用している場合がある。
  • 廃止されたまたは表外のアドレス空間についても、ほぼIETFによって予約されているので自由に使用できる訳ではない。

プロトコル

編集

ヘッダ

編集
 
IPv6のヘッダ構造
→詳細は「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移行技術」を参照

IPv4との互換性

編集

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

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

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

トンネリング

編集

IPv6のネイティブな接続を提供しているISPはまだ少ない。 そのため、IPv4パケット上にIPv6パケットをカプセル化して通すトンネリング技術を使い、既存のIPv4インフラを利用してIPv6を提供するISPもある。 トンネリングに用いられる技術には以下のようなものがある。

  1. IPv4のネットワーク上でIPv6のパケットを搬送するためのトンネリング
  2. 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

編集
→詳細は「フレッツ網におけるIPv6」を参照

NTT（東日本、西日本）のフレッツ網は、実運用されているIPv6のネットワークとしては2023年現在で約2363万 回線[41]を有する世界最大級のネットワークである。フレッツ網におけるIPv6の適用の詳細については、上記項目を参照。

脚注

編集
[脚注の使い方]

注釈

編集
  1. ^ ミドルウェアやサービスコンポーネントを含む
  2. ^ 石の定義は「2mm以上の岩石」であり、地球表面から人類が到達した最大深度約6000 mまでの体積は約31億 km3なので、人類が地球上で観測しうる石の数は最大でも1.988×1027個程度となり、IPv6アドレスの総数約3.40×1038個よりも遥かに少ない。
  3. ^ ユリウス年（1年は正確に365.25日 = 3155万7600秒）で計算した場合。
  4. ^ a b Modified EUI-64の使用はセキュリティとプライバシーの観点からRFC 8064にて非推奨とされた。
  5. ^ NICを交換するか、あるいは利用端末を廃棄するまでの間
  6. ^ 接続ネットワークを変えたとしても（なお、固定利用とモバイル利用で状況が相異なる）、インターフェイスIDが不変のため、追跡可能
  7. ^ セキュリティについてはファイアウォール、IPS、UTMなどで確保すべきであり、匿名性に頼るべきではないとの主張もある。[要出典]
  8. ^ 匿名アドレスとも言う。生成した一時アドレスは数時間 - 数日程度の有効期限を定め、超過した場合は廃棄し新しいアドレスを生成する。使い捨ての一時的なアドレスと言う主旨である。
  9. ^ 携帯電話ネットワーク（LTEなど）に接続した場合を言う。スマートフォンからWi-Fiアクセスポイントに接続した場合は、固定利用の場合に準ずる。
  10. ^ 古い携帯端末では一時アドレスに対応していない場合がある。
  11. ^ フレッツ光ネクスト (NGN) 経由、各種トンネル経由、フレッツ以外のネイティブ事業者、その他によって相異なる
  12. ^ 固定利用の場合には、プレフィックスが半固定となるため、ユーザーCPEを概ね識別、特定可能となる。プレフィックスが変動するタイミングは不定であり、周期的に変更される事もあれば、ISPを全面的に乗り換えするまで同一と言う事も有り得る。
  13. ^ ただし、IPv4においても半固定のIPアドレスをユーザーに割り当てるISPにおいては同様の問題が生ずる。
  14. ^ 2019年9月まで有効
  15. ^ IPv6のパケットを解釈せず単に通過させるだけの機能を言う

出典

編集
  1. ^ 小川 2018, pp. iii, 3–4.
  2. ^ “インターネットのIPv4アドレス枯渇対応について”. 総務省. 2024年11月10日閲覧。
  3. ^ 小川 2018, p. 3.
  4. ^ 小川 2018, pp. 3–4.
  5. ^ “The IP Addressing Issue”. 2013年12月14日閲覧。
  6. ^ 小川 2018, p. 32.
  7. ^ a b “IPv6利用統計”. 2014年11月19日閲覧。
  8. ^ “ついに国内のIPv6利用率が50％超え、IPv4のままでは何がまずい？”. 日経BP. 2024年5月31日閲覧。
  9. ^ 小川 2018, pp. 40–43.
  10. ^ 安力川幸司,伊藤孝史,泉川晴紀 (2017年11月13日). “スマートフォンへのIPv6導入に向けた取り組み”. 2021年6月12日閲覧。
  11. ^ a b 小川 2018, p. 39.
  12. ^ a b 小川 2018, p. 87.
  13. ^ “CIDR REPORT”. 2014年10月12日時点のオリジナルよりアーカイブ。2014年10月28日閲覧。
  14. ^ a b https://www.nic.ad.jp/ja/newsletter/No54/0800.html
  15. ^ “国内スマホユーザーを“IPv6デフォルト化”する計画が明らかに、携帯キャリア大手3社が2017年夏ごろ対応開始”. 2017年4月11日閲覧。
  16. ^ “IIJ: IIJ「フレッツ・シリーズ」対応サービス”. 2017年4月11日閲覧。
  17. ^ 小川 2018, p. 37.
  18. ^ 小川 2018, p. 38.
  19. ^ 小川 2018, pp. 153–156.
  20. ^ 小川 2018, p. 56.
  21. ^ 小川 2018, p. 57.
  22. ^ 小川 2018, pp. 57–58.
  23. ^ a b 小川 2018, p. 58.
  24. ^ 小川 2018, p. 59.
  25. ^ 小川 2018, pp. 59–60.
  26. ^ a b c 小川 2018, p. 60.
  27. ^ 小川 2018, p. 66.
  28. ^ 小川 2018, p. 70.
  29. ^ a b 小川 2018, p. 63.
  30. ^ 小川 2018, p. 64.
  31. ^ “Internet Protocol Version 6 Address Space”. 2017年5月4日閲覧。
  32. ^ “IANA IPv6 Special-Purpose Address Registry”. 2017年5月4日閲覧。
  33. ^ (RFC 7526)
  34. ^ 小川 2018, p. 94.
  35. ^ 小川 2018, p. 95.
  36. ^ a b 小川 2018, pp. 101, 122.
  37. ^ 小川 2018, p. 114-116.
  38. ^ 小川 2018, p. 47.
  39. ^ “IPv6/IPv4トランスレータとは”. 2011年2月18日閲覧。
  40. ^ a b “Windows Vistaでのドメインネームシステムクライアントの動作”. 2011年2月26日閲覧。
  41. ^ “FTTHの上期純増数は41.6万件、2003年度以降で過去最低 ≪ プレスリリース”. 株式会社ＭＭ総研. 2024年5月9日閲覧。

参考文献

編集

関連項目

編集
  • トンネリング
  • KAME - BSD系OSでのIPv6参照実装プロジェクト
  • ICMPv6
  • DHCPv6
  • 萩野純一郎 - itojunの名で活躍したIPv6の代表的な開発者の一人。KAMEプロジェクトを通じたIPv6参照ソフトウェアの研究開発やIETFにおける標準化活動など、次世代インターネット技術の確立と普及に向けて、献身的な貢献をした。その貢献を賞して、次世代インターネット技術に貢献した人物にItojun Service Awardが贈られるようになった。
  • Mobile IPv6 - 移動体ノードで一定のIPv6アドレスを保持して通信可能にするプロトコル
  • IPv4

外部リンク

編集

IPv6アドレス空間

編集
「https://ja.wikipedia.org/w/index.php?title=IPv6&oldid=103037483#ヘッダ」から取得