rfc9386xml2.original.xml   rfc9386.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site. <!ENTITY nbsp "&#160;">
The next line defines an entity named RFC2629, which contains the necessary <!ENTITY zwsp "&#8203;">
XML <!ENTITY nbhy "&#8209;">
for the reference element, and is used much later in the file. This XML co <!ENTITY wj "&#8288;">
ntains 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 variab
le
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 t
o 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">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4234.xml">
<!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 go
od idea to
actually use one for the template because it might have disappeared when yo
u come to test
this template. This is the form of the entity definition
&lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfc
s.xml">
corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The cita
tion 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 draf
t-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 cou
rse this doesn't
change when the draft version changes.
-->
<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">
]> ]>
<!-- Extra statement used by XSLT processors to control the output style. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ipr="trust200902" number="9386"
docName="draft-ietf-v6ops-ipv6-deployment-10"
<!-- Processing Instructions can be placed here but if you are editing obsoletes="6036"
with XMLmind (and maybe other XML editors) they are better placed updates=""
after the rfc element start tag as shown below. --> submissionType="IETF" consensus="true"
xml:lang="en"
<!-- Information about the document. tocInclude="true"
category values: std, bcp, info, exp, and historic tocDepth="3"
For Internet-Drafts, specify attribute "ipr". symRefs="true"
(ipr values are: full3667, noModification3667, noDerivatives3667), sortRefs="true"
Also for Internet-Drafts, can specify values for version="3">
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
category="info"
ipr="trust200902"
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 sectio
n,
otherwise, put inline -->
<?rfc editing="no" ?> <!-- When yes, insert editing marks: editing marks c
onsist of a
string such as <29> printed in the blank line a
t 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 sect
ion entries. -->
<?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsection
s... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others pr
efer
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 no
t starting each
main section on a new page but does not omit the blank lines between li
st items.
If subcompact is also "yes" the blank lines between list items are also
omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** --> <!-- xml2rfc v2v3 conversion 3.15.3 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="IPv6 Deployment Status">IPv6 Deployment Status</title>
if the <seriesInfo name="RFC" value="9386"/>
full title is longer than 42 characters --> <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
<title abbrev="">IPv6 Deployment Status</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<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> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Riesstrasse, 25</street> <street>Riesstrasse, 25</street>
<city>Munich</city> <city>Munich</city>
<code>80992</code> <code>80992</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>giuseppe.fioccola@huawei.com</email> <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> </address>
</author> </author>
<author fullname="Paolo Volpato" initials="P." surname="Volpato">
<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> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Via Lorenteggio, 240</street> <street>Via Lorenteggio, 240</street>
<city>Milan</city> <city>Milan</city>
<code>20147</code> <code>20147</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>paolo.volpato@huawei.com</email> <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> </address>
</author> </author>
<author fullname="Jordi Palet Martinez" initials="J." surname="Palet Martine
<author z">
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> <organization>The IPv6 Company</organization>
<address> <address>
<postal> <postal>
<street>Molino de la Navata, 75</street> <street>Molino de la Navata, 75</street>
<city>La Navata - Galapagar, Madrid</city> <city>La Navata - Galapagar, Madrid</city>
<code>28420</code> <code>28420</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>jordi.palet@theipv6company.com</email> <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> </address>
</author> </author>
<author fullname="Gyan S. Mishra" initials="G." surname="Mishra">
<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> <organization>Verizon Inc.</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country></country> <country/>
</postal> </postal>
<email>gyan.s.mishra@verizon.com</email> <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> </address>
</author> </author>
<author fullname="Chongfeng Xie" initials="C." surname="Xie">
<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> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country></country> <country/>
</postal> </postal>
<email>xiechf@chinatelecom.cn</email> <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> </address>
</author> </author>
<date month="April" year="2023"/>
<date year="2022"/> <!-- month="March" is no longer necessary <area/>
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 da
y and month
irrespective of the day. This silliness should be fixed in v1.31. -->
<!-- Meta-data Declarations -->
<!-- Notice the use of &amp; 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! -->
<workgroup>V6OPS</workgroup> <workgroup>V6OPS</workgroup>
<keyword>Survey</keyword>
<!-- The DTD allows multiple area and workgroup elements but only the first <keyword>Challenges</keyword>
one has any <keyword>IPv6-only</keyword>
effect on output. --> <keyword>Overlay</keyword>
<!-- You can add <keyword/> elements here. They will be incorporated into H <keyword>Underlay</keyword>
TML output <keyword>IPv4aaS</keyword>
files in a meta tag but they have no effect on text or nroff output. --
>
<abstract> <abstract>
<t>This document provides an overview of IPv6 deployment status in 2022. <t>This document provides an overview of the status of IPv6 deployment in 2022.
Specifically, it looks at the degree of adoption of IPv6 in the i ndustry, Specifically, it looks at the degree of adoption of IPv6 in the i ndustry,
analyzes the remaining challenges and proposes further investigat ions in analyzes the remaining challenges, and proposes further investiga tions in
areas where the industry has not yet taken a clear and unified areas where the industry has not yet taken a clear and unified
approach in the transition to IPv6. It obsoletes RFC 6036.</t> approach in the transition to IPv6. It obsoletes RFC 6036.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction"> <t><xref target="RFC6036" format="default"/> describes IPv6 deployment sce
narios that were adopted or
<t><xref target="RFC6036"></xref> described IPv6 deployment scena
rios adopted or
foreseen by a number of Internet Service Providers (ISPs) who res ponded to a technical questionnaire foreseen by a number of Internet Service Providers (ISPs) who res ponded to a technical questionnaire
in early 2010. In doing that, <xref target="RFC6036"></xref> prov ided practices and plans expected in early 2010, and <xref target="RFC6036" format="default"/> also provides practices and plans that were expected
to take place in the following years. to take place in the following years.
Since the publication of <xref target="RFC6036"></xref>, several Since the publication of <xref target="RFC6036" format="default"/
other documents have contributed to >, several other documents have contributed to
the IPv6 transition discussion in operational environments. To na the IPv6 transition discussion in operational environments. To na
me a few:<list> me a few:</t>
<t>- <xref target="RFC6180"></xref> discussed IPv6 deployment mod <ul spacing="normal">
els and transition mechanisms, <li><xref target="RFC6180" format="default"/> discusses IPv6 deployment
recommending those proven to be effective in operational networ models and transition mechanisms,
ks.</t> recommending those proven to be effective in operational networ
<t>- <xref target="RFC6883"></xref> provided guidance and suggest ks.</li>
ions for Internet content providers <li><xref target="RFC6883" format="default"/> provides guidance and sugg
and Application Service Providers (ASPs).</t> estions for Internet content providers
<t>- <xref target="RFC7381"></xref> introduced the guidelines of and Application Service Providers (ASPs).</li>
IPv6 deployment for enterprises.</t> <li><xref target="RFC7381" format="default"/> introduces the guidelines
</list></t> of IPv6 deployment for enterprises.</li>
</ul>
<t><xref target="RFC6540"></xref> recommended the support of IPv6 <t><xref target="RFC6540" format="default"/> recommends the support of IPv
to all IP-capable nodes. 6 to all IP-capable nodes.
It was referenced in the IAB Statement on IPv6 <xref target="IAB" It was referenced in the IAB statement on IPv6 <xref target="IAB"
/>, which represented format="default"/>, which represented
a major step in driving the IETF as well as other Standard Develo a major step in driving the IETF and other Standards Development
ping Organizations (SDOs) Organizations (SDOs)
towards using IPv6 in their works.</t> towards using IPv6 in their works.</t>
<t> In more recent times, organizations, such as ETSI, provided more contr
<t> In more recent times, organizations such as ETSI provided mor ibutions to the use of IPv6 in operational
e contributions to the use of IPv6 in operational environments, targeting IPv6 in different industry segments. As a
environments, targeting IPv6 in different industry segments. As a result, <xref target="ETSI-IP6-WhitePaper" format="default"/>
result, <xref target="ETSI-IP6-WhitePaper"/>, was published to provide an updated view on the IPv6 best practic
was published to provide an updated view on the IPv6 best practic es adopted so far, in particular, in the ISP domain. </t>
es adopted so far, in particular in the ISP domain. </t> <t>Considering all of the above, and after more than ten years since the p
ublication of <xref target="RFC6036" format="default"/>,
<t>Considering all of the above, and after more than ten years si
nce the publication of <xref target="RFC6036"></xref>
it is useful to assess the status of the transition to IPv6. it is useful to assess the status of the transition to IPv6.
Some reasons include:<list> Some reasons include:</t>
<t>- In some areas, the lack of IPv4 addresses forced both carrie <ul spacing="normal">
rs and content providers to shift <li>In some areas, the lack of IPv4 addresses forced both carriers and c
to IPv6 to support the introduction of new applications, in par ontent providers to shift
ticular in wireless networks.</t> to IPv6 to support the introduction of new applications, in par
<t>- Some governmental actions took place to encourage or even en ticular, in wireless networks.</li>
force the adoption of IPv6 in certain countries.</t> <li>Some governmental actions took place to encourage or even enforce th
<t>- Looking at the global adoption of IPv6, this seems to have r e adoption of IPv6 in certain countries.</li>
eached a threshold that justifies speaking of <li>Looking at the global adoption of IPv6, this seems to have reached a
end-to-end IPv6 connectivity, at least at the IPv6 service laye threshold that justifies speaking of
r.</t> end-to-end IPv6 connectivity, at least at the IPv6 service laye
</list></t> r.</li>
</ul>
<t>This document aims to provide a survey of the status of IPv6 d <t>This document aims to provide a survey of the status of IPv6 deployment
eployment and highlight both the and highlight both the
achievements and remaining obstacles in the transition to IPv6 ne tworks (and its coexistence with continued IPv4 services). achievements and remaining obstacles in the transition to IPv6 ne tworks (and its coexistence with continued IPv4 services).
The target is to give an updated view of the practices and plans The target is to give an updated view of the practices and plans
already described in <xref target="RFC6036"></xref>, already described in <xref target="RFC6036" format="default"/>
to encourage further actions and more investigations in those are to encourage further actions and more investigations in those are
as that are still under discussion, and to present as that are still under discussion and to present
the main incentives for the adoption of IPv6.</t> the main incentives for the adoption of IPv6.</t>
<t>This document is intended for a general audience interested in understa
<t>This document is intended for a general audience interested to nding
understand the status of IPv6 in different industries the status of IPv6 in different industries
and network domains. People who provide or use network services m ay find it useful for the transition to IPv6. and network domains. People who provide or use network services m ay find it useful for the transition to IPv6.
Also, people developing plans for IPv6 adoption in an organizatio n or in an industry may find information and Also, people developing plans for IPv6 adoption in an organizatio n or in an industry may find information and
references for their analysis. Attention is given to the differen t stages of the transition to IPv6 networks and services. references for their analysis. Attention is given to the differen t stages of the transition to IPv6 networks and services.
In particular, a terminology on the use of “IPv6-only” is provide d, considering IPv6-only networks and services as the In particular, terminology on the use of "IPv6-only" is provided, considering IPv6-only networks and services as the
final stage of such transition.</t> final stage of such transition.</t>
<t>The topics discussed in this document are organized into four main chap
ters.</t>
<ul spacing="normal">
<li><xref target="global_picture"/> reports data and analytics about the
status of IPv6.</li>
<li><xref target="survey"/> provides a survey of IPv6 deployments in dif
ferent environments, including
ISPs, enterprises, and universities.</li>
<li><xref target="deployment"/> describes the IPv6 deployment approaches
for Mobile Broadband (MBB),
Fixed Broadband (FBB), and enterprises.</li>
<li><xref target="challenges"/> analyzes the general challenges to be so
lved in the IPv6 transition.
Specific attention is given to operations, performance, and se
curity issues.</li>
</ul>
<section anchor="terms" 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 i
t is referring to.
In this regard, it may happen that only part of a service, a netw
ork, or even a node is in an IPv6-only scope, and the rest is not.
The most used terms in relation to the different scopes are liste
d below:</t>
<dl newline="true">
<dt>IPv6-only interface:</dt><dd> The interface of a node is configure
d 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.</dd>
<dt>IPv6-only node:</dt><dd> The node uses only IPv6. All interfaces o
f the host only have IPv6 addresses.</dd>
<dt>IPv6-only service:</dt><dd> It is used if, between the host's inte
rface and the interface of the content server,
all packet headers of the service session are IPv6.</dd>
<dt>IPv6-only overlay:</dt><dd> It is used if, between the end points
of the tunnels, all inner packet headers of the tunnels are IPv6.
For example, IPv6-only overlay in a fixed network means that th
e encapsulation is only IPv6 between the interfaces of the Provider Edge (PE) no
des
or between the Customer Provider Edge (CPE) node and the Broadb
and Network Gateway (BNG).</dd>
<dt>IPv6-only underlay:</dt><dd> It is used if the data plane and cont
rol plane are IPv6, but this is not necessarily true for the management plane.
For example, IPv6-only underlay in a fixed network means that t
he underlay network protocol is only IPv6 between any PE nodes,
but they can be Dual-Stack in overlay. Segment Routing over IPv
6 (SRv6) is an example of IPv6-only underlay.</dd>
<dt>IPv6-only network:</dt><dd> It is used if every node in this netwo
rk is IPv6-only. IPv4 should not exist in an IPv6-only network.
In particular, an IPv6-only network's data plane, control plane
, and management plane must be IPv6.
All PEs must be IPv6-only. Therefore, if tunnels exist among PE
s, 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, and similarly, an
IPv6-only backbone network means that every node in this backbo
ne network must be IPv6-only.</dd>
<dt>IPv4-as-a-Service (IPv4aaS):</dt><dd>IPv4 service support is provi
ded by means of a transition mechanism; therefore,
there is a combination of encapsulation/translation + IPv6-only
underlay + decapsulation/translation.
For an IPv6-only network, connectivity to legacy IPv4 is either
non-existent or provided by IPv4aaS mechanisms.</dd>
</dl>
<t>Note that IPv6-only definitions are also discussed in <xref target="I
-D.palet-v6ops-ipv6-only" format="default"/>.</t>
</section>
</section>
<section numbered="true" toc="default" anchor="global_picture">
<name>IPv6: The Global Picture</name>
<t>This section deals with some key questions related to IPv6, namely: (1)
the status of IPv4 exhaustion, often considered as one
of the triggers to switch to IPv6, (2) the number of IPv6 end use
rs, a primary measure to sense IPv6 adoption, (3) the percentage
of websites reachable over IPv6, and (4) a report on IPv6 public
actions and policies.</t>
<t>These parameters are monitored by the Regional Internet Registries (RIR
s) and other institutions worldwide, as they provide a first-order
indication on the adoption of IPv6.</t>
<section numbered="true" toc="default">
<name>IPv4 Address Exhaustion</name>
<t>According to <xref 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 about whether the IPv4 address space can sust
ain such a number of allocations and, consequently,
if this may affect the process of its exhaustion. The answer is not s
traightforward, as many aspects have to be considered.</t>
<t>On one hand, the RIRs are reporting scarcity of available and still-r
eserved addresses.
Table 3 of <xref target="POTAROO1" format="default"/> (January 20
22) 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 anot
her 12.1 million, for a total of 17.3 million IPv4 addresses
(-5.5% year over year, comparing 2021 against 2020).
Table 1 of <xref target="POTAROO1" format="default"/> shows that
the total IPv4 allocated pool equaled 3.685 billion addresses
(+0.027% year over year). The ratio between the available addres
ses 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 hand, <xref target="POTAROO1" format="default"/> again h
ighlights 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 r
egistration of an RIR or on the so-called grey market, where third parties opera
te to
enable the buying/selling of IPv4 addresses. In all cases, a set
of IPv4 addresses is "transferred" to a different holder that has the need to ex
pand their address range.
As an example, <xref target="IGP-GT" format="default"/> and <xref
target="NRO" format="default"/> show the amount of transfers to recipient organ
izations in the different regions.
Cloud Service Providers (CSPs) appear to be the most active in bu
ying IPv4 addresses to satisfy their need of providing IPv4 connectivity to thei
r tenants.
NAT systems provide a means to absorb at least a portion of the d
emand of public IPv4 addresses, as they enable the use of private addressing in
internal networks
while limiting the use of public addresses on their WAN-facing si
de.
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 ma
y make the network more complex.
In addition, multiple levels of address translation may coexist i
n a network, e.g., Carrier-Grade NAT (CGN) <xref target="RFC6264" format="defaul
t"/>,
based on two stages of translation. This comes with an economic a
nd operational burden, as discussed later in this document.</t>
<section numbered="true" toc="default">
<name>IPv4 Addresses per Capita and IPv6 Status</name>
<t>The IPv4 addresses per capita ratio measures the quantity of IPv4 a
ddresses allocated to a given country divided by the population of that country.
It provides an indication of the imbalanced distribution of the I
Pv4 addresses worldwide. It clearly derives from the allocation of addresses mad
e in
the early days of the Internet.</t>
<t>The sources for measuring the IPv4 addresses per capita ratio are t
he allocations done by the RIRs and the statistics about the world population.
In this regard, <xref target="POTAROO2" format="default"/> provid
es distribution files. The next tables compare the number of IPv4 addresses avai
lable per person
in a certain country (IPv4 address per capita) against th
e relative adoption of IPv6 in the same country (expressed as the number of IPv6
-capable users
in the considered country). The table shows just a subset
of the data available from <xref target="POTAROO2" format="default"/>. In parti
cular, 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, an
d the data refer
to 1 January 2022.</t>
<table anchor="table_1">
<t>The topics discussed in this document are organized into four <name>IPv4 per Capita and IPv6 Deployment for the Top 25 Most Popula
main chapters.<list> ted Countries in the World (as of January 2022)</name>
<t>Section 2 reports data and analytics about the status of IPv6.</t>
<t>Section 3 provides a survey of IPv6 deployments in different env
ironments, including
ISPs, enterprises and universities.</t>
<t>Section 4 describes the IPv6 deployment approaches for Mobil
e BroadBand (MBB),
Fixed BroadBand (FBB) and Enterprises.</t>
<t>Section 5 analyzes the general challenges to be solved in the IP
v6 transition.
Specific attention is given to operations, performance and secu
rity issues.</t>
</list></t>
<section anchor="terms" title="Terminology"> <thead>
<tr>
<th>Country</th>
<th>IPv4 per Capita</th>
<th>IPv6 Deployment</th>
</tr>
</thead>
<tbody>
<tr>
<t>This section defines the terminology regarding the usage of IPv6-only <td>United States of America</td>
expressions within this document. <td>4.89</td>
The term IPv6-only is defined in relation to the specific scope i <td>47.1%</td></tr><tr>
t is referring to.
In this regard, it may happen that only part of a service, of a n
etwork or even part of a node is in an IPv6-only scope and the rest is not.
Below are listed the most used terms in relation to the different
scopes:<list>
<t>IPv6-only interface: It means that the interface of a node i <td>United Kingdom</td>
s configured to forward only IPv6. <td>1.65</td>
This denotes that just part of the node can be IPv6-only since <td>33.2%</td>
the rest of the interfaces of the same node may work with IPv4 as well. </tr><tr>
A Dual-Stack interface is not an IPv6-only interface.</t>
<t>IPv6-only node: It means that the node uses only IPv6. All i <td>Japan</td>
nterfaces of the host only have IPv6 addresses.</t> <td>1.50</td>
<td>36.7%</td>
</tr><tr>
<t>IPv6-only service: It is used if between the host’s interfac <td>Germany</td>
e and the interface of the content server, <td>1.48</td>
all packet headers of the service session are IPv6.</t> <td>53.0%</td>
</tr><tr>
<t>IPv6-only overlay: It is used if between the end points of t <td>France</td>
he tunnels, all inner packet headers of the tunnels are IPv6. <td>1.27</td>
For example, IPv6-only overlay in fixed network means that the <td>42.1%</td>
encapsulation is only IPv6 between the interfaces of the Provider Edge (PE) node </tr><tr>
s
or between the Customer Provider Edge (CPE) node and the Broadb
and Network Gateway (BNG).</t>
<t>IPv6-only underlay: It is used if the data plane and control <td>Italy</td>
plane are IPv6, but not necessarily management plane. <td>0.91</td>
For example, IPv6-only underlay in fixed network means that the <td>4.7%</td>
underlay network protocol is only IPv6 between any Provider Edge (PE) nodes </tr><tr>
but they can be Dual-Stack in overlay. SRv6 is an example of IP
v6-only underlay.</t>
<t>IPv6-only network: It is used if every node in this network <td>South Africa </td>
is IPv6-only. No IPv4 should exist in an IPv6-only network. <td>0.46</td>
In particular, IPv6-only network’s data plane, control plane, a <td>2.4%</td>
nd management plane must be IPv6. </tr><tr>
All PEs must be IPv6-only. Therefore, if tunnels exist among PE
s, both inner and outer headers must be IPv6.
For example, IPv6-only access network means that every node in
this access network must be IPv6-only and similarly
IPv6-only backbone network means that every nodes in this backb
one network must be IPv6-only.</t>
<t>IPv4 as a Service (IPv4aaS): It means that IPv4 service supp <td>Brazil</td>
ort is provided by means of transition mechanism, therefore <td>0.41</td>
there is a combination of encapsulation/translation + IPv6-only <td>38.7%</td>
underlay + decapsulation/translation. </tr><tr>
For an IPv6-only network, connectivity to legacy IPv4 is either
non-existent or provided by IPv4aaS mechanisms.</t>
</list></t> <td>Russian Federation</td>
<td>0.31</td>
<td>9.7%</td>
</tr><tr>
<t>Note that IPv6-only definitions are also discussed in <xref target= <td>China </td>
"I-D.palet-v6ops-ipv6-only"/>.</t> <td>0.24</td>
<td>60.1%(*)</td>
</tr><tr>
</section> <td>Egypt</td>
<td>0.24</td>
<td>4.3%</td>
</tr><tr>
</section> <td>Mexico</td>
<td>0.23</td>
<td>41.8%</td>
</tr><tr>
<section title="IPv6: The Global Picture"> <td>Turkey</td>
<td>0.20</td>
<td>0.2%</td>
</tr><tr>
<t>This section deals with some key questions related to IPv6 namely: (1 <td>Vietnam</td>
) the status of IPv4 exhaustion, often considered as one <td>0.17</td>
of the triggers to switch to IPv6, (2) the number of IPv6 end use <td>48.0%</td>
rs, a primary measure to sense IPv6 adoption, (3) the percentage </tr><tr>
of websites reachable over IPv6 and (4) a report on IPv6 public a
ctions and policies.</t>
<t>These parameters are monitored by the Regional internet Regist <td>Iran (Islamic Republic)</td>
ries (RIRs) and other institutions worldwide as they provide a first-order <td>0.15</td>
indication on the adoption of IPv6.</t> <td>0.1%</td>
</tr><tr>
<section title="IPv4 Address Exhaustion"> <td>Thailand</td>
<td>0.13</td>
<td>40.8%</td>
</tr><tr>
<t>According to <xref target="CAIR"/> there will be 29.3 billion netw <td>Indonesia</td>
orked devices by 2023, up from 18.4 billion in 2018. <td>0.07</td>
This poses the question on whether the IPv4 address space can sustain <td>5.0%</td>
such a number of allocations and, consequently, </tr><tr>
if this may affect the process of its exhaustion. The answer is not s
traightforward as many aspects have to be considered.</t>
<t>On one hand, the RIRs are reporting scarcity of available and <td>Philippines</td>
still reserved addresses. <td>0.05</td>
Table 3 of <xref target="POTAROO1"/> (January 2022) shows that th <td>13.8%</td>
e available pool of the five RIRs at the end of 2021 counted </tr><tr>
5.2 million IPv4 addresses, while the reserved pool included anot
her 12 million, for a total of 17.3 million IPv4 addresses
(-5.5% year over year, comparing 2021 against 2020).
The same reference, in table 1, shows that the total IPv4 allocat
ed pool equaled to 3.685 billion addresses
(+0.027% year over year). The ratio between the available addres
ses and the total allocated brought to 0.469% of the remaining
IPv4 address space (from 0.474% at the end of 2020).</t>
<t>On the other, <xref target="POTAROO1"/> again highlights the r <td>India</td>
ole of both address transfer and Network Address Translation (NAT) to counter th <td>0.03</td>
e IPv4 exhaustion. <td>76.9%</td>
The transfer of IPv4 addresses can be done under the control or r </tr><tr>
egistration of a RIR or on the so-called grey market where third parties operate
to
enable the buy/sell of IPv4 addresses. In all cases, a set of IPv
4 addresses is “transferred” to a different holder that has the need to expand t
heir address range.
As an example, <xref target="IGP-GT"/> and <xref target="NRO"/> s
how the amount of transfers to recipient organizations in the different regions.
Cloud Service Providers (CSPs) appear to be the most active in bu
ying IPv4 addresses to satisfy their need of providing IPv4 connectivity to thei
r tenants.
NAT systems provide a means to absorb at least a portion of the d
emand of public IPv4 addresses as they enable the use of private addressing in i
nternal networks
while limiting the use of public addresses on their WAN-facing si
de.
In the case of NAT, architectural and operational issues remain.
Private address space cannot provide adequate address span,
especially for large organizations, and the reuse of addresses ma
y make the network more complex.
In addition, multiple levels of address translation may coexist i
n a network, e.g. Carrier-Grade NAT (CGN) <xref target="RFC6264"></xref>
based on two stages of translation. This comes with an economic a
nd operational burden, as discussed later in this document.</t>
<section title="IPv4 addresses per capita and IPv6 status"> <td>Pakistan</td>
<td>0.03</td>
<td>2.1%</td>
</tr><tr>
<t>The IPv4 addresses per capita ratio measures the quantity of I <td>United Republic of Tanzania</td>
Pv4 addresses allocated to a given country divided by the population of that cou <td>0.02</td>
ntry. <td>0.0%</td>
It provides an indication of the imbalanced distribution of the I </tr><tr>
Pv4 addresses worldwide. It clearly derives from the allocation of addresses mad
e in
the early days of the Internet.</t>
<t>The sources for measuring the IPv4 addresses per capita ratio <td>Nigeria</td>
are the allocations done by the RIRs and the statistics about the world populati <td>0.02</td>
on. <td>0.2%</td>
In this regard, <xref target="POTAROO2"/> provides distribution f </tr><tr>
iles. The next tables compare the number of IPv4 addresses available per person
in a certain country (IPv4 address per capita) against th
e relative adoption of IPv6 in the same country (expressed as the number of IPv6
capable users
in the considered country). The table shows just a subset
of the data available from <xref target="POTAROO2"/>. In particular, the follow
ing table
provides the data for the 25 most populated countries in
the world. The table is ordered based on the IPv4 addresses per capita ratio and
the data refer
to the 1st of January 2022.</t>
<figure anchor="table_1" title="IPv4 per capita and IPv6 deployment for th <td>Bangladesh</td>
e top 25 most populated countries in the world, 1st of January 2022"> <td>0.01</td>
<artwork><![CDATA[ <td>0.3%</td>
+----------------------------+---------------+---------------+ </tr><tr>
|Country |IPv4 per capita|IPv6 deployment|
+----------------------------+---------------+---------------+
|United States of America | 4.89| 47.1%|
+----------------------------+---------------+---------------+
|United Kingdom | 1.65| 33.2%|
+----------------------------+---------------+---------------+
|Japan | 1.50| 36.7%|
+----------------------------+---------------+---------------+
|Germany | 1.48| 53.0%|
+----------------------------+---------------+---------------+
|France | 1.27| 42.1%|
+----------------------------+---------------+---------------+
|Italy | 0.91| 4.7%|
+----------------------------+---------------+---------------+
|South Africa | 0.46| 2.4%|
+----------------------------+---------------+---------------+
|Brazil | 0.41| 38.7%|
+----------------------------+---------------+---------------+
|Russian Federation | 0.31| 9.7%|
+----------------------------+---------------+---------------+
|China | 0.24| 60.1%(*)|
+----------------------------+---------------+---------------+
|Egypt | 0.24| 4.3%|
+----------------------------+---------------+---------------+
|Mexico | 0.23| 41.8%|
+----------------------------+---------------+---------------+
|Turkey | 0.20| 0.2%|
+----------------------------+---------------+---------------+
|Vietnam | 0.17| 48.0%|
+----------------------------+---------------+---------------+
|Iran (Islamic Republic) | 0.15| 0.1%|
+----------------------------+---------------+---------------+
|Thailand | 0.13| 40.8%|
+----------------------------+---------------+---------------+
|Indonesia | 0.07| 5.0%|
+----------------------------+---------------+---------------+
|Philippines | 0.05| 13.8%|
+----------------------------+---------------+---------------+
|India | 0.03| 76.9%|
+----------------------------+---------------+---------------+
|Pakistan | 0.03| 2.1%|
+----------------------------+---------------+---------------+
|United Republic of Tanzania | 0.02| 0.0%|
+----------------------------+---------------+---------------+
|Nigeria | 0.02| 0.2%|
+----------------------------+---------------+---------------+
|Bangladesh | 0.01| 0.3%|
+----------------------------+---------------+---------------+
|Ethiopia | 0.00| 0.0%|
+----------------------------+---------------+---------------+
|Democratic Republic of Congo| 0.00| 0.1%|
+----------------------------+---------------+---------------+
]]></artwork> <td>Ethiopia</td>
</figure> <td>0.00</td>
<td>0.0%</td>
</tr><tr>
<t>(*) The IPv6 deployment information in China is derived from <x <td>Democratic Republic of Congo</td>
ref target="CN-IPv6"/>.</t> <td>0.00</td>
<td>0.1%</td>
</tr>
</tbody>
</table>
<t>A direct correlation between low IPv4 per capita and high IPv6 <t>(*) The IPv6 deployment information in China is derived from <xref
adoption is not immediate, yet some indications emerge. target="CN-IPv6" format="default"/>.</t>
For example, countries such as Brazil, China, and India have c <t>A direct correlation between low IPv4 per capita and high IPv6 adop
learly moved towards IPv6 adoption. As discussed later, tion is not immediate, yet some indications emerge.
For example, some countries, such as Brazil, China, and India,
have clearly moved towards IPv6 adoption. As discussed later,
this appears related to several factors in addition to the lac k of IPv4 addresses, including local regulation and this appears related to several factors in addition to the lac k of IPv4 addresses, including local regulation and
market-driven actions. market-driven actions.
The 5 countries at the top of the table, with relative high av ailability of IPv4 addresses, have also shown a good level The 5 countries at the top of the table, with relative high av ailability 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 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 l ow IPv6 adoption.</t> several countries listed in the table still have low or very l ow IPv6 adoption.</t>
</section>
</section> </section>
</section>
<section title="IPv6 Users"> <section numbered="true" toc="default">
<t>The count of the IPv6 users is the key parameter to get an imm <name>IPv6 Users</name>
ediate understanding of the adoption of IPv6. <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 aggregat ing data from several sources. As an example, Some organizations constantly track the usage of IPv6 by aggregat ing data from several sources. As an example,
the Internet Society constantly monitors the volume of IPv6 traff the Internet Society constantly monitors the volume of IPv6 traff
ic for the networks that joined the WorldIPv6Launch ic for the networks that joined the World IPv6 Launch
initiative <xref target="WIPv6L"></xref>. The measurement aggrega initiative <xref target="WIPv6L" format="default"/>. The measurem
tes statistics from organizations such as <xref target="Akm-stats"></xref> ent aggregates statistics from organizations, such as <xref target="Akm-stats" f
that provides data down to the single network level measuring the ormat="default"/>,
number of hits to their content delivery platform. that provide data down to the single network level, measuring the
number of hits to their content delivery platform.
For the scope of this document, the approach used by APNIC to qua ntify the adoption of IPv6 by means of a script that For the scope of this document, the approach used by APNIC to qua ntify the adoption of IPv6 by means of a script that
runs on a user's device <xref target="CAIDA"></xref> is considere d. runs on a user's device <xref target="CAIDA" format="default"/> i s considered.
To give a rough estimation of the relative growth of IPv6, the ne xt table aggregates the total number of estimated IPv6-capable users To give a rough estimation of the relative growth of IPv6, the ne xt table aggregates the total number of estimated IPv6-capable users
at 1st of January 2022, and compares it against the total Interne as of 1 January 2022 and compares it against the total Internet u
t users, as measured by <xref target="POTAROO2"/>.</t> sers, as measured by <xref target="POTAROO2" format="default"/>.</t>
<figure anchor="table_2" title="IPv6-capable users against total (in milli
ons) 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>
<t>Two figures appear: first, the IPv6 Internet population is gro <table anchor="table_2">
wing with a two-digits Compound Annual Growth Rate (CAGR), and <name>IPv6-Capable Users against Total Users (in Millions) as of Janua
second, the ratio IPv6 over total is also growing steadily.</t> ry 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>
</section> <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>
<section title="IPv6 Web Content"> <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>
<t><xref target="W3Techs"/> keeps track of the use of several technical com <td>Ratio</td>
ponents of websites worldwide through different analytical engines. <td>15.0%</td>
The utilization of IPv6 for websites is shown in the next table, where t <td>16.5%</td>
he percentages refer to the websites which are accessible over IPv6.</t> <td>24.3%</td>
<td>27.8%</td>
<td>29.5%</td>
<td>18.4%</td>
</tr>
</tbody>
</table>
<figure anchor="table_3" title="Usage of IPv6 in websites, January 2022 <t>Two figures appear: first, the IPv6 Internet population is growing wi
"> th a two-digit Compound Annual Growth Rate (CAGR), and
<artwork><![CDATA[ second, the ratio IPv6 over total is also growing steadily.</t>
</section>
<section numbered="true" toc="default">
<name>IPv6 Web Content</name>
<t><xref target="W3Techs" format="default"/> keeps track of the use of s
everal technical components of websites worldwide through different analytical e
ngines.
The utilization of IPv6 for websites is shown in the next table, where t
he percentages refer to the websites that are accessible over IPv6.</t>
<table anchor="table_3">
<name>Usage of IPv6 in Websites (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>
| Worldwide | Jan | Jan | Jan | Jan | Jan | CAGR | <td>11.4%</td>
| Websites | 2018 | 2019 | 2020 | 2021 | 2022 | | <td>13.3%</td>
+------------+-------+-------+-------+-------+-------+------+ <td>15.0%</td>
|% of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9%| <td>17.5%</td>
+------------+-------+-------+-------+-------+-------+------+ <td>20.6%</td>
]]></artwork> <td>15.9%</td>
</figure> </tr>
</tbody>
</table>
<t>Looking at the growth rate, it may appear not particularly high. <t>Looking at the growth rate, it may not appear particularly high.
It has to be noted, though, that not all websites are equal. The largest content providers, which already 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. support IPv6, generate a lot more content than small websites. At the be
<xref target="Csc6lab"/> measured at the beginning of January 2022 that ginning of January 2022,
out of the world top 500 sites ranked by <xref target="Csc6lab" format="default"/> measured that out of the world
<xref target="Alx"/>, 203 are IPv6-enabled (+3.6% from January 2021 to J 's top 500 sites, 203 are IPv6 enabled (+3.6% from January 2021 to January 2022)
anuary 2022). .
If we consider that the big content providers (such as Google, Facebook, If we consider that the big content providers (such as Google, Facebook,
Netflix) generate more than 50% of the total mobile traffic and Netflix) generate more than 50% of the total mobile traffic
<xref target="SNDVN"/>, and in some cases even more up to 65% (<xref tar <xref target="SNDVN" format="default"/>, and in some cases even more up
get="ISOC1"></xref> <xref target="HxBld"></xref>), the percentage to 65% <xref target="ISOC1" format="default"/> <xref target="HxBld" format="defa
of content accessible over IPv6 is clearly more relevant than the number ult"/>, the percentage
of enabled IPv6 websites. of content accessible over IPv6 is clearly more relevant than the number
It would be interesting to know what percentage of that 50% of all mobil of enabled IPv6 websites. Of that 50% of all mobile traffic,
e traffic is IPv6. Unfortunately, this information is not available.</t> it would be interesting to know what percentage is IPv6. Unfortunately,
this information is not available.</t>
<t>Related to that, a question that sometimes arises is whether the cont <t>Related to that, a question that sometimes arises is whether the cont
ent stored by content providers would ent stored by content providers would
be all accessible on IPv6 in the hypothetical case of a sudden IPv4 swit be all accessible on IPv6 in the hypothetical case of a sudden IPv4 swit
ch-off. Even if this is pure ch off. Even if this is pure
speculation, the numbers above may bring to state that this is likely th e case. This would reinforce the common thought that, in quantitative terms, speculation, the numbers above may bring to state that this is likely th e case. This would reinforce the common thought that, in quantitative terms,
most of the content is accessible via IPv6.</t> most of the content is accessible via IPv6.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IPv6 Public Actions and Policies</name>
<section title="IPv6 public actions and policies"> <t>As previously noted, the worldwide deployment of IPv6 is not uniform
<t>As previously noted, the worldwide deployment of IPv6 is not u <xref target="G_stats" format="default"/> <xref target="APNIC1" format="default
niform <xref target="G_stats"></xref>, <xref target="APNIC1"></xref>. "/>.
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 lo cal governments 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 lo cal governments
through regulation or incentive to the market. Looking at the Eur opean Union area, countries such as Belgium, France and Germany are well ahead i n terms of IPv6 through regulation or incentive to the market. Looking at the Eur opean Union area, some countries, such as Belgium, France, and Germany, are well ahead in terms of IPv6
adoption.</t> adoption.</t>
<t>In the case of Belgium, the Belgian Institute for Postal services and
<t>In the case of Belgium, the Belgian Institute for Postal servi Telecommunications (BIPT) acted to mediate an agreement between the local ISPs
ces and Telecommunications (BIPT) acted to mediate an agreement between the loca and
l ISPs and the government to limit the use of Carrier-Grade NAT (CGN) system
the government to limit the use of Carrier-Grade NAT (CGN) system s and of public IPv4 addresses for lawful investigations in 2012 <xref target="B
s and of public IPv4 addresses for lawful investigations in 2012 <xref target="B IPT" format="default"/>.
IPT"></xref>.
The agreement limited the use of one IPv4 address per 16 customer s behind NAT. The economic burden sustained by the ISPs for the unoptimized use of NAT induced The agreement limited the use of one IPv4 address per 16 customer s 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> the shift to IPv6 and its increased adoption in the latest years. </t>
<t>In France, the National Regulator (Autoritee de regulation des commun
ications electroniques, or Arcep) introduced an obligation for the mobile carrie
rs awarded
with a license to use 5G frequencies (3.4-3.8 GHz) in Metropolitan France
to be IPv6 compatible <xref target="ARCEP" format="default"/>.
As stated in <xref target="ARCEP" format="default"/> (translated from French),
</t>
<t>In France, the National Regulator (Autoriteé de régulation des <blockquote>The goal is to ensure that services are interoperable and
communications électroniques, or Arcep) introduced an obligation for the mobile to remove obstacles to using services that are only available in IPv6,
carriers awarded as the number of devices in use continues to soar, and because the
with a license to use 5G frequencies (3.4-3.8GHz) in Metropolitan RIPE NCC has run out of IPv4 addresses. </blockquote>
France to be IPv6 compatible <xref target="ARCEP"></xref>.
As stated, "the goal is to ensure that services are interoperable
and to remove obstacles to using services that are only available in IPv6, as t
he number of devices
in use continues to soar, and because the RIPE NCC has run out of
IPv4 addresses". A slow adoption of IPv6 could prevent new Internet services t
o widespread
or create a barrier to entry for newcomers to the market. "IPv6 c
an help to increase competition in the telecom industry, and help to industriali
ze a country
for specific vertical sectors".</t>
<t>Increased IPv6 adoption in Germany depended on a mix of indust <t>
ry and public actions. Specifically, the Federal Office for Information Technolo
gy
(under the Federal Ministry of the Interior) issued over the year
s a few recommendations on the use of IPv6 in the German public administration.
The latest guideline in 2019 constitutes a high-level road map fo
r mandatory IPv6 introduction in the federal administration networks <xref targe
t="GFA"></xref>.</t>
<t>In the United States, the Office of Management and Budget is a A slow adoption of IPv6 could prevent new Internet services from spreading widel
lso calling for IPv6 adoption <xref target="US-FR"></xref>, <xref target="US-CIO y
"></xref>. or create a barrier to entry for newcomers to the market. Per <xr
These documents define a plan to have the 80% of the US Federal I ef target="ARCEP" format="default"/> (translated from French), "IPv6 can help to
P-capable networks based on IPv6-only by the year 2025. increase competition in the telecom industry, and help to industrialize a count
China is another example of government which is supporting a coun ry
try-wide IPv6 adoption <xref target="CN"></xref>. for specific vertical sectors".</t>
In India, the high adoption of IPv6 took origin from the decision <t>Increased IPv6 adoption in Germany depended on a mix of industry and
of Reliance Jio to move to IPv6 in their networks <xref target="RelJio"></xref> public actions. Specifically, the Federal Office for Information Technology
. (under the Federal Ministry of the Interior) issued over the year
s a few recommendations on the use of IPv6 in the German public administration.
The latest guideline in 2019 constitutes a high-level road map fo
r mandatory IPv6 introduction in the federal administration networks <xref targe
t="GFA" format="default"/>.</t>
<t>In the United States, the Office of Management and Budget is also cal
ling for IPv6 adoption <xref target="US-FR" format="default"/> <xref target="US-
CIO" format="default"/>.
These documents define a plan to have 80% of the US federal IP-ca
pable networks based on IPv6-only by the year 2025.
China is another example of a government that is supporting a cou
ntry-wide IPv6 adoption <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" format=
"default"/>.
In addition, the Department of Telecommunications (under the Mini stry of Communications and Information Technology) issued guidelines for the In addition, the Department of Telecommunications (under the Mini stry 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> and fosters further moves to progressive adoption of IPv6 in public and private networks. The latest one dates 2021 <xref target="IDT" format="default"/> and fosters further moves to
IPv6 connection services.</t> IPv6 connection services.</t>
</section>
</section> </section>
<section anchor="survey" numbered="true" toc="default">
<name>A Survey on IPv6 Deployments</name>
<t>This section discusses the status of IPv6 adoption in service provider
and enterprise networks.</t>
<section numbered="true" toc="default">
<name>IPv6 Allocations</name>
<t>RIRs are responsible for allocating IPv6 address blocks to ISPs, Loca
l Internet Registries (LIRs), and
enterprises or other organizations. An ISP/LIR will use the alloc
ated 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" format="default"/>.</t>
<table anchor="table_4">
<name>IPv6 Allocations Worldwide (as of January 2022)</name>
<thead>
<tr>
</section> <th>Registry</th>
<th>Dec 2017</th>
<section anchor="survey" title="A Survey on IPv6 Deployments"> <th>Dec 2018</th>
<t>This section discusses the status of IPv6 adoption in service provider <th>Dec 2019</th>
s and enterprises’ networks.</t> <th>Dec 2020</th>
<th>Dec 2021</th>
<section title="IPv6 Allocations"> <th>Cumulated</th>
<t>RIRs are responsible for allocating IPv6 address blocks to ISP <th>CAGR</th>
s, LIRs (Local Internet Registries) </tr>
as well as enterprises or other organizations. An ISP/LIR will us </thead>
e the allocated block to assign addresses to their end users. <tbody>
The following table shows the amount of individual allocations, p <tr>
er RIR, in the time period 2017-2021 <xref target="APNIC2"/>.</t>
<figure anchor="table_4" title="IPv6 allocations worldwide in the period 2
017-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>
<t>The trend shows the steady progress of IPv6. <td>AFRINIC</td>
The decline of IPv6 allocations in 2020 and 2021 may be due to COVID-19 p <td>112</td>
andemic. It also happens to IPv4 allocations.</t> <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><xref target="APNIC2"/> also compares the number of allocations for bo <t>The trend shows the steady progress of IPv6.
th address families. The decline of IPv6 allocations in 2020 and 2021 may be due to the COVID-
19 pandemic. It also happened to IPv4 allocations.</t>
<t><xref 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 all ocations in comparison to the IPv6 allocations The CAGR looks quite similar in 2021 but a little higher for the IPv4 all ocations in comparison to the IPv6 allocations
(53.6% versus 50.9%).</t> (53.6% versus 50.9%).</t>
<table anchor="table_5">
<name>Allocations per Address Family (as of January 2022)</name>
<thead>
<tr>
<figure anchor="table_5" title="Allocations per address family"> <th>Address family</th>
<artwork><![CDATA[ <th>Dec 2017</th>
<th>Dec 2018</th>
+--------+-------+-------+-------+-------+-------+----------+------+ <th>Dec 2019</th>
| Address| Dec | Dec | Dec | Dec | Dec | Cumulated| CAGR | <th>Dec 2020</th>
| family | 2017 | 2018 | 2019 | 2020 | 2021 | | | <th>Dec 2021</th>
+--------+-------+-------+-------+-------+-------+----------+------+ <th>Cumulated</th>
| IPv6 | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 50.9%| <th>CAGR</th>
| | | | | | | | | </tr>
| IPv4 | 8,091 | 9,707 |13,112 | 6,263 | 7,829 | 45,002 | 53.6%| </thead>
| | | | | | | | | <tbody>
+--------+-------+-------+-------+-------+-------+----------+------+ <tr>
]]></artwork> <td>IPv6</td>
</figure> <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 ma ny allocations of small address ranges (e.g. /24) <xref target="APNIC2"/>. <t>The reason may be that the IPv4 allocations in 2021 included many all ocations of small address ranges (e.g., /24) <xref target="APNIC2" format="defau lt"/>.
On the contrary, a single IPv6 allocation is large enough to cope with the need of an operator for long period. On the contrary, a single IPv6 allocation is large enough to cope with the need of an operator for long period.
After an operator receives an IPv6 /30 or /32 allocation it is un After an operator receives an IPv6 /30 or /32 allocation, it is u
likely that a new request of addresses is repeated in the short term.</t> nlikely that a new request of addresses is repeated in the short term.</t>
<t>The next table is based on <xref target="APNIC3" format="default"/> a
<t>The next table is based on <xref target="APNIC3"/>, <xref targ nd <xref target="APNIC4" format="default"/> and shows the percentage of Autonomo
et="APNIC4"/> and shows the percentage of Autonomous us
Systems (AS) supporting IPv6 compared to the total ASes worldwide Systems (ASes) supporting IPv6 compared to the total ASes worldwi
. de.
The number of IPv6-capable ASes increased from 24.3% in January 2 018 to 38.7% in January 2022. The number of IPv6-capable ASes increased from 24.3% in January 2 018 to 38.7% in January 2022.
This equals to 18% CAGR for IPv6-enabled networks. In comparison, This equals to 18% of the CAGR for IPv6-enabled networks. In comp
the CAGR for the total of IPv6 and IPv4 networks is just 5%.</t> arison, the CAGR for the total of IPv6 and IPv4 networks is just 5%.</t>
<table anchor="table_6">
<figure anchor="table_6" title="Percentage of IPv6-capable ASes"> <name>Percentage of IPv6-Capable ASes (as of January 2022)</name>
<artwork><![CDATA[ <thead>
<tr>
+------------+-------+-------+-------+-------+-------+------+ <th>Advertised ASN</th>
| Advertised | Jan | Jan | Jan | Jan | Jan | CAGR | <th>Jan 2018</th>
| ASN | 2018 | 2019 | 2020 | 2021 | 2022 | | <th>Jan 2019</th>
+------------+-------+-------+-------+-------+-------+------+ <th>Jan 2020</th>
|IPv6-capable| 14,500| 16,470| 18,650| 21,400| 28,140| 18% | <th>Jan 2021</th>
| | | | | | | | <th>Jan 2022</th>
| Total ASN | 59,700| 63,100| 66,800| 70,400| 72,800| 5% | <th>CAGR</th>
| | | | | | | | </tr>
| Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | | </thead>
+------------+-------+-------+-------+-------+-------+------+ <tbody>
]]></artwork> <tr>
</figure>
<t>The tables above provide an aggregated view of the allocations <td>IPv6-capable</td>
dynamic. <td>14,500</td>
The next subsections will zoom into each specific domain to highl <td>16,470</td>
ight its relative status.</t> <td>18,650</td>
<td>21,400</td>
<td>28,140</td>
<td>18%</td>
</tr>
<tr>
</section> <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>
<section title="IPv6 among Internet Service Providers"> <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>As it was proposed at the time of <xref target="RFC6036"></xref>, als <t>The tables above provide an aggregated view of the allocations' dynam
o in the case of this document a survey was submitted to ic.
a group of service providers in Europe during the third quarter of 2020 The next subsections will zoom into each specific domain to highl
(see <xref target="Appendix_A"></xref> for the complete poll), ight its relative status.</t>
to understand their plans about IPv6 and their technical preferences tow </section>
ards its adoption. <section numbered="true" toc="default" anchor="ISPs">
Although such poll does not give an exhaustive view on the IPv6 status, <name>IPv6 among Internet Service Providers</name>
it provides some insights <t>A survey was submitted to
a group of service providers in Europe during the third quarter of 2020
(see <xref target="Appendix_A" format="default"/> for the complete poll)
to understand their plans about IPv6 and their technical preferences reg
arding its adoption.
Although this poll does not give an exhaustive view on the IPv6 status,
it provides some insights
that are relevant to the discussion.</t> that are relevant to the discussion.</t>
<t> The poll revealed that the majority of ISPs interviewed had plans co
<t> The poll revealed that the majority of the ISPs interviewed had plan ncerning IPv6 (79%).
s concerning IPv6 (79%). Of them, 60% had ongoing activities already, while 33% were expected to
Of them, 60% had already ongoing activities, while 33% was expected to s start activities
tart activities in a 12-month timeframe. The transition to IPv6 involved all business se
in a 12-months time-frame. The transition to IPv6 involved all business gments:
segments: mobile (63%), fixed (63%), and enterprise (50%).</t>
mobile (63%), fixed (63%), and enterprises (50%).</t> <t>The reasons to move to IPv6 varied.
Global IPv4 address depletion and the run out of private address space r
<t>The reasons to move to IPv6 varied. ecommended in <xref target="RFC1918" format="default"/>
Global IPv4 address depletion and the run out of private address space r
ecommended in <xref target="RFC1918"></xref>
were reported as the important drivers for IPv6 deployment (48%). were reported as the important drivers for IPv6 deployment (48%).
In a few cases, respondents cited the requirement of national IPv6 polic ies and the launch of 5G as the reasons (13%). In a few cases, respondents cited the requirement of national IPv6 polic ies and the launch of 5G as the reasons (13%).
Enterprise customers demand was also a reason to introduce IPv6 (13%).</ Enterprise customer demand was also a reason to introduce IPv6 (13%).</t
t> >
<t>From a technical preference standpoint, Dual-Stack <xref target="RFC4
<t>From a technical preference standpoint, Dual-Stack <xref target="RFC4213 213" format="default"/> was the most adopted solution
"></xref> was the most adopted solution,
in both wireline (59%) and cellular networks (39%). In wireline, the sec ond most adopted mechanism was Dual-Stack Lite (DS-Lite) in both wireline (59%) and cellular networks (39%). In wireline, the sec ond most adopted mechanism was Dual-Stack Lite (DS-Lite)
<xref target="RFC6333"></xref> (19%). In cellular networks, the second p <xref target="RFC6333" format="default"/> (19%). In cellular networks, t
reference was 464XLAT <xref target="RFC6877"></xref> (21%).</t> he second preference was 464XLAT <xref target="RFC6877" format="default"/> (21%)
.</t>
<t>More details about the answers received can be found in <xref target="Ap <t>More details about the answers received can be found in <xref target=
pendix_A"></xref>.</t> "Appendix_A" format="default"/>.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IPv6 among Enterprises</name>
<section title="IPv6 among Enterprises"> <t>As described in <xref target="RFC7381" format="default"/>, enterprise
s face different challenges than ISPs.
<t>As described in <xref target="RFC7381"></xref>, enterprises face differe
nt challenges than ISPs.
Publicly available reports show how the enterprise deployment of IPv6 la gs behind ISP deployment Publicly available reports show how the enterprise deployment of IPv6 la gs behind ISP deployment
<xref target="cmpwr"></xref>.</t> <xref target="cmpwr" format="default"/>.</t>
<t><xref target="NST_1" format="default"/> provides estimations on the d
<t><xref target="NST_1"></xref> provides estimations on deployment statu eployment status of IPv6 for domains
s of IPv6 for domains such as example.com, example.net, or example.org in the United States.
such as example.com, example.net or example.org in the United States.
The measurement encompasses many industries, including telecommunication s, so the term "enterprises" The measurement encompasses many industries, including telecommunication s, so the term "enterprises"
is a bit loose in this context. In any case, it provides a first indicat ion of IPv6 adoption in several is a bit loose in this context. In any case, it provides a first indicat ion of IPv6 adoption in several
US industry sectors. US industry sectors.
The analysis tries to infer whether IPv6 is supported by looking from "o utside" a company's network. It The analysis tries to infer whether IPv6 is supported by looking from "o utside" a company's network. It
takes into consideration the support of IPv6 to external services such a takes into consideration the support of IPv6 to external services, such
s Domain Name System (DNS), as Domain Name System (DNS),
mail and website. <xref target="BGR_1"></xref> has similar data for Chin mail, and websites. <xref target="BGR_1" format="default"/> has similar
a while <xref target="CNLABS_1"></xref> data for China, while <xref target="CNLABS_1" format="default"/>
provides the status in India.</t> provides the status in India.</t>
<table anchor="table_7">
<name>IPv6 Support for External-Facing Services across Enterprises (as
of January 2022)</name>
<thead>
<tr>
<figure anchor="table_7" title="IPv6 support for external-facing services <th>Country</th>
across enterprises (January 2022)"> <th>Domains analyzed</th>
<artwork><![CDATA[ <th>DNS</th>
<th>Mail</th>
+--------------+----------+---------+---------+---------+ <th>Website</th>
|Country | Domains | DNS | Mail | Website | </tr>
| | analyzed | | | | </thead>
+--------------+----------+---------+---------+---------+ <tbody>
|China | 478 | 74.7% | 0.0% | 19.7% | <tr>
| | | | | | <td>China</td>
+--------------+----------+---------+---------+---------+ <td>478</td>
|India | 104 | 51.9% | 15.4% | 16.3% | <td>74.7%</td>
| | | | | | <td>0.0%</td>
+--------------+----------+---------+---------+---------+ <td>19.7%</td>
|United States | 1070 | 66.8% | 21.2% | 6.3% | </tr>
|of America | | | | | <tr>
+--------------+----------+---------+---------+---------+ <td>India</td>
]]></artwork> <td>104</td>
</figure> <td>51.9%</td>
<td>15.4%</td>
<td>16.3%</td>
</tr>
<tr>
<td>United States 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>) <t>A poll submitted to a group of large enterprises in North America in early 2021 (see <xref target="Appendix_B" format="default"/>)
shows that the operational issues are even more critical than for ISPs.< /t> shows that the operational issues are even more critical than for ISPs.< /t>
<t>Looking at current implementations, almost one third has dual-stacked
<t>Looking at current implementations, almost one third has dual-stacked ne networks, while 20% declares that
tworks, while 20% declares that portions of their networks are IPv6-only.
portions of their networks are IPv6-only. 35% of the enterprises are stu Additionally, 35% of the enterprises did not implement IPv6 at all or are
ck at the training phase. stuck at the training phase.
In no case is the network fully IPv6-based.</t> In no case is the network fully based on IPv6.</t>
<t>Speaking of training, the most critical needs are in the field of IPv
<t>Speaking of training, the most critical needs are in the field of IPv6 s 6 security and IPv6 troubleshooting
ecurity and IPv6 troubleshooting (both highlighted by the two thirds of respondents), followed by address
(both highlighted by the two thirds of respondents), followed by IPv6 fu planning / network configurations (57.41%).</t>
ndamentals (57.41%).</t> <t>Coming to implementation, the three areas of concern are IPv6 securit
y (31.48%), training (27.78%), and
<t>Coming to implementation, the three areas of concern are IPv6 security ( application conversion (25.93%), and 33.33% of respondents think that al
31.48%), training (27.78%), l three areas are
application conversion (25.93%). 33.33% of respondents think that all th
ree areas are
all simultaneously of concern.</t> all simultaneously of concern.</t>
<t>The full poll is reported in <xref target="Appendix_B" format="defaul
<t>The full poll is reported in <xref target="Appendix_B"></xref>.</t> t"/>.</t>
<section numbered="true" toc="default">
<section title="Government and Universities"> <name>Government and Universities</name>
<t>This section focuses specifically on the adoption of IPv6 in govern
<t>This section focuses specifically on the IPv6 adoption of gove ments and academia.</t>
rnments and academia.</t> <t>As far as governmental agencies are concerned, <xref target="NST_2"
format="default"/> provides analytics on
<t>As far as governmental agencies are concerned, <xref target="N the degree of IPv6 support for DNS, mail, and websites across sec
ST_2"></xref> provides analytics on ond-level domains associated with US federal agencies.
the degree of IPv6 support for DNS, mail and websites across seco These domains are in the form of example.gov or example.fed. The
nd level domains associated with the US federal agencies. script used by <xref target="NST_2" format="default"/> has also been employed
These domains are in the form of example.gov or example.fed. The to measure the same analytics in other countries, e.g., China <xr
script used by <xref target="NST_2"></xref> has also been employed ef target="BGR_2" format="default"/>, India <xref target="CNLABS_2" format="defa
to measure the same analytics in other countries: China <xref tar ult"/>,
get="BGR_2"></xref>, India <xref target="CNLABS_2"></xref> and the European Union <xref target="IPv6Forum" format="default"/
and the European Union <xref target="IPv6Forum"></xref>. For this >. For this latter analytic, some post-processing is necessary to filter out
latter analytic some post-processing is necessary to filter out
the non-European domains.</t> the non-European domains.</t>
<table anchor="table_8">
<name>IPv6 Support for External-Facing Services across Governmental
Institutions (as of January 2022)</name>
<thead>
<tr>
<figure anchor="table_8" title="IPv6 support for external-facing services <th>Country</th>
across governmental institutions (January 2022)"> <th>Domains analyzed</th>
<artwork><![CDATA[ <th>DNS</th>
<th>Mail</th>
<th>Website</th>
</tr>
</thead>
<tbody>
<tr>
+--------------+----------+---------+---------+---------+ <td>China</td>
|Country | Domains | DNS | Mail | Website | <td>52</td>
| | analyzed | | | | <td>0.0%</td>
+--------------+----------+---------+---------+---------+ <td>0.0%</td>
|China | 52 | 0.0% | 0.0% | 98.1% | <td>98.1%</td>
| | | | | | </tr>
+--------------+----------+---------+---------+---------+ <tr>
|European | 19 | 47.4% | 0.0% | 21.1% |
|Union (*) | | | | |
+--------------+----------+---------+---------+---------+
|India | 618 | 7.6% | 6.5% | 7.1% |
| | | | | |
+--------------+----------+---------+---------+---------+
|United States | 1283 | 87.1% | 14.0% | 51.7% |
|of America | | | | |
+--------------+----------+---------+---------+---------+
]]></artwork> <td>European Union (*)</td>
</figure> <td>19</td>
<td>47.4%</td>
<td>0.0%</td>
<td>21.1%</td>
</tr>
<tr>
<t>(*) Both EU and country specific domains are considered.</t> <td>India</td>
<td>618</td>
<td>7.6%</td>
<td>6.5%</td>
<td>7.1%</td>
</tr>
<tr>
<t>USA's IPv6 support is higher than other countries. This is lik <td>United States of America</td>
ely due to the IPv6 mandate set by <xref target="US-CIO"></xref>. <td>1283</td>
<td>87.1%</td>
<td>14.0%</td>
<td>51.7%</td>
</tr>
</tbody>
</table>
<t>(*) Both EU and country-specific domains are considered.</t>
<t>IPv6 support in the US is higher than other countries. This is like
ly due to the IPv6 mandate set by <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, In the case of India, the degree of support seems still quite low . This is also true for China,
with the notable exception of high percentage of IPv6-enabled web with the notable exception of a high percentage of IPv6-enabled w
sites for government-related organizations.</t> ebsites for government-related organizations.</t>
<t>Similar statistics are also available for higher education. <xref t
<t>Similar statistics are also available for higher education. <x arget="NST_3" format="default"/> measures the data from second-level domains
ref target="NST_3"></xref> measures the data from second level domains of universities in the US, such as example.edu. <xref target="BGR
of universities in the US, such as example.edu. <xref target="BGR _3" format="default"/> looks at Chinese education-related domains.
_3"></xref> looks at Chinese education-related domains. <xref target="CNLABS_1" format="default"/> analyzes domains in In
<xref target="CNLABS_1"></xref> analyzes domains in India (mostly dia (mostly third level), while <xref target="IPv6Forum" format="default"/> list
third level), while <xref target="IPv6Forum"></xref> lists universities s universities
in the European Union (second level), again after filtering the n on-European domains.</t> in the European Union (second level), again after filtering the n on-European domains.</t>
<table anchor="table_9">
<name>IPv6 Support for External-Facing Services across Universities
(as of January 2022)</name>
<thead>
<tr>
<figure anchor="table_9" title="IPv6 support for external-facing services <th>Country</th>
across universities (January 2022)"> <th>Domains analyzed</th>
<artwork><![CDATA[ <th>DNS</th>
<th>Mail</th>
+--------------+----------+---------+---------+---------+ <th>Website</th>
|Country | Domains | DNS | Mail | Website | </tr>
| | analyzed | | | | </thead>
+--------------+----------+---------+---------+---------+ <tbody>
|China | 111 | 36.9% | 0.0% | 77.5% | <tr>
| | | | | | <td>China</td>
+--------------+----------+---------+---------+---------+ <td>111</td>
|European | 118 | 83.9% | 43.2% | 35.6% | <td>36.9%</td>
|Union | | | | | <td>0.0%</td>
+--------------+----------+---------+---------+---------+ <td>77.5%</td>
|India | 100 | 31.0% | 54.0% | 5.0% | </tr>
| | | | | | <tr>
+--------------+----------+---------+---------+---------+ <td>European Union</td>
|United States | 346 | 49.1% | 19.4% | 21.7% | <td>118</td>
|of America | | | | | <td>83.9%</td>
+--------------+----------+---------+---------+---------+ <td>43.2%</td>
<td>35.6%</td>
]]></artwork> </tr>
</figure> <tr>
<t>Overall, the universities have wider support of IPv6-based services c <td>India</td>
ompared to the other sectors. <td>100</td>
Apart from a couple of exceptions (e.g. the support of IPv6 mail <td>31.0%</td>
in China and IPv6 websites in India), <td>54.0%</td>
the numbers shown in the table above indicate a good support of I <td>5.0%</td>
Pv6 in academia.</t> </tr>
</section> <tr>
<td>United States 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., the support of IPv6 mail
in China and IPv6 websites in India),
the numbers shown in the table above indicate good support of IPv
6 in academia.</t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default" anchor="deployment">
</section> <name>IPv6 Deployment Scenarios</name>
<t>The scope of this section is to discuss the network and service scenari
<section title="IPv6 deployment scenarios"> os applicable for the transition to IPv6.
Most of the related definitions have been provided in <xref targe
<t>The scope of this section is to discuss the network and servic t="terms" format="default"/>. This clause is intended to focus on the technical
e scenarios applicable for the transition to IPv6. and operational characteristics.
Most of the related definitions have been provided in <xref targe The sequence of scenarios described here does not necessarily hav
t="terms"/>. This clause is intended to focus on the technical and operational c e to be intended as a road map for the IPv6 transition.
haracteristics.
The sequence of scenarios described here does not have necessaril
y to be intended as a road map for the IPv6 transition.
Depending on their specific plans and requirements, service provi ders may either adopt the scenarios proposed in a sequence or jump directly to a specific one.</t> Depending on their specific plans and requirements, service provi ders may either adopt the scenarios proposed in a sequence or jump directly to a specific one.</t>
<section numbered="true" toc="default">
<section title="Dual-Stack"> <name>Dual-Stack</name>
<t>Based on the poll answers provided by network operators (<xref target
<t>Based on the answers provided by network operators to the poll (<xref ="Appendix_A" format="default"/>), Dual-Stack <xref target="RFC4213" format="def
target="Appendix_A"></xref>), Dual-Stack <xref target="RFC4213"></xref> ault"/>
appears to be currently the most widely deployed IPv6 solution (a appears to be currently the most widely deployed IPv6 solution (a
bout 50%, see both <xref target="Appendix_A"></xref> and bout 50%; see both <xref target="Appendix_A" format="default"/> and
the statistics reported in <xref target="ETSI-IP6-WhitePaper"/>). the statistics reported in <xref target="ETSI-IP6-WhitePaper" for
</t> mat="default"/>).</t>
<t>With Dual-Stack, IPv6 can be introduced together with other network u
<t>With Dual-Stack, IPv6 can be introduced together with other network u pgrades, and many parts of network management
pgrades and many parts of network management and IT systems can still work in IPv4. This avoids a major upgrad
and IT systems can still work in IPv4. This avoids major upgrade e of such systems to support IPv6, which is possibly
of such systems to support IPv6, which is possibly
the most difficult task in the IPv6 transition. The cost and effo rt on the network management and IT systems upgrade the most difficult task in the IPv6 transition. The cost and effo rt on the network management and IT systems upgrade
are moderate. The benefits are to start using IPv6 and save NAT c osts.</t> are moderate. The benefits are to start using IPv6 and save NAT c osts.</t>
<t>Although Dual-Stack may provide advantages in the introductory stage,
<t>Although Dual-Stack may provide advantages in the introductory it does have a few disadvantages in the long run,
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) 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 addre sses are used with Carrier-Grade NAT (CGN), there is extra investment in the CGN devices, and Operating Expenses (OPEX). For example, even if private addre sses are used with Carrier-Grade NAT (CGN), there is extra investment in the CGN devices,
logs storage and help-desk to track CGN-related issues.</t> logs storage, and help desk to track CGN-related issues.</t>
<t>For this reason, when IPv6 usage exceeds a certain threshold, it may
<t>For this reason, when IPv6 usage exceeds certain threshold, it be advantageous to start a transition to the next scenario.
may be advantageous to start a transition to a next scenario.
For example, the process may start with the IPv4aaS stage, as des cribed hereinafter. For example, the process may start with the IPv4aaS stage, as des cribed hereinafter.
It is difficult to establish the criterion for switching (e.g. to properly identify the upper bound of the IPv4 decrease or the It is difficult to establish the criterion for switching (e.g., t o properly identify the upper bound of the IPv4 decrease or the
lower bound of the IPv6 increase). In addition to the technical f actors, the switch to the next scenarios may also cause a loss of customers. lower bound of the IPv6 increase). In addition to the technical f actors, the switch to the next scenarios may also cause a loss of customers.
Based on the feedback of network operators participating in World Based on the feedback of network operators participating in the W
IPv6 Launch <xref target="WIPv6L"></xref> in June 2021, 108 out of 346 operator orld IPv6 Launch <xref target="WIPv6L" format="default"/> in June 2021, 108 out
s of 346 operators
exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%), exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%),
while 37 exceed 75% (10.7%). 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> The consensus to move to IPv6-only might be reasonable when IPv6 traffic volume is between 50% and 60%.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IPv6-Only Overlay</name>
<section title="IPv6-only Overlay"> <t>As defined in <xref target="terms" format="default"/>, IPv6-only is g
enerally associated with a scope, e.g., IPv6-only overlay or IPv6-only underlay.
<t>As defined in <xref target="terms"/>, IPv6-only is generally a </t>
ssociated with a scope, 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.
<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 t o carry IPv6 traffic. IPv6 or IPv4 hosts and routers Tunneling provides a way to use an existing IPv4 infrastructure t o carry IPv6 traffic. IPv6 or IPv4 hosts and routers
can tunnel IPv6 packets over IPv4 regions by encapsulating them w ithin IPv4 packets. The approach with IPv6-only overlay helps can tunnel IPv6 packets over IPv4 regions by encapsulating them w ithin 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> 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 ti
<t>As a matter of fact, IPv4 reachability must be provided for a me to come over IPv6 for IPv6-only hosts. Most ISPs are leveraging
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 so lutions.</t> CGN to extend the life of IPv4 instead of going with IPv6-only so lutions.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IPv6-Only Underlay</name>
<section title="IPv6-only Underlay"> <t>The IPv6-only underlay network uses IPv6 as the network protocol for
all traffic delivery. Both the control and data planes are based on IPv6.
<t>IPv6-only underlay network uses IPv6 as the network protocol f
or all traffic delivery. Both the control and data planes are IPv6-based.
The definition of IPv6-only underlay needs to be associated with a scope in order to identify the domain where it is applicable, The definition of IPv6-only underlay needs to be associated with a scope in order to identify the domain where it is applicable,
such as IPv6-only access network or IPv6-only backbone network.</ such as the IPv6-only access network or IPv6-only backbone network.</t>
t>
<t>When both enterprises and service providers begin to transit from an
IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not necessarily
need to dual-stack the underlay. Forwarding plane complexity on t
he Provider (P) nodes of the ISP core should be kept simple as a single protocol
only backbone.
Hence, when operators decide to transit to an IPv6 underlay, the
ISP backbone should be IPv6-only while Dual-Stack is not the best choice.
The underlay could be IPv6-only and allows IPv4 packets to be tunneled u
sing VPN over an IPv6-only backbone and leveraging <xref target="RFC8950"></xref
>,
which specifies the extensions necessary to allow advertising IPv
4 Network Layer Routing Information (NLRI) with an IPv6 Next Hop.</t>
<t>IPv6-only underlay network deployment for access and backbone <t>When both enterprises and service providers begin to transition from
network, seems not the first option and the current trend is to keep IPv4/MPLS D an IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not necessarily
ata Plane need to 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.
Hence, when operators
decide to transition to an IPv6 underlay, the ISP backbone should be
IPv6-only because Dual-Stack is not the best choice.
The underlay
could be IPv6-only and allow IPv4 packets to be tunneled using a VPN
over an IPv6-only backbone while leveraging <xref target="RFC8950" format="de
fault"/>, which specifies
the extensions necessary to allow advertising IPv4 Network Layer
Reachability Information (NLRI) with an IPv6 next hop.</t>
<t>IPv6-only underlay network deployment for access and backbone network
s seems to not be the first option, and the current trend is to keep the IPv4/MP
LS data plane
and run IPv4/IPv6 Dual-Stack to edge nodes.</t> and run IPv4/IPv6 Dual-Stack to edge nodes.</t>
<t>As ISPs do the transition in the future to an IPv6-only access networ
<t>As ISPs do the transition in the future to an IPv6-only access k or backbone network, e.g., Segment Routing over IPv6 (SRv6) data plane, they s
network or backbone network, e.g. Segment Routing over IPv6 data plane (SRv6), tart
they start the elimination of IPv4 from the underlay transport network while
the elimination of IPv4 from the underlay transport network while continuing to provide IPv4 services. Basically, as also shown by the poll among
continuing to provide IPv4 services. Basically, as also showed by the poll amon network operators,
g network operators,
from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network per reasons mentioned above related t o the forwarding plane from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network per reasons mentioned above related t o the forwarding plane
complexities.</t> complexities.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IPv4-as-a-Service</name>
<section title="IPv4 as a Service"> <t>IPv4aaS can be used to ensure IPv4 support, and it can be a complex d
ecision that depends on several factors, such as economic aspects, policy, and g
<t>IPv4aaS can be used to ensure IPv4 support and it can be a complex de overnment
cision that depends on several factors, such as economic aspects, policy and gov
ernment
regulation.</t> regulation.</t>
<t><xref target="RFC9313" format="default"/> compares the merits of the
<t><xref target="RFC9313"/> compares the merits of the most commo most common transition solutions for IPv4aaS, i.e., 464XLAT <xref target="RFC687
n transition solutions for IPv4aaS, i.e. 464XLAT <xref target="RFC6877"></xref>, 7" format="default"/>,
DS-lite <xref target="RFC6333"></xref>, Lightweight 4over6 (lw4o6 DS-Lite <xref target="RFC6333" format="default"/>, Lightweight 4o
) <xref target="RFC7596"></xref>, MAP-E <xref target="RFC7597"></xref>, and ver6 (lw4o6) <xref target="RFC7596" format="default"/>, Mapping of Address and P
MAP-T <xref target="RFC7599"></xref>, but does not provide an exp ort with Encapsulation (MAP-E) <xref target="RFC7597" format="default"/>, and
licit recommendation. Mapping of Address and Port using Translation (MAP-T) <xref targe
However, the poll in <xref target="Appendix_A"></xref> indicates t="RFC7599" format="default"/>, but does not provide an explicit recommendation.
that the most widely deployed IPv6 transition solution in the Mobile Broadband ( However, the poll in <xref target="Appendix_A" format="default"/>
MBB) domain indicates that the most widely deployed IPv6 transition solution in the Mobile
is 464XLAT while in the Fixed Broadband (FBB) domain is DS-Lite.< Broadband (MBB) domain
/t> is 464XLAT, while in the Fixed Broadband (FBB) domain, it is DS-L
ite.</t>
<t>Both are IPv4aaS solutions by leveraging IPv6-only underlay. I <t>Both are IPv4aaS solutions that leverage IPv6-only underlay. IPv4aaS
Pv4aaS offers Dual-Stack service to users and allows an ISP offers Dual-Stack service to users and allows an ISP
to run IPv6-only in the network, typically the access network.</t > to run IPv6-only in the network, typically the access network.</t >
<t>While it may not always be the case, IPv6-only transition technologie
<t>While it may not always be the case, IPv6-only transition tech s, such as 464XLAT, require far fewer IPv4 addresses
nologies such as 464XLAT require far fewer IPv4 addresses <xref target="RFC9313" format="default"/>, because they are more
<xref target="RFC9313"/>, because they make a more efficient usag efficient and do not restrict the number of ports per subscriber.
e without restricting the number of ports per subscriber. This helps to reduce troubleshooting costs and to remove some ope
This helps to reduce troubleshooting costs and to remove some ope rational issues related to permanent block listing of IPv4 address blocks
rational issues related to permanent block-listing of IPv4 address blocks when used via CGN in some services.</t>
when used via CGN in some services.</t> <t>IPv4aaS may be facilitated by the natural upgrade or replacement of C
PEs because of newer technologies (triple-play, higher bandwidth WAN links,
<t>IPv4aaS may be facilitated by the natural upgrade or replaceme better Wi-Fi technologies, etc.). The CAPEX and OPEX of other par
nt of CPEs because of newer technologies (tripe-play, higher bandwidth WAN links ts of the network may be lowered (for example, CGN and associated logs)
,
better Wi-Fi technologies, etc.). The CAPEX and OPEX of other par
ts of the network may be lowered (for example CGN and associated logs)
due to the operational simplification of the network.</t> due to the operational simplification of the network.</t>
<t>For deployments with a large number of users (e.g., large mobile oper
<t>For deployments with a large number of users (e.g. large mobil ators) or a large number of hosts (e.g., large Data Centers (DCs)), even the ful
e operators) or a large number of hosts (e.g. large DCs), even the full private l private address space
address space <xref target="RFC1918" format="default"/> is not enough. Also, Du
<xref target="RFC1918"></xref> is not enough. Also, Dual-Stack wi al-Stack will likely lead to duplication of network resources and operations to
ll likely lead to duplication of network resources and operations to support bot support both IPv6 and IPv4,
h IPv6 and IPv4, which increases the amount of state information in the network.
which increases the amount of state information in the network. This suggests that, for scenarios such as MBB or large DCs, IPv4aaS
This suggests that for scenarios such as MBB or large DCs, IPv4aaS
could be more efficient from the start of the IPv6 introduction.< /t> could be more efficient from the start of the IPv6 introduction.< /t>
<t>So, in general, when the Dual-Stack disadvantages outweigh the IPv6-o
<t>So, in general, when the Dual-Stack disadvantages outweigh the nly complexity, it makes sense to transition to IPv4aaS.
IPv6-only complexity, it makes sense to transit to IPv4aaS. Some network operators have already started this process, as in t
Some network operators already started this process, as in the ca he case of <xref target="TMus" format="default"/>, <xref target="RelJio" format=
se of <xref target="TMus"></xref>, <xref target="RelJio"></xref> and <xref targe "default"/>, and <xref target="EE" format="default"/>.</t>
t="EE"></xref>.</t> </section>
<section numbered="true" toc="default">
</section> <name>IPv6-Only</name>
<t>IPv6-only is the final stage of the IPv6 transition, and it happens w
<section title="IPv6-only"> hen a complete network, end to end, no longer has IPv4.
No IPv4 address is configured for network management or anything
<t>IPv6-only is the final stage of the IPv6 transition and it hap else.</t>
pens when a complete network, end-to-end, no longer has IPv4. <t>Since IPv6-only means that both underlay networks and overlay service
No IPv4 address is configured for network management or anything. s are only IPv6, it will take longer to happen.</t>
</t> </section>
<t>Since IPv6-only means that both underlay network and overlay s
ervices are only IPv6, it will take longer to happen.</t>
</section>
</section> </section>
<section numbered="true" toc="default" anchor="challenges">
<section title="Common IPv6 Challenges"> <name>Common IPv6 Challenges</name>
<t>This section lists common IPv6 challenges, which have been validated a <t>This section lists common IPv6 challenges, which have been validated an
nd discussed during several meetings and public events. d discussed during several meetings and public events.
The scope is to encourage more investigations. Despite IPv6 has already b The scope is to encourage more investigations. Despite that IPv6 has alre
een well-proven in production, there are some challenges to consider. ady been well proven in production, there are some challenges to consider.
In this regard, it is worth noting that <xref target="ETSI-GR-IPE-001"></ In this regard, it is worth noting that <xref target="ETSI-GR-IPE-001" fo
xref> also discusses gaps that still exist in IPv6 related use cases.</t> rmat="default"/> also discusses gaps that still exist in IPv6-related use cases.
</t>
<section title="Transition Choices"> <section numbered="true" toc="default">
<t>A service provider, an enterprise or a CSP may perceive quite a comple <name>Transition Choices</name>
x task the transition to IPv6, due to the many technical alternatives available <t>A service provider, an enterprise, or a CSP may perceive quite a comp
lex task with the transition to IPv6 due to the many technical alternatives avai
lable
and the changes required in management and operations. Moreover, the choi ce of the method to support the transition is an important challenge and and the changes required in management and operations. Moreover, the choi ce 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 d esign that fits the service requirements, the network operations and may depend on factors specific to the context, such as the IPv6 network d esign that fits the service requirements, the network operations, and
the deployment strategy.</t> the deployment strategy.</t>
<t>The subsections below briefly highlight the approaches that the diffe
<t>This section briefly highlights the approaches that the different part rent parties may take and the related challenges.</t>
ies may take and the related challenges.</t> <section numbered="true" toc="default">
<name>Service Providers: Fixed and Mobile Operators</name>
<section title="Service Providers"> <t>For fixed operators, the massive software upgrade of CPEs to suppor
t Dual-Stack already started in most of the service provider networks.
<t>For fixed operators, the massive software upgrade of CPEs to s On average, looking at the global statistics, the IPv6 traffic pe
upport Dual-Stack already started in most of the service provider networks. rcentage is currently around 40% <xref target="G_stats" format="default"/>.
On average, looking at the global statistics, the IPv6 traffic pe As highlighted in <xref target="ISPs"/>, all major content provid
rcentage is currently around 40% <xref target="G_stats"></xref>. ers have already implemented Dual-Stack access to their services, and most of th
As highlighted in section 3.2, all major content providers have a em
lready implemented Dual-Stack access to their services and most of them
have implemented IPv6-only in their Data Centers. This aspect cou ld affect the decision on the IPv6 adoption for an operator, have implemented IPv6-only in their Data Centers. This aspect cou ld affect the decision on the IPv6 adoption for an operator,
but there are also other factors like the current IPv4 address sh but there are also other factors, like the current IPv4 address s
ortage, CPE costs, CGN costs and so on.<list> hortage, CPE costs, CGN costs, and so on.</t>
<ul empty="false" spacing="normal">
<t>Fixed Operators with a Dual-Stack architecture, can start defining <li>Fixed operators with a Dual-Stack architecture can start definin
and apply a new strategy when reaching the limit in terms of number g and applying a new strategy when reaching the limit in terms of the number
of IPv4 addresses available. This may be done through CGN or wi of IPv4 addresses available. This may be done through CGN or wi
th an IPv4aaS approach.</t> th an IPv4aaS approach.</li>
<li>Most of the fixed operators remain attached to a Dual-Stack arch
<t>Most of the fixed operators remain attached to a Dual-Stack itecture, and many have already employed CGN. In this case,
architecture and many have already employed CGN. In this case
it is likely that CGN boosts their ability to supply IPv4 conne ctivity to CPEs for more years to come. Indeed, only few it is likely that CGN boosts their ability to supply IPv4 conne ctivity to CPEs for more years to come. Indeed, only few
fixed operators have chosen to move to an IPv6-only scenario.</ fixed operators have chosen to move to an IPv6-only scenario.</
t> li>
</ul>
</list></t> <t>For mobile operators, the situation is quite different, since in so
me cases, mobile operators are already stretching their IPv4 address space.
<t>For mobile operators, the situation is quite different since, in s The reason is that CGN translation limits have been reached and n
ome cases, mobile operators are already stretching their IPv4 address space. o more IPv4 public pool addresses are available.</t>
The reason is that CGN translation limits have been reached and n <ul empty="false" spacing="normal">
o more IPv4 public pool addresses are available.<list> <li>Some mobile operators choose to implement Dual-Stack as a first
and immediate mitigation solution.</li>
<t>Some mobile operators choose to implement Dual-Stack as firs <li>Other mobile operators prefer to move to IPv4aaS solutions (e.g.
t and immediate mitigation solution.</t> , 464XLAT) since Dual-Stack only mitigates and does not solve the
IPv4 address scarcity issue completely.</li>
<t>Other mobile operators prefer to move to IPv4aaS solutions ( </ul>
e.g. 464XLAT) since Dual-Stack only mitigates and does not solve completely the <t>For both fixed and mobile operators, the approach for the transitio
IPv4 address scarcity issue.</t> n is not unique, and this brings different challenges in relation to the
network architecture and related costs; therefore, each operator
</list></t> needs to do their own evaluations for the transition based on the specific situa
tion.</t>
<t>For both fixed and mobile operators the approach for the trans </section>
ition is not unique and this brings different challenges in relation to the <section numbered="true" toc="default">
network architecture and related costs. So each operator needs to <name>Enterprises</name>
do own evaluations for the transition based on the specific situation.</t> <t>At present, the usage of IPv6 for enterprises often relies on upstr
eam service providers, since the enterprise connectivity depends on the services
</section> provided
by their upstream provider. Regarding the enterprises' internal i
<section title="Enterprises"> nfrastructures, IPv6 shows its advantages in the case of a merger and acquisitio
n, because
<t>At present, the usage of IPv6 for enterprises often relies on it can be avoided by the overlapping of the two address spaces, w
upstream service providers, since the enterprise connectivity depends on the ser hich is common in case of IPv4 private addresses. In addition, since several gov
vices provided ernments
by their upstream provider. Regarding the enterprises internal in are introducing IPv6 policies, all the enterprises providing cons
frastructure, IPv6 shows its advantages in the case of merger and acquisition, b ulting services to governments are also required to support IPv6.</t>
ecause <t>However, enterprises face some challenges. They are shielded from I
it can be avoided the overlapping of the two address spaces, whic Pv4 address depletion issues due to their prevalent use of proxy and private add
h is common in case of IPv4 private addresses. In addition, since several govern ressing
ments <xref target="RFC1918" format="default"/>; thus, they do not have
are introducing IPv6 policy, all the enterprises providing consul the business requirement or technical justification to transition to IPv6. Ente
ting service to governments are also required to support IPv6.</t> rprises need to find a business case
and a strong motivation to transition to IPv6 to justify addition
<t>However, enterprises face some challenges. They are shielded f al CAPEX and OPEX. Also, since Information and Communication Technologies (ICTs)
rom IPv4 address depletion issues due to their prevalent use of Proxy and privat are not the core business
e addressing for most of the enterprises, the ICT budget is often constrained
<xref target="RFC1918"></xref>, thus do not have the business req and cannot expand considerably.
uirement or technical justification to transit to IPv6. Enterprises need to find However, there are examples of big enterprises that are consideri
a business case ng IPv6 to achieve business targets through a more efficient IPv6 network and to
and a strong motivation for IPv6 transition to justify additional introduce newer services
CAPEX and OPEX. Also, since Information and Communication Technologies (ICT) is that require IPv6 network architecture.</t>
not the core business <t>Enterprises worldwide, in particular small- and medium-sized enterp
for most of the enterprises, ICT budget is often constrained and rises, are quite late to adopt IPv6, especially on internal networks. In most ca
cannot expand considerably. ses,
But, there are examples of big enterprises that are considering I the enterprise engineers and technicians do not have a great expe
Pv6 to achieve business targets through a more efficient IPv6 network and to int rience with IPv6, and the problem of application porting to IPv6 looks quite dif
roduce newer services ficult.
which require IPv6 network architecture.</t> As highlighted in the relevant poll, the technicians may need to
be trained, but the management does not see a business need for adoption.
<t>Enterprises worldwide, in particular small and medium-sized, a
re quite late to adopt IPv6, especially on internal networks. In most cases,
the enterprise engineers and technicians do not have a great expe
rience with IPv6 and the problem of application porting to IPv6 looks quite diff
icult.
As highlighted in the relevant poll, the technicians may need to
get trained but the management do 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 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 adoptio n of IPv6. combine with the lack of urgent business needs to prevent adoptio n of IPv6.
In 2019 and 2020, there has been a concerted effort by some ARIN In 2019 and 2020, there has been a concerted effort by some ARIN
and APNIC initiatives to provide training <xref target="ARIN-CG"></xref> and APNIC initiatives to provide training <xref target="ARIN-CG" format="defaul
<xref target="ISIF-ASIA-G"></xref>.</t> t"/>
<xref target="ISIF-ASIA-G" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Industrial Internet"> <name>Industrial Internet</name>
<t>In an industrial environment, Operational Technology (OT) refers to
<t>In an industrial environment, OT (Operational technology) refe the systems used to monitor and control
rs to the systems used to monitor and control processes within a factory or production environment, while Infor
processes within a factory or production environment, while IT (I mation Technology (IT) refers to anything related
nformation technology) refers to anything related to computer technology and networking connectivity. IPv6 is frequ
to computer technology and networking connectivity. IPv6 is frequ ently mentioned in relation to Industry 4.0 and the Internet of Things (IoT),
ently mentioned in relation to Industry 4.0 and Internet of Things (IoT), affecting the evolution of both OT and IT.</t>
affecting both OT and IT evolution.</t> <t>There are potential advantages for using IPv6 for the Industrial In
ternet of Things (IIoT), in particular, the large IPv6 address space,
<t>There are potential advantages for using IPv6 for Industrial I the automatic IPv6 address configuration, and resource discovery.
nternet of Things (IIoT), in particular the large IPv6 address space, However, its industrial adoption, in particular, in smart manufacturing systems
the automatic IPv6 address configuration and resource discovery. ,
However, its industrial adoption, in particular in smart manufacturing systems,
has been much slower than expected. There are still many obstacle s and challenges that prevent its pervasive use. The key problems identified are has been much slower than expected. There are still many obstacle s and challenges that prevent its pervasive use. The key problems identified are
the incomplete or underdeveloped tool support, the dependency on the incomplete or underdeveloped tool support, the dependency on
manual configuration and the poor knowledge of the IPv6 protocols. manual configuration, and the poor knowledge of the IPv6 protocols.
To promote the use of IPv6 for smart manufacturing systems and II To promote the use of IPv6 for smart manufacturing systems and II
oT applications a generic approach to remove these pain points is highly desirab oT applications, a generic approach to remove these pain points is highly desira
le. ble.
Indeed, as for enterprises, it is important to provide an easy wa y to familiarize system architects and software developers with the IPv6 protoco l.</t> Indeed, as for enterprises, it is important to provide an easy wa y to familiarize system architects and software developers with the IPv6 protoco l.</t>
<t>Advances in cloud-based platforms and developments in artificial in
<t>Advances in cloud-based platforms and developments in artifici telligence (AI) and machine learning (ML) allow OT and IT systems
al intelligence (AI) and machine learning (ML) allow OT and IT systems to integrate and migrate to a centralized analytical, processing,
to integrate and migrate to a centralized analytical, processing, and integrated platform, which must act in real time.
and integrated platform, which must act in real-time. The limitation is that manufacturing companies have diverse corpo
The limitation is that manufacturing companies have diverse corpo rate cultures, and the adoption of new technologies may lag as a result.</t>
rate 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 configurationless characteristic of IPv6
<t>For Industrial Internet and related IIoT applications, it woul to automatically manage and control the IoT devices. In addition,
d be desirable to leverage the configuration-less characteristic of IPv6 it could be interesting to have the ability to use IP-based communication and
to automatically manage and control the IoT devices. In addition,
it could be interesting to have the ability to use IP based communication and
standard application protocols at every point in the production p rocess and further reduce the use of specialized communication systems.</t> standard application protocols at every point in the production p rocess and further reduce the use of specialized communication systems.</t>
</section>
</section> <section anchor="cloud-dcs" numbered="true" toc="default">
<name>Content and Cloud Service Providers</name>
<section anchor="cloud-dcs" title="Content and Cloud Service Provider <t>The high number of addresses required to connect the virtual and ph
s"> ysical elements in a Data Center and the necessity to overcome the limitation po
sed
<t>The high number of addresses required to connect the virtual a by <xref target="RFC1918" format="default"/> have been the driver
nd physical elements in a Data Center and the necessity to overcome the limitati s to the adoption of IPv6 in several CSP networks.</t>
on posed <t>Most CSPs have adopted IPv6 in their internal infrastructure but ar
by <xref target="RFC1918"></xref> have been the drivers to the ad e also active in gathering IPv4 addresses on the transfer market to serve the
option of IPv6 in several CSP networks.</t>
<t>Most CSPs have adopted IPv6 in their internal infrastructure b
ut are also active in gathering IPv4 addresses on the transfer market to serve t
he
current business needs of IPv4 connectivity. As noted in the prev ious section, most enterprises do not consider the transition to IPv6 as a prior ity. current business needs of IPv4 connectivity. As noted in the prev ious section, most enterprises do not consider the transition to IPv6 as a prior ity.
To this extent, the use of IPv4-based network services by the CSP s will last.</t> To this extent, the use of IPv4-based network services by the CSP s will last.</t>
<t>Several public references, as reported hereinafter, discuss how mos
<t>Several public references, as reported hereinafter, discuss ho t of the major players find themselves at different stages
w most of the major players find themselves at different stages
in the transition to IPv6-only in their Data Center (DC) infrastr ucture. in the transition to IPv6-only in their Data Center (DC) infrastr ucture.
In some cases, the transition already happened and the DC infrast ructure of these hyperscalers is completely based on IPv6.</t> In some cases, the transition already happened and the DC infrast ructure of these hyperscalers is completely based on IPv6.</t>
<t>It is interesting to look at how much traffic in a network is going
<t>It is interesting to look at how much traffic in a network is goin to Caches and Content Delivery Networks (CDNs). The response is expected to be
g 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,
a high percentage, at least higher than 50% in most of the cases, since all the key Caches and CDNs are ready for IPv6 <xref target="Cldflr" form
since all the key Caches and CDNs are IPv6-ready <xref target="Cldflr"></xref>, at="default"/>
<xref target="Ggl"></xref>, <xref target="Ntflx"></xref>, <xref t <xref target="Ggl" format="default"/> <xref target="Ntflx" format
arget="Amzn"></xref>, <xref target="Mcrsft"></xref>, ="default"/> <xref target="Amzn" format="default"/> <xref target="Mcrsft" format
<xref target="Vrzn"></xref>. So the percentage of traffic going t ="default"/>. So the percentage of traffic going to the key Caches/CDNs is a goo
o the key Caches/CDNs is a good approximation of the potential IPv6 traffic in a d approximation of the potential IPv6 traffic in a network.</t>
network.</t> <t>The challenges for CSPs are mainly related to the continuous suppor
t of IPv4 to be guaranteed, since most CSPs already completed the transition to
<t>The challenges for CSPs are mainly related to the continuous s IPv6-only.
upport of IPv4 to be guaranteed, since most CSPs already completed the transitio
n to IPv6-only.
If, in the next years, the scarcity of IPv4 addresses becomes mor e evident, it is likely that the cost of buying an IPv4 address by a CSP could b e charged If, in the next years, the scarcity of IPv4 addresses becomes mor e evident, it is likely that the cost of buying an IPv4 address by a CSP could b e charged
to their customers.</t> to their customers.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="CPEs and user devices"> <name>CPEs and User Devices</name>
<t>It can be noted that most of the user devices (e.g. smartphone <t>It can be noted that most of the user devices (e.g., smartphones) h
s) are already IPv6-enabled since many years. But there are exceptions, for exam ave been IPv6 enabled for many years. But there are exceptions, for example, for
ple, smartTVs the past few years, smart TVs
typically had IPv6 support since few years ago, however not all t have typically had IPv6 support; however, not all the economies r
he economies replace them at the same pace.</t> eplace them at the same pace.</t>
<t>As already mentioned, ISPs who historically provided public IPv4 ad
<t>As already mentioned, ISPs who historically provided public IPv4 a dresses to their customers generally still have those IPv4 addresses (unless the
ddresses to their customers generally still have those IPv4 addresses (unless th y chose to
ey chose to transfer them). Some have chosen to put new customers on CGN but
transfer them). Some have chosen to put new customers on CGN but without touching existing customers. Because of the extremely small number of cu
without touching existing customers. Because of the extreme small number of cust stomers who notice
omers who notice that IPv4 is done via NAT444 (i.e., the preferred CGN solution fo
that IPv4 is done via NAT444 (i.e. the preferred CGN solution for r carriers), it could be less likely to run out of IPv4 addresses and private IP
carriers), it could be less likely to run out of IPv4 addresses and private IPv v4 space. But as IPv4-only devices and traffic reduce, the need to support priva
4 space. te and public IPv4 lessens.
But as IPv4-only devices and traffic reduce, then the need to sup So to have CPEs completely support IPv6 serves as an important
port private and public IPv4 become less. So the complete support of CPEs to IPv challenge and incentive to choose IPv4aaS solutions <xref target=
6 is also "ANSI" format="default"/>
an important challenge and incentive to overcome Dual-Stack towar over Dual-Stack.</t>
ds IPv4aaS solution <xref target="ANSI"></xref>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Software Applications"> <name>Software Applications</name>
<t>The transition to IPv6 requires that the application software is ad
<t>The transition to IPv6 requires that the application software is a apted for use in IPv6-based networks (<xref target="ARIN-SW" format="default"/>
dapted for use in IPv6-based networks (<xref target="ARIN-SW"></xref> provides a provides an example).
n example).
The use of transition mechanisms like 464XLAT is essential to support IPv4-only applications while they evolve to IPv6. The use of transition mechanisms like 464XLAT is essential to support IPv4-only applications while they evolve to IPv6.
Depending on the transition mechanism employed some issues may remain Depending on the transition mechanism employed, some issues may remai
. For example, in the case of NAT64/DNS64 the use of literal IPv4 addresses, n. For example, in the case of NAT64/DNS64, the use of literal IPv4 addresses,
instead of DNS names, will fail, unless mechanisms such as Applicatio instead of DNS names, will fail unless mechanisms such as Application
n Level Gateways (ALG) are used. This issue is not present in 464XLAT Level Gateways (ALGs) are used. This issue is not present in 464XLAT
(see <xref target="RFC8683"></xref>).</t> (see <xref target="RFC8683" format="default"/>).</t>
<t>It is worth mentioning Happy Eyeballs <xref target="RFC8305" format
<t>It is worth mentioning Happy Eyeballs <xref target="RFC8305"></xre ="default"/> as a relevant aspect of application transition to IPv6.</t>
f> as a relevant aspect of application transition to IPv6.</t>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Network Management and Operations</name>
<section title="Network Management and Operations"> <t>There are important IPv6 complementary solutions related to Operation
s, Administration, and Maintenance (OAM) that look less mature compared to IPv4.
<t>There are important IPv6 complementary solutions related to Operations A Network Management System (NMS) has a central role in the modern networ
, Administration and Maintenance (OAM) that look less mature compared to IPv4. ks for both network operators and enterprises, and its transition is a fundament
Network Management System (NMS) has a central role in the modern networks al issue.
for both network operators and enterprises and its transition is a fundamental This is because some IPv6 products are not as field proven as IPv4 produc
issue. ts, even if conventional protocols (e.g., SNMP and RADIUS) already support IPv6.
This is because some IPv6 products are not as field-proven as for IPv4 ev In addition, an incompatible vendor road map for the development of new N
en if conventional protocols (e.g. SNMP, RADIUS) already support IPv6. MS features affects the confidence of network operators or enterprises.</t>
In addition, incompatible vendor road map for the development of new NMS <t>An important factor is represented by the need for training the netwo
features affects the confidence of network operators or enterprises.</t> rk operations workforce. Deploying IPv6 requires that policies and procedures
<t>An important factor is represented by the need for training the networ
k operations workforce. Deploying IPv6 requires that policies and procedures
have to be adjusted in order to successfully plan and complete an IPv6 tr ansition. Staff has to be aware of the best practices for managing have to be adjusted in order to successfully plan and complete an IPv6 tr ansition. Staff has to be aware of the best practices for managing
IPv4 and IPv6 assets. In addition to network nodes, network management ap plications and equipment need to be properly configured and in some cases also IPv4 and IPv6 assets. In addition to network nodes, network management ap plications and equipment need to be properly configured and, in some cases, also
replaced. This may introduce more complexity and costs for the transition .</t> replaced. This may introduce more complexity and costs for the transition .</t>
<t>Availability of both systems and training is necessary in areas such
<t>Availability of both systems and training is necessary in areas such a as IPv6 addressing. IPv6 addresses can be assigned to an interface through diffe
s IPv6 addressing. IPv6 addresses can be assigned to an interface through differ rent means,
ent means, such as Stateless Auto-Configuration (SLAAC) <xref target="RFC4862" forma
such as Stateless Auto-Configuration (SLAAC) <xref target="RFC4862"></xre t="default"/>, or by using the stateful Dynamic Host Configuration Protocol (DHC
f>, or by using stateful Dynamic Host Control Protocol (DHCP) <xref target="RFC8 P) <xref target="RFC8415" format="default"/>.
415"></xref>. IP Address Management (IPAM) systems may contribute by handling the techn
IP Address Management (IPAM) systems may contribute to handle the technic ical differences and automating some of the configuration tasks, such as the add
al differences and automate some of the configuration tasks, such as the address ress assignment
assignment
or the management of DHCP services.</t> or the management of DHCP services.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Performance</name>
<section title="Performance"> <t>People tend to compare the performance of IPv6 versus IPv4 to argue o
<t>People tend to compare the performance of IPv6 versus IPv4 to argue or r motivate the IPv6 transition.
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. 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 fill ing) the gap to IPv4. This position is supported when However, there are some aspects where IPv6 has already filled (or is fill ing) the gap to IPv4. This position is supported when
looking at available analytics on two critical parameters: packet loss an d latency. These parameters have been constantly looking at available analytics on two critical parameters: packet loss an d latency. These parameters have been constantly
monitored over time, but only a few comprehensive measurement campaigns a re providing up-to-date information. monitored over time, but only a few comprehensive measurement campaigns a re providing up-to-date information.
While performance is undoubtedly an important issue to consider and worth further investigation, reality is that 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. D epending on the specific use case and application, a definitive answer cannot be found on what IP version performs better. D epending on the specific use case and application,
IPv6 is better; in others the same applies to IPv4.</t> IPv6 is better; in others, the same applies to IPv4.</t>
<section numbered="true" toc="default">
<section title="IPv6 packet loss and latency"> <name>IPv6 Packet Loss and Latency</name>
<t><xref target="APNIC5"></xref> provides a measurement of both t <t><xref target="APNIC5" format="default"/> provides a measurement of
he failure rate and Round Trip Time (RTT) of IPv6 compared against IPv4. both the failure rate and Round-Trip Time (RTT) of IPv6 compared against IPv4.
Both measures are based on scripts that employs the three-way han Both measures are based on scripts that employ the three-way hand
dshake of TCP. As such, the measurement of the failure rate shake of TCP. As such, the measurement of the failure rate
does not provide a direct measurement of packet loss (that would does not provide a direct measurement of packet loss (which would
need an Internet-wide measurement campaign). need an Internet-wide measurement campaign).
Said that, despite IPv4 is still performing better, the differenc That said, despite that IPv4 is still performing better, the diff
e seems to have decreased in recent years. erence seems to have decreased in recent years.
Two reports, namely <xref target="RIPE1"></xref> and <xref target Two reports, namely <xref target="RIPE1" format="default"/> and <
="APRICOT"></xref>, discussed the associated trend, 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 showing how the average worldwide failure rate of IPv6 is still a bit worse than IPv4. Reasons for this effect may be found in endpoints
with an unreachable IPv6 address, routing instability or firewall behavior. Yet, this worsening effect may appear as with an unreachable IPv6 address, routing instability, or firewal l behavior. Yet, this worsening effect may appear as
disturbing for a plain transition to IPv6.</t> disturbing for a plain transition to IPv6.</t>
<t><xref target="APNIC5" format="default"/> also compares the latency
<t><xref target="APNIC5"></xref> also compares the latency of bot of both address families. Currently, the worldwide average is slightly in favor
h address families. Currently, the worldwide average is slightly in favor of IPv of IPv6.
6.
Zooming at the country or even at the operator level, it is possi ble to get more detailed information and appreciate that cases exist where IPv6 is faster than IPv4. Zooming at the country or even at the operator level, it is possi ble to get more detailed information and appreciate that cases exist where IPv6 is faster than IPv4.
Regions (e.g. Western Europe, Northern America, Southern Asia) an d Countries (e.g. US, India, Germany) with an advanced deployment of IPv6 (e.g. >45%) Regions (e.g., Western Europe, Northern America, and Southern Asi a) and countries (e.g., US, India, and Germany) with an advanced deployment of I Pv6 (e.g., greater than 45%)
are showing that IPv6 has better performance than IPv4. are showing that IPv6 has better performance than IPv4.
<xref target="APRICOT"></xref> highlights how when a difference i <xref target="APRICOT" format="default"/> highlights how when a d
n performance exists it is often related to asymmetric routing issues. ifference in performance exists, it is often related to asymmetric routing issue
Other possible explanations for a relative latency difference lie s.
s on the specificity of the IPv6 header which allows packet fragmentation. Other possible explanations for a relative latency difference
In turn, this means that hardware needs to spend cycles to analyz relate to the specificity of the IPv6 header, which allows packet
e all of the header sections and when it is not capable of handling one of them fragmentation.
it drops the packet. In turn, this means that hardware needs to spend cycles to analyz
A few measurement campaigns on the behavior of IPv6 in CDNs are a e all of the header sections, and when it is not capable of handling one of them
lso available <xref target="MAPRG"></xref>, <xref target="INFOCOM"></xref>. , it drops the packet.
The TCP connect time is still higher for IPv6 in both cases, even A few measurement campaigns on the behavior of IPv6 in CDNs are a
if the gap has reduced over the analysis time window.</t> lso available <xref target="MAPRG" format="default"/> <xref target="INFOCOM" for
</section> mat="default"/>.
The TCP connection time is still higher for IPv6 in both cases, e
<section title="Customer Experience"> ven if the gap has reduced over the analysis time window.</t>
<t>It is not totally clear if the Customer Experience is in some way per </section>
ceived as better when IPv6 is used instead of IPv4. In some cases <section numbered="true" toc="default">
it has been publicly reported by IPv6 content providers, that use <name>Customer Experience</name>
rs have a better experience when using IPv6-only compared to IPv4 <xref target=" <t>It is not totally clear if the customer experience is in some way p
ISOC2"></xref>. erceived as better when IPv6 is used instead of IPv4. In some cases,
This could be explained because in the case of an IPv6 user conne it has been publicly reported by IPv6 content providers that user
cting to an application hosted in an IPv6-only Data Centers, the connection is e s have a better experience when using IPv6-only compared to IPv4 <xref target="I
nd-to-end, SOC2" format="default"/>.
without translations. Instead, when using IPv4 there is a NAT tra This could be explained because, in the case of an IPv6 user conn
nslation either in the CPE or in the service provider’s network, in addition to ecting to an application hosted in an IPv6-only Data Center, the connection is e
nd to end,
without translations. Instead, when using IPv4, there is a NAT tr
anslation either in the CPE or in the service provider's network, in addition to
IPv4 to IPv6 (and back to IPv4) translation in the IPv6-only cont ent provider Data Center. IPv4 to IPv6 (and back to IPv4) translation in the IPv6-only cont ent provider Data Center.
<xref target="ISOC2"></xref>, <xref target="FB"></xref> provide r <xref target="ISOC2" format="default"/> and <xref target="FB" for
easons in favor of IPv6. In other cases, the result seems to be still slightly mat="default"/> provide reasons in favor of IPv6. In other cases, the result see
in favor of IPv4 <xref target="INFOCOM"></xref>, <xref target="MA ms to be still slightly
PRG"></xref>, even if the difference between IPv4 and IPv6 tends to vanish over in favor of IPv4 <xref target="INFOCOM" format="default"/> <xref
time.</t> target="MAPRG" format="default"/>, even if the difference between IPv4 and IPv6
tends to vanish over time.</t>
</section> </section>
</section>
</section> <section anchor="security-privacy" numbered="true" toc="default">
<name>IPv6 Security and Privacy</name>
<section anchor="security-privacy" title="IPv6 security and privacy"> <t>An important point that is sometimes considered as a challenge when d
iscussing the transition to IPv6 is related to the security and privacy.
<t>An important point that is sometimes considered as a challenge when di <xref target="RFC9099" format="default"/> analyzes the operational securi
scussing the transition to IPv6 is related to the security and privacy. ty issues in several places of a network (enterprises,
<xref target="RFC9099"></xref> analyzes the operational security issues i service providers, and residential users). It is also worth considering t
n several places of a network (enterprises, he additional security issues brought by the applied IPv6
service providers and residential users). It is also worth considering th transition technologies used to implement IPv4aaS (e.g., 464XLAT and DS-L
e additional security issues brought by the applied IPv6 ite) <xref target="ComputSecur" format="default"/>.</t>
transition technologies used to implement IPv4aaS (e.g. 464XLAT, DS-Lite) <t>The security aspects have to be considered to keep at least the same,
<xref target="ComputSecur"></xref>.</t> or even a better, level of security
<t>The security aspects have to be considered to keep at least the same o
r even a better level of security
as it exists nowadays in an IPv4 network environment. The autoconfigurati on features of IPv6 will require some more attention. as it exists nowadays in an IPv4 network environment. The autoconfigurati on features of IPv6 will require some more attention.
Router discovery and address autoconfiguration may produce unexpected res ults and security holes. Router discovery and address autoconfiguration may produce unexpected res ults and security holes.
IPsec protects IPv6 traffic at least as well as it does IPv4, and the sec urity protocols for constrained devices (IoT) are designed for IPsec protects IPv6 traffic at least as well as it does IPv4, and the sec urity protocols for constrained devices (IoT) are designed for
IPv6 operation.</t> IPv6 operation.</t>
<t>IPv6 was designed to restore the end-to-end model of communications w
<t>IPv6 was designed to restore the end-to-end model of communications wi ith all nodes on networks using globally unique addresses.
th all nodes on networks using globally unique addresses. But considering this, IPv6 may imply privacy concerns due to greater visi
But, considering this, IPv6 may imply privacy concerns, due to greater vi bility on the Internet.
sibility on the Internet. IPv6 nodes can (and typically do) use privacy extensions <xref target="RF
IPv6 nodes can (and typically do) use privacy extensions <xref target="RF C8981" format="default"/> to prevent any tracking of their burned-in Media Acces
C8981"></xref> to prevent any tracking of their burned-in MAC address(es), s Control (MAC) address(es),
which are easily readable in the original modified EUI-64 interface ident which are easily readable in the original modified 64-bit Extended Unique
ifier format. But, on the other hand, Identifier (EUI-64) interface identifier format. On the other hand,
stable IPv6 interface identifiers (<xref target="RFC8064"></xref>) were d stable IPv6 interface identifiers <xref target="RFC8064" format="default"
eveloped and this can also affect privacy.</t> /> were developed, and this can also affect privacy.</t>
<t>As reported in <xref target="ISOC3" format="default"/>, in comparing
<t>As reported in <xref target="ISOC3"></xref>, comparing IPv6 and IPv4 a IPv6 and IPv4 at the protocol level,
t the protocol level, one may probably conclude that the increased complexity of IPv6 will resu
one may probably conclude that the increased complexity of IPv6 results i lt in an increased number
n an increased number of attack vectors that imply more possible ways to perform different type
of attack vectors, that imply more possible ways to perform different typ s of attacks.
es of attacks.
However, a more interesting and practical question is how IPv6 deployment s compare to IPv4 deployments However, a more interesting and practical question is how IPv6 deployment s compare to IPv4 deployments
in terms of security. In that sense, there are a number of aspects to con sider.</t> in terms of security. In that sense, there are a number of aspects to con sider.</t>
<t>Most security vulnerabilities related to network protocols are based
<t>Most security vulnerabilities related to network protocols are based o on implementation flaws.
n implementation flaws.
Typically, security researchers find vulnerabilities in protocol implemen tations, which Typically, security researchers find vulnerabilities in protocol implemen tations, which
eventually are “patched” to mitigate such vulnerabilities. Over time, thi s process of finding and eventually are "patched" to mitigate such vulnerabilities. Over time, thi s process of finding and
patching vulnerabilities results in more robust implementations. For obvi ous reasons, the IPv4 patching vulnerabilities results in more robust implementations. For obvi ous reasons, the IPv4
protocols have benefited from the work of security researchers for much l onger, and thus, IPv4 protocols have benefited from the work of security researchers for much l onger, and thus IPv4
implementations are generally more robust than IPv6. However, with more I Pv6 deployment, implementations are generally more robust than IPv6. However, with more I Pv6 deployment,
IPv6 will also benefit from this process in the long run. It is also wort IPv6 will also benefit from this process in the long run.
h mentioning that It is also worth mentioning that most vulnerabilities nowadays are
most vulnerabilities are nowadays in the human being and in the applicati caused by human beings and are in the application layer, not the
on layer and not in the IP layer.</t> IP layer.</t>
<t>Besides the intrinsic properties of the protocols, the security level
<t>Besides the intrinsic properties of the protocols, the security level of of the resulting deployments
the resulting deployments
is closely related to the level of expertise of network and security enginee rs. In that sense, there is closely related to the level of expertise of network and security enginee rs. In that sense, there
is obviously much more experience and confidence with deploying and opera ting IPv4 networks is obviously much more experience and confidence with deploying and opera ting IPv4 networks
than with deploying and operating IPv6 networks.</t> than with deploying and operating IPv6 networks.</t>
<section numbered="true" toc="default">
<section title="Protocols security issues"> <name>Protocols' Security Issues</name>
<t>In general, there are security concerns related to IPv6 that can be
<t>In general, there are security concerns related to IPv6 that can be cl classified as follows:</t>
assified as follows:<list style="symbols"> <ul spacing="normal">
<li>Basic IPv6 protocol (basic header, extension headers, addressing
<t>Basic IPv6 protocol (Basic header, Extension Headers, Addressing)</t )</li>
> <li>IPv6-associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)</li>
<li>Internet-wide IPv6 security (filtering, DDoS, transition mechani
<t>IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6)</t> sms)</li>
</ul>
<t>Internet-wide IPv6 security (Filtering, DDoS, Transition Mechanisms) <t>ICMPv6 is an integral part of IPv6 and performs error reporting and
</t> diagnostic functions.
</list></t> The Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv
6, which replaces and enhances
<t>ICMPv6 is an integral part of IPv6 and performs error reporting and di
agnostic functions.
Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6 wh
ich replaces and enhances
functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6 rout ers for discovering multicast functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6 rout ers for discovering multicast
listeners on a directly attached link, much like Internet Group Managemen listeners on a directly attached link, much like how the Internet Group M
t Protocol (IGMP) is used in IPv4.</t> anagement Protocol (IGMP) is used in IPv4.</t>
<t>These IPv6-associated protocols, like ICMPv6, NDP, and MLD, are som
<t>These IPv6 associated protocols like ICMPv6, NDP and MLD are something ething new compared to IPv4, so
new compared to IPv4, so
they add new security threats and the related solutions are still under d iscussion today. they add new security threats and the related solutions are still under d iscussion today.
NDP has vulnerabilities <xref target="RFC3756"></xref> <xref target="RFC6 NDP has vulnerabilities <xref target="RFC3756" format="default"/> <xref t
583"></xref>. arget="RFC6583" format="default"/>.
The specification says to use IPsec but it is impractical and not used, o <xref target="RFC3756" format="default"/> says to use IPsec, but it is im
n the other hand, practical and not used; on the other hand,
SEND (SEcure Neighbour Discovery) <xref target="RFC3971"></xref> is not w SEcure Neighbor Discovery (SEND) <xref target="RFC3971" format="default"/
idely available. > is not widely available.
It is worth mentioning that applying host isolation may address many of t hese concerns, as described in It is worth mentioning that applying host isolation may address many of t hese concerns, as described in
<xref target="I-D.ietf-v6ops-nd-considerations"/>.</t> <xref target="I-D.ietf-v6ops-nd-considerations" format="default"/>.</t>
<t><xref target="RIPE2" format="default"/> describes the most importan
<t><xref target="RIPE2"></xref> describes the most important threats and t threats and solutions
solutions
regarding IPv6 security.</t> regarding IPv6 security.</t>
<section numbered="true" toc="default">
<section title="IPv6 Extension Headers and Fragmentation"> <name>IPv6 Extension Headers and Fragmentation</name>
<t>IPv6 Extension Headers provide a hook for interesting new features to be <t>IPv6 extension headers provide a hook for interesting new feature
added, and are more flexible than IPv4 Options. s to be added and are more flexible than IPv4 options.
This does add some complexity, and in particular some security mechanisms This does add some complexity. In particular, some security mechanisms ma
may require to process the full chain of headers, y require processing the full chain of headers,
and some firewalls may require to filter packets based on their Extension and some firewalls may require filtering packets based on their extension
Headers. Additionally, packets with IPv6 Extension Headers headers. Additionally, packets with IPv6 extension headers
may be dropped in the public Internet <xref target="RFC7872"></xref>. may be dropped in the public Internet <xref target="RFC7872" format="defa
Some documents, e.g. <xref target="I-D.ietf-6man-hbh-processing"/>, <xref ult"/>.
target="I-D.ietf-v6ops-hbh"/>, Some documents, e.g., <xref target="I-D.ietf-6man-hbh-processing" format=
<xref target="I-D.bonica-6man-ext-hdr-update"/>, analyze and provide guid "default"/>, <xref target="I-D.ietf-v6ops-hbh" format="default"/>, and
ance regarding the processing procedures of IPv6 Extension Headers.</t> <xref target="I-D.bonica-6man-ext-hdr-update" format="default"/>, analyze
and provide guidance regarding the processing procedures of IPv6 extension head
<t>Defense against possible attacks through Extension Headers is necessar ers.</t>
y. For example, the original IPv6 Routing Header type 0 (RH0) <t>Defense against possible attacks through extension headers is nec
was deprecated because of possible remote traffic amplification <xref tar essary. For example, the original IPv6 Routing Header type 0 (RH0)
get="RFC5095"></xref>. In addition, it is worth mentioning that unrecognized was deprecated because of possible remote traffic amplification <xref tar
get="RFC5095" format="default"/>. In addition, it is worth mentioning that the u
nrecognized
Hop-by-Hop Options Header and Destination Options Header will not be cons idered by the nodes if they are not configured to deal with it Hop-by-Hop Options Header and Destination Options Header will not be cons idered by the nodes if they are not configured to deal with it
<xref target="RFC8200"></xref>. <xref target="RFC8200" format="default"/>.
Other attacks based on Extension Headers may be based on IPv6 Header Chai Other attacks based on extension headers may be based on IPv6 header chai
ns and Fragmentation that could be used to bypass filtering. ns and fragmentation that could be used to bypass filtering.
To mitigate this effect, the initial IPv6 Header, the Extension Headers a
nd the Upper-Layer Header must all be in the first fragment <xref target="RFC820
0"></xref>.
Also, the use of the IPv6 Fragmentation Header is forbidden in all Neighb
or Discovery messages <xref target="RFC6980"></xref>.</t>
<t>Fragment Header is used by IPv6 source node to send a packet bigger th
an path MTU and the Destination host processes
fragment headers. There are several threats related to fragmentation to p
ay attention to e.g. overlapping fragments (not allowed)
resource consumption while waiting for last fragment (to discard), atomic
fragments (to be isolated).</t>
<t>The operational implications of IPv6 Packets with Extension Headers ar
e further discussed in <xref target="RFC9098"></xref>.</t>
</section>
</section>
</section>
</section>
<section title="Security Considerations">
<t>This document has no impact on the security properties of specific IP
v6 protocols or transition tools.
In addition to the discussion above in <xref target="security-pri
vacy"/>, the security considerations
relating to the protocols and transition tools are described in t
he 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>
To mitigate this effect, the initial IPv6 header, the extension headers,
and the upper-layer header must all be in the first fragment <xref target="RFC82
00" format="default"/>.
Also, the use of the IPv6 fragment header is forbidden in all Neighbo
r Discovery messages <xref target="RFC6980" format="default"/>.</t>
<t>The fragment header is used by the IPv6 source node to send a pac
ket bigger than the path MTU, and the destination host processes
fragment headers. There are several threats related to fragmentation to p
ay attention to, e.g., overlapping fragments (not allowed),
resource consumption while waiting for the last fragment (to discard), an
d atomic fragments (to be isolated).</t>
<t>The operational implications of IPv6 packets with extension heade
rs are further discussed in <xref target="RFC9098" format="default"/>.</t>
</section>
</section>
</section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors of this document would like to thank Brian Carpenter, Fred Ba <t>This document has no IANA actions.</t>
ker, Alexandre Petrescu, Fernando Gont,
Barbara Stark, Haisheng Yu(Johnson), Dhruv Dhody, Gabor Lencse, Shuping P
eng, Daniel Voyer, Daniel Bernier,
Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, Erik Nygren, Edu
ard Vasilenko and Xipeng Xiao
for their comments and review of this document.</t>
</section> </section>
<!-- Possibly a 'Contributors' section ... --> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>This document has no impact on the security properties of specific IPv6
<t>This document has no actions for IANA.</t> protocols or transition tools.
In addition to the discussion above in <xref target="security-pri
vacy" format="default"/>, the security considerations
relating to the protocols and transition tools are described in t
he relevant documents.</t>
</section> </section>
</middle> </middle>
<back>
<!-- *****BACK MATTER ***** --> <displayreference target="I-D.ietf-v6ops-nd-considerations" to="ND-CONSIDERA
<back> TIONS"/>
<!-- References split to informative and normative --> <displayreference target="I-D.ietf-6man-hbh-processing" to="HBH-PROCESSING"/
<references title="Normative References"> >
<displayreference target="I-D.ietf-v6ops-hbh" to="HBH-OPT-HDR"/>
<?rfc include='reference.RFC.1918'?> <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"/
<?rfc include='reference.RFC.6036'?> >
<references>
<?rfc include='reference.RFC.6180'?> <name>References</name>
<references>
<?rfc include='reference.RFC.6883'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<?rfc include='reference.RFC.4213'?> 918.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.7381'?> 036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.6877'?> 180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.6333'?> 883.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.RFC.7596'?> 213.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.7597'?> 381.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.7599'?> 877.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.3756'?> 333.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.6583'?> 596.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.3971'?> 597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.6540'?> 599.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include='reference.RFC.8950'?> 756.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.9099'?> 583.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include='reference.RFC.9313'?> 971.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</references> 540.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Informative References"> 950.xml"/>
<!-- A reference written by by an organization not a persoN. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
099.xml"/>
<?rfc include='reference.RFC.8305'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
313.xml"/>
<?rfc include='reference.RFC.5095'?> </references>
<references>
<?rfc include='reference.RFC.8683'?> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<?rfc include='reference.RFC.8981'?> 05.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.8064'?> 095.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.9098'?> 683.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.7872'?> 981.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.6980'?> 064.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.8200'?> 098.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.6264'?> 872.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.4862'?> 980.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8415'?> 200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.I-D.ietf-v6ops-nd-considerations'?> 264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.I-D.ietf-6man-hbh-processing'?> 862.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
<?rfc include='reference.I-D.ietf-v6ops-hbh'?> <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>
<?rfc include='reference.I-D.palet-v6ops-ipv6-only'?> <reference anchor="I-D.ietf-6man-hbh-processing">
<front>
<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>
<?rfc include='reference.I-D.bonica-6man-ext-hdr-update'?> <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='ETSI-IP6-WhitePaper'> <reference anchor="I-D.palet-v6ops-ipv6-only">
<front> <front>
<title>ETSI White Paper No. 35: IPv6 Best Practices, Benefits, Transition <title>IPv6-only Terminology Definition</title>
Challenges and the Way Forward</title> <author initials="J." surname="Palet Martinez" fullname="Jordi Palet Martinez">
<author> <organization>The IPv6 Company</organization>
<organization>ETSI</organization> </author>
</author> <date month="March" day="9" year="2020"/>
<date year='2020' /> </front>
</front> <seriesInfo name="Internet-Draft" value="draft-palet-v6ops-ipv6-only-05"/>
<seriesInfo name='ISBN' value='979-10-92620-31-1'/> </reference>
</reference>
<reference anchor='ETSI-GR-IPE-001' target="https://www.etsi.org/deliver <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference/I-D.bonica-
/etsi_gr/IPE/001_099/001/01.01.01_60/gr_IPE001v010101p.pdf"> 6man-ext-hdr-update.xml"/>
<front>
<title>ETSI GR IPE 001: IPv6 Enhanced Innovation (IPE) Gap Analysis</title
>
<author>
<organization>ETSI</organization>
</author>
<date year='2021' />
</front>
</reference>
<reference anchor='IAB' target="https://www.iab.org/2016/11/07/iab-state <reference anchor="ETSI-IP6-WhitePaper">
ment-on-ipv6/"> <front>
<front> <title>IPv6 Best Practices, Benefits, Transition Challenges and the
<title>IAB Statement on IPv6</title> Way Forward</title>
<author> <author>
<organization>IAB</organization> <organization>ETSI</organization>
</author> </author>
<date year='2016' /> <date year="2020" month="August"/>
</front> </front>
</reference> <seriesInfo name="ETSI" value="White Paper No. 35"/>
<seriesInfo name="ISBN" value="979-10-92620-31-1"/>
</reference>
<reference anchor='CAIR' target="https://www.cisco.com/c/en/us/solutions <reference anchor="ETSI-GR-IPE-001" target="https://www.etsi.org/deliver
/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490 /etsi_gr/IPE/001_099/001/01.01.01_60/gr_IPE001v010101p.pdf">
.html"> <front>
<front> <title>IPv6 Enhanced Innovation (IPE) Gap Analysis</title>
<title>Cisco Annual Internet Report (2018–2023) White Paper</title> <author>
<author> <organization>ETSI</organization>
<organization>Cisco</organization> </author>
</author> <date year="2021" month="August"/>
<date year='2020' /> </front>
</front> <seriesInfo name="ETSI GR IPE 001," value="V1.1.1"/>
</reference> </reference>
<reference anchor='CAIDA' target="https://www.cmand.org/workshops/202006 <reference anchor="IAB" target="https://www.iab.org/2016/11/07/iab-state
-v6/slides/2020-06-16-client-side.pdf"> ment-on-ipv6/">
<front> <front>
<title>Client-Side IPv6 Measurement</title> <title>IAB Statement on IPv6</title>
<author> <author>
<organization>APNIC</organization> <organization>IAB</organization>
</author> </author>
<date year='2020' /> <date year="2016" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor='POTAROO1' target="https://www.potaroo.net/ispcol/2022 <reference anchor="CAIR" target="https://www.cisco.com/c/en/us/solutions
-01/addr2021.html"> /collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490
<front> .html">
<title>IP Addressing through 2021</title> <front>
<author> <title>Cisco Annual Internet Report (2018-2023) White Paper</title>
<organization>POTAROO</organization> <author>
</author> <organization>Cisco</organization>
<date year='2022' /> </author>
</front> <date year="2020" month="March"/>
</reference> </front>
</reference>
<reference anchor='POTAROO2' target="https://www.potaroo.net/bgp/iso3166 <reference anchor="CAIDA" target="https://www.cmand.org/workshops/202006
/v6cc.html"> -v6/slides/2020-06-16-client-side.pdf">
<front> <front>
<title>IPv6 Resource Allocations</title> <title>Client-Side IPv6 Measurement</title>
<author> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>POTAROO</organization> <organization>APNIC</organization>
</author> </author>
<date year='2022' /> <date year="2020" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor='CN-IPv6' target="https://www.china-ipv6.cn/#/activeco <reference anchor="POTAROO1" target="https://www.potaroo.net/ispcol/2022
nnect/simpleInfo"> -01/addr2021.html">
<front> <front>
<title>Active IPv6 Internet users</title> <title>IP Addressing through 2021</title>
<author> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>National IPv6 Deployment and Monitoring Platform</organizat <organization>POTAROO</organization>
ion> </author>
</author> <date year="2022" month="January"/>
<date year='2022' /> </front>
</front> </reference>
</reference>
<reference anchor='IGP-GT' target="https://via.hypothes.is/https://www.i <reference anchor="POTAROO2" target="https://www.potaroo.net/bgp/iso3166
nternetgovernance.org/wp-content/uploads/IPv6-Migration-Study-final-report.pdf"> /v6cc.html">
<front> <front>
<title>The hidden standards war: economic factors affecting IPv6 deploymen <title>IPv6 Resource Allocations</title>
t</title> <author>
<author> <organization>POTAROO</organization>
<organization>Internet Governance Project, Georgia Tech</organization> </author>
</author> <date year="2023" month="March"/>
<date year='2019' /> </front>
</front> </reference>
</reference>
<reference anchor='NRO' target="https://www.nro.net/wp-content/uploads/N <reference anchor="CN-IPv6" target="https://www.china-ipv6.cn/#/activeco
RO-Statistics-2021-Q3-FINAL.pdf"> nnect/simpleInfo">
<front> <front>
<title>Internet Number Resource Status Report</title> <title>Active IPv6 Internet Users</title>
<author> <author>
<organization>NRO</organization> <organization>National IPv6 Deployment and Monitoring Platform</or
</author> ganization>
<date year='2021' /> </author>
</front> <date year="2022"/>
</reference> </front>
<refcontent>(in Chinese)</refcontent>
</reference>
<reference anchor='ISOC1' target="https://www.internetsociety.org/resour <reference anchor="IGP-GT" target="https://www.emerald.com/insight/conte
ces/2018/state-of-ipv6-deployment-2018/"> nt/doi/10.1108/DPRG-10-2019-0085/full/html">
<front> <front>
<title>State of IPv6 Deployment 2018</title> <title>The hidden standards war: economic factors affecting IPv6 dep
<author> loyment</title>
<organization>Internet Society</organization> <author initials="B." surname="Kuerbis" fullname="Brenden Keurbis">
</author> <organization>Internet Governance Project, Georgia Tech</organizat
<date year='2018' /> ion>
</front> </author>
</reference> <author initials="M." surname="Mueller" fullname="Milton Mueller">
<organization>Internet Governance Project, Georgia Tech</organizat
ion>
</author>
<date year="2019" month="February"/>
</front>
<seriesInfo name="DOI" value="10.1108/DPRG-10-2019-0085"/>
</reference>
<reference anchor='ISOC2' target="https://www.internetsociety.org/blog/20 <reference anchor="NRO" target="https://www.nro.net/wp-content/uploads/N
15/04/facebook-news-feeds-load-20-40-faster-over-ipv6/"> RO-Statistics-2021-Q3-FINAL.pdf">
<front> <front>
<title>Facebook News Feeds Load 20-40% Faster Over IPv6</title> <title>Internet Number Resource Status Report</title>
<author> <author>
<organization>Internet Society</organization> <organization>NRO</organization>
</author> </author>
<date year='2015' /> <date year="2021" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor='ISOC3' target="https://www.internetsociety.org/wp-cont <reference anchor="ISOC1" target="https://www.internetsociety.org/resour
ent/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf"> ces/2018/state-of-ipv6-deployment-2018/">
<front> <front>
<title>IPv6 Security FAQ</title> <title>State of IPv6 Deployment 2018</title>
<author> <author>
<organization>Internet Society</organization> <organization>Internet Society</organization>
</author> </author>
<date year='2019' /> <date year="2018" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor='HxBld' target="https://hexabuild.io/assets/files/Hexa <reference anchor="ISOC2" target="https://www.internetsociety.org/blog/2
Build-IPv6-Adoption-Report-2020.pdf"> 015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/">
<front> <front>
<title>IPv6 Adoption Report 2020</title> <title>Facebook News Feeds Load 20-40% Faster Over IPv6</title>
<author> <author initials="D." surname="York" fullname="Dan York">
<organization>HexaBuild</organization> <organization>Internet Society</organization>
</author> </author>
<date year='2020' /> <date year="2015" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor='G_stats' target="https://www.google.com/intl/en/ipv6/ <reference anchor="ISOC3" target="https://www.internetsociety.org/wp-con
statistics.html"> tent/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf">
<front> <front>
<title>Google IPv6 Statistics</title> <title>IPv6 Security Frequently Asked Questions (FAQ)</title>
<author> <author initials="F." surname="Gont" fullname="Fernando Gont">
<organization>Google</organization> <organization>Internet Society</organization>
</author> </author>
<date year='2021' /> <date year="2019" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor='ARCEP' target="https://www.arcep.fr/uploads/tx_gsavis <reference anchor="HxBld" target="https://hexabuild.io/assets/files/Hexa
/19-1386.pdf"> Build-IPv6-Adoption-Report-2020.pdf">
<front> <front>
<title>Arcep Décision n° 2019-1386, Decision on the terms and conditions f <title>IPv6 Adoption Report 2020: The IPv6 Internet is the Corporate
or awarding licences to use frequencies in the 3.4–3.8GHz band</title> Network</title>
<author> <author>
<organization>ARCEP</organization> <organization>HexaBuild</organization>
</author> </author>
<date year='2019' /> <date year="2020" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor='APNIC1' target="https://stats.labs.apnic.net/ipv6"> <reference anchor="G_stats" target="https://www.google.com/intl/en/ipv6/
<front> statistics.html">
<title>IPv6 Capable Rate by country (%)</title> <front>
<author> <title>Google IPv6 Statistics</title>
<organization>APNIC</organization> <author>
</author> <organization>Google</organization>
<date year='2022' /> </author>
</front> </front>
</reference> </reference>
<reference anchor='APNIC2' target="https://blog.apnic.net/2022/01/19/ip- <reference anchor="ARCEP" target="https://www.arcep.fr/uploads/tx_gsavis
addressing-in-2021/"> /19-1386.pdf">
<front> <front>
<title>IP Addressing 2021</title> <title>Proposant au ministre chargé des
<author> communications électroniques les modalités et les
<organization>APNIC2</organization> conditions d'attribution d'autorisations d'utilisation de
</author> fréquences dans la bande 3,4 - 3,8 GHz</title>
<date year='2022' /> <author>
</front> <organization>ARCEP</organization>
</reference> </author>
<date year="2019" month="November"/>
</front>
<refcontent>[Decision on the terms
and conditions for awarding licenses to use frequencies in
the 3.4 – 3.8 GHz band], Décision n° [Decision No.] 2019-1386</refcont
ent>
</reference>
<reference anchor='APNIC3' target="https://blog.apnic.net/2021/01/05/bgp-in <reference anchor="APNIC1" target="https://stats.labs.apnic.net/ipv6">
-2020-the-bgp-table/>"> <front>
<front> <title>IPv6 Capable Rate by country (%)</title>
<title>BGP in 2020 – The BGP Table</title> <author>
<author> <organization>APNIC Labs</organization>
<organization>APNIC</organization> </author>
</author> </front>
<date year='2021' /> </reference>
</front>
</reference>
<reference anchor='APNIC4' target="https://blog.apnic.net/2022/01/06/bgp <reference anchor="APNIC2" target="https://blog.apnic.net/2022/01/19/ip-
-in-2021-the-bgp-table/>"> addressing-in-2021/">
<front> <front>
<title>BGP in 2021 – The BGP Table</title> <title>IP addressing in 2021</title>
<author> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization> <organization>APNIC</organization>
</author> </author>
<date year='2022' /> <date year="2022" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor='APNIC5' target="https://stats.labs.apnic.net/v6perf/X <reference anchor="APNIC3" target="https://blog.apnic.net/2021/01/05/bgp
A"> -in-2020-the-bgp-table/">
<front> <front>
<title>Average RTT Difference (ms) (V6 - V4) for World (XA)</title> <title>BGP in 2020 - The BGP Table</title>
<author> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization> <organization>APNIC</organization>
</author> </author>
<date year='2022' /> <date year="2021" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor='APRICOT' target="https://2020.apricot.net/assets/file <reference anchor="APNIC4" target="https://blog.apnic.net/2022/01/06/bgp
s/APAE432/ipv6-performance-measurement.pdf"> -in-2021-the-bgp-table/">
<front> <front>
<title>Average RTT Difference (ms) (V6 - V4) for World (XA)</title> <title>BGP in 2021 - The BGP Table</title>
<author initials="G." surname="Huston"> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization> <organization>APNIC</organization>
</author> </author>
<date year='2020' /> <date year="2022" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor='FB' target="https://youtu.be/An7s25FSK0U"> <reference anchor="APNIC5" target="https://stats.labs.apnic.net/v6perf/X
<front> A">
<title>Facebook IPv6 Experience</title> <front>
<author initials="P." surname="Saab"> <title>Average RTT Difference (ms) (V6 - V4) for World (XA)</title>
<organization>V6 World Congress</organization> <author>
</author> <organization>APNIC Labs</organization>
<date year='2015' /> </author>
</front> </front>
</reference> </reference>
<reference anchor='MAPRG' target="https://www.ietf.org/proceedings/99/sl <reference anchor="APRICOT" target="https://2020.apricot.net/assets/file
ides/slides-99-maprg-measuring-youtube-content-delivery-over-ipv6-00.pdf"> s/APAE432/ipv6-performance-measurement.pdf">
<front> <front>
<title>Measuring YouTube Content Delivery over IPv6</title> <title>IPv6 Performance Measurement</title>
<author initials="V." surname="Bajpai"> <author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>TU Munich</organization> <organization>APNIC</organization>
</author> </author>
<date year='2017' /> <date year="2020" month="February"/>
</front> </front>
</reference> </reference>
<reference anchor='INFOCOM' target="https://dl.acm.org/doi/abs/10.1109/IN <reference anchor="FB" target="https://youtu.be/An7s25FSK0U">
FOCOM41043.2020.9155367"> <front>
<front> <title>Paul Saab Facebook V6 World Congress 2015</title>
<title>A Longitudinal View of Netflix: Content Delivery over IPv6 and Cont <author>
ent Cache Deployments</title> <organization/>
<author initials="T.V." surname="Doan"> </author>
<organization>TU Munich</organization> <date year="2015" month="March"/>
</author> </front>
<date year='2020' /> <refcontent>YouTube video, 25:32, posted by Upperside Conferences</refc
</front> ontent>
</reference> </reference>
<reference anchor='RIPE1' target="https://ripe73.ripe.net/wp-content/uplo <reference anchor="MAPRG" target="https://www.ietf.org/proceedings/99/sl
ads/presentations/35-2016-10-24-v6-performance.pdf"> ides/slides-99-maprg-measuring-youtube-content-delivery-over-ipv6-00.pdf">
<front> <front>
<title>Measuring IPv6 Performance</title> <title>Measuring YouTube Content Delivery over IPv6</title>
<author initials="G." surname="Huston"> <author initials="V." surname="Bajpai" fullname="Vaibhav Bajpai">
<organization>APNIC</organization> <organization>TU Munich</organization>
</author> </author>
<date year='2016' /> <date year="2017" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor='RIPE2' target="https://www.ripe.net/support/training/m <reference anchor="INFOCOM" target="https://dl.acm.org/doi/abs/10.1109/I
aterial/ipv6-security/ipv6security-slides.pdf"> NFOCOM41043.2020.9155367">
<front> <front>
<title>IPv6 Security</title> <title>A Longitudinal View of Netflix: Content Delivery over IPv6 an
<author> d Content Cache Deployments</title>
<organization>RIPE</organization> <author initials="T." surname="Doan">
</author> <organization>TU Munich</organization>
<date year='2019' /> </author>
</front> <author initials="V." surname="Bajpai">
</reference> <organization>TU Munich</organization>
</author>
<author initials="S." surname="Crawford">
<organization>SamKnows</organization>
</author>
<date year="2020" month="July"/>
</front>
<refcontent>IEEE INFOCOM 2020, IEEE Conference on Computer Communicatio
ns, pp. 1073-1082</refcontent>
<seriesInfo name="DOI" value="10.1109/INFOCOM41043.2020.9155367"/>
</reference>
<reference anchor='cmpwr' target="https://mydigitalpublication.com/articl <reference anchor="RIPE1" target="https://ripe73.ripe.net/wp-content/upl
e/Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U.S.+Federal+Governme oads/presentations/35-2016-10-24-v6-performance.pdf">
nt/3702828/664279/article.html"> <front>
<front> <title>Measuring IPv6 Performance</title>
<title>Impact on Enterprises of the IPv6-Only direction for the US Federal <author initials="G." surname="Huston">
Government</title> <organization>APNIC</organization>
<author> </author>
<organization>Compuware</organization> <date year="2016" month="October"/>
</author> </front>
<date year='2020' /> </reference>
</front>
</reference>
<reference anchor='BIPT' target="https://www.ripe.net/participate/meeting <reference anchor="RIPE2" target="https://www.ripe.net/support/training/
s/roundtable/september-2017/government-roundtable-meeting-bahrain-26-september-2 material/ipv6-security/ipv6security-slides.pdf">
017/presentations/belgium-experience-bahrain-roundtable.pdf"> <front>
<front> <title>IPv6 Security</title>
<title>IPv6 in Belgium</title> <author>
<author> <organization>RIPE</organization>
<organization>Belgian Institute for Postal services and Telecommunication </author>
s</organization> <date year="2023" month="January"/>
</author> </front>
<date year='2017' /> </reference>
</front>
</reference>
<reference anchor='GFA' target="https://media.frag-den-staat.de/files/foi <reference anchor="cmpwr" target="https://mydigitalpublication.com/artic
/531501/de-government-ipv6-masterplan-v100-entwurf_konvertiert.pdf"> le/Impact+on+Enterprises+of+the+IPv6-Only+Direction+for+the+U.S.+Federal+Governm
<front> ent/3702828/664279/article.html">
<title>IPv6-Masterplan für die Bundesverwaltung</title> <front>
<author> <title>Impact on Enterprises of the IPv6-Only Direction for the U.S.
<organization>German Federal Government Commissioner for Information Tech Federal Government</title>
nology</organization> <author initials="N." surname="Elkins">
</author> <organization>Compuware</organization>
<date year='2019' /> </author>
</front> </front>
</reference> </reference>
<reference anchor='IDT' target="https://dot.gov.in/revision-ipv6-transiti <reference anchor="BIPT" target="https://www.ripe.net/participate/meetin
on-timelines-2021"> gs/roundtable/september-2017/government-roundtable-meeting-bahrain-26-september-
<front> 2017/presentations/belgium-experience-bahrain-roundtable.pdf">
<title>Revision of IPv6 Transition Timelines</title> <front>
<author> <title>IPv6 in Belgium</title>
<organization>Indian Department of Telecommunications</organization> <author initials="J." surname="Vannieuwenhuyse">
</author> <organization>Belgian Institute for Postal services and telecommun
<date year='2021' /> ications</organization>
</front> </author>
</reference> <date year="2017" month="September"/>
</front>
</reference>
<reference anchor='RelJio' target="https://datatracker.ietf.org/meeting/1 <reference anchor="GFA" target="https://media.frag-den-staat.de/files/fo
09/materials/slides-109-v6ops-ipv6-only-adoption-challenges-and-standardization- i/531501/de-government-ipv6-masterplan-v100-entwurf_konvertiert.pdf">
requirements-03"> <front>
<front> <title>IPv6-Masterplan für die Bundesverwaltung</title>
<title>IPv6-only adoption challenges and standardization requirements</tit <author>
le> <organization>German Federal Government Commissioner for Informati
<author> on Technology</organization>
<organization>Reliance Jio</organization> </author>
</author> <date year="2019" month="November"/>
<date year='2020' /> </front>
</front> <refcontent>[IPv6 Master Plan for the Federal Administration]</refconte
</reference> nt>
</reference>
<reference anchor='TMus' target="https://pc.nanog.org/static/published/me <reference anchor="IDT" target="https://dot.gov.in/revision-ipv6-transit
etings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf"> ion-timelines-2021">
<front> <front>
<title>Going IPv6-only</title> <title>Revision of IPv6 Transition Timelines</title>
<author> <author>
<organization>T-Mobile US</organization> <organization>Government of India: Department of Telecommunication
</author> s</organization>
<date year='2018' /> </author>
</front> <date year="2021" month="February"/>
</reference> </front>
</reference>
<reference anchor='EE' target="https://indico.uknof.org.uk/event/38/contr <reference anchor="RelJio" target="https://datatracker.ietf.org/meeting/
ibutions/489/attachments/612/736/Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf"> 109/materials/slides-109-v6ops-ipv6-only-adoption-challenges-and-standardization
<front> -requirements-03">
<title>IPv6-only devices on EE mobile</title> <front>
<author> <title>IPv6-only adoption challenges and standardization requirement
<organization>EE</organization> s</title>
</author> <author initials="R." surname="Chandra">
<date year='2017' /> <organization>Reliance Jio</organization>
</front> </author>
</reference> <date year="2020" month="November"/>
</front>
</reference>
<reference anchor='CN' target="http://www.china.org.cn/business/2017-11/2 <reference anchor="TMus" target="https://pc.nanog.org/static/published/m
7/content_41948814.htm"> eetings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf">
<front> <front>
<title>China to speed up IPv6-based Internet development</title> <title>Going IPv6 Only</title>
<author> <author initials="S." surname="Lagerholm" fullname="Stephan Lagerhol
<organization>China.org.cn</organization> m">
</author> <organization>T-Mobile US</organization>
<date year='2017' /> </author>
</front> <date year="2018" month="June"/>
</reference> </front>
</reference>
<reference anchor='US-FR' target="https://www.federalregister.gov/documen <reference anchor="EE" target="https://indico.uknof.org.uk/event/38/cont
ts/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completing ributions/489/attachments/612/736/Nick_Heatley_EE_IPv6_UKNOF_20170119.pdf">
-the-transition-to-the-next-generation"> <front>
<front> <title>IPv6-only Devices on EE Mobile</title>
<title>Request for Comments on Updated Guidance for Completing the Transit <author initials="N." surname="Heatley" fullname="Nick Heatley">
ion to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6) <organization>EE</organization>
</title> </author>
<author> <date year="2017" month="January"/>
<organization>Federal Register</organization> </front>
</author> </reference>
<date year='2020' />
</front>
</reference>
<reference anchor='US-CIO' target="https://www.cio.gov/assets/resources/i <reference anchor="CN" target="http://www.china.org.cn/business/2017-11/
nternet-protocol-version6-draft.pdf"> 27/content_41948814.htm">
<front> <front>
<title>Memorandum for Heads of Executive Departments and Agencies. Complet <title>China to speed up IPv6-based Internet development</title>
ing the Transition to Internet Protocol Version 6 (IPv6)</title> <author>
<author> <organization>China.org.cn</organization>
<organization>The CIO Council</organization> </author>
</author> <date year="2017" month="November"/>
<date year='2020' /> </front>
</front> </reference>
</reference>
<reference anchor='ARIN-CG' target="https://www.arin.net/about/community_ <reference anchor="US-FR" target="https://www.federalregister.gov/docume
grants/recipients/"> nts/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completin
<front> g-the-transition-to-the-next-generation">
<title>Community Grant Program: IPv6 Security, Applications, and Training <front>
for Enterprises</title> <title>Request for Comments on Updated Guidance for Completing the T
<author> ransition to the Next Generation Internet Protocol, Internet Protocol Version 6
<organization>ARIN</organization> (IPv6)</title>
</author> <author>
<date year='2020' /> <organization>Federal Register</organization>
</front> </author>
</reference> <date year="2020" month="March"/>
</front>
</reference>
<reference anchor='ARIN-SW' target="https://www.arin.net/resources/guide/ <reference anchor="US-CIO" target="https://www.cio.gov/assets/resources/
ipv6/preparing_apps_for_v6.pdf"> internet-protocol-version6-draft.pdf">
<front> <front>
<title>Preparing Applications for IPv6</title> <title>Memorandum for Heads of Executive Departments and Agencies: C
<author> ompleting the Transition to Internet Protocol Version 6 (IPv6)</title>
<organization>ARIN</organization> <author initials="R" surname="Vought" fullname="Russell T. Vought">
</author> <organization>The CIO Council</organization>
<date year='' /> </author>
</front> <date year="2020"/>
</reference> </front>
<reference anchor='ISIF-ASIA-G' target="https://isif.asia/2020-grantees/" </reference>
>
<front>
<title>Internet Operations Research Grant: IPv6 Deployment at Enterprises.
IIESoc. India</title>
<author>
<organization>ISIF Asia</organization>
</author>
<date year='2020' />
</front>
</reference>
<reference anchor='WIPv6L' target="https://www.worldipv6launch.org/measu <reference anchor="ARIN-CG" target="https://www.arin.net/about/community
rements/"> _grants/recipients/2020">
<front> <front>
<title>World IPv6 Launch - Measurements</title> <title>2020 ARIN Community Grant Program Recipients: IPv6
<author> Security, Applications, and Training for Enterprises</title>
<organization>World IPv6 Launch</organization> <author>
</author> <organization>ARIN</organization>
<date year='2021' /> </author>
</front> <date year="2020"/>
</reference> </front>
</reference>
<reference anchor='W3Techs' target="https://w3techs.com/technologies/hist <reference anchor="ARIN-SW" target="https://www.arin.net/resources/guide
ory_overview/site_element/all/y"> /ipv6/preparing_apps_for_v6.pdf">
<front> <front>
<title>Historical yearly trends in the usage statistics of site elements f <title>Preparing Applications for IPv6</title>
or websites</title> <author>
<author> <organization>ARIN</organization>
<organization>W3Techs</organization> </author>
</author> </front>
<date year='2021' /> </reference>
</front>
</reference>
<reference anchor='Csc6lab' target="https://6lab.cisco.com/stats/"> <reference anchor="ISIF-ASIA-G" target="https://isif.asia/ipv6-deploymen
<front> t-at-enterprises/">
<title>World - Display Content Data</title> <front>
<author> <title>IPv6
<organization>Cisco</organization> Deployment at Enterprises</title>
</author> <author>
<date year='2022' /> <organization>India Internet Engineering Society (IIESoc)</organiz
</front> ation>
</reference> </author>
<date year="2022" month="March"/>
</front>
</reference>
<reference anchor='Alx' target="https://www.alexa.com/topsites"> <reference anchor="WIPv6L" target="https://www.worldipv6launch.org/measu
<front> rements/">
<title>The top 500 sites on the web</title> <front>
<author> <title>Measurements</title>
<organization>Alexa</organization> <author>
</author> <organization>World IPv6 Launch</organization>
<date year='2021' /> </author>
</front> <date month="June" year="2022"/>
</reference> </front>
</reference>
<reference anchor='SNDVN' target="https://www.sandvine.com/press-releases <reference anchor="W3Techs" target="https://w3techs.com/technologies/his
/sandvine-releases-2020-mobile-internet-phenomena-report-youtube-is-over-25-of-a tory_overview/site_element/all/y">
ll-mobile-traffic"> <front>
<front> <title>Historical yearly trends in the usage statistics of site elem
<title>Sandvine releases 2020 Mobile Internet Phenomena Report: YouTube is ents for websites</title>
over 25% of all mobile traffic</title> <author>
<author> <organization>W3Techs</organization>
<organization>SANDVINE</organization> </author>
</author> <date year="2023"/>
<date year='2020' /> </front>
</front> </reference>
</reference>
<reference anchor='NST_1' target="https://fedv6-deployment.antd.nist.gov/ <reference anchor="Csc6lab" target="https://6lab.cisco.com/stats/">
cgi-bin/generate-com"> <front>
<front> <title>Display global data</title>
<title>Estimating Industry IPv6 and DNSSEC External Service Deployment Sta <author>
tus</title> <organization>Cisco</organization>
<author> </author>
<organization>NIST</organization> <date year="2023"/>
</author> </front>
<date year='2022' /> </reference>
</front>
</reference>
<reference anchor='NST_2' target="https://fedv6-deployment.antd.nist.gov/ <reference anchor="SNDVN" target="https://www.sandvine.com/press-release
cgi-bin/generate-gov"> s/sandvine-releases-2020-mobile-internet-phenomena-report-youtube-is-over-25-of-
<front> all-mobile-traffic">
<title>Estimating USG IPv6 and DNSSEC External Service Deployment Status</ <front>
title> <title>Sandvine releases 2020 Mobile Internet Phenomena Report: YouT
<author> ube is over 25% of all mobile traffic</title>
<organization>NIST</organization> <author initials="C." surname="Cullen" fullname="Cam Cullen">
</author> <organization>SANDVINE</organization>
<date year='2022' /> </author>
</front> <date year="2020" month="February"/>
</reference> </front>
</reference>
<reference anchor='NST_3' target="https://fedv6-deployment.antd.nist.gov/ <reference anchor="NST_1" target="https://fedv6-deployment.antd.nist.gov
cgi-bin/generate-edu"> /cgi-bin/generate-com">
<front> <front>
<title>Estimating University IPv6 and DNSSEC External Service Deployment S <title>Estimating Industry IPv6 &amp; DNSSEC External Service Deploy
tatus</title> ment Status</title>
<author> <author>
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<date year='2022' /> <date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor='BGR_1' target="http://218.2.231.237:5001/cgi-bin/gener <reference anchor="NST_2" target="https://fedv6-deployment.antd.nist.gov
ate"> /cgi-bin/generate-gov">
<front> <front>
<title>China Commercial IPv6 and DNSSEC Deployment Monitor</title> <title>Estimating USG IPv6 &amp; DNSSEC External Service Deployment
<author> Status</title>
<organization>BIIGROUP</organization> <author>
</author> <organization>NIST</organization>
<date year='2022' /> </author>
</front> <date year="2023"/>
</reference> </front>
</reference>
<reference anchor='BGR_2' target="http://218.2.231.237:5001/cgi-bin/gener <reference anchor="NST_3" target="https://fedv6-deployment.antd.nist.gov
ate_gov"> /cgi-bin/generate-edu">
<front> <front>
<title>China Government IPv6 and DNSSEC Deployment Monitor</title> <title>Estimating University IPv6 &amp; DNSSEC External Service Depl
<author> oyment Status</title>
<organization>BIIGROUP</organization> <author>
</author> <organization>NIST</organization>
<date year='2022' /> </author>
</front> <date year="2023"/>
</reference> </front>
</reference>
<reference anchor='BGR_3' target="http://218.2.231.237:5001/cgi-bin/gener <reference anchor="BGR_1" target="http://218.2.231.237:5001/cgi-bin/gene
ate_edu"> rate">
<front> <front>
<title>China Education IPv6 and DNSSEC Deployment Monitor</title> <title>China Commercial IPv6 and DNSSEC Deployment Monitor</title>
<author> <author>
<organization>BIIGROUP</organization> <organization>BIIGROUP</organization>
</author> </author>
<date year='2022' /> <date month="December" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor='CNLABS_1' target="https://cnlabs.in/IPv6_Mon/generate_ <reference anchor="BGR_2" target="http://218.2.231.237:5001/cgi-bin/gene
industry.html"> rate_gov">
<front> <front>
<title>Industry IPv6 and DNSSEC Statistics</title> <title>China Government IPv6 and DNSSEC Deployment Monitor</title>
<author> <author>
<organization>CNLABS</organization> <organization>BIIGROUP</organization>
</author> </author>
<date year='2022' /> <date month="December" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor='CNLABS_2' target="https://cnlabs.in/IPv6_Mon/generate_ <reference anchor="BGR_3" target="http://218.2.231.237:5001/cgi-bin/gene
gov.html"> rate_edu">
<front> <front>
<title>Industry IPv6 and DNSSEC Statistics</title> <title>China Education IPv6 and DNSSEC Deployment Monitor</title>
<author> <author>
<organization>CNLABS</organization> <organization>BIIGROUP</organization>
</author> </author>
<date year='2022' /> <date month="December" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor='IPv6Forum' target="https://www.ipv6forum.com/IPv6-Moni <reference anchor="CNLABS_1" target="https://cnlabs.in/IPv6_Mon/generate
toring/index.html"> _industry.html">
<front> <front>
<title>Estimating IPv6 &amp; DNSSEC External Service Deployment Status</ti <title>Industry IPv6 and DNSSEC Statistics</title>
tle> <author>
<author> <organization>CNLABS</organization>
<organization>IPv6Forum</organization> </author>
</author> <date year="2022"/>
<date year='2022' /> </front>
</front> </reference>
</reference>
<reference anchor='Akm-stats' target="https://www.akamai.com/uk/en/resour <reference anchor="CNLABS_2" target="https://cnlabs.in/IPv6_Mon/generate
ces/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoptio _gov.html">
n-visualization.jsp"> <front>
<front> <title>Government IPv6 and DNSSEC Statistics</title>
<title>IPv6 Adoption Visualization</title> <author>
<author> <organization>CNLABS</organization>
<organization>Akamai</organization> </author>
</author> <date year="2022"/>
<date year='2021' /> </front>
</front> </reference>
</reference>
<reference anchor='Cldflr' target="https://support.cloudflare.com/hc/en-u <reference anchor="IPv6Forum" target="https://www.ipv6forum.com/IPv6-Mon
s/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support"> itoring/index.html">
<front> <front>
<title>Understanding and configuring Cloudflare's IPv6 support</title> <title>Estimating IPv6 &amp; DNSSEC External Service Deployment Stat
<author> us</title>
<organization>Cloudflare</organization> <author>
</author> <organization>IPv6Forum</organization>
<date /> </author>
</front> <date year="2023"/>
</reference> </front>
</reference>
<reference anchor='Ggl' target="https://support.google.com/interconnect/a <reference anchor="Akm-stats" target="https://www.akamai.com/uk/en/resou
nswer/9058809?hl=en"> rces/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adopti
<front> on-visualization">
<title>Introduction to GGC</title> <front>
<author> <title>IPv6 Adoption Visualization</title>
<organization>Google</organization> <author>
</author> <organization>Akamai</organization>
<date /> </author>
</front> <date year="2023"/>
</reference> </front>
</reference>
<reference anchor='Ntflx' target="https://netflixtechblog.com/enabling-su <reference anchor="Cldflr" target="https://support.cloudflare.com/hc/en-
pport-for-ipv6-48a495d5196f"> us/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support">
<front> <front>
<title>Enabling Support for IPv6</title> <title>Understanding and configuring Cloudflare's IPv6 support</titl
<author> e>
<organization>Netflix</organization> <author>
</author> <organization>Cloudflare</organization>
<date /> </author>
</front> </front>
</reference> </reference>
<reference anchor='Amzn' target="https://aws.amazon.com/es/about-aws/what <reference anchor="Ggl" target="https://support.google.com/interconnect/
s-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/"> answer/9058809?hl=en">
<front> <front>
<title>Announcing Internet Protocol Version 6 (IPv6) support for Amazon Cl <title>Introduction to GGC</title>
oudFront, AWS WAF, and Amazon S3 Transfer Acceleration</title> <author>
<author> <organization>Google</organization>
<organization>Amazon</organization> </author>
</author> </front>
<date /> </reference>
</front>
</reference>
<reference anchor='Mcrsft' target="https://azure.microsoft.com/en-us/upda <reference anchor="Ntflx" target="https://netflixtechblog.com/enabling-s
tes/ipv6-for-azure-vms/"> upport-for-ipv6-48a495d5196f">
<front> <front>
<title>IPv6 for Azure VMs available in most regions</title> <title>Enabling Support for IPv6</title>
<author> <author initials="R." surname="Aggarwal" fullname="Rajiv Aggarwal">
<organization>Microsoft</organization> <organization>Netflix</organization>
</author> </author>
<date /> <author initials="D." surname="Temkin" fullname="David Temkin">
</front> <organization>Netflix</organization>
</reference> </author>
<date year="2012" month="July"/>
</front>
</reference>
<reference anchor='Vrzn' target="https://www.verizondigitalmedia.com/blog <reference anchor="Amzn" target="https://aws.amazon.com/es/about-aws/wha
/verizon-digital-media-services-announces-ipv6-compliance/"> ts-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/">
<front> <front>
<title>Verizon Digital Media Services announces IPv6 Compliance</title> <title>Announcing Internet Protocol Version 6 (IPv6) support for Ama
<author> zon CloudFront, AWS WAF, and Amazon S3 Transfer Acceleration</title>
<organization>Verizon</organization> <author>
</author> <organization>Amazon Web Services</organization>
<date /> </author>
</front> <date month="October" year="2016"/>
</reference> </front>
</reference>
<reference anchor='ANSI' target="https://shop.cta.tech/products/host-and- <reference anchor="Mcrsft" target="https://azure.microsoft.com/en-us/upd
router-profiles-for-ipv6"> ates/ipv6-for-azure-vms/">
<front> <front>
<title>ANSI/CTA Standard Host and Router Profiles for IPv6</title> <title>IPv6 for Azure VMs available in most regions</title>
<author> <author>
<organization>ANSI/CTA</organization> <organization>Microsoft</organization>
</author> </author>
<date year='2020' /> <date month="September" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor='ComputSecur' > <reference anchor="ANSI" target="https://shop.cta.tech/products/host-and
<front> -router-profiles-for-ipv6">
<title>Methodology for the identification of potential security issues of <front>
different IPv6 transition technologies: Threat analysis of DNS64 and stateful NA <title>Host and Router Profiles for IPv6</title>
T64</title> <author>
<author> <organization>ANSI</organization>
<organization>Computers &amp; Security (Elsevier)</organization> </author>
</author> <date year="2020" month="October"/>
<date year='2018' /> </front>
</front> <seriesInfo name="ANSI/CTA" value="2048-A"/>
<seriesInfo name='DOI' value='10.1016/j.cose.2018.04.012'/> </reference>
</reference>
<reference anchor="ComputSecur">
<front>
<title>Methodology for the identification of potential security issu
es of different IPv6 transition technologies: Threat analysis of DNS64 and state
ful NAT64</title>
<author initials="G." surname="Lencse" fullname="Gábor Lencse">
</author>
<author initials="Y." surname="Kadobayashi" fullname="Youki Kadobayas
hi">
</author>
<date year="2018" month="August"/>
</front>
<refcontent>Computers and Security, Volume 77, Issue C, pp. 397-411</re
fcontent>
<seriesInfo name="DOI" value="10.1016/j.cose.2018.04.012"/>
</reference>
</references>
</references> </references>
<section title="Summary of Questionnaire and Replies for network operator <section anchor="Appendix_A" numbered="true" toc="default">
s" anchor="Appendix_A"> <name>Summary of Questionnaire and Replies for Network Operators</name>
<t>A survey was proposed to more than 50 service providers in the
<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 European region during the third quarter of 2020 to ask for their
plans on IPv6 and the status of IPv6 deployment.</t> plans on IPv6 and the status of IPv6 deployment.</t>
<t>In this survey, 40 people, representing 38 organizations, provided resp
onses.
This appendix summarizes the results obtained.</t>
<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 plans to move more fixed, mobile, or enterprise
users
to IPv6 in the next 2 years?</t>
<ol type="A">
<li>If so, fixed, mobile, or enterprise?</li>
<li>What are the reasons to do so?</li>
<li>When to start: already ongoing, in 12 months, or after 12 months?</li>
<li>Which transition solution will you use: Dual-Stack, DS-Lite, 464XLAT,
or MAP-T/E?</li>
</ol>
<t>40 people, representing 38 organizations, provided a response. <t>Answers for 1.A (38 respondents)</t>
This appendix summarizes the results obtained.</t> <table align="center">
<figure> <name>Plan to Move to IPv6 within 2 Years</name>
<artwork><![CDATA[ <thead>
Respondents' business <tr>
Convergent Mobile Fixed <th>Yes</th>
Type of operators 82% 8% 11% <th>No</th>
]]></artwork> </tr>
</figure> </thead>
<tbody>
<t>Question 1. Do you have plan to move more fixed or mobile or enterprise us <tr>
ers <td>79%</td>
to IPv6 in the next 2 years?</t> <td>21%</td>
<t>a. If so, fixed, or mobile, or enterprise?</t> </tr>
<t>b. What are the reasons to do so?</t> </tbody>
<t>c. When to start: already on going, in 12 months, after 12 months?</t> </table>
<t>d. Which transition solution will you use, Dual-Stack, DS-Lite, 464XLAT,
MAP-T/E?</t>
<t>Answer 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 1.B (29 respondents)</t>
<t>Even this was an open question, some common answers can be found.</t>
<t>14 respondents (48%) highlighted issues related to IPv4 depletion. The rea
son to move
to IPv6 is to avoid private and/or overlapping addresses.</t>
<t>For 6 respondents (20%) 5G/IoT is a business incentive to introduce IPv6.<
/t>
<t>4 respondents (13%) also highlight that there is a National regulation req
uest to enable IPv6
associated with the launch of 5G.</t>
<t>4 respondents (13%) consider IPv6 as a part of their innovation strategy o
r an enabler
for new services.</t>
<t>4 respondents (13%) introduce IPv6 because of Enterprise customers demand.
</t>
<t>Answer 1.C (30 respondents)</t>
<figure>
<artwork><![CDATA[
Ongoing In 12 months After 12 months Don't answer
Timeframe 60% 33% 0% 7%
]]></artwork>
</figure>
<t>Answer 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>
<t>Question 2. Do you need to change network devices for the above goal?</t>
<t>a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT?</t>
<t>b. Will you start the transition of your metro or backbone or backhaul ne
twork to support IPv6?</t>
<t>Answer 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 2.B (22 respondents)</t>
<figure>
<artwork><![CDATA[
Yes Future No
Plans for transition 9% 9% 82%
]]></artwork>
</figure>
</section>
<section title="Summary of Questionnaire and Replies for enterprises" anc
hor="Appendix_B">
<t>The Industry Network Technology Council (INTC) developed the following pol <table align="center">
l to <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>
<ul>
<li>14 respondents (48%) highlighted issues related to IPv4 depletion. Th
e reason to move
to IPv6 is to avoid private and/or overlapping addresses.</li>
<li>6 respondents (20%) stated that 5G/IoT is a business incentive to intr
oduce IPv6.</li>
<li>4 respondents (13%) highlighted that there is a national regulation re
quest to associate and enable IPv6 with the launch of 5G.</li>
<li>4 respondents (13%) considered IPv6 as a part of their innovation stra
tegy or an enabler
for new services.</li>
<li>4 respondents (13%) introduced IPv6 because of enterprise customer dem
and.</li>
</ul>
<t>Answers for 1.C (30 respondents)</t>
<table align="center">
<name>Timeframe</name>
<thead>
<tr>
<th>Ongoing</th>
<th>In 12 months</th>
<th>After 12 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>
<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>
<ol type="A">
<li>If yes, what kind of devices: CPE, BNG/mobile core, or NAT?</li>
<li>Will you start the transition of your metro, backbone, or backhaul net
work to support IPv6?</li>
</ol>
<t>Answers for 2.A (30 respondents)</t>
<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>
<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 anchor="Appendix_B" numbered="true" toc="default">
<name>Summary of Questionnaire and Replies for 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 verify the need or willingness of medium-to-large US-based enterprises
for training and consultancy on IPv6 (https://industrynetcouncil.org/) in ear for training and consultancy on IPv6 <eref brackets="angle" target="https://i
ly 2021.</t> ndustrynetcouncil.org/"/> in early 2021.</t>
<t>54 organizations provided answers.</t>
<t>54 organizations provided an answer.</t> <t>Question 1. How much IPv6 implementation have you done at your organiza
tion?
<t>Question 1. How much IPv6 implementation have you done at your organizatio (54 respondents)</t>
n?
(54 respondents)</t>
<figure>
<artwork><![CDATA[
None 16.67%
Some people have gotten some training 16.67%
Many people have gotten some training 1.85%
Website is IPv6 enabled 7.41%
Most equipment is dual-stacked 31.48%
Have an IPv6 transition plan for entire network 5.56%
Running IPv6-only in many places 20.37%
Entire network is IPv6-only 0.00%
]]></artwork>
</figure>
<t>Question 2. What kind of help or classes would you like to see INTC do? (
54 respondents)</t>
<figure>
<artwork><![CDATA[
Classes/labs on IPv6 security 66.67%
Classes/labs on IPv6 fundamentals 55.56%
Classes/labs on address planning/network conf. 57.41%
Classes/labs on IPv6 troubleshooting 66.67%
Classes/labs on application conversion 35.19%
Other 14.81%
]]></artwork>
</figure>
<t>Question 3. As you begin to think about the implementation of IPv6 <table>
<name>IPv6 Implementation</name>
<tbody>
<tr>
<td>None</td>
<td>16.67%</td>
</tr>
<tr>
<td>Some people have gotten some training</td>
<td>16.67%</td>
</tr>
<tr>
<td>Many people have gotten some training</td>
<td>1.85%</td>
</tr>
<tr>
<td>Website is IPv6 enabled</td>
<td>7.41%</td>
</tr>
<tr>
<td>Most equipment is dual-stacked</td>
<td>31.48%</td>
</tr>
<tr>
<td>Have an IPv6 transition plan for entire network</td>
<td>5.56%</td>
</tr>
<tr>
<td>Running IPv6-only in many places</td>
<td>20.37%</td>
</tr>
<tr>
<td>Entire network is 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 respondents)</t>
<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.</td>
<td>57.41%</td>
</tr>
<tr>
<td>Classes/labs on IPv6 troubleshooting</td>
<td>66.67%</td>
</tr>
<tr>
<td>Classes/labs on application 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? at your organization, what areas do you feel are of concern?
(54 respondents)</t> (54 respondents)</t>
<figure> <table align="center">
<artwork><![CDATA[ <name>Areas of Concern for IPv6 Implementation</name>
Security 31.48% <tbody>
Application conversion 25.93% <tr>
Training 27.78% <td>Security</td>
All the above 33.33% <td>31.48%</td>
Don't know enough to answer 14.81% </tr>
Other 9.26% <tr>
]]></artwork> <td>Application conversion</td>
</figure> <td>25.93%</td>
</tr>
</section> <tr>
</back> <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</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="Bri
an Carpenter"/>, <contact fullname="Fred Baker"/>, <contact fullname="Alexandre
Petrescu"/>, <contact fullname="Fernando Gont"/>,
<contact fullname="Barbara Stark"/>, <contact fullname="Haisheng Yu (John
son)"/>, <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="Donav
an 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> </rfc>
 End of changes. 248 change blocks. 
2408 lines changed or deleted 2668 lines changed or added

This html diff was produced by rfcdiff 1.48.