RFC 9386

IPv6 Deployment Status

📅 published April 2023, from ietf

RFC 9386: IPv6 Deployment Status 💖✨

Okay bestie, let's get into it! 🦋 This is the IPv6 deployment status doc from April 2023, and it's giving a big-picture check-in on how the IPv6 glow-up is going. It's Informational, not a Standards Track spec, so think of it as the tea rather than the rulebook. 🫶

Here's the title block tea ☕:

Who wrote it: G. Fioccola, P. Volpato, J. Palet Martinez, G. Mishra, and C. Xie. Fioccola, Volpato, and Mishra's crews are at Huawei Technologies, Verizon Inc., and China Telecom respectively, and J. Palet Martinez is at The IPv6 Company. 💅

What it obsoletes: RFC 6036. This one replaces it, so 6036 is officially retired. 👑

What it updates: Nothing listed in the header, so this doc isn't updating any other RFC. 🌸

When: April 2023, ISSN 2070-1721. 🎀

The whole vibe is an overview of IPv6 adoption in 2022, looking at how many people and sites are actually on it, what's still blocking the way, and where the industry hasn't landed on one clear approach yet. Super iconic. ✨

Status of This Memo 📜

Real talk: this is not an Internet Standards Track spec. It's published for informational purposes only. 🧚

It is still an IETF product with IETF consensus, reviewed publicly and approved by the IESG. Not everything the IESG approves is up for Internet Standard status, though, so check Section 2 of RFC 7841 if you're curious. 🤓

For the current status, errata, or to send feedback, head to https://www.rfc-editor.org/info/rfc9386. 💜

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect when it was published. Please actually read those, bestie, because they spell out your rights. 📖

If you pull Code Components out of this doc, they must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License. 💀

Table of Contents 🗺️

1.  Introduction
  1.1.  Terminology
2.  IPv6: The Global Picture
  2.1.  IPv4 Address Exhaustion
    2.1.1.  IPv4 Addresses per Capita and IPv6 Status
  2.2.  IPv6 Users
  2.3.  IPv6 Web Content
  2.4.  IPv6 Public Actions and Policies
3.  A Survey on IPv6 Deployments
  3.1.  IPv6 Allocations
  3.2.  IPv6 among Internet Service Providers
  3.3.  IPv6 among Enterprises
    3.3.1.  Government and Universities
4.  IPv6 Deployment Scenarios
  4.1.  Dual-Stack
  4.2.  IPv6-Only Overlay
  4.3.  IPv6-Only Underlay
  4.4.  IPv4-as-a-Service
  4.5.  IPv6-Only
5.  Common IPv6 Challenges
  5.1.  Transition Choices
    5.1.1.  Service Providers: Fixed and Mobile Operators
    5.1.2.  Enterprises
    5.1.3.  Industrial Internet
    5.1.4.  Content and Cloud Service Providers
    5.1.5.  CPEs and User Devices
    5.1.6.  Software Applications
  5.2.  Network Management and Operations
  5.3.  Performance
    5.3.1.  IPv6 Packet Loss and Latency
    5.3.2.  Customer Experience
  5.4.  IPv6 Security and Privacy
    5.4.1.  Protocols' Security Issues
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Summary of Questionnaire and Replies for Network
        Operators
Appendix B.  Summary of Questionnaire and Replies for Enterprises
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🌷

[RFC6036] is the OG doc that described the IPv6 deployment scenarios a bunch of ISPs were adopting or planning. Those ISPs answered a technical questionnaire in early 2010, and [RFC6036] also covered the practices and plans they expected in the years after. 📅

A lot has happened since [RFC6036] came out, and several other docs have joined the chat:

  • [RFC6180] talks about IPv6 deployment models and transition mechanisms, and recommends the ones that have proven themselves in real operational networks. 🔧
  • [RFC6883] gives guidance and suggestions for Internet content providers and Application Service Providers (ASPs). 🌐
  • [RFC7381] lays out IPv6 deployment guidelines for enterprises. 🏢

[RFC6540] recommends that all IP-capable nodes support IPv6. It got cited in the IAB statement on IPv6 [IAB], which was a huge moment for pushing the IETF and other Standards Development Organizations (SDOs) to use IPv6 in their work. 🚀

More recently, organizations like ETSI have been putting in work on IPv6 in operational environments, aimed at different industry segments. That led to [ETSI-IP6-WhitePaper], which gives an updated look at the IPv6 best practices people have adopted so far, especially in the ISP domain. 📚

So, after more than ten years since [RFC6036] dropped, it's time to check in on how the IPv6 transition is going. A few reasons why it's so timely: 👀

  • In some areas, running out of IPv4 addresses pushed carriers and content providers to move to IPv6 so they could support new applications, especially in wireless networks. 📱
  • Some governments took action to encourage, or even enforce, IPv6 adoption in certain countries. 🏛️
  • Looking at global adoption, it seems to have crossed a threshold that justifies talking about end-to-end IPv6 connectivity, at least at the IPv6 service layer. 🌍

This doc surveys where IPv6 deployment stands and highlights both the wins and the remaining obstacles in moving to IPv6 networks (and coexisting with the IPv4 services that are still around). The goal is an updated view of the practices and plans already described in [RFC6036], to encourage more action and more investigation in the areas still under discussion, and to lay out the main incentives for adopting IPv6. 💅

This is for a general audience trying to understand IPv6 status across different industries and network domains. People who provide or use network services may find it useful for their transition, and people planning IPv6 adoption in an organization or industry can find info and references here for their analysis. 🎯

The doc pays attention to the different stages of the transition to IPv6 networks and services. It also defines the terminology around "IPv6-only," treating IPv6-only networks and services as the final stage of that transition. ✨

The topics are organized into four main chapters: 🗂️

  • Section 2 reports data and analytics about where IPv6 stands. 📊
  • Section 3 surveys IPv6 deployments in different environments, including ISPs, enterprises, and universities. 🎓
  • Section 4 describes IPv6 deployment approaches for Mobile Broadband (MBB), Fixed Broadband (FBB), and enterprises. 📡
  • Section 5 analyzes the general challenges to solve in the IPv6 transition, with special attention to operations, performance, and security issues. 🛠️

1.1. Terminology 🧠

This section defines the IPv6-only terms used in this doc. The term IPv6-only is defined relative to the specific scope it refers to. That means only part of a service, a network, or even a node might be in an IPv6-only scope while the rest isn't. The most-used terms for the different scopes are below: 🔍

IPv6-only interface: : The interface of a node is configured to forward only IPv6. Only part of the node can be IPv6-only, since the node's other interfaces may still work with IPv4. A Dual-Stack interface is not an IPv6-only interface. 🙅

IPv6-only node: : The node uses only IPv6, and all of the host's interfaces only have IPv6 addresses. 💖

IPv6-only service: : This applies if, between the host's interface and the content server's interface, all packet headers of the service session are IPv6. 🎀

IPv6-only overlay: : This applies if, between the tunnel endpoints, all inner packet headers of the tunnels are IPv6. For example, an IPv6-only overlay in a fixed network means 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: : This applies if the data plane and control plane are IPv6, though that isn't necessarily true for the management plane. For example, an IPv6-only underlay in a fixed network means the underlay network protocol is only IPv6 between any PE nodes, while they can still be Dual-Stack in the overlay. Segment Routing over IPv6 (SRv6) is an example of an IPv6-only underlay. 🌊

IPv6-only network: : This applies if every node in the network is IPv6-only. IPv4 should not exist in an IPv6-only network. In particular, an IPv6-only network's data plane, control plane, and management plane MUST be IPv6. All PEs MUST be IPv6-only, so if tunnels exist among PEs, both inner and outer headers MUST be IPv6. For example, an IPv6-only access network means every node in that access network MUST be IPv6-only, and likewise, an IPv6-only backbone network means every node in that backbone network MUST be IPv6-only. 🚨

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

Note that IPv6-only definitions are also discussed in [IPv6-ONLY-DEF]. 📝

2. IPv6: The Global Picture 🌍

This section covers the key questions about IPv6: (1) the status of IPv4 exhaustion, often seen as one of the triggers for switching to IPv6, (2) the number of IPv6 end users, which is a primary measure of 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, because they give a first-order indication of IPv6 adoption. 📈

Part 1 of 10 is done, so keep an eye out for part 2! 🫶💜

2.1. IPv4 Address Exhaustion ✨

okay so bestie, let's talk about the big IPv4 crunch 💅 According to [CAIR], there will be 29.3 billion networked devices by 2023, up from 18.4 billion in 2018. 🤯 That raises the question of whether the IPv4 address space can keep up with that many allocations and, if it can't, how that changes the whole exhaustion situation. The answer is not straightforward, because there are a lot of moving parts 🧩

On one hand, the RIRs are reporting that available and still-reserved addresses are running low 📉 Table 3 of [POTAROO1] (January 2022) shows that at the end of 2021 the available pool of the five RIRs held 5.2 million IPv4 addresses, while the reserved pool had another 12.1 million, for a total of 17.3 million IPv4 addresses (-5.5% year over year, comparing 2021 against 2020). Table 1 of [POTAROO1] shows that the total IPv4 allocated pool equaled 3.685 billion addresses (+0.027% year over year). The ratio between available addresses and total allocated dropped to 0.469% of the remaining IPv4 address space (from 0.474% at the end of 2020). Yikes, the leftovers are shrinking, periodt 😭

On the other hand, [POTAROO1] again highlights the role of both address transfer and Network Address Translation (NAT) as ways to counter IPv4 exhaustion 🔄 IPv4 transfers can happen under the control or registration of an RIR, or on the so-called grey market, where third parties operate to help people buy and sell IPv4 addresses 🛒 In every case, a set of IPv4 addresses is "transferred" to a different holder who needs 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 buyers of IPv4 addresses, since they need to give their tenants IPv4 connectivity ☁️

NAT systems help absorb at least some of the demand for public IPv4 addresses, because they let internal networks use private addressing while limiting how many public addresses are used on their WAN-facing side 🏠 But NAT comes with its own architectural and operational issues 😬 Private address space can't provide an adequate address span, especially for large organizations, and reusing addresses can make the network more complex. Plus, multiple levels of address translation may coexist in a network, for example Carrier-Grade NAT (CGN) [RFC6264], which is 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 how many IPv4 addresses are allocated to a given country, divided by that country's population 🧮 It shows how unevenly IPv4 addresses are spread around the world, and it clearly comes from the allocations made in the early days of the Internet 🦕

The sources for measuring the IPv4 addresses per capita ratio are the allocations done by the RIRs and the statistics about world population. [POTAROO2] provides distribution files for this. The table below compares the number of IPv4 addresses available per person in a country (IPv4 address per capita) against the relative adoption of IPv6 in that same country (expressed as the number of IPv6-capable users in that country). It's just a subset of the data from [POTAROO2], covering the 25 most populated countries in the world, ordered by IPv4 addresses per capita, with data as of 1 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% |
+------------------------------+-----------------+-----------------+
| Germany                      |            1.48 |           53.0% |
+------------------------------+-----------------+-----------------+
| France                       |            1.27 |           42.1% |
+------------------------------+-----------------+-----------------+
| Italy                        |            0.91 |            4.7% |
+------------------------------+-----------------+-----------------+
| South Africa                 |            0.46 |            2.4% |
+------------------------------+-----------------+-----------------+
| Brazil                       |            0.41 |           38.7% |
+------------------------------+-----------------+-----------------+
| Russian Federation           |            0.31 |            9.7% |
+------------------------------+-----------------+-----------------+
| China                        |            0.24 |        60.1%(*) |
+------------------------------+-----------------+-----------------+
| Egypt                        |            0.24 |            4.3% |
+------------------------------+-----------------+-----------------+
| Mexico                       |            0.23 |           41.8% |
+------------------------------+-----------------+-----------------+
| Turkey                       |            0.20 |            0.2% |
+------------------------------+-----------------+-----------------+
| Vietnam                      |            0.17 |           48.0% |
+------------------------------+-----------------+-----------------+
| Iran (Islamic Republic)      |            0.15 |            0.1% |
+------------------------------+-----------------+-----------------+
| Thailand                     |            0.13 |           40.8% |
+------------------------------+-----------------+-----------------+
| Indonesia                    |            0.07 |            5.0% |
+------------------------------+-----------------+-----------------+
| Philippines                  |            0.05 |           13.8% |
+------------------------------+-----------------+-----------------+
| India                        |            0.03 |           76.9% |
+------------------------------+-----------------+-----------------+
| Pakistan                     |            0.03 |            2.1% |
+------------------------------+-----------------+-----------------+
| United Republic of Tanzania  |            0.02 |            0.0% |
+------------------------------+-----------------+-----------------+
| Nigeria                      |            0.02 |            0.2% |
+------------------------------+-----------------+-----------------+
| Bangladesh                   |            0.01 |            0.3% |
+------------------------------+-----------------+-----------------+
| Ethiopia                     |            0.00 |            0.0% |
+------------------------------+-----------------+-----------------+
| Democratic Republic of Congo |            0.00 |            0.1% |
+------------------------------+-----------------+-----------------+

  Table 1: IPv4 per Capita and IPv6 Deployment for the Top 25 Most
       Populated Countries in the World (as of January 2022)

(*) The IPv6 deployment information in China is derived from [CN-IPv6].

A direct correlation between low IPv4 per capita and high IPv6 adoption isn't immediate, but some signals do pop up 👀 For example, countries like Brazil, China, and India have clearly moved towards IPv6 adoption. As discussed later, this seems tied to several factors beyond the lack of IPv4 addresses, including local regulation and market-driven actions 📜 The 5 countries at the top of the table, which have relatively high IPv4 availability, have also shown a good level of IPv6 adoption. In other cases, scarce IPv4 addresses haven't meant a clear move towards IPv6, since several countries in the table still have low or very low IPv6 adoption 🤷‍♀️

2.2. IPv6 Users 🎀

The count of IPv6 users is the key parameter for understanding how much IPv6 is being adopted, bestie 📊 Some organizations constantly track IPv6 usage by aggregating data from several sources. For example, the Internet Society constantly monitors the volume of IPv6 traffic for networks that joined the World IPv6 Launch initiative [WIPv6L]. That measurement aggregates statistics from organizations such as [Akm-stats], which provide data down to the single network level by measuring the number of hits to their content delivery platform. For the scope of this document, the approach APNIC uses to quantify IPv6 adoption is considered: a script that runs on a user's device [CAIDA] 🖥️ To give a rough estimate of IPv6's relative growth, the table below totals the estimated IPv6-capable users as of 1 January 2022 and compares that against total Internet users, as measured by [POTAROO2].

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

  Table 2: IPv6-Capable Users against Total Users (in Millions) as
                         of January 2022

Two figures stand out. First, the IPv6 Internet population is growing with a two-digit Compound Annual Growth Rate (CAGR), and second, the ratio of IPv6 over total keeps climbing steadily 📈✨

2.3. IPv6 Web Content ✨

[W3Techs] keeps an eye on how several technical bits of websites are used around the world, using a few different analytics engines 👀. The table below shows how much IPv6 shows up for websites, where the percentages are for sites that can be reached 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% |
+-----------+-------+-------+-------+-------+-------+-------+

Table 3: Usage of IPv6 in Websites (as of January 2022)

Okay, so looking at the growth rate, it might not seem super high 🙃. BUT not all websites are equal, bestie 💅. The biggest content providers already support IPv6, and they make way more content than small websites do. At the start of January 2022, [Csc6lab] measured that out of the world's top 500 sites, 203 are IPv6 enabled (+3.6% from January 2021 to January 2022). Now here's the tea: the big content providers (like Google, Facebook, and Netflix) make more than 50% of the total mobile traffic [SNDVN], and in some cases even up to 65% [ISOC1] [HxBld] 😱. So the percentage of content you can reach over IPv6 is way more important than the number of IPv6 enabled websites, periodt 🔥. It would be iconic to know what share of that 50% of all mobile traffic is IPv6, but unfortunately that info isn't available 😭.

Related to that, people sometimes ask whether all the content stored by content providers would still be reachable over IPv6 if IPv4 got switched off overnight. Even if that's pure speculation 🙈, the numbers above kinda suggest that this is likely the case. That would back up the common thought that, in quantitative terms, most of the content is accessible via IPv6 💜.

2.4. IPv6 Public Actions and Policies 🏛️

As we already mentioned, IPv6 isn't being deployed evenly across the world [G_stats] [APNIC1] 🌍. It's worth noticing that in some places, higher IPv6 adoption happened because local governments took action, either through regulation or by giving incentives to the market 🎀. In the European Union, countries like Belgium, France, and Germany are way ahead on IPv6 adoption 🇪🇺.

In Belgium, the Belgian Institute for Postal services and Telecommunications (BIPT) stepped in to mediate an agreement between the local ISPs and the government in 2012 [BIPT]. The goal was to limit the use of Carrier-Grade NAT (CGN) systems and of public IPv4 addresses for lawful investigations. The agreement limited the use of one IPv4 address per 16 customers behind NAT. The economic burden the ISPs had from the unoptimized use of NAT pushed them to shift to IPv6, and that's why adoption has grown in the latest years 📈.

In France, the National Regulator (Autorite de regulation des communications electroniques, or Arcep) introduced an obligation for mobile carriers that were awarded a license to use 5G frequencies (3.4-3.8 GHz) in Metropolitan France to be IPv6 compatible [ARCEP] 📶. As stated in [ARCEP] (translated from French):

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 stop new Internet services from spreading widely, or create a barrier to entry for newcomers to the market 🚧. Per [ARCEP] (translated from French), "IPv6 can help to increase competition in the telecom industry, and help to industrialize a country for specific vertical sectors" 💖.

In Germany, increased IPv6 adoption came from a mix of industry and public actions 🇩🇪. Specifically, the Federal Office for Information Technology (under the Federal Ministry of the Interior) has issued a few recommendations over the years about using IPv6 in the German public administration. The latest guideline, from 2019, is 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 lay out a plan to have 80% of the US federal IP-capable networks be IPv6-only by the year 2025 ⭐. China is another example of a government supporting a country-wide IPv6 adoption [CN] 🧧. In India, the high adoption of IPv6 started with the decision from Reliance Jio to move to IPv6 in their networks [RelJio] 🚀. On top of that, the Department of Telecommunications (under the Ministry of Communications and Information Technology) issued guidelines for the progressive adoption of IPv6 in public and private networks. The latest one is from 2021 [IDT] and it keeps pushing further moves to IPv6 connection services 🦋.

3. A Survey on IPv6 Deployments 📊

This section talks about the status of IPv6 adoption in service provider and enterprise networks 🧚.

3.1. IPv6 Allocations

RIRs are responsible for allocating IPv6 address blocks to ISPs, Local Internet Registries (LIRs), and enterprises or other organizations 🏢. An ISP/LIR then uses the allocated block to assign addresses to their end users. The table below shows the number of individual allocations per RIR in the time period from 2017-2021 [APNIC2] 🍓.

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

Table 4: IPv6 Allocations Worldwide (as of January 2022)

The trend shows the steady progress of IPv6 📈✨. The dip in IPv6 allocations in 2020 and 2021 may be due to the COVID-19 pandemic 😷. IPv4 allocations had that dip too.

[APNIC2] also compares the number of allocations for both address families 👯. The CAGR looks pretty similar in 2021, but it's a little higher for IPv4 allocations compared to IPv6 allocations (53.6% versus 50.9%).

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

Table 5: Allocations per Address Family (as of January 2022)

The reason might be that the IPv4 allocations in 2021 included lots of allocations of small address ranges (e.g., /24) [APNIC2] 🧐. On the flip side, a single IPv6 allocation is big enough to cover an operator's needs for a long period 💅. After an operator gets an IPv6 /30 or /32 allocation, it's unlikely they'll need a new request for addresses in the short term 🫶.

The next table is based on [APNIC3] and [APNIC4] and shows the percentage of Autonomous Systems (ASes) supporting IPv6 compared to the total ASes worldwide 🌐. The number of IPv6-capable ASes went from 24.3% in January 2018 to 38.7% in January 2022. That equals an 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%  |      |
+--------------+--------+--------+--------+--------+--------+------+

Table 6: Percentage of IPv6-Capable ASes (as of January 2022)

The tables above give you an aggregated view of how the allocations are moving 🎞️. The next subsections zoom into each specific domain so we can check out its relative status 🔍.

3.2. IPv6 among Internet Service Providers 📡

A survey went out to a group of service providers in Europe during the third quarter of 2020 (see Appendix A for the complete poll) 📝. It was meant to figure out their plans about IPv6 and their technical preferences for adopting it. Even though this poll doesn't give an exhaustive view of the IPv6 status, it gives some insights that are relevant to the discussion 💭.

The poll revealed that the majority of ISPs interviewed had plans concerning IPv6 (79%) 🎉. Of those, 60% already had ongoing activities, while 33% were expected to start activities in a 12-month timeframe ⏰. The transition to IPv6 involved all business segments: mobile (63%), fixed (63%), and enterprise (50%) 💜.

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 their reasons (13%). Enterprise customer 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 🏢✨

okay so, as [RFC7381] explains, enterprises face a totally different set of struggles than ISPs 🫶. Public reports show that enterprise IPv6 deployment is lagging behind ISP deployment [cmpwr] 😭.

[NST_1] gives estimates of IPv6 deployment status for domains like example.com, example.net, or example.org in the United States 💅. The measurement covers a bunch of industries, including telecommunications, so "enterprises" is kinda loose here 🙈. Still, it's a first peek at IPv6 adoption across several US industry sectors. The analysis tries to figure out whether IPv6 is supported by looking from "outside" a company's network 👀. It checks IPv6 support for external services like Domain Name System (DNS), mail, and websites. [BGR_1] has similar data for China, and [CNLABS_1] shows the status in India 🌏.

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

        Table 7: IPv6 Support for External-Facing Services across
                     Enterprises (as of January 2022)

A poll sent 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 they are for ISPs 🔥.

Looking at current implementations, almost one third have dual-stacked networks 🦋, while 20% say that portions of their networks are IPv6-only ✨. Another 35% of the enterprises either didn't implement IPv6 at all or are stuck in the training phase 💀. In no case is the network fully based on IPv6 😤.

Speaking of training, the most critical needs are IPv6 security and IPv6 troubleshooting, which both got highlighted by two thirds of respondents 🙌. Right behind those is address planning / network configurations (57.41%) 🗂️.

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

The full poll is reported in Appendix B 🎀.

3.3.1. Government and Universities 🏛️🎓

This section zooms in on the adoption of IPv6 in governments and academia 🧚.

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 tied to US federal agencies 🇺🇸. These domains look like example.gov or example.fed. The script used by [NST_2] has also been used to measure the same analytics in other countries, e.g., China [BGR_2], India [CNLABS_2], and the European Union [IPv6Forum]. For that last one, some post-processing is necessary to filter out the non-European domains 🧹.

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

         Table 8: IPv6 Support for External-Facing Services across
               Governmental Institutions (as of January 2022)

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

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

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

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

         Table 9: IPv6 Support for External-Facing Services across
                     Universities (as of January 2022)

Overall, universities have wider support for IPv6-based services than 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 in the table above show good support of IPv6 in academia 🌸.

4. IPv6 Deployment Scenarios 🌈

The scope of this section is to talk about the network and service scenarios that matter for the transition to IPv6 🦋. Most of the related definitions are back in Section 1.1, so go check there if you need them. This part zooms in on the technical and operational characteristics 🔧. The sequence of scenarios described here doesn't have to be a road map for the IPv6 transition 🗺️. Depending on their specific plans and requirements, service providers may adopt the scenarios in a sequence or jump straight to one specific scenario 🚀.

4.1. Dual-Stack 🧃

Based on the poll answers from network operators (Appendix A), Dual-Stack [RFC4213] seems to be the most widely deployed IPv6 solution right now (about 50%; see both Appendix A and the statistics in [ETSI-IP6-WhitePaper]) 👑.

With Dual-Stack, IPv6 can be introduced together with other network upgrades, and lots of network management and IT systems can keep working in IPv4 💅. That avoids a major upgrade of those systems to support IPv6, which is possibly the hardest part of the IPv6 transition 😤. The cost and effort of upgrading network management and IT systems are moderate. The benefits are that you get to start using IPv6 and save on NAT costs 💸.

Dual-Stack can be great in the introductory stage, but it has a few downsides in the long run, like duplicating network resources and state 🙃. It also needs more IPv4 addresses, which pushes up both Capital Expenses (CAPEX) and Operating Expenses (OPEX) 📉. For example, even if private addresses are used with Carrier-Grade NAT (CGN), there's extra spending on the CGN devices, log storage, and a help desk to track CGN-related issues 🎧.

So when IPv6 usage goes past a certain threshold, it may be worth starting a transition to the next scenario 🦋. For example, the process may start with the IPv4aaS stage, described hereinafter ✨. It's hard to set the criterion for switching (e.g., properly identifying the upper bound of the IPv4 decrease or the lower bound of the IPv6 increase) 🤔. Besides the technical factors, switching to the next scenarios may also cause a loss of customers 😭. Based on feedback from network operators taking part in the World IPv6 Launch [WIPv6L] in June 2021, 108 out of 346 operators exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%), and 37 exceed 75% (10.7%) 📊. The consensus to move to IPv6-only might be reasonable when IPv6 traffic volume is between 50% and 60% 🎯.

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 means the overlay tunnel between a network's end points is based only on IPv6 🌊. Tunneling gives you 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 wrapping them inside IPv4 packets 🎁. The IPv6-only overlay approach helps keep compatibility with the existing IPv4 base, but it is not a long-term solution 🙈.

Here's the real tea: IPv4 reachability must be provided for a long time to come over IPv6 for IPv6-only hosts 🫖. Most ISPs are leveraging CGN to extend the life of IPv4 instead of going with IPv6-only solutions 💅.

4.3. IPv6-Only Underlay 🏗️

The IPv6-only underlay network uses IPv6 as the network protocol for all traffic delivery 💖. Both the control and data planes are based on IPv6. The definition of IPv6-only underlay needs to be tied to a scope so you can tell which domain it applies to, such as an IPv6-only access network or IPv6-only backbone network 🗺️.

When both enterprises and service providers start moving from an IPv4/MPLS backbone to bring IPv6 into the underlay, they don't necessarily need to Dual-Stack the underlay 🙌. Forwarding plane complexity on the Provider (P) nodes of the ISP core should be kept simple, like a backbone with a single protocol 🧠. So when operators decide to transition to an IPv6 underlay, the ISP backbone should be IPv6-only, because Dual-Stack is not the best choice 🙅‍♀️. The underlay could be IPv6-only and still allow IPv4 packets to be tunneled using a VPN over an IPv6-only backbone, while leveraging [RFC8950], which specifies the extensions needed to advertise IPv4 Network Layer Reachability Information (NLRI) with an IPv6 next hop 🦋.

IPv6-only underlay deployment for access and backbone networks doesn't seem to be the first option 😅. The current trend is to keep the IPv4/MPLS data plane and run IPv4/IPv6 Dual-Stack on edge nodes 🌸.

As ISPs move to an IPv6-only access network or backbone network in the future, e.g., with the Segment Routing over IPv6 (SRv6) data plane, they start eliminating IPv4 from the underlay transport network while continuing to provide IPv4 services 🚀. Basically, as the poll among network operators also showed, from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network, for the forwarding plane complexity reasons mentioned above 🫶✨.

4.4. IPv4-as-a-Service ✨

okay bestie, IPv4aaS is how you keep IPv4 support working for people 💅 and deciding whether to do it is lowkey complicated 😭 because it depends on a bunch of stuff like economics, 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], Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], and Mapping of Address and Port using Translation (MAP-T) [RFC7599]. It does not give an explicit recommendation though 🙈 However, the poll in Appendix A shows that the most widely deployed IPv6 transition solution in the Mobile Broadband (MBB) domain is 464XLAT, while in the Fixed Broadband (FBB) domain, it is DS-Lite 📱🏠

Both are IPv4aaS solutions that leverage IPv6-only underlay 🦋 IPv4aaS offers Dual-Stack service to users and lets an ISP 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 are more efficient and do not restrict the number of ports per subscriber 💖 This helps to reduce troubleshooting costs and to remove some operational issues related to permanent block listing of IPv4 address blocks when used via CGN in some services. no cap, that's a big win 🎀

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

For deployments with a large number of users (e.g., large mobile operators) or a large number of hosts (e.g., large Data Centers (DCs)), even the full private address space [RFC1918] is not enough 😭 Also, Dual-Stack will likely lead to duplication of network resources and operations to support both IPv6 and IPv4, which increases the amount of state information in the network. This suggests that, for scenarios such as MBB or large DCs, IPv4aaS could be more efficient from the start of the IPv6 introduction 🚀

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

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 else. literally the full glow-up ✨

Since IPv6-only means that both underlay networks and overlay services are only IPv6, it will take longer to happen 🐢 but it's worth the wait 💜

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 that IPv6 has already been well proven in production, there are some challenges to consider 🤔 In this regard, it is worth noting that [ETSI-GR-IPE-001] also discusses gaps that still exist in IPv6-related use cases 📚

5.1. Transition Choices

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

The subsections below briefly highlight the approaches that the different parties may take and the related challenges 💅

5.1.1. Service Providers: Fixed and Mobile Operators

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 applying a new strategy when reaching the limit in terms of the number of IPv4 addresses available. This may be done through CGN or with an IPv4aaS approach. 🎯
  • 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. 🥹

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 a first and immediate mitigation solution. 🩹
  • Other mobile operators prefer to move to IPv4aaS solutions (e.g., 464XLAT) since Dual-Stack only mitigates and does not solve the IPv4 address scarcity issue completely. 🦋

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

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 infrastructures, IPv6 shows its advantages in the case of a merger and acquisition, because it can be avoided by the overlapping of the two address spaces, which is common in case of IPv4 private addresses. In addition, since several governments are introducing IPv6 policies, all the enterprises providing consulting services to governments are also required to support IPv6 🏛️✨

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

Enterprises worldwide, in particular small- and medium-sized enterprises, are quite late to adopt IPv6, especially on internal networks 🐌 In most cases, the enterprise engineers and technicians do not have a great experience with IPv6, and the problem of application porting to IPv6 looks quite difficult. As highlighted in the relevant poll, the technicians may need to be trained, but the management does not see a business need for adoption. This creates an unfortunate cycle where the perceived complexity of the IPv6 protocol and concerns about security and manageability combine with the lack of urgent business needs to prevent adoption of IPv6 💀 In 2019 and 2020, there has been a concerted effort by some ARIN and APNIC initiatives to provide training [ARIN-CG] [ISIF-ASIA-G] 🎓

5.1.3. Industrial Internet

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

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

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 configurationless characteristic of IPv6 to automatically manage and control the IoT devices 🪄 In addition, it could be interesting to have the ability to use IP-based communication and standard application protocols at every point in the production process and further reduce the use of specialized communication systems 🌈

5.1.4. Content and Cloud Service Providers ✨

The high number of addresses needed to connect the virtual and physical stuff in a Data Center, plus having to get past the limits that [RFC1918] sets, are the big reasons several CSP networks have adopted IPv6. 💜

Most CSPs have adopted IPv6 in their internal infrastructure, but they're also super active in gathering IPv4 addresses on the transfer market to keep up with their current business needs for IPv4 connectivity. 🛒 As noted in the previous section, most enterprises don't treat the move to IPv6 as a priority, so, bestie, CSPs are going to keep using IPv4-based network services for a while. 😭

Several public references, which I'll share below, talk about how most of the major players are at different stages of moving to IPv6-only in their Data Center (DC) infrastructure. ✨ In some cases the transition has already happened, and the DC infrastructure of these hyperscalers is completely based on IPv6. 🤯

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

The challenges for CSPs are mainly about continuing to guarantee IPv4 support, since most CSPs have already completed the transition to IPv6-only. 😬 If the scarcity of IPv4 addresses becomes more evident in the next few years, it's likely that the cost of a CSP buying an IPv4 address could end up being charged to their customers. 💸

5.1.5. CPEs and User Devices 📱

It's worth noting that most user devices (e.g., smartphones) have been IPv6 enabled for many years. But there are exceptions! For the past few years, smart TVs have typically had IPv6 support, however not every economy replaces them at the same pace. 📺

As already mentioned, ISPs that historically gave public IPv4 addresses to their customers generally still have those addresses (unless they chose to transfer them). Some have chosen to put new customers on CGN without touching existing customers. 🙈 Because of the extremely small number of customers who notice that IPv4 is done via NAT444 (i.e., the preferred CGN solution for carriers), it could be less likely to run out of IPv4 addresses and private IPv4 space. But as IPv4-only devices and traffic go down, the need to support private and public IPv4 lessens. So having CPEs fully support IPv6 is an important challenge and an incentive to choose IPv4aaS solutions [ANSI] over Dual-Stack. 🎀

5.1.6. Software Applications 💻

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

It's also worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect of application transition to IPv6. 🦋

5.2. Network Management and Operations 🛠️

Okay so there are some important IPv6 complementary solutions for Operations, Administration, and Maintenance (OAM) that look less mature compared to IPv4. A Network Management System (NMS) has a central role in modern networks for both network operators and enterprises, so its transition is a fundamental issue. Some IPv6 products aren't as field proven as IPv4 products, even if conventional protocols (e.g., SNMP and RADIUS) already support IPv6. On top of that, an incompatible vendor road map for developing new NMS features shakes the confidence of network operators and enterprises. 😬

An important factor is the need to train the network operations workforce. Deploying IPv6 means policies and procedures have to be adjusted to successfully plan and complete an IPv6 transition. Staff have to be aware of best practices for managing IPv4 and IPv6 assets. Beyond 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. 💰

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

5.3. Performance 📊

People love to compare IPv6 and IPv4 performance to argue for or against the IPv6 transition. In some cases, IPv6 behaving "worse" than IPv4 may be used as an argument for avoiding 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 provide up-to-date information. While performance is undoubtedly an important issue worth further investigation, the reality is that a definitive answer cannot be found on which 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 employ the three-way handshake of TCP. As such, the measurement of the failure rate does not provide a direct measurement of packet loss (which would need an Internet-wide measurement campaign). That said, even though 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 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 in at the country or even operator level, you can get more detailed info and see that there are cases where IPv6 is faster than IPv4. Regions (e.g., Western Europe, Northern America, and Southern Asia) and countries (e.g., US, India, and Germany) with an advanced deployment of IPv6 (e.g., greater than 45%) are showing that IPv6 has better performance than IPv4. [APRICOT] highlights how, when a difference in performance exists, it is often related to asymmetric routing issues. Other possible explanations for a relative latency difference relate to the specificity of the IPv6 header, which allows packet fragmentation. In turn, this means hardware needs to spend cycles analyzing all of the header sections, and when it isn't capable of handling one of them, it drops the packet. A few measurement campaigns on the behavior of IPv6 in CDNs are also available [MAPRG] [INFOCOM]. The TCP connection time is still higher for IPv6 in both cases, even though the gap has reduced over the analysis time window. ⏱️

5.3.2. Customer Experience 🙌

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

5.4. IPv6 Security and Privacy ✨

okay so security and privacy are literally the thing people bring up when they talk about moving to IPv6, and it deserves a whole convo 🫶 [RFC9099] looks at operational security issues in several places in a network (enterprises, service providers, and residential users) 🔐. It's also worth thinking about the extra security issues that come with the IPv6 transition techs used to build IPv4aaS (e.g., 464XLAT and DS-Lite) [ComputSecur] 👀.

Security has to keep at least the same level it has today in an IPv4 network environment, or even a better one 💅. The autoconfiguration features of IPv6 need some extra 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 ✨.

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 bring privacy concerns because of greater visibility on the Internet 🙈. IPv6 nodes can (and typically do) use privacy extensions [RFC8981] to stop anyone tracking their burned-in Media Access Control (MAC) address(es), which are easily readable in the original modified 64-bit Extended Unique Identifier (EUI-64) interface identifier format 🎀. On the other hand, stable IPv6 interface identifiers [RFC8064] were developed, and this can also affect privacy 🌸.

As reported in [ISOC3], if you compare IPv6 and IPv4 at the protocol level, you can probably conclude that the increased complexity of IPv6 will result in more attack vectors, which means 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 get "patched" to mitigate them 🩹. 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, so IPv4 implementations are generally more robust than IPv6 💅. However, with more IPv6 deployment, IPv6 will benefit from this process in the long run 🌈. It's also worth mentioning that most vulnerabilities nowadays are caused by human beings and sit in the application layer, not 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 🎓. So yeah, there is obviously much more experience and confidence with deploying and operating IPv4 networks than with IPv6 networks 🥹.

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)
  • Internet-wide IPv6 security (filtering, DDoS, transition mechanisms)

ICMPv6 is an integral part of IPv6 and handles error reporting and diagnostic functions 🩺. The Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6, and it replaces and enhances functions of ARP 🔍. Multicast Listener Discovery (MLD) is used by IPv6 routers to discover multicast listeners on a directly attached link, kind of like how the 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 being talked about today 🗣️. NDP has vulnerabilities [RFC3756] [RFC6583]. [RFC3756] says to use IPsec, but that's impractical and not used 😵; on the other hand, SEcure Neighbor Discovery (SEND) [RFC3971] is not widely available 🙁. It's worth mentioning that applying host isolation may address many of these concerns, as described in [ND-CONSIDERATIONS] 🧱.

[RIPE2] describes the most important threats and solutions regarding IPv6 security 📚.

5.4.1.1. IPv6 Extension Headers and Fragmentation 🧩

IPv6 extension headers provide a hook for interesting new features to be added, and they're more flexible than IPv4 options 🪝. This does add some complexity 🤯. In particular, some security mechanisms may require processing the full chain of headers, and some firewalls may require filtering packets based on their extension headers 🔥. Additionally, packets with IPv6 extension headers may be dropped in the public Internet [RFC7872] 😭. Some documents, e.g., [HBH-PROCESSING], [HBH-OPT-HDR], and [IPv6-EXT-HDR], analyze and give guidance on 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] 📉. It's also worth mentioning that the unrecognized Hop-by-Hop Options Header and Destination Options Header will not be considered by the nodes if they are not configured to deal with it [RFC8200] 🙅. Other attacks based on extension headers may use IPv6 header chains and fragmentation to bypass filtering 🕵️. To mitigate this effect, the initial IPv6 header, the extension headers, and the upper-layer header must all be in the first fragment [RFC8200] 🧷. Also, the use of the IPv6 fragment header is forbidden in all Neighbor Discovery messages [RFC6980] 🚫.

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

The operational implications of IPv6 packets with extension headers are further discussed in [RFC9098] 📝.

6. IANA Considerations 📋

This document has no IANA actions 🙌.

7. 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 documents 📚. Please go read those too, bestie, they matter a lot 💜.

8. References 📑

8.1. Normative References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.2. Informative References

okay the reference list is giving librarian energy 📚✨ here are the receipts, all of them 💅

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Appendix A. Summary of Questionnaire and Replies for Network Operators ✨

Back in the third quarter of 2020, a survey went out to more than 50 service providers in the European region 👀 asking about their IPv6 plans and how deployment was going.

In this survey, 40 people, representing 38 organizations, provided responses. This appendix summarizes the results obtained. 💅

Respondents' business:

                  +============+========+=======+
                  | Convergent | Mobile | Fixed |
                  +============+========+=======+
                  | 82%        | 8%     | 11%   |
                  +------------+--------+-------+

                    Table 10: Type of Operators

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

  • A. If so, fixed, mobile, or enterprise?
  • B. What are the reasons to do so?
  • C. When to start: already ongoing, in 12 months, or after 12 months?
  • D. Which transition solution will you use: Dual-Stack, DS-Lite, 464XLAT, or MAP-T/E?

Answers for 1.A (38 respondents)

                           +=====+=====+
                           | Yes | No  |
                           +=====+=====+
                           | 79% | 21% |
                           +-----+-----+

                       Table 11: Plan to Move
                       to IPv6 within 2 Years
           +========+=======+============+=============+
           | Mobile | Fixed | Enterprise | No Response |
           +========+=======+============+=============+
           | 63%    | 63%   | 50%        | 3%          |
           +--------+-------+------------+-------------+

                     Table 12: Business Segment

Answers for 1.B (29 respondents) 💖

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

  • 14 respondents (48%) highlighted issues related to IPv4 depletion. The reason to move to IPv6 is to avoid private and/or overlapping addresses.
  • 6 respondents (20%) stated that 5G/IoT is a business incentive to introduce IPv6.
  • 4 respondents (13%) highlighted that there is a national regulation request to associate and enable IPv6 with the launch of 5G.
  • 4 respondents (13%) considered IPv6 as a part of their innovation strategy or an enabler for new services.
  • 4 respondents (13%) introduced IPv6 because of enterprise customer demand.

Answers for 1.C (30 respondents) ⏳

    +=========+==============+=================+=============+
    | Ongoing | In 12 months | After 12 months | No Response |
    +=========+==============+=================+=============+
    | 60%     | 33%          | 0%              | 7%          |
    +---------+--------------+-----------------+-------------+

                       Table 13: Timeframe

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

          +============+=========+=======+=============+
          | Dual-Stack | 464XLAT | MAP-T | No Response |
          +============+=========+=======+=============+
          | 39%        | 21%     | 4%    | 36%         |
          +------------+---------+-------+-------------+

              Table 14: Transition in Use: Cellular
         +============+=========+==========+=============+
         | Dual-Stack | DS-Lite | 6RD/6VPE | No Response |
         +============+=========+==========+=============+
         | 59%        | 19%     | 4%       | 19%         |
         +------------+---------+----------+-------------+

               Table 15: Transition in Use: Wireline

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

  • A. If yes, what kind of devices: CPE, BNG/mobile core, or NAT?
  • B. Will you start the transition of your metro, backbone, or backhaul network to support IPv6?

Answers for 2.A (30 respondents)

                    +=====+=====+=============+
                    | Yes | No  | No Response |
                    +=====+=====+=============+
                    | 43% | 33% | 23%         |
                    +-----+-----+-------------+

                      Table 16: Need to Change
           +======+=========+=====+=====+=============+
           | CPEs | Routers | BNG | CGN | Mobile core |
           +======+=========+=====+=====+=============+
           | 47%  | 27%     | 20% | 33% | 27%         |
           +------+---------+-----+-----+-------------+

                     Table 17: What to Change

Answers for 2.B (22 respondents) 🌈

                       +=====+========+=====+
                       | Yes | Future | No  |
                       +=====+========+=====+
                       | 9%  | 9%     | 82% |
                       +-----+--------+-----+

                        Table 18: Plans for
                             Transition

Appendix B. Summary of Questionnaire and Replies for Enterprises 🎀

okay so the Industry Network Technology Council (INTC) ran a little poll in early 2021 🧚 to check whether medium-to-large US-based enterprises actually wanted training and consultancy on IPv6 (<https://industrynetcouncil.org/>). bestie, they were asking the real questions 💅

54 organizations answered 🫶

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% |
    +-------------------------------------------------+--------+

                   Table 19: IPv6 Implementation

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% |
     +------------------------------------------------+--------+

                   Table 20: Help/Classes from INTC

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

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

                Table 21: Areas of Concern for IPv6
                           Implementation

Acknowledgements 🫶

the authors wanted to thank Brian Carpenter, Fred Baker, Alexandre Petrescu, Fernando Gont, Barbara Stark, Haisheng Yu (Johnson), Dhruv Dhody, Gábor Lencse, Shuping Peng, Daniel Voyer, Daniel Bernier, Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, Erik Nygren, Eduard Vasilenko, and Xipeng Xiao for taking the time to comment on and review this document 💜

Contributors 🌸

Nalini Elkins
Inside Products
Email: nalini.elkins@insidethestack.com


Sébastien Lourdez
Post Luxembourg
Email: sebastien.lourdez@post.lu

Authors' Addresses 💜

Giuseppe Fioccola
Huawei Technologies
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com


Paolo Volpato
Huawei Technologies
Via Lorenteggio, 240
20147 Milan
Italy
Email: paolo.volpato@huawei.com


Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar, Madrid
Spain
Email: jordi.palet@theipv6company.com


Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com


Chongfeng Xie
China Telecom
Email: xiechf@chinatelecom.cn

that's the whole thing, bestie 🌈🦋 we made it through all 10 parts and every single detail is still here 👑😭

📦 where this page comes from