idnits 2.17.1 draft-ietf-v6ops-ipv6-deployment-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-transition-comparison-02 ** Obsolete normative reference: RFC 6036 (Obsoleted by RFC 9386) == Outdated reference: A later version (-04) exists of draft-ietf-bess-ipv6-only-pe-design-00 == Outdated reference: A later version (-06) exists of draft-palet-v6ops-ipv6-only-05 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS G. Fioccola 3 Internet-Draft P. Volpato 4 Intended status: Informational Huawei Technologies 5 Expires: September 8, 2022 N. Elkins 6 Inside Products 7 J. Palet Martinez 8 The IPv6 Company 9 G. Mishra 10 Verizon Inc. 11 C. Xie 12 China Telecom 13 March 7, 2022 15 IPv6 Deployment Status 16 draft-ietf-v6ops-ipv6-deployment-05 18 Abstract 20 This document provides an overview of IPv6 deployment status and a 21 view on how the transition to IPv6 is progressing among network 22 operators and enterprises. It also aims to analyze the related 23 challenges and therefore encourage actions and more investigations in 24 those areas where the industry has not taken a clear and unified 25 approach. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 8, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. IPv4 vs IPv6: The Global Picture . . . . . . . . . . . . . . 5 63 2.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5 64 2.2. IPv6 Users . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. IPv6 Web Content . . . . . . . . . . . . . . . . . . . . 7 66 2.4. IPv4 addresses per capita and IPv6 status . . . . . . . . 7 67 3. A Survey on IPv6 Deployments . . . . . . . . . . . . . . . . 10 68 3.1. IPv6 Allocations and Networks . . . . . . . . . . . . . . 10 69 3.2. IPv6 among Network Operators . . . . . . . . . . . . . . 12 70 3.3. IPv6 among Enterprises . . . . . . . . . . . . . . . . . 14 71 3.3.1. Government and Universities . . . . . . . . . . . . . 15 72 3.4. Observations on Industrial Internet . . . . . . . . . . . 17 73 3.5. Observations on Content and Cloud Service Providers . . . 17 74 3.6. Application Transition . . . . . . . . . . . . . . . . . 18 75 4. Towards an IPv6 Overlay Service Design . . . . . . . . . . . 18 76 4.1. IPv6 introduction . . . . . . . . . . . . . . . . . . . . 19 77 4.2. IPv6-only Service Delivery . . . . . . . . . . . . . . . 20 78 5. IPv6-only Underlay Network Deployment . . . . . . . . . . . . 21 79 6. IPv6 Benefits . . . . . . . . . . . . . . . . . . . . . . . . 23 80 7. Common IPv6 Challenges . . . . . . . . . . . . . . . . . . . 25 81 7.1. Transition Choices . . . . . . . . . . . . . . . . . . . 25 82 7.1.1. Service Providers . . . . . . . . . . . . . . . . . . 25 83 7.1.2. Enterprises and Industrial Internet . . . . . . . . . 26 84 7.1.3. Cloud and Data Centers . . . . . . . . . . . . . . . 27 85 7.1.4. CEs and user devices . . . . . . . . . . . . . . . . 28 86 7.2. Government and Regulators . . . . . . . . . . . . . . . . 28 87 7.3. Network Management and Operations . . . . . . . . . . . . 29 88 7.4. Performance . . . . . . . . . . . . . . . . . . . . . . . 29 89 7.4.1. IPv6 packet loss and latency . . . . . . . . . . . . 30 90 7.4.2. Customer Experience . . . . . . . . . . . . . . . . . 30 91 7.5. IPv6 security . . . . . . . . . . . . . . . . . . . . . . 31 92 7.5.1. Protocols security issues . . . . . . . . . . . . . . 32 93 7.5.2. IPv6 Extension Headers and Fragmentation . . . . . . 33 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 95 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 100 12.2. Informative References . . . . . . . . . . . . . . . . . 36 101 Appendix A. Summary of Questionnaire and Replies for network 102 operators . . . . . . . . . . . . . . . . . . . . . 42 103 Appendix B. Summary of Questionnaire and Replies for enterprises 44 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 106 1. Introduction 108 [RFC6036] described IPv6 deployment scenarios adopted or foreseen by 109 a number of Internet Service Providers (ISPs) who responded to a 110 technical questionnaire in early 2010. In doing that, [RFC6036] 111 provided practices and plans expected to take place in the following 112 years. Since the publication of [RFC6036], several other documents 113 contributed to discuss the transition to IPv6 in operational 114 environments. To name a few: 116 - [RFC6180] discussed IPv6 deployment models and transition 117 mechanisms, recommending those that showed to be effective in 118 operational networks. 120 - [RFC6883] provided guidance and suggestions for Internet content 121 providers and Application Service Providers (ASPs). 123 - [RFC7381] introduced the guidelines of IPv6 deployment for 124 enterprises. 126 It is worth mentioning here also [RFC6540] that not only recommended 127 the support of IPv6 to all IP-capable nodes, but it was referenced in 128 the IAB Statement on IPv6 [IAB], which represented a major step in 129 driving the IETF as well as other Standard Developing Organizations 130 (SDOs) to assume the use of IPv6 in their works. 132 In more recent times, organizations such as ETSI provided more 133 contributions to the use of IPv6 in operational environments, 134 targeting IPv6 in different industry segments. As a result, 135 [ETSI-IP6-WhitePaper], was published to provide an updated view on 136 the IPv6 best practices adopted so far, in particular in the ISPs 137 domain. 139 Considering all of the above, and after more than ten years since the 140 publication of [RFC6036] it may be interesting to verify where the 141 transition of the Internet to IPv6 currently stands, what major steps 142 have been accomplished and what is still missing. Some reasons 143 justify such questions: 145 - In some areas, the lack of publicly available IPv4 addresses 146 forced both carriers and content providers to shift to IPv6 to 147 support the introduction of new applications, in particular in 148 wireless networks. 150 - Some governmental actions took place to encourage or even 151 enforce, at different degrees, the adoption of IPv6 in certain 152 countries. 154 - Looking at the global adoption of IPv6, this seems to have 155 reached a threshold that justifies speaking of native, end-to-end 156 IPv6 connectivity (between a user's device and a content on a 157 site) at the IPv6 service layer. 159 This document intends to explode such statements, providing a survey 160 of the status of IPv6 deployment and highlighting both the 161 achievements and remaining obstacles in the transition to IPv6-only 162 networks. The target is to give an updated view of the practices and 163 plans already described in [RFC6036], to encourage further actions 164 and more investigations in those areas that are still under 165 discussion, and to present the main incentives for the adoption of 166 IPv6. The expectation is that this process may help to understand 167 what is missing and how to improve the current IPv6 deployment 168 strategies of network operators, enterprises, content and cloud 169 service providers. 171 The initial section of this document reports some data about the 172 status of IPv6. The exhaustion of IPv4 as well as the measured 173 adoption of IPv6 at the users' and the content's side will be 174 discussed. Comparing both IPv4 and IPv6, this latter has a higher 175 growth rate. While this fact alone does not permit to conclude that 176 the definitive transition to IPv6 is undergoing, at least testifies 177 that a portion of the ICT industry has decided to invest and deploy 178 IPv6 at large. 180 The next section provides a survey of IPv6 deployments in different 181 environments, including ISPs, enterprises, cloud providers and 182 universities. Data from some well-known analytics will be discussed. 183 In addition, two independent polls among network operators and 184 enterprises will also be presented. 186 Then, a section on IPv6 overlay service design will describe the IPv6 187 transition approaches for Mobile BroadBand (MBB), Fixed BroadBand 188 (FBB) and Enterprise services. At present, Dual-Stack (DS) is the 189 most deployed solution for IPv6 introduction, while 464XLAT and Dual- 190 Stack Lite (DS-Lite) seem the preferred ones for those players that 191 have already enabled IPv6-only service delivery. A section on IPv6 192 underlay network deployment will also focus on the common approaches 193 for the transport network. 195 The last parts of the document will analyze the incentives brought by 196 IPv6 as well as the general challenges to be faced to move forward in 197 the transition. Specific attention will be given to operational, 198 performance and security issues. All these considerations will be 199 input for the final section of the document that aims to highlight 200 the areas still requiring improvement and some actions that the 201 industry might consider to favor the adoption of IPv6. 203 2. IPv4 vs IPv6: The Global Picture 205 This section deals with some key questions related to IPv6, namely 206 the status of IPv4 exhaustion, often considered as one of the 207 triggers to switch to IPv6, the number of IPv6 end users, a primary 208 measure to sense IPv6 adoption, and the percentage of websites 209 reachable over IPv6. The former is constantly measured by the 210 Regional Internet Registries (RIRs) and the next subsection provides 211 an indication of where we currently stand. The utilization of IPv6 212 at both the end user's side and the content's side has also been 213 monitored by several institutions worldwide as these two parameters 214 provide a first-order indication on the real adoption of IPv6. 216 2.1. IPv4 Address Exhaustion 218 According to [CAIR] there will be 29.3 billion networked devices by 219 2023, up from 18.4 billion in 2018. This poses the question on 220 whether the IPv4 address space can sustain such a number of 221 allocations and, consequently, if this is affecting the process of 222 its exhaustion. The answer is not straightforward as many aspects 223 have to be considered. 225 On one hand, the RIRs are reporting scarcity of available and still 226 reserved addresses. Table 3 of [POTAROO1] shows that the available 227 pool of the five RIRs counts 5.2 million IPv4 addresses, while the 228 reserved pool includes another 12 million, for a total of "usable" 229 addresses equal to 17.3 million (-5.5% year over year, comparing 2021 230 against 2020). The same reference, in table 1, shows that the total 231 IPv4 allocated pool equals to 3.685 billion addresses (+0.027% year 232 over year). The ratio between the "usable" addresses and the total 233 allocated brings to 0.469% of remaining space (from 0.474% at the end 234 of 2020). 236 On the other, [POTAROO1] again highlights the role of both NAT and 237 the address transfer to counter the IPv4 exhaustion. NAT systems 238 well fit in the current client/server model used by most of the 239 available Internet applications, with this phenomenon amplified by 240 the general shift to cloud. Anyway, it should be noted that, in some 241 cases, private address space cannot provide adequate address and the 242 reuse of addresses may make the network even more complex. The 243 transfer of IPv4 addresses also contributes to mitigate the need of 244 addresses. As an example, [IGP-GT] and [NRO] show the amount of 245 transfers to recipient organizations in the different regions. Cloud 246 Service Providers (CSPs) appear to be the most active in buying 247 available addresses to satisfy their need of providing IPv4 248 connectivity to their tenants. But, since each address blocks of 249 Internet is licensed by a specific resource-holder and stored for the 250 verification of the authenticity, frequent address transfer may 251 affect the global assignment process. 253 2.2. IPv6 Users 255 The count of the IPv6 users is the key parameter to get an immediate 256 understanding of the adoption of IPv6. Some organizations constantly 257 track the usage of IPv6 by aggregating data from several sources. As 258 an example, the Internet Society constantly monitors the volume of 259 IPv6 traffic for the networks that joined the WorldIPv6Launch 260 initiative [WIPv6L]. The measurement aggregates statistics from 261 organizations such as [Akm-stats] that provides data down to the 262 single network level measuring the number of hits to their content 263 delivery platform. For the scope of this document, we follow the 264 approach used by APNIC to quantify the adoption of IPv6 by means of a 265 script that runs on a user's device [CAIDA]. To give a rough 266 estimation of the relative growth of IPv6, the next table aggregates 267 the total number of estimated IPv6-capable users at January 2022, and 268 compares it against the total Internet users, as measured by 269 [POTAROO2]. 271 +--------+--------+--------+--------+--------+--------+--------+ 272 | | Jan | Jan | Jan | Jan | Jan | CAGR | 273 | | 2018 | 2019 | 2020 | 2021 | 2022 | | 274 +--------+--------+--------+--------+--------+--------+--------+ 275 | IPv6 | 513.07| 574.02| 989.25|1,136.28|1,207.61| 23.9% | 276 +--------+--------+--------+--------+--------+--------+--------+ 277 | World |3,410.27|3,470.36|4,065.00|4,091.62|4,093.69| 4.7% | 278 +--------+--------+--------+--------+--------+--------+--------+ 279 | Ratio | 15.0%| 16.5%| 24.3%| 27.8%| 29.5%| 18.4% | 280 +--------+--------+--------+--------+--------+--------+--------+ 282 Figure 1: IPv6-capable users against total (in millions) 284 Two figures appear: first, the IPv6 Internet population is growing 285 with a two-digits Compound Annual Growth Rate (CAGR), and second, the 286 ratio IPv6 over total is also growing steadily. 288 2.3. IPv6 Web Content 290 [W3Tech] keeps track of the use of several technical components of 291 websites. The utilization of IPv6 for websites is shown in the next 292 table. 294 +------------+-------+-------+-------+-------+-------+------+ 295 | Wolrdwide | Jan | Jan | Jan | Jan | Jan | CAGR | 296 | Websites | 2018 | 2019 | 2020 | 2021 | 2022 | | 297 +------------+-------+-------+-------+-------+-------+------+ 298 |% of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9%| 299 +------------+-------+-------+-------+-------+-------+------+ 301 Figure 2: Usage of IPv6 in websites 303 Looking at the growth rate, it may appear not particularly high. It 304 has to be noted, though, that not all websites are equal. The 305 largest content providers, which already support IPv6, generate a lot 306 more IPv6-based content than small websites. [Csc6lab] measured at 307 the beginning of January 2022 that out of the world top 500 sites 308 ranked by [Alx], 203 are IPv6-enabled (+3.6% from January 2021 to 309 January 2022). If we consider that the big content providers (such 310 as Google, Facebook, Netflix) generate more than 50% of the total 311 mobile traffic [SNDVN], and in some cases even more up to 65% 312 ([ISOC1] [HxBld]), the percentage of content accessible over IPv6 is 313 clearly more relevant than the number of enabled IPv6 websites. 315 Related to that, a question that sometimes arises is whether the 316 content stored by content providers would be all accessible on IPv6 317 in the hypothetical case of a sudden IPv4 switch-off. Even if this 318 is pure speculation, the numbers above may bring to state that this 319 is likely the case. This would reinforce the common thought that, in 320 quantitative terms, most of content is accessible via IPv6. 322 2.4. IPv4 addresses per capita and IPv6 status 324 The IPv4 addresses per capita ratio measures the quantity of IPv4 325 addresses allocated to a given country divided by the population of 326 that country. It is a theoretical ratio, anyhow it provides an 327 indication of the imbalanced distribution of the IPv4 addresses 328 worldwide. It clearly derives from the allocation of addresses made 329 in the early days of the Internet by the most advanced countries. 331 The sources for measuring the IPv4 addresses per capita ratio are the 332 allocations done by the RIRs and the statistics about the world 333 population. In our case, we take the distribution files of 334 [POTAROO2], which summarize the most useful information. We then 335 compare the obtained ratio against the measured adoption of IPv6. As 336 explained in section 2.2, this is expressed as the number of IPv6 337 capable users over the total Internet population of the considered 338 country. The result is shown in the following table, where some of 339 countries with the highest number of IPv4 allocations are reported. 340 The table is ordered based on the IPv4 addresses per capita ratio. 342 +------------------------+-----------------+-----------------+ 343 |Country | IPv4 per capita| IPv6 deployment| 344 +------------------------+-----------------+-----------------+ 345 |United States of America| 4.89| 47.1%| 346 +------------------------+-----------------+-----------------+ 347 |Sweden | 2.97| 11.8%| 348 +------------------------+-----------------+-----------------+ 349 |Netherlands | 2.93| 35.5%| 350 +------------------------+-----------------+-----------------+ 351 |Switzerland | 2.75| 34.9%| 352 +------------------------+-----------------+-----------------+ 353 |Republic of Korea | 2.19| 17.1%| 354 +------------------------+-----------------+-----------------+ 355 |Australia | 1.91| 28.8%| 356 +------------------------+-----------------+-----------------+ 357 |Canada | 1.85| 32.4%| 358 +------------------------+-----------------+-----------------+ 359 |United Kingdom | 1.65| 33.2%| 360 +------------------------+-----------------+-----------------+ 361 |Belgium | 1.62| 62.0%| 362 +------------------------+-----------------+-----------------+ 363 |Japan | 1.50| 36.7%| 364 +------------------------+-----------------+-----------------+ 365 |Germany | 1.48| 53.0%| 366 +------------------------+-----------------+-----------------+ 367 |France | 1.27| 42.1%| 368 +------------------------+-----------------+-----------------+ 369 |Austria | 1.24| 29.2%| 370 +------------------------+-----------------+-----------------+ 371 |Italy | 0.91| 4.7%| 372 +------------------------+-----------------+-----------------+ 373 |Spain | 0.69| 3.0%| 374 +------------------------+-----------------+-----------------+ 375 |Poland | 0.55| 14.7%| 376 +------------------------+-----------------+-----------------+ 377 |Brazil | 0.41| 38.7%| 378 +------------------------+-----------------+-----------------+ 379 |Russian Federation | 0.31| 9.7%| 380 +------------------------+-----------------+-----------------+ 381 |China (*) | 0.24| 60.1%| 382 +------------------------+-----------------+-----------------+ 383 |India | 0.03| 76.9%| 384 +------------------------+-----------------+-----------------+ 386 Figure 3: IPv4 per capita and IPv6 deployment 388 (*) The IPv6 deployment information in China is derived from 389 [CN-IPv6]. 391 It is clear that a direct correlation between the two measures is not 392 always straightforward. One may expect that a low IPv4 addresses per 393 capita ratio should correspond to high IPv6 deployment. This is true 394 for India and, relatively, for Brazil, but other countries such as 395 the Russian Federation, Poland, Spain and Italy are still quite 396 dependent on IPv4. 398 The opposite effect should apply for countries with a high value for 399 same ratio. While this is true for Sweden and the Republic of Korea, 400 which have a relatively low IPv6 deployment, for other countries at 401 the top of the list this does not apply. The USA, Germany, France, 402 Belgium all have a good level of IPv6 deployment, while other 403 countries such the Netherlands, Switzerland, the UK, Canada, 404 Australia, Japan are just following with around one third of their 405 Internet population using IPv6. 407 The reasons for having high or medium-to-high IPv6 deployment may be 408 quite different from country to country. For example, in West 409 European countries such as Belgium, France, Germany the outcome 410 depends on a mix of government and regulation activities which 411 incentivized the adoption of IPv6 in the recent years. In some cases 412 it has been industry self-regulation which created the traction for a 413 bigger IPv6 adoption. 415 The IPv6 adoption in USA, China and India comes from different needs. 416 Mobile operators have anticipated the usage of IPv6 to cope with the 417 lack of available addresses (India) and to support new services and 418 applications. In addition to that, all National governments have 419 issues specific policies to bring IPv6 deployment forward. 421 3. A Survey on IPv6 Deployments 423 Right after the count of the IPv6 users, it is fundamental to 424 understand the status of IPv6 in terms of concrete adoption in 425 operational networks. This section deals with the status of IPv6 426 among carriers, service and content providers, enterprises and 427 research institutions. 429 3.1. IPv6 Allocations and Networks 431 RIRs are responsible for allocating IPv6 address blocks to ISPs, LIRs 432 (Local Internet Registries) as well as enterprises or other 433 organizations. An ISP/LIR will use the allocated block to assign 434 addresses to their end users. For example, a mobile carrier will 435 assign one or several /64 prefixes to the User Equipment (UE). 437 Several analytics are available from the RIRs. Here we are 438 interested to those relevant to IPv6. The next table shows the 439 amount of individual allocations, per RIR, in the time period 440 2017-2021 [APNIC2]. 442 +---------+-------+-------+-------+-------+-------+---------+------+ 443 | Registry| Dec | Dec | Dec | Dec | Dec |Cumulated| CAGR | 444 | | 2017 | 2018 | 2019 | 2020 | 2021 | | | 445 +---------+-------+-------+-------+-------+-------+---------+------+ 446 | AFRINIC | 112 | 110 | 115 | 109 | 136 | 582 | 51% | 447 | APNIC | 1,369 | 1,474 | 1,484 | 1,498 | 1,392 | 7,217 | 52% | 448 | ARIN | 684 | 659 | 605 | 644 | 671 | 3,263 | 48% | 449 | LACNIC | 1,549 | 1,448 | 1,614 | 1,801 | 730 | 7,142 | 47% | 450 | RIPE NCC| 2,051 | 2,620 | 3,104 | 1,403 | 2,542 | 11,720 | 55% | 451 | | | | | | | | | 452 | Total | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 51% | 453 +---------+-------+-------+-------+-------+-------+---------+------+ 455 Figure 4: IPv6 allocations worldwide 457 Overall, the trend is positive, witnessing the vivacity around IPv6. 458 The decline of IPv6 allocations in 2020 (remarkable for RIPE NCC) and 459 2021 (in LACNIC), could be explained with the COVID-19 measures that 460 may have affected the whole industry. 462 [APNIC2] also compares the number of allocations for both address 463 families. Differently from what happened in 2020, when CAGR was 464 higher for the IPv6 allocations, in 2021 IPv4 stayed a little ahead 465 (53.6% versus 50.9%). 467 +--------+-------+-------+-------+-------+-------+----------+------+ 468 | Address| Dec | Dec | Dec | Dec | Dec | Cumulated| CAGR | 469 | family | 2017 | 2018 | 2019 | 2020 | 2021 | | | 470 +--------+-------+-------+-------+-------+-------+----------+------+ 471 | IPv6 | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 50.9%| 472 | | | | | | | | | 473 | IPv4 | 8,091 | 9,707 |13,112 | 6,263 | 7,829 | 45,002 | 53.6%| 474 | | | | | | | | | 475 +--------+-------+-------+-------+-------+-------+----------+------+ 477 Figure 5: Allocations per address family 479 As noted, the pandemic may have influenced the ICT industry including 480 the dynamic of the address allocations. The number of IPv4 481 allocations in 2021 includes many allocations of small address ranges 482 (e.g. /24) [APNIC2]. On the contrary, a single IPv6 allocation is 483 large enough to cope with the need of an operators for many years. 484 After an operator receives an IPv6 /30 or /32 allocation it is 485 unlikely that a new request of addresses is repeated in the short 486 term. Hence the two CAGR values in the table should not be compared 487 directly as the weight of the allocations is different. 489 The next table is based on [APNIC3], [APNIC4] and shows the 490 percentage of Autonomous System (AS) numbers supporting IPv6 compared 491 to the total ASes worldwide. The number of IPv6-capable ASes 492 increased from 24.3% in January 2018 to 38.7% in January 2022. This 493 equals to 18% CAGR for IPv6-enabled networks, highlighting how IPv6 494 is growing faster than IPv4, since the CAGR value for the total of 495 IPv6 and IPv4 networks grew of just 5%. 497 +------------+-------+-------+-------+-------+-------+------+ 498 | Advertised | Jan | Jan | Jan | Jan | Jan | CAGR | 499 | ASN | 2018 | 2019 | 2020 | 2021 | 2022 | | 500 +------------+-------+-------+-------+-------+-------+------+ 501 |IPv6-capable| 14,500| 16,470| 18,650| 21,400| 28,140| 18% | 502 | | | | | | | | 503 | Total ASN | 59,700| 63,100| 66,800| 70,400| 72,800| 5% | 504 | | | | | | | | 505 | Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | | 506 +------------+-------+-------+-------+-------+-------+------+ 508 Figure 6: Percentage of IPv6-capable ASes 510 The tables above provide an aggregated view of the allocations 511 dynamic. Apart from the recent times influenced by the pandemic, the 512 general trend related to IPv6 adoption is positive. What the 513 aggregated view does not tell us is the split between the different 514 types of organizations. The next sections of this chapter will zoom 515 into each specific area to highlight the relative status. 517 3.2. IPv6 among Network Operators 519 Only a few public references describing the status of IPv6 in 520 specific networks are available. An example is the case of Reliance 521 Jio [RlncJ]. To understand the degree of adoption of IPv6 in the 522 operators' domain, it is necessary to consult the data provided by 523 those organizations that constantly track the usage of IPv6. Among 524 the others, we have the Internet Society that constantly monitors the 525 volume of IPv6 traffic for the networks that joined the 526 WorldIPv6Launch initiative [WIPv6L] and Akamai [Akm-stats] that 527 collects statistics both at a country level and at the single 528 operator's network measuring the number of hits to their content 529 delivery platform. In addition to them, the RIRs also provide 530 detailed information about the prefixes allocated and the ASes 531 associated to each operator. Overall, the vast majority of the 532 operators worldwide have enabled IPv6 and provide IPv6-based services 533 even if the degree of adoption varies quite greatly based on local 534 market demand, regulatory actions, and political decisions (e.g. 535 [RIPE3] to look at the relative differences across the European 536 market). 538 As it was proposed at the time of [RFC6036], also in the case of this 539 document a survey was submitted to a group of service providers in 540 Europe (see Appendix A for the complete poll), to understand the 541 details about their plans about IPv6 and their technical preferences 542 towards its adoption. Such poll does not pretend to give an 543 exhaustive view on the IPv6 status, but to integrate the available 544 data with some insights that may be relevant to the discussion. 546 The poll reveals that the majority of the operators interviewed has 547 plans concerning IPv6 (79%). Of them, 60% has already ongoing 548 activities, while 33% is expected to start activities in a 12-months 549 time-frame. The transition to IPv6 involves all business segments: 550 mobile (63%), fixed (63%), and enterprises (50%). 552 The reasons to move to IPv6 vary. The majority of the operators that 553 do have a plan for IPv6 perceives issues related to IPv4 depletion 554 and prefer to avoid the use of private addressing schemes (48%) to 555 save the NAT costs. Global IPv4 address depletion and the run out of 556 private address space recommended in [RFC1918] are reported as the 557 important drivers for IPv6 deployment. In some cases, the adoption 558 of IPv6 is driven by innovation strategy (as the enabler of new 559 services, 13%) or is introduced because of 5G/IoT, which play the 560 role of business incentive to IPv6 (20%). In a few cases, 561 respondents highlight the availability of National Regulatory 562 policies requiring to enable IPv6 together with the launch of 5G 563 (13%). Enterprise customers demand is also a reason to introduce 564 IPv6 (13%). 566 From a technical preference standpoint, Dual-Stack is the most 567 adopted solution, both in wireline (59%) and in cellular networks 568 (39%). In wireline, the second most adopted mechanism is DS-Lite 569 (19%), while in cellular networks the second preference goes to 570 464XLAT (21%). 572 In the majority of the cases, the interviewed operators do not see 573 any need to transition their network as a whole. They consider to 574 touch or to replace only what it is needed. CE (47%), BNG (20%), CGN 575 devices (33%), mobile core (27%) are the components that may be 576 affected by transition or replacement. It is interesting to see that 577 most of the network operators have no major plans to transition the 578 transport network (metro and backbone) soon, since they do not see 579 business reasons. It seems that there is no pressure to move to 580 native IPv6-only forwarding in the short term, anyway the future 581 benefit of IPv6 may justify the shift in the long term. 583 More details about the answers received can be found in Appendix A. 585 3.3. IPv6 among Enterprises 587 As described in [RFC7381], enterprises face different challenges than 588 operators. Some publicly available statistics also show that the 589 deployment of IPv6 lags behind other sectors. 591 [NST_1] provides estimations on deployment status of IPv6 for more 592 than 1000 second level domains such as example.com, example.net or 593 example.org belonging to organizations in the United States. The 594 measurement encompasses many industries, including 595 telecommunications, so that the term "enterprises" is a bit loose to 596 this extent. In any case, it provides a first indication of IPv6 597 adoption in several US industry sectors. The analysis tries to infer 598 whether IPv6 is supported by looking from "outside" a company's 599 network. It takes into consideration the support of IPv6 to external 600 services such as Domain Name System (DNS), mail and website. 601 Overall, for around the 66.85% of the considered domains there is an 602 active DNS Name Server (NS) v6 record but only 6.3% have IPv6 support 603 for their websites and 21.2% have IPv6-based mail services as of 604 January 2022. 606 [BGR_1] have similar data for China. The measurement considers 478 607 second or third level domains such as example.cn or example.com.cn. 608 74% have IPv6 support for DNS, 0% have IPv6-based mail services, 20% 609 have IPv6-based websites. 611 [CNLABS_1] provides the status in India. Of the 104 measured 612 domains, 51.9% are IPv6-enablesd, 15.4% have IPv6 support in DNS, 613 16.3% have IPv6 support for the mail service. 615 A poll submitted to a group of large enterprises in North America 616 (see Appendix B) show that the operational issues are likely to be 617 more critical than for operators. 619 Looking at current implementations, almost one third has dual-stacked 620 networks, while 20% declares that portions of their networks are 621 IPv6-only. 35% of the enterprises are stuck at the training phase. 622 In no cases the network is fully IPv6-based. 624 Speaking of training, the most critical needs are in the field of 625 IPv6 security and IPv6 troubleshooting (both highlighted by the two 626 thirds of respondents), followed by IPv6 fundamentals (57.41%). 628 Coming to implementation, the three areas of concern are IPv6 629 security (31.48%), training (27.78%), application conversion 630 (25.93%). Interestingly, 33.33% of respondents think that all three 631 areas are all simultaneously of concern. 633 The full poll is reported in Appendix B. 635 3.3.1. Government and Universities 637 This section focuses specifically on governments and academia, due to 638 the relevance of both domains in the process of IPv6 adoption. The 639 already mentioned organizations that estimates the IPv6 status 640 provide a deep focus on IPv6 in the network domains associated with 641 governmental and education-related agencies. 643 As far as governmental institutions or agencies are concerned, 644 [NST_2] provides analytics on the degree of support that IPv6 gives 645 to DSN, mail and websites across 1283 second level domains associated 646 with US Federal agencies. These domains are in the form of 647 example.gov or example.fed. The script used by [NST_2] have also 648 been employed to measure the same analytics in other countries. For 649 China [BGR_2] looks at 52 third level domains such as example.gov.cn. 650 [CNLABS_2] provides statistics for 618 Indian government-related 651 domains (ranging from the second to the fifth level). [IPv6Forum] 652 analyzes 19 governmental domains connected to either the European 653 Union or its member States. 655 +--------------+----------+---------+---------+---------+ 656 |Country | Domains | DNS | Mail | Website | 657 | | analyzed | | | | 658 +--------------+----------+---------+---------+---------+ 659 |China | 52 | 0.0% | 0.0% | 98.1% | 660 | | | | | | 661 +--------------+----------+---------+---------+---------+ 662 |European | 19 | 47.4% | 0.0% | 21.1% | 663 |Union (*) | | | | | 664 +--------------+----------+---------+---------+---------+ 665 |India | 618 | 7.6% | 6.5% | 7.1% | 666 | | | | | | 667 +--------------+----------+---------+---------+---------+ 668 |United States | 1283 | 87.1% | 14.0% | 51.7% | 669 |of America | | | | | 670 +--------------+----------+---------+---------+---------+ 672 Figure 7: IPv6 support for external-facing services across 673 governmental institutions 675 (*) Both EU and European governments domains are considered. 677 Looking at the USA, the support given by IPv6 to the services is 678 higher than that in the enterprise sector discussed in the previous 679 section. This is likely to depend on the directions set by [US-CIO] 680 through the mandate to transition to IPv6. In the case of India, the 681 degree of support seems still quite low. This is also true for 682 China, with the notable exception of the percentage of IPv6-enabled 683 government-related organizations websites. 685 Similar statistics are also available for higher education. [NST_3] 686 measures the data coming from 346 second level domains of 687 universities in the US, such as example.edu. [BGR_3] looks at 111 688 Chinese education-related domains such as example.edu.cn. [CNLABS_3] 689 analyzes 100 domains in India (mostly third level), while [IPv6Forum] 690 lists 118 universities in the European Union (second level). 692 +--------------+----------+---------+---------+---------+ 693 |Country | Domains | DNS | Mail | Website | 694 | | analyzed | | | | 695 +--------------+----------+---------+---------+---------+ 696 |China | 111 | 36.9% | 0.0% | 77.5% | 697 | | | | | | 698 +--------------+----------+---------+---------+---------+ 699 |European | 118 | 83.9% | 43.2% | 35.6% | 700 |Union | | | | | 701 +--------------+----------+---------+---------+---------+ 702 |India | 100 | 31.0% | 54.0% | 5.0% | 703 | | | | | | 704 +--------------+----------+---------+---------+---------+ 705 |United States | 346 | 49.1% | 19.4% | 21.7% | 706 |of America | | | | | 707 +--------------+----------+---------+---------+---------+ 709 Figure 8: IPv6 support for external-facing services across 710 universities 712 Overall, the universities have wider support of IPv6-based services 713 if compared with the other sectors. Apart from a couple of 714 exceptions (e.g. the support of IPv6 mail in China and IPv6 web sites 715 in India), the numbers shown in the table above indicate a good 716 support of IPv6. 718 3.4. Observations on Industrial Internet 720 There are potential advantages for implementing IPv6 for IIoT 721 (Industrial Internet of Things) applications, in particular the large 722 IPv6 address space, the automatic IPv6 configuration and resource 723 discovery. 725 However, there are still many obstacles that prevent its pervasive 726 use. The key problems identified are the incomplete or immature tool 727 support, the dependency on manual configuration and the poor 728 knowledge of the IPv6 protocols among insiders. To advance and ease 729 the use of IPv6 for smart manufacturing systems and IIoT applications 730 in general, a generic approach to remove these pain points is 731 therefore, highly desirable. 733 3.5. Observations on Content and Cloud Service Providers 735 Both the number of addresses required to connect all of the virtual 736 and physical elements in a Data Center and the necessity to overcome 737 the limitation posed by [RFC1918] have been the drivers to adopt IPv6 738 in several CSP networks. 740 Several public references, as reported in Section 7.1.3, discuss how 741 most of the major players find themselves at different stages in the 742 transition to IPv6-only in their Data Center (DC) infrastructure. In 743 some cases, the transition already happened and the DC infrastructure 744 of these hyperscalers is completely based on IPv6. This can be 745 considered a good sign because the end-to-end connectivity between a 746 client (e.g. an application on a smartphone) and a server (a Virtual 747 Machine in a DC) may be based on IPv6. 749 3.6. Application Transition 751 The preliminary step to take full benefit of the IPv6 capabilities is 752 to write or adapt the application software for use in IPv6 networks 753 (see, as an example, [ARIN-SW]). 755 It is worth mentioning Happy Eyeballs [RFC6555] and Happy Eyeballs 2 756 [RFC8305] as a major aspect of application transition and porting to 757 IPv6. All host and network router OS's by default prefer IPv6 over 758 IPv4. 760 Happy Eyeballs plays an important role and is extremely helpful when 761 applications are migrated from IPv4 to IPv6 having a single DNS name 762 with both A and AAAA record. In this way all applications can 763 migrate to IPv6 as IPv6 is preferred over IPv4 and so all IPv6 dual- 764 stacked hosts can communicate using same URL to the server via IPv6 765 and all IPv4 hosts can as well use the same URL to communicate via 766 IPv4. Eventually when all host endpoints are dual-stacked, the 767 application servers can migrate from dual stack to IPv6-only. For 768 external connectivity to the internet, web proxy can be used 769 providing 6to6 or 4to6 proxy to the internet. This allows 770 application servers on the internal network to change to IPv6-only 771 once all host endpoints are all dual-stacked. 773 At the current stage, the full support of IPv6 is not yet complete 774 [Wikipedia], as issues remains in particular for applications known 775 not to work properly behind NAT64. 777 4. Towards an IPv6 Overlay Service Design 779 This section reports the most deployed approaches for the IPv6 780 transition in MBB, FBB and enterprise. 782 Two approaches are usually considered [ETSI-IP6-WhitePaper], namely: 783 (1) IPv6 introduction, and (2) IPv6-only. Depending on their 784 specific plans and requirements, operators may consider either of the 785 two or both. The usual approach sees them as two sequential stages, 786 i.e. deal with IPv6 introduction first and then move to IPv6-only. 787 In some cases, operators may instead jump directly to IPv6-only to 788 avoid the operational burden of a transient phase. IPv6 introduction 789 aims at delivering the service in a controlled manner, where the 790 traffic volume of IPv6-based services is minimal. When the service 791 conditions change, e.g. when the traffic grows beyond a certain 792 threshold, then the move to IPv6-only may occur. In this latter 793 case, the service is delivered solely on IPv6, including the traffic 794 originated from IPv4-based nodes. For this reason, the IPv6-only 795 stage is also called IPv4aaS (IPv4 as a Service). 797 The consolidated approach foresees to enable IPv6 in the network 798 (sometimes referred to as the underlay) and move progressively to the 799 service layer. Recently, the attention has shifted to enabling IPv6 800 at the service layer (the overlay) leaving the transition of the 801 network to IPv6 at a later stage. This relates to the increased 802 adoption of the transition mechanisms described in this section. 804 4.1. IPv6 introduction 806 In order to enable the deployment of an IPv6 service over an underlay 807 IPv4 architecture, there are two possible approaches: 809 o Enabling Dual-Stack [RFC4213] at the Customer Edge router (CE) 811 o IPv6-in-IPv4 tunneling, e.g. with IPv6 Rapid Deployment (6rd) or 812 Generic Routing Encapsulation (GRE). 814 Based on information provided by operators with the answers to the 815 poll (Appendix A), Dual-Stack appears to be currently the most widely 816 deployed IPv6 solution, for MBB, FBB and enterprises, accounting for 817 about 50% of all IPv6 deployments (see both Appendix A and the 818 statistics reported in [ETSI-IP6-WhitePaper]). Therefore, for 819 operators that are willing to introduce IPv6 the most common approach 820 is to apply the Dual-Stack transition solution, which appears more 821 robust, and easier to troubleshoot and support. 823 With Dual-Stack, IPv6 can be introduced together with other network 824 upgrades and many parts of network management and IT systems can 825 still work in IPv4. This avoids major upgrade of such systems to 826 support IPv6, which is possibly the most difficult task in the IPv6 827 transition. In other words, the cost and effort on the network 828 management and IT system upgrade are moderate. The benefits are to 829 start to accommodate future services and save the NAT costs. 831 The CE has both IPv4 and IPv6 addresses at the WAN side and uses an 832 IPv6 connection to the operator gateway, e.g. Broadband Network 833 Gateway (BNG) or Packet Gateway (PGW) / User Plane Function (UPF). 834 However, the hosts and content servers can still be IPv4 and/or IPv6. 836 For example, NAT64 can enable IPv6-only hosts to access IPv4 servers. 837 The backbone network underlay can also be IPv4 or IPv6. 839 Although the Dual-Stack IPv6 transition provides advantages in the 840 IPv6 introductory stage, it does have few disadvantages in the long 841 run, like the duplication of the network resources and states, as 842 well as other limitations for network operation. It also means 843 requiring more IPv4 addresses, so an increase in both Capital 844 Expenses (CAPEX) and Operating Expenses (OPEX). Even if private 845 addresses are being used via Carrier-Grade NAT (CGN), there is extra 846 investment in the CGN devices, logs storage and helpdesk to track 847 CGN-related issues. 849 For this reason, when IPv4 traffic is vanishingly small or when IPv6 850 usage increases to more than a given percentage, which highly depends 851 on each network, it could be advantageous to switch to the IPv6-only 852 stage with IPv4aaS. It is difficult to establish the criterion for 853 switching (e.g. to properly identify the upper bound of the IPv4 854 decrease or the lower bound of the IPv6 increase). In addition to 855 the technical factors, the switch to IPv6-only may also include a 856 loss of customers. Based on operational experience and some 857 measurements of network operators participating in World IPv6 Launch 858 [WIPv6L] where, at June 2021, out of 346 entries 108 exceed 50% of 859 IPv6 traffic volume (31.2%), 72 overcome 60% (20.8%), while 37 go 860 beyond 75% (10.7%), the consensus to move to IPv6-only is when IPv6 861 traffic volume is between 50% and 60%, which easily happens from 862 since the moment IPv6 is deployed in networks where residential 863 customers traffic is higher than business traffic (because major 864 content providers, as already explained, already use IPv6). 866 4.2. IPv6-only Service Delivery 868 The second stage, named IPv6-only and including IPv4 support via 869 IPv4aaS, can be a complex decision that depends on several factors, 870 such as economic aspects, policy and government regulation. 872 [I-D.ietf-v6ops-transition-comparison] discusses and compares the 873 technical merits of the most common transition solutions for 874 IPv6-only service delivery, 464XLAT [RFC6877], DS-lite [RFC6333], 875 Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T 876 [RFC7599], but without providing an explicit recommendation. As the 877 poll highlights Appendix A, the most widely deployed IPv6 transition 878 solution in the MBB domain is 464XLAT while in the FBB space is DS- 879 Lite. 881 Both of them are IPv6-only solutions providing IPv4aaS. IPv4aaS 882 offers Dual-Stack service to users and allows an operator to run 883 IPv6-only in the network (typically, the access network). It needs 884 to be observed that an increasing number of operators, also in the 885 FBB area, tend to prefer 464XLAT over the other transition 886 mechanisms, especially in the case of MBB/FBB convergence. 888 While it cannot be always the case, IPv6-only transition technologies 889 such as 464XLAT require much less IPv4 public addresses 890 [I-D.ietf-v6ops-transition-comparison], because they make a more 891 efficient usage without restricting the number of ports per 892 subscriber. This contributes to reduce troubleshooting costs and to 893 remove some operational issues related to permanent black-listing of 894 IPv4 address blocks when used via CGN in some services. For example, 895 Sony Play Station Network or OpenDNS imply a higher rotation of IPv4 896 prefixes in CGN, until they get totally blocked, which means extra 897 CAPEX in new IPv4 transfers. 899 IPv6-only may be facilitated by the natural upgrade or replacement of 900 CEs because of newer technologies (tripe-play, higher bandwidth WAN 901 links, better WiFi technologies, etc.). The CAPEX and OPEX of other 902 parts of the network may be lowered (for example CGN and associated 903 logs) due to the operational simplification of the network. 905 In terms of addressing needs, for specific applications such as in 906 the case of large mobile operators or large DCs, even the full 907 private address space [RFC1918] is not large enough. Also, Dual- 908 Stack likely leads to duplication of network resources and operations 909 to support both IPv6 and IPv4, which increases the amount of state 910 information in the network. For this reason, in some scenarios (e.g. 911 MBB or DCs) IPv6-only stage could be more efficient from the start 912 since the IPv6 introduction phase. 914 So, in general, when the Dual-Stack disadvantages outweigh the 915 IPv6-only complexity, it makes sense to apply the transition to 916 IPv6-only. Some network operators already started this process, 917 while others are still waiting. 919 5. IPv6-only Underlay Network Deployment 921 IPv6-only alone can be misinterpreted as not supporting IPv4. It can 922 be referred to different portions of the network, to the underlay 923 network, to the overlay network (services), as also mentioned in 924 [I-D.palet-v6ops-ipv6-only]. 926 As opposed to the IPv6-only service delivery (with IPv4aaS) discussed 927 in the previous sections, the IPv6-only network means that the whole 928 network (both operator underlay transport and customer traffic 929 overlay) uses IPv6 as the network protocol for all traffic delivery, 930 but some operators may do IPv6-only at the access network only. This 931 can be accomplished on a case-by-case basis. 933 As a matter of fact, IPv4 reachability must be provided for a long 934 time to come over IPv6 for IPv6-only endpoints. Most operators are 935 leveraging CGN to extend the life of IPv4 instead of going with 936 IPv4aaS. 938 When operators (both enterprises and service providers) start to 939 migrate from an IPv4 core, MPLS LDPv4 core, SR-MPLSv4 core to 940 introduce IPv6 in the underlay, they do not necessarily need to dual 941 stack the underlay to maintain both IPv4 and IPv6 address families in 942 the transport layer. Forwarding plane complexity on the Provider (P) 943 core should be kept simple as a single protocol only core. An 944 example could be Softwire Mesh Framework [RFC5565] which is based on 945 a standard single protocol IPv4-Only or IPv6-Only for core where 946 where IPv4 packets can be tunneled over 4to6 MPLS software over an 947 IPv6-Only core. 949 Hence, when operators decide to migrate to an IPv6 underlay, the 950 Provider (P) core should be IPv4-only or IPv6-only while Dual-Stack 951 is not the best choice. The underlay could be IPv6-only and allows 952 IPv4 packets to be tunneled using VPN over an IPv6-only core and 953 leveraging Advertising IPv4 Network Layer Routing Information (NLRI) 954 with an IPv6 Next Hop [RFC8950]. Indeed, [RFC8950] specifies the 955 extensions necessary to allow advertising IPv4 NLRI, Virtual Private 956 Network Unicast (VPN-IPv4) NLRI, Multicast Virtual Private Network 957 (MVPN-IPv4) NLRI with a Next Hop address that belongs to the IPv6 958 protocol. And also, [I-D.ietf-bess-ipv6-only-pe-design] allows dual- 959 stacked functionality without having to dual-stack the interface and 960 without any tunneling mechanisms, resulting in OPEX savings for the 961 elimination of IPv4 addressing and BGP peering. This also enables 962 the quick deployment of IPv6 in a core or Data Center network without 963 provisioning IPv6 links with global unicast address, that can be a 964 long process in very large networks. 966 Regarding the IPv6 underlay network deployment for Access Network 967 (AN) Metro Edge BNG to NG edge, the current trend is to keep MPLS 968 Data Plane IPv4-only and run IPv4/IPv6 Dual Stack to the Access 969 Network (AN) to Customer RG edge node. 971 As operators do the transition in the future to IPv6 metro and 972 backbone network, e.g. Segment Routing over IPv6 data plane (SRv6), 973 they are able to start the elimination of IPv4 from the underlay 974 transport network while continuing to provide overlay IPv4 services. 975 Basically, as also showed by the poll among network operators, from a 976 network architecture perspective, it is not recommended to apply 977 Dual-Stack to the transport network per reasons mentioned above about 978 the forwarding plane complexities. 980 If we consider IPv6-only to mean both operator underlay network and 981 customer VPN traffic, that will take more time. If we look at the 982 long term evolution, IPv6 can bring other advantages like introducing 983 advanced protocols developed only on IPv6. 985 6. IPv6 Benefits 987 A comparison of the technical and operational characteristics of IPv4 988 and IPv6 should quite easily highlight the merits of the latter. On 989 the other hand, the long path IPv6 is still taking to become the 990 dominant network protocol shows that those merits are either not 991 clear enough or not sufficient against other market, managerial or 992 financial reasons. The scope of this section is to list what are 993 generally considered the benefits of IPv6, following discussions at 994 the IETF and other communities. The list below does not mean to be 995 exhaustive; it tries to collect some facts about the use of IPv6. 997 1. Address space advantage: this is probably the most well-known 998 characteristic of IPv6. The address space is orders of magnitude 999 wider than IPv4's. With the emergence of new digital 1000 technologies, such as 5G, IoT and Cloud, new use cases have come 1001 into being, posing new requirements to IP networks. Over time, 1002 numerous technical and economic stop-gap measures have been 1003 developed in an attempt to extend the lifetime of IPv4, but all 1004 of these measures add cost and complexity to network 1005 infrastructure and raise significant barriers to innovation. It 1006 is widely recognized that full transition to IPv6 is the only 1007 viable option to ensure future growth and innovation to Internet 1008 technology and services. Other sections of this paper have 1009 already mentioned the efforts of both network and content 1010 providers to evolve their internal infrastructures to be 1011 IPv6-only to solve the issue of a constrained address space. 1012 From an operational perspective, the wide IPv6 address space 1013 avoids the typical renumbering activities that take place either 1014 when two networks merge or when an infrastructure needs to span 1015 across multiple geographic regions. 1017 2. Government and regulation incentives: the shift to IPv6 is 1018 beneficial to create the market conditions to foster innovation 1019 and competition. This is, as an example, one of conclusions 1020 highlighted in [ARCEP]: "This dearth of IPv4 addresses means that 1021 the internet will not stop working but it will stop growing. 1022 This shortage is also resulting in a significant increase in the 1023 price being charged for these addresses in the secondary market, 1024 which creates a real barrier to entry for new entrants to the 1025 internet. It has therefore become imperative, for the sake of 1026 competition and innovation, that all internet players switch over 1027 to IPv6". Governments have a huge responsibility in promoting 1028 IPv6 deployment. Some of them are already adopting policies to 1029 encourage IPv6 utilization or enforce increased security on IPv4. 1030 So, even without funding the IPv6 transition, governments can 1031 recommend to add IPv6 compatibility for every connectivity, 1032 service or products bid. This will encourage the network 1033 operators and vendors who do not want to miss out on government 1034 related bids to evolve their infrastructures to be IPv6 capable. 1035 Any public incentives for technical evolution will be bonded to 1036 IPv6 capabilities of the technology itself. In this regard, in 1037 the United States, the Office of Management and Budget is calling 1038 for an implementation plan to have 80% of the IP-enabled 1039 resources on Federal networks be IPv6-only by 2025. If resources 1040 cannot be converted, then the Federal agency is required to have 1041 a plan to retire them. The Call for Comment is at [US-FR] and 1042 [US-CIO]. In China, the government launched IPv6 action plan in 1043 2017, which requires that networks, applications and terminal 1044 devices will fully support the adoption of IPv6 by the end of 1045 2025 [CN]. 1047 3. New functionality and standard: it has been already mentioned the 1048 IAB statement [IAB], which asks the IETF, as well as other 1049 Standards Developing Organizations (SDOs), to ensure that their 1050 standards do not assume IPv4. The IAB expects that the IETF will 1051 stop requiring IPv4 compatibility in new or extended protocols. 1052 Future IETF protocol work will then optimize for and depend on 1053 IPv6. [RFC6540] recommends that all networking standards assume 1054 the use of IPv6 and be written so they do not require IPv4. In 1055 addition, every RIR worldwide strongly recommends immediate IPv6 1056 adoption. This is an incentive to network equipment vendors to 1057 endorse IPv6 and view it as the standards-based solution to the 1058 IPv4 address shortage. The introduction of new functionality is 1059 one of the technical benefit of IPv6 due to the flexible 1060 structure of the packet header. The IETF is currently active in 1061 defining operational recommendations for the usage of Extension 1062 Headers and Options left open by the base standards. 1064 4. Future Proof: IPv6 was designed from scratch to be future-proof, 1065 despite some incompatibilities with IPv4. For example, 1066 mechanisms to translate back and forth from IPv4 to IPv6 are 1067 already in place in mobile networks worldwide. This allows to 1068 introduce newer generations of mobile services, as in the case of 1069 5G applications. While exceptions may exist, IPv6 foresees the 1070 absence of NAT along the network path. This allows an operator 1071 to remove the technical constraints of handling NAT and the 1072 relevant cost. A side effect to that, this approach brings the 1073 connectivity model back to the end-to-end client/server paradigm. 1074 Worth noting, the vast majority of terminals is IPv6-capable. 1075 Content is also greatly available on IPv6. The service 1076 connectivity, from terminal to content, in particular in mobile 1077 networks, is reality. 1079 7. Common IPv6 Challenges 1081 There are some areas of improvement, that are often mentioned in the 1082 literature and during the discussions on IPv6 deployment. This 1083 section highlights these common IPv6 challenges in order to encourage 1084 more investigations on these aspects. 1086 7.1. Transition Choices 1088 From an architectural perspective, a service provider or an 1089 enterprise may perceive quite a complex task the transition to IPv6, 1090 due to the many technical alternatives available and the changes 1091 required in management and operations. Moreover, the choice of the 1092 method to support the transition may depend on factors specific to 1093 the operator's or the enterprise's context, such as the IPv6 network 1094 design that fits the service requirements, the deployment strategy, 1095 and the service and network operations. 1097 This section briefly highlights the approaches that service providers 1098 and enterprises may take and the related challenges. 1100 7.1.1. Service Providers 1102 For fixed operators, the massive software upgrade of CEs to support 1103 Dual-Stack already started in most of service provider networks. On 1104 average, looking at the global statistics, the IPv6 traffic 1105 percentage is currently between 30% and 40% of IPv6. As highlighted 1106 earlier, all major content providers have already implemented Dual- 1107 Stack access to their services and most of them have implemented 1108 IPv6-only in their Data Centers. This aspect could affect the 1109 decision on the IPv6 adoption for an operator, but there are also 1110 other aspects like the current IPv4 addressing status, CE costs, CGN 1111 costs and so on. 1113 Fixed Operators with a Dual-Stack architecture, can start defining 1114 and apply a new strategy when reaching the limit in terms of 1115 number of IPv4 addresses available. This can be done through CGN 1116 or with an IPv6-only approach (IPv4aaS). 1118 On the one hand, most of the fixed operators remain attached to a 1119 Dual-Stack architecture and have already employed CGN. In this 1120 case it is likely that CGN boosts their ability to supply IPv4 1121 connectivity to CEs for more years to come. On the other hand, 1122 only few fixed operators have chosen to move to IPv6-only. 1124 For mobile operators, the situation is quite different since, in some 1125 cases, mobile operators are already stretching their IPv4 address 1126 space since CGN translation levels have been reached and no more IPv4 1127 public pool addresses are available. 1129 Some mobile operators choose to implement Dual-Stack as first and 1130 immediate mitigation solution. 1132 Other mobile operators prefer to move to IPv6-only solution (e.g. 1133 464XLAT) since Dual-Stack only mitigates and does not solve 1134 completely the IPv4 address scarcity issue. 1136 For both fixed and mobile operators the approach for the transition 1137 is not unique and this bring different challenges in relation to the 1138 network architecture and related costs. So each operator needs to do 1139 own evaluations for the transition based on the specific situation. 1141 7.1.2. Enterprises and Industrial Internet 1143 At present, the key driver for enterprises relies on upstream service 1144 providers. If they run out of IPv4 addresses, it is likely that they 1145 start providing native IPv6 and non-native IPv4. So for other 1146 networks trying to reach enterprise networks, the IPv6 experience 1147 could be better than the transitional IPv4 if the enterprise deploys 1148 IPv6 in its public-facing services. IPv6 also shows its advantages 1149 in the case of acquisition, indeed when an enterprise merges two 1150 networks which use IPv4 private addresses, the address space of the 1151 two networks may overlap and this makes the merge difficult. Since 1152 several governments are introducing IPv6 policy, all the enterprises 1153 providing consulting service to governments are also required to 1154 support IPv6 and to show their technical expertise in the IPv6 arena. 1156 Enterprises are shielded from IPv4 address depletion issues due to 1157 Enterprises predominantly using Proxy and Non internet routable 1158 private [RFC1918], thus do not have the business requirement or 1159 technical justification to migrate to IPv6. Enterprises need to find 1160 a business case and a strong motivation for IPv6 transition to 1161 justify additional CAPEX and OPEX. Also, since ICT is not the core 1162 business for most of the enterprises, ICT budget is often constrained 1163 and cannot expand considerably. However, there are examples of big 1164 enterprises that are considering IPv6 to achieve business targets 1165 through a more efficient IPv6 network and to introduce newer services 1166 which require future-proof IPv6 network architectures. 1168 Enterprises worldwide, in particular small and medium-sized, are 1169 quite late to adopt IPv6, especially on internal networks. In most 1170 cases, the enterprise engineers and technicians don't know well how 1171 IPv6 works and the problem of application porting to IPv6 looks quite 1172 difficult, even if technically is not a big issue. As highlighted in 1173 the relevant poll, the technicians may want to get trained but the 1174 management do not see a business need for adoption. This creates an 1175 unfortunate cycle where misinformation about the complexity of the 1176 IPv6 protocol and unreasonable fears about security and manageability 1177 combine with the perceived lack of urgent business needs to prevent 1178 adoption of IPv6. In 2019 and 2020, there has been a concerted 1179 effort by some grass roots non-profits working with ARIN and APNIC to 1180 provide training [ARIN-CG] [ISIF-ASIA-G]. 1182 For enterprises, the challenge is that of "First Mover Disadvantage". 1183 Compared to network operators that may feel the need of a network 1184 evolution towards IPv6, enterprises typically upgrade to new 1185 technologies and architectures, such as IPv6, only if it gains them 1186 revenue, and this is evident, at least in the short term. 1188 As the most promising protocol for network applications, IPv6 is 1189 frequently mentioned in relation to Internet of Things and Industry 1190 4.0. However, its industrial adoption, in particular in smart 1191 manufacturing systems, has been much slower than expected. Indeed, 1192 as for enterprises, it is important to provide an easy way to 1193 familiarize system architects and software developers with the IPv6 1194 protocol. 1196 For Industrial Internet and related IIoT applications, it would be 1197 desirable to be able to implement a truly distributed system without 1198 dependencies to central components. In this regard the distributed 1199 IIoT applications can leverage the configuration-less characteristic 1200 of IPv6. In addition, it could be interesting to have the ability to 1201 use IP based communication and standard application protocols at 1202 every point in the production process and further reduce the use of 1203 specialized communication systems. 1205 7.1.3. Cloud and Data Centers 1207 Most CSPs have adopted IPv6 in their internal infrastructure but are 1208 also active in gathering IPv4 addresses on the transfer market to 1209 serve the current business needs of IPv4 connectivity. As noted in 1210 the previous section, most enterprises do not consider the transition 1211 to IPv6 as a priority. To this extent, the use of IPv4-based network 1212 services by the CSPs will last. Yet, CSPs are struggling to buy IPv4 1213 addresses. 1215 It is interesting to look at how much traffic in a network is going 1216 to Caches and Content Delivery Networks (CDNs). The response is 1217 expected to be an high percentage, at least higher than 50% in most 1218 of the cases. Since all the key Caches and CDNs are IPv6-ready 1219 [Cldflr], [Akm], [Ggl], [Ntflx], [Amzn], [Mcrsft], [Vrzn]. So the 1220 percentage of traffic going to the key Caches/CDNs is a good 1221 approximation of the potential IPv6 traffic in a network. 1223 The challenge for CSPs is related to the support of non-native IPv4 1224 since most CSPs provide native IPv6. If, in the next years, the 1225 scarcity of IPv4 addresses becomes more evident, it is likely that 1226 the cost of buying an IPv4 address by a CSP could be charged to their 1227 customers. 1229 7.1.4. CEs and user devices 1231 It can be noted that most of the user devices (e.g. smartphones) are 1232 already IPv6-enabled since so many years. But there are exceptions, 1233 for example, smartTVs and Set-Top Box (STBs) typically had IPv6 1234 support since few years ago, however not all the economies replace 1235 them at the same pace. 1237 As already mentioned, ISPs who historically provided public IPv4 1238 addresses to their customers generally still have those IPv4 1239 addresses (unless they chose to transfer them). Some have chosen to 1240 put new customers on CGN but without touching existing customers. 1241 Because of the extremely small number of customers who notice that 1242 IPv4 is done via NAT444, it could be less likely to run out of IPv4 1243 addresses and private IPv4 space. But as IPv4-only devices and 1244 traffic reduce, then the need to support private and public IPv4 1245 become less. So the complete support of CEs to IPv6 is also an 1246 important challenge and incentive to overcome Dual-Stack towards 1247 IPv6-only with IPv4aaS [ANSI]. 1249 7.2. Government and Regulators 1251 The global picture shows that the deployment of IPv6 worldwide is not 1252 uniform at all [G_stats], [APNIC1]. Countries where either market 1253 conditions or local regulators have stimulated the adoption of IPv6 1254 show clear sign of growth. 1256 As an example, zooming into the European Union area, countries such 1257 as Belgium, France and Germany are well ahead in terms of IPv6 1258 adoption. The French National Regulator, Arcep, can be considered a 1259 good reference of National support to IPv6. [ARCEP] introduced an 1260 obligation for the operators awarded with a license to use 5G 1261 frequencies (3.4-3.8GHz) in Metropolitan France to be IPv6 1262 compatible. As stated, "the goal is to ensure that services are 1263 interoperable and to remove obstacles to using services that are only 1264 available in IPv6, as the number of devices in use continues to soar, 1265 and because the RIPE NCC has run out of IPv4 addresses". A slow 1266 adoption of IPv6 could prevent new Internet services to widespread or 1267 create a barrier to entry for newcomers to the market. "IPv6 can help 1268 to increase competition in the telecom industry, and help to 1269 industrialize a country for specific vertical sectors". 1271 A renewed industrial policy might be advocated in other countries and 1272 regions to stimulate IPv6 adoption. As an example, in the United 1273 States, the Office of Management and Budget is also calling for IPv6 1274 adoption [US-FR], [US-CIO]. China is another example of govern 1275 supporting a country-wide adoption. 1277 7.3. Network Management and Operations 1279 There are important IPv6 complementary solutions related to 1280 Operations, Administration and Maintenance (OAM) that look not so 1281 complete compared to IPv4. Network Management System (NMS) has a 1282 central role in the modern networks for both network operators and 1283 enterprises and its transition is a fundamental challenge. This is 1284 because some IPv6 products are not field-proven as for IPv4 even if 1285 traditional protocols (e.g. SNMP, RADIUS) already supports IPv6. In 1286 addition, incompatible vendor roadmap for the development of new NMS 1287 features affects the confidence of network operators or enterprises. 1288 For example, YANG is the configuration language for networking but in 1289 the real world the data modeling is still vendor dependent. 1291 An important factor is represented by the need for training the 1292 network operations workforce. Deploying IPv6 requires it as policies 1293 and procedures have to be adjusted in order to successfully plan and 1294 complete an IPv6 transition. Staff has to be aware of the best 1295 practices for managing IPv4 and IPv6 assets. In addition to network 1296 nodes, network management applications and equipment need to be 1297 properly configured and in some cases also replaced. This may 1298 introduce more complexity and costs for the transition. 1300 7.4. Performance 1302 People tend to compare the performance of IPv6 versus IPv4 to argue 1303 or motivate the IPv6 transition. In some cases, IPv6 behaving 1304 "worse" than IPv4 may be used as an argument for avoiding the full 1305 adoption of IPv6. However, there are some aspects where IPv6 is 1306 filling the gap to IPv4. This position is supported when looking at 1307 available analytics on two critical parameters: packet loss and 1308 latency. These parameters have been constantly monitored over time, 1309 but only a few extensive researches and measurement campaigns are 1310 currently providing up-to-date information. While performance is 1311 undoubtedly an important issue to consider and worth further 1312 investigation, reality is that a definitive answer cannot be found on 1313 what IP version performs better. Depending on the specific use case 1314 and application, IPv6 is better; in others the same applies to IPv4. 1316 7.4.1. IPv6 packet loss and latency 1318 [APNIC5] provides a measurement of both the failure rate and RTT of 1319 IPv6 compared against IPv4. Both measures are based on scripts that 1320 employs the three-way handshake of TCP. As such, the measurement of 1321 the failure rate does not provide a direct measurement of packet loss 1322 (that would need an Internet-wide measurement campaign). Said that, 1323 despite IPv4 is still performing better, the difference seems to have 1324 decreased in recent years. Two reports, namely [RIPE1] and 1325 [APRICOT], discussed the associated trend, showing how the average 1326 worldwide failure rate of IPv6 is still a bit worse than IPv4. 1327 Reasons for this effect may be found in endpoints with an unreachable 1328 IPv6 address, routing instability or firewall behavior. Yet, this 1329 worsening effect may appear as disturbing for a plain transition to 1330 IPv6. 1332 [APNIC5] also compares the latency of both address families. 1333 Currently, the worldwide average is still in favor of IPv4. Zooming 1334 at the country or even at the operator level, it is possible to get 1335 more detailed information and appreciate that cases exist where IPv6 1336 is faster than IPv4. Regions (e.g. Western Europe, Northern 1337 America, Southern Asia) and Countries (e.g. US, India, Germany) with 1338 an advanced deployment of IPv6 (e.g. >45%) are showing that IPv6 has 1339 better performance than IPv4. [APRICOT] highlights how when a 1340 difference in performance exists it is often related to asymmetric 1341 routing issues. Other possible explanations for a relative latency 1342 difference lays on the specificity of the IPv6 header which allows 1343 packet fragmentation. In turn, this means that hardware needs to 1344 spend cycles to analyze all of the header sections and when it is not 1345 capable of handling one of them it drops the packet. Even 1346 considering this, a difference in latency stands and sometimes it is 1347 perceived as a limiting factor for IPv6. A few measurement campaigns 1348 on the behavior of IPv6 in CDNs are also available [MAPRG], 1349 [INFOCOM]. The TCP connect time is still higher for IPv6 in both 1350 cases, even if the gap has reduced over the analysis time window. 1352 7.4.2. Customer Experience 1354 It is not totally clear if the Customer Experience is in some way 1355 perceived as better when IPv6 is used instead of IPv4. In some cases 1356 it has been publicly reported by IPv6 content providers, that users 1357 have a better experience when using IPv6-only compared to IPv4 1358 [ISOC2]. This could be explained because in the case of an IPv6 user 1359 connecting to an application hosted in an IPv6-only Data Centers, the 1360 connection is end-to-end, without translations. Instead, when using 1361 IPv4 there is a NAT translation either in the CE or in the service 1362 provider's network, in addition to IPv4 to IPv6 (and back to IPv4) 1363 translation in the IPv6-only content provider Data Center. [ISOC2], 1365 [FB] provide reasons in favor of IPv6. In other cases, the result 1366 seems to be still slightly in favor of IPv4 [INFOCOM], [MAPRG], even 1367 if the difference between IPv4 and IPv6 tends to vanish over time. 1369 7.5. IPv6 security 1371 Another point that is sometimes considered as a challenge when 1372 discussing the transition to IPv6 is related to the Security. 1373 [RFC9099] analyzes the operational security issues in several places 1374 of a network (enterprises, service providers and residential users). 1375 It is also worth considering the additional security issues brought 1376 into existence by the applied IPv6 transition technologies used to 1377 implement IPv4aaS, e.g. 464XLAT, DS-Lite. Some hints are in the 1378 paper [ComputSecur]. 1380 The security aspects have to be considered to keep the same level of 1381 security as it exists nowadays in an IPv4-only network environment. 1382 The autoconfiguration features of IPv6 will require some more 1383 attention. Router discovery and address autoconfiguration may 1384 produce unexpected results and security holes. The IPsec protocol 1385 implementation has initially been set as mandatory in every node of 1386 the network, but then relaxed to recommendation due to extremely 1387 constrained hardware deployed in some devices e.g., sensors, Internet 1388 of Things (IoT). 1390 There are some concerns in terms of the security but, on the other 1391 hand, IPv6 offers increased efficiency. There are measurable 1392 benefits to IPv6 to notice, like more transparency, improved 1393 mobility, and also end to end security (if implemented). 1395 As reported in [ISOC3], comparing IPv6 and IPv4 at the protocol 1396 level, one may probably conclude that the increased complexity of 1397 IPv6 results in an increased number of attack vectors, that imply 1398 more possible ways to perform different types attacks. However, a 1399 more interesting and practical question is how IPv6 deployments 1400 compare to IPv4 deployments in terms of security. In that sense, 1401 there are a number of aspects to consider. 1403 Most security vulnerabilities related to network protocols are based 1404 on implementation flaws. Typically, security researchers find 1405 vulnerabilities in protocol implementations, which eventually are 1406 "patched" to mitigate such vulnerabilities. Over time, this process 1407 of finding and patching vulnerabilities results in more robust 1408 implementations. For obvious reasons, the IPv4 protocols have 1409 benefited from the work of security researchers for much longer, and 1410 thus, IPv4 implementations are generally more robust than IPv6. 1411 However, this is turning also in the other way around, as with more 1412 IPv6 deployment there may be older IPv4 flaws not discovered or even 1413 not resolved anymore by vendors. 1415 Besides the intrinsic properties of the protocols, the security level 1416 of the resulting deployments is closely related to the level of 1417 expertise of network and security engineers. In that sense, there is 1418 obviously much more experience and confidence with deploying and 1419 operating IPv4 networks than with deploying and operating IPv6 1420 networks. 1422 Finally, implementation of IPv6 security controls obviously depends 1423 on the availability of features in security devices and tools. 1424 Whilst there have been improvements in this area, there is a lack of 1425 parity in terms of features and/or performance when considering IPv4 1426 and IPv6 support in security devices and tools. 1428 7.5.1. Protocols security issues 1430 It is important to say that IPv6 is not more or less secure than IPv4 1431 and the knowledge of the protocol is the best security measure. 1433 In general there are security concerns related to IPv6 that can be 1434 classified as follows: 1436 o Basic IPv6 protocol (Basic header, Extension Headers, Addressing) 1438 o IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) 1440 o Internet-wide IPv6 security (Filtering, DDoS, Transition 1441 Mechanisms) 1443 ICMPv6 is an integral part of IPv6 and performs error reporting and 1444 diagnostic functions. Since it is used in many IPv6 related 1445 protocols, ICMPv6 packet with multicast address should be filtered 1446 carefully to avoid attacks. Neighbor Discovery Protocol (NDP) is a 1447 node discovery protocol in IPv6 which replaces and enhances functions 1448 of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers 1449 for discovering multicast listeners on a directly attached link, much 1450 like Internet Group Management Protocol (IGMP) is used in IPv4. 1452 These IPv6 associated protocols like ICMPv6, NDP and MLD are 1453 something new compared to IPv4, so they add new security threats and 1454 the related solutions are still under discussion today. NDP has 1455 vulnerabilities [RFC3756] [RFC6583]. The specification says to use 1456 IPsec but it is impractical and not used, on the other hand, SEND 1457 (SEcure Neighbour Discovery) [RFC3971] is not widely available. 1459 [RIPE2] describes the most important threats and solutions regarding 1460 IPv6 security. 1462 7.5.2. IPv6 Extension Headers and Fragmentation 1464 IPv6 Extension Headers imply some issues, in particular their 1465 flexibility also means an increased complexity, indeed security 1466 devices and software must process the full chain of headers while 1467 firewalls must be able to filter based on Extension Headers. 1468 Additionally, packets with IPv6 Extension Headers may be dropped in 1469 the public Internet. Some documents, e.g. 1470 [I-D.hinden-6man-hbh-processing], [I-D.bonica-6man-ext-hdr-update], 1471 [I-D.peng-v6ops-hbh] analyze and provide guidance regarding the 1472 processing procedures of IPv6 Extension Headers. 1474 There are some possible attacks through EHs, for example RH0 can be 1475 used for traffic amplification over a remote path and it is 1476 deprecated. Other attacks based on Extension Headers are based on 1477 IPv6 Header Chains and Fragmentation that could be used to bypass 1478 filtering, but to mitigate this effect, Header chain should go only 1479 in the first fragment and the use of the IPv6 Fragmentation Header is 1480 forbidden in all Neighbor Discovery messages. 1482 Fragment Header is used by IPv6 source node to send a packet bigger 1483 than path MTU and the Destination host processes fragment headers. 1484 There are several threats related to fragmentation to pay attention 1485 to e.g. overlapping fragments (not allowed) resource consumption 1486 while waiting for last fragment (to discard), atomic fragments (to be 1487 isolated). 1489 A lot of additional functionality has been added to IPv6 primarily by 1490 adding Extension Headers and/or using overlay encapsulation. All of 1491 the these expand the packet size and this could lead to oversized 1492 packets that would be dropped on some links. It is important to 1493 investigate the potential problems with oversized packets in the 1494 first place. Fragmentation must not be done in transit and a better 1495 solution needs to be found, e.g. upgrade all links to bigger MTU or 1496 follow specific recommendations at the source node. 1497 [I-D.vasilenko-v6ops-ipv6-oversized-analysis] analyzes available 1498 standards for the resolution of oversized packet drops. 1500 8. Security Considerations 1502 This document has no impact on the security properties of specific 1503 IPv6 protocols or transition tools. The security considerations 1504 relating to the protocols and transition tools are described in the 1505 relevant documents. 1507 9. Contributors 1509 Sebastien Lourdez 1510 Post Luxembourg 1511 Email: sebastien.lourdez@post.lu 1513 10. Acknowledgements 1515 The authors of this document would like to thank Brian Carpenter, 1516 Fred Baker, Alexandre Petrescu, Barbara Stark, Haisheng Yu(Johnson), 1517 Dhruv Dhody, Gabor Lencse, Shuping Peng, Daniel Voyer, Daniel 1518 Bernier, Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, 1519 Erik Nygren, Eduard Vasilenko and Xipeng Xiao for their comments and 1520 review of this document. 1522 11. IANA Considerations 1524 This document has no actions for IANA. 1526 12. References 1528 12.1. Normative References 1530 [I-D.ietf-v6ops-transition-comparison] 1531 Lencse, G., Martinez, J. P., Howard, L., Patterson, R., 1532 and I. Farrer, "Pros and Cons of IPv6 Transition 1533 Technologies for IPv4aaS", draft-ietf-v6ops-transition- 1534 comparison-02 (work in progress), March 2022. 1536 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1537 and E. Lear, "Address Allocation for Private Internets", 1538 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1539 . 1541 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1542 Neighbor Discovery (ND) Trust Models and Threats", 1543 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1544 . 1546 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1547 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1548 DOI 10.17487/RFC3971, March 2005, 1549 . 1551 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1552 for IPv6 Hosts and Routers", RFC 4213, 1553 DOI 10.17487/RFC4213, October 2005, 1554 . 1556 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 1557 Scenarios for IPv6 Deployment", RFC 6036, 1558 DOI 10.17487/RFC6036, October 2010, 1559 . 1561 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1562 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1563 DOI 10.17487/RFC6180, May 2011, 1564 . 1566 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1567 Stack Lite Broadband Deployments Following IPv4 1568 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1569 . 1571 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1572 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1573 RFC 6540, DOI 10.17487/RFC6540, April 2012, 1574 . 1576 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1577 Neighbor Discovery Problems", RFC 6583, 1578 DOI 10.17487/RFC6583, March 2012, 1579 . 1581 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1582 Combination of Stateful and Stateless Translation", 1583 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1584 . 1586 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1587 Content Providers and Application Service Providers", 1588 RFC 6883, DOI 10.17487/RFC6883, March 2013, 1589 . 1591 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1592 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1593 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1594 . 1596 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1597 Farrer, "Lightweight 4over6: An Extension to the Dual- 1598 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1599 July 2015, . 1601 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1602 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1603 Port with Encapsulation (MAP-E)", RFC 7597, 1604 DOI 10.17487/RFC7597, July 2015, 1605 . 1607 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1608 and T. Murakami, "Mapping of Address and Port using 1609 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1610 2015, . 1612 [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. 1613 Patel, "Advertising IPv4 Network Layer Reachability 1614 Information (NLRI) with an IPv6 Next Hop", RFC 8950, 1615 DOI 10.17487/RFC8950, November 2020, 1616 . 1618 [RFC9099] Vyncke, E., Chittimaneni, K., Kaeo, M., and E. Rey, 1619 "Operational Security Considerations for IPv6 Networks", 1620 RFC 9099, DOI 10.17487/RFC9099, August 2021, 1621 . 1623 12.2. Informative References 1625 [Akm] Akamai, "IPv6 Adaptation", 1626 . 1629 [Akm-stats] 1630 Akamai, "IPv6 Adoption Visualization", 2021, 1631 . 1635 [Alx] Alexa, "The top 500 sites on the web", 2021, 1636 . 1638 [Amzn] Amazon, "Announcing Internet Protocol Version 6 (IPv6) 1639 support for Amazon CloudFront, AWS WAF, and Amazon S3 1640 Transfer Acceleration", . 1644 [ANSI] ANSI/CTA, "ANSI/CTA Standard Host and Router Profiles for 1645 IPv6", 2020, . 1648 [APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2022, 1649 . 1651 [APNIC2] APNIC2, "Addressing 2021", 2022, 1652 . 1655 [APNIC3] APNIC, "BGP in 2020 - The BGP Table", 2021, 1656 >. 1659 [APNIC4] APNIC, "BGP in 2021 - The BGP Table", 2022, 1660 >. 1663 [APNIC5] APNIC, "Average RTT Difference (ms) (V6 - V4) for World 1664 (XA)", 2022, . 1666 [APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for 1667 World (XA)", 2020, 1668 . 1671 [ARCEP] ARCEP, "Arcep Decision no 2019-1386, Decision on the terms 1672 and conditions for awarding licences to use frequencies in 1673 the 3.4-3.8GHz band", 2019, 1674 . 1676 [ARIN-CG] ARIN, "Community Grant Program: IPv6 Security, 1677 Applications, and Training for Enterprises", 2020, 1678 . 1680 [ARIN-SW] ARIN, "Preparing Applications for IPv6", 1681 . 1684 [BGR_1] BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment 1685 Monitor", 2022, 1686 . 1688 [BGR_2] BIIGROUP, "China Government IPv6 and DNSSEC Deployment 1689 Monitor", 2022, 1690 . 1692 [BGR_3] BIIGROUP, "China Education IPv6 and DNSSEC Deployment 1693 Monitor", 2022, 1694 . 1696 [CAIDA] APNIC, "Client-Side IPv6 Measurement", 2020, 1697 . 1700 [CAIR] Cisco, "Cisco Annual Internet Report (2018-2023) White 1701 Paper", 2020, 1702 . 1706 [Cldflr] Cloudflare, "Understanding and configuring Cloudflare's 1707 IPv6 support", . 1711 [CN] China.org.cn, "China to speed up IPv6-based Internet 1712 development", 2017, . 1715 [CN-IPv6] National IPv6 Deployment and Monitoring Platform, "Active 1716 IPv6 Internet users", 2022, 1717 . 1719 [CNLABS_1] 1720 CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, 1721 . 1723 [CNLABS_2] 1724 CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, 1725 . 1727 [CNLABS_3] 1728 CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, 1729 . 1731 [ComputSecur] 1732 Computers & Security (Elsevier), "Methodology for the 1733 identification of potential security issues of different 1734 IPv6 transition technologies: Threat analysis of DNS64 and 1735 stateful NAT64", DOI 10.1016/j.cose.2018.04.012, 2018. 1737 [Csc6lab] Cisco, "World - Display Content Data", 2022, 1738 . 1740 [ETSI-IP6-WhitePaper] 1741 ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, 1742 Benefits, Transition Challenges and the Way Forward", 1743 ISBN 979-10-92620-31-1, 2020. 1745 [FB] Saab, P., "Facebook IPv6 Experience", 2015, 1746 . 1748 [G_stats] Google, "Google IPv6 Per-Country IPv6 adoption", 2021, 1749 . 1752 [Ggl] Google, "Introduction to GGC", 1753 . 1756 [HxBld] HexaBuild, "IPv6 Adoption Report 2020", 2020, 1757 . 1760 [I-D.bonica-6man-ext-hdr-update] 1761 Bonica, R. and T. Jinmei, "Inserting, Processing And 1762 Deleting IPv6 Extension Headers", draft-bonica-6man-ext- 1763 hdr-update-07 (work in progress), February 2022. 1765 [I-D.hinden-6man-hbh-processing] 1766 Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 1767 Processing Procedures", draft-hinden-6man-hbh- 1768 processing-01 (work in progress), June 2021. 1770 [I-D.ietf-bess-ipv6-only-pe-design] 1771 Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang, 1772 Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for 1773 IPv4-NLRI with IPv6-NH", draft-ietf-bess-ipv6-only-pe- 1774 design-00 (work in progress), September 2021. 1776 [I-D.palet-v6ops-ipv6-only] 1777 Martinez, J. P., "IPv6-only Terminology Definition", 1778 draft-palet-v6ops-ipv6-only-05 (work in progress), March 1779 2020. 1781 [I-D.peng-v6ops-hbh] 1782 Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra, 1783 "Processing of the Hop-by-Hop Options Header", draft-peng- 1784 v6ops-hbh-06 (work in progress), August 2021. 1786 [I-D.vasilenko-v6ops-ipv6-oversized-analysis] 1787 Vasilenko, E., Xipeng, X., and D. Khaustov, "IPv6 1788 Oversized Packets Analysis", draft-vasilenko-v6ops-ipv6- 1789 oversized-analysis-01 (work in progress), September 2021. 1791 [IAB] IAB, "IAB Statement on IPv6", 2016, 1792 . 1794 [IGP-GT] Internet Governance Project, Georgia Tech, "The hidden 1795 standards war: economic factors affecting IPv6 1796 deployment", 2019, . 1800 [INFOCOM] Doan, T., "A Longitudinal View of Netflix: Content 1801 Delivery over IPv6 and Content Cache Deployments", 2020, 1802 . 1805 [IPv6Forum] 1806 IPv6Forum, "Estimating IPv6 & DNSSEC External Service 1807 Deployment Status", 2022, 1808 . 1810 [ISIF-ASIA-G] 1811 ISIF Asia, "Internet Operations Research Grant: IPv6 1812 Deployment at Enterprises. IIESoc. India", 2020, 1813 . 1815 [ISOC1] Internet Society, "State of IPv6 Deployment 2018", 2018, 1816 . 1819 [ISOC2] Internet Society, "Facebook News Feeds Load 20-40% Faster 1820 Over IPv6", 2015, 1821 . 1824 [ISOC3] Internet Society, "IPv6 Security FAQ", 2019, 1825 . 1828 [MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over 1829 IPv6", 2017, . 1833 [Mcrsft] Microsoft, "IPv6 for Azure VMs available in most regions", 1834 . 1837 [NRO] NRO, "Internet Number Resource Status Report", 2021, 1838 . 1841 [NST_1] NIST, "Estimating Industry IPv6 and DNSSEC External 1842 Service Deployment Status", 2022, . 1845 [NST_2] NIST, "Estimating USG IPv6 and DNSSEC External Service 1846 Deployment Status", 2022, . 1849 [NST_3] NIST, "Estimating University IPv6 and DNSSEC External 1850 Service Deployment Status", 2022, . 1853 [Ntflx] Netflix, "Enabling Support for IPv6", 1854 . 1857 [POTAROO1] 1858 POTAROO, "IP Addressing through 2021", 2022, 1859 . 1861 [POTAROO2] 1862 POTAROO, "IPv6 Resource Allocations", 2022, 1863 . 1865 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1866 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1867 . 1869 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1870 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1871 2012, . 1873 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1874 Better Connectivity Using Concurrency", RFC 8305, 1875 DOI 10.17487/RFC8305, December 2017, 1876 . 1878 [RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, 1879 . 1882 [RIPE2] RIPE, "IPv6 Security", 2019, 1883 . 1886 [RIPE3] RIPE, "IPv6", 2021, 1887 . 1890 [RlncJ] Reliance Jio, "IPv6-only adoption challenges and 1891 standardization requirements", 2020, 1892 . 1896 [SNDVN] SANDVINE, "Sandvine releases 2020 Mobile Internet 1897 Phenomena Report: YouTube is over 25% of all mobile 1898 traffic", 2020, . 1902 [US-CIO] The CIO Council, "Memorandum for Heads of Executive 1903 Departments and Agencies. Completing the Transition to 1904 Internet Protocol Version 6 (IPv6)", 2020, 1905 . 1908 [US-FR] Federal Register, "Request for Comments on Updated 1909 Guidance for Completing the Transition to the Next 1910 Generation Internet Protocol, Internet Protocol Version 6 1911 (IPv6)", 2020, . 1916 [Vrzn] Verizon, "Verizon Digital Media Services announces IPv6 1917 Compliance", . 1921 [W3Tech] W3Tech, "Historical yearly trends in the usage statistics 1922 of site elements for websites", 2021, . 1925 [Wikipedia] 1926 Wikipedia, "Comparison of IPv6 support in common 1927 applications", . 1930 [WIPv6L] World IPv6 Launch, "World IPv6 Launch - Measurements", 1931 2021, . 1933 Appendix A. Summary of Questionnaire and Replies for network operators 1935 A survey was proposed to more than 50 service providers in the 1936 European region during the third quarter of 2020 to ask for their 1937 plans on IPv6 and the status of IPv6 deployment. 1939 40 people, representing 38 organizations, provided a response. This 1940 appendix summarizes the results obtained. 1942 Respondents' business 1943 Convergent Mobile Fixed 1944 Type of operators 82% 8% 11% 1946 Question 1. Do you have plan to move more fixed or mobile or 1947 enterprise users to IPv6 in the next 2 years? 1949 a. If so, fixed, or mobile, or enterprise? 1951 b. What are the reasons to do so? 1953 c. When to start: already on going, in 12 months, after 12 months? 1955 d. Which transition solution will you use, Dual-Stack, DS-Lite, 1956 464XLAT, MAP-T/E? 1958 Answer 1.A (38 respondents) 1960 Yes No 1961 Plans availability 79% 21% 1963 Mobile Fixed Enterprise Don't answer 1964 Business segment 63% 63% 50% 3% 1966 Answer 1.B (29 respondents) 1968 Even this was an open question, some common answers can be found. 1970 14 respondents (48%) highlighted issues related to IPv4 depletion. 1971 The reason to move to IPv6 is to avoid private and/or overlapping 1972 addresses. 1974 For 6 respondents (20%) 5G/IoT is a business incentive to introduce 1975 IPv6. 1977 4 respondents (13%) also highlight that there is a National 1978 regulation request to enable IPv6 associated with the launch of 5G. 1980 4 respondents (13%) consider IPv6 as a part of their innovation 1981 strategy or an enabler for new services. 1983 4 respondents (13%) introduce IPv6 because of Enterprise customers 1984 demand. 1986 Answer 1.C (30 respondents) 1987 On-going In 12 months After 12 months Don't answer 1988 Timeframe 60% 33% 0% 7% 1990 Answer 1.D (28 respondents for cellular, 27 for wireline) 1992 Transition in use Dual-Stack 464XLAT MAP-T Don't answer 1993 Cellular 39% 21% 4% 36% 1995 Transition in use Dual-Stack DS-Lite 6RD/6VPE Don't answer 1996 Wireline 59% 19% 4% 19% 1998 Question 2. Do you need to change network devices for the above 1999 goal? 2001 a. If yes, what kind of devices: CE, or BNG/mobile core, or NAT? 2003 b. Will you migrate your metro or backbone or backhaul network to 2004 support IPv6? 2006 Answer 2.A (30 respondents) 2008 Yes No Don't answer 2009 Need of changing 43% 33% 23% 2011 CEs Routers BNG CGN Mobile core 2012 What to change 47% 27% 20% 33% 27% 2014 Answer 2.B (22 respondents) 2016 Yes Future No 2017 Plans for transition 9% 9% 82% 2019 Appendix B. Summary of Questionnaire and Replies for enterprises 2021 The Industry Network Technology Council (INTC) developed the 2022 following poll to verify the need or willingness of medium-to-large 2023 US-based enterprises for training and consultancy on IPv6 2024 (https://industrynetcouncil.org/). 2026 54 organizations provided an answer. 2028 Question 1. How much IPv6 implementation have you done at your 2029 organization? (54 respondents) 2030 None 16.67% 2031 Some people have gotten some training 16.67% 2032 Many people have gotten some training 1.85% 2033 Web site is IPv6 enabled 7.41% 2034 Most equipment is dual-stacked 31.48% 2035 Have an IPv6 transition plan for entire network 5.56% 2036 Running native IPv6 in many places 20.37% 2037 Entire network is IPv6-only 0.00% 2039 Question 2. What kind of help or classes would you like to see INTC 2040 do? ( 54 respondents) 2042 Classes/labs on IPv6 security 66.67% 2043 Classes/labs on IPv6 fundamentals 55.56% 2044 Classes/labs on address planning/network conf. 57.41% 2045 Classes/labs on IPv6 troubleshooting 66.67% 2046 Classes/labs on application conversion 35.19% 2047 Other 14.81% 2049 Question 3. As you begin to think about the implementation of IPv6 2050 at your organization, what areas do you feel are of concern? (54 2051 respondents) 2053 Security 31.48% 2054 Application conversion 25.93% 2055 Training 27.78% 2056 All the above 33.33% 2057 Don't know enough to answer 14.81% 2058 Other 9.26% 2060 Authors' Addresses 2062 Giuseppe Fioccola 2063 Huawei Technologies 2064 Riesstrasse, 25 2065 Munich 80992 2066 Germany 2068 Email: giuseppe.fioccola@huawei.com 2070 Paolo Volpato 2071 Huawei Technologies 2072 Via Lorenteggio, 240 2073 Milan 20147 2074 Italy 2076 Email: paolo.volpato@huawei.com 2077 Nalini Elkins 2078 Inside Products 2079 36A Upper Circle 2080 Carmel Valley CA 93924 2081 United States of America 2083 Email: nalini.elkins@insidethestack.com 2085 Jordi Palet Martinez 2086 The IPv6 Company 2087 Molino de la Navata, 75 2088 La Navata - Galapagar, Madrid 28420 2089 Spain 2091 Email: jordi.palet@theipv6company.com 2093 Gyan S. Mishra 2094 Verizon Inc. 2096 Email: gyan.s.mishra@verizon.com 2098 Chongfeng Xie 2099 China Telecom 2101 Email: xiechf@chinatelecom.cn