idnits 2.17.1 draft-vf-v6ops-ipv6-deployment-01.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 seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1263 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 == Outdated reference: A later version (-06) exists of draft-lmhp-v6ops-transition-comparison-05 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 0 errors (**), 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: May 6, 2021 N. Elkins 6 Inside Products 7 S. Lourdez 8 Post Luxembourg 9 November 2, 2020 11 IPv6 Deployment Status 12 draft-vf-v6ops-ipv6-deployment-01 14 Abstract 16 Looking globally, IPv6 is growing faster than IPv4 and this means 17 that the collective wisdom of the networking industry has selected 18 IPv6 for the future. This document provides an overview of IPv6 19 transition deployment status and a view on how the transition to IPv6 20 is progressing among network operators that are introducing IPv6 or 21 have already adopted an IPv6-only solution. It also aims to analyze 22 the transition challenges and therefore encourage actions and more 23 investigations on some areas that are still under discussion. The 24 overall IPv6 incentives are also examined. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 6, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. The global picture of IPv6 . . . . . . . . . . . . . . . . . 4 68 2.1. IPv6 users . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. IPv6 allocations and networks . . . . . . . . . . . . . . 5 70 3. Survey among Network Operators . . . . . . . . . . . . . . . 6 71 4. Considerations for Enterprises . . . . . . . . . . . . . . . 7 72 5. IPv6 deployments worldwide . . . . . . . . . . . . . . . . . 7 73 5.1. IPv6 service design for Mobile, Fixed broadband and 74 enterprises . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1.1. IPv6 introduction . . . . . . . . . . . . . . . . . . 7 76 5.1.2. IPv6-only service delivery . . . . . . . . . . . . . 8 77 6. Findings of the IPv6 Survey . . . . . . . . . . . . . . . . . 9 78 7. IPv6 incentives . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. Call for action . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Transition choices . . . . . . . . . . . . . . . . . . . 11 81 8.1.1. Service providers . . . . . . . . . . . . . . . . . . 12 82 8.1.2. Enterprises . . . . . . . . . . . . . . . . . . . . . 13 83 8.2. Network Operations . . . . . . . . . . . . . . . . . . . 14 84 8.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 14 85 8.3.1. IPv6 latency . . . . . . . . . . . . . . . . . . . . 14 86 8.3.2. IPv6 packet loss . . . . . . . . . . . . . . . . . . 15 87 8.3.3. Router's performance . . . . . . . . . . . . . . . . 15 88 8.4. IPv6 security . . . . . . . . . . . . . . . . . . . . . . 15 89 8.4.1. Protocols security issues . . . . . . . . . . . . . . 16 90 8.4.2. IPv6 Extension Headers and Fragmentation . . . . . . 17 91 8.4.3. Oversized IPv6 packets . . . . . . . . . . . . . . . 17 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 13.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Appendix A. Summary of Questionnaire and Replies . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 The focus of this document is to provide a survey of the deployed 105 IPv6 transition technologies and to highlight the difficulties in the 106 transition. This process helps to understand what is missing and how 107 to improve the current IPv6 deployment strategies of the network 108 operators and enterprises. The objective is to give an updated view 109 of the practices and plans already described in [RFC6036]. The scope 110 is to report the current IPv6 status and encourage actions and more 111 investigations on some areas that are still under discussion as well 112 as the main incentives for the IPv6 adoption. 114 [RFC6180] discussed the IPv6 deployment models and migration tools. 115 [RFC6036] described the Service Provider Scenarios for IPv6 116 Deployment, [RFC7381] introduced the guidelines of the IPv6 117 deployment for Enterprise and [RFC6883] provided guidance and 118 suggestions for Internet Content Providers and Application Service 119 Providers. On the other hand, this document focuses on the end-to- 120 end services and in particular on the device - network - content 121 communication chain. 123 [ETSI-IP6-WhitePaper] reported the IPv6 Best Practices, Benefits, 124 Transition Challenges and the Way Forward. IPv6 is becoming a 125 priority again and a new wave of IPv6 deployment is expected, due the 126 exhaustion of the IPv4 address space since 2010, in addition 127 technologies like 5G, cloud, IoT require its use, governments and 128 standard bodies (including IETF) demand it, and the device - network 129 - content communication chain is calling for its adoption. In this 130 regard it is possible to mention the IAB Statement on IPv6 stating 131 that "IETF will stop requiring IPv4 compatibility in new or extended 132 protocols". 134 The following sections give the global picture of IPv6 to show how 135 IPv6 is growing faster than IPv4 worldwide in all measures including 136 number of users, percentage of content, and amount of traffic. This 137 testifies that the key Internet industry players have decided 138 strategically to invest and deploy IPv6 in large-scale to sustain the 139 Internet growth. 141 Then it is presented the survey among network operators about the 142 IPv6 deployment and the considerations that have come out. IPv6 143 transition solutions for Mobile BroadBand (MBB), Fixed BroadBand 144 (FBB) and enterprise services are ready. Dual-Stack is the most 145 deployed solution for IPv6 introduction, while 464XLAT and Dual Stack 146 Lite (DS-Lite) seem the most suitable for IPv6-only service delivery. 148 Finally, The IPv6 incentives are presented but the general IPv6 149 challenges are also reported in particular in relation to 150 Architecture, Operations, Performance and Security issues. These 151 considerations aim to start a call for action on the areas of 152 improvement, that are often mentioned as reason for not deploying 153 IP6. 155 2. The global picture of IPv6 157 The utilization of IPv6 has been monitored by many agencies and 158 institutions worldwide. Different analytics have been made 159 available, ranging from the number of IPv6 users, its relative 160 utilization over the Internet, to the number of carriers able to 161 route IPv6 network prefixes. [ETSI-IP6-WhitePaper] provided several 162 of those analytics. The scope of this section then is to summarize 163 the status of the IPv6 adoption, so to get an indication of the 164 relevance of IPv6 today. For the analytics listed here, the trend 165 over the past five years is given, expressed as the Compound Annual 166 Growth Rate (CAGR). In general, this shows how IPv6 has grown in the 167 past few years, and that is growing faster than IPv4. 169 2.1. IPv6 users 171 [ETSI-IP6-WhitePaper] provided the main statistics about the 172 utilization of IPv6 worldwide and references the organizations that 173 make their measurement publicly available through their web sites. 174 To give a rough estimation of the relative growth of IPv6, the next 175 table shows the total number of estimated IPv6 users at January 2020 176 as measured by [APNIC1]. 178 +--------+------+-------+-------+--------+--------+--------+--------+ 179 | | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 180 | | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 181 +--------+------+-------+-------+--------+--------+--------+--------+ 182 | World | 74.24| 179.42| 290.68| 513.68 | 574.02 | 989.25 | 67.9% | 183 +--------+------+-------+-------+--------+--------+--------+--------+ 185 Figure 1: IPv6 users worldwide (in millions) 187 2.2. IPv6 allocations and networks 189 Regional Internet Registries (RIRs) are responsible for assigning an 190 IPv6 address block to ISPs or enterprises. An ISP will use the 191 assigned block to provide addresses to their end users. For example, 192 a mobile carrier will assign one or several /64 prefixes to the end 193 users. Several analytics are available for the RIRs. The next table 194 shows the amount of individual allocations, per RIR, in the time 195 period 2015-2019 [APNIC2]. 197 +---------+------+-------+-------+-------+-------+-----------+------+ 198 | Registry| Jan | Jan | Jan | Jan | Jan | Cumulated | CAGR | 199 | | 2015 | 2016 | 2017 | 2018 | 2019 | | | 200 +---------+------+-------+-------+-------+-------+-----------+------+ 201 | AFRINIC | 86 | 116 | 112 | 110 | 115 | 539 | 58% | 202 | APNIC | 778 | 1,681 | 1,369 | 1,474 | 1,484 | 6,786 | 72% | 203 | ARIN | 602 | 646 | 684 | 658 | 605 | 3,195 | 52% | 204 | LACNIC | 1,061| 1,010 | 1,549 | 1,450 | 1,618 | 6,688 | 58% | 205 | RIPE | 2,206| 2,141 | 2,051 | 2,617 | 3,105 | 12,120 | 53% | 206 | | | | | | | | | 207 | Total | 4,733| 5,594 | 5,765 | 6,309 | 6,927 | 29,328 | 58% | 208 +---------+------+-------+-------+-------+-------+-----------+------+ 210 Figure 2: IPv6 allocations worldwide 212 [APNIC2] also compares the number of allocations for both address 213 families, and the result is in favor of IPv6. The average yearly 214 growth is 58% for IPv6 in the period 2015-2019 versus 47% for IPv4, a 215 sign that IPv6 is growing bigger than IPv4. This is described in the 216 next table. 218 +--------+-------+------+------+--------+--------+-----------+------+ 219 | Address| Jan | Jan | Jan | Jan | Jan | Cumulated | CAGR | 220 | family | 2015 | 2016 | 2017 | 2018 | 2019 | | | 221 +--------+-------+------+------+--------+--------+-----------+------+ 222 | IPv6 | 4,733 | 5,594| 5,765| 6,309 | 6,927 | 29,328 | 58% | 223 | | | | | | | | | 224 | IPv4 | 11,732| 9,787| 9,440| 10,199 | 14,033 | 55,191 | 47% | 225 | | | | | | | | | 226 +--------+-------+------+------+--------+--------+-----------+------+ 228 Figure 3: Allocations per address family 230 The next table is based on [POTAROO] and shows the percentage of ASes 231 supporting IPv6 compared to the total ASes worldwide. The number of 232 IPv6-capable ASes increases from 21.1% in January 2015 to 27.5% in 233 January 2020. This equals to 15.19% CAGR for IPv6 enabled networks. 234 This also shows that the number of networks supporting IPv6 is 235 growing faster than the ones supporting IPv4, since the total (IPv6 236 and IPv4) networks grow at 9.23% CAGR. 238 +------------+-------+-------+-------+-------+-------+-------+------+ 239 | Advertised | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 240 | ASN | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 241 +------------+-------+-------+-------+-------+-------+-------+------+ 242 |IPv6-capable| 9,182 | 10,744| 12,663| 14,506| 16,440| 18,623|15.19%| 243 | | | | | | | | | 244 | Total ASN | 43,543| 44,549| 44,368| 60,281| 63,782| 67,713| 9.23%| 245 | | | | | | | | | 246 | Ratio | 21.1% | 24.1% | 28.5% | 24.1% | 25.8% | 27.5% | | 247 +------------+-------+-------+-------+-------+-------+-------+------+ 249 Figure 4: Percentage of IPv6-capable ASes 251 3. Survey among Network Operators 253 It was started an IPv6 poll to more than 50 network operators about 254 the status of IPv6 deployment. This poll reveals that more than 30 255 operators will migrate fixed and mobile users to IPv6 in next 2 256 years. The IPv6 Poll has been submitted in particular to network 257 operators considering that, as showed by the previous section, both 258 user devices and contents seem more ready for IPv6. The answers to 259 the questionnaire can be found in Appendix. 261 The main Questions asked are: 263 * Do you plan to move more fixed or mobile or enterprise users to 264 IPv6 (e.g. Dual-Stack) or IPv6-only in the next 2 years? What 265 are the reasons to do so? Which transition solution will you use, 266 Dual-Stack, DS-Lite, 464XLAT, MAP-T/E? 268 * Do you need to change network devices for the above goal? Will 269 you migrate your metro or backbone or backhaul network to support 270 IPv6? 272 The result of this questionnaire highlights that major IPv6 migration 273 will happen in next 2 years. Dual Stack is always the most adopted 274 solution and the transition to IPv6-only is motivated in particular 275 by business reasons like the 5G and IoT requirements. In addition it 276 is worth mentioning that the migration of transport network (metro 277 and backbone) is not considered a priority today for many network 278 operators and the focus is in particular on the end to end IPv6 279 services. 281 More details about the answers received can be found in the Appendix. 283 4. Considerations for Enterprises 285 As described in [RFC7381], enterprises face different challenges than 286 operators. The overall problem for many enterprises is to handle 287 IPv6-based connectivity to the upstream providers, while supporting a 288 mixed IPv4/IPv6 domain in the internal network. 290 The business reasons for IPv6 is unique to each enterprise especially 291 for the internal network. But the most common drivers are on the 292 external network due to the fact that when Internet service 293 providers, run out of IPv4 addresses, they will provide native IPv6 294 and non-native IPv4. So for client networks trying to reach 295 enterprise networks, the IPv6 experience will be better than the 296 transitional IPv4 if the enterprise deploys IPv6 in its public-facing 297 services. 299 5. IPv6 deployments worldwide 301 This section reports the most deployed approaches for the IPv6 302 migration in MBB, FBB and enterprise. 304 5.1. IPv6 service design for Mobile, Fixed broadband and enterprises 306 The consolidated strategy, as also described in 307 [ETSI-IP6-WhitePaper], is based on two stages, namely: (1) IPv6 308 introduction, and (2) IPv6-only. The first stage aims at delivering 309 the service in a controlled manner, where the traffic volume of 310 IPv6-based services is minimal. When the service conditions change, 311 e.g. when the traffic grows beyond a certain threshold, then the 312 move to the second stage may occur. In this latter case, the service 313 is delivered solely on IPv6. 315 5.1.1. IPv6 introduction 317 In order to enable the deployment of an IPv6 service over an underlay 318 IPv4 architecture, there are two possible approaches: 320 o Enabling Dual-Stack at the CPE 322 o Tunneling IPv6 traffic over IPv4, e.g. with 6rd. 324 So, from a technical perspective, the first stage is based on Dual- 325 Stack [RFC4213] or tunnel-based mechanisms such as Generic Routing 326 Encapsulation (GRE), IPv6 Rapid Deployment (6rd), Connection of IPv6 327 Domains via IPv4 Clouds (6to4), and others. 329 Dual-Stack [RFC4213] is more robust, and easier to troubleshoot and 330 support. Based on information provided by operators with the answers 331 to the poll (see Appendix A), it can be stated that Dual-Stack is 332 currently the most widely deployed IPv6 solution, for MBB, FBB and 333 enterprises, accounting for about 50% of all IPv6 deployments, see 334 both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper]. 335 Therefore, for operators that are willing to introduce IPv6 the most 336 common approach is to apply the Dual-Stack transition solution. 338 With Dual-Stack, IPv6 can be introduced together with other network 339 upgrade and many parts of network management and IT systems can still 340 work in IPv4. This avoids major upgrade of such systems to support 341 IPv6, which is possibly the most difficult task in IPv6 transition. 342 In other words, the cost and effort on the network management and IT 343 system upgrade are moderate. The benefits are to start to 344 accommodate future services and save the NAT costs. 346 The CPE has only an IPv6 address at the WAN side and uses an IPv6 347 connection to the operator gateway, e.g. Broadband Network Gateway 348 (BNG) or Packet Gateway (PGW) / User Plane Function (UPF). However, 349 the hosts and content servers can still be IPv4 and/or IPv6. For 350 example, NAT64 can enable IPv6 hosts to access IPv4 servers. The 351 backbone network underlay can also be IPv4 or IPv6. 353 Although the Dual-Stack IPv6 transition is a good solution to be 354 followed in the IPv6 introduction stage, it does have few 355 disadvantages in the long run, like the duplication of the network 356 resources and states, as well as other limitations for network 357 operation. For this reason, when IPv6 increases to a certain limit, 358 it would be better to switch to the IPv6-only stage. 360 5.1.2. IPv6-only service delivery 362 The second stage, named here IPv6-only, can be a complex decision 363 that depends on several factors, such as economic factors, policy and 364 government regulation. 366 [I-D.lmhp-v6ops-transition-comparison] discusses and compares the 367 technical merits of the most common transition solutions for 368 IPv6-only service delivery, 464XLAT, DS-lite, Lightweight 4over6 369 (lw4o6), MAP-E, and MAP-T, but without providing an explicit 370 recommendation. As the poll highlights, the most widely deployed 371 IPv6 transition solution for MBB is 464XLAT and for FBB is DS-Lite. 373 Based on the survey among network operators in Appendix A it is 374 possible to analyze the IPv6 transition technologies that are already 375 deployed or that will be deployed. The different answers to the 376 questionnaire and in particular [ETSI-IP6-WhitePaper] reported 377 detailed statistics on that and it can be stated that, besides Dual- 378 Stack, the most widely deployed IPv6 transition solution for MBB is 379 464XLAT [RFC6877], and for FBB is DS-Lite [RFC6333], both of which 380 are IPv6-only solutions. 382 Looking at the different feedback from network operators, in some 383 cases, even when using private addresses, such as 10.0.0.0/8 space 384 [RFC1918], the address pool is not large enough, e.g. for large 385 mobile operators or large Data Centers (DCs), Dual-Stack is not 386 enough, because it still requires IPv4 addresses to be assigned. 387 Also, Dual-Stack will likely lead to duplication of several network 388 operations both in IPv6 and IPv4 and this increases the amount of 389 state information in the network with a waste of resources. For this 390 reason, in some scenarios (e.g. MBB or DCs) IPv6-only stage could be 391 more efficient from the start since the IPv6 introduction phase with 392 Dual-Stack may consume more resources (for example CGNAT costs). 394 So, in general, it is possible to state that, when the Dual-Stack 395 disadvantages outweigh the IPv6-only complexity, it makes sense to 396 migrate to IPv6-only. Some network operators already started this 397 process, while others are still waiting. 399 6. Findings of the IPv6 Survey 401 Global IPv4 address depletion is reported by most network operators 402 as the important driver for IPv6 deployment. Indeed, the main reason 403 for IPv6 deployment given is related to the run out of private 404 10.0.0.0/8 space [RFC1918]. 5G and IoT service deployment is another 405 incentive not only for business reasons but also for the need of more 406 addresses. 408 The answers in Appendix shows that the IPv6 deployment strategy is 409 based mainly on Dual Stack architecture and most of the network 410 operators are migrating or plan to migrate in the next few years. 411 The main motivation is related to the depletion of IPv4 addresses and 412 to save the NAT costs. 414 It is interesting to see that most of the network operators have no 415 big plans to migrate transport network (metro and backbone) soon, 416 since they do not see business reasons. It seems that there is no 417 pressure to migrate to native IPv6 forwarding in the short term, 418 anyway the future benefit of IPv6 may justify in the long term a 419 migration to native IPv6. Some network operators also said that a 420 software upgrade can be enough to support IPv6 where it is needed for 421 now. 423 This survey demonstrates that full replacement of IPv4 will take long 424 time. Indeed the transition to IPv6 has different impacts and 425 requirements depending on the network segment: 427 o It is possible to say that almost all mobile devices are already 428 IPv6 capable while for fixed access most of the CPEs are Dual 429 Stack. Data Centers are also evolving and deploying IPv6 to cope 430 with the increasing demand of cloud services. 432 o While the access network seems not strongly impacted because it is 433 mainly based on layer 2 traffic, regarding Edge and BNG, most 434 network operators that provide IPv6 connectivity runs BNG devices 435 in Dual Stack in order to distribute both IPv4 and IPv6. 437 o For Metro and Backbone, the trend is to keep MPLS Data Plane and 438 run IPv6/IPv4 over PE devices at the border. All MPLS services 439 can be guaranteed in IPv6 as well through 6PE/6VPE protocols. 441 In this scenario it is clear that the complete deployment of a full 442 IPv6 data plane will take more time. If we look at the long term 443 evolution, IPv6 can bring other advantages like introducing advanced 444 protocols developed only on IPv6 (e.g. SRv6) to implement all the 445 controlled SLA services aimed by the 5G technology and beyond. 447 7. IPv6 incentives 449 It is possible to state that IPv6 adoption is no longer optional, 450 indeed there are several incentives for the IPv6 deployment: 452 Technical incentives: all Internet technical standard bodies and 453 network equipment vendors have endorsed IPv6 and view it as the 454 standards-based solution to the IPv4 address shortage. The IETF, 455 as well as other SDOs, need to ensure that their standards do not 456 assume IPv4. The IAB expects that the IETF will stop requiring 457 IPv4 compatibility in new or extended protocols. Future IETF 458 protocol work will then optimize for and depend on IPv6. It is 459 recommended that all networking standards assume the use of IPv6 460 and be written so they do not require IPv4 ([RFC6540]). In 461 addition, every Internet registry worldwide strongly recommends 462 immediate IPv6 adoption. 464 Business incentives: with the emergence of new digital 465 technologies, such as 5G, IOT and Cloud, new use cases have come 466 into being and posed more new requirements for IPv6 deployment. 467 Over time, numerous technical and economic stop-gap measures have 468 been developed in an attempt to extend the lifetime of IPv4, but 469 all of these measures add cost and complexity to network 470 infrastructure and raise significant barriers to innovation. It 471 is widely recognized that full transition to IPv6 is the only 472 viable option to ensure future growth and innovation in Internet 473 technology and services. Several large networks and Data Centers 474 have already evolved their internal infrastructures to be 475 IPv6-only. Forward looking large corporations are also working 476 toward migrating their enterprise networks to IPv6-only 477 environments. 479 Governments incentives: governments have a huge responsibility in 480 promoting IPv6 deployment within their countries. There are 481 example of governments already adopting policies to encourage IPv6 482 utilization or enforce increased security on IPv4. So, even 483 without funding the IPv6 transition, governments can recommend to 484 add IPv6 compatibility for every connectivity, service or products 485 bid. This will encourage the network operators and vendors who 486 don't want to miss out on government related bids to evolve their 487 infrastructure to be IPv6 capable. Any public incentives for 488 technical evolution will be bonded to IPv6 capabilities of the 489 technology itself. In this regard, in the United States, the 490 Office of Management and Budget is calling for an implementation 491 plan to have 80% of the IP-enabled resources on Federal networks 492 be IPv6-only by 2025. If resources cannot be converted, then the 493 Federal agency is required to have a plan to retire them. The 494 Call for Comment is at [US-FR] and [US-CIO]. 496 8. Call for action 498 There are some areas of improvement, that are often mentioned in the 499 literature and during the discussions on IPv6 deployment. This 500 section lists these topics and wants to start a call for action to 501 encourage more investigations on these aspects. 503 8.1. Transition choices 505 From an architectural perspective, a service provider or an 506 enterprise may perceive quite a complex task the transition to IPv6, 507 due to the many technical alternatives available and the changes 508 required in management and operations. Moreover, the choice of the 509 method to support the transition may depend on factors specific to 510 the operator's or the enterprise's context, such as the IPv6 network 511 design that fits the service requirements, the deployment strategy, 512 and the service and network operations. 514 This section briefly highlights the basic approaches that service 515 providers and enterprises may take. The scope is to raise the 516 discussion whether actions may be taken that allow to overcome the 517 issues highlighted and further push the adoption of IPv6. 519 8.1.1. Service providers 521 For a service provider, the IPv6 transition often refers to the 522 service architecture (also referred to as overlay) and not to the 523 network architecture (underlay). IPv6 is introduced at the service 524 layer when a service requiring IPv6-based connectivity is deployed in 525 an IPv4-based network. In this case, as already mentioned in the 526 previous sections, a strategy is based on two stages: IPv6 527 introduction and IPv6-only. 529 For fixed operators, the massive CPE software upgrade to support Dual 530 Stack started in most of service providers network and the traffic 531 percentage is currently between 30% and 40% of IPv6, looking at the 532 global statistics. This is valid for a network operator that 533 provides Dual Stack and gives the same opportunity for end terminal 534 applications to choose freely the path that they want and assuming a 535 normal internet usage. Anyway, it is interesting to see that in the 536 latest years all major content providers have already implemented 537 dual stack access to their services and most of them have implemented 538 IPv6-only in their Data Centers. This aspect could affect the 539 decision on the IPv6 adoption for an operator, but there are also 540 other aspects like the current IPv4 addressing status, CPE costs, 541 CGNAT costs and so on. Most operators already understood the need to 542 adopt IPv6 in their networks and services, and also to promote the 543 diffusion into their clients, while others are still at the edge of a 544 massive implementation decision. Indeed, two situations are 545 possible: 547 Operators that have already employed CGNAT and have introduced 548 IPv6 in their networks, so they remain attached to a Dual Stack 549 architecture. Although IPv6 brought them to a more technological 550 advanced state, CGNAT, on the other end, boosts for some time 551 their ability to supply CPE IPv4 connectivity. 553 Operators with a Dual Stack architecture that have introduced IPv6 554 both in the backbone and for the CPEs, but when reaching the limit 555 in terms of number of IPv4 addresses available, they need to start 556 defining and start to apply a new strategy that can be through 557 CGNAT or with an IPv6-only approach. 559 For mobile operators, the situation is different since they are 560 stretching their IPv4 address space since CGNAT translation levels 561 have been reached and no more IPv4 public pool addresses are 562 available. The new requirements from IoT services, 5G 3GPP release 563 implementations, Voice over Long-Term Evolution (VoLTE) together with 564 the constraints of national regulator lawful interception are seen as 565 major drivers for IPv6. For these reasons, two situations are 566 possible: 568 Some mobile operators choose to implement Dual-Stack as first and 569 immediate mitigation solution. 571 Other mobile operators prefer to move to IPv6-only solution(e.g. 572 464XLAT) since Dual-Stack only mitigates and does not solve 573 completely the IPv4 number scarcity issue. 575 8.1.2. Enterprises 577 The dual stage approach described in the previous sections may be 578 still applicable for enterprises, even if the priorities to apply 579 either stage are different since they have to consider both the 580 internal and external network. 582 Enterprises (private, managed networks) in US and Europe have failed 583 to adopt IPv6, especially on internal networks. Other countries, in 584 particular in Asia, who faced a shortage of IPv4 addresses, have 585 moved somewhat more quickly. But, even there, the large "brick-and- 586 mortar" enterprises find no business reason to adopt IPv6. 588 The enterprise engineers and technicians also don't know how IPv6 589 works. The technicians want to get trained yet the management does 590 not feel that they do not want to pay for such training because they 591 do not see a business need for adoption. This creates an unfortunate 592 cycle where misinformation about the complexity of the IPv6 protocol 593 and unreasonable fears about security and manageability combine with 594 the perceived lack of urgent business needs to prevent adoption of 595 IPv6. 597 In 2019 and 2020, there has been a concerted effort by some grass 598 roots non-profits working with ARIN and APNIC to provide training 599 [ARIN-CG] [ISIF-ASIA-G]. 601 Having said that, some problems such as the problem of application 602 conversion from IPv6 are quite difficult. The reliance of the 603 economic, governmental, and military enterprise organizations on 604 computer applications is great; the number of legacy systems, and 605 ossification at such organizations, is also great. A number of 606 mission-critical computer applications were written in the 1970's. 607 While they have the source code, no one at the enterprise may be 608 familiar with the application nor do they have the funds for external 609 resources. So, transitioning to IPv6 is quite difficult. 611 The problem may be that of "First Mover Disadvantage". 612 Understandably, corporations, having responsibility to their 613 stockholders, have upgraded to new technologies and architectures, 614 such as IPv6, only if it gains them revenue. Thus, legacy programs 615 and technical debt accumulate. 617 8.2. Network Operations 619 An important factor is represented by the need for training the 620 network operations workforce. Deploying IPv6 requires it as policies 621 and procedures have to be adjusted in order to successfully plan and 622 complete an IPv6 migration. Staff has to be aware of the best 623 practices for managing IPv4 and IPv6 assets. In addition to network 624 nodes, network management applications and equipment need to be 625 properly configured and in same cases also replaced. This may 626 introduce more complexity and costs for the migration. 628 8.3. Performance 630 Despite their relative differences, people tend to compare the 631 performance of IPv6 versus IPv4, even if these differences are not so 632 important for applications. In some cases, IPv6 behaving "worse" 633 than IPv4 tends to re-enforce the justification of not moving towards 634 the full adoption of IPv6. This position is supported when looking 635 at available analytics on two critical parameters: packet loss and 636 latency. These parameters have been constantly monitored over time, 637 but only a few extensive researches and measurement campaigns are 638 currently providing up-to-date information. This paragraph will look 639 briefly at both of them, considering the available measurements. 640 Operators are invited to bring in their experience and enrich the 641 information reported below. 643 8.3.1. IPv6 latency 645 [APNIC3] constantly compares the latency of both address families. 646 Currently, the worldwide average is still in favor of IPv4. Zooming 647 at the country or even at the operator level, it is possible to get 648 more detailed information and appreciate that cases exist where IPv6 649 is faster than IPv4. [APRICOT] highlights how when a difference in 650 performance exists it is often related to asymmetric routing issues. 651 Other possible explanations for a relative latency difference lays on 652 the specificity of the IPv6 header which allows packet fragmentation. 653 In turn, this means that hardware needs to spend cycles to analyze 654 all of the header sections and when it is not capable of handling one 655 of them it drops the packet. Even considering this, a difference in 656 latency stands and sometimes it is perceived as a limiting factor for 657 IPv6. A few measurement campaigns on the behavior of IPv6 in Content 658 Delivery Networks (CDN) are also available [MAPRG-IETF99], [INFOCOM]. 660 The TCP connect time is still higher for IPv6 in both cases, even if 661 the gap has reduced over the analysis time window. 663 8.3.2. IPv6 packet loss 665 [APNIC3] also provides the failure rate of IPv6. Two reports, namely 666 [RIPE1] and [APRICOT], discussed the associated trend, showing how 667 the average worldwide failure rate of IPv6 worsened from around 1.5% 668 in 2016 to a value exceeding 2% in 2020. Reasons for this effect may 669 be found in endpoints with an unreachable IPv6 address, routing 670 instability or firewall behaviours. Yet, this worsening effect may 671 appeae as disturbing for a plain transition to IPv6. Operators are 672 once again invited to share their experience and discuss the 673 performance of IPv6 in their network scenarios. 675 8.3.3. Router's performance 677 It is worth mentioning the aspect of Router's performance too. IPv6 678 is 4 times longer than IPv4 and it is possible to do a simple 679 calculation: the same memory on routers could permit to have 1/4 of 680 different tables (routing, filtering, next hop). Anyway most of the 681 routers showed a remarkably similar throughput and latency for IPv4 682 and IPv6. For smaller software switching platforms, some tests 683 reported a lower throughput for IPv6 compared to IPv4 only in case of 684 smaller packet sizes, while for larger hardware switching platforms 685 there was no throughput variance between IPv6 and IPv4 both at larger 686 frame sizes and at the smaller packet size. 688 8.4. IPv6 security 690 IPv6 presents a number of exciting possibilities for the expanding 691 global Internet, however, there are also noted security challenges 692 associated with the transition to IPv6. [I-D.ietf-opsec-v6] analyzes 693 the operational security issues in several places of a network 694 (enterprises, service providers and residential users). 696 The security aspects have to be considered to keep the same level of 697 security as it exists nowadays in an IPv4-only network environment. 698 The autoconfiguration features of IPv6 will require some more 699 attention for the things going on at the network level. Router 700 discovery and address autoconfiguration may produce unexpected 701 results and security holes. The IPsec protocol implementation has 702 initially been set as mandatory in every node of the network, but 703 then relaxed to recommendation due to extremely constrained hardware 704 deployed in some devices e.g., sensors, Internet of Things (IoT). 706 There are some concerns in terms of the security but, on the other 707 hand, IPv6 offers increased efficiency. There are measurable 708 benefits to IPv6 to notice, like more transparency, improved 709 mobility, and also end to end security (if implemented). 711 As reported in [ISOC], comparing IPv6 and IPv4 at the protocol level, 712 one may probably conclude that the increased complexity of IPv6 713 results in an increased number of attack vectors, that imply more 714 possible ways to perform different types attacks. However, a more 715 interesting and practical question is how IPv6 deployments compare to 716 IPv4 deployments in terms of security. In that sense, there are a 717 number of aspects to consider. 719 Most security vulnerabilities related to network protocols are based 720 on implementation flaws. Typically, security researchers find 721 vulnerabilities in protocol implementations, which eventually are 722 "patched" to mitigate such vulnerabilities. Over time, this process 723 of finding and patching vulnerabilities results in more robust 724 implementations. For obvious reasons, the IPv4 protocols have 725 benefited from the work of security researchers for much longer, and 726 thus IPv4 implementations are generally more robust than IPv6. 728 Besides the intrinsic properties of the protocols, the security level 729 of the resulting deployments is closely related to the level of 730 expertise of network and security engineers. In that sense, there is 731 obviously much more experience and confidence with deploying and 732 operating IPv4 networks than with deploying and operating IPv6 733 networks. 735 Finally, implementation of IPv6 security controls obviously depends 736 on the availability of features in security devices and tools. 737 Whilst there have been improvements in this area, there is a lack of 738 parity in terms of features and/or performance when considering IPv4 739 and IPv6 support in security devices and tools. 741 8.4.1. Protocols security issues 743 It is important to say that IPv6 is not more or less secure than IPv4 744 and the knowledge of the protocol is the best security measure. 746 In general there are security concerns related to IPv6 that can be 747 classified as follows: 749 o Basic IPv6 protocol (Basic header, Extension Headers, Addressing) 751 o IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) 753 o Internet-wide IPv6 security (Filtering, DDoS, Transition 754 Mechanisms) 756 ICMPv6 is an integral part of IPv6 and performs error reporting and 757 diagnostic functions. Since it is used in many IPv6 related 758 protocols, ICMPv6 packet with multicast address should be filtered 759 carefully to avoid attacks. Neighbor Discovery Protocol (NDP) is a 760 node discovery protocol in IPv6 which replaces and enhances functions 761 of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers 762 for discovering multicast listeners on a directly attached link, much 763 like Internet Group Management Protocol (IGMP) is used in IPv4. 765 These IPv6 associated protocols like ICMPv6, NDP and MLD are 766 something new compared to IPv4, so they adds new security threats and 767 the related solutions are still under discussion today. NDP has 768 vulnerabilities [RFC3756] [RFC6583]. The specification says to use 769 IPsec but it is impractical and not used, on the other hand, SEND 770 (SEcure Neighbour Discovery) [RFC3971] is not widely available. 772 [RIPE2] describes the most important threats and solutions regarding 773 IPv6 security. 775 8.4.2. IPv6 Extension Headers and Fragmentation 777 IPv6 Extension Headers imply some issues, in particular their 778 flexibility also means an increased complexity, indeed security 779 devices and software must process the full chain of headers while 780 firewalls must be able to filter based on Extension Headers. 781 Additionally, packets with IPv6 Extension Headers may be dropped in 782 the public Internet. 784 There are some possible attacks through EHs, for example RH0 can be 785 used for traffic amplification over a remote path and it is 786 deprecated. Other attacks based on Extension Headers are based on 787 IPv6 Header Chains and Fragmentation that could be used to bypass 788 filtering, but, to mitigate this effect, Header chain should go only 789 in the first fragment and the use of the IPv6 Fragmentation Header is 790 forbidden in all Neighbor Discovery messages. 792 Fragment Header is used by IPv6 source node to send a packet bigger 793 than path MTU and the Destination host processes fragment headers. 794 There are several threats related to fragmentation to pay attention 795 to e.g. overlapping fragments (not allowed) resource consumption 796 while waiting for last fragment (to discard), atomic fragments (to be 797 isolated). 799 8.4.3. Oversized IPv6 packets 801 A lot of additional functionality has been added to IPv6 primarily by 802 adding Extension Headers and/or using overlay encapsulation. All of 803 the these expand the packet size and this could lead to oversized 804 packets that would be dropped on some links. 806 It is better to investigate the potential problems with oversized 807 packets in the first place. Fragmentation must not be done in 808 transit and a better solution needs to be found, e.g. upgrade all 809 links to bigger MTU or follow specific recommendations at the source 810 node. 812 9. Security Considerations 814 This document has no impact on the security properties of specific 815 IPv6 protocols or transition tools. The security considerations 816 relating to the protocols and transition tools are described in the 817 relevant documents. 819 10. Contributors 821 TBC 823 11. Acknowledgements 825 TBC 827 12. IANA Considerations 829 This document has no actions for IANA. 831 13. References 833 13.1. Normative References 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, 837 DOI 10.17487/RFC2119, March 1997, 838 . 840 13.2. Informative References 842 [APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2020, 843 . 845 [APNIC2] APNIC2, "Addressing 2019", 2020, 846 . 848 [APNIC3] APNIC, "Average RTT Difference (ms) (V6 - V4) for World 849 (XA)", 2020, . 851 [APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for 852 World (XA)", 2020, 853 . 856 [ARIN-CG] ARIN, "Community Grant Program: IPv6 Security, 857 Applications, and Training for Enterprises", 2020, 858 . 860 [ETSI-IP6-WhitePaper] 861 ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, 862 Benefits, Transition Challenges and the Way Forward", 863 ISBN 979-10-92620-31-1, 2020. 865 [I-D.ietf-opsec-v6] 866 Vyncke, E., Kk, C., Kaeo, M., and E. Rey, "Operational 867 Security Considerations for IPv6 Networks", draft-ietf- 868 opsec-v6-21 (work in progress), November 2019. 870 [I-D.lmhp-v6ops-transition-comparison] 871 Lencse, G., Martinez, J., Howard, L., Patterson, R., and 872 I. Farrer, "Pros and Cons of IPv6 Transition Technologies 873 for IPv4aaS", draft-lmhp-v6ops-transition-comparison-05 874 (work in progress), July 2020. 876 [INFOCOM] Doan, T., "A Longitudinal View of Netflix: Content 877 Delivery over IPv6 and Content Cache Deployments", 2020, 878 . 881 [ISIF-ASIA-G] 882 ISIF Asia, "Internet Operations Research Grant: IPv6 883 Deployment at Enterprises. IIESoc. India", 2020, 884 . 886 [ISOC] Internet Society, "IPv6 Security FAQ", 2019, 887 . 890 [MAPRG-IETF99] 891 Bajpai, V., "Measuring YouTube Content Delivery over 892 IPv6", 2017, . 896 [POTAROO] POTAROO, "IPv6 / IPv4 Comparative Statistics", 2020, 897 . 899 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 900 and E. Lear, "Address Allocation for Private Internets", 901 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 902 . 904 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 905 Neighbor Discovery (ND) Trust Models and Threats", 906 RFC 3756, DOI 10.17487/RFC3756, May 2004, 907 . 909 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 910 "SEcure Neighbor Discovery (SEND)", RFC 3971, 911 DOI 10.17487/RFC3971, March 2005, 912 . 914 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 915 for IPv6 Hosts and Routers", RFC 4213, 916 DOI 10.17487/RFC4213, October 2005, 917 . 919 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 920 Scenarios for IPv6 Deployment", RFC 6036, 921 DOI 10.17487/RFC6036, October 2010, 922 . 924 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 925 Transition Mechanisms during IPv6 Deployment", RFC 6180, 926 DOI 10.17487/RFC6180, May 2011, 927 . 929 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 930 Stack Lite Broadband Deployments Following IPv4 931 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 932 . 934 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 935 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 936 RFC 6540, DOI 10.17487/RFC6540, April 2012, 937 . 939 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 940 Neighbor Discovery Problems", RFC 6583, 941 DOI 10.17487/RFC6583, March 2012, 942 . 944 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 945 Combination of Stateful and Stateless Translation", 946 RFC 6877, DOI 10.17487/RFC6877, April 2013, 947 . 949 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 950 Content Providers and Application Service Providers", 951 RFC 6883, DOI 10.17487/RFC6883, March 2013, 952 . 954 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 955 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 956 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 957 . 959 [RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, 960 . 963 [RIPE2] RIPE, "IPv6 Security", 2019, 964 . 967 [US-CIO] The CIO Council, "Memorandum for Heads of Executive 968 Departments and Agencies. Completing the Transition to 969 Internet Protocol Version 6 (IPv6)", 2020, 970 . 973 [US-FR] Federal Register, "Request for Comments on Updated 974 Guidance for Completing the Transition to the Next 975 Generation Internet Protocol, Internet Protocol Version 6 976 (IPv6)", 2020, . 981 Appendix A. Summary of Questionnaire and Replies 983 This Appendix summarizes the questionnaire and the replies received. 985 1. Do you have plan to move more fixed or mobile or enterprise users 986 to IPv6 in the next 2 years? 988 a. If yes, fixed, or mobile, or enterprise? 990 b. What're the reasons to do so? 991 c. When to start: already on going, in 12 months, after 12 months? 993 d. Which transition solution will you use, Dual-Stack, DS-Lite, 994 464XLAT, MAP-T/E? 996 2. Do you need to change network devices for the above goal? 998 a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT? 1000 b. Will you migrate your metro or backbone or backhaul network to 1001 support IPv6? 1003 Some answers below: 1005 Answer 1: (1) Yes, IPv6 migration strategy relies upon the deployment 1006 of Dual Stack architecture. IPv4 service continuity designs is based 1007 on DS-Lite for fixed environments and 464XLAT for mobile 1008 environments. No plans to move towards MAP-E or MAP-T solutions for 1009 the time being. (2) Yes, it's a matter of upgrading CPE, routers 1010 (including BNGs), etc. Tunneling options (ISATAP, TEREDO, 6rd) will 1011 also be used for migration. 1013 Answer 2: (1) Yes, at this moment we widely use IPv6 for mobile 1014 services while we are using DS-Lite for fixed services (FTTH and 1015 DSL). (2) We have no pressure to migrate to native IPv6 forwarding 1016 in the short term and it would represent a significant work without 1017 clear immediate benefit or business rationale. However we may see a 1018 future benefit with SRv6 which may justify in the long term a 1019 migration to native IPv6. 1021 Answer 3: (1) Yes, fixed. The IP depletion topic is crucial, so we 1022 need to speed up the DS-Lite deployment and also Carrier Grade NAT 1023 introduction. (2) Yes, CGNAT introduction. 1025 Answer 4: (1) No, we are rolling IPv6 users back to IPv4. DS-Lite. 1026 (2) No, it was already done. IPv6 works worse than IPv4. it is 1027 immature. 1029 Answer 5: (1) Yes, all 3. Target is Dual-stack for fixed, mobile and 1030 enterprise. (2) Yes, we are adding specific services cards inside our 1031 FTTH equipment for dealing with CGNAT. Metro and backbone are 1032 already Dual Stack. 1034 Answer 6: (1) Yes, Enterprises customer demand is high and the 1035 transition is on going through Dual-Stack. (2) No big plan for 1036 transport network. 1038 Answer 7: No such requirements 1039 Answer 8: (1) Yes, mobile. The Internet APN is not yet enabled for 1040 IPv6, this will be done soon. 464XLAT will be used to save on RFC1918 1041 address space. (2) Yes, PGW; Metro is already IPv6 and Backbone is 1042 currently IPv4/MPLS. No native IPv6 planned as for now. 1044 Answer 9: (1) Yes, Dual-Stack for all 3. Not all services are 1045 available on IPv6. IPv6 adoption has been stated from many years but 1046 still not finished. Dual-Stack is used. (2) No, at the moment it is 1047 6PE solution. No plan to migrate on native IPv6. 1049 Answer 10: (1) Yes, all 3. Ongoing transition with Dual-stack and 1050 464XLAT. (2) No plan for Metro and Backbone. 1052 Answer 11: No such requirements. 1054 Answer 12: (1) Yes, mobile and fixed. To mitigate IPv4 exhaustion in 1055 12 months, Dual-Stack is used. (2) No (hopefully). Managed by 1056 software upgrade. 1058 Answer 13: (1) Yes, on Mobile and Fixed. Mobile: IPv4 exhaustion for 1059 the RAN transport and IPv6 roll out ongoing. Fixed: Enterprises are 1060 requesting IPv6 and also competitors are offering it. Mobile: dual 1061 stack and 6VPE; Enterprise: Dual Stack and 6VPE. (2) No, maybe only a 1062 software upgrade. 1064 Answer 14: (1) Yes, fixed. IPv4 address depletion, on going, Dual- 1065 Stack with NAT444. (2) No. 1067 Answer 15: (1) Yes, Mobile. Running out of private IPv4 address 1068 space and do not want to overlap addresses. Transition on going 1069 through 464XLAT. (2) Not yet, this is not the most pressing concern 1070 at the moment but it is planned. 1072 Answer 16: No, already on Dual-Stack for many years. Discussing 1073 IPv6-only. 1075 Answer 17: (1) Yes, all 3, strategy on going, Dual-Stack, MAP-T. (2) 1076 Yes, CPE, BR Dual-Stack. 1078 Answer 18: (1) Yes, Mobile, due to address deficit. It would be very 1079 likely 464XLAT. (2) It is not clear at the moment. Still under 1080 investigation. CPE, Mobile Core, NAT. For IPv6 native support no 1081 plans for today. 1083 Answer 19: No. Difficult to do it for enterprises, and don't really 1084 care for residential customers. 1086 Answer 20: (1) Yes, fixed, mobile. IP space depletion. Mobile and 1087 Backbone are already done, Fixed is becoming Dual-Stack. (2) Yes, 1088 ordinary CPE and small routers. Some of them needs just software 1089 upgrade. Backbone done, no plan for metro and backhaul. 1091 Answer 21: No such requirements 1093 Answer 22: (1) Yes, mobile, we have few enterprise requests for IPv6; 1094 fixed already Dual-Stack. We are in the exhaustion point in public 1095 IPv4 usage in mobile so we need to move to IPv6 in the terminals. 1096 Dual-Stack deployment is ongoing. (2) No, all devices already support 1097 dual-stack mode. No migration needed. We already support IPv6 1098 forwarding in our backbone. 1100 Answer 23: No, already Dual-Stack 1102 Answer 24: (1) Yes, fixed. DS-Lite. (2) Yes, BNG supporting CGNAT. 1104 Answer 25: (1) Yes, fixed. DS-Lite will be deployed. (2) Yes. 1106 Answer 26: (1) Yes, Mobile (Fixed already Dual-Stack). IPv4 1107 depletion and Business customers are asking for it. Dual-Stack will 1108 be deployed. (2) No. 1110 Answer 27: (1) Yes, Mobile. Dual-Stack is on going. (2) Yes, MBH, 1111 mobile core. 1113 Answer 28: No such requirements. 1115 Answer 29: (1) Yes, fixed and mobile, enterprise is not certain. 1116 IPv4 addressing is not enough, fixed and mobile should be started in 1117 12 months. (2) Telco Cloud, BNG and PEs already support IPv6. 1119 Answer 30: (1) Yes, all 3. Government has pushed. Dual-Stack for 1120 FBB in 12 months. (2) Yes, RGs have not good readiness, but not much 1121 could be done about it. PPPoE access does not create problem in 1122 access and aggregation. BNG should only change configuration. 1124 Answer 31: (1) Yes, mobile for 5G sites. Plan to use IPv6 soon. 6VPE 1125 in the beginning, then migrate to Dual-stack. (2) IP BH devices 1126 already support IPv6. 1128 Answer 32: No. 1130 Answer 33: Yes, Enterprises. We are running short of IPV4 addresses. 1131 In our Internet Core IPV4/IPV6 Dual Stack was already introduced. 1132 The rollout of IPV6 services is slow and we started with business 1133 services. From customer perspective Dual Stack is still a "must 1134 have" and this will be true for many years to come. Another thought 1135 is related to regulatory obligations. Anyway a total switch from 1136 IPv4 to IPv6 will not be possible for many more years. 1138 Answer 34: No, we have no plans to introduce new wave of IPv6 in our 1139 network. 1141 Answer 35: (1) Yes. Fixed, Enterprise. IPv4 addressing is not 1142 enough. Dual Stack deployment is ongoing. (2) Yes, CPE for metro and 1143 backbone. 1145 Answer 36: (1) Yes, Fixed, Enterprise. Dual-Stack. (2) Yes, CPE for 1146 IPv6 service delivery support. 1148 Answer 37: Yes, mobile and enterprise. 6PE is deployed on the PEs, 1149 and dual-stack. The PE supports IPv6 by modifying the live network 1150 configuration or upgrading the software. 1152 Answer 38: Yes, both home broadband and enterprise services support 1153 IPv6. IPv6 services are basic capabilities of communication 1154 networks. Currently 6RD, dual stack (native IPv6) in the future. 1155 The dual-stack feature does not require device changes. The home 1156 gateway is connected to the switch and the BNG. The Dual Stack can 1157 be supported through configuration changes. Both the metro and 1158 backbone networks use MPLS to provide bearer services and do not 1159 require IPv6 capabilities. IPv6 is not enabled on both the metro and 1160 backbone networks. IPv6 services are implemented through 6VPE. 1162 Answer 39: (1) Yes, Enterprises B2B needs more IP addresses. Dual- 1163 Stack is already on going. (2) No, BNG/mobile core and NAT. Metro 1164 and Backbone already support today. 1166 Answer 40: Not for now. 1168 Authors' Addresses 1170 Giuseppe Fioccola 1171 Huawei Technologies 1172 Riesstrasse, 25 1173 Munich 80992 1174 Germany 1176 Email: giuseppe.fioccola@huawei.com 1177 Paolo Volpato 1178 Huawei Technologies 1179 Via Lorenteggio, 240 1180 Milan 20147 1181 Italy 1183 Email: paolo.volpato@huawei.com 1185 Nalini Elkins 1186 Inside Products 1187 36A Upper Circle 1188 Carmel Valley CA 93924 1189 United States of America 1191 Email: nalini.elkins@insidethestack.com 1193 Sebastien Lourdez 1194 Post Luxembourg 1196 Email: sebastien.lourdez@post.lu