V6OPS                                                        G. Fioccola
Internet-Draft                                                P. Volpato
Intended status: Informational                       Huawei Technologies
Expires: December 3, 2021                                      N. Elkins
                                                         Inside Products
                                                       J. Palet Martinez
                                                        The IPv6 Company
                                                               G. Mishra
                                                            Verizon Inc.
                                                                  C. Xie
                                                           China Telecom
                                                            June 1, 2021

                         IPv6 Deployment Status


   Looking globally, IPv6 is growing faster than IPv4.  This means that
   the networking industry is selecting IPv6 for the future.  This
   document provides an overview of IPv6 transition deployment status
   and a view on how the transition to IPv6 is progressing among network
   operators and enterprises that are introducing IPv6 or have already
   adopted an IPv6-only solution.  It also aims to analyze the
   transition challenges and therefore encourage actions and more
   investigations on some areas that are still under discussion.  The
   overall IPv6 incentives are also examined.

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 https://datatracker.ietf.org/drafts/current/.

   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 December 3, 2021.

Fioccola, et al.        Expires December 3, 2021                [Page 1]

Internet-Draft                                                 June 2021

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The global IPv6 picture . . . . . . . . . . . . . . . . . . .   4
     2.1.  IPv4 Address Exhaustion . . . . . . . . . . . . . . . . .   4
     2.2.  IPv6 users  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  IPv6 allocations and networks . . . . . . . . . . . . . .   5
     2.4.  IPv6 web content  . . . . . . . . . . . . . . . . . . . .   7
   3.  A study on IPv6 deployments . . . . . . . . . . . . . . . . .   8
     3.1.  Survey among Network Operators  . . . . . . . . . . . . .   8
     3.2.  Survey among Enterprises  . . . . . . . . . . . . . . . .   9
       3.2.1.  Government, campuses and universities . . . . . . . .  10
     3.3.  Application transition  . . . . . . . . . . . . . . . . .  11
     3.4.  Observations on Content and Cloud Service Providers . . .  11
     3.5.  Observations on Industrial Internet . . . . . . . . . . .  11
   4.  IPv6 overlay service design . . . . . . . . . . . . . . . . .  11
     4.1.  IPv6 introduction . . . . . . . . . . . . . . . . . . . .  12
     4.2.  IPv6-only service delivery  . . . . . . . . . . . . . . .  13
   5.  IPv6 underlay network deployment  . . . . . . . . . . . . . .  14
   6.  IPv6 incentives . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Call for action . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Transition choices  . . . . . . . . . . . . . . . . . . .  16
       7.1.1.  Service providers . . . . . . . . . . . . . . . . . .  17
       7.1.2.  Enterprises . . . . . . . . . . . . . . . . . . . . .  18
       7.1.3.  Cloud and Data Centers  . . . . . . . . . . . . . . .  20
       7.1.4.  CPEs and user devices . . . . . . . . . . . . . . . .  20
       7.1.5.  Industrial Internet . . . . . . . . . . . . . . . . .  21
       7.1.6.  Government and Regulators . . . . . . . . . . . . . .  21
     7.2.  Network Operations  . . . . . . . . . . . . . . . . . . .  22
     7.3.  Performance . . . . . . . . . . . . . . . . . . . . . . .  22
       7.3.1.  IPv6 latency  . . . . . . . . . . . . . . . . . . . .  22
       7.3.2.  IPv6 packet loss  . . . . . . . . . . . . . . . . . .  23
       7.3.3.  Router's performance  . . . . . . . . . . . . . . . .  23

Fioccola, et al.        Expires December 3, 2021                [Page 2]

Internet-Draft                                                 June 2021

       7.3.4.  Customer Experience . . . . . . . . . . . . . . . . .  23
     7.4.  IPv6 security . . . . . . . . . . . . . . . . . . . . . .  24
       7.4.1.  Protocols security issues . . . . . . . . . . . . . .  25
       7.4.2.  Transition technologies . . . . . . . . . . . . . . .  26
       7.4.3.  IPv6 Extension Headers and Fragmentation  . . . . . .  26
       7.4.4.  Oversized IPv6 packets  . . . . . . . . . . . . . . .  26
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  27
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  27
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     12.2.  Informative References . . . . . . . . . . . . . . . . .  29
   Appendix A.  Summary of Questionnaire and Replies for network
                operators  . . . . . . . . . . . . . . . . . . . . .  35
   Appendix B.  Summary of Questionnaire and Replies for enterprises  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

   This document provides a survey of the status of IPv6 deployment and
   highlights the difficulties in the transition.  This process helps to
   understand what is missing and how to improve the current IPv6
   deployment strategies of network operators, enterprises, content and
   cloud service providers.  The scope is to give an updated view of the
   practices and plans already described in [RFC6036], to encourage
   actions and more investigations on some areas that are still under
   discussion and to present the main incentives for the IPv6 adoption.

   On the one hand [RFC6180] discusses the IPv6 deployment models and
   transition tools, [RFC6036] describes the Service Provider Scenarios
   for IPv6 Deployment, [RFC7381] introduces the guidelines of the IPv6
   deployment for Enterprise and [RFC6883] provides guidance and
   suggestions for Internet Content Providers and Application Service
   Providers.  This document focuses on the end-to-end services and in
   particular on the device - network - content communication chain.

   It is possible to mention the IAB Statement on IPv6 [IAB] stating
   that "the IAB expects that the IETF will stop requiring IPv4
   compatibility in new or extended protocols".  At the same time, SDOs
   (Standard Developing Organizations), such as ETSI, are working more
   on IPv6, as an example [ETSI-IP6-WhitePaper], reports the IPv6 Best
   Practices, Benefits, Transition Challenges and the Way Forward.

   The initial section goes through the global picture of IPv6 to show
   how IPv6 is growing faster than IPv4 worldwide.  This testifies that
   most of the industry players have decided to invest and deploy IPv6
   in large-scale.

Fioccola, et al.        Expires December 3, 2021                [Page 3]

Internet-Draft                                                 June 2021

   Then a study of IPv6 deployments is presented, including the survey
   among network operators and enterprises.  The section on IPv6 overlay
   service design describes the IPv6 transition approaches for Mobile
   BroadBand (MBB), Fixed BroadBand (FBB) and Enterprise services.  In
   particular Dual-Stack is the most deployed solution for IPv6
   introduction, while 464XLAT and Dual-Stack Lite (DS-Lite) seem the
   most suitable for IPv6-only service delivery.  The section on IPv6
   underlay network deployment focuses on the common approach for the
   transport network.

   Finally, The IPv6 incentives are presented and the general IPv6
   challenges are also reported in particular in relation to Transition
   choices, Operations, Performance and Security issues.  These
   considerations aim to start a call for action on the areas of
   improvement, that are often mentioned as reason for not deploying

2.  The global IPv6 picture

   The utilization of IPv6 has been monitored by many agencies and
   institutions worldwide.  Different analytics have been made
   available, ranging from the number of IPv6 users, its relative
   utilization over the Internet, to the number of carriers able to
   route IPv6 network prefixes.  [ETSI-IP6-WhitePaper] provided several
   of those analytics.  The scope of this section then is to summarize
   the status of the IPv6 adoption, so to get an indication of the
   relevance of IPv6 today.  For the analytics listed here, the trend
   over the past five years is given, expressed as the Compound Annual
   Growth Rate (CAGR).  In general, this shows how IPv6 has grown in the
   past few years, and that is growing faster than IPv4.

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 is affecting the process of
   its exhaustion.  The answer is not straightforward as many aspects
   have to be considered.

   On the one hand, the Regional Internet Registries (RIRs) are
   reporting scarcity of available and still reserved addresses.
   Table 3 of [POTAROO1] shows that the available pool of the five RIRs
   counts a little more than 6 million IPv4 address, while the reserved
   pool includes another 12 million, for a total of "usable" addresses
   equal to 18.3 million.  The same reference, in table 1, shows that
   the total IPv4 allocated pool equals 3.684 billion addresses.  The

Fioccola, et al.        Expires December 3, 2021                [Page 4]

Internet-Draft                                                 June 2021

   ratio between the "usable" addresses and the total allocated brings
   to 0.005% of remaining space.

   On the other, [POTAROO1] again highlights the role of both NAT and
   the address transfer to counter the IPv4 exhaustion.  NAT systems
   well fit in the current client/server model used by most of the
   available Internet applications, with this phenomenon amplified by
   the general shift to cloud.  Anyway, it should be noted that, in some
   cases, private address space cannot provide adequate address and the
   reuse of addresses makes the network even more complex.  The transfer
   of IPv4 addresses also contributes to mitigate the need of addresses.
   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 available
   addresses to satisfy their need of providing IPv4 connectivity to
   their tenants.  But, since each address blocks of Internet is
   licensed by a specific resource-holder and stored for the
   verification of the authenticity, frequent address transfer may
   affect the global routing.

2.2.  IPv6 users

   [ETSI-IP6-WhitePaper] provided the main statistics about the
   utilization of IPv6 worldwide and references the organizations that
   make their measurement publicly available through their web sites.
   To give a rough estimation of the relative growth of IPv6, the next
   table shows the total number of estimated IPv6-capable users at
   December 2020 as measured by [POTAROO2], [APNIC1].

   |        |  Dec  |  Dec  |  Dec   |  Dec   |  Dec   |  CAGR  |
   |        |  2016 |  2017 |  2018  |  2019  |  2020  |        |
   | World  | 300.85| 473.14| 543.04 | 990.19 |1,201.09|   41%  |

           Figure 1: IPv6-capable users worldwide (in millions)

2.3.  IPv6 allocations and networks

   RIRs are responsible for allocating IPv6 address blocks to Internet
   Service Providers (ISPs) or LIRs (Local Internet Registries) and
   assigning to direct end users (such as enterprises or other
   organizations).  An ISP/LIR will use the allocated block to assign
   addresses to their end users.  For example, a mobile carrier will
   assign one or several /64 prefixes to the User Equipment (UE).
   Several analytics are available from the RIRs.  The next table shows

Fioccola, et al.        Expires December 3, 2021                [Page 5]

Internet-Draft                                                 June 2021

   the amount of individual allocations, per RIR, in the time period
   2016-2020 [APNIC2].

   | Registry|  Dec  |  Dec  |  Dec  |  Dec  |  Dec  |Cumulated| CAGR |
   |         |  2016 |  2017 |  2018 |  2019 |  2020 |         |      |
   | AFRINIC |   116 |   112 |   110 |   115 |   109 |    562  | 48%  |
   |  APNIC  | 1,681 | 1,369 | 1,474 | 1,484 | 1,498 |  7,506  | 45%  |
   |   ARIN  |   646 |   684 |   659 |   605 |   644 |  3,238  | 50%  |
   |  LACNIC | 1,009 | 1,549 | 1,448 | 1,614 | 1,801 |  7,421  | 65%  |
   | RIPE NCC| 2,141 | 2,051 | 2,620 | 3,104 | 1,403 | 11,319  | 52%  |
   |         |       |       |       |       |       |         |      |
   |  Total  | 5,593 | 5,765 | 6,311 | 6,922 | 5,455 | 30,046  | 52%  |

                   Figure 2: IPv6 allocations worldwide

   Note that the decline in 2020 of IPv6 allocations from the RIPE NCC
   could be explained with the COVID-19 measures that affect many
   European countries.  Anyway countries all over the world have been
   similarly affected, but the decline in IPv6 allocation activity in
   2020 is only seen in the data from the RIPE NCC.  It may be also due
   to the big grow in the previous years.  If most of the LIRs and
   enterprises already got IPv6 addresses in the few years, at some
   point, in every RIR the requests will decline.

   [APNIC2] also compares the number of allocations for both address
   families, and the result is in favor of IPv6.  The average yearly
   growth is 52% for IPv6 in the period 2016-2020 versus 49% for IPv4, a
   sign that IPv6 is growing bigger than IPv4.  This is described in the
   next table.

   | Address| Dec  | Dec  |  Dec   |  Dec   |  Dec  | Cumulated | CAGR |
   | family | 2016 | 2017 |  2018  |  2019  |  2020 |           |      |
   |  IPv6  | 5,593| 5,765|  6,311 |  6,922 | 5,455 |   30,046  | 52%  |
   |        |      |      |        |        |       |           |      |
   |  IPv4  |10,515| 9,437| 10,192 | 14,019 | 7,437 |   51,600  | 49%  |
   |        |      |      |        |        |       |           |      |

                 Figure 3: Allocations per address family

Fioccola, et al.        Expires December 3, 2021                [Page 6]

Internet-Draft                                                 June 2021

   The next table is based on [APNIC3], [APNIC4] and shows the
   percentage of ASes supporting IPv6 compared to the total ASes
   worldwide.  The number of IPv6-capable ASes increases from 22.6% in
   January 2017 to 30.4% in January 2021.  This equals to 14% CAGR for
   IPv6 enabled networks.  This also shows that the number of networks
   supporting IPv6 is growing faster than the ones supporting IPv4,
   since the total (IPv6 and IPv4) networks grow at 6% CAGR.

   | Advertised |  Jan  |  Jan  |  Jan  |  Jan  |  Jan  | CAGR |
   |    ASN     |  2017 |  2018 |  2019 |  2020 |  2021 |      |
   |IPv6-capable| 12,700| 14,500| 16,470| 18,600| 21,400|  14% |
   |            |       |       |       |       |       |      |
   | Total ASN  | 56,100| 59,700| 63,100| 66,800| 70,400|   6% |
   |            |       |       |       |       |       |      |
   |   Ratio    | 22.6% | 24.3% | 26.1% | 27.8% | 30.4% |      |

                 Figure 4: Percentage of IPv6-capable ASes

2.4.  IPv6 web content

   [W3Tech] keeps track of the use of several technical components of
   websites.  The utilization of IPv6 for websites is shown in the next

   |  Wolrdwide |  Jan  |  Jan  |  Jan  |  Jan  |  Jan  | CAGR |
   |  Websites  |  2017 |  2018 |  2019 |  2020 |  2021 |      |
   |% of IPv6   |  9.6% | 11.4% | 13.3% | 15.0% | 17.5% |  16% |

                    Figure 5: Usage of IPv6 in websites

   Looking at the growth rate, that 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 IPv6-based content than small websites.  [Csc6lab] measured at
   the beginning of January 2021 that out of the world top 500 sites
   ranked by [Alx], 196 are IPv6-enabled.  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 should be quite relevant.

Fioccola, et al.        Expires December 3, 2021                [Page 7]

Internet-Draft                                                 June 2021

   Related to that, a question that 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, it is likely the case.  This would immediately raise the
   quantity of content potentially accessible via IPv6.

3.  A study on IPv6 deployments

3.1.  Survey among Network Operators

   Apart from a few public references who provide the status of IPv6 in
   a specific network (e.g.  [RlncJ]), most of available data come from
   organizations that constantly track the usage of IPv6 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.  The analytics show a
   degree of adoption that varies quite greatly according to the
   numerous reasons that are discussed throughout this paper (related to
   market demand, local regulation, political actions).

   To understand the details about the plans and the technical
   preferences towards IPv6, a survey was submitted to a group of
   service providers in Europe (see Appendix A for the complete poll).

   Without pretending to be exhaustive, the poll captured some insights
   that could be relevant to the discussion.  The poll reveals that the
   majority of the operators interviewed has plans concerning IPv6
   (79%).  Of them, 60% already has ongoing activities, while 33% is
   expected to start activities in a 12-months time-frame.  The
   transition to IPv6 involves all business segments: mobile (63%),
   fixed (63%), and enterprise (50%).

   The reasons to move to IPv6 vary.  The majority of the operators that
   have a plan for IPv6 perceive issues related to IPv4 depletion and
   prefer to avoid the use of private addressing schemes (48%) to save
   the NAT costs.  Global IPv4 address depletion and the run out of
   private address space recommended in [RFC1918] are reported as the
   important drivers for IPv6 deployment.  In some cases, the adoption
   of IPv6 is driven by innovation strategy (as the enabler of new
   services, 13%) or is introduced because of 5G/IoT, which play the
   role of business incentive to IPv6 (20%).  In a few cases,
   respondents highlight the availability of National Regulatory
   policies requiring to enable IPv6 together with the launch of 5G
   (13%).  Enterprise customers demand is also a reason to introduce
   IPv6 (13%).

Fioccola, et al.        Expires December 3, 2021                [Page 8]

Internet-Draft                                                 June 2021

   From a technical preference standpoint, Dual-Stack is the most
   adopted solution, both in wireline (59%) and in cellular networks
   (39%).  In wireline, the second most adopted mechanism is DS-Lite
   (19%), while in cellular networks the second preference goes to
   464XLAT (21%).

   In the majority of the cases, the interviewed operators do not see
   any need to do the transition of their network as a whole.  They
   consider to touch or to replace only what it is needed.  CPE (47%),
   BNG (20%), CGN devices (33%), mobile core (27%) are the components
   that may be affected by transition or replacement.  It is interesting
   to see that most of the network operators have no big plans to do
   transition for the transport network (metro and backbone) soon, since
   they do not see business reasons.  It seems that there is no pressure
   to do transition to native IPv6-only forwarding in the short term,
   anyway the future benefit of IPv6 may justify in the long term a
   transition to native IPv6-only.

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

3.2.  Survey among Enterprises

   As described in [RFC7381], enterprises face different challenges than
   operators.  Some publicly available statistics also show that the
   deployment of IPv6 lags behind other sectors.

   [NST_1] provides estimations on deployment status of IPv6 for more
   than 1000 second level domains such as example.com, example.net or
   example.org belonging to organizations in the United States.  The
   measurement encompasses many industries, including
   telecommunications.  So, the term "enterprises" is a bit loose to
   this extent.  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.
   Overall, for around 65% of the considered domains there is an active
   DNS Name Server (NS) record, but less than 20% have IPv6 support for
   their websites and less than 10% have IPv6-based mail services, as of
   January 2021.

   [BGR_1] have similar data for China.  The measurement considers 241
   second or third level domains such as example.com, example.cn or
   example.com.cn.  33% have IPv6 support for DNS, 2% are operationally
   ready to support mail services, 98% have IPv6-based websites.

Fioccola, et al.        Expires December 3, 2021                [Page 9]

Internet-Draft                                                 June 2021

   A poll submitted to a group of large enterprises in North America
   (see Appendix B) show that the operational issues are likely to be
   more critical than for operators.

   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 cases the network is 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%).  Interestingly, 33.33% of respondents think that all three
   areas are all simultaneously of concern.

   The full poll is reported in Appendix B.

3.2.1.  Government, campuses and universities

   This section focuses specifically on governments and academia, due to
   the relevance of both domains in the process of IPv6 adoption.  The
   already mentioned organizations that estimates the IPv6 status
   provide a deep focus on IPv6 in the network domains associated with
   governmental and education-related agencies.

   As far as the US Governmental and Federal Agencies are concerned, the
   statistics [NST_2] show higher IPv6 adoption than the overall
   enterprise sector discussed in the previous section.  This is lilely
   to be dependent on the support provided by [US-CIO].  Looking at the
   1250 measured second level domains (e.g. example.gov or example.fed
   domains) as of January 2021, more than 80% provide IPv6 support for
   DNS, around 40% have IPv6-enabled websites while only 15% have mail
   services over IPv6.  For China [BGR_2], 54 third level domains such
   as example.gov.cn domains are analyzed.  DNS is operational in 42% of
   the cases, mail services over IPv6 are not yet enabled while 98% of
   the government agencies have an IPv6 website enabled.

   For higher education, [NST_3] measures the data coming from 346
   second level domains such as example.edu, while [BGR_3] looks at 71
   domains such as example.edu.cn.  Starting with the former, slightly
   less than 50% .edu domains have IPv6 support for DNS, around 20% for
   mail services and slightly more than 15% have an IPv6 website.  In
   the case of China, 50% have DNS operational, 0% IPv6 support for mail
   services and 99% have an IPv6-enabled website.

Fioccola, et al.        Expires December 3, 2021               [Page 10]

Internet-Draft                                                 June 2021

3.3.  Application transition

   It is worth mentioning Happy Eyeballs [RFC6555] and Happy Eyeballs 2
   [RFC8305] as a major aspect of application transition and porting to
   IPv6.  All host and network router OS's by default prefer IPv6 over

3.4.  Observations on Content and Cloud Service Providers

   The number of addresses required to connect all of the virtual and
   physical elements in a Data Center and the necessity to overcome the
   limitation posed by [RFC1918] has been the driver to adopt IPv6 in
   several Content and Cloud Service Provider (CSP) networks.

   Several public references, as reported in Section 7.1.3, discuss how
   most of the major players find themselves at different stages in the
   transition to IPv6-only in their DC infrastructure.  In some cases,
   the transition already happened and the DC infrastructure of these
   hyperscalers is completely based on IPv6.  This can be considered a
   good sign because the end-to-end connectivity between a client (e.g.
   an application on a smartphone) and a server (a Virtual Machine in a
   DC) may be based on IPv6.

3.5.  Observations on Industrial Internet

   There are potential advantages for implementing IPv6 for IIoT
   (Industrial Internet of Things) applications, in particular the large
   IPv6 address space, the automatic IPv6 configuration and resource

   However, there are still many obstacles that prevent its pervasive
   use.  The key problems identified are the incomplete or immature tool
   support, the dependency on manual configuration and the poor
   knowledge of the IPv6 protocols among insiders.  To advance and ease
   the use of IPv6 for smart manufacturing systems and IIoT applications
   in general, a generic approach to remove these pain points is
   therefore highly desirable.

4.  IPv6 overlay service design

   This section reports the most deployed approaches for the IPv6
   transition in MBB, FBB and enterprise.

   The consolidated strategy, as also described in
   [ETSI-IP6-WhitePaper], is based on two stages, namely: (1) IPv6
   introduction, and (2) IPv6-only.  The first stage aims at delivering
   the service in a controlled manner, where the traffic volume of
   IPv6-based services is minimal.  When the service conditions change,

Fioccola, et al.        Expires December 3, 2021               [Page 11]

Internet-Draft                                                 June 2021

   e.g.  when the traffic grows beyond a certain threshold, then the
   move to the second stage may occur.  In this latter case, the service
   is delivered solely on IPv6, including the traffic originated from
   IPv4-based nodes.  For this reason, the IPv6-only stage is also
   called IPv4aaS (IPv4 as a Service).

4.1.  IPv6 introduction

   In order to enable the deployment of an IPv6 service over an underlay
   IPv4 architecture, there are two possible approaches:

   o  Enabling Dual-Stack at the Customer Premises Equipment (CPE)

   o  IPv6-in-IPv4 tunneling, e.g. with IPv6 Rapid Deployment (6rd).

   So, from a technical perspective, the first stage is based on Dual-
   Stack [RFC4213] or tunnel-based mechanisms such as Generic Routing
   Encapsulation (GRE), 6rd and others.

   Dual-Stack [RFC4213] is more robust, and easier to troubleshoot and
   support.  Based on information provided by operators with the answers
   to the poll (see Appendix A), it can be stated that Dual-Stack is
   currently the most widely deployed IPv6 solution, for MBB, FBB and
   enterprises, accounting for about 50% of all IPv6 deployments, see
   both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper].
   Therefore, for operators that are willing to introduce IPv6 the most
   common approach is to apply the Dual-Stack transition solution.

   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
   support IPv6, which is possibly the most difficult task in the IPv6
   transition.  In other words, the cost and effort on the network
   management and IT system upgrade are moderate.  The benefits are to
   start to accommodate future services and save the NAT costs.

   The CPE has both IPv4 and IPv6 addresses at the WAN side and uses an
   IPv6 connection to the operator gateway, e.g.  Broadband Network
   Gateway (BNG) or Packet Gateway (PGW) / User Plane Function (UPF).
   However, the hosts and content servers can still be IPv4 and/or IPv6.
   For example, NAT64 can enable IPv6-only hosts to access IPv4 servers.
   The backbone network underlay can also be IPv4 or IPv6.

   Although the Dual-Stack IPv6 transition is a good solution to be
   followed in the IPv6 introduction stage, it does have few
   disadvantages in the long run, like the duplication of the network
   resources and states, as well as other limitations for network
   operation.  It also means requiring more IPv4 addresses, so an

Fioccola, et al.        Expires December 3, 2021               [Page 12]

Internet-Draft                                                 June 2021

   increase in both Capital Expenses (CAPEX) and Operating Expenses
   (OPEX).  Even if private addresses are being used via Carrier-Grade
   NAT (CGN), there is extra investment in the CGN devices.

   For this reason, when IPv4 traffic is vanishingly small or when IPv6
   usage increases to more than a given percentage, which highly depends
   on each network (typically over 60%), it would be better to switch to
   the IPv6-only stage with IPv4aaS.  It is difficult to establish the
   criterion for switching and in particular the limit of the IPv4
   decrease or the IPv6 increase beyond which the switch to IPv6 is
   desirable.  There are several factors to consider, indeed the
   switching costs might be high including loss of customers.

   [WIPv6L] reports measurements of network operator participants in
   World IPv6 Launch, in particular the IPv6 deployment is more than 50%
   for 105 out of 318 (33%) and more that 75% for 38 out of 318 (12%).
   So it could be possible to consider a threshold of IPv6 increase up
   to 75% and it is something that is already a reality for a number of

4.2.  IPv6-only service delivery

   The second stage, named here IPv6-only (but including IPv4 support
   via IPv4aaS), can be a complex decision that depends on several
   factors, such as economic factors, policy and government regulation.

   [I-D.ietf-v6ops-transition-comparison] discusses and compares the
   technical merits of the most common transition solutions for
   IPv6-only service delivery, 464XLAT [RFC6877], DS-lite [RFC6333],
   Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T
   [RFC7599], but without providing an explicit recommendation.  As the
   poll highlights, the most widely deployed IPv6 transition solution
   for MBB is 464XLAT and for FBB is DS-Lite.

   Based on the survey among network operators in Appendix A it is
   possible to analyze the IPv6 transition technologies that are already
   deployed or that will be deployed.  The different answers to the
   questionnaire and in particular [ETSI-IP6-WhitePaper] reported
   detailed statistics on that and it can be stated that, besides Dual-
   Stack, the most widely deployed IPv6 transition solution for MBB is
   464XLAT, and for FBB is DS-Lite, both of which are IPv6-only
   solutions, also referred as IPv4 as a Service.  IPv4aaS offers Dual-
   Stack service to users and allows an operator to run IPv6-only in the
   access network.

   However, it needs to be observed, that more FBB and mixed MBB/FBB are
   turning to 464XLAT, as 464XLAT seems to be the most valid solution

Fioccola, et al.        Expires December 3, 2021               [Page 13]

Internet-Draft                                                 June 2021

   for MBB and it is often preferred to the other transition mechanisms,
   especially if we consider the case of mixed MBB/FBB.

   Looking at the different feedback from network operators, in some
   cases, even when using private addresses, such as private address
   space as recommended in [RFC1918], the address pool is not large
   enough, e.g. for large mobile operators or large Data Centers (DCs),
   Dual-Stack is not enough, because it still requires IPv4 addresses to
   be assigned.  Also, Dual-Stack will likely lead to duplication of
   several network operations both in IPv6 and IPv4 and this increases
   the amount of state information in the network with a waste of
   resources.  For this reason, in some scenarios (e.g.  MBB or DCs)
   IPv6-only stage could be more efficient from the start since the IPv6
   introduction phase with Dual-Stack may consume more resources (for
   example CGN costs).

   It is worth mentioning that the IPv6-only transition technologies
   with IPv4aaS, such as 464XLAT, have a much lower need for IPv4 public
   addresses, because they make a more efficient usage without
   restricting the number of ports per subscriber and this reduces
   troubleshooting costs as well.  This may also be tied to the
   permanent black-listing of IPv4 address blocks when used via CGN in
   some services, such as Sony Play Station Network or OpenDNS, among
   others, which implies a higher rotation of IPv4 prefixes in CGN,
   until they get totally blocked.  IPv6-only with IPv4aaS, in many
   cases, could outweigh sooner than expected the advantages of Dual-
   Stack or IPv6-in-IPv4 tunneling.  It can also be facilitated by the
   natural upgrade or replacement of CPEs because of newer technologies
   (tripe-play, higher bandwidth WAN links, better WiFi technologies,
   etc.) and, at the same time, the CAPEX and OPEX of other parts of the
   network will be lowered (for example CGN and associated logs), indeed
   the chance to reduce the usage of IPv4 addresses could also be turn
   into revenues by means of IPv4 transfers.

   So, in general, as already mentioned in the previous section, when
   the Dual-Stack disadvantages outweigh the IPv6-only complexity, it
   makes sense to do the transition to IPv6-only.  Some network
   operators already started this process, while others are still

5.  IPv6 underlay network deployment

   IPv6-only alone can be misinterpreted.  It can be referred to
   different portions of the network, to the underlay network, to the
   overlay (services) [I-D.palet-v6ops-ipv6-only].

   As opposed to the IPv6-only service delivery (with IPv4aaS) discussed
   in the previous sections, the IPv6-only network means that the whole

Fioccola, et al.        Expires December 3, 2021               [Page 14]

Internet-Draft                                                 June 2021

   network uses IPv6 as the network protocol for all traffic delivery,
   but some operators may do IPv6-only at the access network only.  It
   is a case-by-case basis.

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

   Regarding the IPv6 underlay network deployment, the network operator,
   both in the IPv6 introduction stage and in IPv6-only stage, needs to
   consider the necessity to connect IPv6 islands over an IPv4 transport
   network, e.g. using 6PE or 6VPE.  For metro and backbone network, the
   current trend is to keep MPLS Data Plane and run IPv6/IPv4 over PE
   devices at the border.

   As operators do the transition in the future to IPv6 metro and
   backbone network, e.g.  Segment Routing over IPv6 dataplane (SRv6),
   they are able to start the elimination of IPv4 from the underlay
   transport network while continuing to provide overlay IPv4 services.
   Basically, as also showed by the poll among network operators, from a
   network architecture perspective, it is not advisable to apply Dual-
   Stack to the transport network.  It can be either IPv4 only or IPv6
   only but never dual-stacked, considering the possibility to have
   overlay IPv6 connections through MPLS VPNs or Segment Routing (SR).

   In this scenario it is clear that the complete deployment of a full
   IPv6-only network will take more time.  If we look at the long term
   evolution, IPv6 can bring other advantages like introducing advanced
   protocols developed only on IPv6.

6.  IPv6 incentives

   It is possible to state that IPv6 adoption is no longer optional,
   indeed there are several incentives for the IPv6 deployment:

      Technical incentives: all Internet technical standard bodies and
      network equipment vendors have endorsed IPv6 and view it as the
      standards-based solution to the IPv4 address shortage.  The IETF,
      as well as other Standards Developing Organizations (SDOs), need
      to ensure that their standards do not assume IPv4.  The IAB
      expects that the IETF will stop requiring IPv4 compatibility in
      new or extended protocols.  Future IETF protocol work will then
      optimize for and depend on IPv6.  It is recommended by [RFC6540]
      that all networking standards assume the use of IPv6 and be
      written so they do not require IPv4.  In addition, every Regional
      Internet Registry worldwide strongly recommends immediate IPv6

Fioccola, et al.        Expires December 3, 2021               [Page 15]

Internet-Draft                                                 June 2021

      Business incentives: with the emergence of new digital
      technologies, such as 5G, IoT and Cloud, new use cases have come
      into being and posed more new requirements for IPv6 deployment.
      Over time, numerous technical and economic stop-gap measures have
      been developed in an attempt to extend the lifetime of IPv4, but
      all of these measures add cost and complexity to network
      infrastructure and raise significant barriers to innovation.  It
      is widely recognized that full transition to IPv6 is the only
      viable option to ensure future growth and innovation in Internet
      technology and services.  Several large networks and Data Centers
      have already evolved their internal infrastructures to be
      IPv6-only.  Forward looking large corporations are also working
      toward the transition of their enterprise networks to IPv6-only

      Governments incentives: governments have a huge responsibility in
      promoting IPv6 deployment within their countries.  There are
      example of governments already adopting policies to encourage IPv6
      utilization or enforce increased security on IPv4.  So, even
      without funding the IPv6 transition, governments can recommend to
      add IPv6 compatibility for every connectivity, service or products
      bid.  This will encourage the network operators and vendors who do
      not want to miss out on government related bids to evolve their
      infrastructures to be IPv6 capable.  Any public incentives for
      technical evolution will be bonded to IPv6 capabilities of the
      technology itself.  In this regard, in the United States, the
      Office of Management and Budget is calling for an implementation
      plan to have 80% of the IP-enabled resources on Federal networks
      be IPv6-only by 2025.  If resources cannot be converted, then the
      Federal agency is required to have a plan to retire them.  The
      Call for Comment is at [US-FR] and [US-CIO].  In China, the
      government launched IPv6 action plan in 2017, which requires that
      networks, applications and terminal devices will fully support the
      adoption of IPv6 by the end of 2025 [CN].

7.  Call for action

   There are some areas of improvement, that are often mentioned in the
   literature and during the discussions on IPv6 deployment.  This
   section lists these topics and wants to start a call for action to
   encourage more investigations on these aspects.

7.1.  Transition choices

   From an architectural perspective, a service provider or an
   enterprise 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

Fioccola, et al.        Expires December 3, 2021               [Page 16]

Internet-Draft                                                 June 2021

   method to support the transition may depend on factors specific to
   the operator's or the enterprise's context, such as the IPv6 network
   design that fits the service requirements, the deployment strategy,
   and the service and network operations.

   This section briefly highlights the basic approaches that service
   providers and enterprises may take.  The scope is to raise the
   discussion whether actions may be taken that allow to overcome the
   issues highlighted and further push the adoption of IPv6.

7.1.1.  Service providers

   IPv6 is introduced at the service layer when a service requiring
   IPv6-based connectivity is deployed in an IPv4-based network.  In
   this case, as already mentioned in the previous sections, a strategy
   is based on two stages: IPv6 introduction and IPv6-only.

   For fixed operators, the massive CPE software upgrade to support
   Dual-Stack started in most of service providers network and the
   traffic percentage is currently between 30% and 40% of IPv6, looking
   at the global statistics.  This is valid for a network operator that
   provides Dual-Stack and gives the same opportunity for end terminal
   applications to choose freely the path that they want and assuming a
   normal Internet usage.  Anyway, it is interesting to see that in the
   latest years 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.  Indeed, in some cases the
   percentage of IPv6 traffic can also exceed 65%, reaching even 80-90%.
   This aspect could affect the decision on the IPv6 adoption for an
   operator, but there are also other aspects like the current IPv4
   addressing status, CPE costs, CGN costs and so on.  Most operators
   already understood the need to adopt IPv6 in their networks and
   services, and also to promote the diffusion into their clients, while
   others are still at the edge of a massive implementation decision.
   Indeed, two situations are possible:

      Operators that have already employed CGN and have introduced IPv6
      in their networks, so they remain attached to a Dual-Stack
      architecture.  Although IPv6 brought them to a more technological
      advanced state, CGN, on the other end, boosts for some time their
      ability to supply CPE IPv4 connectivity.

      Operators with a Dual-Stack architecture that have introduced IPv6
      both in the backbone and for the CPEs, but when reaching the limit
      in terms of number of IPv4 addresses available, they need to start
      defining and start to apply a new strategy that can be through CGN
      or with an IPv6-only with IPv4aaS approach.

Fioccola, et al.        Expires December 3, 2021               [Page 17]

Internet-Draft                                                 June 2021

   For mobile operators, the situation is different since they are
   stretching their IPv4 address space since CGN translation levels have
   been reached and no more IPv4 public pool addresses are available.
   The new requirements from IoT services, 5G 3GPP release
   implementations, Voice over Long-Term Evolution (VoLTE) together with
   the constraints of national regulator lawful interception are seen as
   major drivers for IPv6.  For these reasons, two situations are

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

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

7.1.2.  Enterprises

   The business reasons for IPv6 is unique to each enterprise especially
   for the internal network.  But the most common drivers are on the
   external network due to the fact that when Internet service
   providers, run out of IPv4 addresses, they will provide native IPv6
   and non-native IPv4.  So for client networks trying to reach
   enterprise networks, the IPv6 experience will be better than the
   transitional IPv4 if the enterprise deploys IPv6 in its public-facing
   services.  Enterprise that is or will be expanding into emerging
   markets or that partners with other companies who use IPv6 (larger
   enterprise, governments, service providers) has to deploy IPv6 or
   plan to do in the near term to support the long term goals.  As an
   example it is possible to mention the emerging energy market and in
   particular SmartGrid where high density of IP-enabled endpoints are
   needed and IPv6 is a key technology.  IPv6 also shows its advantages
   in the case of acquisition, indeed when an enterprise merge two
   networks which use IPv4 private addresses, the address space of the
   two networks may overlap and this makes the merge difficult.

   The dual stage approach described in the previous sections can be
   still applicable for enterprises, even if the priorities to apply
   either stage are different since they have to consider both the
   internal and external network:

      It is possible to start with Dual-Stack on hosts/OS and then in
      client network distribution layer.  This allows the IPv6
      introduction independently since both hosts/OS and client networks
      belong to the domain of the enterprise.

      Dual-Stack can be further extended to WAN/campus core/edge
      routers.  Also, as temporary solution, the NAT64 can be used for

Fioccola, et al.        Expires December 3, 2021               [Page 18]

Internet-Draft                                                 June 2021

      servers/apps only capable of IPv4.  Enterprise Data Center is also
      to be considered for the IPv6 transition.  In this regard the
      application support needs to be taken into account, even if
      virtualization should make DCs simpler and more flexible.

      There are additional challenges also related to the campus network
      and the cloud interconnection, indeed the networking may be not
      homogeneous.  IPv6 could help to build a flat network by
      leveraging SD-WAN integration.  The perspective of IPv6-only could
      also ensure better end-to-end performance.

   Enterprises (private, managed networks) worldwide have failed to
   adopt IPv6, especially on internal networks.  Some countries, in
   particular in Asia, who faced a shortage of IPv4 addresses, have
   moved somewhat more quickly.  But, even there, the large "brick-and-
   mortar" enterprises find no business reason to adopt IPv6.

   The enterprise engineers and technicians also don't know how IPv6
   works.  The technicians want to get trained yet the management does
   not feel that they do not want to pay for such training because they
   do not see a business need for adoption.  This creates an unfortunate
   cycle where misinformation about the complexity of the IPv6 protocol
   and unreasonable fears about security and manageability combine with
   the perceived lack of urgent business needs to prevent adoption of

   In 2019 and 2020, there has been a concerted effort by some grass
   roots non-profits working with ARIN and APNIC to provide training

   Having said that, some problems such as the problem of application
   porting to IPv6 are quite difficult, even if technically is not a big
   issue.  The reliance of the economic, governmental, and military
   enterprise organizations on computer applications is great; the
   number of legacy systems, and ossification at such organizations, is
   also great.  A number of mission-critical computer applications were
   written in the 1970's.  While they have the source code, no one at
   the enterprise may be familiar with the application nor do they have
   the funds for external resources.  So, transitioning to IPv6 is quite

   The problem may be that of "First Mover Disadvantage".
   Understandably, corporations, having responsibility to their
   stakeholders, have upgraded to new technologies and architectures,
   such as IPv6, only if it gains them revenue.  Thus, legacy programs
   and technical debt accumulate.

Fioccola, et al.        Expires December 3, 2021               [Page 19]

Internet-Draft                                                 June 2021

7.1.3.  Cloud and Data Centers

   It was already highlighted how 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.  This is primarily directed to serve the
   transition to cloud of enterprise's applications.

   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.  Yet, CSPs are
   struggling to buy IPv4 addresses.  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 will be charged to an
   enterprise as a fee.  From a financial standpoint this effect might
   be taken into consideration when evaluating the decision of moving to

   It could be 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 an high percentage, at least higher than 50% in
   most of the cases.  Since all the key Caches and CDNs are IPv6-ready
   [Cldflr], [Akm], [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.

7.1.4.  CPEs and user devices

   It can be noted that most of the user devices (e.g. smartphones) are
   already IPv6-enabled for so many years.  But there are exceptions,
   for example smartTVs and Set-Top Box (STBs) 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 extremely small number of customers who notice that
   IPv4 is done via NAT444 (or even NAT4444 if the customer has set up
   their home network with double NAT), it could be less likely to run
   out of IPv4 addresses and private IPv4 space.  But as IPv4-only
   devices and traffic reduce, then the need to support private and
   public IPv4 become less.  So the CPE support to IPv6 is also an
   important incentive to overcome Dual-Stack towards IPv6-only with

Fioccola, et al.        Expires December 3, 2021               [Page 20]

Internet-Draft                                                 June 2021

7.1.5.  Industrial Internet

   As the most promising protocol for network applications, IPv6 is
   frequently mentioned in relation to Internet of Things and Industry
   4.0.  However, its industrial adoption, in particular in smart
   manufacturing systems, has been much slower than expected.  Indeed,
   it is important to provide an easy way to familiarize system
   architects and software developers with the IPv6 protocol and its
   role in the application development life cycle in order to limit the
   dependency on manual configuration and improve the tool support.

   It is possible to differentiate types of data and access to
   understand how and where the IPv6 transition can happen.  In the
   control network, determinism is required with full operational
   visibility and control, as well as reliability and availability.  In
   monitoring IoT, best effort can be acceptable and low OPEX, zero-
   touch functions autoconfiguration, zero-configuration.  For
   diagnostics and alerts, trust and transmissions that do not impact
   the control network are needed.  For safety, guarantees in terms of
   redundancy, latency similar to the control network but with total
   assurance, is necessary.

   For IIoT applications, it would be desirable to be able to implement
   a truly distributed system without dependencies to central components
   like a DHCP server.  In this regard the distributed IIoT applications
   can leverage the configuration-less characteristic of IPv6 and in
   this regard all the possible problems and compatibility issues with
   IPv6 link local addresses, SLAAC (StateLess Address Auto
   Configuration) needs to be investigated.

   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 like PLCs (Programmable Logic Controllers) and
   fieldbuses for real-time control to subsystems where this is
   absolutely necessary.

7.1.6.  Government and Regulators

   The slogan should be "stimulate if you can, regulate if you must".
   The global picture shows that the deployment of IPv6 worldwide is not
   uniform at all [G_stats], [APNIC1].  Countries where either market
   conditions or local regulators have stimulated the adoption of IPv6
   show clear sign of growth.

   As an example, zooming into the European Union area, countries such
   as Belgium, France and Germany are well ahead in terms of IPv6
   adoption.  The French National Regulator, Arcep, can be considered a

Fioccola, et al.        Expires December 3, 2021               [Page 21]

Internet-Draft                                                 June 2021

   good reference of National support to IPv6.  [ARCEP] introduced an
   obligation for the operators awarded with a license to use 5G
   frequencies (3.4-3.8GHz) in Metropolitan France to be IPv6
   compatible.  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".

   A renewed industrial policy might be advocated in other countries and
   regions to stimulate IPv6 adoption.  As an example, in the United
   States, the Office of Management and Budget is also calling for IPv6
   adoption [US-FR], [US-CIO].

7.2.  Network Operations

   An important factor is represented by the need for training the
   network operations workforce.  Deploying IPv6 requires it as 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.

7.3.  Performance

   Despite their relative differences, people tend to compare the
   performance of IPv6 versus IPv4, even if these differences are not so
   important for applications.  In some cases, IPv6 behaving "worse"
   than IPv4 tends to re-enforce the justification of not moving towards
   the full adoption of IPv6.  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 extensive researches and measurement campaigns are
   currently providing up-to-date information.  This section will look
   briefly at both of them, considering the available measurements.
   Operators are invited to bring in their experience and enrich the
   information reported below.

7.3.1.  IPv6 latency

   [APNIC5] constantly compares the latency of both address families.
   Currently, the worldwide average is still in favor of IPv4.  Zooming
   at the country or even at the operator level, it is possible to get

Fioccola, et al.        Expires December 3, 2021               [Page 22]

Internet-Draft                                                 June 2021

   more detailed information and appreciate that cases exist where IPv6
   is faster 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 lays 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.  Even considering this, a difference in
   latency stands and sometimes it is perceived as a limiting factor for
   IPv6.  A few measurement campaigns on the behavior of IPv6 in CDNs
   are also available [MAPRG-IETF99], [INFOCOM].  The TCP connect time
   is still higher for IPv6 in both cases, even if the gap has reduced
   over the analysis time window.

7.3.2.  IPv6 packet loss

   [APNIC5] also provides the failure rate of IPv6.  Two reports, namely
   [RIPE1] and [APRICOT], discussed the associated trend, showing how
   the average worldwide failure rate of IPv6 worsened from around 1.5%
   in 2016 to a value exceeding 2% in 2020.  Reasons for this effect may
   be found in endpoints with an unreachable IPv6 address, routing
   instability or firewall behaviour.  Yet, this worsening effect may
   appear as disturbing for a plain transition to IPv6.  Operators are
   once again invited to share their experience and discuss the
   performance of IPv6 in their network scenarios.

7.3.3.  Router's performance

   It is worth mentioning the aspect of Router's performance too.  IPv6
   is 4 times longer than IPv4 and it is possible to do a simple
   calculation: the same memory on routers could permit to have 1/4 of
   different tables (routing, filtering, next hop).  Anyway, most of the
   routers showed a remarkably similar throughput and latency for IPv4
   and IPv6.  For smaller software switching platforms, some tests
   reported a lower throughput for IPv6 compared to IPv4 only in case of
   smaller packet sizes, while for larger hardware switching platforms
   there was no throughput variance between IPv6 and IPv4 both at larger
   frame sizes and at the smaller packet size.

7.3.4.  Customer Experience

   It has been publicly reported by IPv6 content providers, such as for
   example FaceBook and Akamai, that users have a better experience when
   using IPv6-only compared to IPv4 (40% faster time to complete HTTP
   get ) [ISOC2].  This can be easily explained because in the case of
   IPv6 users, reaching IPv6-only Data Centers, IPv6 is end-to-end,
   without translations.  Instead when using IPv4 there is a NAT
   translation in the CPE, maybe one more in the ISP CGN and then, the

Fioccola, et al.        Expires December 3, 2021               [Page 23]

Internet-Draft                                                 June 2021

   translation from IPv4 to IPv6 (and back to IPv4) in the IPv6-only
   content provider Data Center.  In summary, that means that the
   customer "perceived experience" can be close to "double" faster with
   IPv6 than with IPv4.

7.4.  IPv6 security

   IPv6 presents a number of exciting possibilities for the expanding
   global Internet, however, there are also noted security challenges
   associated with the transition to IPv6.  [I-D.ietf-opsec-v6] analyzes
   the operational security issues in several places of a network
   (enterprises, service providers and residential users).

   The security aspects have to be considered to keep the same level of
   security as it exists nowadays in an IPv4-only network environment.
   The autoconfiguration features of IPv6 will require some more
   attention for the things going on at the network level.  Router
   discovery and address autoconfiguration may produce unexpected
   results and security holes.  The IPsec protocol implementation has
   initially been set as mandatory in every node of the network, but
   then relaxed to recommendation due to extremely constrained hardware
   deployed in some devices e.g., sensors, Internet of Things (IoT).

   There are some concerns in terms of the security but, on the other
   hand, IPv6 offers increased efficiency.  There are measurable
   benefits to IPv6 to notice, like more transparency, improved
   mobility, and also end to end security (if implemented).

   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 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, this is turning also in the other way around, as with more
   IPv6 deployment there may be older IPv4 flaws not discovered or even
   not resolved anymore by vendors.

Fioccola, et al.        Expires December 3, 2021               [Page 24]

Internet-Draft                                                 June 2021

   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

   Finally, implementation of IPv6 security controls obviously depends
   on the availability of features in security devices and tools.
   Whilst there have been improvements in this area, there is a lack of
   parity in terms of features and/or performance when considering IPv4
   and IPv6 support in security devices and tools.

7.4.1.  Protocols security issues

   It is important to say that IPv6 is not more or less secure than IPv4
   and the knowledge of the protocol is the best security measure.

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

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

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

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

   ICMPv6 is an integral part of IPv6 and performs error reporting and
   diagnostic functions.  Since it is used in many IPv6 related
   protocols, ICMPv6 packet with multicast address should be filtered
   carefully to avoid attacks.  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 adds 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.

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

Fioccola, et al.        Expires December 3, 2021               [Page 25]

Internet-Draft                                                 June 2021

7.4.2.  Transition technologies

   It is also worth considering the additional security issues brought
   into existence by the applied IPv6 transition technologies used to
   implement IPv4aaS, e.g. 464XLAT, DS-Lite.  Some hints are in the
   paper [ComputSecur].

   The different transition mechanisms must be deployed and operated in
   a secure way.  [I-D.ietf-opsec-v6] also proposes operational
   guidelines for the most known and deployed transition techniques.

7.4.3.  IPv6 Extension Headers and Fragmentation

   IPv6 Extension Headers imply some issues, in particular their
   flexibility also means an increased complexity, indeed security
   devices and software must process the full chain of headers while
   firewalls must be able to filter based on Extension Headers.
   Additionally, packets with IPv6 Extension Headers may be dropped in
   the public Internet.  Some documents, e.g.
   [I-D.hinden-6man-hbh-processing], [I-D.bonica-6man-ext-hdr-update],
   [I-D.peng-v6ops-hbh] analyze and provide guidance regarding the
   processing procedures of IPv6 Extension Headers.

   There are some possible attacks through EHs, for example RH0 can be
   used for traffic amplification over a remote path and it is
   deprecated.  Other attacks based on Extension Headers are based on
   IPv6 Header Chains and Fragmentation that could be used to bypass
   filtering, but, to mitigate this effect, Header chain should go only
   in the first fragment and the use of the IPv6 Fragmentation Header is
   forbidden in all Neighbor Discovery messages.

   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

7.4.4.  Oversized IPv6 packets

   A lot of additional functionality has been added to IPv6 primarily by
   adding Extension Headers and/or using overlay encapsulation.  All of
   the these expand the packet size and this could lead to oversized
   packets that would be dropped on some links.

   It is better to investigate the potential problems with oversized
   packets in the first place.  Fragmentation must not be done in
   transit and a better solution needs to be found, e.g. upgrade all

Fioccola, et al.        Expires December 3, 2021               [Page 26]

Internet-Draft                                                 June 2021

   links to bigger MTU or follow specific recommendations at the source
   node.  [I-D.vasilenko-v6ops-ipv6-oversized-analysis] analyzes
   available standards for the resolution of oversized packet drops.

8.  Security Considerations

   This document has no impact on the security properties of specific
   IPv6 protocols or transition tools.  The security considerations
   relating to the protocols and transition tools are described in the
   relevant documents.

9.  Contributors

   Sebastien Lourdez
   Post Luxembourg
   Email: sebastien.lourdez@post.lu

10.  Acknowledgements

   The authors of this document would like to thank Brian Carpenter,
   Fred Baker, Jordi Palet Martinez, Alexandre Petrescu, Barbara Stark,
   Haisheng Yu(Johnson), Dhruv Dhody, Gabor Lencse, Shuping Peng, Eduard
   Vasilenko and Xipeng Xiao for their comments and review of this

11.  IANA Considerations

   This document has no actions for IANA.

12.  References

12.1.  Normative References

              Vyncke, E., Kk, C., Kaeo, M., and E. Rey, "Operational
              Security Considerations for IPv6 Networks", draft-ietf-
              opsec-v6-27 (work in progress), May 2021.

              Lencse, G., Martinez, J. P., Howard, L., Patterson, R.,
              and I. Farrer, "Pros and Cons of IPv6 Transition
              Technologies for IPv4aaS", draft-ietf-v6ops-transition-
              comparison-00 (work in progress), April 2021.

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

Fioccola, et al.        Expires December 3, 2021               [Page 27]

Internet-Draft                                                 June 2021

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

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

Fioccola, et al.        Expires December 3, 2021               [Page 28]

Internet-Draft                                                 June 2021

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

   [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>.

12.2.  Informative References

   [Akm]      Akamai, "IPv6 Adaptation",

              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", <https://aws.amazon.com/es/about-

Fioccola, et al.        Expires December 3, 2021               [Page 29]

Internet-Draft                                                 June 2021

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

   [APNIC2]   APNIC2, "Addressing 2020", 2021,

   [APNIC3]   APNIC, "BGP in 2019 - The BGP Table", 2020,

   [APNIC4]   APNIC, "IPv6 in 2020", 2021,

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

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

   [ARCEP]    ARCEP, "Arcep Decision no 2019-1386, Decision on the terms
              and conditions for awarding licences to use frequencies in
              the 3.4-3.8GHz band", 2019,

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

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

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

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

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

Fioccola, et al.        Expires December 3, 2021               [Page 30]

Internet-Draft                                                 June 2021

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

   [CN]       China.org.cn, "China to speed up IPv6-based Internet
              development", 2017, <http://www.china.org.cn/

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

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

   [G_stats]  Google, "Google IPv6 Per-Country IPv6 adoption", 2021,

   [Ggl]      Google, "Introduction to GGC",

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

              Bonica, R. and T. Jinmei, "Inserting, Processing And
              Deleting IPv6 Extension Headers", draft-bonica-6man-ext-
              hdr-update-05 (work in progress), March 2021.

              Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
              Processing Procedures", draft-hinden-6man-hbh-
              processing-00 (work in progress), December 2020.

Fioccola, et al.        Expires December 3, 2021               [Page 31]

Internet-Draft                                                 June 2021

              Martinez, J. P., "IPv6-only Terminology Definition",
              draft-palet-v6ops-ipv6-only-05 (work in progress), March

              Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,
              "Processing of the Hop-by-Hop Options Header", draft-peng-
              v6ops-hbh-03 (work in progress), January 2021.

              Vasilenko, E., Xipeng, X., and D. Khaustov, "IPv6
              Oversized Packets Analysis", draft-vasilenko-v6ops-ipv6-
              oversized-analysis-00 (work in progress), March 2021.

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

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

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

              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,

Fioccola, et al.        Expires December 3, 2021               [Page 32]

Internet-Draft                                                 June 2021

              Bajpai, V., "Measuring YouTube Content Delivery over
              IPv6", 2017, <https://www.ietf.org/proceedings/99/slides/

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

   [NRO]      AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC, "Internet Number
              Resource Status Report", 2020, <https://www.nro.net/wp-

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

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

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

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

              POTAROO, "Addressing 2020", 2020,

              POTAROO, "IPv6 Resource Distribution Reports", 2021,

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <https://www.rfc-editor.org/info/rfc6555>.

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

Fioccola, et al.        Expires December 3, 2021               [Page 33]

Internet-Draft                                                 June 2021

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

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

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

   [SNDVN]    SANDVINE, "Sandvine releases 2020 Mobile Internet
              Phenomena Report: YouTube is over 25% of all mobile
              traffic", 2020, <https://www.sandvine.com/press-releases/

   [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, <https://www.federalregister.gov/

   [Vrzn]     Verizon, "Verizon Digital Media Services announces IPv6
              Compliance", <https://www.verizondigitalmedia.com/blog/

   [W3Tech]   W3Tech, "Historical yearly trends in the usage statistics
              of site elements for websites", 2021, <https://w3techs.com

   [WIPv6L]   World IPv6 Launch, "World IPv6 Launch - Measurements",
              2021, <https://www.worldipv6launch.org/measurements/>.

Fioccola, et al.        Expires December 3, 2021               [Page 34]

Internet-Draft                                                 June 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

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

Fioccola, et al.        Expires December 3, 2021               [Page 35]

Internet-Draft                                                 June 2021

   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)

                   On-going  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 migrate 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 migration   9%   9%      82%

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

   54 organizations provided an answer.

Fioccola, et al.        Expires December 3, 2021               [Page 36]

Internet-Draft                                                 June 2021

   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%
      Web site is IPv6 enabled                         7.41%
      Most equipment is dual-stacked                  31.48%
      Have an IPv6 migration plan for entire network   5.56%
      Running native IPv6 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

   Giuseppe Fioccola
   Huawei Technologies
   Riesstrasse, 25
   Munich  80992

   Email: giuseppe.fioccola@huawei.com

Fioccola, et al.        Expires December 3, 2021               [Page 37]

Internet-Draft                                                 June 2021

   Paolo Volpato
   Huawei Technologies
   Via Lorenteggio, 240
   Milan  20147

   Email: paolo.volpato@huawei.com

   Nalini Elkins
   Inside Products
   36A Upper Circle
   Carmel Valley  CA 93924
   United States of America

   Email: nalini.elkins@insidethestack.com

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

   Email: jordi.palet@theipv6company.com

   Gyan S. Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com

   Chongfeng Xie
   China Telecom

   Email: xiechf@chinatelecom.cn

Fioccola, et al.        Expires December 3, 2021               [Page 38]