Skip to main content

IPv6 Deployment Status

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9386.
Authors Giuseppe Fioccola , Paolo Volpato , Jordi Palet Martinez , Gyan Mishra , Chongfeng Xie
Last updated 2023-04-19 (Latest revision 2022-12-01)
Replaces draft-vf-v6ops-ipv6-deployment
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Fred Baker
Shepherd write-up Show Last changed 2022-08-10
IESG IESG state Became RFC 9386 (Informational)
Action Holders
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Warren "Ace" Kumari
Send notices to,,
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
V6OPS                                                        G. Fioccola
Internet-Draft                                                P. Volpato
Obsoletes: 6036 (if approved)                        Huawei Technologies
Intended status: Informational                         J. Palet Martinez
Expires: 4 June 2023                                    The IPv6 Company
                                                               G. Mishra
                                                            Verizon Inc.
                                                                  C. Xie
                                                           China Telecom
                                                         1 December 2022

                         IPv6 Deployment Status


   This document provides an overview of IPv6 deployment status in 2022.
   Specifically, it looks at the degree of adoption of IPv6 in the
   industry, analyzes the remaining challenges and proposes further
   investigations in areas where the industry has not yet taken a clear
   and unified approach in the transition to IPv6.  It obsoletes RFC

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 June 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Fioccola, et al.           Expires 4 June 2023                  [Page 1]
Internet-Draft           IPv6 Deployment Status            December 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  IPv6: The Global Picture  . . . . . . . . . . . . . . . . . .   6
     2.1.  IPv4 Address Exhaustion . . . . . . . . . . . . . . . . .   6
       2.1.1.  IPv4 addresses per capita and IPv6 status . . . . . .   7
     2.2.  IPv6 Users  . . . . . . . . . . . . . . . . . . . . . . .   9
     2.3.  IPv6 Web Content  . . . . . . . . . . . . . . . . . . . .  10
     2.4.  IPv6 public actions and policies  . . . . . . . . . . . .  11
   3.  A Survey on IPv6 Deployments  . . . . . . . . . . . . . . . .  12
     3.1.  IPv6 Allocations  . . . . . . . . . . . . . . . . . . . .  12
     3.2.  IPv6 among Internet Service Providers . . . . . . . . . .  14
     3.3.  IPv6 among Enterprises  . . . . . . . . . . . . . . . . .  14
       3.3.1.  Government and Universities . . . . . . . . . . . . .  15
   4.  IPv6 deployment scenarios . . . . . . . . . . . . . . . . . .  17
     4.1.  Dual-Stack  . . . . . . . . . . . . . . . . . . . . . . .  17
     4.2.  IPv6-only Overlay . . . . . . . . . . . . . . . . . . . .  18
     4.3.  IPv6-only Underlay  . . . . . . . . . . . . . . . . . . .  19
     4.4.  IPv4 as a Service . . . . . . . . . . . . . . . . . . . .  19
     4.5.  IPv6-only . . . . . . . . . . . . . . . . . . . . . . . .  20
   5.  Common IPv6 Challenges  . . . . . . . . . . . . . . . . . . .  21
     5.1.  Transition Choices  . . . . . . . . . . . . . . . . . . .  21
       5.1.1.  Service Providers . . . . . . . . . . . . . . . . . .  21
       5.1.2.  Enterprises . . . . . . . . . . . . . . . . . . . . .  22
       5.1.3.  Industrial Internet . . . . . . . . . . . . . . . . .  23
       5.1.4.  Content and Cloud Service Providers . . . . . . . . .  24
       5.1.5.  CPEs and user devices . . . . . . . . . . . . . . . .  24
       5.1.6.  Software Applications . . . . . . . . . . . . . . . .  25
     5.2.  Network Management and Operations . . . . . . . . . . . .  25
     5.3.  Performance . . . . . . . . . . . . . . . . . . . . . . .  26
       5.3.1.  IPv6 packet loss and latency  . . . . . . . . . . . .  26
       5.3.2.  Customer Experience . . . . . . . . . . . . . . . . .  27
     5.4.  IPv6 security and privacy . . . . . . . . . . . . . . . .  27
       5.4.1.  Protocols security issues . . . . . . . . . . . . . .  28
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  30
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  30
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30

Fioccola, et al.           Expires 4 June 2023                  [Page 2]
Internet-Draft           IPv6 Deployment Status            December 2022

   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     10.2.  Informative References . . . . . . . . . . . . . . . . .  33
   Appendix A.  Summary of Questionnaire and Replies for network
           operators . . . . . . . . . . . . . . . . . . . . . . . .  41
   Appendix B.  Summary of Questionnaire and Replies for
           enterprises . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43

1.  Introduction

   [RFC6036] described IPv6 deployment scenarios adopted or foreseen by
   a number of Internet Service Providers (ISPs) who responded to a
   technical questionnaire in early 2010.  In doing that, [RFC6036]
   provided practices and plans expected to take place in the following
   years.  Since the publication of [RFC6036], several other documents
   have contributed to the IPv6 transition discussion in operational
   environments.  To name a few:

      - [RFC6180] discussed IPv6 deployment models and transition
      mechanisms, recommending those proven to be effective in
      operational networks.

      - [RFC6883] provided guidance and suggestions for Internet content
      providers and Application Service Providers (ASPs).

      - [RFC7381] introduced the guidelines of IPv6 deployment for

   [RFC6540] recommended the support of IPv6 to all IP-capable nodes.
   It was referenced in the IAB Statement on IPv6 [IAB], which
   represented a major step in driving the IETF as well as other
   Standard Developing Organizations (SDOs) towards using IPv6 in their

   In more recent times, organizations such as ETSI provided more
   contributions to the use of IPv6 in operational environments,
   targeting IPv6 in different industry segments.  As a result,
   [ETSI-IP6-WhitePaper], was published to provide an updated view on
   the IPv6 best practices adopted so far, in particular in the ISP

   Considering all of the above, and after more than ten years since the
   publication of [RFC6036] it is useful to assess the status of the
   transition to IPv6.  Some reasons include:

Fioccola, et al.           Expires 4 June 2023                  [Page 3]
Internet-Draft           IPv6 Deployment Status            December 2022

      - In some areas, the lack of IPv4 addresses forced both carriers
      and content providers to shift to IPv6 to support the introduction
      of new applications, in particular in wireless networks.

      - Some governmental actions took place to encourage or even
      enforce the adoption of IPv6 in certain countries.

      - Looking at the global adoption of IPv6, this seems to have
      reached a threshold that justifies speaking of end-to-end IPv6
      connectivity, at least at the IPv6 service layer.

   This document aims to provide a survey of the status of IPv6
   deployment and highlight both the achievements and remaining
   obstacles in the transition to IPv6 networks (and its coexistence
   with continued IPv4 services).  The target is to give an updated view
   of the practices and plans already described in [RFC6036], to
   encourage further actions and more investigations in those areas that
   are still under discussion, and to present the main incentives for
   the adoption of IPv6.

   This document is intended for a general audience interested to
   understand the status of IPv6 in different industries and network
   domains.  People who provide or use network services may find it
   useful for the transition to IPv6.  Also, people developing plans for
   IPv6 adoption in an organization or in an industry may find
   information and references for their analysis.  Attention is given to
   the different stages of the transition to IPv6 networks and services.
   In particular, a terminology on the use of "IPv6-only" is provided,
   considering IPv6-only networks and services as the final stage of
   such transition.

   The topics discussed in this document are organized into four main

      Section 2 reports data and analytics about the status of IPv6.

      Section 3 provides a survey of IPv6 deployments in different
      environments, including ISPs, enterprises and universities.

      Section 4 describes the IPv6 deployment approaches for Mobile
      BroadBand (MBB), Fixed BroadBand (FBB) and Enterprises.

      Section 5 analyzes the general challenges to be solved in the IPv6
      transition.  Specific attention is given to operations,
      performance and security issues.

Fioccola, et al.           Expires 4 June 2023                  [Page 4]
Internet-Draft           IPv6 Deployment Status            December 2022

1.1.  Terminology

   This section defines the terminology regarding the usage of IPv6-only
   expressions within this document.  The term IPv6-only is defined in
   relation to the specific scope it is referring to.  In this regard,
   it may happen that only part of a service, of a network or even part
   of a node is in an IPv6-only scope and the rest is not.  Below are
   listed the most used terms in relation to the different scopes:

      IPv6-only interface: It means that the interface of a node is
      configured to forward only IPv6.  This denotes that just part of
      the node can be IPv6-only since the rest of the interfaces of the
      same node may work with IPv4 as well.  A Dual-Stack interface is
      not an IPv6-only interface.

      IPv6-only node: It means that 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
      the interface of 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
      tunnels, all inner packet headers of the tunnels are IPv6.  For
      example, IPv6-only overlay in fixed network means that the
      encapsulation is only IPv6 between the interfaces of the Provider
      Edge (PE) nodes or between the Customer Provider Edge (CPE) node
      and the Broadband Network Gateway (BNG).

      IPv6-only underlay: It is used if the data plane and control plane
      are IPv6, but not necessarily management plane.  For example,
      IPv6-only underlay in fixed network means that the underlay
      network protocol is only IPv6 between any Provider Edge (PE) nodes
      but they can be Dual-Stack in overlay.  SRv6 is an example of
      IPv6-only underlay.

      IPv6-only network: It is used if every node in this network is
      IPv6-only.  No IPv4 should exist in an IPv6-only network.  In
      particular, IPv6-only network's data plane, control plane, and
      management plane must be IPv6.  All PEs must be IPv6-only.
      Therefore, if tunnels exist among PEs, both inner and outer
      headers must be IPv6.  For example, IPv6-only access network means
      that every node in this access network must be IPv6-only and
      similarly IPv6-only backbone network means that every nodes in
      this backbone network must be IPv6-only.

Fioccola, et al.           Expires 4 June 2023                  [Page 5]
Internet-Draft           IPv6 Deployment Status            December 2022

      IPv4 as a Service (IPv4aaS): It means that IPv4 service support is
      provided by means of transition mechanism, therefore there is a
      combination of encapsulation/translation + IPv6-only underlay +
      decapsulation/translation.  For an IPv6-only network, connectivity
      to legacy IPv4 is either non-existent or provided by IPv4aaS

   Note that IPv6-only definitions are also discussed in

2.  IPv6: The Global Picture

   This section deals with some key questions related to IPv6 namely:
   (1) the status of IPv4 exhaustion, often considered as one of the
   triggers to switch to IPv6, (2) the number of IPv6 end users, a
   primary measure to sense IPv6 adoption, (3) the percentage of
   websites reachable over IPv6 and (4) a report on IPv6 public actions
   and policies.

   These parameters are monitored by the Regional internet Registries
   (RIRs) and other institutions worldwide as they provide a first-order
   indication on the adoption of IPv6.

2.1.  IPv4 Address Exhaustion

   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
   whether the IPv4 address space can sustain such a number of
   allocations and, consequently, if this may affect the process of its
   exhaustion.  The answer is not straightforward as many aspects have
   to be considered.

   On one hand, the RIRs are reporting scarcity of available and still
   reserved addresses.  Table 3 of [POTAROO1] (January 2022) shows that
   the available pool of the five RIRs at the end of 2021 counted 5.2
   million IPv4 addresses, while the reserved pool included another 12
   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,
   shows that the total IPv4 allocated pool equaled to 3.685 billion
   addresses (+0.027% year over year).  The ratio between the available
   addresses and the total allocated brought to 0.469% of the remaining
   IPv4 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.

Fioccola, et al.           Expires 4 June 2023                  [Page 6]
Internet-Draft           IPv6 Deployment Status            December 2022

   In all cases, a set of IPv4 addresses is "transferred" to a different
   holder that has the need to expand their address range.  As an
   example, [IGP-GT] and [NRO] show the amount of transfers to recipient
   organizations in the different regions.  Cloud Service Providers
   (CSPs) appear to be the most active in buying IPv4 addresses to
   satisfy their need of providing IPv4 connectivity to their tenants.
   NAT systems provide a means to absorb at least a portion of the
   demand of public IPv4 addresses as they enable the use of private
   addressing in internal networks while limiting the use of public
   addresses on their WAN-facing side.  In the case of NAT,
   architectural and operational issues remain.  Private address space
   cannot provide adequate address span, especially for large
   organizations, and the reuse of addresses may make the network more
   complex.  In addition, multiple levels of address translation may
   coexist in a network, e.g.  Carrier-Grade NAT (CGN) [RFC6264] based
   on two stages of translation.  This comes with an economic and
   operational burden, as discussed later in this document.

2.1.1.  IPv4 addresses per capita and IPv6 status

   The IPv4 addresses per capita ratio measures the quantity of IPv4
   addresses allocated to a given country divided by the population of
   that country.  It provides an indication of the imbalanced
   distribution of the IPv4 addresses worldwide.  It clearly derives
   from the allocation of addresses made in the early days of the

   The sources for measuring the IPv4 addresses per capita ratio are the
   allocations done by the RIRs and the statistics about the world
   population.  In this regard, [POTAROO2] provides distribution files.
   The next tables compare the number of IPv4 addresses available per
   person in a certain country (IPv4 address per capita) against the
   relative adoption of IPv6 in the same country (expressed as the
   number of IPv6 capable users in the considered country).  The table
   shows just a subset of the data available from [POTAROO2].  In
   particular, the following table provides the data for the 25 most
   populated countries in the world.  The table is ordered based on the
   IPv4 addresses per capita ratio and the data refer to the 1st of
   January 2022.

   |Country                     |IPv4 per capita|IPv6 deployment|
   |United States of America    |           4.89|          47.1%|
   |United Kingdom              |           1.65|          33.2%|
   |Japan                       |           1.50|          36.7%|

Fioccola, et al.           Expires 4 June 2023                  [Page 7]
Internet-Draft           IPv6 Deployment Status            December 2022

   |Germany                     |           1.48|          53.0%|
   |France                      |           1.27|          42.1%|
   |Italy                       |           0.91|           4.7%|
   |South Africa                |           0.46|           2.4%|
   |Brazil                      |           0.41|          38.7%|
   |Russian Federation          |           0.31|           9.7%|
   |China                       |           0.24|       60.1%(*)|
   |Egypt                       |           0.24|           4.3%|
   |Mexico                      |           0.23|          41.8%|
   |Turkey                      |           0.20|           0.2%|
   |Vietnam                     |           0.17|          48.0%|
   |Iran (Islamic Republic)     |           0.15|           0.1%|
   |Thailand                    |           0.13|          40.8%|
   |Indonesia                   |           0.07|           5.0%|
   |Philippines                 |           0.05|          13.8%|
   |India                       |           0.03|          76.9%|
   |Pakistan                    |           0.03|           2.1%|
   |United Republic of Tanzania |           0.02|           0.0%|
   |Nigeria                     |           0.02|           0.2%|
   |Bangladesh                  |           0.01|           0.3%|
   |Ethiopia                    |           0.00|           0.0%|
   |Democratic Republic of Congo|           0.00|           0.1%|

     Figure 1: IPv4 per capita and IPv6 deployment for the top 25 most
           populated countries in the world, 1st of January 2022

Fioccola, et al.           Expires 4 June 2023                  [Page 8]
Internet-Draft           IPv6 Deployment Status            December 2022

   (*) The IPv6 deployment information in China is derived from

   A direct correlation between low IPv4 per capita and high IPv6
   adoption is not immediate, yet some indications emerge.  For example,
   countries such as Brazil, China, and India have clearly moved towards
   IPv6 adoption.  As discussed later, this appears related to several
   factors in addition to the lack of IPv4 addresses, including local
   regulation and market-driven actions.  The 5 countries at the top of
   the table, with relative high availability of IPv4 addresses, have
   also shown a good level of IPv6 adoption.  In other cases, a relative
   scarcity of IPv4 addresses has not meant a clear move towards IPv6,
   as several countries listed in the table still have low or very low
   IPv6 adoption.

2.2.  IPv6 Users

   The count of the IPv6 users is the key parameter to get an immediate
   understanding of the adoption of IPv6.  Some organizations constantly
   track the usage of IPv6 by aggregating data from several sources.  As
   an example, the Internet Society constantly monitors the volume of
   IPv6 traffic for the networks that joined the WorldIPv6Launch
   initiative [WIPv6L].  The measurement aggregates statistics from
   organizations such as [Akm-stats] that provides data down to the
   single network level measuring the number of hits to their content
   delivery platform.  For the scope of this document, the approach used
   by APNIC to quantify the adoption of IPv6 by means of a script that
   runs on a user's device [CAIDA] is considered.  To give a rough
   estimation of the relative growth of IPv6, the next table aggregates
   the total number of estimated IPv6-capable users at 1st of January
   2022, and compares it against the total Internet users, as measured
   by [POTAROO2].

   |        |  Jan   |  Jan   |  Jan   |  Jan   |  Jan   |  CAGR  |
   |        |  2018  |  2019  |  2020  |  2021  |  2022  |        |
   |  IPv6  |  513.07|  574.02|  989.25|1,136.28|1,207.61|  23.9% |
   | World  |3,410.27|3,470.36|4,065.00|4,091.62|4,093.69|   4.7% |
   | Ratio  |   15.0%|   16.5%|   24.3%|   27.8%|   29.5%|  18.4% |

       Figure 2: IPv6-capable users against total (in millions) as of
                            1st of January 2022

Fioccola, et al.           Expires 4 June 2023                  [Page 9]
Internet-Draft           IPv6 Deployment Status            December 2022

   Two figures appear: first, the IPv6 Internet population is growing
   with a two-digits Compound Annual Growth Rate (CAGR), and second, the
   ratio IPv6 over total is also growing steadily.

2.3.  IPv6 Web Content

   [W3Techs] keeps track of the use of several technical components of
   websites worldwide through different analytical engines.  The
   utilization of IPv6 for websites is shown in the next table, where
   the percentages refer to the websites which are accessible over IPv6.

   |  Worldwide |  Jan  |  Jan  |  Jan  |  Jan  |  Jan  | CAGR |
   |  Websites  |  2018 |  2019 |  2020 |  2021 |  2022 |      |
   |% of IPv6   | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9%|

             Figure 3: Usage of IPv6 in websites, January 2022

   Looking at the growth rate, it may appear not particularly high.  It
   has to be noted, though, that not all websites are equal.  The
   largest content providers, which already support IPv6, generate a lot
   more content than small websites.  [Csc6lab] measured at the
   beginning of January 2022 that out of the world top 500 sites ranked
   by [Alx], 203 are IPv6-enabled (+3.6% from January 2021 to January
   2022).  If we consider that the big content providers (such as
   Google, Facebook, Netflix) generate more than 50% of the total mobile
   traffic [SNDVN], and in some cases even more up to 65% ([ISOC1]
   [HxBld]), the percentage of content accessible over IPv6 is clearly
   more relevant than the number of enabled IPv6 websites.  It would be
   interesting to know what percentage of that 50% of all mobile traffic
   is IPv6.  Unfortunately, this information is not available.

   Related to that, a question that sometimes arises is whether the
   content stored by content providers would be all accessible on IPv6
   in the hypothetical case of a sudden IPv4 switch-off.  Even if this
   is pure speculation, the numbers above may bring to state that this
   is likely the case.  This would reinforce the common thought that, in
   quantitative terms, most of the content is accessible via IPv6.

Fioccola, et al.           Expires 4 June 2023                 [Page 10]
Internet-Draft           IPv6 Deployment Status            December 2022

2.4.  IPv6 public actions and policies

   As previously noted, the worldwide deployment of IPv6 is not uniform
   [G_stats], [APNIC1].  It is worth noticing that, in some cases,
   higher IPv6 adoption in certain countries has been achieved as a
   consequence of actions taken by the local governments through
   regulation or incentive to the market.  Looking at the European Union
   area, countries such as Belgium, France and Germany are well ahead in
   terms of IPv6 adoption.

   In the case of Belgium, the Belgian Institute for Postal services and
   Telecommunications (BIPT) acted to mediate an agreement between the
   local ISPs and the government to limit the use of Carrier-Grade NAT
   (CGN) systems and of public IPv4 addresses for lawful investigations
   in 2012 [BIPT].  The agreement limited the use of one IPv4 address
   per 16 customers behind NAT.  The economic burden sustained by the
   ISPs for the unoptimized use of NAT induced the shift to IPv6 and its
   increased adoption in the latest years.

   In France, the National Regulator (Autoritee de regulation des
   communications electroniques, or Arcep) introduced an obligation for
   the mobile carriers awarded with a license to use 5G frequencies
   (3.4-3.8GHz) in Metropolitan France to be IPv6 compatible [ARCEP].
   As stated, "the goal is to ensure that services are interoperable and
   to remove obstacles to using services that are only available in
   IPv6, as the number of devices in use continues to soar, and because
   the RIPE NCC has run out of IPv4 addresses".  A slow adoption of IPv6
   could prevent new Internet services to widespread or create a barrier
   to entry for newcomers to the market.  "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
   public actions.  Specifically, the Federal Office for Information
   Technology (under the Federal Ministry of the Interior) issued over
   the years a few recommendations on the use of IPv6 in the German
   public administration.  The latest guideline in 2019 constitutes a
   high-level road map for mandatory IPv6 introduction in the federal
   administration networks [GFA].

   In the United States, the Office of Management and Budget is also
   calling for IPv6 adoption [US-FR], [US-CIO].  These documents define
   a plan to have the 80% of the US Federal IP-capable networks based on
   IPv6-only by the year 2025.  China is another example of government
   which is supporting a country-wide IPv6 adoption [CN].  In India, the
   high adoption of IPv6 took origin from the decision of Reliance Jio
   to move to IPv6 in their networks [RelJio].  In addition, the
   Department of Telecommunications (under the Ministry of

Fioccola, et al.           Expires 4 June 2023                 [Page 11]
Internet-Draft           IPv6 Deployment Status            December 2022

   Communications and Information Technology) issued guidelines for the
   progressive adoption of IPv6 in public and private networks.  The
   latest one dates 2021 [IDT] and fosters further moves to IPv6
   connection services.

3.  A Survey on IPv6 Deployments

   This section discusses the status of IPv6 adoption in service
   providers and enterprises' networks.

3.1.  IPv6 Allocations

   RIRs are responsible for allocating IPv6 address blocks to ISPs, LIRs
   (Local Internet Registries) as well as enterprises or other
   organizations.  An ISP/LIR will use the allocated block to assign
   addresses to their end users.  The following table shows the amount
   of individual allocations, per RIR, in the time period 2017-2021

   | Registry|  Dec  |  Dec  |  Dec  |  Dec  |  Dec  |Cumulated| CAGR |
   |         |  2017 |  2018 |  2019 |  2020 |  2021 |         |      |
   | AFRINIC |   112 |   110 |   115 |   109 |   136 |    582  | 51%  |
   |  APNIC  | 1,369 | 1,474 | 1,484 | 1,498 | 1,392 |  7,217  | 52%  |
   |   ARIN  |   684 |   659 |   605 |   644 |   671 |  3,263  | 48%  |
   |  LACNIC | 1,549 | 1,448 | 1,614 | 1,801 |   730 |  7,142  | 47%  |
   | RIPE NCC| 2,051 | 2,620 | 3,104 | 1,403 | 2,542 | 11,720  | 55%  |
   |         |       |       |       |       |       |         |      |
   |  Total  | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924  | 51%  |

        Figure 4: IPv6 allocations worldwide in the period 2017-2021
                               (January 2022)

   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
   also happens to IPv4 allocations.

   [APNIC2] also compares the number of allocations for both address
   families.  The CAGR looks quite similar in 2021 but a little higher
   for the IPv4 allocations in comparison to the IPv6 allocations (53.6%
   versus 50.9%).

Fioccola, et al.           Expires 4 June 2023                 [Page 12]
Internet-Draft           IPv6 Deployment Status            December 2022

   | Address|  Dec  |  Dec  |  Dec  |  Dec  |  Dec  | Cumulated| CAGR |
   | family |  2017 |  2018 |  2019 |  2020 |  2021 |          |      |
   |  IPv6  | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 |   29,924 | 50.9%|
   |        |       |       |       |       |       |          |      |
   |  IPv4  | 8,091 | 9,707 |13,112 | 6,263 | 7,829 |   45,002 | 53.6%|
   |        |       |       |       |       |       |          |      |

                  Figure 5: Allocations per address family

   The reason may be that the IPv4 allocations in 2021 include many
   allocations of small address ranges (e.g. /24) [APNIC2].  On the
   contrary, a single IPv6 allocation is large enough to cope with the
   need of an operator for long period.  After an operator receives an
   IPv6 /30 or /32 allocation it is unlikely that a new request of
   addresses is repeated in the short term.

   The next table is based on [APNIC3], [APNIC4] and shows the
   percentage of Autonomous Systems (AS) supporting IPv6 compared to the
   total ASes worldwide.  The number of IPv6-capable ASes increased from
   24.3% in January 2018 to 38.7% in January 2022.  This equals to 18%
   CAGR for IPv6-enabled networks.  In comparison, the CAGR for the
   total of IPv6 and IPv4 networks is just 5%.

   | Advertised |  Jan  |  Jan  |  Jan  |  Jan  |  Jan  | CAGR |
   |    ASN     |  2018 |  2019 |  2020 |  2021 |  2022 |      |
   |IPv6-capable| 14,500| 16,470| 18,650| 21,400| 28,140|  18% |
   |            |       |       |       |       |       |      |
   | Total ASN  | 59,700| 63,100| 66,800| 70,400| 72,800|   5% |
   |            |       |       |       |       |       |      |
   |   Ratio    | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% |      |

                 Figure 6: Percentage of IPv6-capable ASes

   The tables above provide an aggregated view of the allocations
   dynamic.  The next subsections will zoom into each specific domain to
   highlight its relative status.

Fioccola, et al.           Expires 4 June 2023                 [Page 13]
Internet-Draft           IPv6 Deployment Status            December 2022

3.2.  IPv6 among Internet Service Providers

   As it was proposed at the time of [RFC6036], also in the case of this
   document a survey was submitted to a group of service providers in
   Europe during the third quarter of 2020 (see Appendix A for the
   complete poll), to understand their plans about IPv6 and their
   technical preferences towards its adoption.  Although such poll does
   not give an exhaustive view on the IPv6 status, it provides some
   insights that are relevant to the discussion.

   The poll revealed that the majority of the ISPs interviewed had plans
   concerning IPv6 (79%).  Of them, 60% had already ongoing activities,
   while 33% was expected to start activities in a 12-months time-frame.
   The transition to IPv6 involved all business segments: mobile (63%),
   fixed (63%), and enterprises (50%).

   The reasons to move to IPv6 varied.  Global IPv4 address depletion
   and the run out of private address space recommended in [RFC1918]
   were reported as the important drivers for IPv6 deployment (48%).  In
   a few cases, respondents cited the requirement of national IPv6
   policies and the launch of 5G as the reasons (13%).  Enterprise
   customers demand was also a reason to introduce IPv6 (13%).

   From a technical preference standpoint, Dual-Stack [RFC4213] was the
   most adopted solution, in both wireline (59%) and cellular networks
   (39%).  In wireline, the second most adopted mechanism was Dual-Stack
   Lite (DS-Lite) [RFC6333] (19%).  In cellular networks, the second
   preference was 464XLAT [RFC6877] (21%).

   More details about the answers received can be found in Appendix A.

3.3.  IPv6 among Enterprises

   As described in [RFC7381], enterprises face different challenges than
   ISPs.  Publicly available reports show how the enterprise deployment
   of IPv6 lags behind ISP deployment [cmpwr].

   [NST_1] provides estimations on deployment status of IPv6 for domains
   such as, or in the United States.
   The measurement encompasses many industries, including
   telecommunications, so the term "enterprises" is a bit loose in this
   context.  In any case, it provides a first indication of IPv6
   adoption in several US industry sectors.  The analysis tries to infer
   whether IPv6 is supported by looking from "outside" a company's
   network.  It takes into consideration the support of IPv6 to external
   services such as Domain Name System (DNS), mail and website.  [BGR_1]
   has similar data for China while [CNLABS_1] provides the status in

Fioccola, et al.           Expires 4 June 2023                 [Page 14]
Internet-Draft           IPv6 Deployment Status            December 2022

   |Country       | Domains  |   DNS   |  Mail   | Website |
   |              | analyzed |         |         |         |
   |China         |    478   |  74.7%  |   0.0%  |   19.7% |
   |              |          |         |         |         |
   |India         |    104   |  51.9%  |  15.4%  |   16.3% |
   |              |          |         |         |         |
   |United States |   1070   |  66.8%  |  21.2%  |    6.3% |
   |of America    |          |         |         |         |

         Figure 7: IPv6 support for external-facing services across
                         enterprises (January 2022)

   A poll submitted to a group of large enterprises in North America in
   early 2021 (see Appendix B) shows that the operational issues are
   even more critical than for ISPs.

   Looking at current implementations, almost one third has dual-stacked
   networks, while 20% declares that portions of their networks are
   IPv6-only. 35% of the enterprises are stuck at the training phase.
   In no case is the network fully IPv6-based.

   Speaking of training, the most critical needs are in the field of
   IPv6 security and IPv6 troubleshooting (both highlighted by the two
   thirds of respondents), followed by IPv6 fundamentals (57.41%).

   Coming to implementation, the three areas of concern are IPv6
   security (31.48%), training (27.78%), application conversion
   (25.93%). 33.33% of respondents think that all three areas are all
   simultaneously of concern.

   The full poll is reported in Appendix B.

3.3.1.  Government and Universities

   This section focuses specifically on the IPv6 adoption of governments
   and academia.

Fioccola, et al.           Expires 4 June 2023                 [Page 15]
Internet-Draft           IPv6 Deployment Status            December 2022

   As far as governmental agencies are concerned, [NST_2] provides
   analytics on the degree of IPv6 support for DNS, mail and websites
   across second level domains associated with the US federal agencies.
   These domains are in the form of or example.fed.  The
   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
   European Union [IPv6Forum].  For this latter analytic some post-
   processing is necessary to filter out the non-European domains.

   |Country       | Domains  |   DNS   |  Mail   | Website |
   |              | analyzed |         |         |         |
   |China         |     52   |   0.0%  |   0.0%  |   98.1% |
   |              |          |         |         |         |
   |European      |     19   |  47.4%  |   0.0%  |   21.1% |
   |Union (*)     |          |         |         |         |
   |India         |    618   |   7.6%  |   6.5%  |    7.1% |
   |              |          |         |         |         |
   |United States |   1283   |  87.1%  |  14.0%  |   51.7% |
   |of America    |          |         |         |         |

         Figure 8: IPv6 support for external-facing services across
                  governmental institutions (January 2022)

   (*) Both EU and country specific domains are considered.

   USA's IPv6 support is higher than other countries.  This is likely
   due to the IPv6 mandate set by [US-CIO].  In the case of India, the
   degree of support seems still quite low.  This is also true for
   China, with the notable exception of high percentage of IPv6-enabled
   websites for government-related organizations.

   Similar statistics are also available for higher education.  [NST_3]
   measures the data from second level domains of universities in the
   US, such as  [BGR_3] looks at Chinese education-related
   domains.  [CNLABS_1] analyzes domains in India (mostly third level),
   while [IPv6Forum] lists universities in the European Union (second
   level), again after filtering the non-European domains.

Fioccola, et al.           Expires 4 June 2023                 [Page 16]
Internet-Draft           IPv6 Deployment Status            December 2022

   |Country       | Domains  |   DNS   |  Mail   | Website |
   |              | analyzed |         |         |         |
   |China         |    111   |  36.9%  |   0.0%  |   77.5% |
   |              |          |         |         |         |
   |European      |    118   |  83.9%  |  43.2%  |   35.6% |
   |Union         |          |         |         |         |
   |India         |    100   |  31.0%  |  54.0%  |    5.0% |
   |              |          |         |         |         |
   |United States |    346   |  49.1%  |  19.4%  |   21.7% |
   |of America    |          |         |         |         |

         Figure 9: IPv6 support for external-facing services across
                        universities (January 2022)

   Overall, the universities have wider support of IPv6-based services
   compared to the other sectors.  Apart from a couple of exceptions
   (e.g. the support of IPv6 mail in China and IPv6 websites in India),
   the numbers shown in the table above indicate a good support of IPv6
   in academia.

4.  IPv6 deployment scenarios

   The scope of this section is to discuss the network and service
   scenarios applicable for the transition to IPv6.  Most of the related
   definitions have been provided in Section 1.1.  This clause is
   intended to focus on the technical and operational characteristics.
   The sequence of scenarios described here does not have necessarily to
   be intended as a road map for the IPv6 transition.  Depending on
   their specific plans and requirements, service providers may either
   adopt the scenarios proposed in a sequence or jump directly to a
   specific one.

4.1.  Dual-Stack

   Based on the answers provided by network operators to the poll
   (Appendix A), Dual-Stack [RFC4213] appears to be currently the most
   widely deployed IPv6 solution (about 50%, see both Appendix A and the
   statistics reported in [ETSI-IP6-WhitePaper]).

   With Dual-Stack, IPv6 can be introduced together with other network
   upgrades and many parts of network management and IT systems can
   still work in IPv4.  This avoids major upgrade of such systems to

Fioccola, et al.           Expires 4 June 2023                 [Page 17]
Internet-Draft           IPv6 Deployment Status            December 2022

   support IPv6, which is possibly the most difficult task in the IPv6
   transition.  The cost and effort on the network management and IT
   systems upgrade are moderate.  The benefits are to start using IPv6
   and save NAT costs.

   Although Dual-Stack may provide advantages in the introductory stage,
   it does have a few disadvantages in the long run, like the
   duplication of the network resources and states.  It also requires
   more IPv4 addresses, thus increasing both Capital Expenses (CAPEX)
   and Operating Expenses (OPEX).  For example, even if private
   addresses are used with Carrier-Grade NAT (CGN), there is extra
   investment in the CGN devices, logs storage and help-desk to track
   CGN-related issues.

   For this reason, when IPv6 usage exceeds certain threshold, it may be
   advantageous to start a transition to a next scenario.  For example,
   the process may start with the IPv4aaS stage, as described
   hereinafter.  It is difficult to establish the criterion for
   switching (e.g. to properly identify the upper bound of the IPv4
   decrease or the lower bound of the IPv6 increase).  In addition to
   the technical factors, the switch to the next scenarios may also
   cause a loss of customers.  Based on the feedback of network
   operators participating in World IPv6 Launch [WIPv6L] in June 2021,
   108 out of 346 operators exceed 50% of IPv6 traffic volume (31.2%),
   72 exceed 60% (20.8%), while 37 exceed 75% (10.7%).  The consensus to
   move to IPv6-only might be reasonable when IPv6 traffic volume is
   between 50% and 60%.

4.2.  IPv6-only Overlay

   As defined in Section 1.1, IPv6-only is generally associated with a
   scope, e.g.  IPv6-only overlay or IPv6-only underlay.

   The IPv6-only overlay denotes that the overlay tunnel between the end
   points of a network is based only on IPv6.  Tunneling provides a way
   to use an existing IPv4 infrastructure to carry IPv6 traffic.  IPv6
   or IPv4 hosts and routers can tunnel IPv6 packets over IPv4 regions
   by encapsulating them within IPv4 packets.  The approach with
   IPv6-only overlay helps to maintain compatibility with the existing
   base of IPv4, but it is not a long-term solution.

   As a matter of fact, IPv4 reachability must be provided for a long
   time to come over IPv6 for IPv6-only hosts.  Most ISPs are leveraging
   CGN to extend the life of IPv4 instead of going with IPv6-only

Fioccola, et al.           Expires 4 June 2023                 [Page 18]
Internet-Draft           IPv6 Deployment Status            December 2022

4.3.  IPv6-only Underlay

   IPv6-only underlay network uses IPv6 as the network protocol for all
   traffic delivery.  Both the control and data planes are IPv6-based.
   The definition of IPv6-only underlay needs to be associated with a
   scope in order to identify the domain where it is applicable, such as
   IPv6-only access network or IPv6-only backbone network.

   When both enterprises and service providers begin to transit from an
   IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not
   necessarily need to dual-stack the underlay.  Forwarding plane
   complexity on the Provider (P) nodes of the ISP core should be kept
   simple as a single protocol only backbone.  Hence, when operators
   decide to transit to an IPv6 underlay, the ISP backbone should be
   IPv6-only while Dual-Stack is not the best choice.  The underlay
   could be IPv6-only and allows IPv4 packets to be tunneled using VPN
   over an IPv6-only backbone and leveraging [RFC8950], which specifies
   the extensions necessary to allow advertising IPv4 Network Layer
   Routing Information (NLRI) with an IPv6 Next Hop.

   IPv6-only underlay network deployment for access and backbone
   network, seems not the first option and the current trend is to keep
   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
   network or backbone network, e.g.  Segment Routing over IPv6 data
   plane (SRv6), they start the elimination of IPv4 from the underlay
   transport network while continuing to provide IPv4 services.
   Basically, as also showed by the poll among network operators, from a
   network architecture perspective, it is not recommended to apply
   Dual-Stack to the transport network per reasons mentioned above
   related to the forwarding plane complexities.

4.4.  IPv4 as a Service

   IPv4aaS can be used to ensure IPv4 support and it can be a complex
   decision that depends on several factors, such as economic aspects,
   policy and government regulation.

   [RFC9313] compares the merits of the most common transition solutions
   for IPv4aaS, i.e. 464XLAT [RFC6877], DS-lite [RFC6333], Lightweight
   4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599], but
   does not provide an explicit recommendation.  However, the poll in
   Appendix A indicates that the most widely deployed IPv6 transition
   solution in the Mobile Broadband (MBB) domain is 464XLAT while in the
   Fixed Broadband (FBB) domain is DS-Lite.

Fioccola, et al.           Expires 4 June 2023                 [Page 19]
Internet-Draft           IPv6 Deployment Status            December 2022

   Both are IPv4aaS solutions by leveraging IPv6-only underlay.  IPv4aaS
   offers Dual-Stack service to users and allows an ISP to run IPv6-only
   in the network, typically the access network.

   While it may not always be the case, IPv6-only transition
   technologies such as 464XLAT require far fewer IPv4 addresses
   [RFC9313], because they make a more efficient usage without
   restricting the number of ports per subscriber.  This helps to reduce
   troubleshooting costs and to remove some operational issues related
   to permanent block-listing of IPv4 address blocks when used via CGN
   in some services.

   IPv4aaS may be facilitated by the natural upgrade or replacement of
   CPEs because of newer technologies (tripe-play, higher bandwidth WAN
   links, better Wi-Fi technologies, etc.).  The CAPEX and OPEX of other
   parts of the network may be lowered (for example CGN and associated
   logs) due to the operational simplification of the network.

   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
   private address space [RFC1918] is not enough.  Also, Dual-Stack will
   likely lead to duplication of network resources and operations to
   support both IPv6 and IPv4, which increases the amount of state
   information in the network.  This suggests that for scenarios such as
   MBB or large DCs, IPv4aaS could be more efficient from the start of
   the IPv6 introduction.

   So, in general, when the Dual-Stack disadvantages outweigh the
   IPv6-only complexity, it makes sense to transit to IPv4aaS.  Some
   network operators already started this process, as in the case of
   [TMus], [RelJio] and [EE].

4.5.  IPv6-only

   IPv6-only is the final stage of the IPv6 transition and it happens
   when a complete network, end-to-end, no longer has IPv4.  No IPv4
   address is configured for network management or anything.

   Since IPv6-only means that both underlay network and overlay services
   are only IPv6, it will take longer to happen.

Fioccola, et al.           Expires 4 June 2023                 [Page 20]
Internet-Draft           IPv6 Deployment Status            December 2022

5.  Common IPv6 Challenges

   This section lists common IPv6 challenges, which have been validated
   and discussed during several meetings and public events.  The scope
   is to encourage more investigations.  Despite IPv6 has already been
   well-proven in production, there are some challenges to consider.  In
   this regard, it is worth noting that [ETSI-GR-IPE-001] also discusses
   gaps that still exist in IPv6 related use cases.

5.1.  Transition Choices

   A service provider, an enterprise or a CSP may perceive quite a
   complex task the transition to IPv6, due to the many technical
   alternatives available and the changes required in management and
   operations.  Moreover, the choice of the method to support the
   transition is an important challenge and may depend on factors
   specific to the context, such as the IPv6 network design that fits
   the service requirements, the network operations and the deployment

   This section briefly highlights the approaches that the different
   parties may take and the related challenges.

5.1.1.  Service Providers

   For fixed operators, the massive software upgrade of CPEs to support
   Dual-Stack already started in most of the service provider networks.
   On average, looking at the global statistics, the IPv6 traffic
   percentage is currently around 40% [G_stats].  As highlighted in
   section 3.2, all major content providers have already implemented
   Dual-Stack access to their services and most of them have implemented
   IPv6-only in their Data Centers.  This aspect could affect the
   decision on the IPv6 adoption for an operator, but there are also
   other factors like the current IPv4 address shortage, CPE costs, CGN
   costs and so on.

      Fixed Operators with a Dual-Stack architecture, can start defining
      and apply a new strategy when reaching the limit in terms of
      number of IPv4 addresses available.  This may be done through CGN
      or with an IPv4aaS approach.

      Most of the fixed operators remain attached to a Dual-Stack
      architecture and many have already employed CGN.  In this case it
      is likely that CGN boosts their ability to supply IPv4
      connectivity to CPEs for more years to come.  Indeed, only few
      fixed operators have chosen to move to an IPv6-only scenario.

Fioccola, et al.           Expires 4 June 2023                 [Page 21]
Internet-Draft           IPv6 Deployment Status            December 2022

   For mobile operators, the situation is quite different since, in some
   cases, mobile operators are already stretching their IPv4 address
   space.  The reason is that CGN translation limits have been reached
   and no more IPv4 public pool addresses are available.

      Some mobile operators choose to implement Dual-Stack as first and
      immediate mitigation solution.

      Other mobile operators prefer to move to IPv4aaS solutions (e.g.
      464XLAT) since Dual-Stack only mitigates and does not solve
      completely the IPv4 address scarcity issue.

   For both fixed and mobile operators the approach for the transition
   is not unique and this brings different challenges in relation to the
   network architecture and related costs.  So each operator needs to do
   own evaluations for the transition based on the specific situation.

5.1.2.  Enterprises

   At present, the usage of IPv6 for enterprises often relies on
   upstream service providers, since the enterprise connectivity depends
   on the services provided by their upstream provider.  Regarding the
   enterprises internal infrastructure, IPv6 shows its advantages in the
   case of merger and acquisition, because it can be avoided the
   overlapping of the two address spaces, which is common in case of
   IPv4 private addresses.  In addition, since several governments are
   introducing IPv6 policy, all the enterprises providing consulting
   service to governments are also required to support IPv6.

   However, enterprises face some challenges.  They are shielded from
   IPv4 address depletion issues due to their prevalent use of Proxy and
   private addressing [RFC1918], thus do not have the business
   requirement or technical justification to transit to IPv6.
   Enterprises need to find a business case and a strong motivation for
   IPv6 transition to justify additional CAPEX and OPEX.  Also, since
   Information and Communication Technologies (ICT) is not the core
   business for most of the enterprises, ICT budget is often constrained
   and cannot expand considerably.  But, there are examples of big
   enterprises that are considering IPv6 to achieve business targets
   through a more efficient IPv6 network and to introduce newer services
   which require IPv6 network architecture.

   Enterprises worldwide, in particular small and medium-sized, are
   quite late to adopt IPv6, especially on internal networks.  In most
   cases, the enterprise engineers and technicians do not have a great
   experience with IPv6 and the problem of application porting to IPv6
   looks quite difficult.  As highlighted in the relevant poll, the
   technicians may need to get trained but the management do not see a

Fioccola, et al.           Expires 4 June 2023                 [Page 22]
Internet-Draft           IPv6 Deployment Status            December 2022

   business need for adoption.  This creates an unfortunate cycle where
   the perceived complexity of the IPv6 protocol and concerns about
   security and manageability combine with the lack of urgent business
   needs to prevent adoption of IPv6.  In 2019 and 2020, there has been
   a concerted effort by some ARIN and APNIC initiatives to provide
   training [ARIN-CG] [ISIF-ASIA-G].

5.1.3.  Industrial Internet

   In an industrial environment, OT (Operational technology) refers to
   the systems used to monitor and control processes within a factory or
   production environment, while IT (Information technology) refers to
   anything related to computer technology and networking connectivity.
   IPv6 is frequently mentioned in relation to Industry 4.0 and Internet
   of Things (IoT), affecting both OT and IT evolution.

   There are potential advantages for using IPv6 for Industrial Internet
   of Things (IIoT), in particular the large IPv6 address space, the
   automatic IPv6 address configuration and resource discovery.
   However, its industrial adoption, in particular in smart
   manufacturing systems, has been much slower than expected.  There are
   still many obstacles and challenges that prevent its pervasive use.
   The key problems identified are the incomplete or underdeveloped tool
   support, the dependency on manual configuration and the poor
   knowledge of the IPv6 protocols.  To promote the use of IPv6 for
   smart manufacturing systems and IIoT applications a generic approach
   to remove these pain points is highly desirable.  Indeed, as for
   enterprises, it is important to provide an easy way to familiarize
   system architects and software developers with the IPv6 protocol.

   Advances in cloud-based platforms and developments in artificial
   intelligence (AI) and machine learning (ML) allow OT and IT systems
   to integrate and migrate to a centralized analytical, processing, and
   integrated platform, which must act in real-time.  The limitation is
   that manufacturing companies have diverse corporate cultures and the
   adoption of new technologies may lag as a result.

   For Industrial Internet and related IIoT applications, it would be
   desirable to leverage the configuration-less characteristic of IPv6
   to automatically manage and control the IoT devices.  In addition, it
   could be interesting to have the ability to use IP based
   communication and standard application protocols at every point in
   the production process and further reduce the use of specialized
   communication systems.

Fioccola, et al.           Expires 4 June 2023                 [Page 23]
Internet-Draft           IPv6 Deployment Status            December 2022

5.1.4.  Content and Cloud Service Providers

   The high number of addresses required to connect the virtual and
   physical elements in a Data Center and the necessity to overcome the
   limitation posed by [RFC1918] have been the drivers to the adoption
   of IPv6 in several CSP networks.

   Most CSPs have adopted IPv6 in their internal infrastructure but are
   also active in gathering IPv4 addresses on the transfer market to
   serve the current business needs of IPv4 connectivity.  As noted in
   the previous section, most enterprises do not consider the transition
   to IPv6 as a priority.  To this extent, the use of IPv4-based network
   services by the CSPs will last.

   Several public references, as reported hereinafter, discuss how most
   of the major players find themselves at different stages in the
   transition to IPv6-only in their Data Center (DC) infrastructure.  In
   some cases, the transition already happened and the DC infrastructure
   of these hyperscalers is completely based on IPv6.

   It is interesting to look at how much traffic in a network is going
   to Caches and Content Delivery Networks (CDNs).  The response is
   expected to be a high percentage, at least higher than 50% in most of
   the cases, since all the key Caches and CDNs are IPv6-ready [Cldflr],
   [Ggl], [Ntflx], [Amzn], [Mcrsft], [Vrzn].  So the percentage of
   traffic going to the key Caches/CDNs is a good approximation of the
   potential IPv6 traffic in a network.

   The challenges for CSPs are mainly related to the continuous support
   of IPv4 to be guaranteed, since most CSPs already completed the
   transition to IPv6-only.  If, in the next years, the scarcity of IPv4
   addresses becomes more evident, it is likely that the cost of buying
   an IPv4 address by a CSP could be charged to their customers.

5.1.5.  CPEs and user devices

   It can be noted that most of the user devices (e.g. smartphones) are
   already IPv6-enabled since many years.  But there are exceptions, for
   example, smartTVs typically had IPv6 support since few years ago,
   however not all the economies replace them at the same pace.

   As already mentioned, ISPs who historically provided public IPv4
   addresses to their customers generally still have those IPv4
   addresses (unless they chose to transfer them).  Some have chosen to
   put new customers on CGN but without touching existing customers.
   Because of the extreme small number of customers who notice that IPv4
   is done via NAT444 (i.e. the preferred CGN solution for carriers), it
   could be less likely to run out of IPv4 addresses and private IPv4

Fioccola, et al.           Expires 4 June 2023                 [Page 24]
Internet-Draft           IPv6 Deployment Status            December 2022

   space.  But as IPv4-only devices and traffic reduce, then the need to
   support private and public IPv4 become less.  So the complete support
   of CPEs to IPv6 is also an important challenge and incentive to
   overcome Dual-Stack towards IPv4aaS solution [ANSI].

5.1.6.  Software Applications

   The transition to IPv6 requires that the application software is
   adapted for use in IPv6-based networks ([ARIN-SW] provides an
   example).  The use of transition mechanisms like 464XLAT is essential
   to support IPv4-only applications while they evolve to IPv6.
   Depending on the transition mechanism employed some issues may
   remain.  For example, in the case of NAT64/DNS64 the use of literal
   IPv4 addresses, instead of DNS names, will fail, unless mechanisms
   such as Application Level Gateways (ALG) are used.  This issue is not
   present in 464XLAT (see [RFC8683]).

   It is worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect
   of application transition to IPv6.

5.2.  Network Management and Operations

   There are important IPv6 complementary solutions related to
   Operations, Administration and Maintenance (OAM) that look less
   mature compared to IPv4.  Network Management System (NMS) has a
   central role in the modern networks for both network operators and
   enterprises and its transition is a fundamental issue.  This is
   because some IPv6 products are not as field-proven as for IPv4 even
   if conventional protocols (e.g.  SNMP, RADIUS) already support IPv6.
   In addition, incompatible vendor road map for the development of new
   NMS features affects the confidence of network operators or

   An important factor is represented by the need for training the
   network operations workforce.  Deploying IPv6 requires that policies
   and procedures have to be adjusted in order to successfully plan and
   complete an IPv6 transition.  Staff has to be aware of the best
   practices for managing IPv4 and IPv6 assets.  In addition to network
   nodes, network management applications and equipment need to be
   properly configured and in some cases also replaced.  This may
   introduce more complexity and costs for the transition.

Fioccola, et al.           Expires 4 June 2023                 [Page 25]
Internet-Draft           IPv6 Deployment Status            December 2022

   Availability of both systems and training is necessary in areas such
   as IPv6 addressing.  IPv6 addresses can be assigned to an interface
   through different means, such as Stateless Auto-Configuration (SLAAC)
   [RFC4862], or by using stateful Dynamic Host Control Protocol (DHCP)
   [RFC8415].  IP Address Management (IPAM) systems may contribute to
   handle the technical differences and automate some of the
   configuration tasks, such as the address assignment or the management
   of DHCP services.

5.3.  Performance

   People tend to compare the performance of IPv6 versus IPv4 to argue
   or motivate the IPv6 transition.  In some cases, IPv6 behaving
   "worse" than IPv4 may be used as an argument for avoiding the full
   adoption of IPv6.  However, there are some aspects where IPv6 has
   already filled (or is filling) the gap to IPv4.  This position is
   supported when looking at available analytics on two critical
   parameters: packet loss and latency.  These parameters have been
   constantly monitored over time, but only a few comprehensive
   measurement campaigns are providing up-to-date information.  While
   performance is undoubtedly an important issue to consider and worth
   further investigation, reality is that a definitive answer cannot be
   found on what IP version performs better.  Depending on the specific
   use case and application, IPv6 is better; in others the same applies
   to IPv4.

5.3.1.  IPv6 packet loss and latency

   [APNIC5] provides a measurement of both the failure rate and Round
   Trip Time (RTT) of IPv6 compared against IPv4.  Both measures are
   based on scripts that employs the three-way handshake of TCP.  As
   such, the measurement of the failure rate does not provide a direct
   measurement of packet loss (that would need an Internet-wide
   measurement campaign).  Said that, despite IPv4 is still performing
   better, the difference seems to have decreased in recent years.  Two
   reports, namely [RIPE1] and [APRICOT], discussed the associated
   trend, showing how the average worldwide failure rate of IPv6 is
   still a bit worse than IPv4.  Reasons for this effect may be found in
   endpoints with an unreachable IPv6 address, routing instability or
   firewall behavior.  Yet, this worsening effect may appear as
   disturbing for a plain transition to IPv6.

   [APNIC5] also compares the latency of both address families.
   Currently, the worldwide average is slightly in favor of IPv6.
   Zooming at the country or even at the operator level, it is possible
   to get more detailed information and appreciate that cases exist
   where IPv6 is faster than IPv4.  Regions (e.g.  Western Europe,
   Northern America, Southern Asia) and Countries (e.g.  US, India,

Fioccola, et al.           Expires 4 June 2023                 [Page 26]
Internet-Draft           IPv6 Deployment Status            December 2022

   Germany) with an advanced deployment of IPv6 (e.g. >45%) are showing
   that IPv6 has better performance than IPv4.  [APRICOT] highlights how
   when a difference in performance exists it is often related to
   asymmetric routing issues.  Other possible explanations for a
   relative latency difference lies on the specificity of the IPv6
   header which allows packet fragmentation.  In turn, this means that
   hardware needs to spend cycles to analyze all of the header sections
   and when it is not capable of handling one of them it drops the
   packet.  A few measurement campaigns on the behavior of IPv6 in CDNs
   are also available [MAPRG], [INFOCOM].  The TCP connect time is still
   higher for IPv6 in both cases, even if the gap has reduced over the
   analysis time window.

5.3.2.  Customer Experience

   It is not totally clear if the Customer Experience is in some way
   perceived as better when IPv6 is used instead of IPv4.  In some cases
   it has been publicly reported by IPv6 content providers, that users
   have a better experience when using IPv6-only compared to IPv4
   [ISOC2].  This could be explained because in the case of an IPv6 user
   connecting to an application hosted in an IPv6-only Data Centers, the
   connection is end-to-end, without translations.  Instead, when using
   IPv4 there is a NAT translation either in the CPE or in the service
   provider's network, in addition to IPv4 to IPv6 (and back to IPv4)
   translation in the IPv6-only content provider Data Center.  [ISOC2],
   [FB] provide reasons in favor of IPv6.  In other cases, the result
   seems to be still slightly in favor of IPv4 [INFOCOM], [MAPRG], even
   if the difference between IPv4 and IPv6 tends to vanish over time.

5.4.  IPv6 security and privacy

   An important point that is sometimes considered as a challenge when
   discussing the transition to IPv6 is related to the security and
   privacy.  [RFC9099] analyzes the operational security issues in
   several places of a network (enterprises, service providers and
   residential users).  It is also worth considering the additional
   security issues brought by the applied IPv6 transition technologies
   used to implement IPv4aaS (e.g. 464XLAT, DS-Lite) [ComputSecur].

   The security aspects have to be considered to keep at least the same
   or even a better level of security as it exists nowadays in an IPv4
   network environment.  The autoconfiguration features of IPv6 will
   require some more attention.  Router discovery and address
   autoconfiguration may produce unexpected results and security holes.
   IPsec protects IPv6 traffic at least as well as it does IPv4, and the
   security protocols for constrained devices (IoT) are designed for
   IPv6 operation.

Fioccola, et al.           Expires 4 June 2023                 [Page 27]
Internet-Draft           IPv6 Deployment Status            December 2022

   IPv6 was designed to restore the end-to-end model of communications
   with all nodes on networks using globally unique addresses.  But,
   considering this, IPv6 may imply privacy concerns, due to greater
   visibility on the Internet.  IPv6 nodes can (and typically do) use
   privacy extensions [RFC8981] to prevent any tracking of their burned-
   in MAC address(es), which are easily readable in the original
   modified EUI-64 interface identifier format.  But, on the other hand,
   stable IPv6 interface identifiers ([RFC8064]) were developed and this
   can also affect privacy.

   As reported in [ISOC3], comparing IPv6 and IPv4 at the protocol
   level, one may probably conclude that the increased complexity of
   IPv6 results in an increased number of attack vectors, that imply
   more possible ways to perform different types of attacks.  However, a
   more interesting and practical question is how IPv6 deployments
   compare to IPv4 deployments in terms of security.  In that sense,
   there are a number of aspects to consider.

   Most security vulnerabilities related to network protocols are based
   on implementation flaws.  Typically, security researchers find
   vulnerabilities in protocol implementations, which eventually are
   "patched" to mitigate such vulnerabilities.  Over time, this process
   of finding and patching vulnerabilities results in more robust
   implementations.  For obvious reasons, the IPv4 protocols have
   benefited from the work of security researchers for much longer, and
   thus, IPv4 implementations are generally more robust than IPv6.
   However, with more IPv6 deployment, IPv6 will also benefit from this
   process in the long run.  It is also worth mentioning that most
   vulnerabilities are nowadays in the human being and in the
   application layer and not in the IP layer.

   Besides the intrinsic properties of the protocols, the security level
   of the resulting deployments is closely related to the level of
   expertise of network and security engineers.  In that sense, there is
   obviously much more experience and confidence with deploying and
   operating IPv4 networks than with deploying and operating IPv6

5.4.1.  Protocols security issues

   In general, there are security concerns related to IPv6 that can be
   classified as follows:

   *  Basic IPv6 protocol (Basic header, Extension Headers, Addressing)

   *  IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)

Fioccola, et al.           Expires 4 June 2023                 [Page 28]
Internet-Draft           IPv6 Deployment Status            December 2022

   *  Internet-wide IPv6 security (Filtering, DDoS, Transition

   ICMPv6 is an integral part of IPv6 and performs error reporting and
   diagnostic functions.  Neighbor Discovery Protocol (NDP) is a node
   discovery protocol in IPv6 which replaces and enhances functions of
   ARP.  Multicast Listener Discovery (MLD) is used by IPv6 routers for
   discovering multicast listeners on a directly attached link, much
   like Internet Group Management Protocol (IGMP) is used in IPv4.

   These IPv6 associated protocols like ICMPv6, NDP and MLD are
   something new compared to IPv4, so they add new security threats and
   the related solutions are still under discussion today.  NDP has
   vulnerabilities [RFC3756] [RFC6583].  The specification says to use
   IPsec but it is impractical and not used, on the other hand, SEND
   (SEcure Neighbour Discovery) [RFC3971] is not widely available.  It
   is worth mentioning that applying host isolation may address many of
   these concerns, as described in [I-D.ietf-v6ops-nd-considerations].

   [RIPE2] describes the most important threats and solutions regarding
   IPv6 security.  IPv6 Extension Headers and Fragmentation

   IPv6 Extension Headers provide a hook for interesting new features to
   be added, and are more flexible than IPv4 Options.  This does add
   some complexity, and in particular some security mechanisms may
   require to process the full chain of headers, and some firewalls may
   require to filter packets based on their Extension Headers.
   Additionally, packets with IPv6 Extension Headers may be dropped in
   the public Internet [RFC7872].  Some documents, e.g.
   [I-D.ietf-6man-hbh-processing], [I-D.ietf-v6ops-hbh],
   [I-D.bonica-6man-ext-hdr-update], analyze and provide guidance
   regarding the processing procedures of IPv6 Extension Headers.

   Defense against possible attacks through Extension Headers is
   necessary.  For example, the original IPv6 Routing Header type 0
   (RH0) was deprecated because of possible remote traffic amplification
   [RFC5095].  In addition, it is worth mentioning that unrecognized
   Hop-by-Hop Options Header and Destination Options Header will not be
   considered by the nodes if they are not configured to deal with it
   [RFC8200].  Other attacks based on Extension Headers may be based on
   IPv6 Header Chains and Fragmentation that could be used to bypass
   filtering.  To mitigate this effect, the initial IPv6 Header, the
   Extension Headers and the Upper-Layer Header must all be in the first
   fragment [RFC8200].  Also, the use of the IPv6 Fragmentation Header
   is forbidden in all Neighbor Discovery messages [RFC6980].

Fioccola, et al.           Expires 4 June 2023                 [Page 29]
Internet-Draft           IPv6 Deployment Status            December 2022

   Fragment Header is used by IPv6 source node to send a packet bigger
   than path MTU and the Destination host processes fragment headers.
   There are several threats related to fragmentation to pay attention
   to e.g. overlapping fragments (not allowed) resource consumption
   while waiting for last fragment (to discard), atomic fragments (to be

   The operational implications of IPv6 Packets with Extension Headers
   are further discussed in [RFC9098].

6.  Security Considerations

   This document has no impact on the security properties of specific
   IPv6 protocols or transition tools.  In addition to the discussion
   above in Section 5.4, the security considerations relating to the
   protocols and transition tools are described in the relevant

7.  Contributors

   Nalini Elkins
   Inside Products

   Sébastien Lourdez
   Post Luxembourg

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

Fioccola, et al.           Expires 4 June 2023                 [Page 30]
Internet-Draft           IPv6 Deployment Status            December 2022

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <>.

   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",
              RFC 3756, DOI 10.17487/RFC3756, May 2004,

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213,
              DOI 10.17487/RFC4213, October 2005,

   [RFC6036]  Carpenter, B. and S. Jiang, "Emerging Service Provider
              Scenarios for IPv6 Deployment", RFC 6036,
              DOI 10.17487/RFC6036, October 2010,

   [RFC6180]  Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment", RFC 6180,
              DOI 10.17487/RFC6180, May 2011,

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,

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

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,

Fioccola, et al.           Expires 4 June 2023                 [Page 31]
Internet-Draft           IPv6 Deployment Status            December 2022

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,

   [RFC6883]  Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
              Content Providers and Application Service Providers",
              RFC 6883, DOI 10.17487/RFC6883, March 2013,

   [RFC7381]  Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
              Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
              Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,

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

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

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <>.

   [RFC8950]  Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
              Patel, "Advertising IPv4 Network Layer Reachability
              Information (NLRI) with an IPv6 Next Hop", RFC 8950,
              DOI 10.17487/RFC8950, November 2020,

   [RFC9099]  Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
              "Operational Security Considerations for IPv6 Networks",
              RFC 9099, DOI 10.17487/RFC9099, August 2021,

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

Fioccola, et al.           Expires 4 June 2023                 [Page 32]
Internet-Draft           IPv6 Deployment Status            December 2022

10.2.  Informative References

              Akamai, "IPv6 Adoption Visualization", 2021,

   [Alx]      Alexa, "The top 500 sites on the web", 2021,

   [Amzn]     Amazon, "Announcing Internet Protocol Version 6 (IPv6)
              support for Amazon CloudFront, AWS WAF, and Amazon S3
              Transfer Acceleration", <

   [ANSI]     ANSI/CTA, "ANSI/CTA Standard Host and Router Profiles for
              IPv6", 2020, <

   [APNIC1]   APNIC, "IPv6 Capable Rate by country (%)", 2022,

   [APNIC2]   APNIC2, "IP Addressing 2021", 2022,

   [APNIC3]   APNIC, "BGP in 2020 – The BGP Table", 2021,

   [APNIC4]   APNIC, "BGP in 2021 – The BGP Table", 2022,

   [APNIC5]   APNIC, "Average RTT Difference (ms) (V6 - V4) for World
              (XA)", 2022, <>.

   [APRICOT]  Huston, G., "Average RTT Difference (ms) (V6 - V4) for
              World (XA)", 2020,

   [ARCEP]    ARCEP, "Arcep Décision n° 2019-1386, Decision on the terms
              and conditions for awarding licences to use frequencies in
              the 3.4–3.8GHz band", 2019,

Fioccola, et al.           Expires 4 June 2023                 [Page 33]
Internet-Draft           IPv6 Deployment Status            December 2022

   [ARIN-CG]  ARIN, "Community Grant Program: IPv6 Security,
              Applications, and Training for Enterprises", 2020,

   [ARIN-SW]  ARIN, "Preparing Applications for IPv6",

   [BGR_1]    BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment
              Monitor", 2022,

   [BGR_2]    BIIGROUP, "China Government IPv6 and DNSSEC Deployment
              Monitor", 2022,

   [BGR_3]    BIIGROUP, "China Education IPv6 and DNSSEC Deployment
              Monitor", 2022,

   [BIPT]     Belgian Institute for Postal services and
              Telecommunications, "IPv6 in Belgium", 2017,

   [CAIDA]    APNIC, "Client-Side IPv6 Measurement", 2020,

   [CAIR]     Cisco, "Cisco Annual Internet Report (2018–2023) White
              Paper", 2020,

   [Cldflr]   Cloudflare, "Understanding and configuring Cloudflare's
              IPv6 support", <

   [cmpwr]    Compuware, "Impact on Enterprises of the IPv6-Only
              direction for the US Federal Government", 2020,

Fioccola, et al.           Expires 4 June 2023                 [Page 34]
Internet-Draft           IPv6 Deployment Status            December 2022

   [CN], "China to speed up IPv6-based Internet
              development", 2017, <

   [CN-IPv6]  National IPv6 Deployment and Monitoring Platform, "Active
              IPv6 Internet users", 2022,

   [CNLABS_1] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022,

   [CNLABS_2] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022,

              Computers & Security (Elsevier), "Methodology for the
              identification of potential security issues of different
              IPv6 transition technologies: Threat analysis of DNS64 and
              stateful NAT64", DOI 10.1016/j.cose.2018.04.012, 2018,

   [Csc6lab]  Cisco, "World - Display Content Data", 2022,

   [EE]       EE, "IPv6-only devices on EE mobile", 2017,

              ETSI, "ETSI GR IPE 001: IPv6 Enhanced Innovation (IPE) Gap
              Analysis", 2021, <

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

   [FB]       Saab, P., "Facebook IPv6 Experience", 2015,

   [GFA]      German Federal Government Commissioner for Information
              Technology, "IPv6-Masterplan für die Bundesverwaltung",
              2019, <

Fioccola, et al.           Expires 4 June 2023                 [Page 35]
Internet-Draft           IPv6 Deployment Status            December 2022

   [Ggl]      Google, "Introduction to GGC",

   [G_stats]  Google, "Google IPv6 Statistics", 2021,

   [HxBld]    HexaBuild, "IPv6 Adoption Report 2020", 2020,

              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, <

              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,

              Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
              "Operational Issues with Processing of the Hop-by-Hop
              Options Header", Work in Progress, Internet-Draft, draft-
              ietf-v6ops-hbh-02, 21 October 2022,

              Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N.
              Buraglio, "Selectively Applying Host Isolation to Simplify
              IPv6 First-hop Deployment", Work in Progress, Internet-
              Draft, draft-ietf-v6ops-nd-considerations-00, 24 October
              2022, <

              Martinez, J. P., "IPv6-only Terminology Definition", Work
              in Progress, Internet-Draft, draft-palet-v6ops-ipv6-only-
              05, 9 March 2020, <

Fioccola, et al.           Expires 4 June 2023                 [Page 36]
Internet-Draft           IPv6 Deployment Status            December 2022

   [IAB]      IAB, "IAB Statement on IPv6", 2016,

   [IDT]      Indian Department of Telecommunications, "Revision of IPv6
              Transition Timelines", 2021, <

   [IGP-GT]   Internet Governance Project, Georgia Tech, "The hidden
              standards war: economic factors affecting IPv6
              deployment", 2019, <

   [INFOCOM]  Doan, T.V., "A Longitudinal View of Netflix: Content
              Delivery over IPv6 and Content Cache Deployments", 2020,

              IPv6Forum, "Estimating IPv6 & DNSSEC External Service
              Deployment Status", 2022,

              ISIF Asia, "Internet Operations Research Grant: IPv6
              Deployment at Enterprises. IIESoc. India", 2020,

   [ISOC1]    Internet Society, "State of IPv6 Deployment 2018", 2018,

   [ISOC2]    Internet Society, "Facebook News Feeds Load 20-40% Faster
              Over IPv6", 2015,

   [ISOC3]    Internet Society, "IPv6 Security FAQ", 2019,

   [MAPRG]    Bajpai, V., "Measuring YouTube Content Delivery over
              IPv6", 2017, <

Fioccola, et al.           Expires 4 June 2023                 [Page 37]
Internet-Draft           IPv6 Deployment Status            December 2022

   [Mcrsft]   Microsoft, "IPv6 for Azure VMs available in most regions",

   [NRO]      NRO, "Internet Number Resource Status Report", 2021,

   [NST_1]    NIST, "Estimating Industry IPv6 and DNSSEC External
              Service Deployment Status", 2022, <https://fedv6-

   [NST_2]    NIST, "Estimating USG IPv6 and DNSSEC External Service
              Deployment Status", 2022, <https://fedv6-

   [NST_3]    NIST, "Estimating University IPv6 and DNSSEC External
              Service Deployment Status", 2022, <https://fedv6-

   [Ntflx]    Netflix, "Enabling Support for IPv6",

   [POTAROO1] POTAROO, "IP Addressing through 2021", 2022,

   [POTAROO2] POTAROO, "IPv6 Resource Allocations", 2022,

   [RelJio]   Reliance Jio, "IPv6-only adoption challenges and
              standardization requirements", 2020,

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,

Fioccola, et al.           Expires 4 June 2023                 [Page 38]
Internet-Draft           IPv6 Deployment Status            December 2022

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

   [RFC6980]  Gont, F., "Security Implications of IPv6 Fragmentation
              with IPv6 Neighbor Discovery", RFC 6980,
              DOI 10.17487/RFC6980, August 2013,

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,

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

   [RFC8683]  Palet Martinez, J., "Additional Deployment Guidelines for
              NAT64/464XLAT in Operator and Enterprise Networks",
              RFC 8683, DOI 10.17487/RFC8683, November 2019,

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,

Fioccola, et al.           Expires 4 June 2023                 [Page 39]
Internet-Draft           IPv6 Deployment Status            December 2022

   [RFC9098]  Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
              G., and W. Liu, "Operational Implications of IPv6 Packets
              with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
              September 2021, <>.

   [RIPE1]    Huston, G., "Measuring IPv6 Performance", 2016,

   [RIPE2]    RIPE, "IPv6 Security", 2019,

   [SNDVN]    SANDVINE, "Sandvine releases 2020 Mobile Internet
              Phenomena Report: YouTube is over 25% of all mobile
              traffic", 2020, <

   [TMus]     T-Mobile US, "Going IPv6-only", 2018,

   [US-CIO]   The CIO Council, "Memorandum for Heads of Executive
              Departments and Agencies. Completing the Transition to
              Internet Protocol Version 6 (IPv6)", 2020,

   [US-FR]    Federal Register, "Request for Comments on Updated
              Guidance for Completing the Transition to the Next
              Generation Internet Protocol, Internet Protocol Version 6
              (IPv6)", 2020, <

   [Vrzn]     Verizon, "Verizon Digital Media Services announces IPv6
              Compliance", <

   [W3Techs]  W3Techs, "Historical yearly trends in the usage statistics
              of site elements for websites", 2021,

Fioccola, et al.           Expires 4 June 2023                 [Page 40]
Internet-Draft           IPv6 Deployment Status            December 2022

   [WIPv6L]   World IPv6 Launch, "World IPv6 Launch - Measurements",
              2021, <>.

Appendix A.  Summary of Questionnaire and Replies for network operators

   A survey was proposed to more than 50 service providers in the
   European region during the third quarter of 2020 to ask for their
   plans on IPv6 and the status of IPv6 deployment.

   40 people, representing 38 organizations, provided a response.  This
   appendix summarizes the results obtained.

   Respondents' business
                               Convergent  Mobile  Fixed
       Type of operators       82%         8%      11%

   Question 1.  Do you have plan to move more fixed or mobile or
   enterprise users to IPv6 in the next 2 years?

   a.  If so, fixed, or mobile, or enterprise?

   b.  What are the reasons to do so?

   c.  When to start: already on going, in 12 months, after 12 months?

   d.  Which transition solution will you use, Dual-Stack, DS-Lite,
   464XLAT, MAP-T/E?

   Answer 1.A (38 respondents)

                           Yes     No
       Plans availability  79%     21%

                           Mobile  Fixed   Enterprise  Don't answer
       Business segment    63%     63%     50%         3%

   Answer 1.B (29 respondents)

   Even this was an open question, some common answers can be found.

   14 respondents (48%) highlighted issues related to IPv4 depletion.
   The reason to move to IPv6 is to avoid private and/or overlapping

   For 6 respondents (20%) 5G/IoT is a business incentive to introduce

Fioccola, et al.           Expires 4 June 2023                 [Page 41]
Internet-Draft           IPv6 Deployment Status            December 2022

   4 respondents (13%) also highlight that there is a National
   regulation request to enable IPv6 associated with the launch of 5G.

   4 respondents (13%) consider IPv6 as a part of their innovation
   strategy or an enabler for new services.

   4 respondents (13%) introduce IPv6 because of Enterprise customers

   Answer 1.C (30 respondents)

                   Ongoing   In 12 months  After 12 months  Don't answer
      Timeframe    60%       33%           0%               7%

   Answer 1.D (28 respondents for cellular, 27 for wireline)

      Transition in use   Dual-Stack  464XLAT  MAP-T  Don't answer
      Cellular            39%         21%      4%     36%

      Transition in use   Dual-Stack  DS-Lite  6RD/6VPE   Don't answer
      Wireline            59%         19%      4%         19%

   Question 2.  Do you need to change network devices for the above

   a.  If yes, what kind of devices: CPE, or BNG/mobile core, or NAT?

   b.  Will you start the transition of your metro or backbone or
   backhaul network to support IPv6?

   Answer 2.A (30 respondents)

                          Yes  No   Don't answer
      Need of changing    43%  33%  23%

                          CPEs    Routers  BNG  CGN   Mobile core
      What to change      47%     27%      20%  33%   27%

   Answer 2.B (22 respondents)

                            Yes  Future  No
      Plans for transition   9%   9%      82%

Fioccola, et al.           Expires 4 June 2023                 [Page 42]
Internet-Draft           IPv6 Deployment Status            December 2022

Appendix B.  Summary of Questionnaire and Replies for enterprises

   The Industry Network Technology Council (INTC) developed the
   following poll to verify the need or willingness of medium-to-large
   US-based enterprises for training and consultancy on IPv6
   ( in early 2021.

   54 organizations provided an answer.

   Question 1.  How much IPv6 implementation have you done at your
   organization?  (54 respondents)

      None                                            16.67%
      Some people have gotten some training           16.67%
      Many people have gotten some training            1.85%
      Website is IPv6 enabled                          7.41%
      Most equipment is dual-stacked                  31.48%
      Have an IPv6 transition plan for entire network  5.56%
      Running IPv6-only in many places                20.37%
      Entire network is IPv6-only                      0.00%

   Question 2.  What kind of help or classes would you like to see INTC
   do? ( 54 respondents)

      Classes/labs on IPv6 security                   66.67%
      Classes/labs on IPv6 fundamentals               55.56%
      Classes/labs on address planning/network conf.  57.41%
      Classes/labs on IPv6 troubleshooting            66.67%
      Classes/labs on application conversion          35.19%
      Other                                           14.81%

   Question 3.  As you begin to think about the implementation of IPv6
   at your organization, what areas do you feel are of concern?  (54

      Security                    31.48%
      Application conversion      25.93%
      Training                    27.78%
      All the above               33.33%
      Don't know enough to answer 14.81%
      Other                        9.26%

Authors' Addresses

Fioccola, et al.           Expires 4 June 2023                 [Page 43]
Internet-Draft           IPv6 Deployment Status            December 2022

   Giuseppe Fioccola
   Huawei Technologies
   Riesstrasse, 25
   80992 Munich

   Paolo Volpato
   Huawei Technologies
   Via Lorenteggio, 240
   20147 Milan

   Jordi Palet Martinez
   The IPv6 Company
   Molino de la Navata, 75
   28420 La Navata - Galapagar, Madrid

   Gyan S. Mishra
   Verizon Inc.

   Chongfeng Xie
   China Telecom

Fioccola, et al.           Expires 4 June 2023                 [Page 44]