rfc9386.original   rfc9386.txt 
V6OPS G. Fioccola Internet Engineering Task Force (IETF) G. Fioccola
Internet-Draft P. Volpato Request for Comments: 9386 P. Volpato
Obsoletes: 6036 (if approved) Huawei Technologies Obsoletes: 6036 Huawei Technologies
Intended status: Informational J. Palet Martinez Category: Informational J. Palet Martinez
Expires: 4 June 2023 The IPv6 Company ISSN: 2070-1721 The IPv6 Company
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
C. Xie C. Xie
China Telecom China Telecom
1 December 2022 April 2023
IPv6 Deployment Status IPv6 Deployment Status
draft-ietf-v6ops-ipv6-deployment-10
Abstract Abstract
This document provides an overview of IPv6 deployment status in 2022. This document provides an overview of the status of IPv6 deployment
Specifically, it looks at the degree of adoption of IPv6 in the in 2022. Specifically, it looks at the degree of adoption of IPv6 in
industry, analyzes the remaining challenges and proposes further the industry, analyzes the remaining challenges, and proposes further
investigations in areas where the industry has not yet taken a clear investigations in areas where the industry has not yet taken a clear
and unified approach in the transition to IPv6. It obsoletes RFC and unified approach in the transition to IPv6. It obsoletes RFC
6036. 6036.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 4 June 2023. 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.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology
2. IPv6: The Global Picture . . . . . . . . . . . . . . . . . . 6 2. IPv6: The Global Picture
2.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 6 2.1. IPv4 Address Exhaustion
2.1.1. IPv4 addresses per capita and IPv6 status . . . . . . 7 2.1.1. IPv4 Addresses per Capita and IPv6 Status
2.2. IPv6 Users . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. IPv6 Users
2.3. IPv6 Web Content . . . . . . . . . . . . . . . . . . . . 10 2.3. IPv6 Web Content
2.4. IPv6 public actions and policies . . . . . . . . . . . . 11 2.4. IPv6 Public Actions and Policies
3. A Survey on IPv6 Deployments . . . . . . . . . . . . . . . . 12 3. A Survey on IPv6 Deployments
3.1. IPv6 Allocations . . . . . . . . . . . . . . . . . . . . 12 3.1. IPv6 Allocations
3.2. IPv6 among Internet Service Providers . . . . . . . . . . 14 3.2. IPv6 among Internet Service Providers
3.3. IPv6 among Enterprises . . . . . . . . . . . . . . . . . 14 3.3. IPv6 among Enterprises
3.3.1. Government and Universities . . . . . . . . . . . . . 15 3.3.1. Government and Universities
4. IPv6 deployment scenarios . . . . . . . . . . . . . . . . . . 17 4. IPv6 Deployment Scenarios
4.1. Dual-Stack . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Dual-Stack
4.2. IPv6-only Overlay . . . . . . . . . . . . . . . . . . . . 18 4.2. IPv6-Only Overlay
4.3. IPv6-only Underlay . . . . . . . . . . . . . . . . . . . 19 4.3. IPv6-Only Underlay
4.4. IPv4 as a Service . . . . . . . . . . . . . . . . . . . . 19 4.4. IPv4-as-a-Service
4.5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5. IPv6-Only
5. Common IPv6 Challenges . . . . . . . . . . . . . . . . . . . 21 5. Common IPv6 Challenges
5.1. Transition Choices . . . . . . . . . . . . . . . . . . . 21 5.1. Transition Choices
5.1.1. Service Providers . . . . . . . . . . . . . . . . . . 21 5.1.1. Service Providers: Fixed and Mobile Operators
5.1.2. Enterprises . . . . . . . . . . . . . . . . . . . . . 22 5.1.2. Enterprises
5.1.3. Industrial Internet . . . . . . . . . . . . . . . . . 23 5.1.3. Industrial Internet
5.1.4. Content and Cloud Service Providers . . . . . . . . . 24 5.1.4. Content and Cloud Service Providers
5.1.5. CPEs and user devices . . . . . . . . . . . . . . . . 24 5.1.5. CPEs and User Devices
5.1.6. Software Applications . . . . . . . . . . . . . . . . 25 5.1.6. Software Applications
5.2. Network Management and Operations . . . . . . . . . . . . 25 5.2. Network Management and Operations
5.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. Performance
5.3.1. IPv6 packet loss and latency . . . . . . . . . . . . 26 5.3.1. IPv6 Packet Loss and Latency
5.3.2. Customer Experience . . . . . . . . . . . . . . . . . 27 5.3.2. Customer Experience
5.4. IPv6 security and privacy . . . . . . . . . . . . . . . . 27 5.4. IPv6 Security and Privacy
5.4.1. Protocols security issues . . . . . . . . . . . . . . 28 5.4.1. Protocols' Security Issues
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. References
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Summary of Questionnaire and Replies for Network
10.2. Informative References . . . . . . . . . . . . . . . . . 33 Operators
Appendix A. Summary of Questionnaire and Replies for network Appendix B. Summary of Questionnaire and Replies for Enterprises
operators . . . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgements
Appendix B. Summary of Questionnaire and Replies for Contributors
enterprises . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
[RFC6036] described IPv6 deployment scenarios adopted or foreseen by [RFC6036] describes IPv6 deployment scenarios that were adopted or
a number of Internet Service Providers (ISPs) who responded to a foreseen by a number of Internet Service Providers (ISPs) who
technical questionnaire in early 2010. In doing that, [RFC6036] responded to a technical questionnaire in early 2010, and [RFC6036]
provided practices and plans expected to take place in the following also provides practices and plans that were expected to take place in
years. Since the publication of [RFC6036], several other documents the following years. Since the publication of [RFC6036], several
have contributed to the IPv6 transition discussion in operational other documents have contributed to the IPv6 transition discussion in
environments. To name a few: operational environments. To name a few:
- [RFC6180] discussed IPv6 deployment models and transition * [RFC6180] discusses IPv6 deployment models and transition
mechanisms, recommending those proven to be effective in mechanisms, recommending those proven to be effective in
operational networks. operational networks.
- [RFC6883] provided guidance and suggestions for Internet content * [RFC6883] provides guidance and suggestions for Internet content
providers and Application Service Providers (ASPs). providers and Application Service Providers (ASPs).
- [RFC7381] introduced the guidelines of IPv6 deployment for * [RFC7381] introduces the guidelines of IPv6 deployment for
enterprises. enterprises.
[RFC6540] recommended the support of IPv6 to all IP-capable nodes. [RFC6540] recommends the support of IPv6 to all IP-capable nodes. It
It was referenced in the IAB Statement on IPv6 [IAB], which was referenced in the IAB statement on IPv6 [IAB], which represented
represented a major step in driving the IETF as well as other a major step in driving the IETF and other Standards Development
Standard Developing Organizations (SDOs) towards using IPv6 in their Organizations (SDOs) towards using IPv6 in their works.
works.
In more recent times, organizations such as ETSI provided more In more recent times, organizations, such as ETSI, provided more
contributions to the use of IPv6 in operational environments, contributions to the use of IPv6 in operational environments,
targeting IPv6 in different industry segments. As a result, targeting IPv6 in different industry segments. As a result,
[ETSI-IP6-WhitePaper], was published to provide an updated view on [ETSI-IP6-WhitePaper] was published to provide an updated view on the
the IPv6 best practices adopted so far, in particular in the ISP IPv6 best practices adopted so far, in particular, in the ISP domain.
domain.
Considering all of the above, and after more than ten years since the 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 publication of [RFC6036], it is useful to assess the status of the
transition to IPv6. Some reasons include: transition to IPv6. Some reasons include:
- In some areas, the lack of IPv4 addresses forced both carriers * In some areas, the lack of IPv4 addresses forced both carriers and
and content providers to shift to IPv6 to support the introduction content providers to shift to IPv6 to support the introduction of
of new applications, in particular in wireless networks. new applications, in particular, in wireless networks.
- Some governmental actions took place to encourage or even * Some governmental actions took place to encourage or even enforce
enforce the adoption of IPv6 in certain countries. the adoption of IPv6 in certain countries.
- Looking at the global adoption of IPv6, this seems to have * Looking at the global adoption of IPv6, this seems to have reached
reached a threshold that justifies speaking of end-to-end IPv6 a threshold that justifies speaking of end-to-end IPv6
connectivity, at least at the IPv6 service layer. connectivity, at least at the IPv6 service layer.
This document aims to provide a survey of the status of IPv6 This document aims to provide a survey of the status of IPv6
deployment and highlight both the achievements and remaining deployment and highlight both the achievements and remaining
obstacles in the transition to IPv6 networks (and its coexistence obstacles in the transition to IPv6 networks (and its coexistence
with continued IPv4 services). The target is to give an updated view with continued IPv4 services). The target is to give an updated view
of the practices and plans already described in [RFC6036], to of the practices and plans already described in [RFC6036] to
encourage further actions and more investigations in those areas that encourage further actions and more investigations in those areas that
are still under discussion, and to present the main incentives for are still under discussion and to present the main incentives for the
the adoption of IPv6. adoption of IPv6.
This document is intended for a general audience interested to This document is intended for a general audience interested in
understand the status of IPv6 in different industries and network understanding the status of IPv6 in different industries and network
domains. People who provide or use network services may find it domains. People who provide or use network services may find it
useful for the transition to IPv6. Also, people developing plans for useful for the transition to IPv6. Also, people developing plans for
IPv6 adoption in an organization or in an industry may find IPv6 adoption in an organization or in an industry may find
information and references for their analysis. Attention is given to information and references for their analysis. Attention is given to
the different stages of the transition to IPv6 networks and services. the different stages of the transition to IPv6 networks and services.
In particular, a terminology on the use of "IPv6-only" is provided, In particular, terminology on the use of "IPv6-only" is provided,
considering IPv6-only networks and services as the final stage of considering IPv6-only networks and services as the final stage of
such transition. such transition.
The topics discussed in this document are organized into four main The topics discussed in this document are organized into four main
chapters. chapters.
Section 2 reports data and analytics about the status of IPv6. * Section 2 reports data and analytics about the status of IPv6.
Section 3 provides a survey of IPv6 deployments in different * Section 3 provides a survey of IPv6 deployments in different
environments, including ISPs, enterprises and universities. environments, including ISPs, enterprises, and universities.
Section 4 describes the IPv6 deployment approaches for Mobile * Section 4 describes the IPv6 deployment approaches for Mobile
BroadBand (MBB), Fixed BroadBand (FBB) and Enterprises. Broadband (MBB), Fixed Broadband (FBB), and enterprises.
Section 5 analyzes the general challenges to be solved in the IPv6 * Section 5 analyzes the general challenges to be solved in the IPv6
transition. Specific attention is given to operations, transition. Specific attention is given to operations,
performance and security issues. performance, and security issues.
1.1. Terminology 1.1. Terminology
This section defines the terminology regarding the usage of IPv6-only This section defines the terminology regarding the usage of IPv6-only
expressions within this document. The term IPv6-only is defined in expressions within this document. The term IPv6-only is defined in
relation to the specific scope it is referring to. In this regard, relation to the specific scope it is referring to. In this regard,
it may happen that only part of a service, of a network or even part it may happen that only part of a service, a network, or even a node
of a node is in an IPv6-only scope and the rest is not. Below are is in an IPv6-only scope, and the rest is not. The most used terms
listed the most used terms in relation to the different scopes: in relation to the different scopes are listed below:
IPv6-only interface: It means that the interface of a node is IPv6-only interface:
configured to forward only IPv6. This denotes that just part of The interface of a node is configured to forward only IPv6. This
the node can be IPv6-only since the rest of the interfaces of the denotes that just part of the node can be IPv6-only since the rest
same node may work with IPv4 as well. A Dual-Stack interface is of the interfaces of the same node may work with IPv4 as well. A
not an IPv6-only interface. Dual-Stack interface is not an IPv6-only interface.
IPv6-only node: It means that the node uses only IPv6. All IPv6-only node:
interfaces of the host only have IPv6 addresses. The node uses only IPv6. All interfaces of the host only have
IPv6 addresses.
IPv6-only service: It is used if between the host's interface and IPv6-only service:
the interface of the content server, all packet headers of the It is used if, between the host's interface and the interface of
service session are IPv6. the content server, all packet headers of the service session are
IPv6.
IPv6-only overlay: It is used if between the end points of the IPv6-only overlay:
tunnels, all inner packet headers of the tunnels are IPv6. For It is used if, between the end points of the tunnels, all inner
example, IPv6-only overlay in fixed network means that the packet headers of the tunnels are IPv6. For example, IPv6-only
encapsulation is only IPv6 between the interfaces of the Provider overlay in a fixed network means that the encapsulation is only
Edge (PE) nodes or between the Customer Provider Edge (CPE) node IPv6 between the interfaces of the Provider Edge (PE) nodes or
and the Broadband Network Gateway (BNG). between the Customer Provider Edge (CPE) node and the Broadband
Network Gateway (BNG).
IPv6-only underlay: It is used if the data plane and control plane IPv6-only underlay:
are IPv6, but not necessarily management plane. For example, It is used if the data plane and control plane are IPv6, but this
IPv6-only underlay in fixed network means that the underlay is not necessarily true for the management plane. For example,
network protocol is only IPv6 between any Provider Edge (PE) nodes IPv6-only underlay in a fixed network means that the underlay
but they can be Dual-Stack in overlay. SRv6 is an example of network protocol is only IPv6 between any PE nodes, but they can
IPv6-only underlay. be Dual-Stack in overlay. Segment Routing over IPv6 (SRv6) is an
example of IPv6-only underlay.
IPv6-only network: It is used if every node in this network is IPv6-only network:
IPv6-only. No IPv4 should exist in an IPv6-only network. In It is used if every node in this network is IPv6-only. IPv4
particular, IPv6-only network's data plane, control plane, and should not exist in an IPv6-only network. In particular, an
management plane must be IPv6. All PEs must be IPv6-only. IPv6-only network's data plane, control plane, and management
Therefore, if tunnels exist among PEs, both inner and outer plane must be IPv6. All PEs must be IPv6-only. Therefore, if
headers must be IPv6. For example, IPv6-only access network means tunnels exist among PEs, both inner and outer headers must be
that every node in this access network must be IPv6-only and IPv6. For example, an IPv6-only access network means that every
similarly IPv6-only backbone network means that every nodes in node in this access network must be IPv6-only, and similarly, an
this backbone network must be IPv6-only. IPv6-only backbone network means that every node in this backbone
network must be IPv6-only.
IPv4 as a Service (IPv4aaS): It means that IPv4 service support is IPv4-as-a-Service (IPv4aaS):
provided by means of transition mechanism, therefore there is a IPv4 service support is provided by means of a transition
combination of encapsulation/translation + IPv6-only underlay + mechanism; therefore, there is a combination of encapsulation/
decapsulation/translation. For an IPv6-only network, connectivity translation + IPv6-only underlay + decapsulation/translation. For
to legacy IPv4 is either non-existent or provided by IPv4aaS an IPv6-only network, connectivity to legacy IPv4 is either non-
mechanisms. existent or provided by IPv4aaS mechanisms.
Note that IPv6-only definitions are also discussed in Note that IPv6-only definitions are also discussed in
[I-D.palet-v6ops-ipv6-only]. [IPv6-ONLY-DEF].
2. IPv6: The Global Picture 2. IPv6: The Global Picture
This section deals with some key questions related to IPv6 namely: This section deals with some key questions related to IPv6, namely:
(1) the status of IPv4 exhaustion, often considered as one of the (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 triggers to switch to IPv6, (2) the number of IPv6 end users, a
primary measure to sense IPv6 adoption, (3) the percentage of primary measure to sense IPv6 adoption, (3) the percentage of
websites reachable over IPv6 and (4) a report on IPv6 public actions websites reachable over IPv6, and (4) a report on IPv6 public actions
and policies. and policies.
These parameters are monitored by the Regional internet Registries These parameters are monitored by the Regional Internet Registries
(RIRs) and other institutions worldwide as they provide a first-order (RIRs) and other institutions worldwide, as they provide a first-
indication on the adoption of IPv6. order indication on the adoption of IPv6.
2.1. IPv4 Address Exhaustion 2.1. IPv4 Address Exhaustion
According to [CAIR] there will be 29.3 billion networked devices by According to [CAIR], there will be 29.3 billion networked devices by
2023, up from 18.4 billion in 2018. This poses the question on 2023, up from 18.4 billion in 2018. This poses the question about
whether the IPv4 address space can sustain such a number of whether the IPv4 address space can sustain such a number of
allocations and, consequently, if this may affect the process of its allocations and, consequently, if this may affect the process of its
exhaustion. The answer is not straightforward as many aspects have exhaustion. The answer is not straightforward, as many aspects have
to be considered. to be considered.
On one hand, the RIRs are reporting scarcity of available and still On one hand, the RIRs are reporting scarcity of available and still-
reserved addresses. Table 3 of [POTAROO1] (January 2022) shows that 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 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 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 million, for a total of 17.3 million IPv4 addresses (-5.5% year over
year, comparing 2021 against 2020). The same reference, in table 1, year, comparing 2021 against 2020). Table 1 of [POTAROO1] shows that
shows that the total IPv4 allocated pool equaled to 3.685 billion the total IPv4 allocated pool equaled 3.685 billion addresses
addresses (+0.027% year over year). The ratio between the available (+0.027% year over year). The ratio between the available addresses
addresses and the total allocated brought to 0.469% of the remaining and the total allocated was brought to 0.469% of the remaining IPv4
IPv4 address space (from 0.474% at the end of 2020). address space (from 0.474% at the end of 2020).
On the other, [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 a RIR or on the so-called grey market
where third parties operate to enable the buy/sell of IPv4 addresses.
In all cases, a set of IPv4 addresses is "transferred" to a different On the other hand, [POTAROO1] again highlights the role of both
holder that has the need to expand their address range. As an address transfer and Network Address Translation (NAT) to counter the
example, [IGP-GT] and [NRO] show the amount of transfers to recipient IPv4 exhaustion. The transfer of IPv4 addresses can be done under
organizations in the different regions. Cloud Service Providers the control or registration of an RIR or on the so-called grey
(CSPs) appear to be the most active in buying IPv4 addresses to market, where third parties operate to enable the buying/selling of
satisfy their need of providing IPv4 connectivity to their tenants. IPv4 addresses. In all cases, a set of IPv4 addresses is
NAT systems provide a means to absorb at least a portion of the "transferred" to a different holder that has the need to expand their
demand of public IPv4 addresses as they enable the use of private address range. As an example, [IGP-GT] and [NRO] show the amount of
addressing in internal networks while limiting the use of public transfers to recipient organizations in the different regions. Cloud
addresses on their WAN-facing side. In the case of NAT, 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 architectural and operational issues remain. Private address space
cannot provide adequate address span, especially for large cannot provide an adequate address span, especially for large
organizations, and the reuse of addresses may make the network more organizations, and the reuse of addresses may make the network more
complex. In addition, multiple levels of address translation may complex. In addition, multiple levels of address translation may
coexist in a network, e.g. Carrier-Grade NAT (CGN) [RFC6264] based coexist in a network, e.g., Carrier-Grade NAT (CGN) [RFC6264], based
on two stages of translation. This comes with an economic and on two stages of translation. This comes with an economic and
operational burden, as discussed later in this document. operational burden, as discussed later in this document.
2.1.1. IPv4 addresses per capita and IPv6 status 2.1.1. IPv4 Addresses per Capita and IPv6 Status
The IPv4 addresses per capita ratio measures the quantity of IPv4 The IPv4 addresses per capita ratio measures the quantity of IPv4
addresses allocated to a given country divided by the population of addresses allocated to a given country divided by the population of
that country. It provides an indication of the imbalanced that country. It provides an indication of the imbalanced
distribution of the IPv4 addresses worldwide. It clearly derives distribution of the IPv4 addresses worldwide. It clearly derives
from the allocation of addresses made in the early days of the from the allocation of addresses made in the early days of the
Internet. Internet.
The sources for measuring the IPv4 addresses per capita ratio are the The sources for measuring the IPv4 addresses per capita ratio are the
allocations done by the RIRs and the statistics about the world allocations done by the RIRs and the statistics about the world
population. In this regard, [POTAROO2] provides distribution files. population. In this regard, [POTAROO2] provides distribution files.
The next tables compare the number of IPv4 addresses available per The next tables compare the number of IPv4 addresses available per
person in a certain country (IPv4 address per capita) against the person in a certain country (IPv4 address per capita) against the
relative adoption of IPv6 in the same country (expressed as the relative adoption of IPv6 in the same country (expressed as the
number of IPv6 capable users in the considered country). The table number of IPv6-capable users in the considered country). The table
shows just a subset of the data available from [POTAROO2]. In shows just a subset of the data available from [POTAROO2]. In
particular, the following table provides the data for the 25 most particular, the following table provides the data for the 25 most
populated countries in the world. The table is ordered based on the populated countries in the world. The table is ordered based on the
IPv4 addresses per capita ratio and the data refer to the 1st of IPv4 addresses per capita ratio, and the data refer to 1 January
January 2022. 2022.
+----------------------------+---------------+---------------+ +==============================+=================+=================+
|Country |IPv4 per capita|IPv6 deployment| | Country | IPv4 per Capita | IPv6 Deployment |
+----------------------------+---------------+---------------+ +==============================+=================+=================+
|United States of America | 4.89| 47.1%| | United States of America | 4.89 | 47.1% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|United Kingdom | 1.65| 33.2%| | United Kingdom | 1.65 | 33.2% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Japan | 1.50| 36.7%| | Japan | 1.50 | 36.7% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Germany | 1.48| 53.0%| | Germany | 1.48 | 53.0% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|France | 1.27| 42.1%| | France | 1.27 | 42.1% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Italy | 0.91| 4.7%| | Italy | 0.91 | 4.7% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|South Africa | 0.46| 2.4%| | South Africa | 0.46 | 2.4% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Brazil | 0.41| 38.7%| | Brazil | 0.41 | 38.7% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Russian Federation | 0.31| 9.7%| | Russian Federation | 0.31 | 9.7% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|China | 0.24| 60.1%(*)| | China | 0.24 | 60.1%(*) |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Egypt | 0.24| 4.3%| | Egypt | 0.24 | 4.3% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Mexico | 0.23| 41.8%| | Mexico | 0.23 | 41.8% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Turkey | 0.20| 0.2%| | Turkey | 0.20 | 0.2% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Vietnam | 0.17| 48.0%| | Vietnam | 0.17 | 48.0% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Iran (Islamic Republic) | 0.15| 0.1%| | Iran (Islamic Republic) | 0.15 | 0.1% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Thailand | 0.13| 40.8%| | Thailand | 0.13 | 40.8% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Indonesia | 0.07| 5.0%| | Indonesia | 0.07 | 5.0% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Philippines | 0.05| 13.8%| | Philippines | 0.05 | 13.8% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|India | 0.03| 76.9%| | India | 0.03 | 76.9% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Pakistan | 0.03| 2.1%| | Pakistan | 0.03 | 2.1% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|United Republic of Tanzania | 0.02| 0.0%| | United Republic of Tanzania | 0.02 | 0.0% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Nigeria | 0.02| 0.2%| | Nigeria | 0.02 | 0.2% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Bangladesh | 0.01| 0.3%| | Bangladesh | 0.01 | 0.3% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Ethiopia | 0.00| 0.0%| | Ethiopia | 0.00 | 0.0% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
|Democratic Republic of Congo| 0.00| 0.1%| | Democratic Republic of Congo | 0.00 | 0.1% |
+----------------------------+---------------+---------------+ +------------------------------+-----------------+-----------------+
Figure 1: IPv4 per capita and IPv6 deployment for the top 25 most Table 1: IPv4 per Capita and IPv6 Deployment for the Top 25 Most
populated countries in the world, 1st of January 2022 Populated Countries in the World (as of January 2022)
(*) The IPv6 deployment information in China is derived from (*) The IPv6 deployment information in China is derived from
[CN-IPv6]. [CN-IPv6].
A direct correlation between low IPv4 per capita and high IPv6 A direct correlation between low IPv4 per capita and high IPv6
adoption is not immediate, yet some indications emerge. For example, adoption is not immediate, yet some indications emerge. For example,
countries such as Brazil, China, and India have clearly moved towards some countries, such as Brazil, China, and India, have clearly moved
IPv6 adoption. As discussed later, this appears related to several towards IPv6 adoption. As discussed later, this appears related to
factors in addition to the lack of IPv4 addresses, including local several factors in addition to the lack of IPv4 addresses, including
regulation and market-driven actions. The 5 countries at the top of local regulation and market-driven actions. The 5 countries at the
the table, with relative high availability of IPv4 addresses, have top of the table, with relative high availability of IPv4 addresses,
also shown a good level of IPv6 adoption. In other cases, a relative have also shown a good level of IPv6 adoption. In other cases, a
scarcity of IPv4 addresses has not meant a clear move towards IPv6, relative scarcity of IPv4 addresses has not meant a clear move
as several countries listed in the table still have low or very low towards IPv6, as several countries listed in the table still have low
IPv6 adoption. or very low IPv6 adoption.
2.2. IPv6 Users 2.2. IPv6 Users
The count of the IPv6 users is the key parameter to get an immediate The count of the IPv6 users is the key parameter to get an immediate
understanding of the adoption of IPv6. Some organizations constantly understanding of the adoption of IPv6. Some organizations constantly
track the usage of IPv6 by aggregating data from several sources. As track the usage of IPv6 by aggregating data from several sources. As
an example, the Internet Society constantly monitors the volume of an example, the Internet Society constantly monitors the volume of
IPv6 traffic for the networks that joined the WorldIPv6Launch IPv6 traffic for the networks that joined the World IPv6 Launch
initiative [WIPv6L]. The measurement aggregates statistics from initiative [WIPv6L]. The measurement aggregates statistics from
organizations such as [Akm-stats] that provides data down to the organizations, such as [Akm-stats], that provide data down to the
single network level measuring the number of hits to their content single network level, measuring the number of hits to their content
delivery platform. For the scope of this document, the approach used 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 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 runs on a user's device [CAIDA] is considered. To give a rough
estimation of the relative growth of IPv6, the next table aggregates estimation of the relative growth of IPv6, the next table aggregates
the total number of estimated IPv6-capable users at 1st of January the total number of estimated IPv6-capable users as of 1 January 2022
2022, and compares it against the total Internet users, as measured and compares it against the total Internet users, as measured by
by [POTAROO2]. [POTAROO2].
+--------+--------+--------+--------+--------+--------+--------+ +=====+==========+==========+==========+==========+==========+=====+
| | Jan | Jan | Jan | Jan | Jan | CAGR | | | Jan 2018 | Jan 2019 | Jan 2020 | Jan 2021 | Jan 2022 |CAGR |
| | 2018 | 2019 | 2020 | 2021 | 2022 | | +=====+==========+==========+==========+==========+==========+=====+
+--------+--------+--------+--------+--------+--------+--------+ |IPv6 | 513.07 | 574.02 | 989.25 | 1,136.28 | 1,207.61 |23.9%|
| 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% |
| 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%|
| Ratio | 15.0%| 16.5%| 24.3%| 27.8%| 29.5%| 18.4% | +-----+----------+----------+----------+----------+----------+-----+
+--------+--------+--------+--------+--------+--------+--------+
Figure 2: IPv6-capable users against total (in millions) as of Table 2: IPv6-Capable Users against Total Users (in Millions) as
1st of January 2022 of January 2022
Two figures appear: first, the IPv6 Internet population is growing Two figures appear: first, the IPv6 Internet population is growing
with a two-digits Compound Annual Growth Rate (CAGR), and second, the with a two-digit Compound Annual Growth Rate (CAGR), and second, the
ratio IPv6 over total is also growing steadily. ratio IPv6 over total is also growing steadily.
2.3. IPv6 Web Content 2.3. IPv6 Web Content
[W3Techs] keeps track of the use of several technical components of [W3Techs] keeps track of the use of several technical components of
websites worldwide through different analytical engines. The websites worldwide through different analytical engines. The
utilization of IPv6 for websites is shown in the next table, where utilization of IPv6 for websites is shown in the next table, where
the percentages refer to the websites which are accessible over IPv6. the percentages refer to the websites that are accessible over IPv6.
+------------+-------+-------+-------+-------+-------+------+ +===========+=======+=======+=======+=======+=======+=======+
| Worldwide | Jan | Jan | Jan | Jan | Jan | CAGR | | Worldwide | Jan | Jan | Jan | Jan | Jan | CAGR |
| Websites | 2018 | 2019 | 2020 | 2021 | 2022 | | | Websites | 2018 | 2019 | 2020 | 2021 | 2022 | |
+------------+-------+-------+-------+-------+-------+------+ +===========+=======+=======+=======+=======+=======+=======+
|% of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9%| | % of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9% |
+------------+-------+-------+-------+-------+-------+------+ +-----------+-------+-------+-------+-------+-------+-------+
Figure 3: Usage of IPv6 in websites, January 2022 Table 3: Usage of IPv6 in Websites (as of January 2022)
Looking at the growth rate, it may appear not particularly high. It Looking at the growth rate, it may not appear particularly high. It
has to be noted, though, that not all websites are equal. The has to be noted, though, that not all websites are equal. The
largest content providers, which already support IPv6, generate a lot largest content providers, which already support IPv6, generate a lot
more content than small websites. [Csc6lab] measured at the more content than small websites. At the beginning of January 2022,
beginning of January 2022 that out of the world top 500 sites ranked [Csc6lab] measured that out of the world's top 500 sites, 203 are
by [Alx], 203 are IPv6-enabled (+3.6% from January 2021 to January IPv6 enabled (+3.6% from January 2021 to January 2022). If we
2022). If we consider that the big content providers (such as consider that the big content providers (such as Google, Facebook,
Google, Facebook, Netflix) generate more than 50% of the total mobile and Netflix) generate more than 50% of the total mobile traffic
traffic [SNDVN], and in some cases even more up to 65% ([ISOC1] [SNDVN], and in some cases even more up to 65% [ISOC1] [HxBld], the
[HxBld]), the percentage of content accessible over IPv6 is clearly percentage of content accessible over IPv6 is clearly more relevant
more relevant than the number of enabled IPv6 websites. It would be than the number of enabled IPv6 websites. Of that 50% of all mobile
interesting to know what percentage of that 50% of all mobile traffic traffic, it would be interesting to know what percentage is IPv6.
is IPv6. Unfortunately, this information is not available. Unfortunately, this information is not available.
Related to that, a question that sometimes arises is whether the Related to that, a question that sometimes arises is whether the
content stored by content providers would be all accessible on IPv6 content stored by content providers would be all accessible on IPv6
in the hypothetical case of a sudden IPv4 switch-off. Even if this 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 pure speculation, the numbers above may bring to state that this
is likely the case. This would reinforce the common thought that, in is likely the case. This would reinforce the common thought that, in
quantitative terms, most of the content is accessible via IPv6. quantitative terms, most of the content is accessible via IPv6.
2.4. IPv6 public actions and policies 2.4. IPv6 Public Actions and Policies
As previously noted, the worldwide deployment of IPv6 is not uniform As previously noted, the worldwide deployment of IPv6 is not uniform
[G_stats], [APNIC1]. It is worth noticing that, in some cases, [G_stats] [APNIC1]. It is worth noticing that, in some cases, higher
higher IPv6 adoption in certain countries has been achieved as a IPv6 adoption in certain countries has been achieved as a consequence
consequence of actions taken by the local governments through of actions taken by the local governments through regulation or
regulation or incentive to the market. Looking at the European Union incentive to the market. Looking at the European Union area, some
area, countries such as Belgium, France and Germany are well ahead in countries, such as Belgium, France, and Germany, are well ahead in
terms of IPv6 adoption. terms of IPv6 adoption.
In the case of Belgium, the Belgian Institute for Postal services and In the case of Belgium, the Belgian Institute for Postal services and
Telecommunications (BIPT) acted to mediate an agreement between the Telecommunications (BIPT) acted to mediate an agreement between the
local ISPs and the government to limit the use of Carrier-Grade NAT local ISPs and the government to limit the use of Carrier-Grade NAT
(CGN) systems and of public IPv4 addresses for lawful investigations (CGN) systems and of public IPv4 addresses for lawful investigations
in 2012 [BIPT]. The agreement limited the use of one IPv4 address in 2012 [BIPT]. The agreement limited the use of one IPv4 address
per 16 customers behind NAT. The economic burden sustained by the 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 ISPs for the unoptimized use of NAT induced the shift to IPv6 and its
increased adoption in the latest years. increased adoption in the latest years.
In France, the National Regulator (Autoritee de regulation des In France, the National Regulator (Autoritee de regulation des
communications electroniques, or Arcep) introduced an obligation for communications electroniques, or Arcep) introduced an obligation for
the mobile carriers awarded with a license to use 5G frequencies the mobile carriers awarded with a license to use 5G frequencies
(3.4-3.8GHz) in Metropolitan France to be IPv6 compatible [ARCEP]. (3.4-3.8 GHz) in Metropolitan France to be IPv6 compatible [ARCEP].
As stated, "the goal is to ensure that services are interoperable and As stated in [ARCEP] (translated from French),
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 goal is to ensure that services are interoperable and to
the RIPE NCC has run out of IPv4 addresses". A slow adoption of IPv6 | remove obstacles to using services that are only available in
could prevent new Internet services to widespread or create a barrier | IPv6, as the number of devices in use continues to soar, and
to entry for newcomers to the market. "IPv6 can help to increase | because the RIPE NCC has run out of IPv4 addresses.
competition in the telecom industry, and help to industrialize a
country for specific vertical sectors". 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".
Increased IPv6 adoption in Germany depended on a mix of industry and Increased IPv6 adoption in Germany depended on a mix of industry and
public actions. Specifically, the Federal Office for Information public actions. Specifically, the Federal Office for Information
Technology (under the Federal Ministry of the Interior) issued over Technology (under the Federal Ministry of the Interior) issued over
the years a few recommendations on the use of IPv6 in the German the years a few recommendations on the use of IPv6 in the German
public administration. The latest guideline in 2019 constitutes a public administration. The latest guideline in 2019 constitutes a
high-level road map for mandatory IPv6 introduction in the federal high-level road map for mandatory IPv6 introduction in the federal
administration networks [GFA]. administration networks [GFA].
In the United States, the Office of Management and Budget is also In the United States, the Office of Management and Budget is also
calling for IPv6 adoption [US-FR], [US-CIO]. These documents define calling for IPv6 adoption [US-FR] [US-CIO]. These documents define a
a plan to have the 80% of the US Federal IP-capable networks based on plan to have 80% of the US federal IP-capable networks based on
IPv6-only by the year 2025. China is another example of government IPv6-only by the year 2025. China is another example of a government
which is supporting a country-wide IPv6 adoption [CN]. In India, the that is supporting a country-wide IPv6 adoption [CN]. In India, the
high adoption of IPv6 took origin from the decision of Reliance Jio high adoption of IPv6 took origin from the decision of Reliance Jio
to move to IPv6 in their networks [RelJio]. In addition, the to move to IPv6 in their networks [RelJio]. In addition, the
Department of Telecommunications (under the Ministry of Department of Telecommunications (under the Ministry of
Communications and Information Technology) issued guidelines for the Communications and Information Technology) issued guidelines for the
progressive adoption of IPv6 in public and private networks. The progressive adoption of IPv6 in public and private networks. The
latest one dates 2021 [IDT] and fosters further moves to IPv6 latest one dates 2021 [IDT] and fosters further moves to IPv6
connection services. connection services.
3. A Survey on IPv6 Deployments 3. A Survey on IPv6 Deployments
This section discusses the status of IPv6 adoption in service This section discusses the status of IPv6 adoption in service
providers and enterprises' networks. provider and enterprise networks.
3.1. IPv6 Allocations 3.1. IPv6 Allocations
RIRs are responsible for allocating IPv6 address blocks to ISPs, LIRs RIRs are responsible for allocating IPv6 address blocks to ISPs,
(Local Internet Registries) as well as enterprises or other Local Internet Registries (LIRs), and enterprises or other
organizations. An ISP/LIR will use the allocated block to assign organizations. An ISP/LIR will use the allocated block to assign
addresses to their end users. The following table shows the amount addresses to their end users. The following table shows the amount
of individual allocations, per RIR, in the time period 2017-2021 of individual allocations, per RIR, in the time period from 2017-2021
[APNIC2]. [APNIC2].
+---------+-------+-------+-------+-------+-------+---------+------+ +==========+=====+=======+=======+=======+=======+===========+====+
| Registry| Dec | Dec | Dec | Dec | Dec |Cumulated| CAGR | | Registry |Dec | Dec | Dec | Dec | Dec | Cumulated |CAGR|
| | 2017 | 2018 | 2019 | 2020 | 2021 | | | | |2017 | 2018 | 2019 | 2020 | 2021 | | |
+---------+-------+-------+-------+-------+-------+---------+------+ +==========+=====+=======+=======+=======+=======+===========+====+
| AFRINIC | 112 | 110 | 115 | 109 | 136 | 582 | 51% | | 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% | | APNIC |1,369| 1,474 | 1,484 | 1,498 | 1,392 | 7,217 |52% |
| 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% | | ARIN |684 | 659 | 605 | 644 | 671 | 3,263 |48% |
| | | | | | | | | +----------+-----+-------+-------+-------+-------+-----------+----+
| Total | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 51% | | 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% |
+----------+-----+-------+-------+-------+-------+-----------+----+
Figure 4: IPv6 allocations worldwide in the period 2017-2021 Table 4: IPv6 Allocations Worldwide (as of January 2022)
(January 2022)
The trend shows the steady progress of IPv6. The decline of IPv6 The trend shows the steady progress of IPv6. The decline of IPv6
allocations in 2020 and 2021 may be due to COVID-19 pandemic. It allocations in 2020 and 2021 may be due to the COVID-19 pandemic. It
also happens to IPv4 allocations. also happened to IPv4 allocations.
[APNIC2] also compares the number of allocations for both address [APNIC2] also compares the number of allocations for both address
families. The CAGR looks quite similar in 2021 but a little higher families. The CAGR looks quite similar in 2021 but a little higher
for the IPv4 allocations in comparison to the IPv6 allocations (53.6% for the IPv4 allocations in comparison to the IPv6 allocations (53.6%
versus 50.9%). versus 50.9%).
+--------+-------+-------+-------+-------+-------+----------+------+ +=========+=====+=====+========+=======+=======+===========+=======+
| Address| Dec | Dec | Dec | Dec | Dec | Cumulated| CAGR | | Address |Dec |Dec | Dec | Dec | Dec | Cumulated | CAGR |
| family | 2017 | 2018 | 2019 | 2020 | 2021 | | | | family |2017 |2018 | 2019 | 2020 | 2021 | | |
+--------+-------+-------+-------+-------+-------+----------+------+ +=========+=====+=====+========+=======+=======+===========+=======+
| IPv6 | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 50.9%| | 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%| | IPv4 |8,091|9,707| 13,112 | 6,263 | 7,829 | 45,002 | 53.6% |
| | | | | | | | | +---------+-----+-----+--------+-------+-------+-----------+-------+
+--------+-------+-------+-------+-------+-------+----------+------+
Figure 5: Allocations per address family Table 5: Allocations per Address Family (as of January 2022)
The reason may be that the IPv4 allocations in 2021 include many The reason may be that the IPv4 allocations in 2021 included many
allocations of small address ranges (e.g. /24) [APNIC2]. On the allocations of small address ranges (e.g., /24) [APNIC2]. On the
contrary, a single IPv6 allocation is large enough to cope with 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 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 IPv6 /30 or /32 allocation, it is unlikely that a new request of
addresses is repeated in the short term. addresses is repeated in the short term.
The next table is based on [APNIC3], [APNIC4] and shows the The next table is based on [APNIC3] and [APNIC4] and shows the
percentage of Autonomous Systems (AS) supporting IPv6 compared to the percentage of Autonomous Systems (ASes) supporting IPv6 compared to
total ASes worldwide. The number of IPv6-capable ASes increased from the total ASes worldwide. The number of IPv6-capable ASes increased
24.3% in January 2018 to 38.7% in January 2022. This equals to 18% from 24.3% in January 2018 to 38.7% in January 2022. This equals to
CAGR for IPv6-enabled networks. In comparison, the CAGR for the 18% of the CAGR for IPv6-enabled networks. In comparison, the CAGR
total of IPv6 and IPv4 networks is just 5%. for the total of IPv6 and IPv4 networks is just 5%.
+------------+-------+-------+-------+-------+-------+------+ +==============+========+========+========+========+========+======+
| Advertised | Jan | Jan | Jan | Jan | Jan | CAGR | | Advertised | Jan | Jan | Jan | Jan | Jan | CAGR |
| ASN | 2018 | 2019 | 2020 | 2021 | 2022 | | | ASN | 2018 | 2019 | 2020 | 2021 | 2022 | |
+------------+-------+-------+-------+-------+-------+------+ +==============+========+========+========+========+========+======+
|IPv6-capable| 14,500| 16,470| 18,650| 21,400| 28,140| 18% | | 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% | | Total ASN | 59,700 | 63,100 | 66,800 | 70,400 | 72,800 | 5% |
| | | | | | | | +--------------+--------+--------+--------+--------+--------+------+
| Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | | | Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | |
+------------+-------+-------+-------+-------+-------+------+ +--------------+--------+--------+--------+--------+--------+------+
Figure 6: Percentage of IPv6-capable ASes Table 6: Percentage of IPv6-Capable ASes (as of January 2022)
The tables above provide an aggregated view of the allocations The tables above provide an aggregated view of the allocations'
dynamic. The next subsections will zoom into each specific domain to dynamic. The next subsections will zoom into each specific domain to
highlight its relative status. highlight its relative status.
3.2. IPv6 among Internet Service Providers 3.2. IPv6 among Internet Service Providers
As it was proposed at the time of [RFC6036], also in the case of this A survey was submitted to a group of service providers in Europe
document a survey was submitted to a group of service providers in during the third quarter of 2020 (see Appendix A for the complete
Europe during the third quarter of 2020 (see Appendix A for the poll) to understand their plans about IPv6 and their technical
complete poll), to understand their plans about IPv6 and their preferences regarding its adoption. Although this poll does not give
technical preferences towards its adoption. Although such poll does an exhaustive view on the IPv6 status, it provides some insights that
not give an exhaustive view on the IPv6 status, it provides some are relevant to the discussion.
insights that are relevant to the discussion.
The poll revealed that the majority of the ISPs interviewed had plans The poll revealed that the majority of ISPs interviewed had plans
concerning IPv6 (79%). Of them, 60% had already ongoing activities, concerning IPv6 (79%). Of them, 60% had ongoing activities already,
while 33% was expected to start activities in a 12-months time-frame. while 33% were expected to start activities in a 12-month timeframe.
The transition to IPv6 involved all business segments: mobile (63%), The transition to IPv6 involved all business segments: mobile (63%),
fixed (63%), and enterprises (50%). fixed (63%), and enterprise (50%).
The reasons to move to IPv6 varied. Global IPv4 address depletion The reasons to move to IPv6 varied. Global IPv4 address depletion
and the run out of private address space recommended in [RFC1918] and the run out of private address space recommended in [RFC1918]
were reported as the important drivers for IPv6 deployment (48%). In were reported as the important drivers for IPv6 deployment (48%). In
a few cases, respondents cited the requirement of national IPv6 a few cases, respondents cited the requirement of national IPv6
policies and the launch of 5G as the reasons (13%). Enterprise policies and the launch of 5G as the reasons (13%). Enterprise
customers demand was also a reason to introduce IPv6 (13%). customer demand was also a reason to introduce IPv6 (13%).
From a technical preference standpoint, Dual-Stack [RFC4213] was the From a technical preference standpoint, Dual-Stack [RFC4213] was the
most adopted solution, in both wireline (59%) and cellular networks most adopted solution in both wireline (59%) and cellular networks
(39%). In wireline, the second most adopted mechanism was Dual-Stack (39%). In wireline, the second most adopted mechanism was Dual-Stack
Lite (DS-Lite) [RFC6333] (19%). In cellular networks, the second Lite (DS-Lite) [RFC6333] (19%). In cellular networks, the second
preference was 464XLAT [RFC6877] (21%). preference was 464XLAT [RFC6877] (21%).
More details about the answers received can be found in Appendix A. More details about the answers received can be found in Appendix A.
3.3. IPv6 among Enterprises 3.3. IPv6 among Enterprises
As described in [RFC7381], enterprises face different challenges than As described in [RFC7381], enterprises face different challenges than
ISPs. Publicly available reports show how the enterprise deployment ISPs. Publicly available reports show how the enterprise deployment
of IPv6 lags behind ISP deployment [cmpwr]. of IPv6 lags behind ISP deployment [cmpwr].
[NST_1] provides estimations on deployment status of IPv6 for domains [NST_1] provides estimations on the deployment status of IPv6 for
such as example.com, example.net or example.org in the United States. domains such as example.com, example.net, or example.org in the
The measurement encompasses many industries, including United States. The measurement encompasses many industries,
telecommunications, so the term "enterprises" is a bit loose in this including telecommunications, so the term "enterprises" is a bit
context. In any case, it provides a first indication of IPv6 loose in this context. In any case, it provides a first indication
adoption in several US industry sectors. The analysis tries to infer of IPv6 adoption in several US industry sectors. The analysis tries
whether IPv6 is supported by looking from "outside" a company's to infer whether IPv6 is supported by looking from "outside" a
network. It takes into consideration the support of IPv6 to external company's network. It takes into consideration the support of IPv6
services such as Domain Name System (DNS), mail and website. [BGR_1] to external services, such as Domain Name System (DNS), mail, and
has similar data for China while [CNLABS_1] provides the status in websites. [BGR_1] has similar data for China, while [CNLABS_1]
India. provides the status in India.
+--------------+----------+---------+---------+---------+ +===============+==================+=======+=======+=========+
|Country | Domains | DNS | Mail | Website | | Country | Domains analyzed | DNS | Mail | Website |
| | analyzed | | | | +===============+==================+=======+=======+=========+
+--------------+----------+---------+---------+---------+ | China | 478 | 74.7% | 0.0% | 19.7% |
|China | 478 | 74.7% | 0.0% | 19.7% | +---------------+------------------+-------+-------+---------+
| | | | | | | India | 104 | 51.9% | 15.4% | 16.3% |
+--------------+----------+---------+---------+---------+ +---------------+------------------+-------+-------+---------+
|India | 104 | 51.9% | 15.4% | 16.3% | | United States | 1070 | 66.8% | 21.2% | 6.3% |
| | | | | | | of America | | | | |
+--------------+----------+---------+---------+---------+ +---------------+------------------+-------+-------+---------+
|United States | 1070 | 66.8% | 21.2% | 6.3% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
Figure 7: IPv6 support for external-facing services across Table 7: IPv6 Support for External-Facing Services across
enterprises (January 2022) Enterprises (as of January 2022)
A poll submitted to a group of large enterprises in North America in A poll submitted to a group of large enterprises in North America in
early 2021 (see Appendix B) shows that the operational issues are early 2021 (see Appendix B) shows that the operational issues are
even more critical than for ISPs. even more critical than for ISPs.
Looking at current implementations, almost one third has dual-stacked Looking at current implementations, almost one third has dual-stacked
networks, while 20% declares that portions of their networks are networks, while 20% declares that portions of their networks are
IPv6-only. 35% of the enterprises are stuck at the training phase. IPv6-only. Additionally, 35% of the enterprises did not implement
In no case is the network fully IPv6-based. IPv6 at all or are stuck at the training phase. In no case is the
network fully based on IPv6.
Speaking of training, the most critical needs are in the field of Speaking of training, the most critical needs are in the field of
IPv6 security and IPv6 troubleshooting (both highlighted by the two IPv6 security and IPv6 troubleshooting (both highlighted by the two
thirds of respondents), followed by IPv6 fundamentals (57.41%). thirds of respondents), followed by address planning / network
configurations (57.41%).
Coming to implementation, the three areas of concern are IPv6 Coming to implementation, the three areas of concern are IPv6
security (31.48%), training (27.78%), application conversion security (31.48%), training (27.78%), and application conversion
(25.93%). 33.33% of respondents think that all three areas are all (25.93%), and 33.33% of respondents think that all three areas are
simultaneously of concern. all simultaneously of concern.
The full poll is reported in Appendix B. The full poll is reported in Appendix B.
3.3.1. Government and Universities 3.3.1. Government and Universities
This section focuses specifically on the IPv6 adoption of governments This section focuses specifically on the adoption of IPv6 in
and academia. governments and academia.
As far as governmental agencies are concerned, [NST_2] provides As far as governmental agencies are concerned, [NST_2] provides
analytics on the degree of IPv6 support for DNS, mail and websites analytics on the degree of IPv6 support for DNS, mail, and websites
across second level domains associated with the US federal agencies. across second-level domains associated with US federal agencies.
These domains are in the form of example.gov or example.fed. The 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 script used by [NST_2] has also been employed to measure the same
analytics in other countries: China [BGR_2], India [CNLABS_2] and the analytics in other countries, e.g., China [BGR_2], India [CNLABS_2],
European Union [IPv6Forum]. For this latter analytic some post- and the European Union [IPv6Forum]. For this latter analytic, some
processing is necessary to filter out the non-European domains. post-processing is necessary to filter out the non-European domains.
+--------------+----------+---------+---------+---------+ +====================+==================+=======+=======+=========+
|Country | Domains | DNS | Mail | Website | | Country | Domains analyzed | DNS | Mail | Website |
| | analyzed | | | | +====================+==================+=======+=======+=========+
+--------------+----------+---------+---------+---------+ | China | 52 | 0.0% | 0.0% | 98.1% |
|China | 52 | 0.0% | 0.0% | 98.1% | +--------------------+------------------+-------+-------+---------+
| | | | | | | European Union (*) | 19 | 47.4% | 0.0% | 21.1% |
+--------------+----------+---------+---------+---------+ +--------------------+------------------+-------+-------+---------+
|European | 19 | 47.4% | 0.0% | 21.1% | | India | 618 | 7.6% | 6.5% | 7.1% |
|Union (*) | | | | | +--------------------+------------------+-------+-------+---------+
+--------------+----------+---------+---------+---------+ | United States of | 1283 | 87.1% | 14.0% | 51.7% |
|India | 618 | 7.6% | 6.5% | 7.1% | | America | | | | |
| | | | | | +--------------------+------------------+-------+-------+---------+
+--------------+----------+---------+---------+---------+
|United States | 1283 | 87.1% | 14.0% | 51.7% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
Figure 8: IPv6 support for external-facing services across Table 8: IPv6 Support for External-Facing Services across
governmental institutions (January 2022) Governmental Institutions (as of January 2022)
(*) Both EU and country specific domains are considered. (*) Both EU and country-specific domains are considered.
USA's IPv6 support is higher than other countries. This is likely IPv6 support in the US is higher than other countries. This is
due to the IPv6 mandate set by [US-CIO]. In the case of India, the likely due to the IPv6 mandate set by [US-CIO]. In the case of
degree of support seems still quite low. This is also true for India, the degree of support seems still quite low. This is also
China, with the notable exception of high percentage of IPv6-enabled true for China, with the notable exception of a high percentage of
websites for government-related organizations. IPv6-enabled websites for government-related organizations.
Similar statistics are also available for higher education. [NST_3] Similar statistics are also available for higher education. [NST_3]
measures the data from second level domains of universities in the measures the data from second-level domains of universities in the
US, such as example.edu. [BGR_3] looks at Chinese education-related US, such as example.edu. [BGR_3] looks at Chinese education-related
domains. [CNLABS_1] analyzes domains in India (mostly third level), domains. [CNLABS_1] analyzes domains in India (mostly third level),
while [IPv6Forum] lists universities in the European Union (second while [IPv6Forum] lists universities in the European Union (second
level), again after filtering the non-European domains. level), again after filtering the non-European domains.
+--------------+----------+---------+---------+---------+ +================+==================+=======+=======+=========+
|Country | Domains | DNS | Mail | Website | | Country | Domains analyzed | DNS | Mail | Website |
| | analyzed | | | | +================+==================+=======+=======+=========+
+--------------+----------+---------+---------+---------+ | China | 111 | 36.9% | 0.0% | 77.5% |
|China | 111 | 36.9% | 0.0% | 77.5% | +----------------+------------------+-------+-------+---------+
| | | | | | | European Union | 118 | 83.9% | 43.2% | 35.6% |
+--------------+----------+---------+---------+---------+ +----------------+------------------+-------+-------+---------+
|European | 118 | 83.9% | 43.2% | 35.6% | | India | 100 | 31.0% | 54.0% | 5.0% |
|Union | | | | | +----------------+------------------+-------+-------+---------+
+--------------+----------+---------+---------+---------+ | United States | 346 | 49.1% | 19.4% | 21.7% |
|India | 100 | 31.0% | 54.0% | 5.0% | | of America | | | | |
| | | | | | +----------------+------------------+-------+-------+---------+
+--------------+----------+---------+---------+---------+
|United States | 346 | 49.1% | 19.4% | 21.7% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
Figure 9: IPv6 support for external-facing services across Table 9: IPv6 Support for External-Facing Services across
universities (January 2022) Universities (as of January 2022)
Overall, the universities have wider support of IPv6-based services Overall, the universities have wider support of IPv6-based services
compared to the other sectors. Apart from a couple of exceptions 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), (e.g., the support of IPv6 mail in China and IPv6 websites in India),
the numbers shown in the table above indicate a good support of IPv6 the numbers shown in the table above indicate good support of IPv6 in
in academia. academia.
4. IPv6 deployment scenarios 4. IPv6 Deployment Scenarios
The scope of this section is to discuss the network and service The scope of this section is to discuss the network and service
scenarios applicable for the transition to IPv6. Most of the related scenarios applicable for the transition to IPv6. Most of the related
definitions have been provided in Section 1.1. This clause is definitions have been provided in Section 1.1. This clause is
intended to focus on the technical and operational characteristics. intended to focus on the technical and operational characteristics.
The sequence of scenarios described here does not have necessarily to The sequence of scenarios described here does not necessarily have to
be intended as a road map for the IPv6 transition. Depending on be intended as a road map for the IPv6 transition. Depending on
their specific plans and requirements, service providers may either their specific plans and requirements, service providers may either
adopt the scenarios proposed in a sequence or jump directly to a adopt the scenarios proposed in a sequence or jump directly to a
specific one. specific one.
4.1. Dual-Stack 4.1. Dual-Stack
Based on the answers provided by network operators to the poll Based on the poll answers provided by network operators (Appendix A),
(Appendix A), Dual-Stack [RFC4213] appears to be currently the most Dual-Stack [RFC4213] appears to be currently the most widely deployed
widely deployed IPv6 solution (about 50%, see both Appendix A and the IPv6 solution (about 50%; see both Appendix A and the statistics
statistics reported in [ETSI-IP6-WhitePaper]). reported in [ETSI-IP6-WhitePaper]).
With Dual-Stack, IPv6 can be introduced together with other network With Dual-Stack, IPv6 can be introduced together with other network
upgrades and many parts of network management and IT systems can upgrades, and many parts of network management and IT systems can
still work in IPv4. This avoids major upgrade of such systems to 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 support IPv6, which is possibly the most difficult task in the IPv6
transition. The cost and effort on the network management and IT transition. The cost and effort on the network management and IT
systems upgrade are moderate. The benefits are to start using IPv6 systems upgrade are moderate. The benefits are to start using IPv6
and save NAT costs. and save NAT costs.
Although Dual-Stack may provide advantages in the introductory stage, Although Dual-Stack may provide advantages in the introductory stage,
it does have a few disadvantages in the long run, like the it does have a few disadvantages in the long run, like the
duplication of the network resources and states. It also requires duplication of the network resources and states. It also requires
more IPv4 addresses, thus increasing both Capital Expenses (CAPEX) more IPv4 addresses, thus increasing both Capital Expenses (CAPEX)
and Operating Expenses (OPEX). For example, even if private and Operating Expenses (OPEX). For example, even if private
addresses are used with Carrier-Grade NAT (CGN), there is extra addresses are used with Carrier-Grade NAT (CGN), there is extra
investment in the CGN devices, logs storage and help-desk to track investment in the CGN devices, logs storage, and help desk to track
CGN-related issues. CGN-related issues.
For this reason, when IPv6 usage exceeds certain threshold, it may be For this reason, when IPv6 usage exceeds a certain threshold, it may
advantageous to start a transition to a next scenario. For example, be advantageous to start a transition to the next scenario. For
the process may start with the IPv4aaS stage, as described example, the process may start with the IPv4aaS stage, as described
hereinafter. It is difficult to establish the criterion for hereinafter. It is difficult to establish the criterion for
switching (e.g. to properly identify the upper bound of the IPv4 switching (e.g., to properly identify the upper bound of the IPv4
decrease or the lower bound of the IPv6 increase). In addition to decrease or the lower bound of the IPv6 increase). In addition to
the technical factors, the switch to the next scenarios may also the technical factors, the switch to the next scenarios may also
cause a loss of customers. Based on the feedback of network cause a loss of customers. Based on the feedback of network
operators participating in World IPv6 Launch [WIPv6L] in June 2021, operators participating in the World IPv6 Launch [WIPv6L] in June
108 out of 346 operators exceed 50% of IPv6 traffic volume (31.2%), 2021, 108 out of 346 operators exceed 50% of IPv6 traffic volume
72 exceed 60% (20.8%), while 37 exceed 75% (10.7%). The consensus to (31.2%), 72 exceed 60% (20.8%), and 37 exceed 75% (10.7%). The
move to IPv6-only might be reasonable when IPv6 traffic volume is consensus to move to IPv6-only might be reasonable when IPv6 traffic
between 50% and 60%. volume is between 50% and 60%.
4.2. IPv6-only Overlay 4.2. IPv6-Only Overlay
As defined in Section 1.1, IPv6-only is generally associated with a As defined in Section 1.1, IPv6-only is generally associated with a
scope, e.g. IPv6-only overlay or IPv6-only underlay. scope, e.g., IPv6-only overlay or IPv6-only underlay.
The IPv6-only overlay denotes that the overlay tunnel between the end 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 points of a network is based only on IPv6. Tunneling provides a way
to use an existing IPv4 infrastructure to carry IPv6 traffic. IPv6 to use an existing IPv4 infrastructure to carry IPv6 traffic. IPv6
or IPv4 hosts and routers can tunnel IPv6 packets over IPv4 regions or IPv4 hosts and routers can tunnel IPv6 packets over IPv4 regions
by encapsulating them within IPv4 packets. The approach with by encapsulating them within IPv4 packets. The approach with
IPv6-only overlay helps to maintain compatibility with the existing IPv6-only overlay helps to maintain compatibility with the existing
base of IPv4, but it is not a long-term solution. base of IPv4, but it is not a long-term solution.
As a matter of fact, IPv4 reachability must be provided for a long 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 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 CGN to extend the life of IPv4 instead of going with IPv6-only
solutions. solutions.
4.3. IPv6-only Underlay 4.3. IPv6-Only Underlay
IPv6-only underlay network uses IPv6 as the network protocol for all The IPv6-only underlay network uses IPv6 as the network protocol for
traffic delivery. Both the control and data planes are IPv6-based. all traffic delivery. Both the control and data planes are based on
The definition of IPv6-only underlay needs to be associated with a IPv6. The definition of IPv6-only underlay needs to be associated
scope in order to identify the domain where it is applicable, such as with a scope in order to identify the domain where it is applicable,
IPv6-only access network or IPv6-only backbone network. such as the IPv6-only access network or IPv6-only backbone network.
When both enterprises and service providers begin to transit from an When both enterprises and service providers begin to transition from
IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not an IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not
necessarily need to dual-stack the underlay. Forwarding plane necessarily need to Dual-Stack the underlay. Forwarding plane
complexity on the Provider (P) nodes of the ISP core should be kept complexity on the Provider (P) nodes of the ISP core should be kept
simple as a single protocol only backbone. Hence, when operators simple as a backbone with a single protocol. Hence, when operators
decide to transit to an IPv6 underlay, the ISP backbone should be decide to transition to an IPv6 underlay, the ISP backbone should be
IPv6-only while Dual-Stack is not the best choice. The underlay IPv6-only because Dual-Stack is not the best choice. The underlay
could be IPv6-only and allows IPv4 packets to be tunneled using VPN could be IPv6-only and allow IPv4 packets to be tunneled using a VPN
over an IPv6-only backbone and leveraging [RFC8950], which specifies over an IPv6-only backbone while leveraging [RFC8950], which
the extensions necessary to allow advertising IPv4 Network Layer specifies the extensions necessary to allow advertising IPv4 Network
Routing Information (NLRI) with an IPv6 Next Hop. Layer Reachability Information (NLRI) with an IPv6 next hop.
IPv6-only underlay network deployment for access and backbone IPv6-only underlay network deployment for access and backbone
network, seems not the first option and the current trend is to keep networks seems to not be the first option, and the current trend is
IPv4/MPLS Data Plane and run IPv4/IPv6 Dual-Stack to edge nodes. to keep the IPv4/MPLS data plane and run IPv4/IPv6 Dual-Stack to edge
nodes.
As ISPs do the transition in the future to an IPv6-only access As ISPs do the transition in the future to an IPv6-only access
network or backbone network, e.g. Segment Routing over IPv6 data network or backbone network, e.g., Segment Routing over IPv6 (SRv6)
plane (SRv6), they start the elimination of IPv4 from the underlay data plane, they start the elimination of IPv4 from the underlay
transport network while continuing to provide IPv4 services. transport network while continuing to provide IPv4 services.
Basically, as also showed by the poll among network operators, from a Basically, as also shown by the poll among network operators, from a
network architecture perspective, it is not recommended to apply network architecture perspective, it is not recommended to apply
Dual-Stack to the transport network per reasons mentioned above Dual-Stack to the transport network per reasons mentioned above
related to the forwarding plane complexities. related to the forwarding plane complexities.
4.4. IPv4 as a Service 4.4. IPv4-as-a-Service
IPv4aaS can be used to ensure IPv4 support and it can be a complex IPv4aaS can be used to ensure IPv4 support, and it can be a complex
decision that depends on several factors, such as economic aspects, decision that depends on several factors, such as economic aspects,
policy and government regulation. policy, and government regulation.
[RFC9313] compares the merits of the most common transition solutions [RFC9313] compares the merits of the most common transition solutions
for IPv4aaS, i.e. 464XLAT [RFC6877], DS-lite [RFC6333], Lightweight for IPv4aaS, i.e., 464XLAT [RFC6877], DS-Lite [RFC6333], Lightweight
4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599], but 4over6 (lw4o6) [RFC7596], Mapping of Address and Port with
does not provide an explicit recommendation. However, the poll in Encapsulation (MAP-E) [RFC7597], and Mapping of Address and Port
Appendix A indicates that the most widely deployed IPv6 transition using Translation (MAP-T) [RFC7599], but does not provide an explicit
solution in the Mobile Broadband (MBB) domain is 464XLAT while in the recommendation. However, the poll in Appendix A indicates that the
Fixed Broadband (FBB) domain is DS-Lite. 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.
Both are IPv4aaS solutions by leveraging IPv6-only underlay. IPv4aaS Both are IPv4aaS solutions that leverage IPv6-only underlay. IPv4aaS
offers Dual-Stack service to users and allows an ISP to run IPv6-only offers Dual-Stack service to users and allows an ISP to run IPv6-only
in the network, typically the access network. in the network, typically the access network.
While it may not always be the case, IPv6-only transition While it may not always be the case, IPv6-only transition
technologies such as 464XLAT require far fewer IPv4 addresses technologies, such as 464XLAT, require far fewer IPv4 addresses
[RFC9313], because they make a more efficient usage without [RFC9313], because they are more efficient and do not restrict the
restricting the number of ports per subscriber. This helps to reduce number of ports per subscriber. This helps to reduce troubleshooting
troubleshooting costs and to remove some operational issues related costs and to remove some operational issues related to permanent
to permanent block-listing of IPv4 address blocks when used via CGN block listing of IPv4 address blocks when used via CGN in some
in some services. services.
IPv4aaS may be facilitated by the natural upgrade or replacement of IPv4aaS may be facilitated by the natural upgrade or replacement of
CPEs because of newer technologies (tripe-play, higher bandwidth WAN CPEs because of newer technologies (triple-play, higher bandwidth WAN
links, better Wi-Fi technologies, etc.). The CAPEX and OPEX of other links, better Wi-Fi technologies, etc.). The CAPEX and OPEX of other
parts of the network may be lowered (for example CGN and associated parts of the network may be lowered (for example, CGN and associated
logs) due to the operational simplification of the network. logs) due to the operational simplification of the network.
For deployments with a large number of users (e.g. large mobile For deployments with a large number of users (e.g., large mobile
operators) or a large number of hosts (e.g. large DCs), even the full operators) or a large number of hosts (e.g., large Data Centers
private address space [RFC1918] is not enough. Also, Dual-Stack will (DCs)), even the full private address space [RFC1918] is not enough.
likely lead to duplication of network resources and operations to Also, Dual-Stack will likely lead to duplication of network resources
support both IPv6 and IPv4, which increases the amount of state and operations to support both IPv6 and IPv4, which increases the
information in the network. This suggests that for scenarios such as amount of state information in the network. This suggests that, for
MBB or large DCs, IPv4aaS could be more efficient from the start of scenarios such as MBB or large DCs, IPv4aaS could be more efficient
the IPv6 introduction. from the start of the IPv6 introduction.
So, in general, when the Dual-Stack disadvantages outweigh the So, in general, when the Dual-Stack disadvantages outweigh the
IPv6-only complexity, it makes sense to transit to IPv4aaS. Some IPv6-only complexity, it makes sense to transition to IPv4aaS. Some
network operators already started this process, as in the case of network operators have already started this process, as in the case
[TMus], [RelJio] and [EE]. of [TMus], [RelJio], and [EE].
4.5. IPv6-only 4.5. IPv6-Only
IPv6-only is the final stage of the IPv6 transition and it happens 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 when a complete network, end to end, no longer has IPv4. No IPv4
address is configured for network management or anything. address is configured for network management or anything else.
Since IPv6-only means that both underlay network and overlay services Since IPv6-only means that both underlay networks and overlay
are only IPv6, it will take longer to happen. services are only IPv6, it will take longer to happen.
5. Common IPv6 Challenges 5. Common IPv6 Challenges
This section lists common IPv6 challenges, which have been validated This section lists common IPv6 challenges, which have been validated
and discussed during several meetings and public events. The scope and discussed during several meetings and public events. The scope
is to encourage more investigations. Despite IPv6 has already been is to encourage more investigations. Despite that IPv6 has already
well-proven in production, there are some challenges to consider. In been well proven in production, there are some challenges to
this regard, it is worth noting that [ETSI-GR-IPE-001] also discusses consider. In this regard, it is worth noting that [ETSI-GR-IPE-001]
gaps that still exist in IPv6 related use cases. also discusses gaps that still exist in IPv6-related use cases.
5.1. Transition Choices 5.1. Transition Choices
A service provider, an enterprise or a CSP may perceive quite a A service provider, an enterprise, or a CSP may perceive quite a
complex task the transition to IPv6, due to the many technical complex task with the transition to IPv6 due to the many technical
alternatives available and the changes required in management and alternatives available and the changes required in management and
operations. Moreover, the choice of the method to support the operations. Moreover, the choice of the method to support the
transition is an important challenge and may depend on factors transition is an important challenge and may depend on factors
specific to the context, such as the IPv6 network design that fits specific to the context, such as the IPv6 network design that fits
the service requirements, the network operations and the deployment the service requirements, the network operations, and the deployment
strategy. strategy.
This section briefly highlights the approaches that the different The subsections below briefly highlight the approaches that the
parties may take and the related challenges. different parties may take and the related challenges.
5.1.1. Service Providers 5.1.1. Service Providers: Fixed and Mobile Operators
For fixed operators, the massive software upgrade of CPEs to support For fixed operators, the massive software upgrade of CPEs to support
Dual-Stack already started in most of the service provider networks. Dual-Stack already started in most of the service provider networks.
On average, looking at the global statistics, the IPv6 traffic On average, looking at the global statistics, the IPv6 traffic
percentage is currently around 40% [G_stats]. As highlighted in percentage is currently around 40% [G_stats]. As highlighted in
section 3.2, all major content providers have already implemented Section 3.2, all major content providers have already implemented
Dual-Stack access to their services and most of them have implemented Dual-Stack access to their services, and most of them have
IPv6-only in their Data Centers. This aspect could affect the implemented IPv6-only in their Data Centers. This aspect could
decision on the IPv6 adoption for an operator, but there are also affect the decision on the IPv6 adoption for an operator, but there
other factors like the current IPv4 address shortage, CPE costs, CGN are also other factors, like the current IPv4 address shortage, CPE
costs and so on. costs, CGN costs, and so on.
Fixed Operators with a Dual-Stack architecture, can start defining * Fixed operators with a Dual-Stack architecture can start defining
and apply a new strategy when reaching the limit in terms of and applying a new strategy when reaching the limit in terms of
number of IPv4 addresses available. This may be done through CGN the number of IPv4 addresses available. This may be done through
or with an IPv4aaS approach. CGN or with an IPv4aaS approach.
Most of the fixed operators remain attached to a Dual-Stack * Most of the fixed operators remain attached to a Dual-Stack
architecture and many have already employed CGN. In this case it architecture, and many have already employed CGN. In this case,
is likely that CGN boosts their ability to supply IPv4 it is likely that CGN boosts their ability to supply IPv4
connectivity to CPEs for more years to come. Indeed, only few connectivity to CPEs for more years to come. Indeed, only few
fixed operators have chosen to move to an IPv6-only scenario. fixed operators have chosen to move to an IPv6-only scenario.
For mobile operators, the situation is quite different since, in some For mobile operators, the situation is quite different, since in some
cases, mobile operators are already stretching their IPv4 address cases, mobile operators are already stretching their IPv4 address
space. The reason is that CGN translation limits have been reached space. The reason is that CGN translation limits have been reached
and no more IPv4 public pool addresses are available. and no more IPv4 public pool addresses are available.
Some mobile operators choose to implement Dual-Stack as first and * Some mobile operators choose to implement Dual-Stack as a first
immediate mitigation solution. and immediate mitigation solution.
Other mobile operators prefer to move to IPv4aaS solutions (e.g. * Other mobile operators prefer to move to IPv4aaS solutions (e.g.,
464XLAT) since Dual-Stack only mitigates and does not solve 464XLAT) since Dual-Stack only mitigates and does not solve the
completely the IPv4 address scarcity issue. IPv4 address scarcity issue completely.
For both fixed and mobile operators the approach for the transition For both fixed and mobile operators, the approach for the transition
is not unique and this brings different challenges in relation to the is not unique, and this brings different challenges in relation to
network architecture and related costs. So each operator needs to do the network architecture and related costs; therefore, each operator
own evaluations for the transition based on the specific situation. needs to do their own evaluations for the transition based on the
specific situation.
5.1.2. Enterprises 5.1.2. Enterprises
At present, the usage of IPv6 for enterprises often relies on At present, the usage of IPv6 for enterprises often relies on
upstream service providers, since the enterprise connectivity depends upstream service providers, since the enterprise connectivity depends
on the services provided by their upstream provider. Regarding the on the services provided by their upstream provider. Regarding the
enterprises internal infrastructure, IPv6 shows its advantages in the enterprises' internal infrastructures, IPv6 shows its advantages in
case of merger and acquisition, because it can be avoided the the case of a merger and acquisition, because it can be avoided by
overlapping of the two address spaces, which is common in case of the overlapping of the two address spaces, which is common in case of
IPv4 private addresses. In addition, since several governments are IPv4 private addresses. In addition, since several governments are
introducing IPv6 policy, all the enterprises providing consulting introducing IPv6 policies, all the enterprises providing consulting
service to governments are also required to support IPv6. services to governments are also required to support IPv6.
However, enterprises face some challenges. They are shielded from However, enterprises face some challenges. They are shielded from
IPv4 address depletion issues due to their prevalent use of Proxy and IPv4 address depletion issues due to their prevalent use of proxy and
private addressing [RFC1918], thus do not have the business private addressing [RFC1918]; thus, they do not have the business
requirement or technical justification to transit to IPv6. requirement or technical justification to transition to IPv6.
Enterprises need to find a business case and a strong motivation for Enterprises need to find a business case and a strong motivation to
IPv6 transition to justify additional CAPEX and OPEX. Also, since transition to IPv6 to justify additional CAPEX and OPEX. Also, since
Information and Communication Technologies (ICT) is not the core Information and Communication Technologies (ICTs) are not the core
business for most of the enterprises, ICT budget is often constrained business for most of the enterprises, the ICT budget is often
and cannot expand considerably. But, there are examples of big constrained and cannot expand considerably. However, there are
enterprises that are considering IPv6 to achieve business targets examples of big enterprises that are considering IPv6 to achieve
through a more efficient IPv6 network and to introduce newer services business targets through a more efficient IPv6 network and to
which require IPv6 network architecture. introduce newer services that require IPv6 network architecture.
Enterprises worldwide, in particular small and medium-sized, are Enterprises worldwide, in particular small- and medium-sized
quite late to adopt IPv6, especially on internal networks. In most enterprises, are quite late to adopt IPv6, especially on internal
cases, the enterprise engineers and technicians do not have a great networks. In most cases, the enterprise engineers and technicians do
experience with IPv6 and the problem of application porting to IPv6 not have a great experience with IPv6, and the problem of application
looks quite difficult. As highlighted in the relevant poll, the porting to IPv6 looks quite difficult. As highlighted in the
technicians may need to get trained but the management do not see a relevant poll, the technicians may need to be trained, but the
business need for adoption. This creates an unfortunate cycle where management does not see a business need for adoption. This creates
the perceived complexity of the IPv6 protocol and concerns about an unfortunate cycle where the perceived complexity of the IPv6
security and manageability combine with the lack of urgent business protocol and concerns about security and manageability combine with
needs to prevent adoption of IPv6. In 2019 and 2020, there has been the lack of urgent business needs to prevent adoption of IPv6. In
a concerted effort by some ARIN and APNIC initiatives to provide 2019 and 2020, there has been a concerted effort by some ARIN and
training [ARIN-CG] [ISIF-ASIA-G]. APNIC initiatives to provide training [ARIN-CG] [ISIF-ASIA-G].
5.1.3. Industrial Internet 5.1.3. Industrial Internet
In an industrial environment, OT (Operational technology) refers to In an industrial environment, Operational Technology (OT) refers to
the systems used to monitor and control processes within a factory or the systems used to monitor and control processes within a factory or
production environment, while IT (Information technology) refers to production environment, while Information Technology (IT) refers to
anything related to computer technology and networking connectivity. anything related to computer technology and networking connectivity.
IPv6 is frequently mentioned in relation to Industry 4.0 and Internet IPv6 is frequently mentioned in relation to Industry 4.0 and the
of Things (IoT), affecting both OT and IT evolution. Internet of Things (IoT), affecting the evolution of both OT and IT.
There are potential advantages for using IPv6 for Industrial Internet There are potential advantages for using IPv6 for the Industrial
of Things (IIoT), in particular the large IPv6 address space, the Internet of Things (IIoT), in particular, the large IPv6 address
automatic IPv6 address configuration and resource discovery. space, the automatic IPv6 address configuration, and resource
However, its industrial adoption, in particular in smart discovery. However, its industrial adoption, in particular, in smart
manufacturing systems, has been much slower than expected. There are manufacturing systems, has been much slower than expected. There are
still many obstacles and challenges that prevent its pervasive use. still many obstacles and challenges that prevent its pervasive use.
The key problems identified are the incomplete or underdeveloped tool The key problems identified are the incomplete or underdeveloped tool
support, the dependency on manual configuration and the poor support, the dependency on manual configuration, and the poor
knowledge of the IPv6 protocols. To promote the use of IPv6 for knowledge of the IPv6 protocols. To promote the use of IPv6 for
smart manufacturing systems and IIoT applications a generic approach smart manufacturing systems and IIoT applications, a generic approach
to remove these pain points is highly desirable. Indeed, as for to remove these pain points is highly desirable. Indeed, as for
enterprises, it is important to provide an easy way to familiarize enterprises, it is important to provide an easy way to familiarize
system architects and software developers with the IPv6 protocol. system architects and software developers with the IPv6 protocol.
Advances in cloud-based platforms and developments in artificial Advances in cloud-based platforms and developments in artificial
intelligence (AI) and machine learning (ML) allow OT and IT systems intelligence (AI) and machine learning (ML) allow OT and IT systems
to integrate and migrate to a centralized analytical, processing, and to integrate and migrate to a centralized analytical, processing, and
integrated platform, which must act in real-time. The limitation is integrated platform, which must act in real time. The limitation is
that manufacturing companies have diverse corporate cultures and the that manufacturing companies have diverse corporate cultures, and the
adoption of new technologies may lag as a result. adoption of new technologies may lag as a result.
For Industrial Internet and related IIoT applications, it would be For Industrial Internet and related IIoT applications, it would be
desirable to leverage the configuration-less characteristic of IPv6 desirable to leverage the configurationless characteristic of IPv6 to
to automatically manage and control the IoT devices. In addition, it automatically manage and control the IoT devices. In addition, it
could be interesting to have the ability to use IP based could be interesting to have the ability to use IP-based
communication and standard application protocols at every point in communication and standard application protocols at every point in
the production process and further reduce the use of specialized the production process and further reduce the use of specialized
communication systems. communication systems.
5.1.4. Content and Cloud Service Providers 5.1.4. Content and Cloud Service Providers
The high number of addresses required to connect the virtual and The high number of addresses required to connect the virtual and
physical elements in a Data Center and the necessity to overcome the physical elements in a Data Center and the necessity to overcome the
limitation posed by [RFC1918] have been the drivers to the adoption limitation posed by [RFC1918] have been the drivers to the adoption
of IPv6 in several CSP networks. of IPv6 in several CSP networks.
skipping to change at page 24, line 28 skipping to change at line 1081
Several public references, as reported hereinafter, discuss how most Several public references, as reported hereinafter, discuss how most
of the major players find themselves at different stages in the of the major players find themselves at different stages in the
transition to IPv6-only in their Data Center (DC) infrastructure. In transition to IPv6-only in their Data Center (DC) infrastructure. In
some cases, the transition already happened and the DC infrastructure some cases, the transition already happened and the DC infrastructure
of these hyperscalers is completely based on IPv6. of these hyperscalers is completely based on IPv6.
It is interesting to look at how much traffic in a network is going It is interesting to look at how much traffic in a network is going
to Caches and Content Delivery Networks (CDNs). The response is to Caches and Content Delivery Networks (CDNs). The response is
expected to be a high percentage, at least higher than 50% in most of expected to be a high percentage, at least higher than 50% in most of
the cases, since all the key Caches and CDNs are IPv6-ready [Cldflr], the cases, since all the key Caches and CDNs are ready for IPv6
[Ggl], [Ntflx], [Amzn], [Mcrsft], [Vrzn]. So the percentage of [Cldflr] [Ggl] [Ntflx] [Amzn] [Mcrsft]. So the percentage of traffic
traffic going to the key Caches/CDNs is a good approximation of the going to the key Caches/CDNs is a good approximation of the potential
potential IPv6 traffic in a network. IPv6 traffic in a network.
The challenges for CSPs are mainly related to the continuous support The challenges for CSPs are mainly related to the continuous support
of IPv4 to be guaranteed, since most CSPs already completed the of IPv4 to be guaranteed, since most CSPs already completed the
transition to IPv6-only. If, in the next years, the scarcity of IPv4 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 addresses becomes more evident, it is likely that the cost of buying
an IPv4 address by a CSP could be charged to their customers. an IPv4 address by a CSP could be charged to their customers.
5.1.5. CPEs and user devices 5.1.5. CPEs and User Devices
It can be noted that most of the user devices (e.g. smartphones) are It can be noted that most of the user devices (e.g., smartphones)
already IPv6-enabled since many years. But there are exceptions, for have been IPv6 enabled for many years. But there are exceptions, for
example, smartTVs typically had IPv6 support since few years ago, example, for the past few years, smart TVs have typically had IPv6
however not all the economies replace them at the same pace. support; however, not all the economies replace them at the same
pace.
As already mentioned, ISPs who historically provided public IPv4 As already mentioned, ISPs who historically provided public IPv4
addresses to their customers generally still have those IPv4 addresses to their customers generally still have those IPv4
addresses (unless they chose to transfer them). Some have chosen to addresses (unless they chose to transfer them). Some have chosen to
put new customers on CGN but without touching existing customers. put new customers on CGN but without touching existing customers.
Because of the extreme small number of customers who notice that IPv4 Because of the extremely small number of customers who notice that
is done via NAT444 (i.e. the preferred CGN solution for carriers), it IPv4 is done via NAT444 (i.e., the preferred CGN solution for
could be less likely to run out of IPv4 addresses and private IPv4 carriers), it could be less likely to run out of IPv4 addresses and
space. But as IPv4-only devices and traffic reduce, then the need to private IPv4 space. But as IPv4-only devices and traffic reduce, the
support private and public IPv4 become less. So the complete support need to support private and public IPv4 lessens. So to have CPEs
of CPEs to IPv6 is also an important challenge and incentive to completely support IPv6 serves as an important challenge and
overcome Dual-Stack towards IPv4aaS solution [ANSI]. incentive to choose IPv4aaS solutions [ANSI] over Dual-Stack.
5.1.6. Software Applications 5.1.6. Software Applications
The transition to IPv6 requires that the application software is The transition to IPv6 requires that the application software is
adapted for use in IPv6-based networks ([ARIN-SW] provides an adapted for use in IPv6-based networks ([ARIN-SW] provides an
example). The use of transition mechanisms like 464XLAT is essential example). The use of transition mechanisms like 464XLAT is essential
to support IPv4-only applications while they evolve to IPv6. to support IPv4-only applications while they evolve to IPv6.
Depending on the transition mechanism employed some issues may Depending on the transition mechanism employed, some issues may
remain. For example, in the case of NAT64/DNS64 the use of literal remain. For example, in the case of NAT64/DNS64, the use of literal
IPv4 addresses, instead of DNS names, will fail, unless mechanisms IPv4 addresses, instead of DNS names, will fail unless mechanisms
such as Application Level Gateways (ALG) are used. This issue is not such as Application Level Gateways (ALGs) are used. This issue is
present in 464XLAT (see [RFC8683]). not present in 464XLAT (see [RFC8683]).
It is worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect It is worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect
of application transition to IPv6. of application transition to IPv6.
5.2. Network Management and Operations 5.2. Network Management and Operations
There are important IPv6 complementary solutions related to There are important IPv6 complementary solutions related to
Operations, Administration and Maintenance (OAM) that look less Operations, Administration, and Maintenance (OAM) that look less
mature compared to IPv4. Network Management System (NMS) has a mature compared to IPv4. A Network Management System (NMS) has a
central role in the modern networks for both network operators and central role in the modern networks for both network operators and
enterprises and its transition is a fundamental issue. This is enterprises, and its transition is a fundamental issue. This is
because some IPv6 products are not as field-proven as for IPv4 even because some IPv6 products are not as field proven as IPv4 products,
if conventional protocols (e.g. SNMP, RADIUS) already support IPv6. even if conventional protocols (e.g., SNMP and RADIUS) already
In addition, incompatible vendor road map for the development of new support IPv6. In addition, an incompatible vendor road map for the
NMS features affects the confidence of network operators or development of new NMS features affects the confidence of network
enterprises. operators or enterprises.
An important factor is represented by the need for training the An important factor is represented by the need for training the
network operations workforce. Deploying IPv6 requires that policies network operations workforce. Deploying IPv6 requires that policies
and procedures have to be adjusted in order to successfully plan and and procedures have to be adjusted in order to successfully plan and
complete an IPv6 transition. Staff has to be aware of the best complete an IPv6 transition. Staff has to be aware of the best
practices for managing IPv4 and IPv6 assets. In addition to network practices for managing IPv4 and IPv6 assets. In addition to network
nodes, network management applications and equipment need to be nodes, network management applications and equipment need to be
properly configured and in some cases also replaced. This may properly configured and, in some cases, also replaced. This may
introduce more complexity and costs for the transition. introduce more complexity and costs for the transition.
Availability of both systems and training is necessary in areas such Availability of both systems and training is necessary in areas such
as IPv6 addressing. IPv6 addresses can be assigned to an interface as IPv6 addressing. IPv6 addresses can be assigned to an interface
through different means, such as Stateless Auto-Configuration (SLAAC) through different means, such as Stateless Auto-Configuration (SLAAC)
[RFC4862], or by using stateful Dynamic Host Control Protocol (DHCP) [RFC4862], or by using the stateful Dynamic Host Configuration
[RFC8415]. IP Address Management (IPAM) systems may contribute to Protocol (DHCP) [RFC8415]. IP Address Management (IPAM) systems may
handle the technical differences and automate some of the contribute by handling the technical differences and automating some
configuration tasks, such as the address assignment or the management of the configuration tasks, such as the address assignment or the
of DHCP services. management of DHCP services.
5.3. Performance 5.3. Performance
People tend to compare the performance of IPv6 versus IPv4 to argue People tend to compare the performance of IPv6 versus IPv4 to argue
or motivate the IPv6 transition. In some cases, IPv6 behaving or motivate the IPv6 transition. In some cases, IPv6 behaving
"worse" than IPv4 may be used as an argument for avoiding the full "worse" than IPv4 may be used as an argument for avoiding the full
adoption of IPv6. However, there are some aspects where IPv6 has adoption of IPv6. However, there are some aspects where IPv6 has
already filled (or is filling) the gap to IPv4. This position is already filled (or is filling) the gap to IPv4. This position is
supported when looking at available analytics on two critical supported when looking at available analytics on two critical
parameters: packet loss and latency. These parameters have been parameters: packet loss and latency. These parameters have been
constantly monitored over time, but only a few comprehensive constantly monitored over time, but only a few comprehensive
measurement campaigns are providing up-to-date information. While measurement campaigns are providing up-to-date information. While
performance is undoubtedly an important issue to consider and worth performance is undoubtedly an important issue to consider and worth
further investigation, reality is that a definitive answer cannot be further investigation, the reality is that a definitive answer cannot
found on what IP version performs better. Depending on the specific be found on what IP version performs better. Depending on the
use case and application, IPv6 is better; in others the same applies specific use case and application, IPv6 is better; in others, the
to IPv4. same applies to IPv4.
5.3.1. IPv6 packet loss and latency 5.3.1. IPv6 Packet Loss and Latency
[APNIC5] provides a measurement of both the failure rate and Round [APNIC5] provides a measurement of both the failure rate and Round-
Trip Time (RTT) of IPv6 compared against IPv4. Both measures are Trip Time (RTT) of IPv6 compared against IPv4. Both measures are
based on scripts that employs the three-way handshake of TCP. As based on scripts that employ the three-way handshake of TCP. As
such, the measurement of the failure rate does not provide a direct such, the measurement of the failure rate does not provide a direct
measurement of packet loss (that would need an Internet-wide measurement of packet loss (which would need an Internet-wide
measurement campaign). Said that, despite IPv4 is still performing measurement campaign). That said, despite that IPv4 is still
better, the difference seems to have decreased in recent years. Two performing better, the difference seems to have decreased in recent
reports, namely [RIPE1] and [APRICOT], discussed the associated years. Two reports, namely [RIPE1] and [APRICOT], discussed the
trend, showing how the average worldwide failure rate of IPv6 is associated trend, showing how the average worldwide failure rate of
still a bit worse than IPv4. Reasons for this effect may be found in IPv6 is still a bit worse than IPv4. Reasons for this effect may be
endpoints with an unreachable IPv6 address, routing instability or found in endpoints with an unreachable IPv6 address, routing
firewall behavior. Yet, this worsening effect may appear as instability, or firewall behavior. Yet, this worsening effect may
disturbing for a plain transition to IPv6. appear as disturbing for a plain transition to IPv6.
[APNIC5] also compares the latency of both address families. [APNIC5] also compares the latency of both address families.
Currently, the worldwide average is slightly in favor of IPv6. Currently, the worldwide average is slightly in favor of IPv6.
Zooming at the country or even at the operator level, it is possible Zooming at the country or even at the operator level, it is possible
to get more detailed information and appreciate that cases exist to get more detailed information and appreciate that cases exist
where IPv6 is faster than IPv4. Regions (e.g. Western Europe, where IPv6 is faster than IPv4. Regions (e.g., Western Europe,
Northern America, Southern Asia) and Countries (e.g. US, India, Northern America, and Southern Asia) and countries (e.g., US, India,
Germany) with an advanced deployment of IPv6 (e.g. >45%) are showing and Germany) with an advanced deployment of IPv6 (e.g., greater than
that IPv6 has better performance than IPv4. [APRICOT] highlights how 45%) are showing that IPv6 has better performance than IPv4.
when a difference in performance exists it is often related to [APRICOT] highlights how when a difference in performance exists, it
asymmetric routing issues. Other possible explanations for a is often related to asymmetric routing issues. Other possible
relative latency difference lies on the specificity of the IPv6 explanations for a relative latency difference relate to the
header which allows packet fragmentation. In turn, this means that specificity of the IPv6 header, which allows packet fragmentation.
hardware needs to spend cycles to analyze all of the header sections In turn, this means that hardware needs to spend cycles to analyze
and when it is not capable of handling one of them it drops the all of the header sections, and when it is not capable of handling
packet. A few measurement campaigns on the behavior of IPv6 in CDNs one of them, it drops the packet. A few measurement campaigns on the
are also available [MAPRG], [INFOCOM]. The TCP connect time is still behavior of IPv6 in CDNs are also available [MAPRG] [INFOCOM]. The
higher for IPv6 in both cases, even if the gap has reduced over the TCP connection time is still higher for IPv6 in both cases, even if
analysis time window. the gap has reduced over the analysis time window.
5.3.2. Customer Experience 5.3.2. Customer Experience
It is not totally clear if the Customer Experience is in some way 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 perceived as better when IPv6 is used instead of IPv4. In some
it has been publicly reported by IPv6 content providers, that users cases, it has been publicly reported by IPv6 content providers that
have a better experience when using IPv6-only compared to IPv4 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 [ISOC2]. This could be explained because, in the case of an IPv6
connecting to an application hosted in an IPv6-only Data Centers, the user connecting to an application hosted in an IPv6-only Data Center,
connection is end-to-end, without translations. Instead, when using the connection is end to end, without translations. Instead, when
IPv4 there is a NAT translation either in the CPE or in the service using IPv4, there is a NAT translation either in the CPE or in the
provider's network, in addition to IPv4 to IPv6 (and back to IPv4) service provider's network, in addition to IPv4 to IPv6 (and back to
translation in the IPv6-only content provider Data Center. [ISOC2], IPv4) translation in the IPv6-only content provider Data Center.
[FB] provide reasons in favor of IPv6. In other cases, the result [ISOC2] and [FB] provide reasons in favor of IPv6. In other cases,
seems to be still slightly in favor of IPv4 [INFOCOM], [MAPRG], even the result seems to be still slightly in favor of IPv4 [INFOCOM]
if the difference between IPv4 and IPv6 tends to vanish over time. [MAPRG], even if the difference between IPv4 and IPv6 tends to vanish
over time.
5.4. IPv6 security and privacy 5.4. IPv6 Security and Privacy
An important point that is sometimes considered as a challenge when An important point that is sometimes considered as a challenge when
discussing the transition to IPv6 is related to the security and discussing the transition to IPv6 is related to the security and
privacy. [RFC9099] analyzes the operational security issues in privacy. [RFC9099] analyzes the operational security issues in
several places of a network (enterprises, service providers and several places of a network (enterprises, service providers, and
residential users). It is also worth considering the additional residential users). It is also worth considering the additional
security issues brought by the applied IPv6 transition technologies security issues brought by the applied IPv6 transition technologies
used to implement IPv4aaS (e.g. 464XLAT, DS-Lite) [ComputSecur]. used to implement IPv4aaS (e.g., 464XLAT and DS-Lite) [ComputSecur].
The security aspects have to be considered to keep at least the same 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 or even a better, level of security as it exists nowadays in an IPv4
network environment. The autoconfiguration features of IPv6 will network environment. The autoconfiguration features of IPv6 will
require some more attention. Router discovery and address require some more attention. Router discovery and address
autoconfiguration may produce unexpected results and security holes. autoconfiguration may produce unexpected results and security holes.
IPsec protects IPv6 traffic at least as well as it does IPv4, and the IPsec protects IPv6 traffic at least as well as it does IPv4, and the
security protocols for constrained devices (IoT) are designed for security protocols for constrained devices (IoT) are designed for
IPv6 operation. IPv6 operation.
IPv6 was designed to restore the end-to-end model of communications IPv6 was designed to restore the end-to-end model of communications
with all nodes on networks using globally unique addresses. But, with all nodes on networks using globally unique addresses. But
considering this, IPv6 may imply privacy concerns, due to greater considering this, IPv6 may imply privacy concerns due to greater
visibility on the Internet. IPv6 nodes can (and typically do) use visibility on the Internet. IPv6 nodes can (and typically do) use
privacy extensions [RFC8981] to prevent any tracking of their burned- privacy extensions [RFC8981] to prevent any tracking of their burned-
in MAC address(es), which are easily readable in the original in Media Access Control (MAC) address(es), which are easily readable
modified EUI-64 interface identifier format. But, on the other hand, in the original modified 64-bit Extended Unique Identifier (EUI-64)
stable IPv6 interface identifiers ([RFC8064]) were developed and this interface identifier format. On the other hand, stable IPv6
can also affect privacy. interface identifiers [RFC8064] were developed, and this can also
affect privacy.
As reported in [ISOC3], comparing IPv6 and IPv4 at the protocol As reported in [ISOC3], in comparing IPv6 and IPv4 at the protocol
level, one may probably conclude that the increased complexity of level, one may probably conclude that the increased complexity of
IPv6 results in an increased number of attack vectors, that imply IPv6 will result in an increased number of attack vectors that imply
more possible ways to perform different types of attacks. However, a more possible ways to perform different types of attacks. However, a
more interesting and practical question is how IPv6 deployments more interesting and practical question is how IPv6 deployments
compare to IPv4 deployments in terms of security. In that sense, compare to IPv4 deployments in terms of security. In that sense,
there are a number of aspects to consider. there are a number of aspects to consider.
Most security vulnerabilities related to network protocols are based Most security vulnerabilities related to network protocols are based
on implementation flaws. Typically, security researchers find on implementation flaws. Typically, security researchers find
vulnerabilities in protocol implementations, which eventually are vulnerabilities in protocol implementations, which eventually are
"patched" to mitigate such vulnerabilities. Over time, this process "patched" to mitigate such vulnerabilities. Over time, this process
of finding and patching vulnerabilities results in more robust of finding and patching vulnerabilities results in more robust
implementations. For obvious reasons, the IPv4 protocols have implementations. For obvious reasons, the IPv4 protocols have
benefited from the work of security researchers for much longer, and benefited from the work of security researchers for much longer, and
thus, IPv4 implementations are generally more robust than IPv6. thus IPv4 implementations are generally more robust than IPv6.
However, with more IPv6 deployment, IPv6 will also benefit from this However, with more IPv6 deployment, IPv6 will also benefit from this
process in the long run. It is also worth mentioning that most process in the long run. It is also worth mentioning that most
vulnerabilities are nowadays in the human being and in the vulnerabilities nowadays are caused by human beings and are in the
application layer and not in the IP layer. application layer, not the IP layer.
Besides the intrinsic properties of the protocols, the security level Besides the intrinsic properties of the protocols, the security level
of the resulting deployments is closely related to the level of of the resulting deployments is closely related to the level of
expertise of network and security engineers. In that sense, there is expertise of network and security engineers. In that sense, there is
obviously much more experience and confidence with deploying and obviously much more experience and confidence with deploying and
operating IPv4 networks than with deploying and operating IPv6 operating IPv4 networks than with deploying and operating IPv6
networks. networks.
5.4.1. Protocols security issues 5.4.1. Protocols' Security Issues
In general, there are security concerns related to IPv6 that can be In general, there are security concerns related to IPv6 that can be
classified as follows: classified as follows:
* Basic IPv6 protocol (Basic header, Extension Headers, Addressing) * Basic IPv6 protocol (basic header, extension headers, addressing)
* IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) * IPv6-associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)
* Internet-wide IPv6 security (Filtering, DDoS, Transition
Mechanisms) * Internet-wide IPv6 security (filtering, DDoS, transition
mechanisms)
ICMPv6 is an integral part of IPv6 and performs error reporting and ICMPv6 is an integral part of IPv6 and performs error reporting and
diagnostic functions. Neighbor Discovery Protocol (NDP) is a node diagnostic functions. The Neighbor Discovery Protocol (NDP) is a
discovery protocol in IPv6 which replaces and enhances functions of node discovery protocol in IPv6, which replaces and enhances
ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers for functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6
discovering multicast listeners on a directly attached link, much routers for discovering multicast listeners on a directly attached
like Internet Group Management Protocol (IGMP) is used in IPv4. link, much like how the Internet Group Management Protocol (IGMP) is
used in IPv4.
These IPv6 associated protocols like ICMPv6, NDP and MLD are These IPv6-associated protocols, like ICMPv6, NDP, and MLD, are
something new compared to IPv4, so they add new security threats and something new compared to IPv4, so they add new security threats and
the related solutions are still under discussion today. NDP has the related solutions are still under discussion today. NDP has
vulnerabilities [RFC3756] [RFC6583]. The specification says to use vulnerabilities [RFC3756] [RFC6583]. [RFC3756] says to use IPsec,
IPsec but it is impractical and not used, on the other hand, SEND but it is impractical and not used; on the other hand, SEcure
(SEcure Neighbour Discovery) [RFC3971] is not widely available. It Neighbor Discovery (SEND) [RFC3971] is not widely available. It is
is worth mentioning that applying host isolation may address many of worth mentioning that applying host isolation may address many of
these concerns, as described in [I-D.ietf-v6ops-nd-considerations]. these concerns, as described in [ND-CONSIDERATIONS].
[RIPE2] describes the most important threats and solutions regarding [RIPE2] describes the most important threats and solutions regarding
IPv6 security. IPv6 security.
5.4.1.1. IPv6 Extension Headers and Fragmentation 5.4.1.1. IPv6 Extension Headers and Fragmentation
IPv6 Extension Headers provide a hook for interesting new features to IPv6 extension headers provide a hook for interesting new features to
be added, and are more flexible than IPv4 Options. This does add be added and are more flexible than IPv4 options. This does add some
some complexity, and in particular some security mechanisms may complexity. In particular, some security mechanisms may require
require to process the full chain of headers, and some firewalls may processing the full chain of headers, and some firewalls may require
require to filter packets based on their Extension Headers. filtering packets based on their extension headers. Additionally,
Additionally, packets with IPv6 Extension Headers may be dropped in packets with IPv6 extension headers may be dropped in the public
the public Internet [RFC7872]. Some documents, e.g. Internet [RFC7872]. Some documents, e.g., [HBH-PROCESSING],
[I-D.ietf-6man-hbh-processing], [I-D.ietf-v6ops-hbh], [HBH-OPT-HDR], and [IPv6-EXT-HDR], analyze and provide guidance
[I-D.bonica-6man-ext-hdr-update], analyze and provide guidance regarding the processing procedures of IPv6 extension headers.
regarding the processing procedures of IPv6 Extension Headers.
Defense against possible attacks through Extension Headers is Defense against possible attacks through extension headers is
necessary. For example, the original IPv6 Routing Header type 0 necessary. For example, the original IPv6 Routing Header type 0
(RH0) was deprecated because of possible remote traffic amplification (RH0) was deprecated because of possible remote traffic amplification
[RFC5095]. In addition, it is worth mentioning that unrecognized [RFC5095]. In addition, it is worth mentioning that the unrecognized
Hop-by-Hop Options Header and Destination Options Header will not be 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 considered by the nodes if they are not configured to deal with it
[RFC8200]. Other attacks based on Extension Headers may be based on [RFC8200]. Other attacks based on extension headers may be based on
IPv6 Header Chains and Fragmentation that could be used to bypass IPv6 header chains and fragmentation that could be used to bypass
filtering. To mitigate this effect, the initial IPv6 Header, the filtering. To mitigate this effect, the initial IPv6 header, the
Extension Headers and the Upper-Layer Header must all be in the first extension headers, and the upper-layer header must all be in the
fragment [RFC8200]. Also, the use of the IPv6 Fragmentation Header first fragment [RFC8200]. Also, the use of the IPv6 fragment header
is forbidden in all Neighbor Discovery messages [RFC6980]. is forbidden in all Neighbor Discovery messages [RFC6980].
Fragment Header is used by IPv6 source node to send a packet bigger The fragment header is used by the IPv6 source node to send a packet
than path MTU and the Destination host processes fragment headers. bigger than the path MTU, and the destination host processes fragment
There are several threats related to fragmentation to pay attention headers. There are several threats related to fragmentation to pay
to e.g. overlapping fragments (not allowed) resource consumption attention to, e.g., overlapping fragments (not allowed), resource
while waiting for last fragment (to discard), atomic fragments (to be consumption while waiting for the last fragment (to discard), and
isolated). atomic fragments (to be isolated).
The operational implications of IPv6 Packets with Extension Headers The operational implications of IPv6 packets with extension headers
are further discussed in [RFC9098]. are further discussed in [RFC9098].
6. Security Considerations 6. IANA Considerations
This document has no IANA actions.
7. Security Considerations
This document has no impact on the security properties of specific This document has no impact on the security properties of specific
IPv6 protocols or transition tools. In addition to the discussion IPv6 protocols or transition tools. In addition to the discussion
above in Section 5.4, the security considerations relating to the above in Section 5.4, the security considerations relating to the
protocols and transition tools are described in the relevant protocols and transition tools are described in the relevant
documents. documents.
7. Contributors 8. References
Nalini Elkins
Inside Products
Email: nalini.elkins@insidethestack.com
Sébastien Lourdez
Post Luxembourg
Email: sebastien.lourdez@post.lu
8. Acknowledgements
The authors of this document would like to thank Brian Carpenter,
Fred Baker, Alexandre Petrescu, Fernando Gont, Barbara Stark,
Haisheng Yu(Johnson), Dhruv Dhody, Gabor 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.
9. IANA Considerations
This document has no actions for IANA.
10. References
10.1. Normative References 8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>. <https://www.rfc-editor.org/info/rfc3756>.
skipping to change at page 33, line 5 skipping to change at line 1461
"Operational Security Considerations for IPv6 Networks", "Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021, RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/info/rfc9099>. <https://www.rfc-editor.org/info/rfc9099>.
[RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R., [RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
and I. Farrer, "Pros and Cons of IPv6 Transition and I. Farrer, "Pros and Cons of IPv6 Transition
Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313, Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
DOI 10.17487/RFC9313, October 2022, DOI 10.17487/RFC9313, October 2022,
<https://www.rfc-editor.org/info/rfc9313>. <https://www.rfc-editor.org/info/rfc9313>.
10.2. Informative References 8.2. Informative References
[Akm-stats] [Akm-stats]
Akamai, "IPv6 Adoption Visualization", 2021, Akamai, "IPv6 Adoption Visualization", 2023,
<https://www.akamai.com/uk/en/resources/our-thinking/ <https://www.akamai.com/uk/en/resources/our-thinking/
state-of-the-internet-report/state-of-the-internet-ipv6- state-of-the-internet-report/state-of-the-internet-ipv6-
adoption-visualization.jsp>. adoption-visualization>.
[Alx] Alexa, "The top 500 sites on the web", 2021,
<https://www.alexa.com/topsites>.
[Amzn] Amazon, "Announcing Internet Protocol Version 6 (IPv6) [Amzn] Amazon Web Services, "Announcing Internet Protocol Version
support for Amazon CloudFront, AWS WAF, and Amazon S3 6 (IPv6) support for Amazon CloudFront, AWS WAF, and
Transfer Acceleration", <https://aws.amazon.com/es/about- Amazon S3 Transfer Acceleration", October 2016,
aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and- <https://aws.amazon.com/es/about-aws/whats-new/2016/10/
s3-transfer-acceleration/>. ipv6-support-for-cloudfront-waf-and-s3-transfer-
acceleration/>.
[ANSI] ANSI/CTA, "ANSI/CTA Standard Host and Router Profiles for [ANSI] ANSI, "Host and Router Profiles for IPv6", ANSI/
IPv6", 2020, <https://shop.cta.tech/products/host-and- CTA 2048-A, October 2020, <https://shop.cta.tech/products/
router-profiles-for-ipv6>. host-and-router-profiles-for-ipv6>.
[APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2022, [APNIC1] APNIC Labs, "IPv6 Capable Rate by country (%)",
<https://stats.labs.apnic.net/ipv6>. <https://stats.labs.apnic.net/ipv6>.
[APNIC2] APNIC2, "IP Addressing 2021", 2022, [APNIC2] Huston, G., "IP addressing in 2021", January 2022,
<https://blog.apnic.net/2022/01/19/ip-addressing-in- <https://blog.apnic.net/2022/01/19/ip-addressing-in-
2021/>. 2021/>.
[APNIC3] APNIC, "BGP in 2020 – The BGP Table", 2021, [APNIC3] Huston, G., "BGP in 2020 - The BGP Table", January 2021,
<https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp- <https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-
table/>>. table/>.
[APNIC4] APNIC, "BGP in 2021 – The BGP Table", 2022, [APNIC4] Huston, G., "BGP in 2021 - The BGP Table", January 2022,
<https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp- <https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp-
table/>>. table/>.
[APNIC5] APNIC, "Average RTT Difference (ms) (V6 - V4) for World [APNIC5] APNIC Labs, "Average RTT Difference (ms) (V6 - V4) for
(XA)", 2022, <https://stats.labs.apnic.net/v6perf/XA>. World (XA)", <https://stats.labs.apnic.net/v6perf/XA>.
[APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for [APRICOT] Huston, G., "IPv6 Performance Measurement", February 2020,
World (XA)", 2020,
<https://2020.apricot.net/assets/files/APAE432/ipv6- <https://2020.apricot.net/assets/files/APAE432/ipv6-
performance-measurement.pdf>. performance-measurement.pdf>.
[ARCEP] ARCEP, "Arcep Décision n° 2019-1386, Decision on the terms [ARCEP] ARCEP, "Proposant au ministre chargé des communications
and conditions for awarding licences to use frequencies in électroniques les modalités et les conditions
the 3.4–3.8GHz band", 2019, 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>. <https://www.arcep.fr/uploads/tx_gsavis/19-1386.pdf>.
[ARIN-CG] ARIN, "Community Grant Program: IPv6 Security, [ARIN-CG] ARIN, "2020 ARIN Community Grant Program Recipients: IPv6
Applications, and Training for Enterprises", 2020, Security, Applications, and Training for Enterprises",
<https://www.arin.net/about/community_grants/recipients/>. 2020, <https://www.arin.net/about/community_grants/
recipients/2020>.
[ARIN-SW] ARIN, "Preparing Applications for IPv6", [ARIN-SW] ARIN, "Preparing Applications for IPv6",
<https://www.arin.net/resources/guide/ipv6/ <https://www.arin.net/resources/guide/ipv6/
preparing_apps_for_v6.pdf>. preparing_apps_for_v6.pdf>.
[BGR_1] BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment [BGR_1] BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment
Monitor", 2022, Monitor", December 2021,
<http://218.2.231.237:5001/cgi-bin/generate>. <http://218.2.231.237:5001/cgi-bin/generate>.
[BGR_2] BIIGROUP, "China Government IPv6 and DNSSEC Deployment [BGR_2] BIIGROUP, "China Government IPv6 and DNSSEC Deployment
Monitor", 2022, Monitor", December 2021,
<http://218.2.231.237:5001/cgi-bin/generate_gov>. <http://218.2.231.237:5001/cgi-bin/generate_gov>.
[BGR_3] BIIGROUP, "China Education IPv6 and DNSSEC Deployment [BGR_3] BIIGROUP, "China Education IPv6 and DNSSEC Deployment
Monitor", 2022, Monitor", December 2021,
<http://218.2.231.237:5001/cgi-bin/generate_edu>. <http://218.2.231.237:5001/cgi-bin/generate_edu>.
[BIPT] Belgian Institute for Postal services and [BIPT] Vannieuwenhuyse, J., "IPv6 in Belgium", September 2017,
Telecommunications, "IPv6 in Belgium", 2017,
<https://www.ripe.net/participate/meetings/roundtable/ <https://www.ripe.net/participate/meetings/roundtable/
september-2017/government-roundtable-meeting-bahrain-26- september-2017/government-roundtable-meeting-bahrain-26-
september-2017/presentations/belgium-experience-bahrain- september-2017/presentations/belgium-experience-bahrain-
roundtable.pdf>. roundtable.pdf>.
[CAIDA] APNIC, "Client-Side IPv6 Measurement", 2020, [CAIDA] Huston, G., "Client-Side IPv6 Measurement", June 2020,
<https://www.cmand.org/workshops/202006-v6/ <https://www.cmand.org/workshops/202006-v6/
slides/2020-06-16-client-side.pdf>. slides/2020-06-16-client-side.pdf>.
[CAIR] Cisco, "Cisco Annual Internet Report (2018–2023) White [CAIR] Cisco, "Cisco Annual Internet Report (2018-2023) White
Paper", 2020, Paper", March 2020,
<https://www.cisco.com/c/en/us/solutions/collateral/ <https://www.cisco.com/c/en/us/solutions/collateral/
executive-perspectives/annual-internet-report/white-paper- executive-perspectives/annual-internet-report/white-paper-
c11-741490.html>. c11-741490.html>.
[Cldflr] Cloudflare, "Understanding and configuring Cloudflare's [Cldflr] Cloudflare, "Understanding and configuring Cloudflare's
IPv6 support", <https://support.cloudflare.com/hc/en-us/ IPv6 support", <https://support.cloudflare.com/hc/en-us/
articles/229666767-Understanding-and-configuring- articles/229666767-Understanding-and-configuring-
Cloudflare-s-IPv6-support>. Cloudflare-s-IPv6-support>.
[cmpwr] Compuware, "Impact on Enterprises of the IPv6-Only [cmpwr] Elkins, N., "Impact on Enterprises of the IPv6-Only
direction for the US Federal Government", 2020, Direction for the U.S. Federal Government",
<https://mydigitalpublication.com/article/ <https://mydigitalpublication.com/article/
Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U
.S.+Federal+Government/3702828/664279/article.html>. .S.+Federal+Government/3702828/664279/article.html>.
[CN] China.org.cn, "China to speed up IPv6-based Internet [CN] China.org.cn, "China to speed up IPv6-based Internet
development", 2017, <http://www.china.org.cn/ development", November 2017, <http://www.china.org.cn/
business/2017-11/27/content_41948814.htm>. business/2017-11/27/content_41948814.htm>.
[CN-IPv6] National IPv6 Deployment and Monitoring Platform, "Active [CN-IPv6] National IPv6 Deployment and Monitoring Platform, "Active
IPv6 Internet users", 2022, IPv6 Internet Users", (in Chinese), 2022,
<https://www.china-ipv6.cn/#/activeconnect/simpleInfo>. <https://www.china-ipv6.cn/#/activeconnect/simpleInfo>.
[CNLABS_1] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, [CNLABS_1] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022,
<https://cnlabs.in/IPv6_Mon/generate_industry.html>. <https://cnlabs.in/IPv6_Mon/generate_industry.html>.
[CNLABS_2] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, [CNLABS_2] CNLABS, "Government IPv6 and DNSSEC Statistics", 2022,
<https://cnlabs.in/IPv6_Mon/generate_gov.html>. <https://cnlabs.in/IPv6_Mon/generate_gov.html>.
[ComputSecur] [ComputSecur]
Computers & Security (Elsevier), "Methodology for the Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", DOI 10.1016/j.cose.2018.04.012, 2018, stateful NAT64", Computers and Security, Volume 77, Issue
<https://doi.org/10.1016/j.cose.2018.04.012>. 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, "World - Display Content Data", 2022, [Csc6lab] Cisco, "Display global data", 2023,
<https://6lab.cisco.com/stats/>. <https://6lab.cisco.com/stats/>.
[EE] EE, "IPv6-only devices on EE mobile", 2017, [EE] Heatley, N., "IPv6-only Devices on EE Mobile", January
2017,
<https://indico.uknof.org.uk/event/38/contributions/489/ <https://indico.uknof.org.uk/event/38/contributions/489/
attachments/612/736/ attachments/612/736/
Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf>. Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf>.
[ETSI-GR-IPE-001] [ETSI-GR-IPE-001]
ETSI, "ETSI GR IPE 001: IPv6 Enhanced Innovation (IPE) Gap ETSI, "IPv6 Enhanced Innovation (IPE) Gap Analysis", ETSI
Analysis", 2021, <https://www.etsi.org/deliver/etsi_gr/ 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>. IPE/001_099/001/01.01.01_60/gr_IPE001v010101p.pdf>.
[ETSI-IP6-WhitePaper] [ETSI-IP6-WhitePaper]
ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, ETSI, "IPv6 Best Practices, Benefits, Transition
Benefits, Transition Challenges and the Way Forward", Challenges and the Way Forward", ETSI White Paper No. 35,
ISBN 979-10-92620-31-1, 2020. ISBN 979-10-92620-31-1, August 2020.
[FB] Saab, P., "Facebook IPv6 Experience", 2015, [FB] "Paul Saab Facebook V6 World Congress 2015", YouTube
video, 25:32, posted by Upperside Conferences, March 2015,
<https://youtu.be/An7s25FSK0U>. <https://youtu.be/An7s25FSK0U>.
[GFA] German Federal Government Commissioner for Information [GFA] German Federal Government Commissioner for Information
Technology, "IPv6-Masterplan für die Bundesverwaltung", Technology, "IPv6-Masterplan für die Bundesverwaltung",
2019, <https://media.frag-den-staat.de/files/foi/531501/ [IPv6 Master Plan for the Federal Administration],
de-government-ipv6-masterplan- November 2019, <https://media.frag-den-
staat.de/files/foi/531501/de-government-ipv6-masterplan-
v100-entwurf_konvertiert.pdf>. v100-entwurf_konvertiert.pdf>.
[Ggl] Google, "Introduction to GGC", [Ggl] Google, "Introduction to GGC",
<https://support.google.com/interconnect/ <https://support.google.com/interconnect/
answer/9058809?hl=en>. answer/9058809?hl=en>.
[G_stats] Google, "Google IPv6 Statistics", 2021, [G_stats] Google, "Google IPv6 Statistics",
<https://www.google.com/intl/en/ipv6/statistics.html>. <https://www.google.com/intl/en/ipv6/statistics.html>.
[HxBld] HexaBuild, "IPv6 Adoption Report 2020", 2020, [HBH-OPT-HDR]
<https://hexabuild.io/assets/files/HexaBuild-IPv6- Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,
Adoption-Report-2020.pdf>.
[I-D.bonica-6man-ext-hdr-update]
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://www.ietf.org/archive/id/draft-
bonica-6man-ext-hdr-update-07.txt>.
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-04, 21 October 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-hbh-
processing-04.txt>.
[I-D.ietf-v6ops-hbh]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
"Operational Issues with Processing of the Hop-by-Hop "Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft- Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-02, 21 October 2022, ietf-v6ops-hbh-04, 10 March 2023,
<https://www.ietf.org/archive/id/draft-ietf-v6ops-hbh- <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
02.txt>. hbh-04>.
[I-D.ietf-v6ops-nd-considerations] [HBH-PROCESSING]
Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N. Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Buraglio, "Selectively Applying Host Isolation to Simplify Processing Procedures", Work in Progress, Internet-Draft,
IPv6 First-hop Deployment", Work in Progress, Internet- draft-ietf-6man-hbh-processing-06, 11 March 2023,
Draft, draft-ietf-v6ops-nd-considerations-00, 24 October <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
2022, <https://datatracker.ietf.org/api/v1/doc/document/ hbh-processing-06>.
draft-ietf-v6ops-nd-considerations/>.
[I-D.palet-v6ops-ipv6-only] [HxBld] HexaBuild, "IPv6 Adoption Report 2020: The IPv6 Internet
Martinez, J. P., "IPv6-only Terminology Definition", Work is the Corporate Network", November 2020,
in Progress, Internet-Draft, draft-palet-v6ops-ipv6-only- <https://hexabuild.io/assets/files/HexaBuild-IPv6-
05, 9 March 2020, <https://www.ietf.org/archive/id/draft- Adoption-Report-2020.pdf>.
palet-v6ops-ipv6-only-05.txt>.
[IAB] IAB, "IAB Statement on IPv6", 2016, [IAB] IAB, "IAB Statement on IPv6", November 2016,
<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>. <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[IDT] Indian Department of Telecommunications, "Revision of IPv6 [IDT] Government of India: Department of Telecommunications,
Transition Timelines", 2021, <https://dot.gov.in/revision- "Revision of IPv6 Transition Timelines", February 2021,
ipv6-transition-timelines-2021>. <https://dot.gov.in/revision-ipv6-transition-timelines-
2021>.
[IGP-GT] Internet Governance Project, Georgia Tech, "The hidden [IGP-GT] Kuerbis, B. and M. Mueller, "The hidden standards war:
standards war: economic factors affecting IPv6 economic factors affecting IPv6 deployment", DOI
deployment", 2019, <https://via.hypothes.is/ 10.1108/DPRG-10-2019-0085, February 2019,
https://www.internetgovernance.org/wp-content/uploads/ <https://www.emerald.com/insight/content/doi/10.1108/DPRG-
IPv6-Migration-Study-final-report.pdf>. 10-2019-0085/full/html>.
[INFOCOM] Doan, T.V., "A Longitudinal View of Netflix: Content [INFOCOM] Doan, T., Bajpai, V., and S. Crawford, "A Longitudinal
Delivery over IPv6 and Content Cache Deployments", 2020, 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/ <https://dl.acm.org/doi/abs/10.1109/
INFOCOM41043.2020.9155367>. 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]
IPv6Forum, "Estimating IPv6 & DNSSEC External Service IPv6Forum, "Estimating IPv6 & DNSSEC External Service
Deployment Status", 2022, Deployment Status", 2023,
<https://www.ipv6forum.com/IPv6-Monitoring/index.html>. <https://www.ipv6forum.com/IPv6-Monitoring/index.html>.
[ISIF-ASIA-G] [ISIF-ASIA-G]
ISIF Asia, "Internet Operations Research Grant: IPv6 India Internet Engineering Society (IIESoc), "IPv6
Deployment at Enterprises. IIESoc. India", 2020, Deployment at Enterprises", March 2022,
<https://isif.asia/2020-grantees/>. <https://isif.asia/ipv6-deployment-at-enterprises/>.
[ISOC1] Internet Society, "State of IPv6 Deployment 2018", 2018, [ISOC1] Internet Society, "State of IPv6 Deployment 2018", June
<https://www.internetsociety.org/resources/2018/state-of- 2018, <https://www.internetsociety.org/resources/2018/
ipv6-deployment-2018/>. state-of-ipv6-deployment-2018/>.
[ISOC2] Internet Society, "Facebook News Feeds Load 20-40% Faster [ISOC2] York, D., "Facebook News Feeds Load 20-40% Faster Over
Over IPv6", 2015, IPv6", April 2015,
<https://www.internetsociety.org/blog/2015/04/facebook- <https://www.internetsociety.org/blog/2015/04/facebook-
news-feeds-load-20-40-faster-over-ipv6/>. news-feeds-load-20-40-faster-over-ipv6/>.
[ISOC3] Internet Society, "IPv6 Security FAQ", 2019, [ISOC3] Gont, F., "IPv6 Security Frequently Asked Questions
<https://www.internetsociety.org/wp- (FAQ)", January 2019, <https://www.internetsociety.org/wp-
content/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf>. content/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf>.
[MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over [MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over
IPv6", 2017, <https://www.ietf.org/proceedings/99/slides/ IPv6", July 2017,
slides-99-maprg-measuring-youtube-content-delivery-over- <https://www.ietf.org/proceedings/99/slides/slides-99-
maprg-measuring-youtube-content-delivery-over-
ipv6-00.pdf>. ipv6-00.pdf>.
[Mcrsft] Microsoft, "IPv6 for Azure VMs available in most regions", [Mcrsft] Microsoft, "IPv6 for Azure VMs available in most regions",
<https://azure.microsoft.com/en-us/updates/ipv6-for-azure- September 2016, <https://azure.microsoft.com/en-
vms/>. us/updates/ipv6-for-azure-vms/>.
[NRO] NRO, "Internet Number Resource Status Report", 2021, [ND-CONSIDERATIONS]
<https://www.nro.net/wp-content/uploads/NRO-Statistics- Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N.
2021-Q3-FINAL.pdf>. 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>.
[NST_1] NIST, "Estimating Industry IPv6 and DNSSEC External [NRO] NRO, "Internet Number Resource Status Report", September
Service Deployment Status", 2022, <https://fedv6- 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>. deployment.antd.nist.gov/cgi-bin/generate-com>.
[NST_2] NIST, "Estimating USG IPv6 and DNSSEC External Service [NST_2] NIST, "Estimating USG IPv6 & DNSSEC External Service
Deployment Status", 2022, <https://fedv6- Deployment Status", 2023, <https://fedv6-
deployment.antd.nist.gov/cgi-bin/generate-gov>. deployment.antd.nist.gov/cgi-bin/generate-gov>.
[NST_3] NIST, "Estimating University IPv6 and DNSSEC External [NST_3] NIST, "Estimating University IPv6 & DNSSEC External
Service Deployment Status", 2022, <https://fedv6- Service Deployment Status", 2023, <https://fedv6-
deployment.antd.nist.gov/cgi-bin/generate-edu>. deployment.antd.nist.gov/cgi-bin/generate-edu>.
[Ntflx] Netflix, "Enabling Support for IPv6", [Ntflx] Aggarwal, R. and D. Temkin, "Enabling Support for IPv6",
<https://netflixtechblog.com/enabling-support-for- July 2012, <https://netflixtechblog.com/enabling-support-
ipv6-48a495d5196f>. for-ipv6-48a495d5196f>.
[POTAROO1] POTAROO, "IP Addressing through 2021", 2022, [POTAROO1] Huston, G., "IP Addressing through 2021", January 2022,
<https://www.potaroo.net/ispcol/2022-01/addr2021.html>. <https://www.potaroo.net/ispcol/2022-01/addr2021.html>.
[POTAROO2] POTAROO, "IPv6 Resource Allocations", 2022, [POTAROO2] POTAROO, "IPv6 Resource Allocations", March 2023,
<https://www.potaroo.net/bgp/iso3166/v6cc.html>. <https://www.potaroo.net/bgp/iso3166/v6cc.html>.
[RelJio] Reliance Jio, "IPv6-only adoption challenges and [RelJio] Chandra, R., "IPv6-only adoption challenges and
standardization requirements", 2020, standardization requirements", November 2020,
<https://datatracker.ietf.org/meeting/109/materials/ <https://datatracker.ietf.org/meeting/109/materials/
slides-109-v6ops-ipv6-only-adoption-challenges-and- slides-109-v6ops-ipv6-only-adoption-challenges-and-
standardization-requirements-03>. standardization-requirements-03>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
skipping to change at page 40, line 10 skipping to change at line 1811
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/info/rfc8981>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>. September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, [RIPE1] Huston, G., "Measuring IPv6 Performance", October 2016,
<https://ripe73.ripe.net/wp-content/uploads/ <https://ripe73.ripe.net/wp-content/uploads/
presentations/35-2016-10-24-v6-performance.pdf>. presentations/35-2016-10-24-v6-performance.pdf>.
[RIPE2] RIPE, "IPv6 Security", 2019, [RIPE2] RIPE, "IPv6 Security", January 2023,
<https://www.ripe.net/support/training/material/ipv6- <https://www.ripe.net/support/training/material/ipv6-
security/ipv6security-slides.pdf>. security/ipv6security-slides.pdf>.
[SNDVN] SANDVINE, "Sandvine releases 2020 Mobile Internet [SNDVN] Cullen, C., "Sandvine releases 2020 Mobile Internet
Phenomena Report: YouTube is over 25% of all mobile Phenomena Report: YouTube is over 25% of all mobile
traffic", 2020, <https://www.sandvine.com/press-releases/ traffic", February 2020, <https://www.sandvine.com/press-
sandvine-releases-2020-mobile-internet-phenomena-report- releases/sandvine-releases-2020-mobile-internet-phenomena-
youtube-is-over-25-of-all-mobile-traffic>. report-youtube-is-over-25-of-all-mobile-traffic>.
[TMus] T-Mobile US, "Going IPv6-only", 2018, [TMus] Lagerholm, S., "Going IPv6 Only", June 2018,
<https://pc.nanog.org/static/published/meetings/ <https://pc.nanog.org/static/published/meetings/
NANOG73/1645/20180625_Lagerholm_T- NANOG73/1645/20180625_Lagerholm_T-
Mobile_S_Journey_To_v1.pdf>. Mobile_S_Journey_To_v1.pdf>.
[US-CIO] The CIO Council, "Memorandum for Heads of Executive [US-CIO] Vought, R., "Memorandum for Heads of Executive Departments
Departments and Agencies. Completing the Transition to and Agencies: Completing the Transition to Internet
Internet Protocol Version 6 (IPv6)", 2020, Protocol Version 6 (IPv6)", 2020,
<https://www.cio.gov/assets/resources/internet-protocol- <https://www.cio.gov/assets/resources/internet-protocol-
version6-draft.pdf>. version6-draft.pdf>.
[US-FR] Federal Register, "Request for Comments on Updated [US-FR] Federal Register, "Request for Comments on Updated
Guidance for Completing the Transition to the Next Guidance for Completing the Transition to the Next
Generation Internet Protocol, Internet Protocol Version 6 Generation Internet Protocol, Internet Protocol Version 6
(IPv6)", 2020, <https://www.federalregister.gov/ (IPv6)", March 2020, <https://www.federalregister.gov/
documents/2020/03/02/2020-04202/request-for-comments-on- documents/2020/03/02/2020-04202/request-for-comments-on-
updated-guidance-for-completing-the-transition-to-the- updated-guidance-for-completing-the-transition-to-the-
next-generation>. next-generation>.
[Vrzn] Verizon, "Verizon Digital Media Services announces IPv6
Compliance", <https://www.verizondigitalmedia.com/blog/
verizon-digital-media-services-announces-
ipv6-compliance/>.
[W3Techs] W3Techs, "Historical yearly trends in the usage statistics [W3Techs] W3Techs, "Historical yearly trends in the usage statistics
of site elements for websites", 2021, of site elements for websites", 2023,
<https://w3techs.com/technologies/history_overview/ <https://w3techs.com/technologies/history_overview/
site_element/all/y>. site_element/all/y>.
[WIPv6L] World IPv6 Launch, "World IPv6 Launch - Measurements", [WIPv6L] World IPv6 Launch, "Measurements", June 2022,
2021, <https://www.worldipv6launch.org/measurements/>. <https://www.worldipv6launch.org/measurements/>.
Appendix A. Summary of Questionnaire and Replies for network operators Appendix A. Summary of Questionnaire and Replies for Network Operators
A survey was proposed to more than 50 service providers in the A survey was proposed to more than 50 service providers in the
European region during the third quarter of 2020 to ask for their European region during the third quarter of 2020 to ask for their
plans on IPv6 and the status of IPv6 deployment. plans on IPv6 and the status of IPv6 deployment.
40 people, representing 38 organizations, provided a response. This In this survey, 40 people, representing 38 organizations, provided
appendix summarizes the results obtained. responses. This appendix summarizes the results obtained.
Respondents' business Respondents' business:
Convergent Mobile Fixed
Type of operators 82% 8% 11%
Question 1. Do you have plan to move more fixed or mobile or +============+========+=======+
| Convergent | Mobile | Fixed |
+============+========+=======+
| 82% | 8% | 11% |
+------------+--------+-------+
Table 10: Type of Operators
Question 1. Do you have plans to move more fixed, mobile, or
enterprise users to IPv6 in the next 2 years? enterprise users to IPv6 in the next 2 years?
a. If so, fixed, or mobile, or enterprise? A. If so, fixed, mobile, or enterprise?
b. What are the reasons to do so? B. What are the reasons to do so?
c. When to start: already on going, in 12 months, after 12 months? C. When to start: already ongoing, in 12 months, or after 12 months?
d. Which transition solution will you use, Dual-Stack, DS-Lite, D. Which transition solution will you use: Dual-Stack, DS-Lite,
464XLAT, MAP-T/E? 464XLAT, or MAP-T/E?
Answer 1.A (38 respondents) Answers for 1.A (38 respondents)
Yes No +=====+=====+
Plans availability 79% 21% | Yes | No |
+=====+=====+
| 79% | 21% |
+-----+-----+
Mobile Fixed Enterprise Don't answer Table 11: Plan to Move
Business segment 63% 63% 50% 3% to IPv6 within 2 Years
Answer 1.B (29 respondents) +========+=======+============+=============+
| Mobile | Fixed | Enterprise | No Response |
+========+=======+============+=============+
| 63% | 63% | 50% | 3% |
+--------+-------+------------+-------------+
Even this was an open question, some common answers can be found. Table 12: Business Segment
14 respondents (48%) highlighted issues related to IPv4 depletion. Answers for 1.B (29 respondents)
The reason to move to IPv6 is to avoid private and/or overlapping
addresses.
For 6 respondents (20%) 5G/IoT is a business incentive to introduce Even though this was an open question, some common answers can be
IPv6. found.
4 respondents (13%) also highlight that there is a National * 14 respondents (48%) highlighted issues related to IPv4 depletion.
regulation request to enable IPv6 associated with the launch of 5G. The reason to move to IPv6 is to avoid private and/or overlapping
addresses.
4 respondents (13%) consider IPv6 as a part of their innovation * 6 respondents (20%) stated that 5G/IoT is a business incentive to
strategy or an enabler for new services. introduce IPv6.
4 respondents (13%) introduce IPv6 because of Enterprise customers * 4 respondents (13%) highlighted that there is a national
demand. regulation request to associate and enable IPv6 with the launch of
5G.
Answer 1.C (30 respondents) * 4 respondents (13%) considered IPv6 as a part of their innovation
strategy or an enabler for new services.
Ongoing In 12 months After 12 months Don't answer * 4 respondents (13%) introduced IPv6 because of enterprise customer
Timeframe 60% 33% 0% 7% demand.
Answer 1.D (28 respondents for cellular, 27 for wireline) Answers for 1.C (30 respondents)
Transition in use Dual-Stack 464XLAT MAP-T Don't answer +=========+==============+=================+=============+
Cellular 39% 21% 4% 36% | Ongoing | In 12 months | After 12 months | No Response |
+=========+==============+=================+=============+
| 60% | 33% | 0% | 7% |
+---------+--------------+-----------------+-------------+
Transition in use Dual-Stack DS-Lite 6RD/6VPE Don't answer Table 13: Timeframe
Wireline 59% 19% 4% 19%
Answers for 1.D (28 respondents for cellular, 27 for wireline)
+============+=========+=======+=============+
| Dual-Stack | 464XLAT | MAP-T | No Response |
+============+=========+=======+=============+
| 39% | 21% | 4% | 36% |
+------------+---------+-------+-------------+
Table 14: Transition in Use: Cellular
+============+=========+==========+=============+
| Dual-Stack | DS-Lite | 6RD/6VPE | No Response |
+============+=========+==========+=============+
| 59% | 19% | 4% | 19% |
+------------+---------+----------+-------------+
Table 15: Transition in Use: Wireline
Question 2. Do you need to change network devices for the above Question 2. Do you need to change network devices for the above
goal? goal?
a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT? A. If yes, what kind of devices: CPE, BNG/mobile core, or NAT?
b. Will you start the transition of your metro or backbone or B. Will you start the transition of your metro, backbone, or
backhaul network to support IPv6? backhaul network to support IPv6?
Answer 2.A (30 respondents) Answers for 2.A (30 respondents)
Yes No Don't answer +=====+=====+=============+
Need of changing 43% 33% 23% | Yes | No | No Response |
+=====+=====+=============+
| 43% | 33% | 23% |
+-----+-----+-------------+
CPEs Routers BNG CGN Mobile core Table 16: Need to Change
What to change 47% 27% 20% 33% 27%
Answer 2.B (22 respondents) +======+=========+=====+=====+=============+
| CPEs | Routers | BNG | CGN | Mobile core |
+======+=========+=====+=====+=============+
| 47% | 27% | 20% | 33% | 27% |
+------+---------+-----+-----+-------------+
Yes Future No Table 17: What to Change
Plans for transition 9% 9% 82%
Appendix B. Summary of Questionnaire and Replies for enterprises Answers for 2.B (22 respondents)
+=====+========+=====+
| Yes | Future | No |
+=====+========+=====+
| 9% | 9% | 82% |
+-----+--------+-----+
Table 18: Plans for
Transition
Appendix B. Summary of Questionnaire and Replies for Enterprises
The Industry Network Technology Council (INTC) developed the The Industry Network Technology Council (INTC) developed the
following poll to verify the need or willingness of medium-to-large following poll to verify the need or willingness of medium-to-large
US-based enterprises for training and consultancy on IPv6 US-based enterprises for training and consultancy on IPv6
(https://industrynetcouncil.org/) in early 2021. <https://industrynetcouncil.org/> in early 2021.
54 organizations provided an answer. 54 organizations provided answers.
Question 1. How much IPv6 implementation have you done at your Question 1. How much IPv6 implementation have you done at your
organization? (54 respondents) organization? (54 respondents)
None 16.67% +-------------------------------------------------+--------+
Some people have gotten some training 16.67% | None | 16.67% |
Many people have gotten some training 1.85% +-------------------------------------------------+--------+
Website is IPv6 enabled 7.41% | Some people have gotten some training | 16.67% |
Most equipment is dual-stacked 31.48% +-------------------------------------------------+--------+
Have an IPv6 transition plan for entire network 5.56% | Many people have gotten some training | 1.85% |
Running IPv6-only in many places 20.37% +-------------------------------------------------+--------+
Entire network is IPv6-only 0.00% | 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
Question 2. What kind of help or classes would you like to see INTC Question 2. What kind of help or classes would you like to see INTC
do? ( 54 respondents) do? (54 respondents)
Classes/labs on IPv6 security 66.67% +------------------------------------------------+--------+
Classes/labs on IPv6 fundamentals 55.56% | Classes/labs on IPv6 security | 66.67% |
Classes/labs on address planning/network conf. 57.41% +------------------------------------------------+--------+
Classes/labs on IPv6 troubleshooting 66.67% | Classes/labs on IPv6 fundamentals | 55.56% |
Classes/labs on application conversion 35.19% +------------------------------------------------+--------+
Other 14.81% | 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
Question 3. As you begin to think about the implementation of IPv6 Question 3. As you begin to think about the implementation of IPv6
at your organization, what areas do you feel are of concern? (54 at your organization, what areas do you feel are of concern? (54
respondents) respondents)
Security 31.48% +-----------------------------+--------+
Application conversion 25.93% | Security | 31.48% |
Training 27.78% +-----------------------------+--------+
All the above 33.33% | Application conversion | 25.93% |
Don't know enough to answer 14.81% +-----------------------------+--------+
Other 9.26% | 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
Acknowledgements
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.
Contributors
Nalini Elkins
Inside Products
Email: nalini.elkins@insidethestack.com
Sébastien Lourdez
Post Luxembourg
Email: sebastien.lourdez@post.lu
Authors' Addresses Authors' Addresses
Giuseppe Fioccola Giuseppe Fioccola
Huawei Technologies Huawei Technologies
Riesstrasse, 25 Riesstrasse, 25
80992 Munich 80992 Munich
Germany Germany
Email: giuseppe.fioccola@huawei.com Email: giuseppe.fioccola@huawei.com
Paolo Volpato Paolo Volpato
Huawei Technologies Huawei Technologies
Via Lorenteggio, 240 Via Lorenteggio, 240
 End of changes. 309 change blocks. 
1002 lines changed or deleted 1094 lines changed or added

This html diff was produced by rfcdiff 1.48.