RFC 9386: IPv6の導入状況

要旨

本文書は、2022年のIPv6の普及の度合いを概観するものである。具体的には、業界におけるIPv6の普及の程度を調査し、残された課題を分析し、業界がIPv6への移行において明確かつ統一的なアプローチを取っていない分野でのさらなる調査を提案する。RFC 6036 は廃止する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9386 で入手できる。

著作権表示

Copyright (c) 2023 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

[RFC6036]は、2010年初めに技術アンケートに回答した多くのインターネット・サービス・プロバイダ(ISP)が採用または予測していたIPv6導入シナリオを記述しており、[RFC6036]はまた、次の年に行われると予想される実践と計画も提供している。[RFC6036]の発行以降、運用環境におけるIPv6移行の議論に貢献した他の文書がいくつかある。いくつか例を挙げると:

• [RFC6180]は、IPv6の導入モデルと移行メカニズムについて議論し、運用中のネットワークで効果的であることが証明されているものを推奨している。
• [RFC6883]は、インターネット・コンテンツ・プロバイダとアプリケーション・サービス・プロバイダ(ASP)のためのガイダンスと提案を提供している。
• [RFC7381]は、企業向けのIPv6導入のガイドラインを紹介している。

[RFC6540]は、すべてのIP対応ノードにIPv6のサポートを推奨している。これは、IPv6に関するIAB声明[IAB]で参照され、IETFや他の標準開発機関(SDO)をIPv6の利用に向けて推進する大きな一歩となった。

最近では、ETSIのような組織が、さまざまな業界におけるIPv6を対象として、運用環境でのIPv6の利用により多くの貢献をした。その結果、特にISPドメインでこれまでに採用されたIPv6のベスト・プラクティスに関する最新の見解を提供するために、[ETSI-IP6-WhitePaper]が発行された。

以上のことを考慮すると、[RFC6036]の発行から10年以上が経過した今、IPv6への移行状況を評価することは有益である。理由としては次のようなものが挙げられる。

• 一部の地域では、IPv4アドレスの不足により、通信事業者とコンテンツ・プロバイダの双方が、特にワイヤレス・ネットワークにおける新しいアプリケーションの導入をサポートするためにIPv6への移行を余儀なくされた。
• いくつかの国では、IPv6の採用を奨励したり、強制したりするために、いくつかの政府の措置が講じられた。
• IPv6の世界的な普及状況を見ると、少なくともIPv6サービス層では、これはエンドツーエンドのIPv6接続を正当化されるしきい値に達しているようだ。

本文書は、IPv6の導入状況を調査し、IPv6ネットワークへの移行(およびIPv4サービスとの共存)における成果と残された障害の両方を明らかにすることにある。目標は、 [RFC6036]ですでに説明されている実践と計画の最新情報を提供することであり、まだ議論中の分野でのさらなる行動と調査を奨励し、IPv6採用の主なインセンティブを提示することである。

本文書は、さまざまな業界やネットワーク・ドメインにおけるIPv6の状況を理解することに関心のある一般読者を対象としている。ネットワーク・サービスを提供または利用する人は、IPv6への移行に役立つと思われる。また、組織や業界でIPv6導入計画を策定している人は、分析のための情報や参考資料を見つけることができるだろう。IPv6ネットワークとサービスへの移行のさまざまな段階に注意が払われている。特に、「IPv6-only」の使用に関する用語が提供されており、IPv6-onlyのネットワークとサービスがこのような移行の最終段階であると考えられている。

本文書で取り上げるトピックは、4つの主要な章で構成されている。

• セクション2では、IPv6の状況に関するデータと分析を報告する。
• セクション3では、 ISP、企業、大学など、さまざまな環境におけるIPv6の導入状況を調査している。
• セクション4では、モバイル・ブロードバンド (MBB)、固定ブロードバンド (FBB)、企業におけるIPv6導入アプローチについて説明する。
• セクション 5では、 IPv6移行において解決すべき一般的な課題を分析する。運用、パフォーマンス、セキュリティの問題には特に注意が払われている。

1.1. 用語

本セクションでは、本文書における「IPv6-only」という表現の使用に関する用語を定義する。IPv6-onlyという用語は、それが指す特定のスコープに関連して定義される。この点で、サービス、ネットワーク、さらにはノードの一部のみがIPv6-onlyスコープに含まれ、残りは含まれない場合がある。さまざまなスコープに関連して最もよく使用される用語を以下に示す:

IPv6-onlyインタフェース:
ノードのインタフェースは、IPv6のみを転送するように設定されている。同じノードの残りのインタフェースはIPv4でも動作する可能性があるため、ノードの一部だけがIPv6-onlyであることを示す。デュアルスタック・インタフェースは、IPv6-onlyインタフェースではない。

IPv6-onlyノード:
IPv6のみを使用するノードをいう。ホストのすべてのインタフェースはIPv6アドレスしか持っていない。

IPv6-onlyサービス:
ホストのインタフェースとコンテンツ・サーバのインタフェースの間で、サービス・セッションのすべてのパケットヘッダがIPv6である場合に使用される。

IPv6-onlyオーバーレイ:
トンネルのエンドポイント間で、トンネルのすべての内部パケットヘッダがIPv6である場合に使用される。例えば、固定ネットワークにおける IPv6-onlyオーバーレイとは、プロバイダ・エッジ(PE)ノードのインタフェース間、またはカスタマ・プロバイダ・エッジ (CPE)ノードとブロードバンド・ネットワーク・ゲートウェイ(BNG)間のカプセル化が IPv6-onlyであることを意味する。

IPv6-onlyアンダーレイ:
データプレーンとコントロールプレーンがIPv6の場合に使用されるが、必ずしもマネジメントプレーンがそうであるとは限らない。例えば、固定ネットワークにおけるIPv6-onlyアンダーレイは、PEノード間のアンダーレイ・ネットワーク・プロトコルがIPv6-onlyであることを意味するが、オーバーレイではデュアルスタックであることもある。Segment Routing over IPv6 (SRv6)はIPv6-onlyのアンダーレイの一例である。

IPv6-onlyネットワーク:
このネットワーク内のすべてのノードがIPv6-onlyの場合に使用する。IPv6-onlyネットワークにIPv4は存在してはならない。特に、IPv6-onlyネットワークのデータプレーン、コントロールプレーン、マネジメントプレーンはIPv6でなければならない。すべてのPEはIPv6-onlyでなければならない。したがって、PE間にトンネルが存在する場合は、その内部ヘッダと外部ヘッダの両方がIPv6でなければならない。例えば、IPv6-onlyアクセスネットワークは、このアクセスネットワーク内のすべてのノードがIPv6-onlyでなければならないことを意味し、同様に、IPv6-onlyバックボーンネットワークは、このバックボーンネットワーク内のすべてのノードが IPv6-onlyでなければならないことを意味する。

IPv4-as-a-Service (IPv4aaS):
IPv4サービスのサポートは、移行メカニズムによって提供されるため、カプセル化/変換 + IPv6-onlyアンダーレイ + カプセル化解除/変換の組み合わせとなる。IPv6-onlyネットワークでは、レガシーなIPv4への接続は存在しないか、IPv4aaSメカニズムによって提供される。

IPv6-onlyの定義は[IPv6-ONLY-DEF]でも検討されていることに注意する。

2. IPv6: グローバルな全体像

このセクションでは、IPv6に関連するいくつかの重要な質問、つまり、(1) IPv6 への切り替えのきっかけの1つと考えられるIPv4枯渇状況、(2) IPv6の普及を意味する主要な指標となるIPv6エンドユーザの数、(3) IPv6でアクセス可能なウェブサイトの割合、(4) IPv6 の公的活動と政策に関する報告について取り扱う。

これらの特徴は、IPv6の普及に関する一次指標となるため、世界中の地域インターネット・レジストリ (RIR)や他の機関によって監視されている。

2.1. IPv4アドレスの枯渇

[CAIR]によると、ネットワークに接続されているデバイス数は、2018年の184億から2023年には293億になると予想されている。このことは、IPv4アドレス空間がそのような数の割り当てを維持できるかどうか、ひいては、それが枯渇プロセスに影響を与える可能性があるかどうかという疑問を提起する。多くの側面を考慮しなければならないため、その答えは簡単ではない。

一方で、RIRは利用可能なアドレスとまだ予約済アドレスが不足していると報告している。[POTAROO1]の表3(2022年1月)によると、2021年末時点で5つのRIRの利用可能なIPv4アドレスプールは520万で、予約済プールはさらに1,210万、合計1,730万である(2021 年と2020年を比較すると、前年比-5.5%)。[POTAROO1]の表1によると、IPv4割り当てプールの合計が36億8,500万アドレス(前年比 +0.027%)に相当する。利用可能なアドレスと割り当てられた総アドレスの比率は、残りのIPv4アドレス空間の0.469% となった(2020年末時点では0.474%)。

他方で、[POTAROO1]は、IPv4枯渇に対処するために、アドレス移転とネットワークアドレス変換(NAT)の両方の役割を再度強調している。IPv4アドレスの移転は、RIRの管理や登録の下で行われることもあれば、第三者がIPv4アドレスの売買を行う、いわゆるグレーマーケットで行われることもある。いずれの場合も、IPv4アドレスは、アドレス範囲を拡張する必要がある別の保有者に「移転」される。例として、[IGP-GT]と[NRO]は、さまざまな地域の受取組織への移転量を示している。クラウド・サービス・プロバイダ(CSP)は、テナントにIPv4接続を提供するというニーズを満たすために、IPv4アドレスの購入に最も積極的であるように見える。NATシステムは、WAN側のパブリックアドレスの使用を制限する一方で、内部ネットワークでのプライベートアドレスの使用を可能にするため、パブリックIPv4アドレスの需要の少なくとも一部を吸収する手段を提供している。NATの場合、アーキテクチャ上と運用上の問題が残る。プライベート・アドレス空間は、特に大規模な組織にとっては適切なアドレススパンを提供できず、アドレスの再利用によりネットワークがより複雑になる可能性がある。さらに、2段階の変換に基づくキャリア・グレードNAT (CGN) [RFC6264]など、複数レベルのアドレス変換がネットワーク内に共存する可能性がある。本文書で後述するように、これには経済的および運用上の負担が伴う。

2.1.1. 一人当たりのIPv4アドレスとIPv6の状況

一人当たりのIPv4アドレスの比率は、ある国に割り当てられたIPv4アドレスの量をその国の人口で割ったものである。これは、世界におけるIPv4アドレスのアンバランスな分布を示すものである。これは明らかに、インターネットの初期に行われたアドレスの割り当てに由来する。

IPv4アドレスの一人当たりの比率を測定するための情報源は、RIRによる割り当てと世界人口に関する統計である。この点については、[POTAROO2]が配布ファイルを提供している。次の表は、ある国の1人あたりが利用できるIPv4アドレスの数(1人あたりの IPv4アドレス数)と、同じ国でのIPv6の相対的な普及率(対象国のIPv6対応ユーザの数で表す)を比較している。この表は、[POTAROO2]から入手可能なデータの本の一部を示している。特に、以下の表は、世界で最も人口の多い25か国のデータを示している。この表は、一人当たりのIPv4アドレスの比率に基づいて並べられており、データは2022年1月1日のものである。

国名	一人当たりのIPv4	IPv6の普及率
アメリカ合衆国	4.89	47.1%
イギリス	1.65	33.2%
日本	1.50	36.7%
ドイツ	1.48	53.0%
フランス	1.27	42.1%
イタリア	0.91	4.7%
南アフリカ	0.46	2.4%
ブラジル	0.41	38.7%
ロシア連邦	0.31	9.7%
中国	0.24	60.1%(*)
エジプト	0.24	4.3%
メキシコ	0.23	41.8%
トルコ	0.20	0.2%
ベトナム	0.17	48.0%
イラン (イスラム共和国)	0.15	0.1%
タイ	0.13	40.8%
インドネシア	0.07	5.0%
フィリピン	0.05	13.8%
インド	0.03	76.9%
パキスタン	0.03	2.1%
タンザニア連合共和国	0.02	0.0%
ナイジェリア	0.02	0.2%
バングラデシュ	0.01	0.3%
エチオピア	0.00	0.0%
コンゴ民主共和国	0.00	0.1%

表1 :世界の人口上位25か国の1人当たりのIPv4およびIPv6の導入状況 (2022年1月現在)

(*) 中国における IPv6 展開情報は[CN-IPv6]から得られる。

一人当たりのIPv4普及率の低さとIPv6の普及率の高さとの間に直接的な相関関係がすぐには明らかになるわけではないが、いくつかの兆候が現れている。例えば、ブラジル、中国、インドなどの一部の国では、明らかにIPv6の普及が進んでいる。後で説明するように、これにはIPv4アドレスの不足に加えて、地域の規制や市場主導の行動など、いくつかの要因に関係しているようだ。表の上位5か国は、IPv4アドレスの利用可能性が比較的高く、IPv6の普及も進んでいる。他のケースでは、表にリストされているいくつかの国では、IPv6の導入が依然として低いか、非常に低いため、IPv4アドレスが相対的に不足していることが、IPv6への明確な移行を意味しない場合もある。

2.2. IPv6ユーザ

IPv6ユーザ数は、IPv6の採用状況を即座に把握するための重要なパラメータである。組織によっては、複数のソースのデータを集計することで、IPv6の利用状況を継続的に追跡している。一例として、Internet Societyは、World IPv6 Launch Initiative [WIPv6L]に参加したネットワークのIPv6トラフィック量を常に監視している。この測定では、単一のネットワーク・レベルまでデータを提供する[Akm-stats]のような組織の統計を集約し、コンテンツ配信プラットフォームへのヒット数を測定している。本文書の範囲では、ユーザのデバイス上で実行されるスクリプト[CAIDA]によってIPv6の採用を定量化するためにAPNICが使用しているアプローチを考慮する。IPv6の相対的な成長の概算を示すために、次の表は、2022年1月1日時点のIPv6対応ユーザの推定総数を集計し、[POTAROO2]によって測定されたインターネット総ユーザと比較したものである。

	2018年1月	2019年1月	2020年1月	2021年1月	2022年1月	CAGR
IPv6	513.07	574.02	989.25	1,136.28	1,207.61	23.9%
世界	3,410.27	3,470.36	4,065.00	4,091.62	4,093.69	4.7%
比率	15.0%	16.5%	24.3%	27.8%	29.5%	18.4%

表2 : 2022年1月時点の総ユーザ数(百万単位)に対するIPv6対応ユーザ数

2つの数字が見える。1つ目は、IPv6インターネット人口が2桁の年平均成長率(CAGR)で増加していること、2つ目は、IPv6比率も着実に増加している。

2.3. IPv6ウェブコンテンツ

[W3Techs]は、さまざまな分析エンジンを通じて、世界中のウェブサイトのいくつかの技術要素の使用状況を追跡している。ウェブサイトにおけるIPv6の利用率は次の表の通りで、割合はIPv6経由でアクセス可能なウェブサイトを指す。

世界中のウェブサイト	2018年1月	2019年1月	2020年1月	2021年1月	2022年1月	CAGR
IPv6の%	11.4%	13.3%	15.0%	17.5%	20.6%	15.9%

表3: ウェブサイトにおけるIPv6の利用状況 (2022年1月現在)

成長率を見ると、それほど高いようには見えないかも知れない。しかし、すべてのウェブサイトが同じではないことに注意しなければならない。すでにIPv6をサポートしている最大手のコンテンツ・プロバイダは、小規模なウェブサイトよりもはるかに多くのコンテンツを生成している。2022年1月初めに、[Csc6lab]が計測したところ、世界の上位500サイトのうち203サイトがIPv6に対応していた(2021 年1月から2022年1月にかけて+3.6%)。大手コンテンツ・プロバイダ(Google、Facebook、Netflixなど)がモバイル・トラフィック全体の50%以上[SNDVN]、場合によってはさらに最大65% [ISOC1] [HxBld]を生成していることを考慮すると、IPv6経由でアクセス可能なコンテンツの割合は、IPv6対応ウェブサイトの数よりも明らかに重要である。モバイル・トラフィック全体の50%のうち、IPv6が占める割合を知ることは興味深い。残念ながら、この情報は入手できない。

これに関連して、時々生じる疑問は、突然IPv4がオフになったと仮定した場合、コンテンツ・プロバイダが保存しているコンテンツはすべてIPv6でアクセスできるのかどうかということである。たとえこれが純粋な推測であったとしても、上記の数字はそうなる可能性が高いことを示している。このことは、定量的に見れば、ほとんどのコンテンツはIPv6経由でアクセス可能であるという一般的な考えを補強するものである。

2.4. IPv6の公的活動とポリシー

先に述べたように、IPv6の世界的な展開は一様ではない[G_stats] [APNIC1]。場合によっては、規制や市場へのインセンティブを通じた地方自治体が講じた措置の結果として、特定の国でより高いIPv6導入が達成されていることは注目に値する。欧州連合(EU)地域に目を向けると、ベルギー、フランス、ドイツなどの一部の国は、IPv6の導入の面で大きく先行している。

ベルギーの場合、ベルギー郵便電気通信庁(BIPT)が仲介役となり、2012年にキャリア・グレードNAT(CGN)システムと、法的調査のためのパブリックIPv4アドレスの使用を制限することで、地元ISPと政府の間で合意した[BIPT]。この合意は、NATの背後にある16の顧客ごとに1つのIPv4アドレスの使用を制限した。最適化されていないNATの使用によって、ISPが被る経済的負担は、IPv6への移行と、ここ数年のIPv6採用の増加を誘発した。

フランスでは、国家規制当局(Autorite deregulatory des communication electrics: 略してArcep)が、フランス首都圏で5G周波数帯(3.4～3.8GHz)のライセンスを付与された携帯通信事業者にIPv6互換性を持たせる義務を導入した[ARCEP]。[ARCEP]に記載されている (フランス語から翻訳)。

その目的は、使用する機器の数が急増し続けており、RIPE NCCがIPv4アドレスを使い果たしたため、サービスの相互運用性を確保し、IPv6でしか利用できないサービスを利用する際の障害を取り除くことである。

IPv6の導入が遅れれば、新しいインターネット・サービスが広く普及するのを妨げたり、新規参入者にとって市場参入の障壁となったりする可能性がある。[ARCEP] (フランス語からの翻訳)によると、「IPv6は通信業界における競争を促進し、特定の垂直セクターのための国の産業化に役立つ。」

ドイツにおけるIPv6普及の促進は、産業界と公的機関の取り組みに依存していた。具体的には、連邦情報技術局(連邦内務省管轄)は、ドイツの行政機関におけるIPv6の利用について、数年にわたりいくつかの勧告を発行してきた。2019年の最新ガイドラインは、連邦行政機関のネットワークにおけるIPv6導入の義務化に向けたハイレベルなロードマップを構成している[GFA]。

米国では、行政管理予算局もIPv6の採用を呼びかけている[US-FR] [US-CIO]。これらの文書では、2025年までに米国連邦政府のIP対応ネットワークの80%をIPv6のみにする計画を定めている。中国は、国全体でのIPv6導入を支援している政府の一例である[CN]。インドでは、Reliance Jioが自社のネットワークでIPv6への移行を決定したことが、IPv6の高い普及率につながった[RelJio]。さらに、電気通信局(通信IT省傘下)は、公共およびプライベート・ネットワークにおけるIPv6の漸進的な採用に関するガイドラインを発行した。最新のものは2021年[IDT]で、IPv6接続サービスへのさらなる移行を促進している。

3. IPv6導入に関する調査

このセクションでは、サービスプロバイダと企業ネットワークにおけるIPv6の採用状況について説明する。

3.1. IPv6の割り当て

RIRは、IPv6アドレスブロックをISP、地域インターネット・レジストリ(LIR)、企業または他の組織に割り当てる役割を担っている。ISP/LIRは、割り当てられたブロックを使用して、エンドユーザにアドレスを割り当てる。以下の表は、2017年から2021年までの期間におけるRIRごとの個別割り当て量を示している[APNIC2]。

レジストリ	2017年12月	2018年12月	2019年12月	2020年12月	2021年12月	累計	CAGR
AFRINIC	112	110	115	109	136	582	51%
APNIC	1,369	1,474	1,484	1,498	1,392	7,217	52%
ARIN	684	659	605	644	671	3,263	48%
LACNIC	1,549	1,448	1,614	1,801	730	7,142	47%
RIPE NCC	2,051	2,620	3,104	1,403	2,542	11,720	55%
合計	5,765	6,311	6,922	5,455	5,471	29,924	51%

表4: 世界中のIPv6割り当て(2022年1月現在)

この傾向は、IPv6が着実な進歩していることを示している。2020年と2021年にIPv6の割り当てが減少するのは、新型コロナウイルス感染症のパンデミックによるものかも知れない。これはIPv4の割り当てでも同じことが起こった。

また、[APNIC2]は両アドレスファミリの割り当て数を比較している。2021年のCAGRはほぼ同様だが、IPv4の割り当て数がIPv6の割り当て数より若干多い(53.6%対50.9%)。

アドレスファミリー	2017年12月	2018年12月	2019年12月	2020年12月	2021年12月	累計	CAGR
IPv6	5,765	6,311	6,922	5,455	5,471	29,924	50.9%
IPv4	8,091	9,707	13,112	6,263	7,829	45,002	53.6%

表5: アドレスファミリごとの割り当て(2022年1月現在)

その理由は、2021年のIPv4割り当てに、小さなアドレス範囲(例えば、/24)の割り当てが多く含まれていたためと考えられる[APNIC2]。これに対し、IPv6で1つの割り当てで、オペレータの長期的なニーズに十分に対応できる大きさである。オペレータが IPv6の/30や/32の割り当てを受けた後、短期間に新たなアドレスの要求が繰り返される可能性はほとんどない。

次の表は[APNIC3]と[APNIC4]に基づき、世界中の全ASに対するIPv6に対応する自律システム(AS)の割合を示している。IPv6対応ASの数は、2018年1月の24.3%から2022年1月には38.7%に増加した。これは、IPv6対応ネットワークのCAGRの18%に相当する。これに対し、IPv6ネットワークとIPv4ネットワークの合計のCAGRはわずか5%である。

広告されたASN	2018年1月	2019年1月	2020年1月	2021年1月	2022年1月	CAGR
IPv6対応	14,500	16,470	18,650	21,400	28,140	18%
合計ASN	59,700	63,100	66,800	70,400	72,800	5%
比率	24.3%	26.1%	27.9%	30.4%	38.7%

表6: IPv6対応ASの割合 (2022年1月時点)

上の表は、割り当ての動的な状況を集計したものである。次のサブセクションでは、それぞれの特定のドメインにズームインし、その相対的な状況を明らかにする。

3.2. インターネット・サービス・プロバイダ間のIPv6

2020年の第3四半期に、ヨーロッパのサービス・プロバイダを対象に、IPv6に関する計画や、IPv6の採用に関する技術的嗜好を把握するための調査が実施された(完全なアンケートの全容については付録Aを参照)。このアンケートはIPv6の状況について網羅的な見解を提供するものではないが、議論に関連するいくつかの洞察を提供する。

調査では、インタビューに応じたISPの大多数(79%)がIPv6に関する計画を持っていることが明らかになった。このうち60%はすでに継続的な活動を行っており、33%は 12か月以内に活動を開始する予定であった。IPv6への移行は、モバイル(63%)、固定(63%)、エンタープライズ(50%)と、すべてのビジネス・セグメントに関わっていた。

IPv6に移行する理由はさまざまだった。グローバルIPv4アドレスの枯渇と、 [RFC1918]で推奨されているプライベート・アドレス空間の不足が、IPv6導入の重要な推進要因として報告された(48%)。いくつかのケースでは、回答者は国のIPv6ポリシーの要件と5Gの開始を理由に挙げている(13%)。企業顧客の需要もIPv6を導入する理由となった(13%)。

技術的嗜好の観点から見ると、デュアルスタック[RFC4213]が有線ネットワーク(59%)と携帯電話ネットワーク(39%)の両方で最も多く採用されているソリューションだった。有線では、Dual-Stack Lite (DS-Lite)[RFC6333] (19%)が2番目に多く採用されたメカニズムだった。携帯電話ネットワークでは、464XLAT [RFC6877] (21%)が2番目に好まれた。

回答の詳細は付録Aを参照のこと。

3.3. 企業におけるIPv6

[RFC7381]に記載されているように、企業はISPとは異なる課題に直面している。公開されているレポート[cmpwr]によると、企業におけるIPv6の導入は、ISP導入に比べて遅れている。

[NST_1]は、米国のexample.com、example.net、example.orgのようなドメインに対するIPv6の導入状況の推計を提供している。この測定は、電気通信を含む多くの業界を包含しているため、「企業」という用語はこの文脈では少し緩い。いずれにせよ、米国のいくつかの産業分野でのIPv6普及の最初の指標となる。この分析では、企業ネットワークの「外側」から見て、IPv6がサポートされているかどうかを推測しようとするものである。ドメイン・ネーム・システム(DNS)、メール、ウェブサイトなどの外部サービスに対するIPv6のサポートを考慮している。[BGR_1]は中国に関する同様のデータがあり、[CNLABS_1]はインドの状況を提供している。

国	分析されたドメイン	DNS	メール	ウェブサイト
中国	478	74.7%	0.0%	19.7%
インド	104	51.9%	15.4%	16.3%
アメリカ合衆国	1070	66.8%	21.2%	6.3%

表7: 企業における外部向けサービスのIPv6サポート(2022年1月現在)

2021年初めに北米の大企業グループに提出されたアンケート調査(付録B参照)によると、運用上の問題はISPよりもさらに深刻であることが示されている。

現在の実装状況を見ると、ほぼ3分の1がデュアルスタック・ネットワークを使用しており、20%はネットワークの一部がIPv6-onlyであることを明らかにしている。さらに、企業の35%はIPv6をまったく実装していないか、トレーニング段階にとどまっている。ネットワークが完全にIPv6に基づいているケースはない。

トレーニングについて言えば、最も重要なニーズはIPv6セキュリティとIPv6トラブルシューティング(どちらも回答者の3分の2が強調)であり、アドレス計画/ネットワーク構成(57.41%)がそれに続く。

実装に関しては、IPv6セキュリティ(31.48%)、トレーニング(27.78%)、アプリケーション変換(25.93%)の3分野が懸念事項であり、回答者の33.33%は、3分野すべてが同時に懸念事項であると考えている。

完全なアンケート調査は付録Bに報告されている。

3.3.1. 政府と大学

このセクションでは、特に政府機関と学術機関におけるIPv6の採用に焦点を当てる。

政府機関に関する限り、[NST_2]は、米国連邦政府機関に関連するセカンド・レベル・ドメインのDNS、メール、ウェブサイトのIPv6サポートの度合いに関する分析を提供している。これらのドメインは、example.govまたはexample.fedの形式である。[NST_2]で使用されたスクリプトは、中国[BGR_2]、インド[CNLABS_2]、欧州連合[IPv6Forum]など、他の国でも同じ分析を測定するために採用されている。この後者の分析では、欧州連合以外のドメインを除外するための後処理が必要である。

国	分析されたドメイン	DNS	メール	ウェブサイト
中国	52	0.0%	0.0%	98.1%
欧州連合(*)	19	47.4%	0.0%	21.1%
インド	618	7.6%	6.5%	7.1%
アメリカ合衆国	1283	87.1%	14.0%	51.7%

表8: 政府機関における外部向けサービスのIPv6サポート (2022年1月現在)

(*) EUドメインと国固有のドメインの両方を考慮

米国のIPv6サポートは他国よりも高い。これは、[US-CIO]がIPv6を義務付けたためと考えられるる。インドの場合、サポートの程度はまだかなり低いようだ。これは中国にも当てはまるが、政府関連組織のIPv6対応ウェブサイトの割合が高いという特筆すべき例外がある。

高等教育機関についても同様の統計がある。[NST_3]は、example.eduのような米国の大学のセカンド・レベル・ドメインのデータを測定している。[BGR_3]は、中国語の教育関連ドメインを見ている。[CNLABS_1]はインドのドメイン(ほとんどが第3レベル)を分析している。一方、[IPv6Forum]は、欧州連合以外のドメインをフィルタリングした後、欧州連合の大学(セカンドレベル)をリストアップしている。

国	分析されたドメイン	DNS	メール	ウェブサイト
中国	111	36.9%	0.0%	77.5%
欧州連合	118	83.9%	43.2%	35.6%
インド	100	31.0%	54.0%	5.0%
アメリカ合衆国	346	49.1%	19.4%	21.7%

表9: 大学における外部向けサービスのIPv6サポート(2022年1月現在)

全体として、大学は他の分野と比べて、IPv6ベースのサービスを幅広くサポートしている。いくつかの例外(中国でのIPv6メールのサポートやインドのIPv6ウェブサイトなど)を除けば、上の表に示されている数字は、学術界におけるIPv6のサポートが良好であることを示している。

4. IPv6 導入シナリオ

本セクションのスコープは、IPv6への移行に適用可能なネットワークとサービスのシナリオについて説明することである。関連する定義の大部分はセクション1.1で提供されている。本セクションでは、技術的および運用上の特徴に焦点を当てることを目的としている。ここで説明する一連のシナリオは、必ずしもIPv6移行のロードマップとして意図する必要はない。サービスプロバイダの具体的な計画や要件に応じて、提案されたシナリオを順番に採用することも、特定のシナリオに直接ジャンプすることもできる。

4.1. デュアルスタック

ネットワーク・オペレータから提供されたアンケート回答(付録A)によると、デュアルスタック[RFC4213]が現在最も広く導入されているIPv6ソリューションと思われる(約50%、付録Aと[ETSI-IP6-WhitePaper]で報告されている統計の両方を参照)。

デュアルスタックでは、他のネットワーク・アップグレードと一緒にIPv6を導入することができ、ネットワーク管理やITシステムの多くの部分は引き続きIPv4で動作する。これにより、IPv6移行において最も困難と思われる、IPv6をサポートするためのシステムの大幅なアップグレードを回避することができる。ネットワーク管理とITシステムのアップグレードにかかるコストと労力は中程度である。メリットとしては、IPv6の利用開始とNATコストの削減が挙げられる。

デュアルスタックは導入段階ではメリットがあるが、長期的にはネットワーク・リソースや状態の重複など、いくつかのデメリットがある。また、より多くのIPv4アドレスが必要になるため、資本的支出(CAPEX)と運用経費 (OPEX)の両方が増加する。例えば、プライベート・アドレスがキャリア・グレードNAT(CGN)で使用されている場合でも、CGNデバイス、ログストレージ、CGN関連の問題を追跡するためのヘルプデスクに追加の投資が必要となる。

このため、IPv6の使用量がある閾値を超えた場合、次のシナリオへの移行を開始することが有利になる場合がある。例えば、以下に説明するように、IPv4aaSの段階からプロセスを開始することができる。切り替えの基準(例えば、IPv4の減少の上限やIPv6の増加の下限を適切に特定すること)を確立することは困難である。技術的な要因に加えて、次のシナリオへの切り替えによって、顧客に損失を与える可能性もある。2021年6月のWorld IPv6 Launch[WIPv6L]に参加したネットワーク・オペレータのフィードバックによると、346事業者のうち108事業者がIPv6トラフィック量の50%を超え(31.2%)、72事業者が60%を超え(20.8%)、37事業者が75%を超えている(10.7%)。IPv6トラフィック量が50%から60%の間であれば、IPv6-onlyに移行するというコンセンサスは妥当かも知れない。

4.2. IPv6-Onlyオーバーレイ

セクション1.1で定義されているように、IPv6-onlyは一般的に、IPv6-onlyオーバーレイやIPv6-onlyアンダーレイなどのスコープと関連付けられる。

IPv6-onlyオーバーレイは、ネットワークのエンドポイント間のオーバーレイ・トンネルがIPv6のみに基づいていることを示す。トンネルは、既存のIPv4インフラを使用してIPv6トラフィックを伝送する方法を提供する。IPv6またはIPv4のホストとルータは、IPv6パケットをIPv4パケット内にカプセル化することで、IPv4領域上にトンネルすることができる。IPv6-onlyオーバーレイによるアプローチは、既存のIPv4ベースとの互換性を維持するのに役立つが、長期的な解決策ではない。

実際のところ、IPv6-onlyホストに対してIPv6経由でのIPv4到達可能性は、今後長期間にわたって提供しなければならない。ほとんどのISPは、IPv6-onlyソリューションではなく、IPv4の寿命を延ばすためにCGNを活用している。

4.3. IPv6-Onlyアンダーレイ

IPv6-onlyアンダーレイ・ネットワークは、すべてのトラフィック配信にIPv6をネットワーク・プロトコルとして使用する。コントロール・プレーンとデータ・プレーンは両方ともIPv6に基づいている。IPv6-onlyアンダーレイの定義は、IPv6-onlyアクセス・ネットワークやIPv6-onlyバックボーン・ネットワークなど、適用可能なドメインを識別するためのスコープと関連付ける必要がある。

企業もサービス・プロバイダも、IPv4/MPLSバックボーンからアンダーレイにIPv6を導入する移行を始める場合、必ずしもアンダーレイをデュアルスタックにする必要はない。ISPコアのプロバイダ(P)ノード上のフォワーディング・プレーンの複雑さは、単一プロトコルのバックボーンとしてシンプルに保たれるべきである。したがって、オペレータがIPv6アンダーレイへの移行を決定した場合、デュアルスタックは最良の選択ではなく、ISPバックボーンはIPv6-onlyにすべきである。IPv6ネクストホップでIPv4 Network Layer Reachability Information (NLRI)を広告するために必要な拡張機能を規定する[RFC8950]を活用し、アンダーレイをIPv6-onlyにして、IPv6-onlyバックボーン上でVPNを使用して、IPv4パケットをトンネルすることができる。

アクセス・ネットワークやバックボーン・ネットワークへのIPv6-onlyアンダーレイ・ネットワークの展開は、最初の選択肢ではないようで、現在の傾向は、IPv4/MPLSデータ・プレーンを維持し、エッジノードにIPv4/IPv6デュアルスタックを実行することである。

ISPが将来的に、IPv6-onlyアクセス・ネットワークやバックボーン・ネットワークに移行する際、例えば、Segment Routing over IPv6 (SRv6)データプレーンは、IPv4サービスを提供し続けながら、アンダーレイ・トランスポート・ネットワークからIPv4の排除を始めることができる。基本的に、ネットワーク・オペレータ間のアンケート調査でも示されているように、ネットワーク・アーキテクチャの観点からは、フォワーディング・プレーンの複雑さに関連する上記の理由により、トランスポート・ネットワークにデュアルスタックを適用することは推奨されない。

4.4. IPv4-as-a-Service

IPv4aaSは、IPv4サポートを確保するために使用することができ、経済的側面、政策、政府の規制など、いくつかの要因に依存する複雑な決定となる可能性がある。

[RFC9313]は、IPv4aaSの最も一般的な移行ソリューション、すなわち464XLAT[RFC6877]、 DS-Lite[RFC6333]、Lightweight 4over6 (lw4o6)[RFC7596]、Mapping of Address and Port with Encapsulation (MAP-E)[RFC7597]、Mapping of Address and Port using Translation (MAP-T)[RFC7599]の利点を比較しているが、明確な推奨は出していない。しかし、付録Aのアンケート調査では、モバイル・ブロードバンド (MBB)ドメインで最も広く導入されているIPv6移行ソリューションは464XLATであるのに対し、固定ブロードバンド(FBB)ドメインではDS-Liteであることが示されている。

どちらも、IPv4aaSソリューションで、IPv6-onlyアンダーレイを活用している。IPv4aaSはユーザにデュアルスタック・サービスを提供し、ISPがネットワーク(通常はアクセス・ネットワーク)内でIPv6-onlyを実行できるようにしている。

常にそうであるとは限らないが、464XLATのようなIPv6-only移行技術は、より効率的で、加入者あたりのポート数を制限しないため、必要なIPv4アドレスははるかに少なくなる[RFC9313]。これにより、トラブルシューティングのコストが削減され、一部のサービスでCGNを経由して使用される場合のIPv4アドレスブロックの恒久的なブロックリストに関連する運用上の問題が解消する。

IPv4aaSは、新しい技術(トリプルプレイ、高帯域幅のWANリンク、より優れたWi-Fi技術など)によるCPEの自然なアップグレードや交換によって促進される可能性がある。ネットワークの運用が簡素化されるため、ネットワークの他の部分(CGNや関連ログなど)のCAPEXとOPEXが削減される可能性がある。

多数のユーザ(大規模なモバイル・オペレータなど)や多数のホスト(大規模なデータセンター(DC)など)を抱える展開では、完全なプライベート・アドレス空間[RFC1918]でも十分ではない。また、デュアルスタックは、IPv6とIPv4の両方をサポートするためにネットワークリソースと運用の重複を招く可能性が高く、ネットワーク内の状態情報の量が増加する。このことは、MBBや大規模DCのようなシナリオでは、IPv6導入当初からIPv4aaSの方が効率的である可能性を示唆している。

したがって、一般的にデュアルスタックのデメリットがIPv6-onlyの複雑さを上回る場合、IPv4aaSに移行することは理にかなっている。[TMus]、[RelJio]、[EE]のように、すでにこのプロセスを開始しているネットワーク・オペレータもある。

4.5. IPv6-Only

IPv6-onlyは、IPv6移行の最終段階であり、ネットワーク全体がエンドツーエンドで IPv4を使用しなくなったときに起こる。ネットワーク管理などにはIPv4アドレスは設定されない。

IPv6-onlyとは、アンダーレイ・ネットワークとオーバーレイ・サービスの両方がIPv6-onlyであることを意味するため、実現にはさらに時間がかかる。

5. 一般的なIPv6の課題

このセクションでは、いくつかの会議や公開イベントで検証され、議論されてきたIPv6の共通課題を列挙する。スコープはさらなる調査を促すことが目的である。IPv6はすでに実運用環境で十分に実証されているが、考慮すべき課題がいくつかある。この点に関して、[ETSI-GR-IPE-001]では、IPv6関連のユースケースに依然として存在するギャップについても議論していることは注目に値する。

5.1. 移行の選択肢

サービスプロバイダ、企業、またはCSPは、利用可能な多くの技術的代替手段と、管理と運用に必要な変更により、IPv6への移行が非常に複雑なタスクだと認識するかもしれない。さらに、移行をサポートする方法の選択は重要な課題であり、サービス要件に適合するIPv6ネットワーク設計、ネットワーク運用、展開戦略など、状況に特有の要因に左右される可能性がある。

以下のサブセクションでは、さまざまな関係者が取り得るアプローチと関連する課題を簡単に説明する。

5.1.1. サービスプロバイダ:固定通信オペレータとモバイル通信オペレータ

固定通信オペレータの場合、デュアルスタックをサポートするためのCPEの大規模なソフトウェア・アップグレードが、ほとんどのサービスプロバイダ・ネットワークですでに始まっている。世界的な統計を平均してみると、IPv6トラフィックの割合は現在約40%である[G_stats]。セクション3.2で強調したように、すべての主要なコンテンツ・プロバイダはすでに自社のサービスにデュアルスタック・アクセスを実装しており、そのほとんどがデータセンターでIPv6-onlyを実装している。この側面は、オペレータのIPv6採用の決定に影響を与える可能性はあるが、現在のIPv4アドレス不足、CPEコスト、CGNコストなど、他の要因もある。

• デュアルスタック・アーキテクチャの固定通信オペレータは、利用可能なIPv4アドレス数が限界に達した時点で、新たな戦略の定義と適用を開始することができる。これは、CGNまたはIPv4aaSのアプローチによって行われる。
• 固定通信オペレータのほとんどはデュアルスタック・アーキテクチャに固執しており、その多くはすでにCGNを採用している。この場合、CGNは今後数年間にわたって、CPEにIPv4接続を供給する能力を高める可能性が高い。実際、IPv6-onlyシナリオへの移行を選択した固定通信オペレータはわずかである。

モバイル通信オペレータの場合、状況がまったく異なり、モバイル通信オペレータはすでにIPv4アドレス空間を拡張しているケースもある。その理由は、CGN変換の限界に達し、これ以上IPv4パブリック・プール・アドレスを利用できないためである。

• モバイル通信オペレータの中には、デュアルスタックの実装を第一の即効性のある軽減策として選択するところもある。
• 他のモバイル通信オペレータは、デュアルスタックはIPv4アドレス不足の問題を軽減するだけで完全には解決しないため、IPv4aaSソリューション(例: 464XLAT)に移行することを好む。

固定通信オペレータとモバイル通信オペレータ共に、移行のアプローチは一様ではなく、ネットワーク・アーキテクチャと関連コストに関してさまざまな課題が生じる。したがって、各オペレータは特定の状況に基づき、移行のための独自の評価を行う必要がある。

5.1.2. 企業

現在、企業におけるIPv6の利用は、アップストリーム・サービス・プロバイダに依存することが多く、企業の接続性はアップストリーム・プロバイダが提供するサービスに依存している。また、企業の内部インフラについては、IPv4プライベート・アドレスの場合によくある2つのアドレス空間の重複を回避することができるため、M&Aの場合にIPv6が優位性を発揮する。さらに、いくつかの政府がIPv6政策を導入しているため、政府向けにコンサルティング・サービスを提供する企業もIPv6のサポートが求められている。

しかし、企業はいくつかの課題に直面している。プロキシやプライベート・アドレス指定[RFC1918]が広く利用されているため、IPv4アドレスの枯渇問題から守られており、IPv6に移行するためのビジネス要件や技術的な正当性がない。企業は、追加のCAPEXとOPEXを正当化するために、IPv6に移行する投資対効果(business case)と強い動機を見つける必要がある。また、ほとんどの企業にとって情報通信技術(ICT)は中核事業ではないため、ICT予算は制約されることが多く、大幅に拡大することはできない。しかし、より効率的なIPv6ネットワークを通じてビジネス目標を達成し、IPv6 ネットワーク・アーキテクチャを必要とする新しいサービスを導入するために、IPv6を検討している大企業の例もある。

世界中の企業、特に中小企業は、特に内部ネットワークでのIPv6の導入が非常に遅れている。ほとんどの場合、企業のエンジニアや技術者はIPv6の経験があまりなく、アプリケーションのIPv6への移植の問題はかなり難しいように見える。関連するアンケート調査で強調されているように、技術者はトレーニングを受ける必要があるかもしれないが、経営陣は導入のビジネスニーズを見出していない。これは、IPv6プロトコルの複雑さ、セキュリティや管理のしやすさへの懸念が、緊急のビジネスニーズの欠如と組み合わさり、IPv6の採用を妨げるという不幸なサイクルを生み出している。2019年と2020年に、ARINとAPNICのいくつかのイニシアチブが、トレーニングを提供するための協調的な取り組みが行われた[ARIN-CG] [ISIF-ASIA-G]。

5.1.3. 産業用インターネット

産業環境では、運用技術(OT)は工場や生産環境内のプロセスを監視・制御するために使用されるシステムを指し、情報技術(IT)はコンピュータ技術やネットワーク接続に関連するものを指す。IPv6は、インダストリー4.0とモノのインターネット(IoT)に関連して頻繁に言及され、OTとITの両方の進化に影響を与えている。

産業用モノのインターネット(IIoT)にIPv6を使用することには、特に大きなIPv6アドレス空間、IPv6アドレスの自動構成、リソース発見などの潜在的な利点がある。しかし、産業界、特にスマート製造システムでのIPv6導入は、予想よりもはるかに遅れている。IPv6の普及を妨げる障害や課題が残っている。認識されている主な問題は、ツールのサポートが不完全または未開発であること、手動設定への依存、IPv6プロトコルに関する知識が乏しいことである。スマート製造システムやIIoTアプリケーションへのIPv6の利用を促進するには、これらのペインポイントを取り除くための一般的なアプローチが非常に望まれる。実際、企業にとっては、システム・アーキテクトやソフトウェア開発者にIPv6プロトコルに慣れるための簡単な方法を提供することが重要である。

クラウドベースのプラットフォームの進歩、人工知能(AI)、機械学習(ML)の発展により、OTとITシステムが統合され、一元化された分析、処理、統合プラットフォームに移行できるようになり、リアルタイムで作動しなければならない。その限界とは、製造業には多様な企業文化があり、その結果、新技術の導入が遅れる可能性があることだ。

産業用インターネットや関連するIIoTアプリケーションでは、IPv6の設定不要の特性を活用して、IoTデバイスを自動的に管理・制御することが望ましいと考えられる。さらに、 IPベースの通信と標準アプリケーション・プロトコルを生産プロセスの各ポイントで使用できるようにし、特殊な通信システムの使用をさらに削減できることも興味深い。

5.1.4. コンテンツとクラウド・サービス・プロバイダ

データセンター内の仮想要素と物理要素を接続するために必要なアドレスの多さと、[RFC1918]によってもたらされる制限を克服する必要性が、いくつかのCSPネットワークでIPv6を採用する原動力となっている。

ほとんどのCSPは内部インフラにIPv6を採用しているが、IPv4接続の現在のビジネスニーズに応えるため、譲渡市場でIPv4 アドレスを集めることにも積極的に取り組んでいる。前セクションで述べたように、ほとんどの企業はIPv6への移行を優先事項とは考えていない。この点で、CSPによるIPv4ベースのネットワーク・サービスの利用は続くだろう。

以下に報告するように、いくつかの公開文献では、大手企業のほとんどがデータセンター(DC)インフラでのIPv6-onlyへの移行において、さまざまな段階にあることを説明している。場合によっては、すでに移行が完了し、これらのハイパースケーラーのDCインフラは完全にIPv6に基づいている。

ネットワーク内のトラフィックがどれだけキャッシュやコンテンツ配信ネットワーク(CDN)に流れているかを調べるのは興味深いことである。主要なキャッシュやCDNは、すべてIPv6に対応しているため、その割合は高く、ほとんどの場合、少なくとも50%を超えると予想される[Cldflr] [Ggl] [Ntflx] [Amzn] [Mcrsft]。したがって、主要なキャッシュ/CDNに流れるトラフィックの割合は、ネットワーク内の潜在的なIPv6トラフィックの近似値である。

ほとんどのCSPはすでにIPv6-onlyへの移行を完了しているため、CSPにとっての課題は主に、IPv4の継続的なサポートを保証することに関連している。今後数年でIPv4アドレスの不足が顕著になれば、CSPはIPv4アドレスの購入コストを顧客に転嫁する可能性がある。

5.1.5. CPEとユーザ機器

ほとんどのユーザ機器(例えば、スマートフォン)は長年にわたってIPv6に対応してきた。しかし、例外もある。例えば、ここ数年、スマートTVは一般的にIPv6をサポートしてきた。ただし、すべての国が同じペースで置き換えらているわけではない。

すでに述べたように、これまでパブリックIPv4アドレスを顧客に提供してきたISPは、一般的にまだそれらのIPv4アドレスを保持している(譲渡することを選択しない限り)。一部のISPは、新規顧客をCGNに登録することを選択したが、既存の顧客には手をつけなかった。IPv4がNAT444経由(つまり、キャリアにとって好ましいCGNソリューション)で行われていることに気づく顧客は極めて少ないため、IPv4アドレスとプライベートIPv4空間が不足する可能性は低いかもしれない。しかし、IPv4-onlyのデバイスとトラフィックが減少すれば、プライベートIPv4とパブリックIPv4をサポートする必要性は減少する。そのため、CPEにIPv6を完全にサポートすることは重要な課題であり、デュアルスタックよりもIPv4aaSソリューション[ANSI]を選択するインセンティブとなる。

5.1.6. ソフトウェア・アプリケーション

IPv6への移行には、アプリケーション・ソフトウェアがIPv6ベースのネットワークで使用できるように適合させる必要がある([ARIN-SW]が例を示している)。IPv4-onlyアプリケーションがIPv6に進化する間、464XLATのような移行メカニズムの使用が不可欠である。採用する移行メカニズムによっては、いくつかの問題が残る可能性がある。例えば、NAT64/DNS64の場合、アプリケーション・レベル・ゲートウェイ(ALG)のようなメカニズムを使用しない限り、DNS名の代わりにリテラルIPv4アドレスを使用すると失敗する。この問題は464XLATには存在しない([RFC8683]を参照)。

アプリケーションのIPv6への移行に関連する側面として、 Happy Eyeballs [RFC8305]について言及する価値がある。

5.2. ネットワークの管理と運用

運用、管理、保守(OAM)に関連するIPv6補完ソリューションには、IPv4に比べて成熟度が低いように見えるる重要なものがある。ネットワーク管理システム(NMS)は、ネットワーク・オペレータと企業の両者にとって、今のネットワークで中心的な役割をになっており、その移行は基本的な問題である。これは、従来のプロトコル(SNMPやRADIUSなど)がすでにIPv6をサポートしていたとしても、一部のIPv6製品はIPv4製品ほど現場で実証されていないためである。さらに、新しいNMS機能の開発に関するベンダーのロードマップに互換性のないことは、ネットワーク・オペレータや企業の信頼に影響を与える。

重要な要素は、ネットワーク運用要員のトレーニングの必要性に代表される。IPv6を導入するには、IPv6への移行を首尾よく計画して完了させるために、ポリシーや手順を整備する必要がある。スタッフは、IPv4とIPv6の資産を管理するためのベストプラクティスを認識しなければならない。ネットワークノードに加えて、ネットワーク管理アプリケーションや機器も適切に設定し、場合によっては交換する必要もある。これにより、移行にさらに複雑さとコストがかかる可能性がある。

IPv6アドレス指定のような分野では、システムとトレーニングの両方が利用可能であることが必要である。IPv6アドレスは、ステートレス自動構成(SLAAC)[RFC4862]やステートフル動的ホスト構成プロトコル(DHCP)[RFC8415]など、さまざまな手段でインタフェースに割り当てることができる。IPアドレス管理(IPAM)システムは、アドレス割り当てやDHCPサービスの管理など、技術的な違いに処理を、構成タスクの一部を自動化することで貢献するかもしれない。

5.3. パフォーマンス

人は、IPv6への移行を主張したり動機付けたりするために、IPv6とIPv4のパフォーマンスを比較しがちである。場合によっては、IPv6の動作がIPv4よりも「悪い」(worse)ことが、IPv6の全面的採用を避ける論拠として使われることもある。しかし、IPv6がすでにIPv4とのギャップを埋めている(または埋めつつある)側面もある。この状況は、パケット損失と遅延という2つの重要なパラメータに関する利用可能な分析を見ると裏付けられる。これらのパラメータは長期にわたって継続的に監視されてきたが、最新の情報を提供する包括的な測定活動はほんのわずかである。パフォーマンスは考慮すべき重要な問題であり、さらに調査する価値があることは間違いないが、実際には、どのIPバージョンがより優れたパフォーマンスを発揮するかについて、決定的な答えは見つかっていない。特定のユースケースやアプリケーションによっては、IPv6の方が優れている場合もあれば、IPv4の方が優れている場合もある。

5.3.1. IPv6 パケット損失と遅延

[APNIC5]は、IPv4と比較したIPv6の失敗率とラウンドトリップ時間(RTT)の両方の測定値を提供している。どちらの測定値も、TCPの3ウェイ・ハンドシェイクを使用するスクリプトに基づいている。そのため、失敗率の測定は、パケット損失の直接的な測定にはならない(インターネット全体の測定活動が必要になる)。とはいえ、IPv4のパフォーマンスの方が依然として高いにもかかわらず、その差は近年縮まっているようだ。[RIPE1]と[APRICOT]という2つのレポートでは、関連する傾向について論じており、IPv6の世界平均失敗率がIPv4よりもまだ若干悪いことが示されている。この影響の理由は、到達不能なIPv6アドレスを持つエンドポイント、ルーティングの不安定性、またはファイアウォールの動作にあるかもしれない。しかし、このような悪化は、IPv6へのシンプルな移行を妨げるものとして現れるかもしれない。

[APNIC5]も両アドレスファミリーのレイテンシも比較している。今のところ、世界平均ではIPv6がわずかに有利である。国やオペレータ・レベルにまでズームすると、より詳細な情報を得ることができ、IPv6がIPv4よりも高速なケースが存在することが分かる。IPv6の導入が進んでいる(例: 45%以上)地域(西ヨーロッパ、北アメリカ、南アジアなど)および国(米国、インド、ドイツなど)では、IPv6がIPv4よりも優れたパフォーマンスを示している。[APRICOT]は、パフォーマンスに差がある場合、それが非対称ルーティングの問題に関連していることが多いことを強調している。相対的なレイテンシの差に関する他の説明は、パケットのフラグメンテーションを可能にするIPv6ヘッダの特異性に関連している。これは、ハードウェアがすべてのヘッダ・セクションを分析するためにサイクルを費やす必要があり、そのうちの1つを処理できない場合、パケットをドロップする。CDNにおけるIPv6の動作に関するいくつかの測定活動も利用できる[MAPRG] [INFOCOM]。分析時間枠全体でギャップが縮まったとしても、TCP接続時間はどちらの場合もIPv6の方が長くなっている。

5.3.2. カスタマ・エクスペリエンス

IPv4の代わりにIPv6を使用した場合に、カスタマ・エクスペリエンスが何らかの形で向上すると認識されるかどうかは、完全には明らかではない。場合によっては、IPv6コンテンツ・プロバイダから、IPv4と比較して、IPv6-onlyを使用した方がユーザのエクスペリエンスが良いということが公に報告されている[ISOC2]。これは、IPv6ユーザがIPv6-onlyデータセンターでホストされているアプリケーションに接続する場合、接続はエンドツーエンドであり、変換は行われないためだと考えられる。その代わり、IPv4を使用する場合、IPv4からIPv6への(そしてIPv4に戻る)変換に加え、IPv6-onlyコンテンツ・プロバイダのデータセンターにおいて、CPEまたはサービス・プロバイダのネットワークのいずれかでNAT変換が行われる。[ISOC2]と[FB]は、IPv6を支持する理由を示している。他のケースでは、IPv4とIPv6の差が時間の経過とともに消えていく傾向があるにせよ、結果は依然として、IPv4[INFOCOM] [MAPRG]にわずかに有利な結果となっているようだ。

5.4. IPv6のセキュリティとプライバシー

IPv6への移行を議論する際に課題として考慮されることがある重要な点は、セキュリティとプライバシーに関するものである。[RFC9099]では、ネットワークのいくつかの場所(企業、サービス・プロバイダ、家庭のユーザ)における運用上のセキュリティ問題を分析している。また、IPv4aaSの実装に使用されるIPv6移行技術(例: 464XLATやDS-Lite)[ComputSecur]の応用がもたらす、追加のセキュリティ上の問題も考慮する価値がある。

少なくとも現在のIPv4ネットワーク環境と同じ、またはそれ以上のセキュリティ・レベルを維持するために、セキュリティ面も考慮しなければならない。IPv6の自動設定機能には、さらに注意が必要である。ルータ発見とアドレスの自動設定は、予期せぬ結果やセキュリティホールを生む可能性がある。IPsecは少なくともIPv4と同様にIPv6トラフィックを保護し、制約のあるデバイス(IoT)用のセキュリティ・プロトコルはIPv6運用向けに設計されている。

IPv6は、グローバルに一意のアドレスを使用するネットワーク上のすべてのノードと通信するエンドツーエンド・モデルを復元するために設計された。しかし、そう考えると、IPv6はインターネット上での可視性が高まるため、プライバシー上の懸念を意味するかもしれない。IPv6ノードは、プライバシー拡張機能[RFC8981]を使用して、焼き付けられたメディア・アクセス・コントロール(MAC)アドレスの追跡を防ぐことができる(そして通常は使用する)。このアドレスは、元の修正された64ビット拡張固有識別子(EUI-64)インタフェース識別子の形式で簡単に読み取ることができる。一方、安定したIPv6インタフェース識別子[RFC8064]は開発されたが、これもプライバシーに影響を与える可能性がある。

[ISOC3]で報告されているように、プロトコルレベルでIPv6とIPv4を比較すると、おそらくIPv6が複雑化した結果、攻撃ベクトルの数が増加し、さまざまなタイプの攻撃を実行される可能性が高まったと結論付けることができるだろう。しかし、より興味深く実用的な問題は、IPv6の導入がIPv4の導入とセキュリティ面でどのように比較されるかということである。その意味で、考慮すべき点はたくさんある。

ネットワーク・プロトコルに関連するセキュリティの脆弱性のほとんどは、実装上の欠陥に基づいている。通常、セキュリティ研究者はプロトコルの実装に脆弱性を発見し、最終的にはその脆弱性を軽減するために「パッチ」を適用する。時間が経つにつれ、この脆弱性の発見とパッチ適用のプロセスにより、堅牢な実装が実現する。明らかな理由として、IPv4プロトコルはセキュリティ研究者の研究結果からずっと長い間恩恵を受けてきたため、IPv4の実装は一般的にIPv6よりも堅牢である。しかし、IPv6の導入が進めば、長期的にはIPv6もこのプロセスの恩恵を受けることになる。また、今日の脆弱性のほとんどは人為的なものであり、IP層ではなくアプリケーション層にあることも言及する価値がある。

プロトコルの本質的な特性に加えて、結果として生じる導入のセキュリティ・レベルは、ネットワークとセキュリティ・エンジニアの専門知識のレベルと密接に関連している。その意味で、IPv4ネットワークの導入と運用の方が、IPv6ネットワークの導入と運用よりも、はるかに多くの経験と信頼があることは明らかである。

5.4.1. プロトコルのセキュリティ問題

一般的に、IPv6に関連するセキュリティ上の懸念は以下のように分類できる:

• 基本IPv6プロトコル(基本ヘッダ、拡張ヘッダ、アドレス指定)
• IPv6関連プロトコル (ICMPv6、NDP、MLD、DNS、DHCPv6)
• インターネット全体のIPv6セキュリティ (フィルタリング、DDoS、移行メカニズム)

ICMPv6はIPv6に不可欠な要素であり、エラー報告と診断機能を実行する。近隣探索プロトコル(NDP)は、IPv6のノード探索プロトコルで、ARPの機能を置き換え、拡張している。マルチキャスト・リスナー検出(MLD)は、IPv6ルータが直接接続されたリンク上のマルチキャスト・リスナーを発見するために使用され、IPv4でインターネット・グループ管理プロトコル(IGMP)が使用されるのとよく似ている。

ICMPv6、NDP、MLDなどのIPv6関連プロトコルは、IPv4と比べて新しいものであるため、新たなセキュリティ脅威が追加され、関連するソリューションは現在も議論されている。NDPには脆弱性がある[RFC3756] [RFC6583]。[RFC3756]はIPsecを使用するよう記載されているが、現実的ではないため使用されていない。一方、SEcure Neighbor Discovery (SEND)[RFC3971]は広く利用されていない。[ND-CONSIDERATIONS]で説明しているように、ホストの分離を適用することで、これらの問題の多くを解決できる可能性があることは言及しておく価値がある。

[RIPE2]は、IPv6セキュリティに関する最も重要な脅威とソリューションを説明している。

5.4.1.1. IPv6拡張ヘッダとフラグメンテーション

IPv6拡張ヘッダは、興味深い新機能を追加するためのフックを提供し、IPv4オプションよりも柔軟性がある。そのため、若干の複雑さが加わる。特に、セキュリティ・メカニズムの中に、ヘッダの全チェーンを処理する必要なものがあるだろうし、ファイアウォールによっては拡張ヘッダに基づいてパケットをフィルタリングする必要があるかもしれない。さらに、IPv6拡張ヘッダを持つパケットは、パブリック・インターネット[RFC7872]でドロップされる可能性がある。[HBH-PROCESSING]、[HBH-OPT-HDR]、[IPv6-EXT-HDR]などの文書が、IPv6拡張ヘッダの処理手順を分析し、ガイダンスを提供している。

拡張ヘッダを使った攻撃の可能性に対する防御が必要である。例えば、オリジナルのIPv6ルーティング・ヘッダ・タイプ0(RH0)は、リモートのトラフィックが増幅される可能性があるため非推奨となった[RFC5095]。さらに、認識されないホップバイホップ・オプション・ヘッダと宛先オプション・ヘッダは、ノードがそれを処理するように設定されていないと、ノードによって考慮されないことも言及しておく価値がある[RFC8200]。拡張ヘッダに基づく他の攻撃は、IPv6ヘッダ・チェーンやフラグメンテーションに基づく可能性があり、フィルタリングをバイパスするために使用される可能性のある。この影響を軽減するために、初期IPv6ヘッダ、拡張ヘッダ、上位層ヘッダはすべて最初のフラグメントに含まなければならない[RFC8200]。また、すべての近隣探索メッセージにおいて、IPv6フラグメント・ヘッダの使用は禁止されている[RFC6980]。

フラグメント・ヘッダは、IPv6送信元ノードがパスMTUより大きなパケットを送信するために使用され、宛先ホストはフラグメント・ヘッダを処理する。フラグメンテーションに関連する注意すべき脅威としては、フラグメントの重複(禁止)、最後のフラグメントを待つ間のリソース消費(破棄)、アトミック・フラグメント(分離)などがある。

拡張ヘッダを持つIPv6パケットの運用上の影響については、[RFC9098]でさらに説明されている。

6. IANA に関する考慮事項

本文書にはIANAのアクションはない。

7. セキュリティに関する考慮事項

本文書は、特定のIPv6プロトコルや移行ツールのセキュリティ特性に影響を与えない。セクション5.4での説明に加え、プロトコルや移行ツールに関連するセキュリティ上の考慮事項は、関連文書に記載されている。

8. 参考文献

8.1. 引用規格

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, https://www.rfc-editor.org/info/rfc1918.

[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, https://www.rfc-editor.org/info/rfc3756.

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, https://www.rfc-editor.org/info/rfc3971.

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, https://www.rfc-editor.org/info/rfc4213.

[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, DOI 10.17487/RFC6036, October 2010, https://www.rfc-editor.org/info/rfc6036.

[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, DOI 10.17487/RFC6180, May 2011, https://www.rfc-editor.org/info/rfc6180.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, https://www.rfc-editor.org/info/rfc6333.

[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012, https://www.rfc-editor.org/info/rfc6540.

[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, https://www.rfc-editor.org/info/rfc6583.

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, https://www.rfc-editor.org/info/rfc6877.

[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, DOI 10.17487/RFC6883, March 2013, https://www.rfc-editor.org/info/rfc6883.

[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, https://www.rfc-editor.org/info/rfc7381.

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, https://www.rfc-editor.org/info/rfc7596.

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, https://www.rfc-editor.org/info/rfc7597.

[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, https://www.rfc-editor.org/info/rfc7599.

[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI 10.17487/RFC8950, November 2020, https://www.rfc-editor.org/info/rfc8950.

[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, https://www.rfc-editor.org/info/rfc9099.

[RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313, DOI 10.17487/RFC9313, October 2022, https://www.rfc-editor.org/info/rfc9313.

8.2. 参考規格

[Akm-stats] Akamai, "IPv6 Adoption Visualization", 2023, https://www.akamai.com/uk/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.

[Amzn] Amazon Web Services, "Announcing Internet Protocol Version 6 (IPv6) support for Amazon CloudFront, AWS WAF, and Amazon S3 Transfer Acceleration", October 2016, https://aws.amazon.com/es/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/.

[ANSI] ANSI, "Host and Router Profiles for IPv6", ANSI/CTA 2048-A, October 2020, https://shop.cta.tech/products/host-and-router-profiles-for-ipv6.

[APNIC1] APNIC Labs, "IPv6 Capable Rate by country (%)", https://stats.labs.apnic.net/ipv6.

[APNIC2] Huston, G., "IP addressing in 2021", January 2022, https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/.

[APNIC3] Huston, G., "BGP in 2020 - The BGP Table", January 2021, https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/.

[APNIC4] Huston, G., "BGP in 2021 - The BGP Table", January 2022, https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp-table/.

[APNIC5] APNIC Labs, "Average RTT Difference (ms) (V6 - V4) for World (XA)", https://stats.labs.apnic.net/v6perf/XA.

[APRICOT] Huston, G., "IPv6 Performance Measurement", February 2020, https://2020.apricot.net/assets/files/APAE432/ipv6-performance-measurement.pdf.

[ARCEP] ARCEP, "Proposant au ministre chargé des communications électroniques les modalités et les conditions d'attribution d'autorisations d'utilisation de fréquences dans la bande 3,4 - 3,8 GHz", [Decision on the terms and conditions for awarding licenses to use frequencies in the 3.4 – 3.8 GHz band], Décision n° [Decision No.] 2019-1386, November 2019, https://www.arcep.fr/uploads/tx_gsavis/19-1386.pdf.

[ARIN-CG] ARIN, "2020 ARIN Community Grant Program Recipients: IPv6 Security, Applications, and Training for Enterprises", 2020, https://www.arin.net/about/community_grants/recipients/2020.

[ARIN-SW] ARIN, "Preparing Applications for IPv6", https://www.arin.net/resources/guide/ipv6/preparing_apps_for_v6.pdf.

[BGR_1] BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment Monitor", December 2021, http://218.2.231.237:5001/cgi-bin/generate.

[BGR_2] BIIGROUP, "China Government IPv6 and DNSSEC Deployment Monitor", December 2021, http://218.2.231.237:5001/cgi-bin/generate_gov.

[BGR_3] BIIGROUP, "China Education IPv6 and DNSSEC Deployment Monitor", December 2021, http://218.2.231.237:5001/cgi-bin/generate_edu.

[BIPT] Vannieuwenhuyse, J., "IPv6 in Belgium", September 2017, https://www.ripe.net/participate/meetings/roundtable/september-2017/government-roundtable-meeting-bahrain-26-september-2017/presentations/belgium-experience-bahrain-roundtable.pdf.

[CAIDA] Huston, G., "Client-Side IPv6 Measurement", June 2020, https://www.cmand.org/workshops/202006-v6/slides/2020-06-16-client-side.pdf.

[CAIR] Cisco, "Cisco Annual Internet Report (2018-2023) White Paper", March 2020, https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html.

[Cldflr] Cloudflare, "Understanding and configuring Cloudflare's IPv6 support", https://support.cloudflare.com/hc/en-us/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support.

[cmpwr] Elkins, N., "Impact on Enterprises of the IPv6-Only Direction for the U.S. Federal Government", https://mydigitalpublication.com/article/Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U.S.+Federal+Government/3702828/664279/article.html.

[CN] China.org.cn, "China to speed up IPv6-based Internet development", November 2017, http://www.china.org.cn/business/2017-11/27/content_41948814.htm.

[CN-IPv6] National IPv6 Deployment and Monitoring Platform, "Active IPv6 Internet Users", (in Chinese), 2022, https://www.china-ipv6.cn/#/activeconnect/simpleInfo.

[CNLABS_1] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, https://cnlabs.in/IPv6_Mon/generate_industry.html.

[CNLABS_2] CNLABS, "Government IPv6 and DNSSEC Statistics", 2022, https://cnlabs.in/IPv6_Mon/generate_gov.html.

[ComputSecur] Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers and Security, Volume 77, Issue C, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018, https://doi.org/10.1016/j.cose.2018.04.012.

[Csc6lab] Cisco, "Display global data", 2023, https://6lab.cisco.com/stats/.

[EE] Heatley, N., "IPv6-only Devices on EE Mobile", January 2017, https://indico.uknof.org.uk/event/38/contributions/489/attachments/612/736/Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf.

[ETSI-GR-IPE-001] ETSI, "IPv6 Enhanced Innovation (IPE) Gap Analysis", ETSI GR IPE 001, V1.1.1, August 2021, https://www.etsi.org/deliver/etsi_gr/IPE/001_099/001/01.01.01_60/gr_IPE001v010101p.pdf.

[ETSI-IP6-WhitePaper] ETSI, "IPv6 Best Practices, Benefits, Transition Challenges and the Way Forward", ETSI White Paper No. 35, ISBN 979-10-92620-31-1, August 2020.

[FB] "Paul Saab Facebook V6 World Congress 2015", YouTube video, 25:32, posted by Upperside Conferences, March 2015, https://youtu.be/An7s25FSK0U.

[GFA] German Federal Government Commissioner for Information Technology, "IPv6-Masterplan für die Bundesverwaltung", [IPv6 Master Plan for the Federal Administration], November 2019, https://media.frag-den-staat.de/files/foi/531501/de-government-ipv6-masterplan-v100-entwurf_konvertiert.pdf.

[Ggl] Google, "Introduction to GGC", https://support.google.com/interconnect/answer/9058809?hl=en.

[G_stats] Google, "Google IPv6 Statistics", https://www.google.com/intl/en/ipv6/statistics.html.

[HBH-OPT-HDR] Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra, "Operational Issues with Processing of the Hop-by-Hop Options Header", Work in Progress, Internet-Draft, draft-ietf-v6ops-hbh-04, 10 March 2023, https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-04.

[HBH-PROCESSING] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-07, 6 April 2023, https://datatracker.ietf.org/doc/html/draft-ietf-6man-hbh-processing-07.

[HxBld] HexaBuild, "IPv6 Adoption Report 2020: The IPv6 Internet is the Corporate Network", November 2020, https://hexabuild.io/assets/files/HexaBuild-IPv6-Adoption-Report-2020.pdf.

[IAB] IAB, "IAB Statement on IPv6", November 2016, https://www.iab.org/2016/11/07/iab-statement-on-ipv6/.

[IDT] Government of India: Department of Telecommunications, "Revision of IPv6 Transition Timelines", February 2021, https://dot.gov.in/revision-ipv6-transition-timelines-2021.

[IGP-GT] Kuerbis, B. and M. Mueller, "The hidden standards war: economic factors affecting IPv6 deployment", DOI 10.1108/DPRG-10-2019-0085, February 2019, https://www.emerald.com/insight/content/doi/10.1108/DPRG-10-2019-0085/full/html.

[INFOCOM] Doan, T., Bajpai, V., and S. Crawford, "A Longitudinal View of Netflix: Content Delivery over IPv6 and Content Cache Deployments", IEEE INFOCOM 2020, IEEE Conference on Computer Communications, pp. 1073-1082, DOI 10.1109/INFOCOM41043.2020.9155367, July 2020, https://dl.acm.org/doi/abs/10.1109/INFOCOM41043.2020.9155367.

[IPv6-EXT-HDR] Bonica, R. and T. Jinmei, "Inserting, Processing And Deleting IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-bonica-6man-ext-hdr-update-07, 24 February 2022, https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update-07.

[IPv6-ONLY-DEF] Palet Martinez, J., "IPv6-only Terminology Definition", Work in Progress, Internet-Draft, draft-palet-v6ops-ipv6-only-05, 9 March 2020, https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only-05.

[IPv6Forum] IPv6Forum, "Estimating IPv6 & DNSSEC External Service Deployment Status", 2023, https://www.ipv6forum.com/IPv6-Monitoring/index.html.

[ISIF-ASIA-G] India Internet Engineering Society (IIESoc), "IPv6 Deployment at Enterprises", March 2022, https://isif.asia/ipv6-deployment-at-enterprises/.

[ISOC1] Internet Society, "State of IPv6 Deployment 2018", June 2018, https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/.

[ISOC2] York, D., "Facebook News Feeds Load 20-40% Faster Over IPv6", April 2015, https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/.

[ISOC3] Gont, F., "IPv6 Security Frequently Asked Questions (FAQ)", January 2019, https://www.internetsociety.org/wp-content/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf.

[MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over IPv6", IETF 99 Proceedings, July 2017, https://datatracker.ietf.org/meeting/99/materials/slides-99-maprg-measuring-youtube-content-delivery-over-ipv6-00.

[Mcrsft] Microsoft, "IPv6 for Azure VMs available in most regions", September 2016, https://azure.microsoft.com/en-us/updates/ipv6-for-azure-vms/.

[ND-CONSIDERATIONS] Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N. Buraglio, "Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment", Work in Progress, Internet-Draft, draft-ietf-v6ops-nd-considerations-00, 24 October 2022, https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-considerations-00.

[NRO] NRO, "Internet Number Resource Status Report", September 2021, https://www.nro.net/wp-content/uploads/NRO-Statistics-2021-Q3-FINAL.pdf.

[NST_1] NIST, "Estimating Industry IPv6 & DNSSEC External Service Deployment Status", 2023, https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com.

[NST_2] NIST, "Estimating USG IPv6 & DNSSEC External Service Deployment Status", 2023, https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov.

[NST_3] NIST, "Estimating University IPv6 & DNSSEC External Service Deployment Status", 2023, https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-edu.

[Ntflx] Aggarwal, R. and D. Temkin, "Enabling Support for IPv6", July 2012, https://netflixtechblog.com/enabling-support-for-ipv6-48a495d5196f.

[POTAROO1] Huston, G., "IP Addressing through 2021", January 2022, https://www.potaroo.net/ispcol/2022-01/addr2021.html.

[POTAROO2] POTAROO, "IPv6 Resource Allocations", March 2023, https://www.potaroo.net/bgp/iso3166/v6cc.html.

[RelJio] Chandra, R., "IPv6-only adoption challenges and standardization requirements", IETF 109 Proceedings, November 2020, https://datatracker.ietf.org/meeting/109/materials/slides-109-v6ops-ipv6-only-adoption-challenges-and-standardization-requirements-03.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, https://www.rfc-editor.org/info/rfc4862.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, https://www.rfc-editor.org/info/rfc5095.

[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, DOI 10.17487/RFC6264, June 2011, https://www.rfc-editor.org/info/rfc6264.

[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, https://www.rfc-editor.org/info/rfc6980.

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, https://www.rfc-editor.org/info/rfc7872.

[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, https://www.rfc-editor.org/info/rfc8064.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.

[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, https://www.rfc-editor.org/info/rfc8305.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, https://www.rfc-editor.org/info/rfc8415.

[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks", RFC 8683, DOI 10.17487/RFC8683, November 2019, https://www.rfc-editor.org/info/rfc8683.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, https://www.rfc-editor.org/info/rfc8981.

[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, https://www.rfc-editor.org/info/rfc9098.

[RIPE1] Huston, G., "Measuring IPv6 Performance", October 2016, https://ripe73.ripe.net/wp-content/uploads/presentations/35-2016-10-24-v6-performance.pdf.

[RIPE2] RIPE, "IPv6 Security", January 2023, https://www.ripe.net/support/training/material/ipv6-security/ipv6security-slides.pdf.

[SNDVN] Cullen, C., "Sandvine releases 2020 Mobile Internet Phenomena Report: YouTube is over 25% of all mobile traffic", February 2020, https://www.sandvine.com/press-releases/sandvine-releases-2020-mobile-internet-phenomena-report-youtube-is-over-25-of-all-mobile-traffic.

[TMus] Lagerholm, S., "Going IPv6 Only", June 2018, https://pc.nanog.org/static/published/meetings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf.

[US-CIO] Vought, R., "Memorandum for Heads of Executive Departments and Agencies: Completing the Transition to Internet Protocol Version 6 (IPv6)", 2020, https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf.

[US-FR] Federal Register, "Request for Comments on Updated Guidance for Completing the Transition to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)", March 2020, https://www.federalregister.gov/documents/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completing-the-transition-to-the-next-generation.

[W3Techs] W3Techs, "Historical yearly trends in the usage statistics of site elements for websites", 2023, https://w3techs.com/technologies/history_overview/site_element/all/y.

[WIPv6L] World IPv6 Launch, "Measurements", June 2022, https://www.worldipv6launch.org/measurements/.

付録 A. ネットワーク・オペレータへのアンケートと回答の概要

2020年の第3四半期中に欧州地域の50以上のサービス・プロバイダに対して、IPv6に関する計画やIPv6の導入状況を尋ねる調査を行った。

今回の調査では、38組織を代表する40名から回答を得た。本付録は、得られた結果をまとめたものである。

回答者の事業内容:

コンバージェント	モバイル	固定
82%	8%	11%

表10: オペレータの種類

質問 1. 今後2年間で、固定、モバイル、企業のどのユーザをIPv6に移行させる計画があるか?

A. 計画がある場合、固定、モバイル、企業のいずれかを移行するのか?
B. その理由は何か?
C. 開始時期: すでに進行中、12か月以内、12か月以降?
D. デュアルスタック、DS-Lite、464XLAT、MAP-T/Eのうち、どの移行ソリューションを使うか?

1.Aの回答(回答者38名)

はい	いいえ
79%	21%

表11 : 2年以内にIPv6に移行する計画

モバイル	固定	企業	回答なし
63%	63%	50%	3%

表12: 事業セグメント

1.B の回答(回答者 29 名)

これは自由回答式の質問だったにもかかわらず、いくつかの共通した回答を見つけることができる。

• 14名の回答者(48%)が、IPv4の枯渇に関連する問題を強調した。IPv6に移行する理由は、プライベート・アドレスや重複アドレスを避けるためである。
• 6名の回答者(20%)は、5G/IoTがIPv6を導入するビジネス上のインセンティブになると述べている。
• 4名の回答者(13%)は、IPv6を5Gの開始に関連付け、有効化するという国家規制の要請があることを強調した。
• 4名の回答者(13%)は、IPv6をイノベーション戦略の一部、または新しいサービスのイネイブラー(実現要因)として考えている。
• 4名の回答者(13%)は、企業顧客の要望を理由にIPv6を導入した。

1.Cの回答(回答者30名)

進行中	12か月以内	12か月以降	回答なし
60%	33%	0%	7％

表13: 期間

1.Dの回答(携帯の回答者28 名、有線の回答者27名)

デュアルスタック	464XLAT	MAP-T	回答なし
39%	21%	4%	36%

表14: 使用するときの移行: 携帯

デュアルスタック	DS-Lite	6RD/6VPE	回答なし
59%	19%	4%	19%

表 15 :使用するときの移行: 有線

質問 2. 上記の目的のためにネットワーク・デバイスを変更する必要があるか?

A. 「イエス」なら、どのようなデバイスか: CPE、BNG/モバイル・コア、またはNAT?
B. IPv6をサポートするために、メトロ、バックボーン、またはバックホール・ネットワークへの移行を開始するか?

2.Aの回答 (回答者30名)

はい	いいえ	回答なし
43%	33%	23%

表16: 変更が必要

CPE	ルータ	BNG	CGN	モバイル・コア
47%	27%	20%	33%	27%

表17: 変更内容

2.Bの回答 (回答者22名)

はい	将来	いいえ
9%	9%	82%

表18: 移行計画

付録B. 企業へのアンケートと回答の概要

Industry Network Technology Council (INTC)は2021年初頭、米国に拠点を置く中規模から大規模企業のIPv6 https://industrynetcouncil.org/に関するトレーニングとコンサルティングの必要性または意欲を検証するために、以下の調査を実施た。

54の組織から回答を得た。

質問1. あなたの組織ではIPv6をどの程度導入したか? (回答者54名)

回答	割合
なし	16.67%
何人かは何らかのトレーニングを受けたことがある	16.67%
多くの人が何らかのトレーニングを受けた	1.85%
ウェブサイトはIPv6に対応している	7.41%
ほとんどの機器はデュアルスタックである	31.48%
ネットワーク全体のIPv6移行計画がある	5.56%
多くの場所でIPv6-onlyで運用している	20.37%
ネットワーク全体がIPv6-only	0.00%

表19: IPv6の実装

質問2. INTCにどのような支援や訓練を望むか? (回答者54名)

回答	割合
IPv6セキュリティに関する訓練/ラボ	66.67%
IPv6の基礎に関する訓練/ラボ	55.56%
アドレス計画/ネットワーク構成に関する訓練/ラボ	57.41%
IPv6トラブルシューティングに関する訓練/ラボ	66.67%
アプリケーション変換に関する訓練/ラボ	35.19%
その他	14.81%

表 20: INTCの支援/訓練

質問3. あなたの組織でIPv6の導入を検討し始めるにあたり、どのような分野に懸念があると感じる? (回答者54名)

回答	割合
セキュリティ	31.48%
アプリケーションの変換	25.93%
トレーニング	27.78%
上記のすべて	33.33%
答えられるほどの知識がない	14.81%
その他	9.26%

表21: IPv6実装に関する懸念事項

謝辞

本文書の著者は、ブライアン・カーペンター、フレッド・ベイカー、アレクサンダー・ペトレスク、フェルナンド・ゴント、バーバラ・スターク、ハイシェン・ユ (ジョンソン)、ドゥルヴ・ドーディ、ボール・レンチェ、シュピン・ペン、ダニエル・ボイヤー、ダニエル・バーニア、ハリハラン・アナンサクリシュナン、ドナバン・フリッツ、イゴール・ルバシェフ、エリック・ニーグレン、エデュアルド・ヴァシレンコ、シャオ・シペンのコメントとレビューに感謝する。

貢献者

ナリニ・エルキンス
Inside Products
メール: [e-mail]

セバスチャン・ルルド
Post Luxembourg
メール: [e-mail]

著者のアドレス

ジュゼッペ・フィオッコラ
Huawei Technologies
Riesstrasse, 25
80992 Munich
ドイツ
メール: [e-mail]

パオロ・ヴォルパト
Huawei Technologies
Via Lorenteggio, 240
20147 Milan
イタリア
メール: [e-mail]

ジョルディ・パレット・マルティネス
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar, Madrid
スペイン
メール: [e-mail]

ギャン・S・ミシュラ
Verizon Inc.
メール: [e-mail]

Chongfeng Xie
China Telecom
メール: [e-mail]

変更履歴

• 2024.2.4