<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
The next line defines an entity named RFC2629, which contains the necessary XML
for the reference element, and is used much later in the file. This XML contains an
anchor (also RFC2629) which can be used to cross-reference this item in the text.
You can also use local file names instead of a URI. The environment variable
XML_LIBRARY provides a search path of directories to look at to locate a
relative path name for the file. There has to be one entity for each item to be
referenced. -->
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"> nbsp " ">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml"> zwsp "​">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!-- There is also a library of current Internet Draft citations. It isn't a good idea to
actually use one for the template because it might have disappeared when you come to test
this template. This is the form of the entity definition
<!ENTITY I-D.mrose-writing-rfcs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs.xml">
corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation will be
to the most recent draft in the sequence, and is updated roughly hourly on the web site.
For working group drafts, the same principle applies: file name starts draft-ietf-wgname-..
and entity file is reference.I-D.ietf-wgname-... The corresponding entity name is
I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example). Of course this doesn't
change when the draft version changes.
-->
<!-- Fudge for XMLmind which doesn't have this built in --> nbhy "‑">
<!ENTITY nbsp " "> wj "⁠">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions can be placed here but if you are editing
with XMLmind (and maybe other XML editors) they are better placed
after the rfc element start tag as shown below. -->
<!-- Information about the document.
category values: std, bcp, info, exp, and historic
For Internet-Drafts, specify attribute "ipr".
(ipr values are: full3667, noModification3667, noDerivatives3667),
Also for Internet-Drafts, can specify values for
attributes "docName" and, if relevant, "iprExtract". Note
that the value for iprExtract is the anchor attribute
value of a section (such as a MIB specification) that can be
extracted for separate publication, and is only
useful whenhe value of "ipr" is not "full3667". -->
<!-- TODO: verify which attributes are specified only
by the RFC editor. It appears that attributes
"number", "obsoletes", "updates", and "seriesNo"
are specified by the RFC editor (and not by
the document author). -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
ipr="trust200902" number="9386"
docName="draft-ietf-v6ops-ipv6-deployment-10"
obsoletes="6036" >
<!-- Processing Instructions- PIs (for a complete list and description,
see file http://xml.resource.org/authoring/README.html and below... -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?> <!-- Controls display of <cref> elements -->
<?rfc inline="no" ?> <!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?> <!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
updates=""
submissionType="IETF" consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.15.3 -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 42 characters -->
<title abbrev="">IPv6 abbrev="IPv6 Deployment Status">IPv6 Deployment Status</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<seriesInfo name="RFC" value="9386"/>
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Riesstrasse, 25</street>
<city>Munich</city>
<code>80992</code>
<country>Germany</country>
</postal>
<email>giuseppe.fioccola@huawei.com</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<author fullname="Paolo Volpato" initials="P." surname="Volpato">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Via Lorenteggio, 240</street>
<city>Milan</city>
<code>20147</code>
<country>Italy</country>
</postal>
<email>paolo.volpato@huawei.com</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<author fullname="Jordi Palet Martinez" initials="J." surname="Palet Martinez">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>The IPv6 Company</organization>
<address>
<postal>
<street>Molino de la Navata, 75</street>
<city>La Navata - Galapagar, Madrid</city>
<code>28420</code>
<country>Spain</country>
</postal>
<email>jordi.palet@theipv6company.com</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<author fullname="Gyan S. Mishra" initials="G." surname="Mishra">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>Verizon Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>gyan.s.mishra@verizon.com</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<author fullname="Chongfeng Xie" initials="C." surname="Xie">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>xiechf@chinatelecom.cn</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<date year="2022"/> <!-- month="March" is no longer necessary
note also, day="30" is optional -->
<!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for
you. If only the year is specified, xml2rfc will fill in the current day and month
irrespective of the day. This silliness should be fixed in v1.31. -->
<!-- Meta-data Declarations -->
<!-- Notice the use of & as an escape for & which would otherwise
start an entity declaration, whereas we want a literal &. -->
<area></area>
<!-- WG name at the upperleft corner of the doc,
IETF fine for individual submissions. You can also
omit this element in which case in defaults to "Network Working Group" -
a hangover from the ancient history of the IETF! --> month="April" year="2023"/>
<area/>
<workgroup>V6OPS</workgroup>
<!-- The DTD allows multiple area and workgroup elements but only the first one has any
effect on output. -->
<!-- You can add <keyword/> elements here. They will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff output. -->
<keyword>Survey</keyword>
<keyword>Challenges</keyword>
<keyword>IPv6-only</keyword>
<keyword>Overlay</keyword>
<keyword>Underlay</keyword>
<keyword>IPv4aaS</keyword>
<abstract>
<t>This document provides an overview of the status of IPv6 deployment status in 2022.
Specifically, it looks at the degree of adoption of IPv6 in the industry,
analyzes the remaining challenges challenges, and proposes further investigations in
areas where the industry has not yet taken a clear and unified
approach in the transition to IPv6. It obsoletes RFC 6036.</t>
</abstract>
</front>
<middle>
<section title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>
<t><xref target="RFC6036"></xref> described target="RFC6036" format="default"/> describes IPv6 deployment scenarios that were adopted or
foreseen by a number of Internet Service Providers (ISPs) who responded to a technical questionnaire
in early 2010. In doing that, 2010, and <xref target="RFC6036"></xref> provided target="RFC6036" format="default"/> also provides practices and plans that were expected
to take place in the following years.
Since the publication of <xref target="RFC6036"></xref>, target="RFC6036" format="default"/>, several other documents have contributed to
the IPv6 transition discussion in operational environments. To name a few:<list>
<t>- <xref target="RFC6180"></xref> discussed few:</t>
<ul spacing="normal">
<li><xref target="RFC6180" format="default"/> discusses IPv6 deployment models and transition mechanisms,
recommending those proven to be effective in operational networks.</t>
<t>- <xref target="RFC6883"></xref> provided networks.</li>
<li><xref target="RFC6883" format="default"/> provides guidance and suggestions for Internet content providers
and Application Service Providers (ASPs).</t>
<t>- <xref target="RFC7381"></xref> introduced (ASPs).</li>
<li><xref target="RFC7381" format="default"/> introduces the guidelines of IPv6 deployment for enterprises.</t>
</list></t> enterprises.</li>
</ul>
<t><xref target="RFC6540"></xref> recommended target="RFC6540" format="default"/> recommends the support of IPv6 to all IP-capable nodes.
It was referenced in the IAB Statement statement on IPv6 <xref target="IAB"/>, target="IAB" format="default"/>, which represented
a major step in driving the IETF as well as and other Standard Developing Standards Development Organizations (SDOs)
towards using IPv6 in their works.</t>
<t> In more recent times, organizations organizations, such as ETSI ETSI, provided more contributions to the use of IPv6 in operational
environments, targeting IPv6 in different industry segments. As a result, <xref target="ETSI-IP6-WhitePaper"/>, target="ETSI-IP6-WhitePaper" format="default"/>
was published to provide an updated view on the IPv6 best practices adopted so far, in particular particular, in the ISP domain. </t>
<t>Considering all of the above, and after more than ten years since the publication of <xref target="RFC6036"></xref> target="RFC6036" format="default"/>,
it is useful to assess the status of the transition to IPv6.
Some reasons include:<list>
<t>- In include:</t>
<ul spacing="normal">
<li>In some areas, the lack of IPv4 addresses forced both carriers and content providers to shift
to IPv6 to support the introduction of new applications, in particular particular, in wireless networks.</t>
<t>- Some networks.</li>
<li>Some governmental actions took place to encourage or even enforce the adoption of IPv6 in certain countries.</t>
<t>- Looking countries.</li>
<li>Looking at the global adoption of IPv6, this seems to have reached a threshold that justifies speaking of
end-to-end IPv6 connectivity, at least at the IPv6 service layer.</t>
</list></t> layer.</li>
</ul>
<t>This document aims to provide a survey of the status of IPv6 deployment and highlight both the
achievements and remaining obstacles in the transition to IPv6 networks (and its coexistence with continued IPv4 services).
The target is to give an updated view of the practices and plans already described in <xref target="RFC6036"></xref>, target="RFC6036" format="default"/>
to encourage further actions and more investigations in those areas that are still under discussion, discussion and to present
the main incentives for the adoption of IPv6.</t>
<t>This document is intended for a general audience interested to understand in understanding
the status of IPv6 in different industries
and network domains. People who provide or use network services may find it useful for the transition to IPv6.
Also, people developing plans for IPv6 adoption in an organization or in an industry may find information and
references for their analysis. Attention is given to the different stages of the transition to IPv6 networks and services.
In particular, a terminology on the use of “IPv6-only” "IPv6-only" is provided, considering IPv6-only networks and services as the
final stage of such transition.</t>
<t>The topics discussed in this document are organized into four main chapters.<list>
<t>Section 2 chapters.</t>
<ul spacing="normal">
<li><xref target="global_picture"/> reports data and analytics about the status of IPv6.</t>
<t>Section 3 IPv6.</li>
<li><xref target="survey"/> provides a survey of IPv6 deployments in different environments, including
ISPs, enterprises enterprises, and universities.</t>
<t>Section 4 universities.</li>
<li><xref target="deployment"/> describes the IPv6 deployment approaches for Mobile BroadBand Broadband (MBB),
Fixed BroadBand (FBB) Broadband (FBB), and Enterprises.</t>
<t>Section 5 enterprises.</li>
<li><xref target="challenges"/> analyzes the general challenges to be solved in the IPv6 transition.
Specific attention is given to operations, performance performance, and security issues.</t>
</list></t> issues.</li>
</ul>
<section anchor="terms" title="Terminology"> numbered="true" toc="default">
<name>Terminology</name>
<t>This section defines the terminology regarding the usage of IPv6-only expressions within this document.
The term IPv6-only is defined in relation to the specific scope it is referring to.
In this regard, it may happen that only part of a service, of a network network, or even part of a node is in an IPv6-only scope scope, and the rest is not.
Below are listed the
The most used terms in relation to the different scopes:<list>
<t>IPv6-only interface: It means that the scopes are listed below:</t>
<dl newline="true">
<dt>IPv6-only interface:</dt><dd> The interface of a node is configured to forward only IPv6.
This denotes that just part of the node can be IPv6-only since the rest of the interfaces of the same node may work with IPv4 as well.
A Dual-Stack interface is not an IPv6-only interface.</t>
<t>IPv6-only node: It means that the interface.</dd>
<dt>IPv6-only node:</dt><dd> The node uses only IPv6. All interfaces of the host only have IPv6 addresses.</t>
<t>IPv6-only service: addresses.</dd>
<dt>IPv6-only service:</dt><dd> It is used if if, between the host’s host's interface and the interface of the content server,
all packet headers of the service session are IPv6.</t>
<t>IPv6-only overlay: IPv6.</dd>
<dt>IPv6-only overlay:</dt><dd> It is used if if, between the end points of the tunnels, all inner packet headers of the tunnels are IPv6.
For example, IPv6-only overlay in a fixed network means that the encapsulation is only IPv6 between the interfaces of the Provider Edge (PE) nodes
or between the Customer Provider Edge (CPE) node and the Broadband Network Gateway (BNG).</t>
<t>IPv6-only underlay: (BNG).</dd>
<dt>IPv6-only underlay:</dt><dd> It is used if the data plane and control plane are IPv6, but this is not necessarily true for the management plane.
For example, IPv6-only underlay in a fixed network means that the underlay network protocol is only IPv6 between any Provider Edge (PE) nodes PE nodes,
but they can be Dual-Stack in overlay. SRv6 Segment Routing over IPv6 (SRv6) is an example of IPv6-only underlay.</t>
<t>IPv6-only network: underlay.</dd>
<dt>IPv6-only network:</dt><dd> It is used if every node in this network is IPv6-only. No IPv4 should not exist in an IPv6-only network.
In particular, an IPv6-only network’s network's data plane, control plane, and management plane must be IPv6.
All PEs must be IPv6-only. Therefore, if tunnels exist among PEs, both inner and outer headers must be IPv6.
For example, an IPv6-only access network means that every node in this access network must be IPv6-only IPv6-only, and similarly similarly, an
IPv6-only backbone network means that every nodes node in this backbone network must be IPv6-only.</t>
<t>IPv4 as a Service (IPv4aaS): It means that IPv4 IPv6-only.</dd>
<dt>IPv4-as-a-Service (IPv4aaS):</dt><dd>IPv4 service support is provided by means of a transition mechanism, therefore mechanism; therefore,
there is a combination of encapsulation/translation + IPv6-only underlay + decapsulation/translation.
For an IPv6-only network, connectivity to legacy IPv4 is either non-existent or provided by IPv4aaS mechanisms.</t>
</list></t> mechanisms.</dd>
</dl>
<t>Note that IPv6-only definitions are also discussed in <xref target="I-D.palet-v6ops-ipv6-only"/>.</t> target="I-D.palet-v6ops-ipv6-only" format="default"/>.</t>
</section>
</section>
<section title="IPv6: numbered="true" toc="default" anchor="global_picture">
<name>IPv6: The Global Picture"> Picture</name>
<t>This section deals with some key questions related to IPv6 IPv6, namely: (1) the status of IPv4 exhaustion, often considered as one
of the triggers to switch to IPv6, (2) the number of IPv6 end users, a primary measure to sense IPv6 adoption, (3) the percentage
of websites reachable over IPv6 IPv6, and (4) a report on IPv6 public actions and policies.</t>
<t>These parameters are monitored by the Regional internet Internet Registries (RIRs) and other institutions worldwide worldwide, as they provide a first-order
indication on the adoption of IPv6.</t>
<section title="IPv4 numbered="true" toc="default">
<name>IPv4 Address Exhaustion"> Exhaustion</name>
<t>According to <xref target="CAIR"/> target="CAIR" format="default"/>, there will be 29.3 billion networked devices by 2023, up from 18.4 billion in 2018.
This poses the question on about whether the IPv4 address space can sustain such a number of allocations and, consequently,
if this may affect the process of its exhaustion. The answer is not straightforward straightforward, as many aspects have to be considered.</t>
<t>On one hand, the RIRs are reporting scarcity of available and still reserved still-reserved addresses.
Table 3 of <xref target="POTAROO1"/> target="POTAROO1" format="default"/> (January 2022) shows that the available pool of the five RIRs at the end of 2021 counted
5.2 million IPv4 addresses, while the reserved pool included another 12 12.1 million, for a total of 17.3 million IPv4 addresses
(-5.5% year over year, comparing 2021 against 2020).
The same reference, in table 1,
Table 1 of <xref target="POTAROO1" format="default"/> shows that the total IPv4 allocated pool equaled to 3.685 billion addresses
(+0.027% year over year). The ratio between the available addresses and the total allocated was brought to 0.469% of the remaining
IPv4 address space (from 0.474% at the end of 2020).</t>
<t>On the other, other hand, <xref target="POTAROO1"/> target="POTAROO1" format="default"/> again highlights the role of both address transfer and Network Address Translation (NAT) to counter the IPv4 exhaustion.
The transfer of IPv4 addresses can be done under the control or registration of a an RIR or on the so-called grey market market, where third parties operate to
enable the buy/sell buying/selling of IPv4 addresses. In all cases, a set of IPv4 addresses is “transferred” "transferred" to a different holder that has the need to expand their address range.
As an example, <xref target="IGP-GT"/> target="IGP-GT" format="default"/> and <xref target="NRO"/> target="NRO" format="default"/> show the amount of transfers to recipient organizations in the different regions.
Cloud Service Providers (CSPs) appear to be the most active in buying IPv4 addresses to satisfy their need of providing IPv4 connectivity to their tenants.
NAT systems provide a means to absorb at least a portion of the demand of public IPv4 addresses addresses, as they enable the use of private addressing in internal networks
while limiting the use of public addresses on their WAN-facing side.
In the case of NAT, architectural and operational issues remain. Private address space cannot provide an adequate address span,
especially for large organizations, and the reuse of addresses may make the network more complex.
In addition, multiple levels of address translation may coexist in a network, e.g. e.g., Carrier-Grade NAT (CGN) <xref target="RFC6264"></xref> target="RFC6264" format="default"/>,
based on two stages of translation. This comes with an economic and operational burden, as discussed later in this document.</t>
<section title="IPv4 addresses numbered="true" toc="default">
<name>IPv4 Addresses per capita Capita and IPv6 status"> Status</name>
<t>The IPv4 addresses per capita ratio measures the quantity of IPv4 addresses allocated to a given country divided by the population of that country.
It provides an indication of the imbalanced distribution of the IPv4 addresses worldwide. It clearly derives from the allocation of addresses made in
the early days of the Internet.</t>
<t>The sources for measuring the IPv4 addresses per capita ratio are the allocations done by the RIRs and the statistics about the world population.
In this regard, <xref target="POTAROO2"/> target="POTAROO2" format="default"/> provides distribution files. The next tables compare the number of IPv4 addresses available per person
in a certain country (IPv4 address per capita) against the relative adoption of IPv6 in the same country (expressed as the number of IPv6 capable IPv6-capable users
in the considered country). The table shows just a subset of the data available from <xref target="POTAROO2"/>. target="POTAROO2" format="default"/>. In particular, the following table
provides the data for the 25 most populated countries in the world. The table is ordered based on the IPv4 addresses per capita ratio ratio, and the data refer
to the 1st of 1 January 2022.</t>
<figure anchor="table_1" title="IPv4
<table anchor="table_1">
<name>IPv4 per capita Capita and IPv6 deployment Deployment for the top Top 25 most populated countries Most Populated Countries in the world, 1st World (as of January 2022">
<artwork><![CDATA[
+----------------------------+---------------+---------------+
|Country |IPv4 2022)</name>
<thead>
<tr>
<th>Country</th>
<th>IPv4 per capita|IPv6 deployment|
+----------------------------+---------------+---------------+
|United Capita</th>
<th>IPv6 Deployment</th>
</tr>
</thead>
<tbody>
<tr>
<td>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 America</td>
<td>4.89</td>
<td>47.1%</td></tr><tr>
<td>United Kingdom</td>
<td>1.65</td>
<td>33.2%</td>
</tr><tr>
<td>Japan</td>
<td>1.50</td>
<td>36.7%</td>
</tr><tr>
<td>Germany</td>
<td>1.48</td>
<td>53.0%</td>
</tr><tr>
<td>France</td>
<td>1.27</td>
<td>42.1%</td>
</tr><tr>
<td>Italy</td>
<td>0.91</td>
<td>4.7%</td>
</tr><tr>
<td>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 </td>
<td>0.46</td>
<td>2.4%</td>
</tr><tr>
<td>Brazil</td>
<td>0.41</td>
<td>38.7%</td>
</tr><tr>
<td>Russian Federation</td>
<td>0.31</td>
<td>9.7%</td>
</tr><tr>
<td>China </td>
<td>0.24</td>
<td>60.1%(*)</td>
</tr><tr>
<td>Egypt</td>
<td>0.24</td>
<td>4.3%</td>
</tr><tr>
<td>Mexico</td>
<td>0.23</td>
<td>41.8%</td>
</tr><tr>
<td>Turkey</td>
<td>0.20</td>
<td>0.2%</td>
</tr><tr>
<td>Vietnam</td>
<td>0.17</td>
<td>48.0%</td>
</tr><tr>
<td>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)</td>
<td>0.15</td>
<td>0.1%</td>
</tr><tr>
<td>Thailand</td>
<td>0.13</td>
<td>40.8%</td>
</tr><tr>
<td>Indonesia</td>
<td>0.07</td>
<td>5.0%</td>
</tr><tr>
<td>Philippines</td>
<td>0.05</td>
<td>13.8%</td>
</tr><tr>
<td>India</td>
<td>0.03</td>
<td>76.9%</td>
</tr><tr>
<td>Pakistan</td>
<td>0.03</td>
<td>2.1%</td>
</tr><tr>
<td>United Republic of Tanzania | 0.02| 0.0%|
+----------------------------+---------------+---------------+
|Nigeria | 0.02| 0.2%|
+----------------------------+---------------+---------------+
|Bangladesh | 0.01| 0.3%|
+----------------------------+---------------+---------------+
|Ethiopia | 0.00| 0.0%|
+----------------------------+---------------+---------------+
|Democratic Tanzania</td>
<td>0.02</td>
<td>0.0%</td>
</tr><tr>
<td>Nigeria</td>
<td>0.02</td>
<td>0.2%</td>
</tr><tr>
<td>Bangladesh</td>
<td>0.01</td>
<td>0.3%</td>
</tr><tr>
<td>Ethiopia</td>
<td>0.00</td>
<td>0.0%</td>
</tr><tr>
<td>Democratic Republic of Congo| 0.00| 0.1%|
+----------------------------+---------------+---------------+
]]></artwork>
</figure> Congo</td>
<td>0.00</td>
<td>0.1%</td>
</tr>
</tbody>
</table>
<t>(*) The IPv6 deployment information in China is derived from <xref target="CN-IPv6"/>.</t> target="CN-IPv6" format="default"/>.</t>
<t>A direct correlation between low IPv4 per capita and high IPv6 adoption is not immediate, yet some indications emerge.
For example, countries some countries, such as Brazil, China, and India India, have clearly moved towards IPv6 adoption. As discussed later,
this appears related to several factors in addition to the lack of IPv4 addresses, including local regulation and
market-driven actions.
The 5 countries at the top of the table, with relative high availability of IPv4 addresses, have also shown a good level
of IPv6 adoption. In other cases, a relative scarcity of IPv4 addresses has not meant a clear move towards IPv6, as
several countries listed in the table still have low or very low IPv6 adoption.</t>
</section>
</section>
<section title="IPv6 Users"> numbered="true" toc="default">
<name>IPv6 Users</name>
<t>The count of the IPv6 users is the key parameter to get an immediate understanding of the adoption of IPv6.
Some organizations constantly track the usage of IPv6 by aggregating data from several sources. As an example,
the Internet Society constantly monitors the volume of IPv6 traffic for the networks that joined the WorldIPv6Launch World IPv6 Launch
initiative <xref target="WIPv6L"></xref>. target="WIPv6L" format="default"/>. The measurement aggregates statistics from organizations organizations, such as <xref target="Akm-stats"></xref> target="Akm-stats" format="default"/>,
that provides provide data down to the single network level level, measuring the number of hits to their content delivery platform.
For the scope of this document, the approach used by APNIC to quantify the adoption of IPv6 by means of a script that
runs on a user's device <xref target="CAIDA"></xref> target="CAIDA" format="default"/> is considered.
To give a rough estimation of the relative growth of IPv6, the next table aggregates the total number of estimated IPv6-capable users
at 1st
as of 1 January 2022, 2022 and compares it against the total Internet users, as measured by <xref target="POTAROO2"/>.</t>
<figure anchor="table_2" title="IPv6-capable users target="POTAROO2" format="default"/>.</t>
<table anchor="table_2">
<name>IPv6-Capable Users against total Total Users (in millions) Millions) as of 1st of January 2022">
<artwork><![CDATA[
+--------+--------+--------+--------+--------+--------+--------+
| | Jan | Jan | Jan | Jan | Jan | CAGR |
| | 2018 | 2019 | 2020 | 2021 | 2022 | |
+--------+--------+--------+--------+--------+--------+--------+
| IPv6 | 513.07| 574.02| 989.25|1,136.28|1,207.61| 23.9% |
+--------+--------+--------+--------+--------+--------+--------+
| World |3,410.27|3,470.36|4,065.00|4,091.62|4,093.69| 4.7% |
+--------+--------+--------+--------+--------+--------+--------+
| Ratio | 15.0%| 16.5%| 24.3%| 27.8%| 29.5%| 18.4% |
+--------+--------+--------+--------+--------+--------+--------+
]]></artwork>
</figure> 2022</name>
<thead>
<tr>
<th></th>
<th>Jan 2018</th>
<th>Jan 2019</th>
<th>Jan 2020</th>
<th>Jan 2021</th>
<th>Jan 2022</th>
<th>CAGR</th>
</tr>
</thead>
<tbody>
<tr>
<td>IPv6</td>
<td>513.07</td>
<td>574.02</td>
<td>989.25</td>
<td>1,136.28</td>
<td>1,207.61</td>
<td>23.9%</td>
</tr>
<tr>
<td>World</td>
<td>3,410.27</td>
<td>3,470.36</td>
<td>4,065.00</td>
<td>4,091.62</td>
<td>4,093.69</td>
<td>4.7%</td>
</tr>
<tr>
<td>Ratio</td>
<td>15.0%</td>
<td>16.5%</td>
<td>24.3%</td>
<td>27.8%</td>
<td>29.5%</td>
<td>18.4%</td>
</tr>
</tbody>
</table>
<t>Two figures appear: first, the IPv6 Internet population is growing with a two-digits two-digit Compound Annual Growth Rate (CAGR), and
second, the ratio IPv6 over total is also growing steadily.</t>
</section>
<section title="IPv6 numbered="true" toc="default">
<name>IPv6 Web Content"> Content</name>
<t><xref target="W3Techs"/> target="W3Techs" format="default"/> keeps track of the use of several technical components of websites worldwide through different analytical engines.
The utilization of IPv6 for websites is shown in the next table, where the percentages refer to the websites which that are accessible over IPv6.</t>
<figure anchor="table_3" title="Usage
<table anchor="table_3">
<name>Usage of IPv6 in websites, January 2022">
<artwork><![CDATA[
+------------+-------+-------+-------+-------+-------+------+
| 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%|
+------------+-------+-------+-------+-------+-------+------+
]]></artwork>
</figure> (as of January 2022)</name>
<thead>
<tr>
<th>Worldwide Websites</th>
<th>Jan 2018</th>
<th>Jan 2019</th>
<th>Jan 2020</th>
<th>Jan 2021</th>
<th>Jan 2022</th>
<th>CAGR</th>
</tr>
</thead>
<tbody>
<tr>
<td>% of IPv6</td>
<td>11.4%</td>
<td>13.3%</td>
<td>15.0%</td>
<td>17.5%</td>
<td>20.6%</td>
<td>15.9%</td>
</tr>
</tbody>
</table>
<t>Looking at the growth rate, it may appear not appear particularly high.
It has to be noted, though, that not all websites are equal. The largest content providers, which already
support IPv6, generate a lot more content than small websites.
<xref target="Csc6lab"/> measured at At the beginning of January 2022 2022,
<xref target="Csc6lab" format="default"/> measured that out of the world world's top 500 sites ranked by
<xref target="Alx"/>, sites, 203 are IPv6-enabled IPv6 enabled (+3.6% from January 2021 to January 2022).
If we consider that the big content providers (such as Google, Facebook, and Netflix) generate more than 50% of the total mobile traffic
<xref target="SNDVN"/>, target="SNDVN" format="default"/>, and in some cases even more up to 65% (<xref target="ISOC1"></xref> <xref target="HxBld"></xref>), target="ISOC1" format="default"/> <xref target="HxBld" format="default"/>, the percentage
of content accessible over IPv6 is clearly more relevant than the number of enabled IPv6 websites.
It Of that 50% of all mobile traffic,
it would be interesting to know what percentage of that 50% of all mobile traffic is IPv6. Unfortunately, this information is not available.</t>
<t>Related to that, a question that sometimes arises is whether the content stored by content providers would
be all accessible on IPv6 in the hypothetical case of a sudden IPv4 switch-off. switch off. Even if this is pure
speculation, the numbers above may bring to state that this is likely the case. This would reinforce the common thought that, in quantitative terms,
most of the content is accessible via IPv6.</t>
</section>
<section title="IPv6 public actions numbered="true" toc="default">
<name>IPv6 Public Actions and policies"> Policies</name>
<t>As previously noted, the worldwide deployment of IPv6 is not uniform <xref target="G_stats"></xref>, target="G_stats" format="default"/> <xref target="APNIC1"></xref>. target="APNIC1" format="default"/>.
It is worth noticing that, in some cases, higher IPv6 adoption in certain countries has been achieved as a consequence of actions taken by the local governments
through regulation or incentive to the market. Looking at the European Union area, countries some countries, such as Belgium, France France, and Germany Germany, are well ahead in terms of IPv6
adoption.</t>
<t>In the case of Belgium, the Belgian Institute for Postal services and Telecommunications (BIPT) acted to mediate an agreement between the local ISPs and
the government to limit the use of Carrier-Grade NAT (CGN) systems and of public IPv4 addresses for lawful investigations in 2012 <xref target="BIPT"></xref>. target="BIPT" format="default"/>.
The agreement limited the use of one IPv4 address per 16 customers behind NAT. The economic burden sustained by the ISPs for the unoptimized use of NAT induced
the shift to IPv6 and its increased adoption in the latest years.</t>
<t>In France, the National Regulator (Autoriteé (Autoritee de régulation regulation des communications électroniques, electroniques, or Arcep) introduced an obligation for the mobile carriers awarded
with a license to use 5G frequencies (3.4-3.8GHz) (3.4-3.8 GHz) in Metropolitan France to be IPv6 compatible <xref target="ARCEP"></xref>. target="ARCEP" format="default"/>.
As stated, "the stated in <xref target="ARCEP" format="default"/> (translated from French),
</t>
<blockquote>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". addresses. </blockquote>
<t>
A slow adoption of IPv6 could prevent new Internet services to widespread from spreading widely
or create a barrier to entry for newcomers to the market. Per <xref target="ARCEP" format="default"/> (translated from French), "IPv6 can help to increase competition in the telecom industry, and help to industrialize a country
for specific vertical sectors".</t>
<t>Increased IPv6 adoption in Germany depended on a mix of industry and public actions. Specifically, the Federal Office for Information Technology
(under the Federal Ministry of the Interior) issued over the years a few recommendations on the use of IPv6 in the German public administration.
The latest guideline in 2019 constitutes a high-level road map for mandatory IPv6 introduction in the federal administration networks <xref target="GFA"></xref>.</t> target="GFA" format="default"/>.</t>
<t>In the United States, the Office of Management and Budget is also calling for IPv6 adoption <xref target="US-FR"></xref>, target="US-FR" format="default"/> <xref target="US-CIO"></xref>. target="US-CIO" format="default"/>.
These documents define a plan to have the 80% of the US Federal federal IP-capable networks based on IPv6-only by the year 2025.
China is another example of a government which that is supporting a country-wide IPv6 adoption <xref target="CN"></xref>. target="CN" format="default"/>.
In India, the high adoption of IPv6 took origin from the decision of Reliance Jio to move to IPv6 in their networks <xref target="RelJio"></xref>. target="RelJio" format="default"/>.
In addition, the Department of Telecommunications (under the Ministry of Communications and Information Technology) issued guidelines for the
progressive adoption of IPv6 in public and private networks. The latest one dates 2021 <xref target="IDT"></xref> target="IDT" format="default"/> and fosters further moves to
IPv6 connection services.</t>
</section>
</section>
<section anchor="survey" title="A numbered="true" toc="default">
<name>A Survey on IPv6 Deployments"> Deployments</name>
<t>This section discusses the status of IPv6 adoption in service providers provider and enterprises’ enterprise networks.</t>
<section title="IPv6 Allocations"> numbered="true" toc="default">
<name>IPv6 Allocations</name>
<t>RIRs are responsible for allocating IPv6 address blocks to ISPs, LIRs (Local Local Internet Registries)
as well as Registries (LIRs), and
enterprises or other organizations. An ISP/LIR will use the allocated block to assign addresses to their end users.
The following table shows the amount of individual allocations, per RIR, in the time period from 2017-2021 <xref target="APNIC2"/>.</t>
<figure anchor="table_4" title="IPv6 allocations worldwide in the period 2017-2021 (January 2022)">
<artwork><![CDATA[
+---------+-------+-------+-------+-------+-------+---------+------+
| 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% |
+---------+-------+-------+-------+-------+-------+---------+------+
]]></artwork>
</figure> target="APNIC2" format="default"/>.</t>
<table anchor="table_4">
<name>IPv6 Allocations Worldwide (as of January 2022)</name>
<thead>
<tr>
<th>Registry</th>
<th>Dec 2017</th>
<th>Dec 2018</th>
<th>Dec 2019</th>
<th>Dec 2020</th>
<th>Dec 2021</th>
<th>Cumulated</th>
<th>CAGR</th>
</tr>
</thead>
<tbody>
<tr>
<td>AFRINIC</td>
<td>112</td>
<td>110</td>
<td>115</td>
<td>109</td>
<td>136</td>
<td>582</td>
<td>51%</td>
</tr>
<tr>
<td>APNIC</td>
<td>1,369</td>
<td>1,474</td>
<td>1,484</td>
<td>1,498</td>
<td>1,392</td>
<td>7,217</td>
<td>52%</td>
</tr>
<tr>
<td>ARIN</td>
<td>684</td>
<td>659</td>
<td>605</td>
<td>644</td>
<td>671</td>
<td>3,263</td>
<td>48%</td>
</tr>
<tr>
<td>LACNIC</td>
<td>1,549</td>
<td>1,448</td>
<td>1,614</td>
<td>1,801</td>
<td>730</td>
<td>7,142</td>
<td>47%</td>
</tr>
<tr>
<td>RIPE NCC</td>
<td>2,051</td>
<td>2,620</td>
<td>3,104</td>
<td>1,403</td>
<td>2,542</td>
<td>11,720</td>
<td>55%</td>
</tr>
<tr>
<td>Total</td>
<td>5,765</td>
<td>6,311</td>
<td>6,922</td>
<td>5,455</td>
<td>5,471</td>
<td>29,924</td>
<td>51%</td>
</tr>
</tbody>
</table>
<t>The trend shows the steady progress of IPv6.
The decline of IPv6 allocations in 2020 and 2021 may be due to the COVID-19 pandemic. It also happens happened to IPv4 allocations.</t>
<t><xref target="APNIC2"/> target="APNIC2" format="default"/> also compares the number of allocations for both address families.
The CAGR looks quite similar in 2021 but a little higher for the IPv4 allocations in comparison to the IPv6 allocations
(53.6% versus 50.9%).</t>
<figure anchor="table_5" title="Allocations
<table anchor="table_5">
<name>Allocations per address family">
<artwork><![CDATA[
+--------+-------+-------+-------+-------+-------+----------+------+
| 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%|
| | | | | | | | |
+--------+-------+-------+-------+-------+-------+----------+------+
]]></artwork>
</figure> Address Family (as of January 2022)</name>
<thead>
<tr>
<th>Address family</th>
<th>Dec 2017</th>
<th>Dec 2018</th>
<th>Dec 2019</th>
<th>Dec 2020</th>
<th>Dec 2021</th>
<th>Cumulated</th>
<th>CAGR</th>
</tr>
</thead>
<tbody>
<tr>
<td>IPv6</td>
<td>5,765</td>
<td>6,311</td>
<td>6,922</td>
<td>5,455</td>
<td>5,471</td>
<td>29,924</td>
<td>50.9%</td>
</tr>
<tr>
<td>IPv4</td>
<td>8,091</td>
<td>9,707</td>
<td>13,112</td>
<td>6,263</td>
<td>7,829</td>
<td>45,002</td>
<td>53.6%</td>
</tr>
</tbody>
</table>
<t>The reason may be that the IPv4 allocations in 2021 include included many allocations of small address ranges (e.g. (e.g., /24) <xref target="APNIC2"/>. target="APNIC2" format="default"/>.
On the contrary, a single IPv6 allocation is large enough to cope with the need of an operator for long period.
After an operator receives an IPv6 /30 or /32 allocation allocation, it is unlikely that a new request of addresses is repeated in the short term.</t>
<t>The next table is based on <xref target="APNIC3"/>, target="APNIC3" format="default"/> and <xref target="APNIC4"/> target="APNIC4" format="default"/> and shows the percentage of Autonomous
Systems (AS) (ASes) supporting IPv6 compared to the total ASes worldwide.
The number of IPv6-capable ASes increased from 24.3% in January 2018 to 38.7% in January 2022.
This equals to 18% of the CAGR for IPv6-enabled networks. In comparison, the CAGR for the total of IPv6 and IPv4 networks is just 5%.</t>
<figure anchor="table_6" title="Percentage
<table anchor="table_6">
<name>Percentage of IPv6-capable ASes">
<artwork><![CDATA[
+------------+-------+-------+-------+-------+-------+------+
| 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% | |
+------------+-------+-------+-------+-------+-------+------+
]]></artwork>
</figure> IPv6-Capable ASes (as of January 2022)</name>
<thead>
<tr>
<th>Advertised ASN</th>
<th>Jan 2018</th>
<th>Jan 2019</th>
<th>Jan 2020</th>
<th>Jan 2021</th>
<th>Jan 2022</th>
<th>CAGR</th>
</tr>
</thead>
<tbody>
<tr>
<td>IPv6-capable</td>
<td>14,500</td>
<td>16,470</td>
<td>18,650</td>
<td>21,400</td>
<td>28,140</td>
<td>18%</td>
</tr>
<tr>
<td>Total ASN</td>
<td>59,700</td>
<td>63,100</td>
<td>66,800</td>
<td>70,400</td>
<td>72,800</td>
<td>5%</td>
</tr>
<tr>
<td>Ratio</td>
<td>24.3%</td>
<td>26.1%</td>
<td>27.9%</td>
<td>30.4%</td>
<td>38.7%</td>
<td></td>
</tr>
</tbody>
</table>
<t>The tables above provide an aggregated view of the allocations allocations' dynamic.
The next subsections will zoom into each specific domain to highlight its relative status.</t>
</section>
<section title="IPv6 numbered="true" toc="default" anchor="ISPs">
<name>IPv6 among Internet Service Providers">
<t>As it was proposed at the time of <xref target="RFC6036"></xref>, also in the case of this document a Providers</name>
<t>A survey was submitted to
a group of service providers in Europe during the third quarter of 2020 (see <xref target="Appendix_A"></xref> target="Appendix_A" format="default"/> for the complete poll), poll)
to understand their plans about IPv6 and their technical preferences towards regarding its adoption.
Although such this poll does not give an exhaustive view on the IPv6 status, it provides some insights
that are relevant to the discussion.</t>
<t> The poll revealed that the majority of the ISPs interviewed had plans concerning IPv6 (79%).
Of them, 60% had already ongoing activities, activities already, while 33% was were expected to start activities
in a 12-months time-frame. 12-month timeframe. The transition to IPv6 involved all business segments:
mobile (63%), fixed (63%), and enterprises enterprise (50%).</t>
<t>The reasons to move to IPv6 varied.
Global IPv4 address depletion and the run out of private address space recommended in <xref target="RFC1918"></xref> target="RFC1918" format="default"/>
were reported as the important drivers for IPv6 deployment (48%).
In a few cases, respondents cited the requirement of national IPv6 policies and the launch of 5G as the reasons (13%).
Enterprise customers customer demand was also a reason to introduce IPv6 (13%).</t>
<t>From a technical preference standpoint, Dual-Stack <xref target="RFC4213"></xref> target="RFC4213" format="default"/> was the most adopted solution, solution
in both wireline (59%) and cellular networks (39%). In wireline, the second most adopted mechanism was Dual-Stack Lite (DS-Lite)
<xref target="RFC6333"></xref> target="RFC6333" format="default"/> (19%). In cellular networks, the second preference was 464XLAT <xref target="RFC6877"></xref> target="RFC6877" format="default"/> (21%).</t>
<t>More details about the answers received can be found in <xref target="Appendix_A"></xref>.</t> target="Appendix_A" format="default"/>.</t>
</section>
<section title="IPv6 numbered="true" toc="default">
<name>IPv6 among Enterprises"> Enterprises</name>
<t>As described in <xref target="RFC7381"></xref>, target="RFC7381" format="default"/>, enterprises face different challenges than ISPs.
Publicly available reports show how the enterprise deployment of IPv6 lags behind ISP deployment
<xref target="cmpwr"></xref>.</t> target="cmpwr" format="default"/>.</t>
<t><xref target="NST_1"></xref> target="NST_1" format="default"/> provides estimations on the deployment status of IPv6 for domains
such as example.com, example.net example.net, or example.org in the United States.
The measurement encompasses many industries, including telecommunications, so the term "enterprises"
is a bit loose in this context. In any case, it provides a first indication of IPv6 adoption in several
US industry sectors.
The analysis tries to infer whether IPv6 is supported by looking from "outside" a company's network. It
takes into consideration the support of IPv6 to external services services, such as Domain Name System (DNS),
mail
mail, and website. websites. <xref target="BGR_1"></xref> target="BGR_1" format="default"/> has similar data for China China, while <xref target="CNLABS_1"></xref> target="CNLABS_1" format="default"/>
provides the status in India.</t>
<figure anchor="table_7" title="IPv6 support
<table anchor="table_7">
<name>IPv6 Support for external-facing services External-Facing Services across enterprises (January 2022)">
<artwork><![CDATA[
+--------------+----------+---------+---------+---------+
|Country | Domains | DNS | Mail | Website |
| | analyzed | | | |
+--------------+----------+---------+---------+---------+
|China | 478 | 74.7% | 0.0% | 19.7% |
| | | | | |
+--------------+----------+---------+---------+---------+
|India | 104 | 51.9% | 15.4% | 16.3% |
| | | | | |
+--------------+----------+---------+---------+---------+
|United Enterprises (as of January 2022)</name>
<thead>
<tr>
<th>Country</th>
<th>Domains analyzed</th>
<th>DNS</th>
<th>Mail</th>
<th>Website</th>
</tr>
</thead>
<tbody>
<tr>
<td>China</td>
<td>478</td>
<td>74.7%</td>
<td>0.0%</td>
<td>19.7%</td>
</tr>
<tr>
<td>India</td>
<td>104</td>
<td>51.9%</td>
<td>15.4%</td>
<td>16.3%</td>
</tr>
<tr>
<td>United States | 1070 | 66.8% | 21.2% | 6.3% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
]]></artwork>
</figure> of America</td>
<td>1070</td>
<td>66.8%</td>
<td>21.2%</td>
<td>6.3%</td>
</tr>
</tbody>
</table>
<t>A poll submitted to a group of large enterprises in North America in early 2021 (see <xref target="Appendix_B"></xref>) target="Appendix_B" format="default"/>)
shows that the operational issues are even more critical than for ISPs.</t>
<t>Looking at current implementations, almost one third has dual-stacked networks, while 20% declares that
portions of their networks are IPv6-only.
Additionally, 35% of the enterprises did not implement IPv6 at all or are stuck at the training phase.
In no case is the network fully IPv6-based.</t> based on IPv6.</t>
<t>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 address planning / network configurations (57.41%).</t>
<t>Coming to implementation, the three areas of concern are IPv6 security (31.48%), training (27.78%), and
application conversion (25.93%). (25.93%), and 33.33% of respondents think that all three areas are
all simultaneously of concern.</t>
<t>The full poll is reported in <xref target="Appendix_B"></xref>.</t> target="Appendix_B" format="default"/>.</t>
<section title="Government numbered="true" toc="default">
<name>Government and Universities"> Universities</name>
<t>This section focuses specifically on the IPv6 adoption of IPv6 in governments and academia.</t>
<t>As far as governmental agencies are concerned, <xref target="NST_2"></xref> target="NST_2" format="default"/> provides analytics on
the degree of IPv6 support for DNS, mail mail, and websites across second level second-level domains associated with the US federal agencies.
These domains are in the form of example.gov or example.fed. The script used by <xref target="NST_2"></xref> target="NST_2" format="default"/> has also been employed
to measure the same analytics in other countries: countries, e.g., China <xref target="BGR_2"></xref>, target="BGR_2" format="default"/>, India <xref target="CNLABS_2"></xref> target="CNLABS_2" format="default"/>,
and the European Union <xref target="IPv6Forum"></xref>. target="IPv6Forum" format="default"/>. For this latter analytic analytic, some post-processing is necessary to filter out
the non-European domains.</t>
<figure anchor="table_8" title="IPv6 support
<table anchor="table_8">
<name>IPv6 Support for external-facing services External-Facing Services across governmental institutions (January 2022)">
<artwork><![CDATA[
+--------------+----------+---------+---------+---------+
|Country | Domains | DNS | Mail | Website |
| | analyzed | | | |
+--------------+----------+---------+---------+---------+
|China | 52 | 0.0% | 0.0% | 98.1% |
| | | | | |
+--------------+----------+---------+---------+---------+
|European | 19 | 47.4% | 0.0% | 21.1% |
|Union (*) | | | | |
+--------------+----------+---------+---------+---------+
|India | 618 | 7.6% | 6.5% | 7.1% |
| | | | | |
+--------------+----------+---------+---------+---------+
|United Governmental Institutions (as of January 2022)</name>
<thead>
<tr>
<th>Country</th>
<th>Domains analyzed</th>
<th>DNS</th>
<th>Mail</th>
<th>Website</th>
</tr>
</thead>
<tbody>
<tr>
<td>China</td>
<td>52</td>
<td>0.0%</td>
<td>0.0%</td>
<td>98.1%</td>
</tr>
<tr>
<td>European Union (*)</td>
<td>19</td>
<td>47.4%</td>
<td>0.0%</td>
<td>21.1%</td>
</tr>
<tr>
<td>India</td>
<td>618</td>
<td>7.6%</td>
<td>6.5%</td>
<td>7.1%</td>
</tr>
<tr>
<td>United States | 1283 | 87.1% | 14.0% | 51.7% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
]]></artwork>
</figure> of America</td>
<td>1283</td>
<td>87.1%</td>
<td>14.0%</td>
<td>51.7%</td>
</tr>
</tbody>
</table>
<t>(*) Both EU and country specific country-specific domains are considered.</t>
<t>USA's IPv6
<t>IPv6 support in the US is higher than other countries. This is likely due to the IPv6 mandate set by <xref target="US-CIO"></xref>. target="US-CIO" format="default"/>.
In the case of India, the degree of support seems still quite low. This is also true for China,
with the notable exception of a high percentage of IPv6-enabled websites for government-related organizations.</t>
<t>Similar statistics are also available for higher education. <xref target="NST_3"></xref> target="NST_3" format="default"/> measures the data from second level second-level domains
of universities in the US, such as example.edu. <xref target="BGR_3"></xref> target="BGR_3" format="default"/> looks at Chinese education-related domains.
<xref target="CNLABS_1"></xref> target="CNLABS_1" format="default"/> analyzes domains in India (mostly third level), while <xref target="IPv6Forum"></xref> target="IPv6Forum" format="default"/> lists universities
in the European Union (second level), again after filtering the non-European domains.</t>
<figure anchor="table_9" title="IPv6 support
<table anchor="table_9">
<name>IPv6 Support for external-facing services External-Facing Services across universities (January 2022)">
<artwork><![CDATA[
+--------------+----------+---------+---------+---------+
|Country | Domains | DNS | Mail | Website |
| | analyzed | | | |
+--------------+----------+---------+---------+---------+
|China | 111 | 36.9% | 0.0% | 77.5% |
| | | | | |
+--------------+----------+---------+---------+---------+
|European | 118 | 83.9% | 43.2% | 35.6% |
|Union | | | | |
+--------------+----------+---------+---------+---------+
|India | 100 | 31.0% | 54.0% | 5.0% |
| | | | | |
+--------------+----------+---------+---------+---------+
|United Universities (as of January 2022)</name>
<thead>
<tr>
<th>Country</th>
<th>Domains analyzed</th>
<th>DNS</th>
<th>Mail</th>
<th>Website</th>
</tr>
</thead>
<tbody>
<tr>
<td>China</td>
<td>111</td>
<td>36.9%</td>
<td>0.0%</td>
<td>77.5%</td>
</tr>
<tr>
<td>European Union</td>
<td>118</td>
<td>83.9%</td>
<td>43.2%</td>
<td>35.6%</td>
</tr>
<tr>
<td>India</td>
<td>100</td>
<td>31.0%</td>
<td>54.0%</td>
<td>5.0%</td>
</tr>
<tr>
<td>United States | 346 | 49.1% | 19.4% | 21.7% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
]]></artwork>
</figure> of America</td>
<td>346</td>
<td>49.1%</td>
<td>19.4%</td>
<td>21.7%</td>
</tr>
</tbody>
</table>
<t>Overall, the universities have wider support of IPv6-based services compared to the other sectors.
Apart from a couple of exceptions (e.g. (e.g., the support of IPv6 mail in China and IPv6 websites in India),
the numbers shown in the table above indicate a good support of IPv6 in academia.</t>
</section>
</section>
</section>
<section title="IPv6 deployment scenarios"> numbered="true" toc="default" anchor="deployment">
<name>IPv6 Deployment Scenarios</name>
<t>The scope of this section is to discuss the network and service scenarios applicable for the transition to IPv6.
Most of the related definitions have been provided in <xref target="terms"/>. target="terms" format="default"/>. This clause is intended to focus on the technical and operational characteristics.
The sequence of scenarios described here does not have necessarily have to be intended as a road map for the IPv6 transition.
Depending on their specific plans and requirements, service providers may either adopt the scenarios proposed in a sequence or jump directly to a specific one.</t>
<section title="Dual-Stack"> numbered="true" toc="default">
<name>Dual-Stack</name>
<t>Based on the poll answers provided by network operators to the poll (<xref target="Appendix_A"></xref>), target="Appendix_A" format="default"/>), Dual-Stack <xref target="RFC4213"></xref> target="RFC4213" format="default"/>
appears to be currently the most widely deployed IPv6 solution (about 50%, 50%; see both <xref target="Appendix_A"></xref> target="Appendix_A" format="default"/> and
the statistics reported in <xref target="ETSI-IP6-WhitePaper"/>).</t> target="ETSI-IP6-WhitePaper" format="default"/>).</t>
<t>With Dual-Stack, IPv6 can be introduced together with other network upgrades upgrades, and many parts of network management
and IT systems can still work in IPv4. This avoids a major upgrade of such systems to support IPv6, which is possibly
the most difficult task in the IPv6 transition. The cost and effort on the network management and IT systems upgrade
are moderate. The benefits are to start using IPv6 and save NAT costs.</t>
<t>Although Dual-Stack may provide advantages in the introductory stage, it does have a few disadvantages in the long run,
like the duplication of the network resources and states. It also requires more IPv4 addresses, thus increasing both Capital Expenses (CAPEX)
and Operating Expenses (OPEX). For example, even if private addresses are used with Carrier-Grade NAT (CGN), there is extra investment in the CGN devices,
logs storage storage, and help-desk help desk to track CGN-related issues.</t>
<t>For this reason, when IPv6 usage exceeds a certain threshold, it may be advantageous to start a transition to a the next scenario.
For example, the process may start with the IPv4aaS stage, as described hereinafter.
It is difficult to establish the criterion for switching (e.g. (e.g., to properly identify the upper bound of the IPv4 decrease or the
lower bound of the IPv6 increase). In addition to the technical factors, the switch to the next scenarios may also cause a loss of customers.
Based on the feedback of network operators participating in the World IPv6 Launch <xref target="WIPv6L"></xref> target="WIPv6L" format="default"/> in June 2021, 108 out of 346 operators
exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%), while 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%.</t>
</section>
<section title="IPv6-only Overlay"> numbered="true" toc="default">
<name>IPv6-Only Overlay</name>
<t>As defined in <xref target="terms"/>, target="terms" format="default"/>, IPv6-only is generally associated with a scope, e.g. e.g., IPv6-only overlay or IPv6-only underlay.</t>
<t>The IPv6-only overlay denotes that the overlay tunnel between the end points of a network is based only on IPv6.
Tunneling provides a way to use an existing IPv4 infrastructure to carry IPv6 traffic. IPv6 or IPv4 hosts and routers
can tunnel IPv6 packets over IPv4 regions by encapsulating them within IPv4 packets. The approach with IPv6-only overlay helps
to maintain compatibility with the existing base of IPv4, but it is not a long-term solution.</t>
<t>As a matter of fact, IPv4 reachability must be provided for a long time to come over IPv6 for IPv6-only hosts. Most ISPs are leveraging
CGN to extend the life of IPv4 instead of going with IPv6-only solutions.</t>
</section>
<section title="IPv6-only Underlay">
<t>IPv6-only numbered="true" toc="default">
<name>IPv6-Only Underlay</name>
<t>The IPv6-only underlay network uses IPv6 as the network protocol for all traffic delivery. Both the control and data planes are IPv6-based. based on IPv6.
The definition of IPv6-only underlay needs to be associated with a scope in order to identify the domain where it is applicable,
such as the IPv6-only access network or IPv6-only backbone network.</t>
<t>When both enterprises and service providers begin to transit transition from an IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not necessarily
need to dual-stack Dual-Stack the underlay.
Forwarding plane complexity on the Provider (P) nodes of
the ISP core should be kept simple as a backbone with a
single protocol only backbone. protocol.
Hence, when operators
decide to transit transition to an IPv6 underlay, the ISP backbone should be
IPv6-only while because Dual-Stack is not the best choice.
The underlay
could be IPv6-only and allows allow IPv4 packets to be tunneled using a VPN
over an IPv6-only backbone and while leveraging <xref target="RFC8950"></xref>, target="RFC8950" format="default"/>, which specifies
the extensions necessary to allow advertising IPv4 Network Layer Routing
Reachability Information (NLRI) with an IPv6 Next Hop.</t> next hop.</t>
<t>IPv6-only underlay network deployment for access and backbone network, networks seems to not be the first option option, and the current trend is to keep the IPv4/MPLS Data Plane data plane
and run IPv4/IPv6 Dual-Stack to edge nodes.</t>
<t>As ISPs do the transition in the future to an IPv6-only access network or backbone network, e.g. e.g., Segment Routing over IPv6 (SRv6) data plane (SRv6), plane, they start
the elimination of IPv4 from the underlay transport network while continuing to provide IPv4 services. Basically, as also showed shown by the poll among network operators,
from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network per reasons mentioned above related to the forwarding plane
complexities.</t>
</section>
<section title="IPv4 as a Service"> numbered="true" toc="default">
<name>IPv4-as-a-Service</name>
<t>IPv4aaS can be used to ensure IPv4 support support, and it can be a complex decision that depends on several factors, such as economic aspects, policy policy, and government
regulation.</t>
<t><xref target="RFC9313"/> target="RFC9313" format="default"/> compares the merits of the most common transition solutions for IPv4aaS, i.e. i.e., 464XLAT <xref target="RFC6877"></xref>,
DS-lite target="RFC6877" format="default"/>,
DS-Lite <xref target="RFC6333"></xref>, target="RFC6333" format="default"/>, Lightweight 4over6 (lw4o6) <xref target="RFC7596"></xref>, MAP-E target="RFC7596" format="default"/>, Mapping of Address and Port with Encapsulation (MAP-E) <xref target="RFC7597"></xref>, target="RFC7597" format="default"/>, and
MAP-T
Mapping of Address and Port using Translation (MAP-T) <xref target="RFC7599"></xref>, target="RFC7599" format="default"/>, but does not provide an explicit recommendation.
However, the poll in <xref target="Appendix_A"></xref> target="Appendix_A" format="default"/> indicates that the most widely deployed IPv6 transition solution in the Mobile Broadband (MBB) domain
is 464XLAT 464XLAT, while in the Fixed Broadband (FBB) domain domain, it is DS-Lite.</t>
<t>Both are IPv4aaS solutions by leveraging that leverage IPv6-only underlay. IPv4aaS offers Dual-Stack service to users and allows an ISP
to run IPv6-only in the network, typically the access network.</t>
<t>While it may not always be the case, IPv6-only transition technologies technologies, such as 464XLAT 464XLAT, require far fewer IPv4 addresses
<xref target="RFC9313"/>, target="RFC9313" format="default"/>, because they make a are more efficient usage without restricting 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 block listing of IPv4 address blocks
when used via CGN in some services.</t>
<t>IPv4aaS may be facilitated by the natural upgrade or replacement of CPEs because of newer technologies (tripe-play, (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 example, CGN and associated logs)
due to the operational simplification of the network.</t>
<t>For deployments with a large number of users (e.g. (e.g., large mobile operators) or a large number of hosts (e.g. (e.g., large DCs), Data Centers (DCs)), even the full private address space
<xref target="RFC1918"></xref> target="RFC1918" format="default"/> 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 that, for scenarios such as MBB or large DCs, IPv4aaS
could be more efficient from the start of the IPv6 introduction.</t>
<t>So, in general, when the Dual-Stack disadvantages outweigh the IPv6-only complexity, it makes sense to transit transition to IPv4aaS.
Some network operators have already started this process, as in the case of <xref target="TMus"></xref>, target="TMus" format="default"/>, <xref target="RelJio"></xref> target="RelJio" format="default"/>, and <xref target="EE"></xref>.</t> target="EE" format="default"/>.</t>
</section>
<section title="IPv6-only"> numbered="true" toc="default">
<name>IPv6-Only</name>
<t>IPv6-only is the final stage of the IPv6 transition transition, and it happens when a complete network, end-to-end, end to end, no longer has IPv4.
No IPv4 address is configured for network management or anything.</t> anything else.</t>
<t>Since IPv6-only means that both underlay network networks and overlay services are only IPv6, it will take longer to happen.</t>
</section>
</section>
<section title="Common numbered="true" toc="default" anchor="challenges">
<name>Common IPv6 Challenges"> Challenges</name>
<t>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 well proven in production, there are some challenges to consider.
In this regard, it is worth noting that <xref target="ETSI-GR-IPE-001"></xref> target="ETSI-GR-IPE-001" format="default"/> also discusses gaps that still exist in IPv6 related IPv6-related use cases.</t>
<section title="Transition Choices"> numbered="true" toc="default">
<name>Transition Choices</name>
<t>A service provider, an enterprise enterprise, or a CSP may perceive quite a complex task with the transition to IPv6, 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 operations, and
the deployment strategy.</t>
<t>This section
<t>The subsections below briefly highlights highlight the approaches that the different parties may take and the related challenges.</t>
<section title="Service Providers"> numbered="true" toc="default">
<name>Service Providers: Fixed and Mobile Operators</name>
<t>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% <xref target="G_stats"></xref>. target="G_stats" format="default"/>.
As highlighted in section 3.2, <xref target="ISPs"/>, all major content providers have already implemented Dual-Stack access to their services 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 factors, like the current IPv4 address shortage, CPE costs, CGN costs costs, and so on.<list>
<t>Fixed Operators on.</t>
<ul empty="false" spacing="normal">
<li>Fixed operators with a Dual-Stack architecture, architecture can start defining and apply 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.</t>
<t>Most approach.</li>
<li>Most of the fixed operators remain attached to a Dual-Stack architecture architecture, and many have already employed CGN. In this case 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.</t>
</list></t> scenario.</li>
</ul>
<t>For mobile operators, the situation is quite different since, 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.<list>
<t>Some available.</t>
<ul empty="false" spacing="normal">
<li>Some mobile operators choose to implement Dual-Stack as a first and immediate mitigation solution.</t>
<t>Other solution.</li>
<li>Other mobile operators prefer to move to IPv4aaS solutions (e.g. (e.g., 464XLAT) since Dual-Stack only mitigates and does not solve completely the
IPv4 address scarcity issue.</t>
</list></t> issue completely.</li>
</ul>
<t>For both fixed and mobile operators operators, the approach for the transition is not unique unique, and this brings different challenges in relation to the
network architecture and related costs. So costs; therefore, each operator needs to do their own evaluations for the transition based on the specific situation.</t>
</section>
<section title="Enterprises"> numbered="true" toc="default">
<name>Enterprises</name>
<t>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 enterprises' internal infrastructure, 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 policy, policies, all the enterprises providing consulting service services to governments are also required to support IPv6.</t>
<t>However, enterprises face some challenges. They are shielded from IPv4 address depletion issues due to their prevalent use of Proxy proxy and private addressing
<xref target="RFC1918"></xref>, thus target="RFC1918" format="default"/>; thus, they do not have the business requirement or technical justification to transit transition to IPv6. Enterprises need to find a business case
and a strong motivation for IPv6 to transition to IPv6 to justify additional CAPEX and OPEX. Also, since Information and Communication Technologies (ICT) is (ICTs) are not the core business
for most of the enterprises, the ICT budget is often constrained and cannot expand considerably.
But,
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
which
that require IPv6 network architecture.</t>
<t>Enterprises worldwide, in particular small small- and medium-sized, 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 IPv6, and the problem of application porting to IPv6 looks quite difficult.
As highlighted in the relevant poll, the technicians may need to get trained be trained, but the management do 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 <xref target="ARIN-CG"></xref> target="ARIN-CG" format="default"/>
<xref target="ISIF-ASIA-G"></xref>.</t> target="ISIF-ASIA-G" format="default"/>.</t>
</section>
<section title="Industrial Internet"> numbered="true" toc="default">
<name>Industrial Internet</name>
<t>In an industrial environment, OT (Operational technology) Operational Technology (OT) refers to the systems used to monitor and control
processes within a factory or production environment, while IT (Information technology) 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 evolution.</t> IT.</t>
<t>There are potential advantages for using IPv6 for the Industrial Internet of Things (IIoT), in particular particular, the large IPv6 address space,
the automatic IPv6 address configuration configuration, and resource discovery. However, its industrial adoption, in particular 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 configuration, and the poor knowledge of the IPv6 protocols.
To promote the use of IPv6 for smart manufacturing systems and IIoT applications 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.</t>
<t>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. real time.
The limitation is that manufacturing companies have diverse corporate cultures cultures, and the adoption of new technologies may lag as a result.</t>
<t>For Industrial Internet and related IIoT applications, it would be desirable to leverage the configuration-less 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 IP-based communication and
standard application protocols at every point in the production process and further reduce the use of specialized communication systems.</t>
</section>
<section anchor="cloud-dcs" title="Content numbered="true" toc="default">
<name>Content and Cloud Service Providers"> Providers</name>
<t>The high number of addresses required to connect the virtual and physical elements in a Data Center and the necessity to overcome the limitation posed
by <xref target="RFC1918"></xref> target="RFC1918" format="default"/> have been the drivers to the adoption of IPv6 in several CSP networks.</t>
<t>Most CSPs have adopted IPv6 in their internal infrastructure but are also active in gathering IPv4 addresses on the transfer market to serve the
current business needs of IPv4 connectivity. As noted in the previous section, most enterprises do not consider the transition to IPv6 as a priority.
To this extent, the use of IPv4-based network services by the CSPs will last.</t>
<t>Several public references, as reported hereinafter, discuss how most of the major players find themselves at different stages
in the transition to IPv6-only in their Data Center (DC) infrastructure.
In some cases, the transition already happened and the DC infrastructure of these hyperscalers is completely based on IPv6.</t>
<t>It is interesting to look at how much traffic in a network is going to Caches and Content Delivery Networks (CDNs). The response is expected to be
a high percentage, at least higher than 50% in most of the cases, since all the key Caches and CDNs are IPv6-ready <xref target="Cldflr"></xref>, ready for IPv6 <xref target="Ggl"></xref>, target="Cldflr" format="default"/>
<xref target="Ntflx"></xref>, target="Ggl" format="default"/> <xref target="Amzn"></xref>, target="Ntflx" format="default"/> <xref target="Mcrsft"></xref>, target="Amzn" format="default"/> <xref target="Vrzn"></xref>. target="Mcrsft" format="default"/>. So the percentage of traffic going to the key Caches/CDNs is a good approximation of the potential IPv6 traffic in a network.</t>
<t>The challenges for CSPs are mainly related to the continuous support of IPv4 to be guaranteed, since most CSPs already completed the transition to IPv6-only.
If, in the next years, the scarcity of IPv4 addresses becomes more evident, it is likely that the cost of buying an IPv4 address by a CSP could be charged
to their customers.</t>
</section>
<section title="CPEs numbered="true" toc="default">
<name>CPEs and user devices"> User Devices</name>
<t>It can be noted that most of the user devices (e.g. (e.g., smartphones) are already IPv6-enabled since have been IPv6 enabled for many years. But there are exceptions, for example, smartTVs for the past few years, smart TVs
have typically had IPv6 support since few years ago, however support; however, not all the economies replace them at the same pace.</t>
<t>As already mentioned, ISPs who historically provided public IPv4 addresses to their customers generally still have those IPv4 addresses (unless they chose to
transfer them). Some have chosen to put new customers on CGN but without touching existing customers. Because of the extreme extremely small number of customers who notice
that IPv4 is done via NAT444 (i.e. (i.e., the preferred CGN solution for carriers), it could be less likely to run out of IPv4 addresses and private IPv4 space. But as IPv4-only devices and traffic reduce, then the need to support private and public IPv4 become less. lessens.
So the complete support of CPEs to have CPEs completely support IPv6 is also serves as an important
challenge and incentive to overcome Dual-Stack towards choose IPv4aaS solution solutions <xref target="ANSI"></xref>.</t> target="ANSI" format="default"/>
over Dual-Stack.</t>
</section>
<section title="Software Applications"> numbered="true" toc="default">
<name>Software Applications</name>
<t>The transition to IPv6 requires that the application software is adapted for use in IPv6-based networks (<xref target="ARIN-SW"></xref> target="ARIN-SW" format="default"/> provides an example).
The use of transition mechanisms like 464XLAT is essential to support IPv4-only applications while they evolve to IPv6.
Depending on the transition mechanism employed employed, some issues may remain. For example, in the case of NAT64/DNS64 NAT64/DNS64, the use of literal IPv4 addresses,
instead of DNS names, will fail, fail unless mechanisms such as Application Level Gateways (ALG) (ALGs) are used. This issue is not present in 464XLAT
(see <xref target="RFC8683"></xref>).</t> target="RFC8683" format="default"/>).</t>
<t>It is worth mentioning Happy Eyeballs <xref target="RFC8305"></xref> target="RFC8305" format="default"/> as a relevant aspect of application transition to IPv6.</t>
</section>
</section>
<section title="Network numbered="true" toc="default">
<name>Network Management and Operations"> Operations</name>
<t>There are important IPv6 complementary solutions related to Operations, Administration Administration, and Maintenance (OAM) that look less mature compared to IPv4.
A Network Management System (NMS) has a central role in the modern networks for both network operators and enterprises enterprises, and its transition is a fundamental issue.
This is because some IPv6 products are not as field-proven field proven as for IPv4 products, even if conventional protocols (e.g. SNMP, (e.g., SNMP and RADIUS) already support IPv6.
In addition, an incompatible vendor road map for the development of new NMS features affects the confidence of network operators or enterprises.</t>
<t>An important factor is represented by the need for training the network operations workforce. Deploying IPv6 requires that policies and procedures
have to be adjusted in order to successfully plan and complete an IPv6 transition. Staff has to be aware of the best practices for managing
IPv4 and IPv6 assets. In addition to network nodes, network management applications and equipment need to be properly configured and and, in some cases cases, also
replaced. This may introduce more complexity and costs for the transition.</t>
<t>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) <xref target="RFC4862"></xref>, target="RFC4862" format="default"/>, or by using the stateful Dynamic Host Control Configuration Protocol (DHCP) <xref target="RFC8415"></xref>. target="RFC8415" format="default"/>.
IP Address Management (IPAM) systems may contribute to handle by handling the technical differences and automate automating some of the configuration tasks, such as the address assignment
or the management of DHCP services.</t>
</section>
<section title="Performance"> numbered="true" toc="default">
<name>Performance</name>
<t>People tend to compare the performance of IPv6 versus IPv4 to argue or motivate the IPv6 transition.
In some cases, IPv6 behaving "worse" than IPv4 may be used as an argument for avoiding the full adoption of IPv6.
However, there are some aspects where IPv6 has already filled (or is filling) the gap to IPv4. This position is supported when
looking at available analytics on two critical parameters: packet loss and latency. These parameters have been constantly
monitored over time, but only a few comprehensive measurement campaigns are providing up-to-date information.
While performance is undoubtedly an important issue to consider and worth further investigation, the reality is that
a definitive answer cannot be found on what IP version performs better. Depending on the specific use case and application,
IPv6 is better; in others others, the same applies to IPv4.</t>
<section title="IPv6 packet loss numbered="true" toc="default">
<name>IPv6 Packet Loss and latency"> Latency</name>
<t><xref target="APNIC5"></xref> target="APNIC5" format="default"/> provides a measurement of both the failure rate and Round Trip Round-Trip Time (RTT) of IPv6 compared against IPv4.
Both measures are based on scripts that employs employ the three-way handshake of TCP. As such, the measurement of the failure rate
does not provide a direct measurement of packet loss (that (which would need an Internet-wide measurement campaign).
Said that,
That said, despite that IPv4 is still performing better, the difference seems to have decreased in recent years.
Two reports, namely <xref target="RIPE1"></xref> target="RIPE1" format="default"/> and <xref target="APRICOT"></xref>, target="APRICOT" format="default"/>, 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 instability, or firewall behavior. Yet, this worsening effect may appear as
disturbing for a plain transition to IPv6.</t>
<t><xref target="APNIC5"></xref> target="APNIC5" format="default"/> also compares the latency of both address families. Currently, the worldwide average is slightly in favor of IPv6.
Zooming at the country or even at the operator level, it is possible to get more detailed information and appreciate that cases exist where IPv6 is faster than IPv4.
Regions (e.g. (e.g., Western Europe, Northern America, and Southern Asia) and Countries (e.g. countries (e.g., US, India, and Germany) with an advanced deployment of IPv6 (e.g. >45%) (e.g., greater than 45%)
are showing that IPv6 has better performance than IPv4.
<xref target="APRICOT"></xref> target="APRICOT" format="default"/> highlights how when a difference in performance exists exists, it is often related to asymmetric routing issues.
Other possible explanations for a relative latency difference lies on
relate to the specificity of the IPv6 header header, which allows packet
fragmentation.
In turn, this means that hardware needs to spend cycles to analyze all of the header sections sections, and when it is not capable of handling one of them them, it drops the packet.
A few measurement campaigns on the behavior of IPv6 in CDNs are also available <xref target="MAPRG"></xref>, target="MAPRG" format="default"/> <xref target="INFOCOM"></xref>. target="INFOCOM" format="default"/>.
The TCP connect connection time is still higher for IPv6 in both cases, even if the gap has reduced over the analysis time window.</t>
</section>
<section title="Customer Experience"> numbered="true" toc="default">
<name>Customer Experience</name>
<t>It is not totally clear if the Customer Experience customer experience is in some way perceived as better when IPv6 is used instead of IPv4. In some cases cases,
it has been publicly reported by IPv6 content providers, providers that users have a better experience when using IPv6-only compared to IPv4 <xref target="ISOC2"></xref>. target="ISOC2" format="default"/>.
This could be explained because because, in the case of an IPv6 user connecting to an application hosted in an IPv6-only Data Centers, Center, the connection is end-to-end, end to end,
without translations. Instead, when using IPv4 IPv4, there is a NAT translation either in the CPE or in the service provider’s provider's network, in addition to
IPv4 to IPv6 (and back to IPv4) translation in the IPv6-only content provider Data Center.
<xref target="ISOC2"></xref>, target="ISOC2" format="default"/> and <xref target="FB"></xref> target="FB" format="default"/> provide reasons in favor of IPv6. In other cases, the result seems to be still slightly
in favor of IPv4 <xref target="INFOCOM"></xref>, target="INFOCOM" format="default"/> <xref target="MAPRG"></xref>, target="MAPRG" format="default"/>, even if the difference between IPv4 and IPv6 tends to vanish over time.</t>
</section>
</section>
<section anchor="security-privacy" title="IPv6 security numbered="true" toc="default">
<name>IPv6 Security and privacy"> Privacy</name>
<t>An important point that is sometimes considered as a challenge when discussing the transition to IPv6 is related to the security and privacy.
<xref target="RFC9099"></xref> target="RFC9099" format="default"/> analyzes the operational security issues in several places of a network (enterprises,
service providers providers, and residential users). It is also worth considering the additional security issues brought by the applied IPv6
transition technologies used to implement IPv4aaS (e.g. 464XLAT, (e.g., 464XLAT and DS-Lite) <xref target="ComputSecur"></xref>.</t> target="ComputSecur" format="default"/>.</t>
<t>The security aspects have to be considered to keep at least the same same, or even a better better, level of security
as it exists nowadays in an IPv4 network environment. The autoconfiguration features of IPv6 will require some more attention.
Router discovery and address autoconfiguration may produce unexpected results and security holes.
IPsec protects IPv6 traffic at least as well as it does IPv4, and the security protocols for constrained devices (IoT) are designed for
IPv6 operation.</t>
<t>IPv6 was designed to restore the end-to-end model of communications with all nodes on networks using globally unique addresses.
But,
But considering this, IPv6 may imply privacy concerns, concerns due to greater visibility on the Internet.
IPv6 nodes can (and typically do) use privacy extensions <xref target="RFC8981"></xref> target="RFC8981" format="default"/> to prevent any tracking of their burned-in MAC Media Access Control (MAC) address(es),
which are easily readable in the original modified EUI-64 64-bit Extended Unique Identifier (EUI-64) interface identifier format. But, on On the other hand,
stable IPv6 interface identifiers (<xref target="RFC8064"></xref>) <xref target="RFC8064" format="default"/> were developed developed, and this can also affect privacy.</t>
<t>As reported in <xref target="ISOC3"></xref>, target="ISOC3" format="default"/>, in comparing IPv6 and IPv4 at the protocol level,
one may probably conclude that the increased complexity of IPv6 results will result in an increased number
of attack vectors, vectors that imply more possible ways to perform different types of attacks.
However, a more interesting and practical question is how IPv6 deployments compare to IPv4 deployments
in terms of security. In that sense, there are a number of aspects to consider.</t>
<t>Most security vulnerabilities related to network protocols are based on implementation flaws.
Typically, security researchers find vulnerabilities in protocol implementations, which
eventually are “patched” "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, thus IPv4
implementations are generally more robust than IPv6. However, with more IPv6 deployment,
IPv6 will also benefit from this process in the long run.
It is also worth mentioning that most vulnerabilities are nowadays in the are
caused by human being beings and are in the application layer and layer, not in the
IP layer.</t>
<t>Besides the intrinsic properties of the protocols, the security level of the resulting deployments
is closely related to the level of expertise of network and security engineers. In that sense, there
is obviously much more experience and confidence with deploying and operating IPv4 networks
than with deploying and operating IPv6 networks.</t>
<section title="Protocols security issues"> numbered="true" toc="default">
<name>Protocols' Security Issues</name>
<t>In general, there are security concerns related to IPv6 that can be classified as follows:<list style="symbols">
<t>Basic follows:</t>
<ul spacing="normal">
<li>Basic IPv6 protocol (Basic (basic header, Extension Headers, Addressing)</t>
<t>IPv6 associated extension headers, addressing)</li>
<li>IPv6-associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)</t>
<t>Internet-wide DHCPv6)</li>
<li>Internet-wide IPv6 security (Filtering, (filtering, DDoS, Transition Mechanisms)</t>
</list></t> transition mechanisms)</li>
</ul>
<t>ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions.
The Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6 IPv6, which replaces and enhances
functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers for discovering multicast
listeners on a directly attached link, much like how the Internet Group Management Protocol (IGMP) is used in IPv4.</t>
<t>These IPv6 associated protocols IPv6-associated protocols, like ICMPv6, NDP NDP, and MLD MLD, are something new compared to IPv4, so
they add new security threats and the related solutions are still under discussion today.
NDP has vulnerabilities <xref target="RFC3756"></xref> target="RFC3756" format="default"/> <xref target="RFC6583"></xref>.
The specification target="RFC6583" format="default"/>.
<xref target="RFC3756" format="default"/> says to use IPsec IPsec, but it is impractical and not used, used; on the other hand,
SEND (SEcure Neighbour Discovery)
SEcure Neighbor Discovery (SEND) <xref target="RFC3971"></xref> target="RFC3971" format="default"/> is not widely available.
It is worth mentioning that applying host isolation may address many of these concerns, as described in
<xref target="I-D.ietf-v6ops-nd-considerations"/>.</t> target="I-D.ietf-v6ops-nd-considerations" format="default"/>.</t>
<t><xref target="RIPE2"></xref> target="RIPE2" format="default"/> describes the most important threats and solutions
regarding IPv6 security.</t>
<section title="IPv6 numbered="true" toc="default">
<name>IPv6 Extension Headers and Fragmentation"> Fragmentation</name>
<t>IPv6 Extension Headers extension headers provide a hook for interesting new features to be added, added and are more flexible than IPv4 Options. options.
This does add some complexity, and in particular complexity. In particular, some security mechanisms may require to process processing the full chain of headers,
and some firewalls may require to filter filtering packets based on their Extension Headers. extension headers. Additionally, packets with IPv6 Extension Headers extension headers
may be dropped in the public Internet <xref target="RFC7872"></xref>. target="RFC7872" format="default"/>.
Some documents, e.g. e.g., <xref target="I-D.ietf-6man-hbh-processing"/>, target="I-D.ietf-6man-hbh-processing" format="default"/>, <xref target="I-D.ietf-v6ops-hbh"/>, target="I-D.ietf-v6ops-hbh" format="default"/>, and
<xref target="I-D.bonica-6man-ext-hdr-update"/>, target="I-D.bonica-6man-ext-hdr-update" format="default"/>, analyze and provide guidance regarding the processing procedures of IPv6 Extension Headers.</t> extension headers.</t>
<t>Defense against possible attacks through Extension Headers extension headers is necessary. For example, the original IPv6 Routing Header type 0 (RH0)
was deprecated because of possible remote traffic amplification <xref target="RFC5095"></xref>. target="RFC5095" format="default"/>. In addition, it is worth mentioning that the unrecognized
Hop-by-Hop Options Header and Destination Options Header will not be considered by the nodes if they are not configured to deal with it
<xref target="RFC8200"></xref>. target="RFC8200" format="default"/>.
Other attacks based on Extension Headers extension headers may be based on IPv6 Header Chains header chains and Fragmentation fragmentation that could be used to bypass filtering.
To mitigate this effect, the initial IPv6 Header, header, the Extension Headers extension headers, and the Upper-Layer Header upper-layer header must all be in the first fragment <xref target="RFC8200"></xref>. target="RFC8200" format="default"/>.
Also, the use of the IPv6 Fragmentation Header fragment header is forbidden in all Neighbor Discovery messages <xref target="RFC6980"></xref>.</t>
<t>Fragment Header target="RFC6980" format="default"/>.</t>
<t>The fragment header is used by the IPv6 source node to send a packet bigger than the path MTU MTU, and the Destination destination host processes
fragment headers. There are several threats related to fragmentation to pay attention to e.g. to, e.g., overlapping fragments (not allowed) allowed),
resource consumption while waiting for the last fragment (to discard), and atomic fragments (to be isolated).</t>
<t>The operational implications of IPv6 Packets packets with Extension Headers extension headers are further discussed in <xref target="RFC9098"></xref>.</t> target="RFC9098" format="default"/>.</t>
</section>
</section>
</section>
</section>
<section title="Security Considerations"> anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document has no impact on the security properties of specific IPv6 protocols or transition tools.
In addition to the discussion above in <xref target="security-privacy"/>, target="security-privacy" format="default"/>, the security considerations
relating to the protocols and transition tools are described in the relevant documents.</t>
</section>
<section anchor="Contributors" title="Contributors">
<contact fullname="Nalini Elkins">
<organization>Inside Products</organization>
<address>
<postal>
<street></street>
<extaddr></extaddr>
<region></region>
<code></code>
<country></country>
</postal>
<email>nalini.elkins@insidethestack.com</email>
</address>
</contact>
<contact fullname="Sébastien Lourdez">
<organization>Post Luxembourg</organization>
<address>
<postal>
<street></street>
<extaddr></extaddr>
<region></region>
<code></code>
<country></country>
</postal>
<email>sebastien.lourdez@post.lu</email>
</address>
</contact>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors of this document would like to thank Brian Carpenter, Fred Baker, Alexandre Petrescu, Fernando Gont,
Barbara Stark, Haisheng Yu(Johnson), Dhruv Dhody, Gabor Lencse, Shuping Peng, Daniel Voyer, Daniel Bernier,
Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, Erik Nygren, Eduard Vasilenko and Xipeng Xiao
for their comments and review of this document.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.6036'?>
<?rfc include='reference.RFC.6180'?>
<?rfc include='reference.RFC.6883'?>
<?rfc include='reference.RFC.4213'?>
<?rfc include='reference.RFC.7381'?>
<?rfc include='reference.RFC.6877'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.7596'?>
<?rfc include='reference.RFC.7597'?>
<?rfc include='reference.RFC.7599'?>
<?rfc include='reference.RFC.3756'?>
<?rfc include='reference.RFC.6583'?>
<?rfc include='reference.RFC.3971'?>
<?rfc include='reference.RFC.6540'?>
<?rfc include='reference.RFC.8950'?>
<?rfc include='reference.RFC.9099'?>
<?rfc include='reference.RFC.9313'?>
<displayreference target="I-D.ietf-v6ops-nd-considerations" to="ND-CONSIDERATIONS"/>
<displayreference target="I-D.ietf-6man-hbh-processing" to="HBH-PROCESSING"/>
<displayreference target="I-D.ietf-v6ops-hbh" to="HBH-OPT-HDR"/>
<displayreference target="I-D.palet-v6ops-ipv6-only" to="IPv6-ONLY-DEF"/>
<displayreference target="I-D.bonica-6man-ext-hdr-update" to="IPv6-EXT-HDR"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6883.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4213.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7381.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6333.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7596.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7599.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6583.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6540.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9099.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9313.xml"/>
</references>
<references title="Informative References">
<!-- A reference written by by an organization not a persoN. -->
<?rfc include='reference.RFC.8305'?>
<?rfc include='reference.RFC.5095'?>
<?rfc include='reference.RFC.8683'?>
<?rfc include='reference.RFC.8981'?>
<?rfc include='reference.RFC.8064'?>
<?rfc include='reference.RFC.9098'?>
<?rfc include='reference.RFC.7872'?>
<?rfc include='reference.RFC.6980'?>
<?rfc include='reference.RFC.8200'?>
<?rfc include='reference.RFC.6264'?>
<?rfc include='reference.RFC.4862'?>
<?rfc include='reference.RFC.8415'?>
<?rfc include='reference.I-D.ietf-v6ops-nd-considerations'?>
<?rfc include='reference.I-D.ietf-6man-hbh-processing'?>
<?rfc include='reference.I-D.ietf-v6ops-hbh'?>
<?rfc include='reference.I-D.palet-v6ops-ipv6-only'?>
<?rfc include='reference.I-D.bonica-6man-ext-hdr-update'?>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5095.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8683.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6980.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
<reference anchor="I-D.ietf-v6ops-nd-considerations">
<front>
<title>
Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment
</title>
<author initials="X." surname="Xiao" fullname="XiPeng Xiao">
<organization>Huawei Technologies</organization>
</author>
<author initials="E" surname="Vasilenko" fullname="Eduard Vasilenko">
<organization>Huawei Technologies</organization>
</author>
<author initials="E." surname="Metz" fullname="Eduard Metz">
<organization>KPN</organization>
</author>
<author initials="G." surname="Mishra" fullname="Gyan S. Mishra">
<organization>Verizon Inc.</organization>
</author>
<author initials="N." surname="Buraglio" fullname="Nick Buraglio">
<organization>Energy Sciences Network</organization>
</author>
<date month="October" day="24" year="2022"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-v6ops-nd-considerations-00"/>
</reference>
<reference anchor='ETSI-IP6-WhitePaper'> anchor="I-D.ietf-6man-hbh-processing">
<front>
<title>ETSI White Paper No. 35:
<title>IPv6 Hop-by-Hop Options Processing Procedures</title>
<author initials="R." surname="Hinden" fullname="Robert M. Hinden">
<organization>Check Point Software</organization>
</author>
<author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
<organization>University of Aberdeen</organization>
</author>
<date month="March" day="11" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-hbh-processing-06"/>
</reference>
<reference anchor="I-D.ietf-v6ops-hbh">
<front>
<title>
Operational Issues with Processing of the Hop-by-Hop Options Header
</title>
<author initials="S." surname="Peng" fullname="Shuping Peng">
<organization>Huawei Technologies</organization>
</author>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="C." surname="Xie" fullname="Chongfeng Xie">
<organization>China Telecom</organization>
</author>
<author initials="Z." surname="Qin" fullname="Zhuangzhuang Qin">
<organization>China Unicom</organization>
</author>
<author initials="G." surname="Mishra" fullname="Gyan S. Mishra">
<organization>Verizon Inc.</organization>
</author>
<date month="March" day="10" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-hbh-04"/>
</reference>
<reference anchor="I-D.palet-v6ops-ipv6-only">
<front>
<title>IPv6-only Terminology Definition</title>
<author initials="J." surname="Palet Martinez" fullname="Jordi Palet Martinez">
<organization>The IPv6 Company</organization>
</author>
<date month="March" day="9" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-palet-v6ops-ipv6-only-05"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference/I-D.bonica-6man-ext-hdr-update.xml"/>
<reference anchor="ETSI-IP6-WhitePaper">
<front>
<title>IPv6 Best Practices, Benefits, Transition Challenges and the Way Forward</title>
<author>
<organization>ETSI</organization>
</author>
<date year='2020' /> year="2020" month="August"/>
</front>
<seriesInfo name='ISBN' value='979-10-92620-31-1'/> name="ETSI" value="White Paper No. 35"/>
<seriesInfo name="ISBN" value="979-10-92620-31-1"/>
</reference>
<reference anchor='ETSI-GR-IPE-001' anchor="ETSI-GR-IPE-001" target="https://www.etsi.org/deliver/etsi_gr/IPE/001_099/001/01.01.01_60/gr_IPE001v010101p.pdf">
<front>
<title>ETSI GR IPE 001: IPv6
<title>IPv6 Enhanced Innovation (IPE) Gap Analysis</title>
<author>
<organization>ETSI</organization>
</author>
<date year='2021' /> year="2021" month="August"/>
</front>
<seriesInfo name="ETSI GR IPE 001," value="V1.1.1"/>
</reference>
<reference anchor='IAB' anchor="IAB" target="https://www.iab.org/2016/11/07/iab-statement-on-ipv6/">
<front>
<title>IAB Statement on IPv6</title>
<author>
<organization>IAB</organization>
</author>
<date year='2016' /> year="2016" month="November"/>
</front>
</reference>
<reference anchor='CAIR' anchor="CAIR" target="https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html">
<front>
<title>Cisco Annual Internet Report (2018–2023) (2018-2023) White Paper</title>
<author>
<organization>Cisco</organization>
</author>
<date year='2020' /> year="2020" month="March"/>
</front>
</reference>
<reference anchor='CAIDA' anchor="CAIDA" target="https://www.cmand.org/workshops/202006-v6/slides/2020-06-16-client-side.pdf">
<front>
<title>Client-Side IPv6 Measurement</title>
<author>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
</author>
<date year='2020' /> year="2020" month="June"/>
</front>
</reference>
<reference anchor='POTAROO1' anchor="POTAROO1" target="https://www.potaroo.net/ispcol/2022-01/addr2021.html">
<front>
<title>IP Addressing through 2021</title>
<author>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>POTAROO</organization>
</author>
<date year='2022' /> year="2022" month="January"/>
</front>
</reference>
<reference anchor='POTAROO2' anchor="POTAROO2" target="https://www.potaroo.net/bgp/iso3166/v6cc.html">
<front>
<title>IPv6 Resource Allocations</title>
<author>
<organization>POTAROO</organization>
</author>
<date year='2022' /> year="2023" month="March"/>
</front>
</reference>
<reference anchor='CN-IPv6' anchor="CN-IPv6" target="https://www.china-ipv6.cn/#/activeconnect/simpleInfo">
<front>
<title>Active IPv6 Internet users</title> Users</title>
<author>
<organization>National IPv6 Deployment and Monitoring Platform</organization>
</author>
<date year='2022' /> year="2022"/>
</front>
<refcontent>(in Chinese)</refcontent>
</reference>
<reference anchor='IGP-GT' target="https://via.hypothes.is/https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-final-report.pdf"> anchor="IGP-GT" target="https://www.emerald.com/insight/content/doi/10.1108/DPRG-10-2019-0085/full/html">
<front>
<title>The hidden standards war: economic factors affecting IPv6 deployment</title>
<author>
<author initials="B." surname="Kuerbis" fullname="Brenden Keurbis">
<organization>Internet Governance Project, Georgia Tech</organization>
</author>
<author initials="M." surname="Mueller" fullname="Milton Mueller">
<organization>Internet Governance Project, Georgia Tech</organization>
</author>
<date year='2019' /> year="2019" month="February"/>
</front>
<seriesInfo name="DOI" value="10.1108/DPRG-10-2019-0085"/>
</reference>
<reference anchor='NRO' anchor="NRO" target="https://www.nro.net/wp-content/uploads/NRO-Statistics-2021-Q3-FINAL.pdf">
<front>
<title>Internet Number Resource Status Report</title>
<author>
<organization>NRO</organization>
</author>
<date year='2021' /> year="2021" month="September"/>
</front>
</reference>
<reference anchor='ISOC1' anchor="ISOC1" target="https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/">
<front>
<title>State of IPv6 Deployment 2018</title>
<author>
<organization>Internet Society</organization>
</author>
<date year='2018' /> year="2018" month="June"/>
</front>
</reference>
<reference anchor='ISOC2' anchor="ISOC2" target="https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/">
<front>
<title>Facebook News Feeds Load 20-40% Faster Over IPv6</title>
<author>
<author initials="D." surname="York" fullname="Dan York">
<organization>Internet Society</organization>
</author>
<date year='2015' /> year="2015" month="April"/>
</front>
</reference>
<reference anchor='ISOC3' anchor="ISOC3" target="https://www.internetsociety.org/wp-content/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf">
<front>
<title>IPv6 Security FAQ</title>
<author> Frequently Asked Questions (FAQ)</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization>Internet Society</organization>
</author>
<date year='2019' /> year="2019" month="January"/>
</front>
</reference>
<reference anchor='HxBld' anchor="HxBld" target="https://hexabuild.io/assets/files/HexaBuild-IPv6-Adoption-Report-2020.pdf">
<front>
<title>IPv6 Adoption Report 2020</title> 2020: The IPv6 Internet is the Corporate Network</title>
<author>
<organization>HexaBuild</organization>
</author>
<date year='2020' /> year="2020" month="November"/>
</front>
</reference>
<reference anchor='G_stats' anchor="G_stats" target="https://www.google.com/intl/en/ipv6/statistics.html">
<front>
<title>Google IPv6 Statistics</title>
<author>
<organization>Google</organization>
</author>
<date year='2021' />
</front>
</reference>
<reference anchor='ARCEP' anchor="ARCEP" target="https://www.arcep.fr/uploads/tx_gsavis/19-1386.pdf">
<front>
<title>Arcep Décision n° 2019-1386, Decision
<title>Proposant au ministre chargé des
communications électroniques les modalités et les
conditions d'attribution d'autorisations d'utilisation de
fréquences dans la bande 3,4 - 3,8 GHz</title>
<author>
<organization>ARCEP</organization>
</author>
<date year="2019" month="November"/>
</front>
<refcontent>[Decision on the terms
and conditions for awarding licences licenses to use frequencies in
the 3.4–3.8GHz band</title>
<author>
<organization>ARCEP</organization>
</author>
<date year='2019' />
</front> 3.4 – 3.8 GHz band], Décision n° [Decision No.] 2019-1386</refcontent>
</reference>
<reference anchor='APNIC1' anchor="APNIC1" target="https://stats.labs.apnic.net/ipv6">
<front>
<title>IPv6 Capable Rate by country (%)</title>
<author>
<organization>APNIC</organization>
<organization>APNIC Labs</organization>
</author>
<date year='2022' />
</front>
</reference>
<reference anchor='APNIC2' anchor="APNIC2" target="https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/">
<front>
<title>IP Addressing addressing in 2021</title>
<author>
<organization>APNIC2</organization>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
</author>
<date year='2022' /> year="2022" month="January"/>
</front>
</reference>
<reference anchor='APNIC3' target="https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/>"> anchor="APNIC3" target="https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/">
<front>
<title>BGP in 2020 – - The BGP Table</title>
<author>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
</author>
<date year='2021' /> year="2021" month="January"/>
</front>
</reference>
<reference anchor='APNIC4' target="https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp-table/>"> anchor="APNIC4" target="https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp-table/">
<front>
<title>BGP in 2021 – - The BGP Table</title>
<author>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
</author>
<date year='2022' /> year="2022" month="January"/>
</front>
</reference>
<reference anchor='APNIC5' anchor="APNIC5" target="https://stats.labs.apnic.net/v6perf/XA">
<front>
<title>Average RTT Difference (ms) (V6 - V4) for World (XA)</title>
<author>
<organization>APNIC</organization>
<organization>APNIC Labs</organization>
</author>
<date year='2022' />
</front>
</reference>
<reference anchor='APRICOT' anchor="APRICOT" target="https://2020.apricot.net/assets/files/APAE432/ipv6-performance-measurement.pdf">
<front>
<title>Average RTT Difference (ms) (V6 - V4) for World (XA)</title>
<title>IPv6 Performance Measurement</title>
<author initials="G." surname="Huston"> surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
</author>
<date year='2020' /> year="2020" month="February"/>
</front>
</reference>
<reference anchor='FB' anchor="FB" target="https://youtu.be/An7s25FSK0U">
<front>
<title>Facebook IPv6 Experience</title>
<author initials="P." surname="Saab">
<organization>V6
<title>Paul Saab Facebook V6 World Congress</organization> Congress 2015</title>
<author>
<organization/>
</author>
<date year='2015' /> year="2015" month="March"/>
</front>
<refcontent>YouTube video, 25:32, posted by Upperside Conferences</refcontent>
</reference>
<reference anchor='MAPRG' anchor="MAPRG" target="https://www.ietf.org/proceedings/99/slides/slides-99-maprg-measuring-youtube-content-delivery-over-ipv6-00.pdf">
<front>
<title>Measuring YouTube Content Delivery over IPv6</title>
<author initials="V." surname="Bajpai"> surname="Bajpai" fullname="Vaibhav Bajpai">
<organization>TU Munich</organization>
</author>
<date year='2017' /> year="2017" month="July"/>
</front>
</reference>
<reference anchor='INFOCOM' anchor="INFOCOM" target="https://dl.acm.org/doi/abs/10.1109/INFOCOM41043.2020.9155367">
<front>
<title>A Longitudinal View of Netflix: Content Delivery over IPv6 and Content Cache Deployments</title>
<author initials="T.V." initials="T." surname="Doan">
<organization>TU Munich</organization>
</author>
<author initials="V." surname="Bajpai">
<organization>TU Munich</organization>
</author>
<author initials="S." surname="Crawford">
<organization>SamKnows</organization>
</author>
<date year='2020' /> year="2020" month="July"/>
</front>
<refcontent>IEEE INFOCOM 2020, IEEE Conference on Computer Communications, pp. 1073-1082</refcontent>
<seriesInfo name="DOI" value="10.1109/INFOCOM41043.2020.9155367"/>
</reference>
<reference anchor='RIPE1' anchor="RIPE1" target="https://ripe73.ripe.net/wp-content/uploads/presentations/35-2016-10-24-v6-performance.pdf">
<front>
<title>Measuring IPv6 Performance</title>
<author initials="G." surname="Huston">
<organization>APNIC</organization>
</author>
<date year='2016' /> year="2016" month="October"/>
</front>
</reference>
<reference anchor='RIPE2' anchor="RIPE2" target="https://www.ripe.net/support/training/material/ipv6-security/ipv6security-slides.pdf">
<front>
<title>IPv6 Security</title>
<author>
<organization>RIPE</organization>
</author>
<date year='2019' /> year="2023" month="January"/>
</front>
</reference>
<reference anchor='cmpwr' anchor="cmpwr" target="https://mydigitalpublication.com/article/Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U.S.+Federal+Government/3702828/664279/article.html">
<front>
<title>Impact on Enterprises of the IPv6-Only direction Direction for the US U.S. Federal Government</title>
<author>
<author initials="N." surname="Elkins">
<organization>Compuware</organization>
</author>
<date year='2020' />
</front>
</reference>
<reference anchor='BIPT' anchor="BIPT" target="https://www.ripe.net/participate/meetings/roundtable/september-2017/government-roundtable-meeting-bahrain-26-september-2017/presentations/belgium-experience-bahrain-roundtable.pdf">
<front>
<title>IPv6 in Belgium</title>
<author>
<author initials="J." surname="Vannieuwenhuyse">
<organization>Belgian Institute for Postal services and Telecommunications</organization> telecommunications</organization>
</author>
<date year='2017' /> year="2017" month="September"/>
</front>
</reference>
<reference anchor='GFA' anchor="GFA" target="https://media.frag-den-staat.de/files/foi/531501/de-government-ipv6-masterplan-v100-entwurf_konvertiert.pdf">
<front>
<title>IPv6-Masterplan für die Bundesverwaltung</title>
<author>
<organization>German Federal Government Commissioner for Information Technology</organization>
</author>
<date year='2019' /> year="2019" month="November"/>
</front>
<refcontent>[IPv6 Master Plan for the Federal Administration]</refcontent>
</reference>
<reference anchor='IDT' anchor="IDT" target="https://dot.gov.in/revision-ipv6-transition-timelines-2021">
<front>
<title>Revision of IPv6 Transition Timelines</title>
<author>
<organization>Indian
<organization>Government of India: Department of Telecommunications</organization>
</author>
<date year='2021' /> year="2021" month="February"/>
</front>
</reference>
<reference anchor='RelJio' anchor="RelJio" target="https://datatracker.ietf.org/meeting/109/materials/slides-109-v6ops-ipv6-only-adoption-challenges-and-standardization-requirements-03">
<front>
<title>IPv6-only adoption challenges and standardization requirements</title>
<author>
<author initials="R." surname="Chandra">
<organization>Reliance Jio</organization>
</author>
<date year='2020' /> year="2020" month="November"/>
</front>
</reference>
<reference anchor='TMus' anchor="TMus" target="https://pc.nanog.org/static/published/meetings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf">
<front>
<title>Going IPv6-only</title>
<author> IPv6 Only</title>
<author initials="S." surname="Lagerholm" fullname="Stephan Lagerholm">
<organization>T-Mobile US</organization>
</author>
<date year='2018' /> year="2018" month="June"/>
</front>
</reference>
<reference anchor='EE' anchor="EE" target="https://indico.uknof.org.uk/event/38/contributions/489/attachments/612/736/Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf">
<front>
<title>IPv6-only devices Devices on EE mobile</title>
<author> Mobile</title>
<author initials="N." surname="Heatley" fullname="Nick Heatley">
<organization>EE</organization>
</author>
<date year='2017' /> year="2017" month="January"/>
</front>
</reference>
<reference anchor='CN' anchor="CN" target="http://www.china.org.cn/business/2017-11/27/content_41948814.htm">
<front>
<title>China to speed up IPv6-based Internet development</title>
<author>
<organization>China.org.cn</organization>
</author>
<date year='2017' /> year="2017" month="November"/>
</front>
</reference>
<reference anchor='US-FR' anchor="US-FR" target="https://www.federalregister.gov/documents/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completing-the-transition-to-the-next-generation">
<front>
<title>Request for Comments on Updated Guidance for Completing the Transition to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)</title>
<author>
<organization>Federal Register</organization>
</author>
<date year='2020' /> year="2020" month="March"/>
</front>
</reference>
<reference anchor='US-CIO' anchor="US-CIO" target="https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf">
<front>
<title>Memorandum for Heads of Executive Departments and Agencies. Agencies: Completing the Transition to Internet Protocol Version 6 (IPv6)</title>
<author>
<author initials="R" surname="Vought" fullname="Russell T. Vought">
<organization>The CIO Council</organization>
</author>
<date year='2020' /> year="2020"/>
</front>
</reference>
<reference anchor='ARIN-CG' target="https://www.arin.net/about/community_grants/recipients/"> anchor="ARIN-CG" target="https://www.arin.net/about/community_grants/recipients/2020">
<front>
<title>Community
<title>2020 ARIN Community Grant Program: Program Recipients: IPv6
Security, Applications, and Training for Enterprises</title>
<author>
<organization>ARIN</organization>
</author>
<date year='2020' /> year="2020"/>
</front>
</reference>
<reference anchor='ARIN-SW' anchor="ARIN-SW" target="https://www.arin.net/resources/guide/ipv6/preparing_apps_for_v6.pdf">
<front>
<title>Preparing Applications for IPv6</title>
<author>
<organization>ARIN</organization>
</author>
<date year='' />
</front>
</reference>
<reference anchor='ISIF-ASIA-G' target="https://isif.asia/2020-grantees/"> anchor="ISIF-ASIA-G" target="https://isif.asia/ipv6-deployment-at-enterprises/">
<front>
<title>Internet Operations Research Grant: IPv6
<title>IPv6
Deployment at Enterprises. IIESoc. India</title> Enterprises</title>
<author>
<organization>ISIF Asia</organization>
<organization>India Internet Engineering Society (IIESoc)</organization>
</author>
<date year='2020' /> year="2022" month="March"/>
</front>
</reference>
<reference anchor='WIPv6L' anchor="WIPv6L" target="https://www.worldipv6launch.org/measurements/">
<front>
<title>World IPv6 Launch - Measurements</title>
<title>Measurements</title>
<author>
<organization>World IPv6 Launch</organization>
</author>
<date year='2021' /> month="June" year="2022"/>
</front>
</reference>
<reference anchor='W3Techs' anchor="W3Techs" target="https://w3techs.com/technologies/history_overview/site_element/all/y">
<front>
<title>Historical yearly trends in the usage statistics of site elements for websites</title>
<author>
<organization>W3Techs</organization>
</author>
<date year='2021' /> year="2023"/>
</front>
</reference>
<reference anchor='Csc6lab' anchor="Csc6lab" target="https://6lab.cisco.com/stats/">
<front>
<title>World - Display Content Data</title>
<title>Display global data</title>
<author>
<organization>Cisco</organization>
</author>
<date year='2022' />
</front>
</reference>
<reference anchor='Alx' target="https://www.alexa.com/topsites">
<front>
<title>The top 500 sites on the web</title>
<author>
<organization>Alexa</organization>
</author>
<date year='2021' /> year="2023"/>
</front>
</reference>
<reference anchor='SNDVN' anchor="SNDVN" target="https://www.sandvine.com/press-releases/sandvine-releases-2020-mobile-internet-phenomena-report-youtube-is-over-25-of-all-mobile-traffic">
<front>
<title>Sandvine releases 2020 Mobile Internet Phenomena Report: YouTube is over 25% of all mobile traffic</title>
<author>
<author initials="C." surname="Cullen" fullname="Cam Cullen">
<organization>SANDVINE</organization>
</author>
<date year='2020' /> year="2020" month="February"/>
</front>
</reference>
<reference anchor='NST_1' anchor="NST_1" target="https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com">
<front>
<title>Estimating Industry IPv6 and & DNSSEC External Service Deployment Status</title>
<author>
<organization>NIST</organization>
</author>
<date year='2022' /> year="2023"/>
</front>
</reference>
<reference anchor='NST_2' anchor="NST_2" target="https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov">
<front>
<title>Estimating USG IPv6 and & DNSSEC External Service Deployment Status</title>
<author>
<organization>NIST</organization>
</author>
<date year='2022' /> year="2023"/>
</front>
</reference>
<reference anchor='NST_3' anchor="NST_3" target="https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-edu">
<front>
<title>Estimating University IPv6 and & DNSSEC External Service Deployment Status</title>
<author>
<organization>NIST</organization>
</author>
<date year='2022' /> year="2023"/>
</front>
</reference>
<reference anchor='BGR_1' anchor="BGR_1" target="http://218.2.231.237:5001/cgi-bin/generate">
<front>
<title>China Commercial IPv6 and DNSSEC Deployment Monitor</title>
<author>
<organization>BIIGROUP</organization>
</author>
<date year='2022' /> month="December" year="2021"/>
</front>
</reference>
<reference anchor='BGR_2' anchor="BGR_2" target="http://218.2.231.237:5001/cgi-bin/generate_gov">
<front>
<title>China Government IPv6 and DNSSEC Deployment Monitor</title>
<author>
<organization>BIIGROUP</organization>
</author>
<date year='2022' /> month="December" year="2021"/>
</front>
</reference>
<reference anchor='BGR_3' anchor="BGR_3" target="http://218.2.231.237:5001/cgi-bin/generate_edu">
<front>
<title>China Education IPv6 and DNSSEC Deployment Monitor</title>
<author>
<organization>BIIGROUP</organization>
</author>
<date year='2022' /> month="December" year="2021"/>
</front>
</reference>
<reference anchor='CNLABS_1' anchor="CNLABS_1" target="https://cnlabs.in/IPv6_Mon/generate_industry.html">
<front>
<title>Industry IPv6 and DNSSEC Statistics</title>
<author>
<organization>CNLABS</organization>
</author>
<date year='2022' /> year="2022"/>
</front>
</reference>
<reference anchor='CNLABS_2' anchor="CNLABS_2" target="https://cnlabs.in/IPv6_Mon/generate_gov.html">
<front>
<title>Industry
<title>Government IPv6 and DNSSEC Statistics</title>
<author>
<organization>CNLABS</organization>
</author>
<date year='2022' /> year="2022"/>
</front>
</reference>
<reference anchor='IPv6Forum' anchor="IPv6Forum" target="https://www.ipv6forum.com/IPv6-Monitoring/index.html">
<front>
<title>Estimating IPv6 & DNSSEC External Service Deployment Status</title>
<author>
<organization>IPv6Forum</organization>
</author>
<date year='2022' /> year="2023"/>
</front>
</reference>
<reference anchor='Akm-stats' target="https://www.akamai.com/uk/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp"> anchor="Akm-stats" target="https://www.akamai.com/uk/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization">
<front>
<title>IPv6 Adoption Visualization</title>
<author>
<organization>Akamai</organization>
</author>
<date year='2021' /> year="2023"/>
</front>
</reference>
<reference anchor='Cldflr' anchor="Cldflr" target="https://support.cloudflare.com/hc/en-us/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support">
<front>
<title>Understanding and configuring Cloudflare's IPv6 support</title>
<author>
<organization>Cloudflare</organization>
</author>
<date />
</front>
</reference>
<reference anchor='Ggl' anchor="Ggl" target="https://support.google.com/interconnect/answer/9058809?hl=en">
<front>
<title>Introduction to GGC</title>
<author>
<organization>Google</organization>
</author>
<date />
</front>
</reference>
<reference anchor='Ntflx' anchor="Ntflx" target="https://netflixtechblog.com/enabling-support-for-ipv6-48a495d5196f">
<front>
<title>Enabling Support for IPv6</title>
<author>
<author initials="R." surname="Aggarwal" fullname="Rajiv Aggarwal">
<organization>Netflix</organization>
</author>
<author initials="D." surname="Temkin" fullname="David Temkin">
<organization>Netflix</organization>
</author>
<date /> year="2012" month="July"/>
</front>
</reference>
<reference anchor='Amzn' anchor="Amzn" target="https://aws.amazon.com/es/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/">
<front>
<title>Announcing Internet Protocol Version 6 (IPv6) support for Amazon CloudFront, AWS WAF, and Amazon S3 Transfer Acceleration</title>
<author>
<organization>Amazon</organization>
<organization>Amazon Web Services</organization>
</author>
<date /> month="October" year="2016"/>
</front>
</reference>
<reference anchor='Mcrsft' anchor="Mcrsft" target="https://azure.microsoft.com/en-us/updates/ipv6-for-azure-vms/">
<front>
<title>IPv6 for Azure VMs available in most regions</title>
<author>
<organization>Microsoft</organization>
</author>
<date />
</front>
</reference>
<reference anchor='Vrzn' target="https://www.verizondigitalmedia.com/blog/verizon-digital-media-services-announces-ipv6-compliance/">
<front>
<title>Verizon Digital Media Services announces IPv6 Compliance</title>
<author>
<organization>Verizon</organization>
</author>
<date /> month="September" year="2016"/>
</front>
</reference>
<reference anchor='ANSI' anchor="ANSI" target="https://shop.cta.tech/products/host-and-router-profiles-for-ipv6">
<front>
<title>ANSI/CTA Standard Host
<title>Host and Router Profiles for IPv6</title>
<author>
<organization>ANSI/CTA</organization>
<organization>ANSI</organization>
</author>
<date year='2020' /> year="2020" month="October"/>
</front>
<seriesInfo name="ANSI/CTA" value="2048-A"/>
</reference>
<reference anchor='ComputSecur' > anchor="ComputSecur">
<front>
<title>Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64</title>
<author>
<organization>Computers & Security (Elsevier)</organization>
<author initials="G." surname="Lencse" fullname="Gábor Lencse">
</author>
<author initials="Y." surname="Kadobayashi" fullname="Youki Kadobayashi">
</author>
<date year='2018' /> year="2018" month="August"/>
</front>
<refcontent>Computers and Security, Volume 77, Issue C, pp. 397-411</refcontent>
<seriesInfo name='DOI' value='10.1016/j.cose.2018.04.012'/> name="DOI" value="10.1016/j.cose.2018.04.012"/>
</reference>
</references>
</references>
<section title="Summary anchor="Appendix_A" numbered="true" toc="default">
<name>Summary of Questionnaire and Replies for network operators" anchor="Appendix_A"> Network Operators</name>
<t>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.</t>
<t>40
<t>In this survey, 40 people, representing 38 organizations, provided a response. responses.
This appendix summarizes the results obtained.</t>
<figure>
<artwork><![CDATA[
Respondents' business
Convergent Mobile Fixed
Type of operators 82% 8% 11%
]]></artwork>
</figure>
<t>Respondents' business:</t>
<table align="center">
<name>Type of Operators</name>
<thead>
<tr>
<th>Convergent</th>
<th>Mobile</th>
<th>Fixed</th>
</tr>
</thead>
<tbody>
<tr>
<td>82%</td>
<td>8%</td>
<td>11%</td>
</tr>
</tbody>
</table>
<t>Question 1. Do you have plan plans to move more fixed or mobile fixed, mobile, or enterprise users
to IPv6 in the next 2 years?</t>
<t>a. If
<ol type="A">
<li>If so, fixed, or mobile, or enterprise?</t>
<t>b. What enterprise?</li>
<li>What are the reasons to do so?</t>
<t>c. When so?</li>
<li>When to start: already on going, ongoing, in 12 months, or after 12 months?</t>
<t>d. Which months?</li>
<li>Which transition solution will you use, use: Dual-Stack, DS-Lite, 464XLAT, MAP-T/E?</t>
<t>Answer or MAP-T/E?</li>
</ol>
<t>Answers for 1.A (38 respondents)</t>
<figure>
<artwork><![CDATA[
Yes No
Plans availability 79% 21%
Mobile Fixed Enterprise Don't answer
Business segment 63% 63% 50% 3%
]]></artwork>
</figure>
<t>Answer
<table align="center">
<name>Plan to Move to IPv6 within 2 Years</name>
<thead>
<tr>
<th>Yes</th>
<th>No</th>
</tr>
</thead>
<tbody>
<tr>
<td>79%</td>
<td>21%</td>
</tr>
</tbody>
</table>
<table align="center">
<name>Business Segment</name>
<thead>
<tr>
<th>Mobile</th>
<th>Fixed</th>
<th>Enterprise</th>
<th>No Response</th>
</tr>
</thead>
<tbody>
<tr>
<td>63%</td>
<td>63%</td>
<td>50%</td>
<td>3%</td>
</tr>
</tbody>
</table>
<t>Answers for 1.B (29 respondents)</t>
<t>Even though this was an open question, some common answers can be found.</t>
<t>14
<ul>
<li>14 respondents (48%) highlighted issues related to IPv4 depletion. The reason to move
to IPv6 is to avoid private and/or overlapping addresses.</t>
<t>For 6 addresses.</li>
<li>6 respondents (20%) stated that 5G/IoT is a business incentive to introduce IPv6.</t>
<t>4 IPv6.</li>
<li>4 respondents (13%) also highlight highlighted that there is a National national regulation request to associate and enable IPv6
associated with the launch of 5G.</t>
<t>4 5G.</li>
<li>4 respondents (13%) consider considered IPv6 as a part of their innovation strategy or an enabler
for new services.</t>
<t>4 services.</li>
<li>4 respondents (13%) introduce introduced IPv6 because of Enterprise customers demand.</t>
<t>Answer enterprise customer demand.</li>
</ul>
<t>Answers for 1.C (30 respondents)</t>
<figure>
<artwork><![CDATA[
Ongoing In
<table align="center">
<name>Timeframe</name>
<thead>
<tr>
<th>Ongoing</th>
<th>In 12 months After months</th>
<th>After 12 months Don't answer
Timeframe 60% 33% 0% 7%
]]></artwork>
</figure>
<t>Answer months</th>
<th>No Response</th>
</tr>
</thead>
<tbody>
<tr>
<td>60%</td>
<td>33%</td>
<td>0%</td>
<td>7%</td>
</tr>
</tbody>
</table>
<t>Answers for 1.D (28 respondents for cellular, 27 for wireline)</t>
<figure>
<artwork><![CDATA[
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%
]]></artwork>
</figure>
<table align="center">
<name>Transition in Use: Cellular</name>
<thead>
<tr>
<th>Dual-Stack</th>
<th>464XLAT</th>
<th>MAP-T</th>
<th>No Response</th>
</tr>
</thead>
<tbody>
<tr>
<td>39%</td>
<td>21%</td>
<td>4%</td>
<td>36%</td>
</tr>
</tbody>
</table>
<table align="center">
<name>Transition in Use: Wireline</name>
<thead>
<tr>
<th>Dual-Stack</th>
<th>DS-Lite</th>
<th>6RD/6VPE</th>
<th>No Response</th>
</tr>
</thead>
<tbody>
<tr>
<td>59%</td>
<td>19%</td>
<td>4%</td>
<td>19%</td>
</tr>
</tbody>
</table>
<t>Question 2. Do you need to change network devices for the above goal?</t>
<t>a. If
<ol type="A">
<li>If yes, what kind of devices: CPE, or BNG/mobile core, or NAT?</t>
<t>b. Will NAT?</li>
<li>Will you start the transition of your metro or backbone metro, backbone, or backhaul network to support IPv6?</t>
<t>Answer IPv6?</li>
</ol>
<t>Answers for 2.A (30 respondents)</t>
<figure>
<artwork><![CDATA[
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%
]]></artwork>
</figure>
<t>Answer
<table align="center">
<name>Need to Change</name>
<thead>
<tr>
<th>Yes</th>
<th>No</th>
<th>No Response</th>
</tr>
</thead>
<tbody>
<tr>
<td>43%</td>
<td>33%</td>
<td>23%</td>
</tr>
</tbody>
</table>
<table align="center">
<name>What to Change</name>
<thead>
<tr>
<th>CPEs</th>
<th>Routers</th>
<th>BNG</th>
<th>CGN</th>
<th>Mobile core</th>
</tr>
</thead>
<tbody>
<tr>
<td>47%</td>
<td>27%</td>
<td>20%</td>
<td>33%</td>
<td>27%</td>
</tr>
</tbody>
</table>
<t>Answers for 2.B (22 respondents)</t>
<figure>
<artwork><![CDATA[
Yes Future No
Plans for transition 9% 9% 82%
]]></artwork>
</figure>
<table align="center">
<name>Plans for Transition</name>
<thead>
<tr>
<th>Yes</th>
<th>Future</th>
<th>No</th>
</tr>
</thead>
<tbody>
<tr>
<td>9%</td>
<td>9%</td>
<td>82%</td>
</tr>
</tbody>
</table>
</section>
<section title="Summary anchor="Appendix_B" numbered="true" toc="default">
<name>Summary of Questionnaire and Replies for enterprises" anchor="Appendix_B"> Enterprises</name>
<t>The Industry Network Technology Council (INTC) developed the following poll to
verify the need or willingness of medium-to-large US-based enterprises
for training and consultancy on IPv6 (https://industrynetcouncil.org/) <eref brackets="angle" target="https://industrynetcouncil.org/"/> in early 2021.</t>
<t>54 organizations provided an answer.</t> answers.</t>
<t>Question 1. How much IPv6 implementation have you done at your organization?
(54 respondents)</t>
<figure>
<artwork><![CDATA[
None 16.67%
Some
<table>
<name>IPv6 Implementation</name>
<tbody>
<tr>
<td>None</td>
<td>16.67%</td>
</tr>
<tr>
<td>Some people have gotten some training 16.67%
Many training</td>
<td>16.67%</td>
</tr>
<tr>
<td>Many people have gotten some training 1.85%
Website training</td>
<td>1.85%</td>
</tr>
<tr>
<td>Website is IPv6 enabled 7.41%
Most enabled</td>
<td>7.41%</td>
</tr>
<tr>
<td>Most equipment is dual-stacked 31.48%
Have dual-stacked</td>
<td>31.48%</td>
</tr>
<tr>
<td>Have an IPv6 transition plan for entire network 5.56%
Running network</td>
<td>5.56%</td>
</tr>
<tr>
<td>Running IPv6-only in many places 20.37%
Entire places</td>
<td>20.37%</td>
</tr>
<tr>
<td>Entire network is IPv6-only 0.00%
]]></artwork>
</figure> IPv6-only</td>
<td>0.00%</td>
</tr>
</tbody>
</table>
<t>Question 2. What kind of help or classes would you like to see INTC do? (
54 (54 respondents)</t>
<figure>
<artwork><![CDATA[
Classes/labs on IPv6 security 66.67%
Classes/labs on IPv6 fundamentals 55.56%
Classes/labs
<table align="center">
<name>Help/Classes from INTC</name>
<tbody>
<tr>
<td>Classes/labs on IPv6 security</td>
<td>66.67%</td>
</tr>
<tr>
<td>Classes/labs on IPv6 fundamentals</td>
<td>55.56%</td>
</tr>
<tr>
<td>Classes/labs on address planning/network conf. 57.41%
Classes/labs conf.</td>
<td>57.41%</td>
</tr>
<tr>
<td>Classes/labs on IPv6 troubleshooting 66.67%
Classes/labs troubleshooting</td>
<td>66.67%</td>
</tr>
<tr>
<td>Classes/labs on application conversion 35.19%
Other 14.81%
]]></artwork>
</figure> conversion</td>
<td>35.19%</td>
</tr>
<tr>
<td>Other</td>
<td>14.81%</td>
</tr>
</tbody>
</table>
<t>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)</t>
<figure>
<artwork><![CDATA[
Security 31.48%
Application conversion 25.93%
Training 27.78%
All the above 33.33%
Don't
<table align="center">
<name>Areas of Concern for IPv6 Implementation</name>
<tbody>
<tr>
<td>Security</td>
<td>31.48%</td>
</tr>
<tr>
<td>Application conversion</td>
<td>25.93%</td>
</tr>
<tr>
<td>Training</td>
<td>27.78%</td>
</tr>
<tr>
<td>All the above</td>
<td>33.33%</td>
</tr>
<tr>
<td>Don't know enough to answer 14.81%
Other 9.26%
]]></artwork>
</figure> answer</td>
<td>14.81%</td>
</tr>
<tr>
<td>Other</td>
<td>9.26%</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors of this document would like to thank <contact fullname="Brian Carpenter"/>, <contact fullname="Fred Baker"/>, <contact fullname="Alexandre Petrescu"/>, <contact fullname="Fernando Gont"/>,
<contact fullname="Barbara Stark"/>, <contact fullname="Haisheng Yu (Johnson)"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Gábor Lencse"/>, <contact fullname="Shuping Peng"/>, <contact fullname="Daniel Voyer"/>, <contact fullname="Daniel Bernier"/>,
<contact fullname="Hariharan Ananthakrishnan"/>, <contact fullname="Donavan Fritz"/>, <contact fullname="Igor Lubashev"/>, <contact fullname="Erik Nygren"/>, <contact fullname="Eduard Vasilenko"/>, and <contact fullname="Xipeng Xiao"/>
for their comments and review of this document.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Nalini Elkins">
<organization>Inside Products</organization>
<address>
<postal>
<street/>
<extaddr/>
<region/>
<code/>
<country/>
</postal>
<email>nalini.elkins@insidethestack.com</email>
</address>
</contact>
<contact fullname="Sébastien Lourdez">
<organization>Post Luxembourg</organization>
<address>
<postal>
<street/>
<extaddr/>
<region/>
<code/>
<country/>
</postal>
<email>sebastien.lourdez@post.lu</email>
</address>
</contact>
</section>
</back>
</rfc>