[要約] RFC 9386は、2022年のIPv6の展開状況を概説し、産業界におけるIPv6の採用度を分析し、残された課題を検討し、IPv6への移行において産業界が明確で統一されたアプローチをまだ取っていない領域でのさらなる調査を提案しています。RFC 6036を置き換えるものです。
Internet Engineering Task Force (IETF) G. Fioccola
Request for Comments: 9386 P. Volpato
Obsoletes: 6036 Huawei Technologies
Category: Informational J. Palet Martinez
ISSN: 2070-1721 The IPv6 Company
G. Mishra
Verizon Inc.
C. Xie
China Telecom
April 2023
This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036.
このドキュメントは、2022年のIPv6展開のステータスの概要を提供します。具体的には、業界でのIPv6の採用の程度を検討し、残りの課題を分析し、業界がまだ明確にしていない分野でのさらなる調査を提案します。IPv6への移行における統一アプローチ。RFC 6036を廃止します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9386.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9386で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. IPv6: The Global Picture
2.1. IPv4 Address Exhaustion
2.1.1. IPv4 Addresses per Capita and IPv6 Status
2.2. IPv6 Users
2.3. IPv6 Web Content
2.4. IPv6 Public Actions and Policies
3. A Survey on IPv6 Deployments
3.1. IPv6 Allocations
3.2. IPv6 among Internet Service Providers
3.3. IPv6 among Enterprises
3.3.1. Government and Universities
4. IPv6 Deployment Scenarios
4.1. Dual-Stack
4.2. IPv6-Only Overlay
4.3. IPv6-Only Underlay
4.4. IPv4-as-a-Service
4.5. IPv6-Only
5. Common IPv6 Challenges
5.1. Transition Choices
5.1.1. Service Providers: Fixed and Mobile Operators
5.1.2. Enterprises
5.1.3. Industrial Internet
5.1.4. Content and Cloud Service Providers
5.1.5. CPEs and User Devices
5.1.6. Software Applications
5.2. Network Management and Operations
5.3. Performance
5.3.1. IPv6 Packet Loss and Latency
5.3.2. Customer Experience
5.4. IPv6 Security and Privacy
5.4.1. Protocols' Security Issues
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Summary of Questionnaire and Replies for Network
Operators
Appendix B. Summary of Questionnaire and Replies for Enterprises
Acknowledgements
Contributors
Authors' Addresses
[RFC6036] describes IPv6 deployment scenarios that were adopted or foreseen by a number of Internet Service Providers (ISPs) who responded to a technical questionnaire in early 2010, and [RFC6036] also provides practices and plans that were expected to take place in the following years. Since the publication of [RFC6036], several other documents have contributed to the IPv6 transition discussion in operational environments. To name a few:
[RFC6036]は、2010年初頭に技術的なアンケートに回答した多くのインターネットサービスプロバイダー（ISP）によって採用または予見されたIPv6展開シナリオを説明し、[RFC6036]は、以下で行われると予想される慣行と計画を提供します。年。[RFC6036]の公開以来、他のいくつかの文書が運用環境でのIPv6遷移の議論に貢献してきました。いくつかの名前を付けるために：
* [RFC6180] discusses IPv6 deployment models and transition mechanisms, recommending those proven to be effective in operational networks.
* [RFC6180]は、IPv6の展開モデルと遷移メカニズムについて説明し、運用ネットワークで効果的であることが証明されたメカニズムを推奨しています。
* [RFC6883] provides guidance and suggestions for Internet content providers and Application Service Providers (ASPs).
* [RFC6883]は、インターネットコンテンツプロバイダーとアプリケーションサービスプロバイダー（ASP）にガイダンスと提案を提供します。
* [RFC7381] introduces the guidelines of IPv6 deployment for enterprises.
* [RFC7381]は、企業向けのIPv6展開のガイドラインを紹介します。
[RFC6540] recommends the support of IPv6 to all IP-capable nodes. It was referenced in the IAB statement on IPv6 [IAB], which represented a major step in driving the IETF and other Standards Development Organizations (SDOs) towards using IPv6 in their works.
[RFC6540]は、すべてのIP対応ノードに対するIPv6のサポートを推奨しています。IPv6 [IAB]のIABステートメントで参照されていました。これは、IETFおよびその他の標準開発組織（SDO）を作業で使用するための主要なステップを表しています。
In more recent times, organizations, such as ETSI, provided more contributions to the use of IPv6 in operational environments, targeting IPv6 in different industry segments. As a result, [ETSI-IP6-WhitePaper] was published to provide an updated view on the IPv6 best practices adopted so far, in particular, in the ISP domain.
最近では、ETSIなどの組織は、さまざまな業界セグメントでIPv6をターゲットにした運用環境でのIPv6の使用にさらに貢献しました。その結果、[ETSI-IP6-WhitePaper]が公開され、特にISPドメインでこれまでに採用されたIPv6ベストプラクティスに関する最新のビューを提供しました。
Considering all of the above, and after more than ten years since the publication of [RFC6036], it is useful to assess the status of the transition to IPv6. Some reasons include:
上記のすべてを考慮して、[RFC6036]の公開から10年以上経った後、IPv6への移行の状態を評価することが役立ちます。いくつかの理由は次のとおりです。
* In some areas, the lack of IPv4 addresses forced both carriers and content providers to shift to IPv6 to support the introduction of new applications, in particular, in wireless networks.
* 一部の分野では、IPv4アドレスが不足しているため、キャリアとコンテンツプロバイダーの両方がIPv6に移行し、特にワイヤレスネットワークでの新しいアプリケーションの導入をサポートすることを余儀なくされました。
* Some governmental actions took place to encourage or even enforce the adoption of IPv6 in certain countries.
* 特定の国でのIPv6の採用を奨励または実施するために、いくつかの政府の行動が起こった。
* Looking at the global adoption of IPv6, this seems to have reached a threshold that justifies speaking of end-to-end IPv6 connectivity, at least at the IPv6 service layer.
* IPv6のグローバルな採用を見ると、これは、少なくともIPv6サービスレイヤーで、エンドツーエンドのIPv6接続性について話すことを正当化するしきい値に達したようです。
This document aims to provide a survey of the status of IPv6 deployment and highlight both the achievements and remaining obstacles in the transition to IPv6 networks (and its coexistence with continued IPv4 services). The target is to give an updated view of the practices and plans already described in [RFC6036] to encourage further actions and more investigations in those areas that are still under discussion and to present the main incentives for the adoption of IPv6.
このドキュメントの目的は、IPv6展開のステータスの調査を提供し、IPv6ネットワークへの移行（および継続的なIPv4サービスとの共存）の成果と残りの障害の両方を強調することを目的としています。ターゲットは、[RFC6036]に既に説明されている実践と計画の最新の見解を提供し、まだ議論中の分野でさらなる行動とさらなる調査を促進し、IPv6の採用のための主要なインセンティブを提示することです。
This document is intended for a general audience interested in understanding the status of IPv6 in different industries and network domains. People who provide or use network services may find it useful for the transition to IPv6. Also, people developing plans for IPv6 adoption in an organization or in an industry may find information and references for their analysis. Attention is given to the different stages of the transition to IPv6 networks and services. In particular, terminology on the use of "IPv6-only" is provided, considering IPv6-only networks and services as the final stage of such transition.
このドキュメントは、さまざまな業界やネットワークドメインにおけるIPv6のステータスを理解することに関心のある一般的な聴衆を対象としています。ネットワークサービスを提供または使用する人は、IPv6への移行に役立つ場合があります。また、組織または業界でIPv6の採用計画を策定する人々は、分析のための情報と参照を見つけるかもしれません。IPv6ネットワークとサービスへの移行のさまざまな段階に注意が払われます。特に、IPv6のみのネットワークとサービスをそのような移行の最終段階として考慮して、「IPv6のみ」の使用に関する用語が提供されます。
The topics discussed in this document are organized into four main chapters.
このドキュメントで説明されているトピックは、4つの主要な章に編成されています。
* Section 2 reports data and analytics about the status of IPv6.
* セクション2は、IPv6のステータスに関するデータと分析を報告しています。
* Section 3 provides a survey of IPv6 deployments in different environments, including ISPs, enterprises, and universities.
* セクション3では、ISP、企業、大学などのさまざまな環境でのIPv6の展開の調査を提供します。
* Section 4 describes the IPv6 deployment approaches for Mobile Broadband (MBB), Fixed Broadband (FBB), and enterprises.
* セクション4では、モバイルブロードバンド（MBB）、固定ブロードバンド（FBB）、および企業のIPv6展開アプローチについて説明します。
* Section 5 analyzes the general challenges to be solved in the IPv6 transition. Specific attention is given to operations, performance, and security issues.
* セクション5では、IPv6遷移で解決される一般的な課題を分析します。運用、パフォーマンス、セキュリティの問題に特別な注意が払われます。
This section defines the terminology regarding the usage of IPv6-only expressions within this document. The term IPv6-only is defined in relation to the specific scope it is referring to. In this regard, it may happen that only part of a service, a network, or even a node is in an IPv6-only scope, and the rest is not. The most used terms in relation to the different scopes are listed below:
このセクションでは、このドキュメント内のIPv6のみの式の使用に関する用語を定義します。IPv6のみという用語は、参照されている特定の範囲に関連して定義されます。この点で、サービス、ネットワーク、またはノードの一部のみがIPv6のみの範囲にあることがあり、残りはそうではありません。さまざまなスコープに関連する最も使用される用語を以下に示します。
IPv6-only interface:
IPv6のみのインターフェイス：
The interface of a node is configured to forward only IPv6. This denotes that just part of the node can be IPv6-only since the rest of the interfaces of the same node may work with IPv4 as well. A Dual-Stack interface is not an IPv6-only interface.
ノードのインターフェイスは、IPv6のみを転送するように構成されています。これは、同じノードの残りのインターフェイスもIPv4で動作する可能性があるため、ノードの一部のみがIPv6のみである可能性があることを示します。デュアルスタックインターフェイスは、IPv6のみのインターフェイスではありません。
IPv6-only node:
IPv6のみのノード：
The node uses only IPv6. All interfaces of the host only have IPv6 addresses.
ノードはIPv6のみを使用します。ホストのすべてのインターフェイスには、IPv6アドレスのみがあります。
IPv6-only service:
IPv6のみのサービス：
It is used if, between the host's interface and the interface of the content server, all packet headers of the service session are IPv6.
ホストのインターフェイスとコンテンツサーバーのインターフェイスの間に、サービスセッションのすべてのパケットヘッダーがIPv6である場合に使用されます。
IPv6-only overlay:
IPv6のみのオーバーレイ：
It is used if, between the end points of the tunnels, all inner packet headers of the tunnels are IPv6. For example, IPv6-only overlay in a fixed network means that the encapsulation is only IPv6 between the interfaces of the Provider Edge (PE) nodes or between the Customer Provider Edge (CPE) node and the Broadband Network Gateway (BNG).
トンネルのエンドポイントの間に、トンネルのすべての内側パケットヘッダーがIPv6である場合に使用されます。たとえば、固定ネットワーク内のIPv6のみのオーバーレイは、カプセル化がプロバイダーエッジ（PE）ノードのインターフェイス間、またはカスタマープロバイダーエッジ（CPE）ノードとブロードバンドネットワークゲートウェイ（BNG）の間のIPv6のみであることを意味します。
IPv6-only underlay:
IPv6のみのアンダーレイ：
It is used if the data plane and control plane are IPv6, but this is not necessarily true for the management plane. For example, IPv6-only underlay in a fixed network means that the underlay network protocol is only IPv6 between any PE nodes, but they can be Dual-Stack in overlay. Segment Routing over IPv6 (SRv6) is an example of IPv6-only underlay.
データプレーンとコントロールプレーンがIPv6である場合に使用されますが、これは必ずしも管理プレーンに当てはまるわけではありません。たとえば、固定ネットワーク内のIPv6のみのアンダーレイは、アンダーレイネットワークプロトコルがPEノード間のIPv6のみであることを意味しますが、オーバーレイのデュアルスタックにすることができます。IPv6（SRV6）を介したセグメントルーティングは、IPv6のみのアンダーレイの例です。
IPv6-only network:
IPv6のみのネットワーク：
It is used if every node in this network is IPv6-only. IPv4 should not exist in an IPv6-only network. In particular, an IPv6-only network's data plane, control plane, and management plane must be IPv6. All PEs must be IPv6-only. Therefore, if tunnels exist among PEs, both inner and outer headers must be IPv6. For example, an IPv6-only access network means that every node in this access network must be IPv6-only, and similarly, an IPv6-only backbone network means that every node in this backbone network must be IPv6-only.
このネットワーク内のすべてのノードがIPv6のみである場合に使用されます。IPv4はIPv6のみのネットワークに存在しないでください。特に、IPv6のみのネットワークのデータプレーン、コントロールプレーン、および管理プレーンはIPv6でなければなりません。すべてのPEはIPv6のみでなければなりません。したがって、トンネルがPESに存在する場合、内側ヘッダーと外側ヘッダーの両方がIPv6でなければなりません。たとえば、IPv6のみのアクセスネットワークは、このアクセスネットワーク内のすべてのノードがIPv6のみである必要があることを意味し、同様に、IPv6のみのバックボーンネットワークは、このバックボーンネットワーク内のすべてのノードがIPv6のみでなければならないことを意味します。
IPv4-as-a-Service (IPv4aaS):
IPv4-as-a-service（ipv4aas）：
IPv4 service support is provided by means of a transition mechanism; therefore, there is a combination of encapsulation/ translation + IPv6-only underlay + decapsulation/translation. For an IPv6-only network, connectivity to legacy IPv4 is either non-existent or provided by IPv4aaS mechanisms.
IPv4サービスサポートは、遷移メカニズムによって提供されます。したがって、カプセル化/翻訳IPv6のみのアンダーレイ脱カプセル化/翻訳の組み合わせがあります。IPv6のみのネットワークの場合、Legacy IPv4への接続性は存在しないか、IPv4AASメカニズムによって提供されます。
Note that IPv6-only definitions are also discussed in [IPv6-ONLY-DEF].
IPv6のみの定義については、[IPv6-Only-Def]で説明されていることに注意してください。
This section deals with some key questions related to IPv6, namely: (1) the status of IPv4 exhaustion, often considered as one of the triggers to switch to IPv6, (2) the number of IPv6 end users, a primary measure to sense IPv6 adoption, (3) the percentage of websites reachable over IPv6, and (4) a report on IPv6 public actions and policies.
このセクションでは、IPv6に関連するいくつかの重要な質問、つまり：（1）IPv4排出のステータスは、多くの場合、IPv6に切り替えるトリガーの1つと考えられることがよくあります。採用、（3）IPv6で到達可能なWebサイトの割合、および（4）IPv6のパブリックアクションとポリシーに関するレポート。
These parameters are monitored by the Regional Internet Registries (RIRs) and other institutions worldwide, as they provide a first-order indication on the adoption of IPv6.
これらのパラメーターは、IPv6の採用に関する一次的な表示を提供するため、地域のインターネットレジストリ（RIRS）および世界中の他の機関によって監視されています。
According to [CAIR], there will be 29.3 billion networked devices by 2023, up from 18.4 billion in 2018. This poses the question about whether the IPv4 address space can sustain such a number of allocations and, consequently, if this may affect the process of its exhaustion. The answer is not straightforward, as many aspects have to be considered.
[Cair]によると、2023年までに293億のネットワークデバイスがあり、2018年の184億から増加します。これは、IPv4アドレススペースがこのような多くの割り当てを維持できるかどうかについての疑問を提起します。その疲労の。多くの側面を考慮する必要があるため、答えは簡単ではありません。
On one hand, the RIRs are reporting scarcity of available and still-reserved addresses. Table 3 of [POTAROO1] (January 2022) shows that the available pool of the five RIRs at the end of 2021 counted 5.2 million IPv4 addresses, while the reserved pool included another 12.1 million, for a total of 17.3 million IPv4 addresses (-5.5% year over year, comparing 2021 against 2020). Table 1 of [POTAROO1] shows that the total IPv4 allocated pool equaled 3.685 billion addresses (+0.027% year over year). The ratio between the available addresses and the total allocated was brought to 0.469% of the remaining IPv4 address space (from 0.474% at the end of 2020).
一方では、RIRSは、利用可能な住所の不足を報告しています。[Potaroo1]（2022年1月）の表3は、2021年末の5つのRIRの利用可能なプールが520万のIPv4アドレスを数え、予約済みのプールにはさらに1,210万人が含まれており、合計1730万のIPv4アドレス（-5.52021年を2020年と比較して、前年比で％）。[Potaroo1]の表1は、IPv4が割り当てられた総プールが36億8,500万の住所（前年比0.027％）に等しいことを示しています。利用可能なアドレスと割り当てられた合計との比率は、残りのIPv4アドレススペースの0.469％（2020年末の0.474％から）になりました。
On the other hand, [POTAROO1] again highlights the role of both address transfer and Network Address Translation (NAT) to counter the IPv4 exhaustion. The transfer of IPv4 addresses can be done under the control or registration of an RIR or on the so-called grey market, where third parties operate to enable the buying/selling of IPv4 addresses. In all cases, a set of IPv4 addresses is "transferred" to a different holder that has the need to expand their address range. As an example, [IGP-GT] and [NRO] show the amount of transfers to recipient organizations in the different regions. Cloud Service Providers (CSPs) appear to be the most active in buying IPv4 addresses to satisfy their need of providing IPv4 connectivity to their tenants. NAT systems provide a means to absorb at least a portion of the demand of public IPv4 addresses, as they enable the use of private addressing in internal networks while limiting the use of public addresses on their WAN-facing side. In the case of NAT, architectural and operational issues remain. Private address space cannot provide an adequate address span, especially for large organizations, and the reuse of addresses may make the network more complex. In addition, multiple levels of address translation may coexist in a network, e.g., Carrier-Grade NAT (CGN) [RFC6264], based on two stages of translation. This comes with an economic and operational burden, as discussed later in this document.
一方、[Potaroo1]は、IPv4の消耗に対抗するためのアドレス転送とネットワークアドレス変換（NAT）の両方の役割を再び強調しています。IPv4アドレスの転送は、RIRの制御または登録、またはいわゆるグレーマーケットで行うことができます。そこでは、第三者がIPv4アドレスの売買を可能にするために運営されています。すべての場合において、一連のIPv4アドレスは、アドレス範囲を拡張する必要がある別のホルダーに「転送」されます。例として、[IGP-GT]および[NRO]は、異なる地域の受信組織への転送量を示しています。クラウドサービスプロバイダー（CSP）は、テナントにIPv4接続を提供する必要性を満たすために、IPv4アドレスを購入する上で最も積極的であるようです。NATシステムは、Public IPv4アドレスの需要の少なくとも一部を吸収する手段を提供します。これは、WANフェイス側でのパブリックアドレスの使用を制限しながら、内部ネットワークでのプライベートアドレス指定の使用を可能にするためです。NATの場合、建築および運用上の問題は残っています。プライベートアドレススペースは、特に大規模な組織では適切なアドレススパンを提供することはできません。アドレスの再利用により、ネットワークがより複雑になる可能性があります。さらに、2つの翻訳に基づいて、複数のレベルのアドレス翻訳がネットワーク、たとえばキャリアグレードNAT（CGN）[RFC6264]に共存する場合があります。この文書で後述するように、これには経済的および運用上の負担が伴います。
The IPv4 addresses per capita ratio measures the quantity of IPv4 addresses allocated to a given country divided by the population of that country. It provides an indication of the imbalanced distribution of the IPv4 addresses worldwide. It clearly derives from the allocation of addresses made in the early days of the Internet.
IPv4アドレスは、一人当たりの比率を測定し、その国の人口で割った特定の国に割り当てられたIPv4アドレスの量を測定します。世界中のIPv4アドレスの不均衡な分布を示しています。インターネットの初期に作られたアドレスの割り当てに明確に派生しています。
The sources for measuring the IPv4 addresses per capita ratio are the allocations done by the RIRs and the statistics about the world population. In this regard, [POTAROO2] provides distribution files. The next tables compare the number of IPv4 addresses available per person in a certain country (IPv4 address per capita) against the relative adoption of IPv6 in the same country (expressed as the number of IPv6-capable users in the considered country). The table shows just a subset of the data available from [POTAROO2]. In particular, the following table provides the data for the 25 most populated countries in the world. The table is ordered based on the IPv4 addresses per capita ratio, and the data refer to 1 January 2022.
IPv4アドレスごとの一人当たりの比率を測定するソースは、RIRSが行った割り当てと世界人口に関する統計です。この点で、[potaroo2]は配布ファイルを提供します。次の表は、同じ国のIPv6の相対的な採用（考慮された国のIPv6対応ユーザーの数として表される）との相対的な採用と、特定の国で1人あたり利用可能なIPv4アドレスの数を比較します（1人あたりのIPv4アドレスあたり）。この表は、[Potaroo2]から利用可能なデータのサブセットのみを示しています。特に、次の表は、世界で最も人口の多い25か国のデータを提供します。この表は、一人当たりのIPv4アドレス比に基づいて注文され、データは2022年1月1日を参照しています。
+==============================+=================+=================+
| Country | IPv4 per Capita | IPv6 Deployment |
+==============================+=================+=================+
| United States of America | 4.89 | 47.1% |
+------------------------------+-----------------+-----------------+
| United Kingdom | 1.65 | 33.2% |
+------------------------------+-----------------+-----------------+
| Japan | 1.50 | 36.7% |
+------------------------------+-----------------+-----------------+
| Germany | 1.48 | 53.0% |
+------------------------------+-----------------+-----------------+
| France | 1.27 | 42.1% |
+------------------------------+-----------------+-----------------+
| Italy | 0.91 | 4.7% |
+------------------------------+-----------------+-----------------+
| South Africa | 0.46 | 2.4% |
+------------------------------+-----------------+-----------------+
| Brazil | 0.41 | 38.7% |
+------------------------------+-----------------+-----------------+
| Russian Federation | 0.31 | 9.7% |
+------------------------------+-----------------+-----------------+
| China | 0.24 | 60.1%(*) |
+------------------------------+-----------------+-----------------+
| Egypt | 0.24 | 4.3% |
+------------------------------+-----------------+-----------------+
| Mexico | 0.23 | 41.8% |
+------------------------------+-----------------+-----------------+
| Turkey | 0.20 | 0.2% |
+------------------------------+-----------------+-----------------+
| Vietnam | 0.17 | 48.0% |
+------------------------------+-----------------+-----------------+
| Iran (Islamic Republic) | 0.15 | 0.1% |
+------------------------------+-----------------+-----------------+
| Thailand | 0.13 | 40.8% |
+------------------------------+-----------------+-----------------+
| Indonesia | 0.07 | 5.0% |
+------------------------------+-----------------+-----------------+
| Philippines | 0.05 | 13.8% |
+------------------------------+-----------------+-----------------+
| India | 0.03 | 76.9% |
+------------------------------+-----------------+-----------------+
| Pakistan | 0.03 | 2.1% |
+------------------------------+-----------------+-----------------+
| United Republic of Tanzania | 0.02 | 0.0% |
+------------------------------+-----------------+-----------------+
| Nigeria | 0.02 | 0.2% |
+------------------------------+-----------------+-----------------+
| Bangladesh | 0.01 | 0.3% |
+------------------------------+-----------------+-----------------+
| Ethiopia | 0.00 | 0.0% |
+------------------------------+-----------------+-----------------+
| Democratic Republic of Congo | 0.00 | 0.1% |
+------------------------------+-----------------+-----------------+
Table 1: IPv4 per Capita and IPv6 Deployment for the Top 25 Most Populated Countries in the World (as of January 2022)
表1：世界で最も人口の多い国の上位25諸国の一人当たりのIPv4およびIPv6の展開（2022年1月現在）
(*) The IPv6 deployment information in China is derived from [CN-IPv6].
（*）中国のIPv6展開情報は[CN-IPV6]から派生しています。
A direct correlation between low IPv4 per capita and high IPv6 adoption is not immediate, yet some indications emerge. For example, some countries, such as Brazil, China, and India, have clearly moved towards IPv6 adoption. As discussed later, this appears related to several factors in addition to the lack of IPv4 addresses, including local regulation and market-driven actions. The 5 countries at the top of the table, with relative high availability of IPv4 addresses, have also shown a good level of IPv6 adoption. In other cases, a relative scarcity of IPv4 addresses has not meant a clear move towards IPv6, as several countries listed in the table still have low or very low IPv6 adoption.
1人あたりの低いIPv4と高いIPv6の採用との間の直接的な相関関係は即時ではありませんが、いくつかの兆候が出現します。たとえば、ブラジル、中国、インドなどの一部の国は、明らかにIPv6の採用に移行しています。後で説明したように、これは、ローカル規制や市場主導型のアクションなど、IPv4アドレスの欠如に加えて、いくつかの要因に関連しているように見えます。テーブルの上部にある5か国は、IPv4アドレスが比較的高く利用可能で、IPv6の採用のレベルも良好であることを示しています。それ以外の場合、IPv4アドレスの相対的な希少性は、テーブルにリストされているいくつかの国がまだ低いまたは非常に低いIPv6の採用を持っているため、IPv6への明確な動きを意味していません。
The count of the IPv6 users is the key parameter to get an immediate understanding of the adoption of IPv6. Some organizations constantly track the usage of IPv6 by aggregating data from several sources. As an example, the Internet Society constantly monitors the volume of IPv6 traffic for the networks that joined the World IPv6 Launch initiative [WIPv6L]. The measurement aggregates statistics from organizations, such as [Akm-stats], that provide data down to the single network level, measuring the number of hits to their content delivery platform. For the scope of this document, the approach used by APNIC to quantify the adoption of IPv6 by means of a script that runs on a user's device [CAIDA] is considered. To give a rough estimation of the relative growth of IPv6, the next table aggregates the total number of estimated IPv6-capable users as of 1 January 2022 and compares it against the total Internet users, as measured by [POTAROO2].
IPv6ユーザーのカウントは、IPv6の採用を即座に理解するための重要なパラメーターです。一部の組織は、いくつかのソースからデータを集約することにより、IPv6の使用を常に追跡しています。一例として、インターネット社会は、世界IPv6ローンチイニシアチブ[WIPV6L]に参加したネットワークのIPv6トラフィックの量を常に監視しています。この測定では、[AKM-stats]などの組織から統計を集約し、データを単一のネットワークレベルに下げてコンテンツ配信プラットフォームにヒット数を測定します。このドキュメントの範囲については、ユーザーのデバイス[CAIDA]で実行されるスクリプトによってIPv6の採用を定量化するためにAPNICが使用するアプローチが考慮されます。IPv6の相対的な成長を大まかに推定するために、次の表は、2022年1月1日現在の推定IPv6対応ユーザーの総数を集約し、[Potaroo2]で測定した総インターネットユーザーと比較します。
+=====+==========+==========+==========+==========+==========+=====+
| | Jan 2018 | Jan 2019 | Jan 2020 | Jan 2021 | Jan 2022 |CAGR |
+=====+==========+==========+==========+==========+==========+=====+
|IPv6 | 513.07 | 574.02 | 989.25 | 1,136.28 | 1,207.61 |23.9%|
+-----+----------+----------+----------+----------+----------+-----+
|World| 3,410.27 | 3,470.36 | 4,065.00 | 4,091.62 | 4,093.69 | 4.7%|
+-----+----------+----------+----------+----------+----------+-----+
|Ratio| 15.0% | 16.5% | 24.3% | 27.8% | 29.5% |18.4%|
+-----+----------+----------+----------+----------+----------+-----+
Table 2: IPv6-Capable Users against Total Users (in Millions) as of January 2022
表2：2022年1月現在の総ユーザー（数百万）に対するIPv6対応ユーザー
Two figures appear: first, the IPv6 Internet population is growing with a two-digit Compound Annual Growth Rate (CAGR), and second, the ratio IPv6 over total is also growing steadily.
2つの数値が表示されます。1つ目は、IPv6インターネット集団が2桁の複合年間成長率（CAGR）で増加しており、2つ目は、合計の比率も着実に増加しています。
[W3Techs] keeps track of the use of several technical components of websites worldwide through different analytical engines. The utilization of IPv6 for websites is shown in the next table, where the percentages refer to the websites that are accessible over IPv6.
[W3Techs]は、さまざまな分析エンジンを介して、世界中のWebサイトのいくつかの技術コンポーネントの使用を追跡しています。WebサイトでのIPv6の使用率は次のテーブルに示されています。ここでは、パーセンテージはIPv6を介してアクセス可能なWebサイトを指します。
+===========+=======+=======+=======+=======+=======+=======+
| Worldwide | Jan | Jan | Jan | Jan | Jan | CAGR |
| Websites | 2018 | 2019 | 2020 | 2021 | 2022 | |
+===========+=======+=======+=======+=======+=======+=======+
| % of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9% |
+-----------+-------+-------+-------+-------+-------+-------+
Table 3: Usage of IPv6 in Websites (as of January 2022)
表3：ウェブサイトでのIPv6の使用（2022年1月現在）
Looking at the growth rate, it may not appear particularly high. It has to be noted, though, that not all websites are equal. The largest content providers, which already support IPv6, generate a lot more content than small websites. At the beginning of January 2022, [Csc6lab] measured that out of the world's top 500 sites, 203 are IPv6 enabled (+3.6% from January 2021 to January 2022). If we consider that the big content providers (such as Google, Facebook, and Netflix) generate more than 50% of the total mobile traffic [SNDVN], and in some cases even more up to 65% [ISOC1] [HxBld], the percentage of content accessible over IPv6 is clearly more relevant than the number of enabled IPv6 websites. Of that 50% of all mobile traffic, it would be interesting to know what percentage is IPv6. Unfortunately, this information is not available.
成長率を見ると、それは特に高く見えないかもしれません。ただし、すべてのWebサイトが等しいわけではないことに注意する必要があります。すでにIPv6をサポートしている最大のコンテンツプロバイダーは、小さなWebサイトよりも多くのコンテンツを生成します。2022年1月の初めに、[CSC6LAB]は、世界のトップ500サイトのうち、203がIPv6対応であると測定しました（2021年1月から2022年1月まで3.6％）。大きなコンテンツプロバイダー（Google、Facebook、Netflixなど）がモバイルトラフィック全体の50％以上を生成し、場合によってはさらに65％[ISOC1] [HXBLD]を生成すると考えると、IPv6を介してアクセス可能なコンテンツの割合は、有効なIPv6 Webサイトの数よりも明らかに関連性があります。すべてのモバイルトラフィックの50％のうち、IPv6の割合を知ることは興味深いでしょう。残念ながら、この情報は利用できません。
Related to that, a question that sometimes arises is whether the content stored by content providers would be all accessible on IPv6 in the hypothetical case of a sudden IPv4 switch off. Even if this is pure speculation, the numbers above may bring to state that this is likely the case. This would reinforce the common thought that, in quantitative terms, most of the content is accessible via IPv6.
それに関連して、時々発生する質問は、突然のIPv4スイッチをオフにするという仮説的な場合、コンテンツプロバイダーによって保存されているコンテンツがIPv6ですべてアクセスできるかどうかです。これが純粋な推測であっても、上記の数字は、これがおそらくそうであると述べるかもしれません。これにより、定量的には、コンテンツのほとんどがIPv6を介してアクセスできるという一般的な考えが強化されます。
As previously noted, the worldwide deployment of IPv6 is not uniform [G_stats] [APNIC1]. It is worth noticing that, in some cases, higher IPv6 adoption in certain countries has been achieved as a consequence of actions taken by the local governments through regulation or incentive to the market. Looking at the European Union area, some countries, such as Belgium, France, and Germany, are well ahead in terms of IPv6 adoption.
前述のように、IPv6の世界的な展開は均一ではありません[g_stats] [apnic1]。場合によっては、特定の国でのIPv6の採用が高いことが、市場への規制またはインセンティブを通じて地方自治体が行った行動の結果として達成されたことに注意する価値があります。欧州連合地域を見ると、ベルギー、フランス、ドイツなどの一部の国は、IPv6の採用に関してはかなり先を行っています。
In the case of Belgium, the Belgian Institute for Postal services and Telecommunications (BIPT) acted to mediate an agreement between the local ISPs and the government to limit the use of Carrier-Grade NAT (CGN) systems and of public IPv4 addresses for lawful investigations in 2012 [BIPT]. The agreement limited the use of one IPv4 address per 16 customers behind NAT. The economic burden sustained by the ISPs for the unoptimized use of NAT induced the shift to IPv6 and its increased adoption in the latest years.
ベルギーの場合、ベルギーの郵便サービスおよび電気通信研究所（BIPT）は、地元のISPと政府との間の合意を仲介するために、キャリアグレードNAT（CGN）システムと合法的な調査のための公共IPv4アドレスの使用を制限するように行動しました。2012年[bipt]。この契約により、NATに次ぐ16人の顧客あたり1つのIPv4アドレスの使用が制限されていました。NATの最適化されていない使用のためにISPによって維持された経済的負担は、IPv6への移行とその最近の採用の増加を誘発しました。
In France, the National Regulator (Autorite de regulation des communications electroniques, or Arcep) introduced an obligation for the mobile carriers awarded with a license to use 5G frequencies (3.4-3.8 GHz) in Metropolitan France to be IPv6 compatible [ARCEP]. As stated in [ARCEP] (translated from French),
フランスでは、国家規制当局（Autorite de Regulation des Communications Electroniques、またはArcep）は、フランスの5G周波数（3.4-3.8 GHz）を使用するライセンスを授与されたモバイルキャリアに、IPv6互換に対応する義務を導入しました[arcep]。[arcep]（フランス語から翻訳）で述べられているように、
The goal is to ensure that services are interoperable and to remove obstacles to using services that are only available in IPv6, as the number of devices in use continues to soar, and because the RIPE NCC has run out of IPv4 addresses.
目標は、サービスが相互運用可能であることを保証し、使用中のデバイスの数が急上昇し続けているため、および熟したNCCがIPv4アドレスを使い果たしているため、IPv6でのみ利用可能なサービスを使用するための障害を削除することです。
A slow adoption of IPv6 could prevent new Internet services from spreading widely or create a barrier to entry for newcomers to the market. Per [ARCEP] (translated from French), "IPv6 can help to increase competition in the telecom industry, and help to industrialize a country for specific vertical sectors".
IPv6の採用が遅いため、新しいインターネットサービスが広く拡散することを妨げたり、新人の市場への参入障壁を作り出すことができます。[Arcep]（フランス語から翻訳）によると、「IPv6は通信業界での競争を増やすのに役立ち、特定の垂直部門の国を工業化するのに役立ちます」。
Increased IPv6 adoption in Germany depended on a mix of industry and public actions. Specifically, the Federal Office for Information Technology (under the Federal Ministry of the Interior) issued over the years a few recommendations on the use of IPv6 in the German public administration. The latest guideline in 2019 constitutes a high-level road map for mandatory IPv6 introduction in the federal administration networks [GFA].
ドイツでのIPv6の採用の増加は、業界と公的行動の混合に依存していました。具体的には、連邦情報技術事務所（内務連邦省の下）は、長年にわたってドイツの行政におけるIPv6の使用に関するいくつかの勧告を発行しました。2019年の最新のガイドラインは、連邦政権ネットワーク[GFA]における必須のIPv6導入のための高レベルのロードマップを構成しています。
In the United States, the Office of Management and Budget is also calling for IPv6 adoption [US-FR] [US-CIO]. These documents define a plan to have 80% of the US federal IP-capable networks based on IPv6-only by the year 2025. China is another example of a government that is supporting a country-wide IPv6 adoption [CN]. In India, the high adoption of IPv6 took origin from the decision of Reliance Jio to move to IPv6 in their networks [RelJio]. In addition, the Department of Telecommunications (under the Ministry of Communications and Information Technology) issued guidelines for the progressive adoption of IPv6 in public and private networks. The latest one dates 2021 [IDT] and fosters further moves to IPv6 connection services.
米国では、管理予算局もIPv6の採用[US-FR] [US-CIO]を求めています。これらの文書は、2025年までにIPv6のみに基づいて米国連邦IP対応ネットワークの80％を持つ計画を定義しています。中国は、国全体のIPv6採用を支援している政府のもう1つの例です[CN]。インドでは、IPv6の高い採用は、Reliance JioがネットワークでIPv6に移動するという決定に起因していました[Reljio]。さらに、電気通信部（通信情報技術省の下で）は、公共および民間のネットワークでIPv6を進歩するためのガイドラインを発行しました。最新のものは2021 [IDT]にさかのぼり、IPv6接続サービスにさらに移動します。
This section discusses the status of IPv6 adoption in service provider and enterprise networks.
このセクションでは、サービスプロバイダーおよびエンタープライズネットワークにおけるIPv6採用のステータスについて説明します。
RIRs are responsible for allocating IPv6 address blocks to ISPs, Local Internet Registries (LIRs), and enterprises or other organizations. An ISP/LIR will use the allocated block to assign addresses to their end users. The following table shows the amount of individual allocations, per RIR, in the time period from 2017-2021 [APNIC2].
RIRSは、IPv6アドレスブロックをISPS、ローカルインターネットレジストリ（LIRS）、および企業またはその他の組織に割り当てる責任があります。ISP/LIRは、割り当てられたブロックを使用して、アドレスをエンドユーザーに割り当てます。次の表は、2017 - 2021年の期間[APNIC2]の期間における個々の割り当ての量を示しています。
+==========+=====+=======+=======+=======+=======+===========+====+
| Registry |Dec | Dec | Dec | Dec | Dec | Cumulated |CAGR|
| |2017 | 2018 | 2019 | 2020 | 2021 | | |
+==========+=====+=======+=======+=======+=======+===========+====+
| 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%|
+----------+-----+-------+-------+-------+-------+-----------+----+
| Total |5,765| 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 51%|
+----------+-----+-------+-------+-------+-------+-----------+----+
Table 4: IPv6 Allocations Worldwide (as of January 2022)
表4：世界中のIPv6割り当て（2022年1月現在）
The trend shows the steady progress of IPv6. The decline of IPv6 allocations in 2020 and 2021 may be due to the COVID-19 pandemic. It also happened to IPv4 allocations.
この傾向は、IPv6の着実な進行を示しています。2020年と2021年のIPv6割り当ての減少は、Covid-19のパンデミックによるものかもしれません。また、IPv4の割り当てにも起こりました。
[APNIC2] also compares the number of allocations for both address families. The CAGR looks quite similar in 2021 but a little higher for the IPv4 allocations in comparison to the IPv6 allocations (53.6% versus 50.9%).
[APNIC2]は、両方のアドレスファミリの割り当ての数も比較します。CAGRは2021年に非常に似ていますが、IPv6割り当てと比較してIPv4割り当てでは少し高く見えます（53.6％対50.9％）。
+=========+=====+=====+========+=======+=======+===========+=======+
| Address |Dec |Dec | Dec | Dec | Dec | Cumulated | CAGR |
| family |2017 |2018 | 2019 | 2020 | 2021 | | |
+=========+=====+=====+========+=======+=======+===========+=======+
| 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% |
+---------+-----+-----+--------+-------+-------+-----------+-------+
Table 5: Allocations per Address Family (as of January 2022)
表5：住所家族ごとの割り当て（2022年1月現在）
The reason may be that the IPv4 allocations in 2021 included many allocations of small address ranges (e.g., /24) [APNIC2]. On the contrary, a single IPv6 allocation is large enough to cope with the need of an operator for long period. After an operator receives an IPv6 /30 or /32 allocation, it is unlikely that a new request of addresses is repeated in the short term.
その理由は、2021年のIPv4割り当てには、小さな住所範囲（ /24）の多くの割り当てが含まれていたためです[APNIC2]。それどころか、単一のIPv6割り当ては、長期にわたってオペレーターの必要性に対処するのに十分な大きさです。オペレーターがIPv6 /30または /32の割り当てを受け取った後、短期的にアドレスの新しい要求が繰り返される可能性は低いです。
The next table is based on [APNIC3] and [APNIC4] and shows the percentage of Autonomous Systems (ASes) supporting IPv6 compared to the total ASes worldwide. The number of IPv6-capable ASes increased from 24.3% in January 2018 to 38.7% in January 2022. This equals to 18% of the CAGR for IPv6-enabled networks. In comparison, the CAGR for the total of IPv6 and IPv4 networks is just 5%.
次の表は[APNIC3]と[APNIC4]に基づいており、世界中のASESと比較してIPv6をサポートする自律システム（ASES）の割合を示しています。IPv6対応ASの数は、2018年1月の24.3％から2022年1月の38.7％に増加しました。これは、IPv6対応ネットワークのCAGRの18％に相当します。それに比べて、IPv6およびIPv4ネットワークの合計のCAGRはわずか5％です。
+==============+========+========+========+========+========+======+
| Advertised | Jan | Jan | Jan | Jan | Jan | CAGR |
| ASN | 2018 | 2019 | 2020 | 2021 | 2022 | |
+==============+========+========+========+========+========+======+
| IPv6-capable | 14,500 | 16,470 | 18,650 | 21,400 | 28,140 | 18% |
+--------------+--------+--------+--------+--------+--------+------+
| Total ASN | 59,700 | 63,100 | 66,800 | 70,400 | 72,800 | 5% |
+--------------+--------+--------+--------+--------+--------+------+
| Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | |
+--------------+--------+--------+--------+--------+--------+------+
Table 6: Percentage of IPv6-Capable ASes (as of January 2022)
表6：IPv6対応ASESの割合（2022年1月現在）
The tables above provide an aggregated view of the allocations' dynamic. The next subsections will zoom into each specific domain to highlight its relative status.
上の表は、割り当ての動的な総ビューを提供します。次のサブセクションでは、特定の各ドメインにズームして、相対的なステータスを強調します。
A survey was submitted to a group of service providers in Europe during the third quarter of 2020 (see Appendix A for the complete poll) to understand their plans about IPv6 and their technical preferences regarding its adoption. Although this poll does not give an exhaustive view on the IPv6 status, it provides some insights that are relevant to the discussion.
調査は、2020年の第3四半期にヨーロッパのサービスプロバイダーグループに提出され（完全な世論調査については、付録Aを参照）、IPv6とその採用に関する技術的選好に関する計画を理解しました。この世論調査では、IPv6ステータスに関する徹底的な見解はありませんが、議論に関連するいくつかの洞察を提供します。
The poll revealed that the majority of ISPs interviewed had plans concerning IPv6 (79%). Of them, 60% had ongoing activities already, while 33% were expected to start activities in a 12-month timeframe. The transition to IPv6 involved all business segments: mobile (63%), fixed (63%), and enterprise (50%).
世論調査では、インタビューされたISPの大部分がIPv6に関する計画を持っていることが明らかになりました（79％）。そのうち60％はすでに進行中の活動を行っていましたが、33％は12か月の時間枠で活動を開始すると予想されていました。IPv6への移行には、モバイル（63％）、固定（63％）、およびエンタープライズ（50％）のすべてのビジネスセグメントが含まれていました。
The reasons to move to IPv6 varied. Global IPv4 address depletion and the run out of private address space recommended in [RFC1918] were reported as the important drivers for IPv6 deployment (48%). In a few cases, respondents cited the requirement of national IPv6 policies and the launch of 5G as the reasons (13%). Enterprise customer demand was also a reason to introduce IPv6 (13%).
IPv6に移動する理由はさまざまでした。グローバルIPv4アドレスの枯渇と[RFC1918]で推奨されるプライベートアドレススペースの不足は、IPv6展開の重要なドライバーとして報告されました（48％）。いくつかのケースでは、回答者は、国家IPv6ポリシーの要件と理由（13％）として5Gの発売を引用しました。エンタープライズの顧客需要は、IPv6を導入する理由でもありました（13％）。
From a technical preference standpoint, Dual-Stack [RFC4213] was the most adopted solution in both wireline (59%) and cellular networks (39%). In wireline, the second most adopted mechanism was Dual-Stack Lite (DS-Lite) [RFC6333] (19%). In cellular networks, the second preference was 464XLAT [RFC6877] (21%).
技術的な好みの観点から、デュアルスタック[RFC4213]は、有線（59％）とセルラーネットワーク（39％）の両方で最も採用されたソリューションでした。有線では、2番目に採用されたメカニズムはデュアルスタックライト（DS-Lite）[RFC6333]（19％）でした。セルラーネットワークでは、2番目の選好は464xlat [RFC6877]（21％）でした。
More details about the answers received can be found in Appendix A.
受け取った回答の詳細については、付録Aをご覧ください。
As described in [RFC7381], enterprises face different challenges than ISPs. Publicly available reports show how the enterprise deployment of IPv6 lags behind ISP deployment [cmpwr].
[RFC7381]で説明されているように、企業はISPとは異なる課題に直面しています。公開されているレポートは、ISP展開[CMPWR]の背後にIPv6のエンタープライズ展開がどのように遅れているかを示しています。
[NST_1] provides estimations on the deployment status of IPv6 for domains such as example.com, example.net, or example.org in the United States. The measurement encompasses many industries, including telecommunications, so the term "enterprises" is a bit loose in this context. In any case, it provides a first indication of IPv6 adoption in several US industry sectors. The analysis tries to infer whether IPv6 is supported by looking from "outside" a company's network. It takes into consideration the support of IPv6 to external services, such as Domain Name System (DNS), mail, and websites. [BGR_1] has similar data for China, while [CNLABS_1] provides the status in India.
[NST_1]は、米国のexample.com、embler.net、またはemble.orgなどのドメインのIPv6の展開ステータスに関する推定を提供します。この測定には、通信を含む多くの業界が含まれているため、この文脈では「企業」という用語は少しゆるいです。いずれにせよ、それはいくつかの米国の産業部門でのIPv6の採用の最初の兆候を提供します。分析は、会社のネットワークを「外部」から見ることによってIPv6がサポートされているかどうかを推測しようとします。ドメイン名システム（DNS）、メール、Webサイトなどの外部サービスに対するIPv6のサポートを考慮しています。[BGR_1]は中国に同様のデータを持っていますが、[CNLABS_1]はインドでのステータスを提供します。
+===============+==================+=======+=======+=========+
| Country | Domains analyzed | DNS | Mail | Website |
+===============+==================+=======+=======+=========+
| China | 478 | 74.7% | 0.0% | 19.7% |
+---------------+------------------+-------+-------+---------+
| India | 104 | 51.9% | 15.4% | 16.3% |
+---------------+------------------+-------+-------+---------+
| United States | 1070 | 66.8% | 21.2% | 6.3% |
| of America | | | | |
+---------------+------------------+-------+-------+---------+
Table 7: IPv6 Support for External-Facing Services across Enterprises (as of January 2022)
表7：IPv6企業全体の外部向けサービスのサポート（2022年1月現在）
A poll submitted to a group of large enterprises in North America in early 2021 (see Appendix B) shows that the operational issues are even more critical than for ISPs.
2021年初頭に北米の大企業グループに提出された世論調査（付録Bを参照）は、運用上の問題がISPよりもさらに重要であることを示しています。
Looking at current implementations, almost one third has dual-stacked networks, while 20% declares that portions of their networks are IPv6-only. Additionally, 35% of the enterprises did not implement IPv6 at all or are stuck at the training phase. In no case is the network fully based on IPv6.
現在の実装を見ると、ほぼ3分の1がデュアルスタックネットワークを持っていますが、20％はネットワークの一部がIPv6のみであると宣言しています。さらに、企業の35％がIPv6をまったく実装していないか、トレーニングフェーズで立ち往生しています。いずれの場合も、ネットワークはIPv6に完全に基づいています。
Speaking of training, the most critical needs are in the field of IPv6 security and IPv6 troubleshooting (both highlighted by the two thirds of respondents), followed by address planning / network configurations (57.41%).
トレーニングといえば、最も重要なニーズは、IPv6セキュリティとIPv6のトラブルシューティング（両方とも回答者の3分の2で強調表示されている）の分野に続き、その後にアドレス計画 /ネットワーク構成（57.41％）が続きます。
Coming to implementation, the three areas of concern are IPv6 security (31.48%), training (27.78%), and application conversion (25.93%), and 33.33% of respondents think that all three areas are all simultaneously of concern.
実装に来ると、懸念される3つの領域は、IPv6セキュリティ（31.48％）、トレーニング（27.78％）、およびアプリケーション変換（25.93％）、および回答者の33.33％が3つの領域すべてがすべて懸念事項であると考えています。
The full poll is reported in Appendix B.
完全な世論調査は付録Bに報告されています。
This section focuses specifically on the adoption of IPv6 in governments and academia.
このセクションでは、政府と学界でのIPv6の採用に特に焦点を当てています。
As far as governmental agencies are concerned, [NST_2] provides analytics on the degree of IPv6 support for DNS, mail, and websites across second-level domains associated with US federal agencies. These domains are in the form of example.gov or example.fed. The script used by [NST_2] has also been employed to measure the same analytics in other countries, e.g., China [BGR_2], India [CNLABS_2], and the European Union [IPv6Forum]. For this latter analytic, some post-processing is necessary to filter out the non-European domains.
政府機関に関する限り、[NST_2]は、米国の連邦機関に関連する第2レベルのドメイン全体でDNS、メール、およびWebサイトのIPv6サポートの程度に関する分析を提供しています。これらのドメインは、example.govまたはexample.fedの形式です。[NST_2]で使用されるスクリプトは、他の国で同じ分析を測定するためにも採用されています。たとえば、中国[BGR_2]、インド[CNLABS_2]、および欧州連合[IPv6Forum]。この後者の分析では、非ヨーロッパのドメインを除外するには、いくつかの後処理が必要です。
+====================+==================+=======+=======+=========+
| Country | Domains analyzed | DNS | Mail | Website |
+====================+==================+=======+=======+=========+
| China | 52 | 0.0% | 0.0% | 98.1% |
+--------------------+------------------+-------+-------+---------+
| European Union (*) | 19 | 47.4% | 0.0% | 21.1% |
+--------------------+------------------+-------+-------+---------+
| India | 618 | 7.6% | 6.5% | 7.1% |
+--------------------+------------------+-------+-------+---------+
| United States of | 1283 | 87.1% | 14.0% | 51.7% |
| America | | | | |
+--------------------+------------------+-------+-------+---------+
Table 8: IPv6 Support for External-Facing Services across Governmental Institutions (as of January 2022)
表8：政府機関全体の外部向けサービスのIPv6サポート（2022年1月現在）
(*) Both EU and country-specific domains are considered.
（*）EUと国固有のドメインの両方が考慮されます。
IPv6 support in the US is higher than other countries. This is likely due to the IPv6 mandate set by [US-CIO]. In the case of India, the degree of support seems still quite low. This is also true for China, with the notable exception of a high percentage of IPv6-enabled websites for government-related organizations.
米国でのIPv6サポートは、他の国よりも高くなっています。これは、[us-cio]によって設定されたIPv6マンデートによるものです。インドの場合、サポートの程度はまだ非常に低いようです。これは中国にも当てはまりますが、政府関連の組織向けのIPv6対応のWebサイトの割合が高いことを例外としています。
Similar statistics are also available for higher education. [NST_3] measures the data from second-level domains of universities in the US, such as example.edu. [BGR_3] looks at Chinese education-related domains. [CNLABS_1] analyzes domains in India (mostly third level), while [IPv6Forum] lists universities in the European Union (second level), again after filtering the non-European domains.
同様の統計も高等教育に利用できます。[NST_3]は、Example.eduなど、米国の大学の第2レベルのドメインからのデータを測定します。[BGR_3]は、中国の教育関連のドメインに注目しています。[CNLABS_1]はインドのドメインを分析します（ほとんどが第3レベル）。一方、[IPv6Forum]は、非ヨーロッパのドメインをフィルタリングした後、欧州連合（第2レベル）の大学をリストします。
+================+==================+=======+=======+=========+
| Country | Domains analyzed | DNS | Mail | Website |
+================+==================+=======+=======+=========+
| China | 111 | 36.9% | 0.0% | 77.5% |
+----------------+------------------+-------+-------+---------+
| European Union | 118 | 83.9% | 43.2% | 35.6% |
+----------------+------------------+-------+-------+---------+
| India | 100 | 31.0% | 54.0% | 5.0% |
+----------------+------------------+-------+-------+---------+
| United States | 346 | 49.1% | 19.4% | 21.7% |
| of America | | | | |
+----------------+------------------+-------+-------+---------+
Table 9: IPv6 Support for External-Facing Services across Universities (as of January 2022)
表9：大学全体の外部向けサービスのIPv6サポート（2022年1月現在）
Overall, the universities have wider support of IPv6-based services compared to the other sectors. Apart from a couple of exceptions (e.g., the support of IPv6 mail in China and IPv6 websites in India), the numbers shown in the table above indicate good support of IPv6 in academia.
全体として、大学は他のセクターと比較してIPv6ベースのサービスをより広く支援しています。いくつかの例外（たとえば、中国のIPv6メールとインドのIPv6ウェブサイトのサポート）は別として、上記の表に示されている数字は、アカデミアのIPv6の良好なサポートを示しています。
The scope of this section is to discuss the network and service scenarios applicable for the transition to IPv6. Most of the related definitions have been provided in Section 1.1. This clause is intended to focus on the technical and operational characteristics. The sequence of scenarios described here does not necessarily have to be intended as a road map for the IPv6 transition. Depending on their specific plans and requirements, service providers may either adopt the scenarios proposed in a sequence or jump directly to a specific one.
このセクションの範囲は、IPv6への移行に適用されるネットワークおよびサービスシナリオについて説明することです。関連する定義のほとんどは、セクション1.1で提供されています。この条項は、技術的および運用上の特性に焦点を当てることを目的としています。ここで説明する一連のシナリオは、必ずしもIPv6遷移のロードマップとして意図する必要はありません。特定の計画と要件に応じて、サービスプロバイダーは、シーケンスで提案されたシナリオを採用するか、特定のシナリオに直接ジャンプする場合があります。
Based on the poll answers provided by network operators (Appendix A), Dual-Stack [RFC4213] appears to be currently the most widely deployed IPv6 solution (about 50%; see both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper]).
ネットワークオペレーター（付録A）が提供する世論調査の回答に基づいて、デュアルスタック[RFC4213]は現在、最も広く展開されているIPv6ソリューションです（約50％;付録Aと[ETSI-IP6-WhitePaperの両方の統計を参照してください]）。
With Dual-Stack, IPv6 can be introduced together with other network upgrades, and many parts of network management and IT systems can still work in IPv4. This avoids a major upgrade of such systems to support IPv6, which is possibly the most difficult task in the IPv6 transition. The cost and effort on the network management and IT systems upgrade are moderate. The benefits are to start using IPv6 and save NAT costs.
デュアルスタックを使用すると、IPv6は他のネットワークアップグレードと一緒に導入でき、ネットワーク管理およびITシステムの多くの部分はIPv4で機能します。これにより、IPv6のトランジションで最も困難なタスクであるIPv6をサポートするためのこのようなシステムの主要なアップグレードが回避されます。ネットワーク管理とITシステムのアップグレードのコストと労力は緩やかです。利点は、IPv6の使用を開始し、NATコストを節約することです。
Although Dual-Stack may provide advantages in the introductory stage, it does have a few disadvantages in the long run, like the duplication of the network resources and states. It also requires more IPv4 addresses, thus increasing both Capital Expenses (CAPEX) and Operating Expenses (OPEX). For example, even if private addresses are used with Carrier-Grade NAT (CGN), there is extra investment in the CGN devices, logs storage, and help desk to track CGN-related issues.
デュアルスタックは導入段階で利点を提供する可能性がありますが、ネットワークリソースと状態の複製のように、長期的にはいくつかの欠点があります。また、より多くのIPv4アドレスを必要とするため、資本費用（CAPEX）と営業費用（OPEX）の両方が増加します。たとえば、キャリアグレードNAT（CGN）でプライベートアドレスが使用されている場合でも、CGN関連の問題を追跡するために、CGNデバイス、ログストレージ、ヘルプデスクに追加の投資があります。
For this reason, when IPv6 usage exceeds a certain threshold, it may be advantageous to start a transition to the next scenario. For example, the process may start with the IPv4aaS stage, as described hereinafter. It is difficult to establish the criterion for switching (e.g., to properly identify the upper bound of the IPv4 decrease or the lower bound of the IPv6 increase). In addition to the technical factors, the switch to the next scenarios may also cause a loss of customers. Based on the feedback of network operators participating in the World IPv6 Launch [WIPv6L] in June 2021, 108 out of 346 operators exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%), and 37 exceed 75% (10.7%). The consensus to move to IPv6-only might be reasonable when IPv6 traffic volume is between 50% and 60%.
このため、IPv6の使用が特定のしきい値を超える場合、次のシナリオへの移行を開始することが有利かもしれません。たとえば、以下に説明するように、プロセスはIPv4AASステージから始まることがあります。切り替えの基準を確立することは困難です（たとえば、IPv4の減少またはIPv6増加の下限を適切に識別するため）。技術的要因に加えて、次のシナリオへの切り替えは顧客の損失を引き起こす可能性があります。2021年6月に世界IPv6発売[WIPv6L]に参加しているネットワークオペレーターのフィードバックに基づいて、346のオペレーターのうち108がIPv6トラフィック量の50％（31.2％）を超え、72は60％（20.8％）を超え、37は75を超えています。％（10.7％）。IPv6のみに移行するためのコンセンサスは、IPv6のトラフィック量が50％から60％の場合、妥当な場合があります。
As defined in Section 1.1, IPv6-only is generally associated with a scope, e.g., IPv6-only overlay or IPv6-only underlay.
セクション1.1で定義されているように、IPv6のみは一般に、IPv6のみのオーバーレイまたはIPv6のみのアンダーレイなど、スコープに関連付けられています。
The IPv6-only overlay denotes that the overlay tunnel between the end points of a network is based only on IPv6. Tunneling provides a way to use an existing IPv4 infrastructure to carry IPv6 traffic. IPv6 or IPv4 hosts and routers can tunnel IPv6 packets over IPv4 regions by encapsulating them within IPv4 packets. The approach with IPv6-only overlay helps to maintain compatibility with the existing base of IPv4, but it is not a long-term solution.
IPv6のみのオーバーレイは、ネットワークのエンドポイント間のオーバーレイトンネルがIPv6のみに基づいていることを示します。トンネリングは、既存のIPv4インフラストラクチャを使用してIPv6トラフィックを運ぶ方法を提供します。IPv6またはルーターは、IPv4パケット内でそれらをカプセル化することにより、IPv4領域でIPv6パケットをトンネルできます。IPv6のみのオーバーレイを使用したアプローチは、IPv4の既存のベースとの互換性を維持するのに役立ちますが、長期的なソリューションではありません。
As a matter of fact, IPv4 reachability must be provided for a long time to come over IPv6 for IPv6-only hosts. Most ISPs are leveraging CGN to extend the life of IPv4 instead of going with IPv6-only solutions.
実際のところ、IPv6のみのホストのIPv6を超えるために、IPv4の到達可能性を長時間提供する必要があります。ほとんどのISPは、IPv6のみのソリューションを使用する代わりに、CGNを活用してIPv4の寿命を延ばしています。
The IPv6-only underlay network uses IPv6 as the network protocol for all traffic delivery. Both the control and data planes are based on IPv6. The definition of IPv6-only underlay needs to be associated with a scope in order to identify the domain where it is applicable, such as the IPv6-only access network or IPv6-only backbone network.
IPv6のみのアンダーレイネットワークは、すべてのトラフィック配信のネットワークプロトコルとしてIPv6を使用します。制御面とデータプレーンの両方は、IPv6に基づいています。IPv6のみのアクセスネットワークやIPv6のみのバックボーンネットワークなど、該当するドメインを識別するために、IPv6のみのアンダーレイの定義をスコープに関連付ける必要があります。
When both enterprises and service providers begin to transition from an IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not necessarily need to Dual-Stack the underlay. Forwarding plane complexity on the Provider (P) nodes of the ISP core should be kept simple as a backbone with a single protocol. Hence, when operators decide to transition to an IPv6 underlay, the ISP backbone should be IPv6-only because Dual-Stack is not the best choice. The underlay could be IPv6-only and allow IPv4 packets to be tunneled using a VPN over an IPv6-only backbone while leveraging [RFC8950], which specifies the extensions necessary to allow advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 next hop.
企業とサービスプロバイダーの両方がIPv4/MPLSバックボーンから移行して、アンダーレイにIPv6を導入し始める場合、必ずしもアンダーレイをデュアルスタックする必要はありません。ISPコアのプロバイダー（P）ノードの転送面の複雑さは、単一のプロトコルを備えたバックボーンとしてシンプルに保つ必要があります。したがって、オペレーターがIPv6アンダーレイに移行することを決定した場合、デュアルスタックが最良の選択ではないため、ISPバックボーンはIPv6のみである必要があります。アンダーレイはIPv6のみであり、[RFC8950]をレバレッジしながら、IPv6のみのバックボーンを介してVPNを使用してIPv4パケットをトンネルにすることができます。。
IPv6-only underlay network deployment for access and backbone networks seems to not be the first option, and the current trend is to keep the IPv4/MPLS data plane and run IPv4/IPv6 Dual-Stack to edge nodes.
AccessおよびBackboneネットワーク用のIPv6のみのアンダーレイネットワーク展開は最初のオプションではないようであり、現在の傾向はIPv4/MPLSデータプレーンを維持し、IPv4/IPv6デュアルスタックをエッジノードに実行することです。
As ISPs do the transition in the future to an IPv6-only access network or backbone network, e.g., Segment Routing over IPv6 (SRv6) data plane, they start the elimination of IPv4 from the underlay transport network while continuing to provide IPv4 services. Basically, as also shown by the poll among network operators, from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network per reasons mentioned above related to the forwarding plane complexities.
ISPSは、IPv6のみのアクセスネットワークまたはバックボーンネットワーク、たとえばIPv6（SRV6）データプレーンを介したセグメントルーティング、IPv4サービスを提供し続けながらIPv4の排除を開始します。基本的に、ネットワークオペレーターの間で投票で示されているように、ネットワークアーキテクチャの観点からは、転送面の複雑さに関連する理由に従って、トランスポートネットワークにデュアルスタックを適用することはお勧めしません。
IPv4aaS can be used to ensure IPv4 support, and it can be a complex decision that depends on several factors, such as economic aspects, policy, and government regulation.
IPv4AASを使用してIPv4のサポートを確保することができます。また、経済的側面、政策、政府規制など、いくつかの要因に依存する複雑な決定になる可能性があります。
[RFC9313] compares the merits of the most common transition solutions for IPv4aaS, i.e., 464XLAT [RFC6877], DS-Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], and Mapping of Address and Port using Translation (MAP-T) [RFC7599], but does not provide an explicit recommendation. However, the poll in Appendix A indicates that the most widely deployed IPv6 transition solution in the Mobile Broadband (MBB) domain is 464XLAT, while in the Fixed Broadband (FBB) domain, it is DS-Lite.
[RFC9313]は、IPv4AASの最も一般的な遷移ソリューションのメリット、つまり464XLAT [RFC6333]、Lightweight 4Over6（LW4O6）[RFC7596]、標準のアドレスおよびポートのマッピング（MAP-E）のマッピングを比較します。[RFC7597]、および翻訳（MAP-T）[RFC7599]を使用したアドレスとポートのマッピングですが、明示的な推奨事項は提供されません。ただし、付録Aの世論調査では、モバイルブロードバンド（MBB）ドメインで最も広く展開されているIPv6遷移ソリューションが464xLatであることが示されていますが、固定ブロードバンド（FBB）ドメインでは、DS-Liteです。
Both are IPv4aaS solutions that leverage IPv6-only underlay. IPv4aaS offers Dual-Stack service to users and allows an ISP to run IPv6-only in the network, typically the access network.
どちらもIPv6のみのアンダーレイを活用するIPv4AASソリューションです。IPv4aasは、ユーザーにデュアルスタックサービスを提供し、ISPがネットワーク（通常はアクセスネットワーク）でIPv6のみを実行できるようにします。
While it may not always be the case, IPv6-only transition technologies, such as 464XLAT, require far fewer IPv4 addresses [RFC9313], because they are more efficient and do not restrict the number of ports per subscriber. This helps to reduce troubleshooting costs and to remove some operational issues related to permanent block listing of IPv4 address blocks when used via CGN in some services.
必ずしもそうではないかもしれませんが、464xlatなどのIPv6のみの移行技術には、より効率的で、サブスクライバーあたりのポート数を制限しないため、IPv4アドレスがはるかに少なくなります[RFC9313]。これにより、トラブルシューティングコストを削減し、一部のサービスでCGNを介して使用する場合のIPv4アドレスブロックの永続的なブロックリストに関連するいくつかの運用上の問題を削除するのに役立ちます。
IPv4aaS may be facilitated by the natural upgrade or replacement of CPEs because of newer technologies (triple-play, higher bandwidth WAN links, better Wi-Fi technologies, etc.). The CAPEX and OPEX of other parts of the network may be lowered (for example, CGN and associated logs) due to the operational simplification of the network.
IPV4AAは、新しいテクノロジー（トリプルプレイ、より高い帯域幅WANリンク、より良いWi-Fiテクノロジーなど）のために、CPEの自然なアップグレードまたは交換によって促進される場合があります。ネットワークの運用上の簡素化により、ネットワークの他の部分のCAPEXとOPEXは、（たとえば、CGNや関連するログなど）低下させることができます。
For deployments with a large number of users (e.g., large mobile operators) or a large number of hosts (e.g., large Data Centers (DCs)), even the full private address space [RFC1918] is not enough. Also, Dual-Stack will likely lead to duplication of network resources and operations to support both IPv6 and IPv4, which increases the amount of state information in the network. This suggests that, for scenarios such as MBB or large DCs, IPv4aaS could be more efficient from the start of the IPv6 introduction.
多数のユーザー（大規模なモバイルオペレーターなど）または多数のホスト（大規模なデータセンター（DCS）など）との展開については、完全なプライベートアドレススペース[RFC1918]でも十分ではありません。また、デュアルスタックは、IPv6とIPv4の両方をサポートするためにネットワークリソースと操作の重複につながる可能性があり、ネットワーク内の状態情報の量が増加します。これは、MBBや大型DCなどのシナリオの場合、IPv4AASがIPv6の導入の開始からより効率的になる可能性があることを示唆しています。
So, in general, when the Dual-Stack disadvantages outweigh the IPv6-only complexity, it makes sense to transition to IPv4aaS. Some network operators have already started this process, as in the case of [TMus], [RelJio], and [EE].
したがって、一般に、デュアルスタックの欠点がIPv6のみの複雑さを上回る場合、IPv4aasに移行することは理にかなっています。[tmus]、[reljio]、および[ee]の場合のように、一部のネットワーク演算子はすでにこのプロセスを開始しています。
IPv6-only is the final stage of the IPv6 transition, and it happens when a complete network, end to end, no longer has IPv4. No IPv4 address is configured for network management or anything else.
IPv6のみがIPv6遷移の最終段階であり、完全なネットワークが終了し、IPv4がない場合に発生します。ネットワーク管理などのIPv4アドレスは構成されていません。
Since IPv6-only means that both underlay networks and overlay services are only IPv6, it will take longer to happen.
IPv6のみは、アンダーレイネットワークとオーバーレイサービスの両方がIPv6のみであることを意味するため、発生するのに時間がかかります。
This section lists common IPv6 challenges, which have been validated and discussed during several meetings and public events. The scope is to encourage more investigations. Despite that IPv6 has already been well proven in production, there are some challenges to consider. In this regard, it is worth noting that [ETSI-GR-IPE-001] also discusses gaps that still exist in IPv6-related use cases.
このセクションには、いくつかの会議や公開イベントで検証および議論された一般的なIPv6の課題がリストされています。範囲は、より多くの調査を促進することです。IPv6はすでに生産が十分に証明されているにもかかわらず、考慮すべきいくつかの課題があります。この点で、[ETSI-GR-IPE-001]は、IPv6関連のユースケースにまだ存在するギャップについても議論していることは注目に値します。
A service provider, an enterprise, or a CSP may perceive quite a complex task with the transition to IPv6 due to the many technical alternatives available and the changes required in management and operations. Moreover, the choice of the method to support the transition is an important challenge and may depend on factors specific to the context, such as the IPv6 network design that fits the service requirements, the network operations, and the deployment strategy.
サービスプロバイダー、企業、またはCSPは、利用可能な多くの技術的な選択肢と管理と運用に必要な変更により、IPv6への移行と非常に複雑なタスクを認識する場合があります。さらに、遷移をサポートする方法の選択は重要な課題であり、サービス要件、ネットワーク操作、展開戦略に適合するIPv6ネットワーク設計など、コンテキストに固有の要因に依存する場合があります。
The subsections below briefly highlight the approaches that the different parties may take and the related challenges.
以下のサブセクションは、さまざまな当事者がとる可能性のあるアプローチと関連する課題を簡単に強調しています。
For fixed operators, the massive software upgrade of CPEs to support Dual-Stack already started in most of the service provider networks. On average, looking at the global statistics, the IPv6 traffic percentage is currently around 40% [G_stats]. As highlighted in Section 3.2, all major content providers have already implemented Dual-Stack access to their services, and most of them have implemented IPv6-only in their Data Centers. This aspect could affect the decision on the IPv6 adoption for an operator, but there are also other factors, like the current IPv4 address shortage, CPE costs, CGN costs, and so on.
固定オペレーターの場合、ほとんどのサービスプロバイダーネットワークですでに開始されたデュアルスタックをサポートするためのCPEの大規模なソフトウェアアップグレード。平均して、グローバル統計を見ると、IPv6のトラフィック率は現在約40％です[G_stats]。セクション3.2で強調されているように、すべての主要なコンテンツプロバイダーはすでにサービスへのデュアルスタックアクセスを実装しており、そのほとんどはデータセンターにIPv6のみを実装しています。この側面は、オペレーターのIPv6採用に関する決定に影響を与える可能性がありますが、現在のIPv4アドレスの不足、CPEコスト、CGNコストなど、他の要因もあります。
* Fixed operators with a Dual-Stack architecture can start defining and applying a new strategy when reaching the limit in terms of the number of IPv4 addresses available. This may be done through CGN or with an IPv4aaS approach.
* デュアルスタックアーキテクチャを備えた固定オペレーターは、利用可能なIPv4アドレスの数に関して制限に達すると、新しい戦略の定義と適用を開始できます。これは、CGNまたはIPV4AASアプローチを介して行うことができます。
* Most of the fixed operators remain attached to a Dual-Stack architecture, and many have already employed CGN. In this case, it is likely that CGN boosts their ability to supply IPv4 connectivity to CPEs for more years to come. Indeed, only few fixed operators have chosen to move to an IPv6-only scenario.
* 固定オペレーターのほとんどは、デュアルスタックアーキテクチャに取り付けられたままであり、多くはすでにCGNを採用しています。この場合、CGNは今後数年間、CPESにIPv4接続を供給する能力を高める可能性があります。実際、IPv6のみのシナリオに移行することを選択した固定演算子はわずかです。
For mobile operators, the situation is quite different, since in some cases, mobile operators are already stretching their IPv4 address space. The reason is that CGN translation limits have been reached and no more IPv4 public pool addresses are available.
モバイルオペレーターの場合、状況はまったく異なります。場合によっては、モバイルオペレーターがすでにIPv4アドレススペースを伸ばしているためです。その理由は、CGNの翻訳制限に達し、IPv4パブリックプールアドレスが利用できないためです。
* Some mobile operators choose to implement Dual-Stack as a first and immediate mitigation solution.
* 一部のモバイルオペレーターは、最初の即時緩和ソリューションとしてデュアルスタックを実装することを選択します。
* Other mobile operators prefer to move to IPv4aaS solutions (e.g., 464XLAT) since Dual-Stack only mitigates and does not solve the IPv4 address scarcity issue completely.
* 他のモバイルオペレーターは、デュアルスタックが緩和し、IPv4アドレスの希少性の問題を完全に解決しないため、IPv4AASソリューション（464XLATなど）に移動することを好みます。
For both fixed and mobile operators, the approach for the transition is not unique, and this brings different challenges in relation to the network architecture and related costs; therefore, each operator needs to do their own evaluations for the transition based on the specific situation.
固定オペレーターとモバイルオペレーターの両方にとって、移行のアプローチは一意ではなく、これはネットワークアーキテクチャと関連コストに関連してさまざまな課題をもたらします。したがって、各オペレーターは、特定の状況に基づいて移行に対して独自の評価を行う必要があります。
At present, the usage of IPv6 for enterprises often relies on upstream service providers, since the enterprise connectivity depends on the services provided by their upstream provider. Regarding the enterprises' internal infrastructures, IPv6 shows its advantages in the case of a merger and acquisition, because it can be avoided by the overlapping of the two address spaces, which is common in case of IPv4 private addresses. In addition, since several governments are introducing IPv6 policies, all the enterprises providing consulting services to governments are also required to support IPv6.
現在、エンタープライズの接続性はアップストリームプロバイダーが提供するサービスに依存するため、企業のIPv6の使用はしばしば上流のサービスプロバイダーに依存しています。企業の内部インフラストラクチャに関して、IPv6は合併と買収の場合に利点を示します。これは、IPv4プライベートアドレスの場合に一般的な2つのアドレススペースの重複によって回避できるためです。さらに、いくつかの政府がIPv6ポリシーを導入しているため、政府にコンサルティングサービスを提供するすべての企業もIPv6をサポートする必要があります。
However, enterprises face some challenges. They are shielded from IPv4 address depletion issues due to their prevalent use of proxy and private addressing [RFC1918]; thus, they do not have the business requirement or technical justification to transition to IPv6. Enterprises need to find a business case and a strong motivation to transition to IPv6 to justify additional CAPEX and OPEX. Also, since Information and Communication Technologies (ICTs) are not the core business for most of the enterprises, the ICT budget is often constrained and cannot expand considerably. However, there are examples of big enterprises that are considering IPv6 to achieve business targets through a more efficient IPv6 network and to introduce newer services that require IPv6 network architecture.
ただし、企業はいくつかの課題に直面しています。これらは、プロキシとプライベートアドレス指定の一般的な使用により、IPv4アドレスの枯渇の問題から保護されています[RFC1918]。したがって、IPv6に移行するためのビジネス要件や技術的正当化はありません。企業は、ビジネスケースとIPv6に移行するための強力な動機を見つける必要があります。また、情報通信技術（ICT）はほとんどの企業の中心的なビジネスではないため、ICT予算はしばしば制約され、かなり拡大することはできません。ただし、IPv6ネットワークを介してビジネス目標を達成し、IPv6ネットワークアーキテクチャを必要とする新しいサービスを導入するためにIPv6を検討している大企業の例があります。
Enterprises worldwide, in particular small- and medium-sized enterprises, are quite late to adopt IPv6, especially on internal networks. In most cases, the enterprise engineers and technicians do not have a great experience with IPv6, and the problem of application porting to IPv6 looks quite difficult. As highlighted in the relevant poll, the technicians may need to be trained, but the management does not see a business need for adoption. This creates an unfortunate cycle where the perceived complexity of the IPv6 protocol and concerns about security and manageability combine with the lack of urgent business needs to prevent adoption of IPv6. In 2019 and 2020, there has been a concerted effort by some ARIN and APNIC initiatives to provide training [ARIN-CG] [ISIF-ASIA-G].
世界中の企業、特に中小企業は、特に内部ネットワークでIPv6を採用するのに非常に遅れています。ほとんどの場合、エンタープライズエンジニアと技術者はIPv6で素晴らしい経験をしていません。IPv6へのアプリケーションの問題の問題は非常に困難です。関連する世論調査で強調されているように、技術者は訓練を受ける必要があるかもしれませんが、経営陣は養子縁組のビジネス上の必要性を見ていません。これにより、IPv6プロトコルの知覚された複雑さとセキュリティと管理性に関する懸念が、IPv6の採用を防ぐための緊急のビジネスのニーズの欠如と組み合わされる不幸なサイクルが作成されます。2019年と2020年には、トレーニング[ARIN-CG] [ISIF-ASIA-G]を提供するために、アリンと無呼吸のイニシアチブによる協調的な努力がありました。
In an industrial environment, Operational Technology (OT) refers to the systems used to monitor and control processes within a factory or production environment, while Information Technology (IT) refers to anything related to computer technology and networking connectivity. IPv6 is frequently mentioned in relation to Industry 4.0 and the Internet of Things (IoT), affecting the evolution of both OT and IT.
産業環境では、運用技術（OT）とは、工場または生産環境内のプロセスを監視および制御するために使用されるシステムを指し、情報技術（IT）はコンピューターテクノロジーとネットワーキングの接続性に関連するものを指します。IPv6は、Industry 4.0とモノのインターネット（IoT）に関連して頻繁に言及されており、OTとITの両方の進化に影響します。
There are potential advantages for using IPv6 for the Industrial Internet of Things (IIoT), in particular, the large IPv6 address space, the automatic IPv6 address configuration, and resource discovery. However, its industrial adoption, in particular, in smart manufacturing systems, has been much slower than expected. There are still many obstacles and challenges that prevent its pervasive use. The key problems identified are the incomplete or underdeveloped tool support, the dependency on manual configuration, and the poor knowledge of the IPv6 protocols. To promote the use of IPv6 for smart manufacturing systems and IIoT applications, a generic approach to remove these pain points is highly desirable. Indeed, as for enterprises, it is important to provide an easy way to familiarize system architects and software developers with the IPv6 protocol.
IPv6を産業用インターネットのインターネット（IIOT）に使用することには潜在的な利点があります。特に、大規模なIPv6アドレス空間、自動IPv6アドレス構成、およびリソース発見があります。ただし、特にスマートマニュファクチャリングシステムでの産業採用は、予想よりもはるかに遅くなっています。その広範な使用を妨げる多くの障害と課題がまだあります。特定された重要な問題は、不完全または未開発のツールサポート、手動構成への依存性、およびIPv6プロトコルの知識が不十分です。Smart Manufacturing SystemsおよびIIOTアプリケーションにIPv6の使用を促進するには、これらの問題点を削除する一般的なアプローチが非常に望ましいです。実際、企業に関しては、IPv6プロトコルでシステムアーキテクトやソフトウェア開発者を簡単に慣れる簡単な方法を提供することが重要です。
Advances in cloud-based platforms and developments in artificial intelligence (AI) and machine learning (ML) allow OT and IT systems to integrate and migrate to a centralized analytical, processing, and integrated platform, which must act in real time. The limitation is that manufacturing companies have diverse corporate cultures, and the adoption of new technologies may lag as a result.
クラウドベースのプラットフォームの進歩と人工知能（AI）および機械学習（ML）の開発により、OTおよびITシステムは、リアルタイムで動作する必要がある集中分析、処理、および統合プラットフォームに統合および移行できます。制限は、製造会社には多様な企業文化があり、その結果、新しいテクノロジーの採用が遅れる可能性があることです。
For Industrial Internet and related IIoT applications, it would be desirable to leverage the configurationless characteristic of IPv6 to automatically manage and control the IoT devices. In addition, it could be interesting to have the ability to use IP-based communication and standard application protocols at every point in the production process and further reduce the use of specialized communication systems.
産業用インターネットおよび関連するIIOTアプリケーションの場合、IPv6の構成レス特性を活用して、IoTデバイスを自動的に管理および制御することが望ましいでしょう。さらに、生産プロセスのあらゆるポイントでIPベースの通信と標準アプリケーションプロトコルを使用し、特殊な通信システムの使用をさらに削減できることは興味深いかもしれません。
The high number of addresses required to connect the virtual and physical elements in a Data Center and the necessity to overcome the limitation posed by [RFC1918] have been the drivers to the adoption of IPv6 in several CSP networks.
データセンターの仮想要素と物理的要素を接続するために必要な多くのアドレスと、[RFC1918]によってもたらされる制限を克服する必要性は、いくつかのCSPネットワークでIPv6の採用の要因となっています。
Most CSPs have adopted IPv6 in their internal infrastructure but are also active in gathering IPv4 addresses on the transfer market to serve the current business needs of IPv4 connectivity. As noted in the previous section, most enterprises do not consider the transition to IPv6 as a priority. To this extent, the use of IPv4-based network services by the CSPs will last.
ほとんどのCSPは、内部インフラストラクチャでIPv6を採用していますが、IPv4接続の現在のビジネスニーズに応えるために、転送市場にIPv4アドレスを収集する際にも積極的です。前のセクションで述べたように、ほとんどの企業はIPv6への移行を優先事項とは考えていません。この程度まで、CSPSによるIPv4ベースのネットワークサービスの使用は続きます。
Several public references, as reported hereinafter, discuss how most of the major players find themselves at different stages in the transition to IPv6-only in their Data Center (DC) infrastructure. In some cases, the transition already happened and the DC infrastructure of these hyperscalers is completely based on IPv6.
以下に報告されているように、いくつかの公開参照は、データセンター（DC）インフラストラクチャのIPv6のみへの移行において、ほとんどの主要なプレーヤーがどのように自分自身をさまざまな段階で見つけているかを議論します。場合によっては、遷移がすでに発生し、これらのハイパースケーラーのDCインフラストラクチャは完全にIPv6に基づいています。
It is interesting to look at how much traffic in a network is going to Caches and Content Delivery Networks (CDNs). The response is expected to be a high percentage, at least higher than 50% in most of the cases, since all the key Caches and CDNs are ready for IPv6 [Cldflr] [Ggl] [Ntflx] [Amzn] [Mcrsft]. So the percentage of traffic going to the key Caches/CDNs is a good approximation of the potential IPv6 traffic in a network.
ネットワーク内のトラフィックがキャッシュやコンテンツ配信ネットワーク（CDN）にどれだけのトラフィックが行われるかを見るのは興味深いことです。すべての主要なキャッシュとCDNがIPv6 [Cldflr] [GGL] [NTFLX] [AMZN] [MCRSFT]の準備ができているため、ほとんどの場合、ほとんどの場合、ほとんどの場合50％を超える割合が高いと予想されます。したがって、主要なキャッシュ/CDNSに行くトラフィックの割合は、ネットワーク内の潜在的なIPv6トラフィックの適切な近似です。
The challenges for CSPs are mainly related to the continuous support of IPv4 to be guaranteed, since most CSPs already completed the transition to IPv6-only. If, in the next years, the scarcity of IPv4 addresses becomes more evident, it is likely that the cost of buying an IPv4 address by a CSP could be charged to their customers.
CSPの課題は、ほとんどのCSPがすでにIPv6のみへの移行を完了したため、主にIPv4の継続的なサポートに関連しています。次の年に、IPv4アドレスの希少性がより明白になった場合、CSPでIPv4アドレスを購入するコストが顧客に請求される可能性があります。
It can be noted that most of the user devices (e.g., smartphones) have been IPv6 enabled for many years. But there are exceptions, for example, for the past few years, smart TVs have typically had IPv6 support; however, not all the economies replace them at the same pace.
ほとんどのユーザーデバイス（スマートフォンなど）のほとんどは、長年にわたってIPv6が有効になっていることに注意してください。しかし、例外がありますが、たとえば、過去数年間、スマートテレビには通常IPv6のサポートがありました。ただし、すべての経済が同じペースでそれらを置き換えるわけではありません。
As already mentioned, ISPs who historically provided public IPv4 addresses to their customers generally still have those IPv4 addresses (unless they chose to transfer them). Some have chosen to put new customers on CGN but without touching existing customers. Because of the extremely small number of customers who notice that IPv4 is done via NAT444 (i.e., the preferred CGN solution for carriers), it could be less likely to run out of IPv4 addresses and private IPv4 space. But as IPv4-only devices and traffic reduce, the need to support private and public IPv4 lessens. So to have CPEs completely support IPv6 serves as an important challenge and incentive to choose IPv4aaS solutions [ANSI] over Dual-Stack.
すでに述べたように、歴史的に顧客にパブリックIPv4アドレスを提供していたISPは、通常、それらのIPv4アドレスをまだ持っています（それらを転送することを選択しない限り）。一部の人々は、既存の顧客に触れることなく、新しい顧客をCGNに配置することを選択しました。IPv4がNAT444を介して行われていることに気づいた顧客の数が非常に少ないため（つまり、キャリア向けの優先CGNソリューション）、IPv4アドレスとプライベートIPv4スペースを使い果たす可能性は低くなります。しかし、IPv4のみのデバイスとトラフィックが減少するにつれて、プライベートおよびパブリックのIPv4をサポートする必要性が低下します。したがって、CPEが完全にサポートすることは、IPv6がデュアルスタックよりもIPv4AASソリューション[ANSI]を選択するための重要な課題とインセンティブとして機能します。
The transition to IPv6 requires that the application software is adapted for use in IPv6-based networks ([ARIN-SW] provides an example). The use of transition mechanisms like 464XLAT is essential to support IPv4-only applications while they evolve to IPv6. Depending on the transition mechanism employed, some issues may remain. For example, in the case of NAT64/DNS64, the use of literal IPv4 addresses, instead of DNS names, will fail unless mechanisms such as Application Level Gateways (ALGs) are used. This issue is not present in 464XLAT (see [RFC8683]).
IPv6への移行では、アプリケーションソフトウェアがIPv6ベースのネットワークで使用するために適合する必要があります（[Arin-SW]が例を提供します）。464XLATのような遷移メカニズムの使用は、IPv4に進化している間にIPv4のみのアプリケーションをサポートするために不可欠です。採用されている遷移メカニズムに応じて、いくつかの問題が残っている可能性があります。たとえば、NAT64/DNS64の場合、DNS名の代わりにリテラルIPv4アドレスの使用は、アプリケーションレベルゲートウェイ（ALG）などのメカニズムを使用しない限り故障します。この問題は464xlatには存在しません（[RFC8683]を参照）。
It is worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect of application transition to IPv6.
Happy Eyeballs [RFC8305]をIPv6へのアプリケーションの移行の関連する側面として言及する価値があります。
There are important IPv6 complementary solutions related to Operations, Administration, and Maintenance (OAM) that look less mature compared to IPv4. A Network Management System (NMS) has a central role in the modern networks for both network operators and enterprises, and its transition is a fundamental issue. This is because some IPv6 products are not as field proven as IPv4 products, even if conventional protocols (e.g., SNMP and RADIUS) already support IPv6. In addition, an incompatible vendor road map for the development of new NMS features affects the confidence of network operators or enterprises.
IPv4と比較して成熟度が低いように見える運用、管理、およびメンテナンス（OAM）に関連する重要なIPv6補完ソリューションがあります。ネットワーク管理システム（NMS）は、ネットワークオペレーターと企業の両方の最新のネットワークで中心的な役割を果たしており、その移行は基本的な問題です。これは、従来のプロトコル（SNMPやRadiusなど）がすでにIPv6をサポートしている場合でも、一部のIPv6製品はIPv4製品ほどフィールド証明されていないためです。さらに、新しいNMS機能を開発するための互換性のないベンダーロードマップは、ネットワークオペレーターまたは企業の信頼に影響します。
An important factor is represented by the need for training the network operations workforce. Deploying IPv6 requires that policies and procedures have to be adjusted in order to successfully plan and complete an IPv6 transition. Staff has to be aware of the best practices for managing IPv4 and IPv6 assets. In addition to network nodes, network management applications and equipment need to be properly configured and, in some cases, also replaced. This may introduce more complexity and costs for the transition.
重要な要素は、ネットワーク運用労働力をトレーニングする必要性によって表されます。IPv6を展開するには、IPv6遷移を正常に計画および完了するために、ポリシーと手順を調整する必要があります。スタッフは、IPv4およびIPv6アセットを管理するためのベストプラクティスに注意する必要があります。ネットワークノードに加えて、ネットワーク管理アプリケーションと機器を適切に構成し、場合によっては交換する必要があります。これにより、移行のためのより複雑さとコストが導入される場合があります。
Availability of both systems and training is necessary in areas such as IPv6 addressing. IPv6 addresses can be assigned to an interface through different means, such as Stateless Auto-Configuration (SLAAC) [RFC4862], or by using the stateful Dynamic Host Configuration Protocol (DHCP) [RFC8415]. IP Address Management (IPAM) systems may contribute by handling the technical differences and automating some of the configuration tasks, such as the address assignment or the management of DHCP services.
IPv6アドレス指定などの分野では、システムとトレーニングの両方の可用性が必要です。IPv6アドレスは、Stateless Auto Configuration（SLAAC）[RFC4862]などのさまざまな手段を介してインターフェイスに割り当てることができます。IPアドレス管理（IPAM）システムは、技術的な違いを処理し、アドレスの割り当てやDHCPサービスの管理などの構成タスクの一部を自動化することで貢献する場合があります。
People tend to compare the performance of IPv6 versus IPv4 to argue or motivate the IPv6 transition. In some cases, IPv6 behaving "worse" than IPv4 may be used as an argument for avoiding the full adoption of IPv6. However, there are some aspects where IPv6 has already filled (or is filling) the gap to IPv4. This position is supported when looking at available analytics on two critical parameters: packet loss and latency. These parameters have been constantly monitored over time, but only a few comprehensive measurement campaigns are providing up-to-date information. While performance is undoubtedly an important issue to consider and worth further investigation, the reality is that a definitive answer cannot be found on what IP version performs better. Depending on the specific use case and application, IPv6 is better; in others, the same applies to IPv4.
人々は、IPv6とIPv4のパフォーマンスを比較して、IPv6遷移を議論または動機付けする傾向があります。場合によっては、IPv4の完全な採用を回避するための議論として、IPv4よりも「悪い」動作をしているIPv6が使用される場合があります。ただし、IPv6がIPv4とのギャップを既に埋めている（または埋めている）いくつかの側面があります。この位置は、パケットの損失とレイテンシという2つの重要なパラメーターで利用可能な分析を調べるときにサポートされています。これらのパラメーターは時間の経過とともに常に監視されていますが、最新の情報を提供している包括的な測定キャンペーンはわずかです。パフォーマンスは間違いなく考慮すべき重要な問題であり、さらなる調査に値する重要な問題ですが、現実には、どのようなIPバージョンがパフォーマンスを発揮するかについて決定的な答えが見つからないということです。特定のユースケースとアプリケーションに応じて、IPv6の方が優れています。その他では、IPv4にも同じことが当てはまります。
[APNIC5] provides a measurement of both the failure rate and Round-Trip Time (RTT) of IPv6 compared against IPv4. Both measures are based on scripts that employ the three-way handshake of TCP. As such, the measurement of the failure rate does not provide a direct measurement of packet loss (which would need an Internet-wide measurement campaign). That said, despite that IPv4 is still performing better, the difference seems to have decreased in recent years. Two reports, namely [RIPE1] and [APRICOT], discussed the associated trend, showing how the average worldwide failure rate of IPv6 is still a bit worse than IPv4. Reasons for this effect may be found in endpoints with an unreachable IPv6 address, routing instability, or firewall behavior. Yet, this worsening effect may appear as disturbing for a plain transition to IPv6.
[APNIC5]は、IPv4と比較したIPv6の故障率と往復時間（RTT）の両方の測定を提供します。両方の測定値は、TCPの3方向の握手を使用するスクリプトに基づいています。そのため、故障率の測定では、パケット損失の直接測定値は提供されません（インターネット全体の測定キャンペーンが必要です）。とはいえ、IPv4はまだパフォーマンスが向上しているにもかかわらず、近年違いが減少しているようです。2つのレポート、つまり[Ripe1]と[Apricot]は、関連する傾向について議論し、IPv6の平均世界の故障率がIPv4よりも少し悪い方法を示しています。この効果の理由は、到達不可能なIPv6アドレス、ルーティング不安定性、またはファイアウォールの動作を備えたエンドポイントにあります。しかし、この悪化効果は、IPv6への単純な移行のために邪魔になるように見えるかもしれません。
[APNIC5] also compares the latency of both address families. Currently, the worldwide average is slightly in favor of IPv6. Zooming at the country or even at the operator level, it is possible to get more detailed information and appreciate that cases exist where IPv6 is faster than IPv4. Regions (e.g., Western Europe, Northern America, and Southern Asia) and countries (e.g., US, India, and Germany) with an advanced deployment of IPv6 (e.g., greater than 45%) are showing that IPv6 has better performance than IPv4. [APRICOT] highlights how when a difference in performance exists, it is often related to asymmetric routing issues. Other possible explanations for a relative latency difference relate to the specificity of the IPv6 header, which allows packet fragmentation. In turn, this means that hardware needs to spend cycles to analyze all of the header sections, and when it is not capable of handling one of them, it drops the packet. A few measurement campaigns on the behavior of IPv6 in CDNs are also available [MAPRG] [INFOCOM]. The TCP connection time is still higher for IPv6 in both cases, even if the gap has reduced over the analysis time window.
[APNIC5]は、両方のアドレスファミリの遅延も比較します。現在、世界の平均はIPv6をわずかに支持しています。国またはオペレーターレベルでズームすると、より詳細な情報を取得し、IPv6がIPv4よりも速い場合にケースが存在することを理解することができます。IPv6の高度な展開（45％を超える）を備えた地域（例：西ヨーロッパ、北アメリカ、南アジア）および国（例：米国、インド、ドイツ）は、IPv6がIPv4よりも優れたパフォーマンスを持っていることを示しています。[Apricot]は、パフォーマンスの違いが存在するときに、しばしば非対称ルーティングの問題に関連していることを強調しています。相対的な潜時の違いについての他の考えられる説明は、パケットの断片化を可能にするIPv6ヘッダーの特異性に関連しています。これは、すべてのヘッダーセクションを分析するためにハードウェアを使用する必要があることを意味し、そのうちの1つを処理できない場合、パケットをドロップします。CDNでのIPv6の動作に関するいくつかの測定キャンペーンも利用可能です[MAPRG] [InfoCom]。どちらの場合も、IPv6のTCP接続時間は、分析時間ウィンドウでギャップが減少した場合でも、さらに高いです。
It is not totally clear if the customer experience is in some way perceived as better when IPv6 is used instead of IPv4. In some cases, it has been publicly reported by IPv6 content providers that users have a better experience when using IPv6-only compared to IPv4 [ISOC2]. This could be explained because, in the case of an IPv6 user connecting to an application hosted in an IPv6-only Data Center, the connection is end to end, without translations. Instead, when using IPv4, there is a NAT translation either in the CPE or in the service provider's network, in addition to IPv4 to IPv6 (and back to IPv4) translation in the IPv6-only content provider Data Center. [ISOC2] and [FB] provide reasons in favor of IPv6. In other cases, the result seems to be still slightly in favor of IPv4 [INFOCOM] [MAPRG], even if the difference between IPv4 and IPv6 tends to vanish over time.
IPv4の代わりにIPv6を使用する場合、カスタマーエクスペリエンスが何らかの方法でより良いと認識されているかどうかは完全には明らかではありません。場合によっては、IPv6コンテンツプロバイダーによって、IPv4のみを使用する場合、ユーザーはIPv4 [ISOC2]と比較してより良い経験を積むことが公開されています。これは、IPv6のみのデータセンターでホストされているアプリケーションに接続するIPv6ユーザーの場合、接続が翻訳なしで端から端までであるためです。代わりに、IPv4を使用する場合、IPv4からIPv6（およびIPv4に戻る）翻訳に加えて、CPEまたはサービスプロバイダーのネットワークのいずれかにNAT翻訳があります。[ISOC2]および[FB]は、IPv6を支持する理由を提供します。それ以外の場合、結果は、IPv4とIPv6の違いが時間とともに消える傾向がある場合でも、IPv4 [infocom] [maprg]をわずかに有利にしているようです。
An important point that is sometimes considered as a challenge when discussing the transition to IPv6 is related to the security and privacy. [RFC9099] analyzes the operational security issues in several places of a network (enterprises, service providers, and residential users). It is also worth considering the additional security issues brought by the applied IPv6 transition technologies used to implement IPv4aaS (e.g., 464XLAT and DS-Lite) [ComputSecur].
IPv6への移行を議論する際に課題と見なされる重要なポイントは、セキュリティとプライバシーに関連しています。[RFC9099]は、ネットワークのいくつかの場所（エンタープライズ、サービスプロバイダー、住宅ユーザー）の運用セキュリティ問題を分析します。また、IPv4aaS（464xlatやDS-Liteなど）を実装するために使用されるApplied IPv6トランジションテクノロジーによってもたらされる追加のセキュリティ問題を考慮する価値があります[ComputSecur]。
The security aspects have to be considered to keep at least the same, or even a better, level of security as it exists nowadays in an IPv4 network environment. The autoconfiguration features of IPv6 will require some more attention. Router discovery and address autoconfiguration may produce unexpected results and security holes. IPsec protects IPv6 traffic at least as well as it does IPv4, and the security protocols for constrained devices (IoT) are designed for IPv6 operation.
セキュリティの側面は、IPv4ネットワーク環境に最近存在するため、少なくとも同じ、またはより良いレベルのセキュリティを維持するために考慮される必要があります。IPv6の自動構成機能には、さらに注意が必要です。ルーターの発見とアドレスの自動構成は、予期しない結果とセキュリティ穴を引き起こす可能性があります。IPSECは、IPv4と同様にIPv6トラフィックを保護し、IPv4のセキュリティプロトコル（IoT）のセキュリティプロトコルはIPv6操作用に設計されています。
IPv6 was designed to restore the end-to-end model of communications with all nodes on networks using globally unique addresses. But considering this, IPv6 may imply privacy concerns due to greater visibility on the Internet. IPv6 nodes can (and typically do) use privacy extensions [RFC8981] to prevent any tracking of their burned-in Media Access Control (MAC) address(es), which are easily readable in the original modified 64-bit Extended Unique Identifier (EUI-64) interface identifier format. On the other hand, stable IPv6 interface identifiers [RFC8064] were developed, and this can also affect privacy.
IPv6は、グローバルに一意のアドレスを使用して、ネットワーク上のすべてのノードとの通信のエンドツーエンドモデルを復元するように設計されています。しかし、これを考慮すると、IPv6はインターネット上の可視性が高いため、プライバシーの懸念を暗示する可能性があります。IPv6ノードは、プライバシー拡張機能[RFC8981]を使用して、バーンインメディアアクセス制御（MAC）アドレス（ES）の追跡を防ぐことができます。-64）インターフェイス識別子形式。一方、安定したIPv6インターフェイス識別子[RFC8064]が開発され、これもプライバシーに影響を与える可能性があります。
As reported in [ISOC3], in comparing IPv6 and IPv4 at the protocol level, one may probably conclude that the increased complexity of IPv6 will result in an increased number of attack vectors that imply more possible ways to perform different types of attacks. However, a more interesting and practical question is how IPv6 deployments compare to IPv4 deployments in terms of security. In that sense, there are a number of aspects to consider.
[ISOC3]で報告されているように、プロトコルレベルでIPv6とIPv4を比較する際に、IPv6の複雑さの増加により、さまざまなタイプの攻撃を実行する可能性のある方法を暗示する攻撃ベクターの数が増えると結論付ける可能性があります。ただし、より興味深い実用的な質問は、IPv6の展開がセキュリティの観点からIPv4の展開と比較する方法です。その意味で、考慮すべき多くの側面があります。
Most security vulnerabilities related to network protocols are based on implementation flaws. Typically, security researchers find vulnerabilities in protocol implementations, which eventually are "patched" to mitigate such vulnerabilities. Over time, this process of finding and patching vulnerabilities results in more robust implementations. For obvious reasons, the IPv4 protocols have benefited from the work of security researchers for much longer, and thus IPv4 implementations are generally more robust than IPv6. However, with more IPv6 deployment, IPv6 will also benefit from this process in the long run. It is also worth mentioning that most vulnerabilities nowadays are caused by human beings and are in the application layer, not the IP layer.
ネットワークプロトコルに関連するほとんどのセキュリティの脆弱性は、実装の欠陥に基づいています。通常、セキュリティ研究者は、プロトコルの実装の脆弱性を見つけ、最終的にはそのような脆弱性を軽減するために「パッチが適用されます」。時間が経つにつれて、この脆弱性を見つけてパッチするプロセスは、より堅牢な実装をもたらします。明らかな理由で、IPv4プロトコルはセキュリティ研究者の仕事の恩恵を受けてきたため、一般にIPv4の実装はIPv6よりも堅牢です。ただし、IPv6の展開が増えると、IPv6も長期的にはこのプロセスの恩恵を受けます。また、今日のほとんどの脆弱性は人間によって引き起こされ、IP層ではなくアプリケーション層にあることに言及する価値があります。
Besides the intrinsic properties of the protocols, the security level of the resulting deployments is closely related to the level of expertise of network and security engineers. In that sense, there is obviously much more experience and confidence with deploying and operating IPv4 networks than with deploying and operating IPv6 networks.
プロトコルの固有のプロパティに加えて、結果として生じる展開のセキュリティレベルは、ネットワークおよびセキュリティエンジニアの専門知識のレベルと密接に関連しています。その意味で、IPv4ネットワークの展開と操作よりも、IPv4ネットワークの展開と運用の展開と運用の経験と自信がはるかに多く、自信があります。
In general, there are security concerns related to IPv6 that can be classified as follows:
一般に、次のように分類できるIPv6に関連するセキュリティ上の懸念があります。
* Basic IPv6 protocol (basic header, extension headers, addressing)
* 基本的なIPv6プロトコル（基本ヘッダー、拡張ヘッダー、アドレス指定）
* IPv6-associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)
* IPv6関連プロトコル（ICMPV6、NDP、MLD、DNS、DHCPV6）
* Internet-wide IPv6 security (filtering, DDoS, transition mechanisms)
* インターネット全体のIPv6セキュリティ（フィルタリング、DDO、遷移メカニズム）
ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions. The Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6, which replaces and enhances functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like how the Internet Group Management Protocol (IGMP) is used in IPv4.
ICMPV6はIPv6の不可欠な部分であり、エラー報告および診断機能を実行します。Neighbor Discovery Protocol（NDP）は、IPv6のノードディスカバリープロトコルであり、ARPの機能を置き換えて強化します。マルチキャストリスナーディスカバリー（MLD）は、IPv4ルーターがIPv4で使用する方法と同様に、直接添付のリンクでマルチキャストリスナーを発見するために使用されます。
These IPv6-associated protocols, like ICMPv6, NDP, and MLD, are something new compared to IPv4, so they add new security threats and the related solutions are still under discussion today. NDP has vulnerabilities [RFC3756] [RFC6583]. [RFC3756] says to use IPsec, but it is impractical and not used; on the other hand, SEcure Neighbor Discovery (SEND) [RFC3971] is not widely available. It is worth mentioning that applying host isolation may address many of these concerns, as described in [ND-CONSIDERATIONS].
ICMPV6、NDP、MLDなどのこれらのIPv6関連プロトコルは、IPv4と比較して新しいものであるため、新しいセキュリティの脅威を追加し、関連するソリューションは現在も議論中です。NDPには脆弱性があります[RFC3756] [RFC6583]。[RFC3756]はIPSECを使用すると言っていますが、それは非現実的であり、使用されていません。一方、Secure Neighbor Discovery（SEND）[RFC3971]は広く利用できません。[ND考慮]で説明されているように、ホストの分離を適用することは、これらの懸念の多くに対処する可能性があることに言及する価値があります。
[RIPE2] describes the most important threats and solutions regarding IPv6 security.
[Ripe2]は、IPv6セキュリティに関する最も重要な脅威と解決策を説明しています。
IPv6 extension headers provide a hook for interesting new features to be added and are more flexible than IPv4 options. This does add some complexity. In particular, some security mechanisms may require processing the full chain of headers, and some firewalls may require filtering packets based on their extension headers. Additionally, packets with IPv6 extension headers may be dropped in the public Internet [RFC7872]. Some documents, e.g., [HBH-PROCESSING], [HBH-OPT-HDR], and [IPv6-EXT-HDR], analyze and provide guidance regarding the processing procedures of IPv6 extension headers.
IPv6拡張ヘッダーは、興味深い新機能を追加するためのフックを提供し、IPv4オプションよりも柔軟性があります。これにより、複雑さが追加されます。特に、一部のセキュリティメカニズムでは、ヘッダーの完全なチェーンを処理する必要がある場合があり、一部のファイアウォールでは、拡張ヘッダーに基づいてフィルタリングパケットが必要になる場合があります。さらに、IPv6拡張ヘッダーを備えたパケットは、パブリックインターネット[RFC7872]で削除される場合があります。いくつかのドキュメント、たとえば[HBH処理]、[HBH-OPT-HDR]、および[IPv6-Ext-HDR]は、IPv6拡張ヘッダーの処理手順に関するガイダンスを分析および提供します。
Defense against possible attacks through extension headers is necessary. For example, the original IPv6 Routing Header type 0 (RH0) was deprecated because of possible remote traffic amplification [RFC5095]. In addition, it is worth mentioning that the unrecognized Hop-by-Hop Options Header and Destination Options Header will not be considered by the nodes if they are not configured to deal with it [RFC8200]. Other attacks based on extension headers may be based on IPv6 header chains and fragmentation that could be used to bypass filtering. To mitigate this effect, the initial IPv6 header, the extension headers, and the upper-layer header must all be in the first fragment [RFC8200]. Also, the use of the IPv6 fragment header is forbidden in all Neighbor Discovery messages [RFC6980].
拡張ヘッダーによる可能な攻撃に対する防御が必要です。たとえば、リモートトラフィック増幅の可能性があるため、元のIPv6ルーティングヘッダータイプ0（RH0）は非推奨でした[RFC5095]。さらに、認識されていないホップバイホップオプションヘッダーと宛先オプションヘッダーが、それを扱うように構成されていない場合、ノードによって考慮されないことを言及する価値があります[RFC8200]。拡張ヘッダーに基づく他の攻撃は、フィルタリングをバイパスするために使用できるIPv6ヘッダーチェーンと断片化に基づいている場合があります。この効果を軽減するには、初期のIPv6ヘッダー、拡張ヘッダー、および上層ヘッダーはすべて最初のフラグメント[RFC8200]にある必要があります。また、IPv6フラグメントヘッダーの使用は、すべての近隣発見メッセージ[RFC6980]で禁止されています。
The fragment header is used by the IPv6 source node to send a packet bigger than the path MTU, and the destination host processes fragment headers. There are several threats related to fragmentation to pay attention to, e.g., overlapping fragments (not allowed), resource consumption while waiting for the last fragment (to discard), and atomic fragments (to be isolated).
フラグメントヘッダーは、IPv6ソースノードによって使用され、パスMTUよりも大きなパケットを送信し、宛先ホストはフラグメントヘッダーを処理します。断片化に関連するいくつかの脅威があります。たとえば、フラグメント（許可されていない）、最後のフラグメント（廃棄するため）、および原子フラグメント（分離する）を待っている間のリソースの消費。
The operational implications of IPv6 packets with extension headers are further discussed in [RFC9098].
IPv6パケットの拡張ヘッダーによる運用上の意味については、[RFC9098]でさらに説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document has no impact on the security properties of specific IPv6 protocols or transition tools. In addition to the discussion above in Section 5.4, the security considerations relating to the protocols and transition tools are described in the relevant documents.
このドキュメントは、特定のIPv6プロトコルまたは遷移ツールのセキュリティプロパティに影響を与えません。上記のセクション5.4の議論に加えて、プロトコルと遷移ツールに関連するセキュリティ上の考慮事項については、関連するドキュメントで説明されています。
[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>.
[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 survey was proposed to more than 50 service providers in the European region during the third quarter of 2020 to ask for their plans on IPv6 and the status of IPv6 deployment.
2020年の第3四半期にヨーロッパ地域の50を超えるサービスプロバイダーに調査が提案され、IPv6に関する計画とIPv6展開のステータスを求めました。
In this survey, 40 people, representing 38 organizations, provided responses. This appendix summarizes the results obtained.
この調査では、38の組織を代表する40人が回答を提供しました。この付録は、得られた結果をまとめたものです。
Respondents' business:
回答者のビジネス：
+============+========+=======+
| Convergent | Mobile | Fixed |
+============+========+=======+
| 82% | 8% | 11% |
+------------+--------+-------+
Table 10: Type of Operators
表10：オペレーターのタイプ
Question 1. Do you have plans to move more fixed, mobile, or enterprise users to IPv6 in the next 2 years?
質問1.今後2年間で、より固定、モバイル、またはエンタープライズユーザーをIPv6に移す計画はありますか？
A. If so, fixed, mobile, or enterprise?
A.もしそうなら、固定、モバイル、またはエンタープライズ？
B. What are the reasons to do so?
B.そうする理由は何ですか？
C. When to start: already ongoing, in 12 months, or after 12 months?
C.開始する時期：すでに継続的、12か月後、または12か月後？
D. Which transition solution will you use: Dual-Stack, DS-Lite, 464XLAT, or MAP-T/E?
D.デュアルスタック、DS-Lite、464XLAT、またはMAP-T/Eのどの遷移ソリューションを使用しますか？
Answers for 1.A (38 respondents)
1.Aの回答（38人の回答者）
+=====+=====+
| Yes | No |
+=====+=====+
| 79% | 21% |
+-----+-----+
Table 11: Plan to Move to IPv6 within 2 Years
表11：2年以内にIPv6に移動する計画
+========+=======+============+=============+
| Mobile | Fixed | Enterprise | No Response |
+========+=======+============+=============+
| 63% | 63% | 50% | 3% |
+--------+-------+------------+-------------+
Table 12: Business Segment
表12：ビジネスセグメント
Answers for 1.B (29 respondents)
1.B（29人の回答者）の回答
Even though this was an open question, some common answers can be found.
これは未解決の質問でしたが、いくつかの一般的な答えが見つかります。
* 14 respondents (48%) highlighted issues related to IPv4 depletion. The reason to move to IPv6 is to avoid private and/or overlapping addresses.
* 14人の回答者（48％）は、IPv4の枯渇に関連する問題を強調しました。IPv6に移動する理由は、プライベートおよび/または重複するアドレスを避けるためです。
* 6 respondents (20%) stated that 5G/IoT is a business incentive to introduce IPv6.
* 6人の回答者（20％）は、5G/IoTがIPv6を導入するビジネスインセンティブであると述べました。
* 4 respondents (13%) highlighted that there is a national regulation request to associate and enable IPv6 with the launch of 5G.
* 4人の回答者（13％）は、5Gの発売にIPv6を関連付けて有効にするという全国規制要求があることを強調しました。
* 4 respondents (13%) considered IPv6 as a part of their innovation strategy or an enabler for new services.
* 4人の回答者（13％）は、IPv6をイノベーション戦略の一部または新しいサービスのイネーブラーと見なしました。
* 4 respondents (13%) introduced IPv6 because of enterprise customer demand.
* 4人の回答者（13％）は、エンタープライズの顧客需要のためにIPv6を導入しました。
Answers for 1.C (30 respondents)
1.Cの回答（30人の回答者）
+=========+==============+=================+=============+
| Ongoing | In 12 months | After 12 months | No Response |
+=========+==============+=================+=============+
| 60% | 33% | 0% | 7% |
+---------+--------------+-----------------+-------------+
Table 13: Timeframe
表13：時間枠
Answers for 1.D (28 respondents for cellular, 27 for wireline)
1.Dの回答（Cellularの28人の回答者、有線の27人）
+============+=========+=======+=============+
| Dual-Stack | 464XLAT | MAP-T | No Response |
+============+=========+=======+=============+
| 39% | 21% | 4% | 36% |
+------------+---------+-------+-------------+
Table 14: Transition in Use: Cellular
表14：使用中の遷移：セルラー
+============+=========+==========+=============+
| Dual-Stack | DS-Lite | 6RD/6VPE | No Response |
+============+=========+==========+=============+
| 59% | 19% | 4% | 19% |
+------------+---------+----------+-------------+
Table 15: Transition in Use: Wireline
表15：使用中の遷移：有線
Question 2. Do you need to change network devices for the above goal?
質問2.上記の目標のためにネットワークデバイスを変更する必要がありますか？
A. If yes, what kind of devices: CPE, BNG/mobile core, or NAT?
A.はいの場合、どのようなデバイス：CPE、BNG/Mobile Core、またはNAT？
B. Will you start the transition of your metro, backbone, or backhaul network to support IPv6?
B. IPv6をサポートするために、メトロ、バックボーン、またはバックホールネットワークの移行を開始しますか？
Answers for 2.A (30 respondents)
2.Aの回答（30人の回答者）
+=====+=====+=============+
| Yes | No | No Response |
+=====+=====+=============+
| 43% | 33% | 23% |
+-----+-----+-------------+
Table 16: Need to Change
表16：変更する必要があります
+======+=========+=====+=====+=============+
| CPEs | Routers | BNG | CGN | Mobile core |
+======+=========+=====+=====+=============+
| 47% | 27% | 20% | 33% | 27% |
+------+---------+-----+-----+-------------+
Table 17: What to Change
表17：何を変更するか
Answers for 2.B (22 respondents)
2.Bの回答（22人の回答者）
+=====+========+=====+
| Yes | Future | No |
+=====+========+=====+
| 9% | 9% | 82% |
+-----+--------+-----+
Table 18: Plans for Transition
表18：移行の計画
The Industry Network Technology Council (INTC) developed the following poll to verify the need or willingness of medium-to-large US-based enterprises for training and consultancy on IPv6 <https://industrynetcouncil.org/> in early 2021.
業界ネットワークテクノロジーカウンシル（INTC）は、2021年初頭にIPv6 <https://industrynetcouncil.org/>のトレーニングとコンサルティングのための中程度の米国に拠点を置く企業の必要性または意欲を検証するために、以下の世論調査を開発しました。
54 organizations provided answers.
54の組織が回答を提供しました。
Question 1. How much IPv6 implementation have you done at your organization? (54 respondents)
質問1.組織でどのくらいのIPv6の実装をしましたか？（54人の回答者）
+-------------------------------------------------+--------+
| None | 16.67% |
+-------------------------------------------------+--------+
| Some people have gotten some training | 16.67% |
+-------------------------------------------------+--------+
| Many people have gotten some training | 1.85% |
+-------------------------------------------------+--------+
| Website is IPv6 enabled | 7.41% |
+-------------------------------------------------+--------+
| Most equipment is dual-stacked | 31.48% |
+-------------------------------------------------+--------+
| Have an IPv6 transition plan for entire network | 5.56% |
+-------------------------------------------------+--------+
| Running IPv6-only in many places | 20.37% |
+-------------------------------------------------+--------+
| Entire network is IPv6-only | 0.00% |
+-------------------------------------------------+--------+
Table 19: IPv6 Implementation
表19：IPv6の実装
Question 2. What kind of help or classes would you like to see INTC do? (54 respondents)
質問2.どのようなヘルプやクラスを把握したいですか？（54人の回答者）
+------------------------------------------------+--------+
| Classes/labs on IPv6 security | 66.67% |
+------------------------------------------------+--------+
| Classes/labs on IPv6 fundamentals | 55.56% |
+------------------------------------------------+--------+
| Classes/labs on address planning/network conf. | 57.41% |
+------------------------------------------------+--------+
| Classes/labs on IPv6 troubleshooting | 66.67% |
+------------------------------------------------+--------+
| Classes/labs on application conversion | 35.19% |
+------------------------------------------------+--------+
| Other | 14.81% |
+------------------------------------------------+--------+
Table 20: Help/Classes from INTC
表20：INTCのヘルプ/クラス
Question 3. As you begin to think about the implementation of IPv6 at your organization, what areas do you feel are of concern? (54 respondents)
質問3.組織でのIPv6の実装について考え始めると、どの分野が懸念されていると思いますか？（54人の回答者）
+-----------------------------+--------+
| Security | 31.48% |
+-----------------------------+--------+
| Application conversion | 25.93% |
+-----------------------------+--------+
| Training | 27.78% |
+-----------------------------+--------+
| All the above | 33.33% |
+-----------------------------+--------+
| Don't know enough to answer | 14.81% |
+-----------------------------+--------+
| Other | 9.26% |
+-----------------------------+--------+
Table 21: Areas of Concern for IPv6 Implementation
表21：IPv6実装の懸念領域
The authors of this document would like to thank Brian Carpenter, Fred Baker, Alexandre Petrescu, Fernando Gont, Barbara Stark, Haisheng Yu (Johnson), Dhruv Dhody, Gábor Lencse, Shuping Peng, Daniel Voyer, Daniel Bernier, Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, Erik Nygren, Eduard Vasilenko, and Xipeng Xiao for their comments and review of this document.
この文書の著者は、ブライアン・カーペンター、フレッド・ベイカー、アレクサンドル・ペトレスク、フェルナンド・ゴント、バーバラ・スターク、ハイシェン・ユ（ジョンソン）、ドルフ・ドディ、ガーバー・レンセ、シュピング・ペン、ダニエル・ヴォイヤー、ダニエル・ベルニエ、ハリハラン・アナンサクリッシュナン、ドナヴァン・フリッツ、Igor Lubashev、Erik Nygren、Eduard Vasilenko、およびXipeng Xiaoのコメントとこの文書のレビューについて。
Nalini Elkins
Inside Products
Email: nalini.elkins@insidethestack.com
Sébastien Lourdez
Post Luxembourg
Email: sebastien.lourdez@post.lu
Giuseppe Fioccola
Huawei Technologies
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Paolo Volpato
Huawei Technologies
Via Lorenteggio, 240
20147 Milan
Italy
Email: paolo.volpato@huawei.com
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar, Madrid
Spain
Email: jordi.palet@theipv6company.com
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Chongfeng Xie
China Telecom
Email: xiechf@chinatelecom.cn