idnits 2.17.1 draft-ietf-v6ops-ipv6-deployment-00.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 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (April 7, 2021) is 1112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-21 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 0 errors (**), 0 flaws (~~), 4 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: October 9, 2021 N. Elkins 6 Inside Products 7 G. Mishra 8 Verizon Inc. 9 C. Xie 10 China Telecom 11 April 7, 2021 13 IPv6 Deployment Status 14 draft-ietf-v6ops-ipv6-deployment-00 16 Abstract 18 Looking globally, IPv6 is growing faster than IPv4 and this means 19 that the collective wisdom of the networking industry has selected 20 IPv6 for the future. This document provides an overview of IPv6 21 transition deployment status and a view on how the transition to IPv6 22 is progressing among network operators and enterprises that are 23 introducing IPv6 or have already adopted an IPv6-only solution. It 24 also aims to analyze the transition challenges and therefore 25 encourage actions and more investigations on some areas that are 26 still under discussion. The overall IPv6 incentives are also 27 examined. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in BCP 14 [RFC2119] 34 [RFC8174] when, and only when, they appear in all capitals, as shown 35 here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 9, 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. IPv4 Adress Exhaustion . . . . . . . . . . . . . . . . . . . 4 73 3. The global picture of IPv6 . . . . . . . . . . . . . . . . . 5 74 3.1. IPv6 users . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2. IPv6 allocations and networks . . . . . . . . . . . . . . 5 76 4. Survey among Network Operators . . . . . . . . . . . . . . . 7 77 5. Considerations for Enterprises . . . . . . . . . . . . . . . 8 78 6. Observations on Content and Cloud Service Providers . . . . . 8 79 7. Industrial Internet application . . . . . . . . . . . . . . . 8 80 8. IPv6 deployments worldwide . . . . . . . . . . . . . . . . . 9 81 8.1. IPv6 service design for Mobile, Fixed broadband and 82 enterprises . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1.1. IPv6 introduction . . . . . . . . . . . . . . . . . . 9 84 8.1.2. IPv6-only service delivery . . . . . . . . . . . . . 10 85 9. Findings of the IPv6 Survey . . . . . . . . . . . . . . . . . 11 86 10. IPv6 incentives . . . . . . . . . . . . . . . . . . . . . . . 12 87 11. Call for action . . . . . . . . . . . . . . . . . . . . . . . 13 88 11.1. Transition choices . . . . . . . . . . . . . . . . . . . 13 89 11.1.1. Service providers . . . . . . . . . . . . . . . . . 13 90 11.1.2. Enterprises . . . . . . . . . . . . . . . . . . . . 14 91 11.1.3. Cloud and Data Centers . . . . . . . . . . . . . . . 16 92 11.1.4. Industrial Internet . . . . . . . . . . . . . . . . 16 93 11.1.5. Government and Regulators . . . . . . . . . . . . . 17 94 11.2. Network Operations . . . . . . . . . . . . . . . . . . . 17 95 11.3. Performance . . . . . . . . . . . . . . . . . . . . . . 18 96 11.3.1. IPv6 latency . . . . . . . . . . . . . . . . . . . . 18 97 11.3.2. IPv6 packet loss . . . . . . . . . . . . . . . . . . 18 98 11.3.3. Router's performance . . . . . . . . . . . . . . . . 19 99 11.4. IPv6 security . . . . . . . . . . . . . . . . . . . . . 19 100 11.4.1. Protocols security issues . . . . . . . . . . . . . 20 101 11.4.2. IPv6 Extension Headers and Fragmentation . . . . . . 21 102 11.4.3. Oversized IPv6 packets . . . . . . . . . . . . . . . 21 103 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 104 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 105 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 106 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 16.1. Normative References . . . . . . . . . . . . . . . . . . 22 109 16.2. Informative References . . . . . . . . . . . . . . . . . 22 110 Appendix A. Summary of Questionnaire and Replies . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 113 1. Introduction 115 The focus of this document is to provide a survey of the deployed 116 IPv6 transition technologies and to highlight the difficulties in the 117 transition. This process helps to understand what is missing and how 118 to improve the current IPv6 deployment strategies of network 119 operators, enterprises, content and cloud service providers. The 120 objective is to give an updated view of the practices and plans 121 already described in [RFC6036]. The scope is to report the current 122 IPv6 status and encourage actions and more investigations on some 123 areas that are still under discussion as well as the main incentives 124 for the IPv6 adoption. 126 [RFC6180] discussed the IPv6 deployment models and migration tools. 127 [RFC6036] described the Service Provider Scenarios for IPv6 128 Deployment, [RFC7381] introduced the guidelines of the IPv6 129 deployment for Enterprise and [RFC6883] provided guidance and 130 suggestions for Internet Content Providers and Application Service 131 Providers. On the other hand, this document focuses on the end-to- 132 end services and in particular on the device - network - content 133 communication chain. 135 [ETSI-IP6-WhitePaper] reported the IPv6 Best Practices, Benefits, 136 Transition Challenges and the Way Forward. IPv6 is becoming a 137 priority again and a new wave of IPv6 deployment is expected, due the 138 exhaustion of the IPv4 address space since 2010, in addition 139 technologies like 5G, cloud, IoT require its use, governments and 140 standard bodies (including IETF) demand it, and the device - network 141 - content communication chain is calling for its adoption. In this 142 regard it is possible to mention the IAB Statement on IPv6 stating 143 that "IETF will stop requiring IPv4 compatibility in new or extended 144 protocols". 146 The following sections go through the issue of IPv4 address 147 exhaustion and give the global picture of IPv6 to show how IPv6 is 148 growing faster than IPv4 worldwide in all measures including number 149 of users, percentage of content, and amount of traffic. This 150 testifies that the key Internet industry players have decided 151 strategically to invest and deploy IPv6 in large-scale to sustain the 152 Internet growth. 154 Then it is presented the survey among network operators as well as 155 considerations and observations for enterprises and content and cloud 156 service providers about the IPv6 deployment and the considerations 157 that have come out. IPv6 transition solutions for Mobile BroadBand 158 (MBB), Fixed BroadBand (FBB) and enterprise services are ready. 159 Dual-Stack is the most deployed solution for IPv6 introduction, while 160 464XLAT and Dual Stack Lite (DS-Lite) seem the most suitable for 161 IPv6-only service delivery. 163 Finally, The IPv6 incentives are presented but the general IPv6 164 challenges are also reported in particular in relation to 165 Architecture, Operations, Performance and Security issues. These 166 considerations aim to start a call for action on the areas of 167 improvement, that are often mentioned as reason for not deploying 168 IP6. 170 2. IPv4 Adress Exhaustion 172 According to [CAIR] there will be 29.3 billion networked devices by 173 2023, up from 18.4 billion in 2018. This poses the question on 174 whether the IPv4 address space can sustain such a number of 175 allocations and, consequently, if this is affecting the process of 176 its exhaustion. The answer is not straightforward as many aspects 177 have to be considered. 179 On the one hand, the RIRs are reporting scarcity of available and 180 still reserved addresses. Table 3 of [POTAROO1] shows that the 181 available pool of the five RIRs counts a little more than 6 million 182 IPv4 address, while the reserved pool includes another 12 million, 183 for a total of "usable" addresses equal to 18.3 million. The same 184 reference, in table 1, shows that the total IPv4 allocated pool 185 equals 3.684 billion addresses. The ratio between the "usable" 186 addresses and the total allocated brings to 0.005% of remaining 187 space. 189 On the other, [POTAROO1] again highlights the role of both NAT and 190 the address transfer to counter the IPv4 exhaustion. NAT systems 191 well fit in the current client/server model used by most of the 192 available Internet applications, with this phenomenon amplified by 193 the general shift to cloud. The transfer of IPv4 addresses also 194 contributes to mitigate the the need of addresses. As an example, 195 [IGP-GT] shows the amount of transfers to recipient organizations in 196 the ARIN region in 2018. Cloud Service Providers (CSPs) appear to be 197 the most active is buying available addresses to satisfy their need 198 of providing IPv4 connectivity to their tenants. 200 3. The global picture of IPv6 202 The utilization of IPv6 has been monitored by many agencies and 203 institutions worldwide. Different analytics have been made 204 available, ranging from the number of IPv6 users, its relative 205 utilization over the Internet, to the number of carriers able to 206 route IPv6 network prefixes. [ETSI-IP6-WhitePaper] provided several 207 of those analytics. The scope of this section then is to summarize 208 the status of the IPv6 adoption, so to get an indication of the 209 relevance of IPv6 today. For the analytics listed here, the trend 210 over the past five years is given, expressed as the Compound Annual 211 Growth Rate (CAGR). In general, this shows how IPv6 has grown in the 212 past few years, and that is growing faster than IPv4. 214 3.1. IPv6 users 216 [ETSI-IP6-WhitePaper] provided the main statistics about the 217 utilization of IPv6 worldwide and references the organizations that 218 make their measurement publicly available through their web sites. 219 To give a rough estimation of the relative growth of IPv6, the next 220 table shows the total number of estimated IPv6 users at December 2020 221 as measured by [POTAROO2], [APNIC1]. 223 +--------+-------+-------+--------+--------+--------+--------+ 224 | | Dec | Dec | Dec | Dec | Dec | CAGR | 225 | | 2016 | 2017 | 2018 | 2019 | 2020 | | 226 +--------+-------+-------+--------+--------+--------+--------+ 227 | World | 300.85| 473.14| 543.04 | 990.19 |1,201.09| 41% | 228 +--------+-------+-------+--------+--------+--------+--------+ 230 Figure 1: IPv6 users worldwide (in millions) 232 3.2. IPv6 allocations and networks 234 Regional Internet Registries (RIRs) are responsible for assigning an 235 IPv6 address block to ISPs or enterprises. An ISP will use the 236 assigned block to provide addresses to their end users. For example, 237 a mobile carrier will assign one or several /64 prefixes to the end 238 users. Several analytics are available for the RIRs. The next table 239 shows the amount of individual allocations, per RIR, in the time 240 period 2016-2020 [APNIC2]. 242 +---------+-------+-------+-------+-------+-------+---------+------+ 243 | Registry| Dec | Dec | Dec | Dec | Dec |Cumulated| CAGR | 244 | | 2016 | 2017 | 2018 | 2019 | 2020 | | | 245 +---------+-------+-------+-------+-------+-------+---------+------+ 246 | AFRINIC | 116 | 112 | 110 | 115 | 109 | 562 | 48% | 247 | APNIC | 1,681 | 1,369 | 1,474 | 1,484 | 1,498 | 7,506 | 45% | 248 | ARIN | 646 | 684 | 659 | 605 | 644 | 3,238 | 50% | 249 | LACNIC | 1,009 | 1,549 | 1,448 | 1,614 | 1,801 | 7,421 | 65% | 250 | RIPE NCC| 2,141 | 2,051 | 2,620 | 3,104 | 1,403 | 11,319 | 52% | 251 | | | | | | | | | 252 | Total | 5,593 | 5,765 | 6,311 | 6,922 | 5,455 | 30,046 | 52% | 253 +---------+-------+-------+-------+-------+-------+---------+------+ 255 Figure 2: IPv6 allocations worldwide 257 Note that the decline in 2020 of IPv6 allocations from the RIPE NCC 258 could be explained with the COVID-19 measures that affect many 259 European countries. Anyway countries all over the world have been 260 similarly affected, but the decline in IPv6 allocation activity in 261 2020 is only seen in the data from the RIPE NCC. 263 [APNIC2] also compares the number of allocations for both address 264 families, and the result is in favor of IPv6. The average yearly 265 growth is 52% for IPv6 in the period 2016-2020 versus 49% for IPv4, a 266 sign that IPv6 is growing bigger than IPv4. This is described in the 267 next table. 269 +--------+------+------+--------+--------+-------+-----------+------+ 270 | Address| Dec | Dec | Dec | Dec | Dec | Cumulated | CAGR | 271 | family | 2016 | 2017 | 2018 | 2019 | 2020 | | | 272 +--------+------+------+--------+--------+-------+-----------+------+ 273 | IPv6 | 5,593| 5,765| 6,311 | 6,922 | 5,455 | 30,046 | 52% | 274 | | | | | | | | | 275 | IPv4 |10,515| 9,437| 10,192 | 14,019 | 7,437 | 51,600 | 49% | 276 | | | | | | | | | 277 +--------+------+------+--------+--------+-------+-----------+------+ 279 Figure 3: Allocations per address family 281 The next table is based on [APNIC3], [APNIC4] and shows the 282 percentage of ASes supporting IPv6 compared to the total ASes 283 worldwide. The number of IPv6-capable ASes increases from 22.6% in 284 January 2017 to 30.4% in January 2021. This equals to 14% CAGR for 285 IPv6 enabled networks. This also shows that the number of networks 286 supporting IPv6 is growing faster than the ones supporting IPv4, 287 since the total (IPv6 and IPv4) networks grow at 6% CAGR. 289 +------------+-------+-------+-------+-------+-------+------+ 290 | Advertised | Jan | Jan | Jan | Jan | Jan | CAGR | 291 | ASN | 2017 | 2018 | 2019 | 2020 | 2021 | | 292 +------------+-------+-------+-------+-------+-------+------+ 293 |IPv6-capable| 12,700| 14,500| 16,470| 18,600| 21,400| 14% | 294 | | | | | | | | 295 | Total ASN | 56,100| 59,700| 63,100| 66,800| 70,400| 6% | 296 | | | | | | | | 297 | Ratio | 22.6% | 24.3% | 26.1% | 27.8% | 30.4% | | 298 +------------+-------+-------+-------+-------+-------+------+ 300 Figure 4: Percentage of IPv6-capable ASes 302 4. Survey among Network Operators 304 It was started an IPv6 poll to more than 50 network operators about 305 the status of IPv6 deployment. This poll reveals that more than 30 306 operators will migrate fixed and mobile users to IPv6 in next 2 307 years. The IPv6 Poll has been submitted in particular to network 308 operators considering that, as showed by the previous section, both 309 user devices and contents seem more ready for IPv6. The answers to 310 the questionnaire can be found in Appendix. 312 The main Questions asked are: 314 * Do you plan to move more fixed or mobile or enterprise users to 315 IPv6 (e.g. Dual-Stack) or IPv6-only in the next 2 years? What 316 are the reasons to do so? Which transition solution will you use, 317 Dual-Stack, DS-Lite, 464XLAT, MAP-T/E? 319 * Do you need to change network devices for the above goal? Will 320 you migrate your metro or backbone or backhaul network to support 321 IPv6? 323 The result of this questionnaire highlights that major IPv6 migration 324 will happen in next 2 years. Dual Stack is always the most adopted 325 solution and the transition to IPv6-only is motivated in particular 326 by business reasons like the 5G and IoT requirements. In addition it 327 is worth mentioning that the migration of transport network (metro 328 and backbone) is not considered a priority today for many network 329 operators and the focus is in particular on the end to end IPv6 330 services. 332 More details about the answers received can be found in the Appendix. 334 5. Considerations for Enterprises 336 As described in [RFC7381], enterprises face different challenges than 337 operators. The overall problem for many enterprises is to handle 338 IPv6-based connectivity to the upstream providers, while supporting a 339 mixed IPv4/IPv6 domain in the internal network. 341 The business reasons for IPv6 is unique to each enterprise especially 342 for the internal network. But the most common drivers are on the 343 external network due to the fact that when Internet service 344 providers, run out of IPv4 addresses, they will provide native IPv6 345 and non-native IPv4. So for client networks trying to reach 346 enterprise networks, the IPv6 experience will be better than the 347 transitional IPv4 if the enterprise deploys IPv6 in its public-facing 348 services. Enterprise that is or will be expanding into emerging 349 markets or that partners with other companies who use IPv6 (larger 350 enterprise, governments, service providers) has to deploy IPv6 or 351 plan to do in the near term to support the long term goals. As an 352 example it is possible to mention the emerging energy market and in 353 partiuclar SmartGrid where high density of IP-enabled endpoints are 354 needed and IPv6 is a key technology. 356 6. Observations on Content and Cloud Service Providers 358 The number of addresses required to connect all of the virtual and 359 physical elements in a Data Center and the necessity to overcome the 360 limitation posed by [RFC1918] has been the driver to adopt IPv6 in 361 several Content and Cloud Service Provider (CSP) networks. 363 Several public references discuss how most of the major players find 364 themselves at different stages in the transition to IPv6-only in 365 their DC infrastructure. In some cases, the transition already 366 happened and the DC infrastructure of these hyperscalers is 367 completely based on IPv6. This can be considered a good sign because 368 the end-to-end connectivity between a client (e.g. an application on 369 a smartphone) and a server (a Virtual Machine in a DC) may be based 370 on IPv6. 372 7. Industrial Internet application 374 There are potential advantages for implementing IPv6 for IIoT 375 (Industrial Internet of Things) applications, in particular the large 376 IPv6 address space, the automatic IPv6 configuration and resource 377 discovery. 379 However, there are still many obstacles that prevent its pervasive 380 use. The key problems identified are the incomplete or immature tool 381 support, the dependency on manual configuration and the poor 382 knowledge of the IPv6 protocols among insiders. To advance and ease 383 the use of IPv6 for smart manufacturing systems and IIoT applications 384 in general, a generic approach to remove these pain points is 385 therefore highly desirable. 387 8. IPv6 deployments worldwide 389 This section reports the most deployed approaches for the IPv6 390 migration in MBB, FBB and enterprise. 392 8.1. IPv6 service design for Mobile, Fixed broadband and enterprises 394 The consolidated strategy, as also described in 395 [ETSI-IP6-WhitePaper], is based on two stages, namely: (1) IPv6 396 introduction, and (2) IPv6-only. The first stage aims at delivering 397 the service in a controlled manner, where the traffic volume of 398 IPv6-based services is minimal. When the service conditions change, 399 e.g. when the traffic grows beyond a certain threshold, then the 400 move to the second stage may occur. In this latter case, the service 401 is delivered solely on IPv6. 403 8.1.1. IPv6 introduction 405 In order to enable the deployment of an IPv6 service over an underlay 406 IPv4 architecture, there are two possible approaches: 408 o Enabling Dual-Stack at the CPE 410 o Tunneling IPv6 traffic over IPv4, e.g. with 6rd. 412 So, from a technical perspective, the first stage is based on Dual- 413 Stack [RFC4213] or tunnel-based mechanisms such as Generic Routing 414 Encapsulation (GRE), IPv6 Rapid Deployment (6rd), Connection of IPv6 415 Domains via IPv4 Clouds (6to4), and others. 417 Dual-Stack [RFC4213] is more robust, and easier to troubleshoot and 418 support. Based on information provided by operators with the answers 419 to the poll (see Appendix A), it can be stated that Dual-Stack is 420 currently the most widely deployed IPv6 solution, for MBB, FBB and 421 enterprises, accounting for about 50% of all IPv6 deployments, see 422 both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper]. 423 Therefore, for operators that are willing to introduce IPv6 the most 424 common approach is to apply the Dual-Stack transition solution. 426 With Dual-Stack, IPv6 can be introduced together with other network 427 upgrade and many parts of network management and IT systems can still 428 work in IPv4. This avoids major upgrade of such systems to support 429 IPv6, which is possibly the most difficult task in IPv6 transition. 431 In other words, the cost and effort on the network management and IT 432 system upgrade are moderate. The benefits are to start to 433 accommodate future services and save the NAT costs. 435 The CPE has only an IPv6 address at the WAN side and uses an IPv6 436 connection to the operator gateway, e.g. Broadband Network Gateway 437 (BNG) or Packet Gateway (PGW) / User Plane Function (UPF). However, 438 the hosts and content servers can still be IPv4 and/or IPv6. For 439 example, NAT64 can enable IPv6 hosts to access IPv4 servers. The 440 backbone network underlay can also be IPv4 or IPv6. 442 Although the Dual-Stack IPv6 transition is a good solution to be 443 followed in the IPv6 introduction stage, it does have few 444 disadvantages in the long run, like the duplication of the network 445 resources and states, as well as other limitations for network 446 operation. For this reason, when IPv6 increases to a certain limit, 447 it would be better to switch to the IPv6-only stage. 449 8.1.2. IPv6-only service delivery 451 The second stage, named here IPv6-only, can be a complex decision 452 that depends on several factors, such as economic factors, policy and 453 government regulation. 455 [I-D.lmhp-v6ops-transition-comparison] discusses and compares the 456 technical merits of the most common transition solutions for 457 IPv6-only service delivery, 464XLAT, DS-lite, Lightweight 4over6 458 (lw4o6), MAP-E, and MAP-T, but without providing an explicit 459 recommendation. As the poll highlights, the most widely deployed 460 IPv6 transition solution for MBB is 464XLAT and for FBB is DS-Lite. 462 Based on the survey among network operators in Appendix A it is 463 possible to analyze the IPv6 transition technologies that are already 464 deployed or that will be deployed. The different answers to the 465 questionnaire and in particular [ETSI-IP6-WhitePaper] reported 466 detailed statistics on that and it can be stated that, besides Dual- 467 Stack, the most widely deployed IPv6 transition solution for MBB is 468 464XLAT [RFC6877], and for FBB is DS-Lite [RFC6333], both of which 469 are IPv6-only solutions. 471 Looking at the different feedback from network operators, in some 472 cases, even when using private addresses, such as 10.0.0.0/8 space 473 [RFC1918], the address pool is not large enough, e.g. for large 474 mobile operators or large Data Centers (DCs), Dual-Stack is not 475 enough, because it still requires IPv4 addresses to be assigned. 476 Also, Dual-Stack will likely lead to duplication of several network 477 operations both in IPv6 and IPv4 and this increases the amount of 478 state information in the network with a waste of resources. For this 479 reason, in some scenarios (e.g. MBB or DCs) IPv6-only stage could be 480 more efficient from the start since the IPv6 introduction phase with 481 Dual-Stack may consume more resources (for example CGNAT costs). 483 So, in general, it is possible to state that, when the Dual-Stack 484 disadvantages outweigh the IPv6-only complexity, it makes sense to 485 migrate to IPv6-only. Some network operators already started this 486 process, while others are still waiting. 488 9. Findings of the IPv6 Survey 490 Global IPv4 address depletion is reported by most network operators 491 as the important driver for IPv6 deployment. Indeed, the main reason 492 for IPv6 deployment given is related to the run out of private 493 10.0.0.0/8 space [RFC1918]. 5G and IoT service deployment is another 494 incentive not only for business reasons but also for the need of more 495 addresses. 497 The answers in Appendix shows that the IPv6 deployment strategy is 498 based mainly on Dual Stack architecture and most of the network 499 operators are migrating or plan to migrate in the next few years. 500 The main motivation is related to the depletion of IPv4 addresses and 501 to save the NAT costs. 503 It is interesting to see that most of the network operators have no 504 big plans to migrate transport network (metro and backbone) soon, 505 since they do not see business reasons. It seems that there is no 506 pressure to migrate to native IPv6 forwarding in the short term, 507 anyway the future benefit of IPv6 may justify in the long term a 508 migration to native IPv6. Some network operators also said that a 509 software upgrade can be enough to support IPv6 where it is needed for 510 now. 512 This survey demonstrates that full replacement of IPv4 will take long 513 time. Indeed the transition to IPv6 has different impacts and 514 requirements depending on the network segment: 516 o It is possible to say that almost all mobile devices are already 517 IPv6 capable while for fixed access most of the CPEs are Dual 518 Stack. Data Centers are also evolving and deploying IPv6 to cope 519 with the increasing demand of cloud services. 521 o While the access network seems not strongly impacted because it is 522 mainly based on layer 2 traffic, regarding Edge and BNG, most 523 network operators that provide IPv6 connectivity runs BNG devices 524 in Dual Stack in order to distribute both IPv4 and IPv6. 526 o For Metro and Backbone, the trend is to keep MPLS Data Plane and 527 run IPv6/IPv4 over PE devices at the border. All MPLS services 528 can be guaranteed in IPv6 as well through 6PE/6VPE protocols. 530 In this scenario it is clear that the complete deployment of a full 531 IPv6 data plane will take more time. If we look at the long term 532 evolution, IPv6 can bring other advantages like introducing advanced 533 protocols developed only on IPv6 (e.g. SRv6) to implement all the 534 controlled SLA services aimed by the 5G technology and beyond. 536 10. IPv6 incentives 538 It is possible to state that IPv6 adoption is no longer optional, 539 indeed there are several incentives for the IPv6 deployment: 541 Technical incentives: all Internet technical standard bodies and 542 network equipment vendors have endorsed IPv6 and view it as the 543 standards-based solution to the IPv4 address shortage. The IETF, 544 as well as other SDOs, need to ensure that their standards do not 545 assume IPv4. The IAB expects that the IETF will stop requiring 546 IPv4 compatibility in new or extended protocols. Future IETF 547 protocol work will then optimize for and depend on IPv6. It is 548 recommended that all networking standards assume the use of IPv6 549 and be written so they do not require IPv4 ([RFC6540]). In 550 addition, every Internet registry worldwide strongly recommends 551 immediate IPv6 adoption. 553 Business incentives: with the emergence of new digital 554 technologies, such as 5G, IOT and Cloud, new use cases have come 555 into being and posed more new requirements for IPv6 deployment. 556 Over time, numerous technical and economic stop-gap measures have 557 been developed in an attempt to extend the lifetime of IPv4, but 558 all of these measures add cost and complexity to network 559 infrastructure and raise significant barriers to innovation. It 560 is widely recognized that full transition to IPv6 is the only 561 viable option to ensure future growth and innovation in Internet 562 technology and services. Several large networks and Data Centers 563 have already evolved their internal infrastructures to be 564 IPv6-only. Forward looking large corporations are also working 565 toward migrating their enterprise networks to IPv6-only 566 environments. 568 Governments incentives: governments have a huge responsibility in 569 promoting IPv6 deployment within their countries. There are 570 example of governments already adopting policies to encourage IPv6 571 utilization or enforce increased security on IPv4. So, even 572 without funding the IPv6 transition, governments can recommend to 573 add IPv6 compatibility for every connectivity, service or products 574 bid. This will encourage the network operators and vendors who 575 don't want to miss out on government related bids to evolve their 576 infrastructure to be IPv6 capable. Any public incentives for 577 technical evolution will be bonded to IPv6 capabilities of the 578 technology itself. In this regard, in the United States, the 579 Office of Management and Budget is calling for an implementation 580 plan to have 80% of the IP-enabled resources on Federal networks 581 be IPv6-only by 2025. If resources cannot be converted, then the 582 Federal agency is required to have a plan to retire them. The 583 Call for Comment is at [US-FR] and [US-CIO]. 585 11. Call for action 587 There are some areas of improvement, that are often mentioned in the 588 literature and during the discussions on IPv6 deployment. This 589 section lists these topics and wants to start a call for action to 590 encourage more investigations on these aspects. 592 11.1. Transition choices 594 From an architectural perspective, a service provider or an 595 enterprise may perceive quite a complex task the transition to IPv6, 596 due to the many technical alternatives available and the changes 597 required in management and operations. Moreover, the choice of the 598 method to support the transition may depend on factors specific to 599 the operator's or the enterprise's context, such as the IPv6 network 600 design that fits the service requirements, the deployment strategy, 601 and the service and network operations. 603 This section briefly highlights the basic approaches that service 604 providers and enterprises may take. The scope is to raise the 605 discussion whether actions may be taken that allow to overcome the 606 issues highlighted and further push the adoption of IPv6. 608 11.1.1. Service providers 610 For a service provider, the IPv6 transition often refers to the 611 service architecture (also referred to as overlay) and not to the 612 network architecture (underlay). IPv6 is introduced at the service 613 layer when a service requiring IPv6-based connectivity is deployed in 614 an IPv4-based network. In this case, as already mentioned in the 615 previous sections, a strategy is based on two stages: IPv6 616 introduction and IPv6-only. 618 For fixed operators, the massive CPE software upgrade to support Dual 619 Stack started in most of service providers network and the traffic 620 percentage is currently between 30% and 40% of IPv6, looking at the 621 global statistics. This is valid for a network operator that 622 provides Dual Stack and gives the same opportunity for end terminal 623 applications to choose freely the path that they want and assuming a 624 normal internet usage. Anyway, it is interesting to see that in the 625 latest years all major content providers have already implemented 626 dual stack access to their services and most of them have implemented 627 IPv6-only in their Data Centers. This aspect could affect the 628 decision on the IPv6 adoption for an operator, but there are also 629 other aspects like the current IPv4 addressing status, CPE costs, 630 CGNAT costs and so on. Most operators already understood the need to 631 adopt IPv6 in their networks and services, and also to promote the 632 diffusion into their clients, while others are still at the edge of a 633 massive implementation decision. Indeed, two situations are 634 possible: 636 Operators that have already employed CGNAT and have introduced 637 IPv6 in their networks, so they remain attached to a Dual Stack 638 architecture. Although IPv6 brought them to a more technological 639 advanced state, CGNAT, on the other end, boosts for some time 640 their ability to supply CPE IPv4 connectivity. 642 Operators with a Dual Stack architecture that have introduced IPv6 643 both in the backbone and for the CPEs, but when reaching the limit 644 in terms of number of IPv4 addresses available, they need to start 645 defining and start to apply a new strategy that can be through 646 CGNAT or with an IPv6-only approach. 648 For mobile operators, the situation is different since they are 649 stretching their IPv4 address space since CGNAT translation levels 650 have been reached and no more IPv4 public pool addresses are 651 available. The new requirements from IoT services, 5G 3GPP release 652 implementations, Voice over Long-Term Evolution (VoLTE) together with 653 the constraints of national regulator lawful interception are seen as 654 major drivers for IPv6. For these reasons, two situations are 655 possible: 657 Some mobile operators choose to implement Dual-Stack as first and 658 immediate mitigation solution. 660 Other mobile operators prefer to move to IPv6-only solution(e.g. 661 464XLAT) since Dual-Stack only mitigates and does not solve 662 completely the IPv4 number scarcity issue. 664 11.1.2. Enterprises 666 The dual stage approach described in the previous sections can be 667 still applicable for enterprises, even if the priorities to apply 668 either stage are different since they have to consider both the 669 internal and external network: 671 It is possible to start with Dual-Stack on hosts/OS and then in 672 client network distribution layer. This allows the IPv6 673 introduction independently since both hosts/OS and client networks 674 belong to the domain of the enterprise. 676 Dual-Stack can be further extended to WAN/campus core/edge 677 routers. Also, as temporary solution, the use of NAT64 is 678 recommended for servers/apps only capable of IPv4. Enterprise 679 Data Center is also to be considered for the IPv6 transition. In 680 this regard the application support needs to be taken into 681 account, even if virtualization should make DCs simpler and more 682 flexible. 684 There are additional challenges also related to the campus network 685 and the cloud interconnection, indeed the networking may be not 686 homogeneous. IPv6 could help to build a flat network by 687 leveraging SD-WAN integration. The perspective of IPv6-only could 688 also ensure better end-to-end performance. 690 Enterprises (private, managed networks) in US and Europe have failed 691 to adopt IPv6, especially on internal networks. Other countries, in 692 particular in Asia, who faced a shortage of IPv4 addresses, have 693 moved somewhat more quickly. But, even there, the large "brick-and- 694 mortar" enterprises find no business reason to adopt IPv6. 696 The enterprise engineers and technicians also don't know how IPv6 697 works. The technicians want to get trained yet the management does 698 not feel that they do not want to pay for such training because they 699 do not see a business need for adoption. This creates an unfortunate 700 cycle where misinformation about the complexity of the IPv6 protocol 701 and unreasonable fears about security and manageability combine with 702 the perceived lack of urgent business needs to prevent adoption of 703 IPv6. 705 In 2019 and 2020, there has been a concerted effort by some grass 706 roots non-profits working with ARIN and APNIC to provide training 707 [ARIN-CG] [ISIF-ASIA-G]. 709 Having said that, some problems such as the problem of application 710 conversion from IPv6 are quite difficult. The reliance of the 711 economic, governmental, and military enterprise organizations on 712 computer applications is great; the number of legacy systems, and 713 ossification at such organizations, is also great. A number of 714 mission-critical computer applications were written in the 1970's. 715 While they have the source code, no one at the enterprise may be 716 familiar with the application nor do they have the funds for external 717 resources. So, transitioning to IPv6 is quite difficult. 719 The problem may be that of "First Mover Disadvantage". 720 Understandably, corporations, having responsibility to their 721 stockholders, have upgraded to new technologies and architectures, 722 such as IPv6, only if it gains them revenue. Thus, legacy programs 723 and technical debt accumulate. 725 11.1.3. Cloud and Data Centers 727 It was already highlighted how CSPs have adopted IPv6 in their 728 internal infrastructure but are also active in gathering IPv4 729 addresses on the transfer market to serve the current business needs 730 of IPv4 connectivity. This is primarily directed to serve the 731 transition to cloud of enterprise's applications. 733 As noted in the previous section, most enterprises do not consider 734 the transition to IPv6 as a priority. To this extent, the use of 735 IPv4-based network services by the CSPs will last. Yet, CSPs are 736 struggling to buy IPv4 addresses. If, in the next years, the 737 scarcity of IPv4 addresses becomes more evident, it is likely that 738 the cost of buying an IPv4 address by a CSP will be charged to an 739 enterprise as a fee. From a financial standpoint this effect might 740 be taken into consideration when evaluating the decision of moving to 741 IPv6. 743 11.1.4. Industrial Internet 745 As the most promising protocol for network applications, IPv6 is 746 frequently mentioned in relation to Internet of Things and Industry 747 4.0. However, its industrial adoption, in particular in smart 748 manufacturing systems, has been much slower than expected. Indeed, 749 it is important to provide an easy way to familiarize system 750 architects and software developers with the IPv6 protocol and its 751 role in the application development life cycle in order to limit the 752 dependency on manual configuration and improve the tool support. 754 It is possible to differentiate types of data and access to 755 understand how and where the IPv6 transition can happen. In the 756 control network, determinism is required with full operational 757 visibility and control, as well as reliability and availability. In 758 monitoring IoT, best effort can be acceptable and low OPEX, zero- 759 touch functions autoconfiguration, zero-configuration. For 760 diagnostics and alerts, trust and transmissions that do not impact 761 the control network are needed. For safety, guarantees in terms of 762 redundancy, latency similar to the control network but with total 763 assurance, is necessary. 765 For IIoT applications, it would be desirable to be able to implement 766 a truly distributed system without dependencies to central components 767 like a DHCP server. In this regard the distributed IIoT applications 768 can leverage the configuration-less characteristic of IPv6 and in 769 this regard all the possible problems and compatibility issues with 770 IPv6 link local addresses, SLAAC (StateLess Address Auto 771 Configuration) needs to be investigated. 773 In addition, it could be interesting to have the ability to use IP 774 based communication and standard application protocols at every point 775 in the production process and further reduce the use of specialized 776 communication systems like PLCs (Programmable Logic Controllers) and 777 fieldbuses for real-time control to subsystems where this is 778 absolutely necessary. 780 11.1.5. Government and Regulators 782 The slogan should be "stimulate if you can, regulate if you must". 783 The global picture shows that the deployment of IPv6 worldwide is not 784 uniform at all [G_stats], [APNIC1]. Countries where either market 785 conditions or local regulators have stimulated the adoption of IPv6 786 show clear sign of growth. 788 As an example, zooming into the European Union area, countries such 789 as Belgium, France and Germany are well ahead in terms of IPv6 790 adoption. The French National Regulator, Arcep, can be considered a 791 good reference of National support to IPv6. [ARCEP] introduced an 792 obligation for the operators awarded with a license to use 5G 793 frequencies (3.4-3.8GHz) in Metropolitan France to be IPv6 794 compatible. As stated, "the goal is to ensure that services are 795 interoperable and to remove obstacles to using services that are only 796 available in IPv6, as the number of devices in use continues to soar, 797 and because the RIPE NCC has run out of IPv4 addresses". A slow 798 adoption of IPv6 could prevent new Internet services to widespread or 799 create a barrier to entry for newcomers to the market. "IPv6 can help 800 to increase competition in the telecom industry, and help to 801 industrialize a country for specific vertical sectors". 803 A renewed industrial policy might be advocated in other countries and 804 regions to stimulate IPv6 adoption. As an example, in the United 805 States, the Office of Management and Budget is also calling for IPv6 806 adoption [US-FR], [US-CIO]. 808 11.2. Network Operations 810 An important factor is represented by the need for training the 811 network operations workforce. Deploying IPv6 requires it as policies 812 and procedures have to be adjusted in order to successfully plan and 813 complete an IPv6 migration. Staff has to be aware of the best 814 practices for managing IPv4 and IPv6 assets. In addition to network 815 nodes, network management applications and equipment need to be 816 properly configured and in same cases also replaced. This may 817 introduce more complexity and costs for the migration. 819 11.3. Performance 821 Despite their relative differences, people tend to compare the 822 performance of IPv6 versus IPv4, even if these differences are not so 823 important for applications. In some cases, IPv6 behaving "worse" 824 than IPv4 tends to re-enforce the justification of not moving towards 825 the full adoption of IPv6. This position is supported when looking 826 at available analytics on two critical parameters: packet loss and 827 latency. These parameters have been constantly monitored over time, 828 but only a few extensive researches and measurement campaigns are 829 currently providing up-to-date information. This paragraph will look 830 briefly at both of them, considering the available measurements. 831 Operators are invited to bring in their experience and enrich the 832 information reported below. 834 11.3.1. IPv6 latency 836 [APNIC5] constantly compares the latency of both address families. 837 Currently, the worldwide average is still in favor of IPv4. Zooming 838 at the country or even at the operator level, it is possible to get 839 more detailed information and appreciate that cases exist where IPv6 840 is faster than IPv4. [APRICOT] highlights how when a difference in 841 performance exists it is often related to asymmetric routing issues. 842 Other possible explanations for a relative latency difference lays on 843 the specificity of the IPv6 header which allows packet fragmentation. 844 In turn, this means that hardware needs to spend cycles to analyze 845 all of the header sections and when it is not capable of handling one 846 of them it drops the packet. Even considering this, a difference in 847 latency stands and sometimes it is perceived as a limiting factor for 848 IPv6. A few measurement campaigns on the behavior of IPv6 in Content 849 Delivery Networks (CDN) are also available [MAPRG-IETF99], [INFOCOM]. 850 The TCP connect time is still higher for IPv6 in both cases, even if 851 the gap has reduced over the analysis time window. 853 11.3.2. IPv6 packet loss 855 [APNIC5] also provides the failure rate of IPv6. Two reports, namely 856 [RIPE1] and [APRICOT], discussed the associated trend, showing how 857 the average worldwide failure rate of IPv6 worsened from around 1.5% 858 in 2016 to a value exceeding 2% in 2020. Reasons for this effect may 859 be found in endpoints with an unreachable IPv6 address, routing 860 instability or firewall behaviours. Yet, this worsening effect may 861 appeae as disturbing for a plain transition to IPv6. Operators are 862 once again invited to share their experience and discuss the 863 performance of IPv6 in their network scenarios. 865 11.3.3. Router's performance 867 It is worth mentioning the aspect of Router's performance too. IPv6 868 is 4 times longer than IPv4 and it is possible to do a simple 869 calculation: the same memory on routers could permit to have 1/4 of 870 different tables (routing, filtering, next hop). Anyway most of the 871 routers showed a remarkably similar throughput and latency for IPv4 872 and IPv6. For smaller software switching platforms, some tests 873 reported a lower throughput for IPv6 compared to IPv4 only in case of 874 smaller packet sizes, while for larger hardware switching platforms 875 there was no throughput variance between IPv6 and IPv4 both at larger 876 frame sizes and at the smaller packet size. 878 11.4. IPv6 security 880 IPv6 presents a number of exciting possibilities for the expanding 881 global Internet, however, there are also noted security challenges 882 associated with the transition to IPv6. [I-D.ietf-opsec-v6] analyzes 883 the operational security issues in several places of a network 884 (enterprises, service providers and residential users). 886 The security aspects have to be considered to keep the same level of 887 security as it exists nowadays in an IPv4-only network environment. 888 The autoconfiguration features of IPv6 will require some more 889 attention for the things going on at the network level. Router 890 discovery and address autoconfiguration may produce unexpected 891 results and security holes. The IPsec protocol implementation has 892 initially been set as mandatory in every node of the network, but 893 then relaxed to recommendation due to extremely constrained hardware 894 deployed in some devices e.g., sensors, Internet of Things (IoT). 896 There are some concerns in terms of the security but, on the other 897 hand, IPv6 offers increased efficiency. There are measurable 898 benefits to IPv6 to notice, like more transparency, improved 899 mobility, and also end to end security (if implemented). 901 As reported in [ISOC], comparing IPv6 and IPv4 at the protocol level, 902 one may probably conclude that the increased complexity of IPv6 903 results in an increased number of attack vectors, that imply more 904 possible ways to perform different types attacks. However, a more 905 interesting and practical question is how IPv6 deployments compare to 906 IPv4 deployments in terms of security. In that sense, there are a 907 number of aspects to consider. 909 Most security vulnerabilities related to network protocols are based 910 on implementation flaws. Typically, security researchers find 911 vulnerabilities in protocol implementations, which eventually are 912 "patched" to mitigate such vulnerabilities. Over time, this process 913 of finding and patching vulnerabilities results in more robust 914 implementations. For obvious reasons, the IPv4 protocols have 915 benefited from the work of security researchers for much longer, and 916 thus IPv4 implementations are generally more robust than IPv6. 918 Besides the intrinsic properties of the protocols, the security level 919 of the resulting deployments is closely related to the level of 920 expertise of network and security engineers. In that sense, there is 921 obviously much more experience and confidence with deploying and 922 operating IPv4 networks than with deploying and operating IPv6 923 networks. 925 Finally, implementation of IPv6 security controls obviously depends 926 on the availability of features in security devices and tools. 927 Whilst there have been improvements in this area, there is a lack of 928 parity in terms of features and/or performance when considering IPv4 929 and IPv6 support in security devices and tools. 931 11.4.1. Protocols security issues 933 It is important to say that IPv6 is not more or less secure than IPv4 934 and the knowledge of the protocol is the best security measure. 936 In general there are security concerns related to IPv6 that can be 937 classified as follows: 939 o Basic IPv6 protocol (Basic header, Extension Headers, Addressing) 941 o IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) 943 o Internet-wide IPv6 security (Filtering, DDoS, Transition 944 Mechanisms) 946 ICMPv6 is an integral part of IPv6 and performs error reporting and 947 diagnostic functions. Since it is used in many IPv6 related 948 protocols, ICMPv6 packet with multicast address should be filtered 949 carefully to avoid attacks. Neighbor Discovery Protocol (NDP) is a 950 node discovery protocol in IPv6 which replaces and enhances functions 951 of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers 952 for discovering multicast listeners on a directly attached link, much 953 like Internet Group Management Protocol (IGMP) is used in IPv4. 955 These IPv6 associated protocols like ICMPv6, NDP and MLD are 956 something new compared to IPv4, so they adds new security threats and 957 the related solutions are still under discussion today. NDP has 958 vulnerabilities [RFC3756] [RFC6583]. The specification says to use 959 IPsec but it is impractical and not used, on the other hand, SEND 960 (SEcure Neighbour Discovery) [RFC3971] is not widely available. 962 [RIPE2] describes the most important threats and solutions regarding 963 IPv6 security. 965 11.4.2. IPv6 Extension Headers and Fragmentation 967 IPv6 Extension Headers imply some issues, in particular their 968 flexibility also means an increased complexity, indeed security 969 devices and software must process the full chain of headers while 970 firewalls must be able to filter based on Extension Headers. 971 Additionally, packets with IPv6 Extension Headers may be dropped in 972 the public Internet. 974 There are some possible attacks through EHs, for example RH0 can be 975 used for traffic amplification over a remote path and it is 976 deprecated. Other attacks based on Extension Headers are based on 977 IPv6 Header Chains and Fragmentation that could be used to bypass 978 filtering, but, to mitigate this effect, Header chain should go only 979 in the first fragment and the use of the IPv6 Fragmentation Header is 980 forbidden in all Neighbor Discovery messages. 982 Fragment Header is used by IPv6 source node to send a packet bigger 983 than path MTU and the Destination host processes fragment headers. 984 There are several threats related to fragmentation to pay attention 985 to e.g. overlapping fragments (not allowed) resource consumption 986 while waiting for last fragment (to discard), atomic fragments (to be 987 isolated). 989 11.4.3. Oversized IPv6 packets 991 A lot of additional functionality has been added to IPv6 primarily by 992 adding Extension Headers and/or using overlay encapsulation. All of 993 the these expand the packet size and this could lead to oversized 994 packets that would be dropped on some links. 996 It is better to investigate the potential problems with oversized 997 packets in the first place. Fragmentation must not be done in 998 transit and a better solution needs to be found, e.g. upgrade all 999 links to bigger MTU or follow specific recommendations at the source 1000 node. 1002 12. Security Considerations 1004 This document has no impact on the security properties of specific 1005 IPv6 protocols or transition tools. The security considerations 1006 relating to the protocols and transition tools are described in the 1007 relevant documents. 1009 13. Contributors 1011 Sebastien Lourdez 1012 Post Luxembourg 1013 Email: sebastien.lourdez@post.lu 1015 14. Acknowledgements 1017 The authors of this document would like to thank Brian Carpenter, 1018 Fred Baker, Jordi Palet Martinez, Alexandre Petrescu, Barbara Stark, 1019 Haisheng Yu(Johnson), Dhruv Dhody, Gabor Lencse, Shuping Peng for 1020 their comments and review of this document. 1022 15. IANA Considerations 1024 This document has no actions for IANA. 1026 16. References 1028 16.1. Normative References 1030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1031 Requirement Levels", BCP 14, RFC 2119, 1032 DOI 10.17487/RFC2119, March 1997, 1033 . 1035 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1036 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1037 May 2017, . 1039 16.2. Informative References 1041 [APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2020, 1042 . 1044 [APNIC2] APNIC2, "Addressing 2020", 2021, 1045 . 1047 [APNIC3] APNIC, "BGP in 2019 - The BGP Table", 2020, 1048 . 1051 [APNIC4] APNIC, "IPv6 in 2020", 2021, 1052 . 1054 [APNIC5] APNIC, "Average RTT Difference (ms) (V6 - V4) for World 1055 (XA)", 2020, . 1057 [APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for 1058 World (XA)", 2020, 1059 . 1062 [ARCEP] ARCEP, "Arcep Decision no 2019-1386, Decision on the terms 1063 and conditions for awarding licences to use frequencies in 1064 the 3.4-3.8GHz band", 2019, 1065 . 1067 [ARIN-CG] ARIN, "Community Grant Program: IPv6 Security, 1068 Applications, and Training for Enterprises", 2020, 1069 . 1071 [CAIR] Cisco, "Cisco Annual Internet Report (2018-2023) White 1072 Paper", 2020, 1073 . 1077 [ETSI-IP6-WhitePaper] 1078 ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, 1079 Benefits, Transition Challenges and the Way Forward", 1080 ISBN 979-10-92620-31-1, 2020. 1082 [G_stats] Google, "Google IPv6 Per-Country IPv6 adoption", 2021, 1083 . 1086 [I-D.ietf-opsec-v6] 1087 Vyncke, E., Kk, C., Kaeo, M., and E. Rey, "Operational 1088 Security Considerations for IPv6 Networks", draft-ietf- 1089 opsec-v6-21 (work in progress), November 2019. 1091 [I-D.lmhp-v6ops-transition-comparison] 1092 Lencse, G., Martinez, J., Howard, L., Patterson, R., and 1093 I. Farrer, "Pros and Cons of IPv6 Transition Technologies 1094 for IPv4aaS", draft-lmhp-v6ops-transition-comparison-06 1095 (work in progress), January 2021. 1097 [IGP-GT] Internet Governance Project, Georgia Tech, "The hidden 1098 standards war: economic factors affecting IPv6 1099 deployment", 2019, . 1103 [INFOCOM] Doan, T., "A Longitudinal View of Netflix: Content 1104 Delivery over IPv6 and Content Cache Deployments", 2020, 1105 . 1108 [ISIF-ASIA-G] 1109 ISIF Asia, "Internet Operations Research Grant: IPv6 1110 Deployment at Enterprises. IIESoc. India", 2020, 1111 . 1113 [ISOC] Internet Society, "IPv6 Security FAQ", 2019, 1114 . 1117 [MAPRG-IETF99] 1118 Bajpai, V., "Measuring YouTube Content Delivery over 1119 IPv6", 2017, . 1123 [POTAROO1] 1124 POTAROO, "Addressing 2020", 2020, 1125 . 1127 [POTAROO2] 1128 POTAROO, "IPv6 Resource Distribution Reports", 2021, 1129 . 1131 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1132 and E. Lear, "Address Allocation for Private Internets", 1133 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1134 . 1136 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1137 Neighbor Discovery (ND) Trust Models and Threats", 1138 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1139 . 1141 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1142 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1143 DOI 10.17487/RFC3971, March 2005, 1144 . 1146 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1147 for IPv6 Hosts and Routers", RFC 4213, 1148 DOI 10.17487/RFC4213, October 2005, 1149 . 1151 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 1152 Scenarios for IPv6 Deployment", RFC 6036, 1153 DOI 10.17487/RFC6036, October 2010, 1154 . 1156 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1157 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1158 DOI 10.17487/RFC6180, May 2011, 1159 . 1161 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1162 Stack Lite Broadband Deployments Following IPv4 1163 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1164 . 1166 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1167 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1168 RFC 6540, DOI 10.17487/RFC6540, April 2012, 1169 . 1171 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1172 Neighbor Discovery Problems", RFC 6583, 1173 DOI 10.17487/RFC6583, March 2012, 1174 . 1176 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1177 Combination of Stateful and Stateless Translation", 1178 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1179 . 1181 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1182 Content Providers and Application Service Providers", 1183 RFC 6883, DOI 10.17487/RFC6883, March 2013, 1184 . 1186 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1187 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1188 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1189 . 1191 [RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, 1192 . 1195 [RIPE2] RIPE, "IPv6 Security", 2019, 1196 . 1199 [US-CIO] The CIO Council, "Memorandum for Heads of Executive 1200 Departments and Agencies. Completing the Transition to 1201 Internet Protocol Version 6 (IPv6)", 2020, 1202 . 1205 [US-FR] Federal Register, "Request for Comments on Updated 1206 Guidance for Completing the Transition to the Next 1207 Generation Internet Protocol, Internet Protocol Version 6 1208 (IPv6)", 2020, . 1213 Appendix A. Summary of Questionnaire and Replies 1215 This Appendix summarizes the questionnaire and the replies received. 1217 1. Do you have plan to move more fixed or mobile or enterprise users 1218 to IPv6 in the next 2 years? 1220 a. If yes, fixed, or mobile, or enterprise? 1222 b. What're the reasons to do so? 1224 c. When to start: already on going, in 12 months, after 12 months? 1226 d. Which transition solution will you use, Dual-Stack, DS-Lite, 1227 464XLAT, MAP-T/E? 1229 2. Do you need to change network devices for the above goal? 1231 a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT? 1233 b. Will you migrate your metro or backbone or backhaul network to 1234 support IPv6? 1236 Some answers below: 1238 Answer 1: (1) Yes, IPv6 migration strategy relies upon the deployment 1239 of Dual Stack architecture. IPv4 service continuity designs is based 1240 on DS-Lite for fixed environments and 464XLAT for mobile 1241 environments. No plans to move towards MAP-E or MAP-T solutions for 1242 the time being. (2) Yes, it's a matter of upgrading CPE, routers 1243 (including BNGs), etc. Tunneling options (ISATAP, TEREDO, 6rd) will 1244 also be used for migration. 1246 Answer 2: (1) Yes, at this moment we widely use IPv6 for mobile 1247 services while we are using DS-Lite for fixed services (FTTH and 1248 DSL). (2) We have no pressure to migrate to native IPv6 forwarding 1249 in the short term and it would represent a significant work without 1250 clear immediate benefit or business rationale. However we may see a 1251 future benefit with SRv6 which may justify in the long term a 1252 migration to native IPv6. 1254 Answer 3: (1) Yes, fixed. The IP depletion topic is crucial, so we 1255 need to speed up the DS-Lite deployment and also Carrier Grade NAT 1256 introduction. (2) Yes, CGNAT introduction. 1258 Answer 4: (1) No, we are rolling IPv6 users back to IPv4. DS-Lite. 1259 (2) No, it was already done. IPv6 works worse than IPv4. it is 1260 immature. 1262 Answer 5: (1) Yes, all 3. Target is Dual-stack for fixed, mobile and 1263 enterprise. (2) Yes, we are adding specific services cards inside our 1264 FTTH equipment for dealing with CGNAT. Metro and backbone are 1265 already Dual Stack. 1267 Answer 6: (1) Yes, Enterprises customer demand is high and the 1268 transition is on going through Dual-Stack. (2) No big plan for 1269 transport network. 1271 Answer 7: No such requirements 1273 Answer 8: (1) Yes, mobile. The Internet APN is not yet enabled for 1274 IPv6, this will be done soon. 464XLAT will be used to save on RFC1918 1275 address space. (2) Yes, PGW; Metro is already IPv6 and Backbone is 1276 currently IPv4/MPLS. No native IPv6 planned as for now. 1278 Answer 9: (1) Yes, Dual-Stack for all 3. Not all services are 1279 available on IPv6. IPv6 adoption has been stated from many years but 1280 still not finished. Dual-Stack is used. (2) No, at the moment it is 1281 6PE solution. No plan to migrate on native IPv6. 1283 Answer 10: (1) Yes, all 3. Ongoing transition with Dual-stack and 1284 464XLAT. (2) No plan for Metro and Backbone. 1286 Answer 11: No such requirements. 1288 Answer 12: (1) Yes, mobile and fixed. To mitigate IPv4 exhaustion in 1289 12 months, Dual-Stack is used. (2) No (hopefully). Managed by 1290 software upgrade. 1292 Answer 13: (1) Yes, on Mobile and Fixed. Mobile: IPv4 exhaustion for 1293 the RAN transport and IPv6 roll out ongoing. Fixed: Enterprises are 1294 requesting IPv6 and also competitors are offering it. Mobile: dual 1295 stack and 6VPE; Enterprise: Dual Stack and 6VPE. (2) No, maybe only a 1296 software upgrade. 1298 Answer 14: (1) Yes, fixed. IPv4 address depletion, on going, Dual- 1299 Stack with NAT444. (2) No. 1301 Answer 15: (1) Yes, Mobile. Running out of private IPv4 address 1302 space and do not want to overlap addresses. Transition on going 1303 through 464XLAT. (2) Not yet, this is not the most pressing concern 1304 at the moment but it is planned. 1306 Answer 16: No, already on Dual-Stack for many years. Discussing 1307 IPv6-only. 1309 Answer 17: (1) Yes, all 3, strategy on going, Dual-Stack, MAP-T. (2) 1310 Yes, CPE, BR Dual-Stack. 1312 Answer 18: (1) Yes, Mobile, due to address deficit. It would be very 1313 likely 464XLAT. (2) It is not clear at the moment. Still under 1314 investigation. CPE, Mobile Core, NAT. For IPv6 native support no 1315 plans for today. 1317 Answer 19: No. Difficult to do it for enterprises, and don't really 1318 care for residential customers. 1320 Answer 20: (1) Yes, fixed, mobile. IP space depletion. Mobile and 1321 Backbone are already done, Fixed is becoming Dual-Stack. (2) Yes, 1322 ordinary CPE and small routers. Some of them needs just software 1323 upgrade. Backbone done, no plan for metro and backhaul. 1325 Answer 21: No such requirements 1327 Answer 22: (1) Yes, mobile, we have few enterprise requests for IPv6; 1328 fixed already Dual-Stack. We are in the exhaustion point in public 1329 IPv4 usage in mobile so we need to move to IPv6 in the terminals. 1330 Dual-Stack deployment is ongoing. (2) No, all devices already support 1331 dual-stack mode. No migration needed. We already support IPv6 1332 forwarding in our backbone. 1334 Answer 23: No, already Dual-Stack 1336 Answer 24: (1) Yes, fixed. DS-Lite. (2) Yes, BNG supporting CGNAT. 1338 Answer 25: (1) Yes, fixed. DS-Lite will be deployed. (2) Yes. 1340 Answer 26: (1) Yes, Mobile (Fixed already Dual-Stack). IPv4 1341 depletion and Business customers are asking for it. Dual-Stack will 1342 be deployed. (2) No. 1344 Answer 27: (1) Yes, Mobile. Dual-Stack is on going. (2) Yes, MBH, 1345 mobile core. 1347 Answer 28: No such requirements. 1349 Answer 29: (1) Yes, fixed and mobile, enterprise is not certain. 1350 IPv4 addressing is not enough, fixed and mobile should be started in 1351 12 months. (2) Telco Cloud, BNG and PEs already support IPv6. 1353 Answer 30: (1) Yes, all 3. Government has pushed. Dual-Stack for 1354 FBB in 12 months. (2) Yes, RGs have not good readiness, but not much 1355 could be done about it. PPPoE access does not create problem in 1356 access and aggregation. BNG should only change configuration. 1358 Answer 31: (1) Yes, mobile for 5G sites. Plan to use IPv6 soon. 6VPE 1359 in the beginning, then migrate to Dual-stack. (2) IP BH devices 1360 already support IPv6. 1362 Answer 32: No. 1364 Answer 33: Yes, Enterprises. We are running short of IPV4 addresses. 1365 In our Internet Core IPV4/IPV6 Dual Stack was already introduced. 1366 The rollout of IPV6 services is slow and we started with business 1367 services. From customer perspective Dual Stack is still a "must 1368 have" and this will be true for many years to come. Another thought 1369 is related to regulatory obligations. Anyway a total switch from 1370 IPv4 to IPv6 will not be possible for many more years. 1372 Answer 34: No, we have no plans to introduce new wave of IPv6 in our 1373 network. 1375 Answer 35: (1) Yes. Fixed, Enterprise. IPv4 addressing is not 1376 enough. Dual Stack deployment is ongoing. (2) Yes, CPE for metro and 1377 backbone. 1379 Answer 36: (1) Yes, Fixed, Enterprise. Dual-Stack. (2) Yes, CPE for 1380 IPv6 service delivery support. 1382 Answer 37: Yes, mobile and enterprise. 6PE is deployed on the PEs, 1383 and dual-stack. The PE supports IPv6 by modifying the live network 1384 configuration or upgrading the software. 1386 Answer 38: Yes, both home broadband and enterprise services support 1387 IPv6. IPv6 services are basic capabilities of communication 1388 networks. Currently 6RD, dual stack (native IPv6) in the future. 1389 The dual-stack feature does not require device changes. The home 1390 gateway is connected to the switch and the BNG. The Dual Stack can 1391 be supported through configuration changes. Both the metro and 1392 backbone networks use MPLS to provide bearer services and do not 1393 require IPv6 capabilities. IPv6 is not enabled on both the metro and 1394 backbone networks. IPv6 services are implemented through 6VPE. 1396 Answer 39: (1) Yes, Enterprises B2B needs more IP addresses. Dual- 1397 Stack is already on going. (2) No, BNG/mobile core and NAT. Metro 1398 and Backbone already support today. 1400 Answer 40: Not for now. 1402 Authors' Addresses 1404 Giuseppe Fioccola 1405 Huawei Technologies 1406 Riesstrasse, 25 1407 Munich 80992 1408 Germany 1410 Email: giuseppe.fioccola@huawei.com 1412 Paolo Volpato 1413 Huawei Technologies 1414 Via Lorenteggio, 240 1415 Milan 20147 1416 Italy 1418 Email: paolo.volpato@huawei.com 1420 Nalini Elkins 1421 Inside Products 1422 36A Upper Circle 1423 Carmel Valley CA 93924 1424 United States of America 1426 Email: nalini.elkins@insidethestack.com 1428 Gyan S. Mishra 1429 Verizon Inc. 1431 Email: gyan.s.mishra@verizon.com 1432 Chongfeng Xie 1433 China Telecom 1435 Email: xiechf.bri@chinatelecom.cn