idnits 2.17.1 draft-vf-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 seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2020) is 1282 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: April 18, 2021 October 15, 2020 7 IPv6 Transition Deployment Status 8 draft-vf-v6ops-ipv6-deployment-00 10 Abstract 12 Looking globally, IPv6 is growing faster than IPv4 and this means 13 that the collective wisdom of the networking industry has selected 14 IPv6 for the future. This document provides an overview of IPv6 15 transition deployment status and a view on how the transition to IPv6 16 is progressing among network operators that are introducing IPv6 or 17 have already adopted an IPv6-only solution. It also aims to analyze 18 the transition challenges and therefore encourage actions and more 19 investigations on some areas that are still under discussion. The 20 overall IPv6 incentives are also examined. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 18, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. The global picture of IPv6 . . . . . . . . . . . . . . . . . 4 64 2.1. IPv6 connectivity . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Number of IPv6 users . . . . . . . . . . . . . . . . . . 5 66 2.3. Web sites supporting IPv6 . . . . . . . . . . . . . . . . 6 67 2.4. Regional Internet Registries' Allocations . . . . . . . . 6 68 2.5. Networks supporting IPv6 . . . . . . . . . . . . . . . . 7 69 3. Survey among Network Operators . . . . . . . . . . . . . . . 8 70 4. IPv6 deployments worldwide . . . . . . . . . . . . . . . . . 9 71 4.1. IPv6 service design for Mobile, Fixed broadband and 72 enterprises . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.1. IPv6 introduction . . . . . . . . . . . . . . . . . . 9 74 4.1.2. IPv6-only service delivery . . . . . . . . . . . . . 10 75 5. Considerations coming out of IPv6 deployments . . . . . . . . 11 76 6. IPv6 incentives . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Call for action . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. Transition choices . . . . . . . . . . . . . . . . . . . 13 79 7.1.1. Service providers . . . . . . . . . . . . . . . . . . 13 80 7.1.2. Enterprises . . . . . . . . . . . . . . . . . . . . . 13 81 7.2. Network Operations . . . . . . . . . . . . . . . . . . . 13 82 7.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.3.1. IPv6 latency . . . . . . . . . . . . . . . . . . . . 14 84 7.3.2. IPv6 packet loss . . . . . . . . . . . . . . . . . . 14 85 7.4. IPv6 security . . . . . . . . . . . . . . . . . . . . . . 15 86 7.4.1. Protocols security issues . . . . . . . . . . . . . . 16 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 12.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Appendix A. Summary of Questionnaire and Replies . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 The focus of this document is to provide a survey of the deployed 100 IPv6 transition technologies and to highlight the difficulties in the 101 transition. This process helps to understand what is missing and how 102 to improve the current IPv6 deployment strategies of the network 103 operators and enterprises. The objective is to give an updated view 104 of the practices and plans already described in [RFC6036]. The scope 105 is to report the current IPv6 status and encourage actions and more 106 investigations on some areas that are still under discussion as well 107 as the main incentives for the IPv6 adoption. 109 [RFC6180] discussed the IPv6 deployment models and migration tools. 110 [RFC6036] described the Service Provider Scenarios for IPv6 111 Deployment, [RFC7381] introduced the guidelines of the IPv6 112 deployment for Enterprise and [RFC6883] provided guidance and 113 suggestions for Internet Content Providers and Application Service 114 Providers. On the other hand, this document focuses on the end-to- 115 end services and in particular on the device - network - content 116 communication chain. 118 [ETSI-IP6-WhitePaper] reported the IPv6 Best Practices, Benefits, 119 Transition Challenges and the Way Forward. IPv6 is becoming a 120 priority again and a new wave of IPv6 deployment is expected, due the 121 exhaustion of the IPv4 address space since 2010, in addition 122 technologies like 5G, cloud, IoT require its use, governments and 123 standard bodies (including IETF) demand it, and the device - network 124 - content communication chain is calling for its adoption. In this 125 regard it is possible to mention the IAB Statement on IPv6 stating 126 that "IETF will stop requiring IPv4 compatibility in new or extended 127 protocols". 129 The following sections give the global picture of IPv6 to show how 130 IPv6 is growing faster than IPv4 worldwide in all measures including 131 number of users, percentage of content, and amount of traffic. This 132 testifies that the key Internet industry players have decided 133 strategically to invest and deploy IPv6 in large-scale to sustain the 134 Internet growth. 136 Then it is presented the survey among network operators about the 137 IPv6 deployment and the considerations that have come out. IPv6 138 transition solutions for Mobile BroadBand (MBB), Fixed BroadBand 139 (FBB) and enterprise services are ready. Dual-Stack is the most 140 deployed solution for IPv6 introduction, while 464XLAT and Dual Stack 141 Lite (DS-Lite) seem the most suitable for IPv6-only service delivery. 143 Finally, The IPv6 incentives are presented but the general IPv6 144 challenges are also reported in particular in relation to 145 Architecture, Operations, Performance and Security issues. These 146 considerations aim to start a call for action on the areas of 147 improvement, that are often mentioned as reason for not deploying 148 IP6. 150 2. The global picture of IPv6 152 The utilization of IPv6 has been monitored by many agencies and 153 institutions worldwide. Different analytics have been made 154 available, ranging from the number of IPv6 users, its relative 155 utilization over the Internet, to the number of carriers able to 156 route IPv6 network prefixes. The scope of this section then is to 157 provide a glance at the status of the IPv6 adoption, so to get an 158 indication of the relevance of IPv6 today. For each analytic listed 159 in the next subsections the trend over the past five years is given, 160 expressed as the Compound Annual Growth Rate (CAGR). In general, 161 this shows how IPv6 has grown in the past few years, and that is 162 growing faster than IPv4. 164 2.1. IPv6 connectivity 166 Some OTTs and Internet Registries keep track of the utilization of 167 IPv6 worldwide, collecting the number of end points (IPv6 addresses) 168 that access their servers. The following table show the percentage 169 of IPv6 connections as collected and reported by [APNIC1], 170 [FACEBOOK], and [GOOGLE] in the period January 1, 2015 to January 1, 171 2020. It has to be noted that [FACEBOOK] started their collection in 172 September, 2017. As such, January, 2018 is the first data point 173 reported in the table. For each data set, the relative CAGR shows 174 how steady the IPv6 growth results. 176 +---------+------+-------+-------+-------+--------+--------+--------+ 177 | Source | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 178 | | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 179 +---------+------+-------+-------+-------+--------+--------+--------+ 180 | APNIC | 3.13 | 5.51% | 8.05% | 16.83 | 20.11% | 24.58% | 51.01% | 181 | | % | | | % | | | | 182 | Faceboo | N/A | N/A | N/A | 18.35 | 23.66% | 26.24% | 19.58% | 183 | k | | | | % | | | | 184 | Google | 5.84 | 10.41 | 16.51 | 21.84 | 26.32% | 30.16% | 38.87% | 185 | | % | % | % | % | | | | 186 +---------+------+-------+-------+-------+--------+--------+--------+ 188 Table 1: IPv6 connectivity percentage 190 The next table also shows the relative increase of IPv6 connections 191 as measured by [AKAMAI] on their platforms over the last five years. 192 The percentage is expressed as the number of hits generated by IPv6 193 users over the total hits. For the sake of conciseness, only a few 194 examples are reported. 196 +----------+-------+-------+-------+-------+--------+--------+------+ 197 | Source | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 198 | | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 199 +----------+-------+-------+-------+-------+--------+--------+------+ 200 | Reliance | 6.7% | 10.7% | 73.2% | 84.0% | 86.3% | 87.0% | 67% | 201 | (IN) | | | | | | | | 202 | ATT | 20.9% | 40.0% | 49.0% | 59.6% | 68.4% | 67.7% | 26% | 203 | (USA) | | | | | | | | 204 | Softbank | 2.1% | 11.2% | 20.9% | 28.7% | 40.8% | 45.8% | 85% | 205 | (JP) | | | | | | | | 206 +----------+-------+-------+-------+-------+--------+--------+------+ 208 Table 2: IPv6 connectivity percentage - Operators 210 2.2. Number of IPv6 users 212 The analytics provided by [APNIC1] also give an estimation on the 213 number of IPv6 users worldwide, which is constantly increasing. The 214 next table shows the growth for the five economies with the highest 215 numbers of IPv6 users at January 2020 as well as the estimation of 216 the total IPv6 users worldwide. 218 +--------+------+-------+-------+--------+--------+--------+--------+ 219 | Countr | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 220 | y | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 221 +--------+------+-------+-------+--------+--------+--------+--------+ 222 | India | 0.10 | 4.27 | 61.99 | 227.22 | 250.10 | 360.74 | 413.7% | 223 | USA | 31.9 | 84.80 | 95.15 | 109.86 | 122.79 | 137.31 | 33.9% | 224 | | 1 | | | | | | | 225 | China | 4.12 | 4.52 | 4.87 | 2.84 | 8.32 | 130.10 | 99.5% | 226 | Brazil | 0.14 | 9.77 | 12.84 | 26.42 | 32.87 | 50.48 | 226.9% | 227 | Japan | 10.4 | 18.43 | 17.11 | 27.56 | 28.98 | 40.86 | 31.2% | 228 | | 9 | | | | | | | 229 | World | 74.2 | 179.4 | 290.6 | 513.68 | 574.02 | 989.25 | 67.9% | 230 | | 4 | 2 | 8 | | | | | 231 +--------+------+-------+-------+--------+--------+--------+--------+ 233 Table 3: IPv6 users worldwide (in millions) 235 2.3. Web sites supporting IPv6 237 The progression of IPv6 web sites on the global Internet is shown in 238 the next table, as reported by [W3TECHS] 240 +---------+-------+-------+-------+--------+--------+--------+------+ 241 | Country | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 242 | | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 243 +---------+-------+-------+-------+--------+--------+--------+------+ 244 | Servers | 5.2% | 6.1% | 9.6% | 11.4% | 13.3% | 15.0% | 24% | 245 +---------+-------+-------+-------+--------+--------+--------+------+ 247 Table 4: IPv6 web servers worldwide 249 As explained by [W3TECHS], the statistic above refers to the whole 250 Internet and includes all sizes of providers, businesses and 251 enterprises. As such, it has to be noted that the biggest OTTs and 252 Content Providers host a large amount of servers which are actually 253 counted as one single website. The relative percentage of IPv6 254 capable servers would be much higher, as these players alone provide 255 a big portion of the contents accessed every day by the Internet 256 community. 258 2.4. Regional Internet Registries' Allocations 260 Regional Internet Registries (RIRs) are responsible for assigning an 261 IPv6 address block to ISPs or enterprises. An ISP will use the 262 assigned block to provide addresses to their end users. For example, 263 a mobile carrier will assign one or several /64 prefixes to the end 264 users. Several analytics are available for the RIRs. The next table 265 shows the amount of individual allocations, per RIR, in the time 266 period 2015-2019 [APNIC2]. 268 +---------+------+-------+-------+-------+-------+-----------+------+ 269 | Registr | Jan | Jan | Jan | Jan | Jan | Cumulated | CAGR | 270 | y | 2015 | 2016 | 2017 | 2018 | 2019 | | | 271 +---------+------+-------+-------+-------+-------+-----------+------+ 272 | AFRINIC | 86 | 116 | 112 | 110 | 115 | 539 | 58% | 273 | APNIC | 778 | 1,681 | 1,369 | 1,474 | 1,484 | 6,786 | 72% | 274 | ARIN | 602 | 646 | 684 | 658 | 605 | 3,195 | 52% | 275 | LACNIC | 1,06 | 1,010 | 1,549 | 1,450 | 1,618 | 6,688 | 58% | 276 | | 1 | | | | | | | 277 | RIPE | 2,20 | 2,141 | 2,051 | 2,617 | 3,105 | 12,120 | 53% | 278 | | 6 | | | | | | | 279 | Total | 4,73 | 5,594 | 5,765 | 6,309 | 6,927 | 29,328 | 58% | 280 | | 3 | | | | | | | 281 +---------+------+-------+-------+-------+-------+-----------+------+ 283 Table 5: IPv6 web servers worldwide 285 [APNIC2] also compares the number of allocations for both address 286 families, and the result is in favor of IPv6. The average yearly 287 growth is 58% for IPv6 in the period 2015-2019 versus 47% for IPv4, a 288 sign that IPv6 is growing bigger than IPv4. This is described in the 289 next table. 291 +--------+-------+------+------+--------+--------+-----------+------+ 292 | Addres | Jan | Jan | Jan | Jan | Jan | Cumulated | CAGR | 293 | s | 2015 | 2016 | 2017 | 2018 | 2019 | | | 294 | family | | | | | | | | 295 +--------+-------+------+------+--------+--------+-----------+------+ 296 | IPv6 | 4,733 | 5,59 | 5,76 | 6,309 | 6,927 | 29,328 | 58% | 297 | | | 4 | 5 | | | | | 298 | IPv4 | 11,73 | 9,78 | 9,44 | 10,199 | 14,033 | 55,191 | 47% | 299 | | 2 | 7 | 0 | | | | | 300 +--------+-------+------+------+--------+--------+-----------+------+ 302 Table 6: Allocations per address family 304 2.5. Networks supporting IPv6 306 The next table is based on [POTAROO] and shows the percentage of ASes 307 supporting IPv6 compared to the total ASes worldwide. The number of 308 IPv6-capable ASes increases from 21.1% in January 2015 to 27.5% in 309 January 2020. This equals to 15.19% CAGR for IPv6 enabled networks. 310 This also shows that the number of networks supporting IPv6 is 311 growing faster than the ones supporting IPv4, since the total (IPv6 312 and IPv4) networks grow at 9.23% CAGR. 314 +-----------+-------+-------+-------+-------+-------+-------+-------+ 315 | Advertise | Jan | Jan | Jan | Jan | Jan | Jan | CAGR | 316 | d ASN | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | | 317 +-----------+-------+-------+-------+-------+-------+-------+-------+ 318 | IPv6-capa | 9,182 | 10,74 | 12,66 | 14,50 | 16,44 | 18,62 | 15.19 | 319 | ble | | 4 | 3 | 6 | 0 | 3 | % | 320 | Total ASN | 43,54 | 44,54 | 44,36 | 60,28 | 63,78 | 67,71 | 9.23% | 321 | | 3 | 9 | 8 | 1 | 2 | 3 | | 322 | Ratio | 21.1% | 24.1% | 28.5% | 24.1% | 25.8% | 27.5% | | 323 +-----------+-------+-------+-------+-------+-------+-------+-------+ 325 Table 7: IPv6 web servers worldwide 327 3. Survey among Network Operators 329 It was started an IPv6 poll to more than 50 network operators about 330 the status of IPv6 deployment. This poll reveals that more than 30 331 operators will migrate fixed and mobile users to IPv6 in next 2 332 years. The IPv6 Poll has been submitted in particular to network 333 operators considering that, as showed by the previous section, both 334 user devices and contents seem more ready for IPv6. The answers to 335 the questionnaire can be found in Appendix. 337 The main Questions asked are: 339 * Do you plan to move more fixed or mobile or enterprise users to 340 IPv6 (e.g. Dual-Stack) or IPv6-only in the next 2 years? What 341 are the reasons to do so? Which transition solution will you use, 342 Dual-Stack, DS-Lite, 464XLAT, MAP-T/E? 344 * Do you need to change network devices for the above goal? Will 345 you migrate your metro or backbone or backhaul network to support 346 IPv6? 348 The result of this questionnaire highlights that major IPv6 migration 349 will happen in next 2 years. Dual Stack is always the most adopted 350 solution and the transition to IPv6-only is motivated in particular 351 by business reasons like the 5G and IoT requirements. In addition it 352 is worth mentioning that the migration of transport network (metro 353 and backbone) is not considered a priority today for many network 354 operators and the focus is in particular on the end to end IPv6 355 services. 357 More details about the answers received can be found in the Appendix. 359 4. IPv6 deployments worldwide 361 This section reports the most deployed approaches for the IPv6 362 migration in MBB, FBB and enterprise. 364 4.1. IPv6 service design for Mobile, Fixed broadband and enterprises 366 The consolidated strategy, as also described in 367 [ETSI-IP6-WhitePaper], is based on two stages, namely: (1) IPv6 368 introduction, and (2) IPv6-only. The first stage aims at delivering 369 the service in a controlled manner, where the traffic volume of 370 IPv6-based services is minimal. When the service conditions change, 371 e.g. when the traffic grows beyond a certain threshold, then the 372 move to the second stage may occur. In this latter case, the service 373 is delivered solely on IPv6. 375 4.1.1. IPv6 introduction 377 In order to enable the deployment of an IPv6 service over an underlay 378 IPv4 architecture, there are two possible approaches: 380 o Enabling Dual-Stack at the CPE 382 o Tunneling IPv6 traffic over IPv4, e.g. with 6rd. 384 So, from a technical perspective, the first stage is based on Dual- 385 Stack [RFC4213] or tunnel-based mechanisms such as Generic Routing 386 Encapsulation (GRE), IPv6 Rapid Deployment (6rd), Connection of IPv6 387 Domains via IPv4 Clouds (6to4), and others. 389 Dual-Stack [RFC4213] is more robust, and easier to troubleshoot and 390 support. Based on information provided by operators with the answers 391 to the poll (see Appendix A), it can be stated that Dual-Stack is 392 currently the most widely deployed IPv6 solution, for MBB, FBB and 393 enterprises, accounting for about 50% of all IPv6 deployments, see 394 both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper]. 395 Therefore, for operators that are willing to introduce IPv6 the most 396 common approach is to apply the Dual-Stack transition solution. 398 With Dual-Stack, IPv6 can be introduced together with other network 399 upgrade and many parts of network management and IT systems can still 400 work in IPv4. This avoids major upgrade of such systems to support 401 IPv6, which is possibly the most difficult task in IPv6 transition. 402 In other words, the cost and effort on the network management and IT 403 system upgrade are moderate. The benefits are to start to 404 accommodate future services and save the NAT costs. 406 The CPE has only an IPv6 address at the WAN side and uses an IPv6 407 connection to the operator gateway, e.g. Broadband Network Gateway 408 (BNG) or Packet Gateway (PGW) / User Plane Function (UPF). However, 409 the hosts and content servers can still be IPv4 and/or IPv6. For 410 example, NAT64 can enable IPv6 hosts to access IPv4 servers. The 411 backbone network underlay can also be IPv4 or IPv6. 413 Although the Dual-Stack IPv6 transition is a good solution to be 414 followed in the IPv6 introduction stage, it does have few 415 disadvantages in the long run, like the duplication of the network 416 resources, as well as other limitations for network operation. For 417 this reason, when IPv6 increases to a certain limit, it would be 418 better to switch to the IPv6-only stage. 420 4.1.2. IPv6-only service delivery 422 The second stage, named here IPv6-only, can be a complex decision 423 that depends on several factors, such as economic factors, policy and 424 government regulation. 426 [I-D.lmhp-v6ops-transition-comparison] discusses and compares the 427 technical merits of the most common transition solutions for 428 IPv6-only service delivery, 464XLAT, DS-lite, Lightweight 4over6 429 (lw4o6), MAP-E, and MAP-T, but without providing an explicit 430 recommendation. As the poll highlights, the most widely deployed 431 IPv6 transition solution for MBB is 464XLAT and for FBB is DS-Lite. 433 Based on the survey among network operators in Appendix A it is 434 possible to analyze the IPv6 transition technologies that are already 435 deployed or that will be deployed. The different answers to the 436 questionnaire and in particular [ETSI-IP6-WhitePaper] reported 437 detailed statistics on that and it can be stated that, besides Dual- 438 Stack, the most widely deployed IPv6 transition solution for MBB is 439 464XLAT [RFC6877], and for FBB is DS-Lite [RFC6333], both of which 440 are IPv6-only solutions. 442 Looking at the different feedback from network operators, in some 443 cases, even when using private addresses, such as 10.0.0.0/8 space 444 [RFC1918], the address pool is not large enough, e.g. for large 445 mobile operators or large Data Centers (DCs), Dual-Stack is not 446 enough, because it still requires IPv4 addresses to be assigned. 447 Also, Dual-Stack will likely lead to duplication of several network 448 operations both in IPv6 and IPv4 and this increases the amount of 449 state information in the network with a waste of resources. For this 450 reason, in some scenarios (e.g. MBB or DCs) IPv6-only stage could be 451 more efficient from the start since the IPv6 introduction phase with 452 Dual-Stack may consume more resources (for example CGNAT costs). 454 So, in general, it is possible to state that, when the Dual-Stack 455 disadvantages outweigh the IPv6-only complexity, it makes sense to 456 migrate to IPv6-only. Some network operators already started this 457 process, while others are still waiting. 459 5. Considerations coming out of IPv6 deployments 461 Global IPv4 address depletion is reported by most network operators 462 as the important driver for IPv6 deployment. Indeed, the main reason 463 for IPv6 deployment given is related to the run out of private 464 10.0.0.0/8 space [RFC1918]. 5G and IoT service deployment is another 465 incentive not only for business reasons but also for the need of more 466 addresses. 468 The answers in Appendix shows that the IPv6 deployment strategy is 469 based mainly on Dual Stack architecture and most of the network 470 operators are migrating or plan to migrate in the next few years. 472 It is interesting to see that most of the network operators have no 473 big plans to migrate transport network (metro and backbone) soon, 474 since they do not see business reasons. It seems that despite the 475 future benefit with IPv6 (e.g. SRv6) which may justify in the long 476 term a migration to native IPv6, there is no pressure to migrate to 477 native IPv6 forwarding in the short term. Most of the network 478 operators said that a software upgrade can be enough to support IPv6 479 where it is needed for now. 481 This survey demonstrates that full replacement of IPv4 will take long 482 time. Indeed the transition to IPv6 has different impacts and 483 requirements depending on the network segment: 485 o It is possible to say that almost all mobile devices are already 486 IPv6 capable while for fixed access most of the CPEs are Dual 487 Stack. Data Centers are also evolving and deploying IPv6 to cope 488 with the increasing demand of cloud services. 490 o While the access network seems not strongly impacted because it is 491 mainly based on layer 2 traffic, regarding Edge and BNG, most 492 network operators that provide IPv6 connectivity runs BNG devices 493 in Dual Stack in order to distribute both IPv4 and IPv6. 495 o For Metro and Backbone, the trend is to keep MPLS Data Plane and 496 run IPv6/IPv4 over PE devices at the border. All MPLS services 497 can be guaranteed in IPv6 as well through 6PE/6VPE protocols. 499 In this scenario it is clear that the complete deployment of a full 500 IPv6 data plane will take more time. If we look at the long term 501 evolution, IPv6 can bring other advantages like introducing advanced 502 protocols developed only on IPv6 (e.g. SRv6) to implement all the 503 controlled SLA services aimed by the 5G technology and beyond. 505 6. IPv6 incentives 507 It is possible to state that IPv6 adoption is no longer optional, 508 indeed there are several incentives for the IPv6 deployment: 510 Technical incentives: all Internet technical standard bodies and 511 network equipment vendors have endorsed IPv6 and view it as the 512 standards-based solution to the IPv4 address shortage. The IETF, 513 as well as other SDOs, need to ensure that their standards do not 514 assume IPv4. The IAB expects that the IETF will stop requiring 515 IPv4 compatibility in new or extended protocols. Future IETF 516 protocol work will then optimize for and depend on IPv6. It is 517 recommended that all networking standards assume the use of IPv6 518 and be written so they do not require IPv4 ([RFC6540]). In 519 addition, every Internet registry worldwide strongly recommends 520 immediate IPv6 adoption. 522 Business incentives: with the emergence of new digital 523 technologies, such as 5G, IOT and Cloud, new use cases have come 524 into being and posed more new requirements for IPv6 deployment. 525 Over time, numerous technical and economic stop-gap measures have 526 been developed in an attempt to extend the lifetime of IPv4, but 527 all of these measures add cost and complexity to network 528 infrastructure and raise significant barriers to innovation. It 529 is widely recognized that full transition to IPv6 is the only 530 viable option to ensure future growth and innovation in Internet 531 technology and services. Several large networks and Data Centers 532 have already evolved their internal infrastructures to be 533 IPv6-only. Forward looking large corporations are also working 534 toward migrating their enterprise networks to IPv6-only 535 environments. 537 Governments incentives: governments have a huge responsibility in 538 promoting IPv6 deployment within their countries. There are 539 example of governments already adopting policies to encourage IPv6 540 utilization or enforce increased security on IPv4. So, even 541 without funding the IPv6 transition, governments can recommend to 542 add IPv6 compatibility for every connectivity, service or products 543 bid. This will encourage the network operators and vendors who 544 don't want to miss out on government related bids to evolve their 545 infrastructure to be IPv6 capable. Any public incentives for 546 technical evolution will be bonded to IPv6 capabilities of the 547 technology itself. 549 7. Call for action 551 There are some areas of improvement, that are often mentioned in the 552 literature and during the discussions on IPv6 deployment. This 553 section lists these topics and wants to start a call for action to 554 encourage more investigations on these aspects. 556 7.1. Transition choices 558 From an architectural perspective, a service provider or an 559 enterprise may perceive quite a complex task the transition to IPv6, 560 due to the many technical alternatives available and the changes 561 required in management and operations. Moreover, the choice of the 562 method to support the transition may depend on factors specific to 563 the operator's or the enterprise's context, such as the IPv6 network 564 design that fits the service requirements, the deployment strategy, 565 and the service and network operations. 567 This section briefly highlights the basic approaches that service 568 providers and enterprises may take. The scope is to raise the 569 discussion whether actions may be taken that allow to overcome the 570 issues highlighted and further push the adoption of IPv6. 572 7.1.1. Service providers 574 For a service provider, the IPv6 transition often refers to the 575 service architecture (also referred to as overlay) and not to the 576 network architecture (underlay). IPv6 is introduced at the service 577 layer when a service requiring IPv6-based connectivity is deployed in 578 an IPv4-based network. In this case, as already mentioned in the 579 previous sections, a strategy is based on two stages: IPv6 580 introduction and IPv6-only. 582 7.1.2. Enterprises 584 As described in [RFC7381], enterprises face different challenges than 585 operators. The overall problem for many enterprises is to handle 586 IPv6-based connectivity to the upstream providers, while supporting a 587 mixed IPv4/IPv6 domain in the internal network. The dual stage 588 approach may be still applicable, even if the priorities to apply 589 either stage are different. 591 7.2. Network Operations 593 An important factor is represented by the need for training the 594 network operations workforce. Deploying IPv6 requires it as policies 595 and procedures have to be adjusted in order to successfully plan and 596 complete an IPv6 migration. Staff has to be aware of the best 597 practices for managing IPv4 and IPv6 assets. In addition to network 598 nodes, network management applications and equipment need to be 599 properly configured and in same cases also replaced. This may 600 introduce more complexity and costs for the migration. 602 7.3. Performance 604 Despite their relative differences, people tend to compare the 605 performance of IPv6 versus IPv4. In some cases, IPv6 behaving 606 "worse" than IPv4 tends to re-enforce the justification of not moving 607 towards the full adoption of IPv6. This position is supported when 608 looking at available analytics on two critical parameters: packet 609 loss and latency. These parameters have been constantly monitored 610 over time, but only a few extensive researches and measurement 611 campaigns are currently providing up-to-date information. This 612 paragraph will look briefly at both of them, considering the 613 available measurements. Operators are invited to bring in their 614 experience and enrich the information reported below. 616 7.3.1. IPv6 latency 618 [APNIC3] constantly compares the latency of both address families. 619 Currently, the worldwide average is still in favor of IPv4. Zooming 620 at the country or even at the operator level, it is possible to get 621 more detailed information and appreciate that cases exist where IPv6 622 is faster than IPv4. [APRICOT] highlights how when a difference in 623 performance exists it is often related to asymmetric routing issues. 624 Other possible explanations for a relative latency difference lays on 625 the specificity of the IPv6 header which allows packet fragmentation. 626 In turn, this means that hardware needs to spend cycles to analyze 627 all of the header sections and when it is not capable of handling one 628 of them it drops the packet. Even considering this, a difference in 629 latency stands and sometimes it is perceived as a limiting factor for 630 IPv6. A few measurement campaigns on the behavior of IPv6 in Content 631 Delivery Networks (CDN) are also available [MAPRG-IETF99], [INFOCOM]. 632 The TCP connect time is still higher for IPv6 in both cases, even if 633 the gap has reduced over the analysis time window. 635 7.3.2. IPv6 packet loss 637 [APNIC3] also provides the failure rate of IPv6. Two reports, namely 638 [RIPE1] and [APRICOT], discussed the associated trend, showing how 639 the average worldwide failure rate of IPv6 worsened from around 1.5% 640 in 2016 to a value exceeding 2% in 2020. Reasons for this effect may 641 be found in endpoints with an unreachable IPv6 address, routing 642 instability or firewall behaviours. Yet, this worsening effect may 643 appeae as disturbing for a plain transition to IPv6. Operators are 644 once again invited to share their experience and discuss the 645 performance of IPv6 in their network scenarios. 647 7.4. IPv6 security 649 IPv6 presents a number of exciting possibilities for the expanding 650 global Internet, however, there are also noted security challenges 651 associated with the transition to IPv6. [I-D.ietf-opsec-v6] analyzes 652 the operational security issues in several places of a network 653 (enterprises, service providers and residential users). 655 The security aspects have to be considered to keep the same level of 656 security as it exists nowadays in an IPv4-only network environment. 657 The autoconfiguration features of IPv6 will require some more 658 attention for the things going on at the network level. Router 659 discovery and address autoconfiguration may produce unexpected 660 results and security holes. The IPsec protocol implementation has 661 initially been set as mandatory in every node of the network, but 662 then relaxed to recommendation due to extremely constrained hardware 663 deployed in some devices e.g., sensors, Internet of Things (IoT). 665 There are some concerns in terms of the security but, on the other 666 hand, IPv6 offers increased efficiency. There are measurable 667 benefits to IPv6 to notice, like more transparency, improved 668 mobility, and also end to end security (if implemented). 670 As reported in [ISOC], comparing IPv6 and IPv4 at the protocol level, 671 one may probably conclude that the increased complexity of IPv6 672 results in an increased number of attack vectors, that imply more 673 possible ways to perform different types attacks. However, a more 674 interesting and practical question is how IPv6 deployments compare to 675 IPv4 deployments in terms of security. In that sense, there are a 676 number of aspects to consider. 678 Most security vulnerabilities related to network protocols are based 679 on implementation flaws. Typically, security researchers find 680 vulnerabilities in protocol implementations, which eventually are 681 "patched" to mitigate such vulnerabilities. Over time, this process 682 of finding and patching vulnerabilities results in more robust 683 implementations. For obvious reasons, the IPv4 protocols have 684 benefited from the work of security researchers for much longer, and 685 thus IPv4 implementations are generally more robust than IPv6. 687 Besides the intrinsic properties of the protocols, the security level 688 of the resulting deployments is closely related to the level of 689 expertise of network and security engineers. In that sense, there is 690 obviously much more experience and confidence with deploying and 691 operating IPv4 networks than with deploying and operating IPv6 692 networks. 694 Finally, implementation of IPv6 security controls obviously depends 695 on the availability of features in security devices and tools. 696 Whilst there have been improvements in this area, there is a lack of 697 parity in terms of features and/or performance when considering IPv4 698 and IPv6 support in security devices and tools. 700 7.4.1. Protocols security issues 702 It is important to say that IPv6 is not more or less secure than IPv4 703 and the knowledge of the protocol is the best security measure. 705 In general there are security concerns related to IPv6 that can be 706 classified as follows: 708 o Basic IPv6 protocol (Basic header, Extension Headers, Addressing) 710 o IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) 712 o Internet-wide IPv6 security (Filtering, DDoS, Transition 713 Mechanisms) 715 ICMPv6 is an integral part of IPv6 and performs error reporting and 716 diagnostic functions. Since it is used in many IPv6 related 717 protocols, ICMPv6 packet with multicast address should be filtered 718 carefully to avoid attacks. Neighbor Discovery Protocol (NDP) is a 719 node discovery protocol in IPv6 which replaces and enhances functions 720 of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers 721 for discovering multicast listeners on a directly attached link, much 722 like Internet Group Management Protocol (IGMP) is used in IPv4. 724 These IPv6 associated protocols like ICMPv6, NDP and MLD are 725 something new compared to IPv4, so they adds new security threats and 726 the related solutions are still under discussion today. NDP has 727 vulnerabilities [RFC3756] [RFC6583]. The specification says to use 728 IPsec but it is impractical and not used, on the other hand, SEND 729 (SEcure Neighbour Discovery) [RFC3971] is not widely available. 731 [RIPE2] describes the most important threats and solutions regarding 732 IPv6 security. 734 8. Security Considerations 736 This document has no impact on the security properties of specific 737 IPv6 protocols or transition tools. The security considerations 738 relating to the protocols and transition tools are described in the 739 relevant documents. 741 9. Contributors 743 The following people provided relevant contributions to this 744 document: 746 TBC 748 10. Acknowledgements 750 TBC 752 11. IANA Considerations 754 This document has no actions for IANA. 756 12. References 758 12.1. Normative References 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 12.2. Informative References 767 [AKAMAI] AKAMAI, "IPv6 Adoption Visualization", 2020, 768 . 772 [APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2020, 773 . 775 [APNIC2] APNIC2, "Addressing 2019", 2020, 776 . 778 [APNIC3] APNIC, "Average RTT Difference (ms) (V6 - V4) for World 779 (XA)", 2020, . 781 [APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for 782 World (XA)", 2020, 783 . 786 [ETSI-IP6-WhitePaper] 787 ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, 788 Benefits, Transition Challenges and the Way Forward", 789 ISBN 979-10-92620-31-1, 2020. 791 [FACEBOOK] 792 FACEBOOK, "IPv6", 2020, . 794 [GOOGLE] GOOGLE, "IPv6 Adoption", 2020, 795 . 797 [I-D.ietf-opsec-v6] 798 Vyncke, E., Kk, C., Kaeo, M., and E. Rey, "Operational 799 Security Considerations for IPv6 Networks", draft-ietf- 800 opsec-v6-21 (work in progress), November 2019. 802 [I-D.lmhp-v6ops-transition-comparison] 803 Lencse, G., Martinez, J., Howard, L., Patterson, R., and 804 I. Farrer, "Pros and Cons of IPv6 Transition Technologies 805 for IPv4aaS", draft-lmhp-v6ops-transition-comparison-05 806 (work in progress), July 2020. 808 [INFOCOM] Doan, T., "A Longitudinal View of Netflix: Content 809 Delivery over IPv6 and Content Cache Deployments", 2020, 810 . 813 [ISOC] Internet Society, "IPv6 Security FAQ", 2019, 814 . 817 [MAPRG-IETF99] 818 Bajpai, V., "Measuring YouTube Content Delivery over 819 IPv6", 2017, . 823 [POTAROO] POTAROO, "IPv6 / IPv4 Comparative Statistics", 2020, 824 . 826 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 827 and E. Lear, "Address Allocation for Private Internets", 828 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 829 . 831 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 832 Neighbor Discovery (ND) Trust Models and Threats", 833 RFC 3756, DOI 10.17487/RFC3756, May 2004, 834 . 836 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 837 "SEcure Neighbor Discovery (SEND)", RFC 3971, 838 DOI 10.17487/RFC3971, March 2005, 839 . 841 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 842 for IPv6 Hosts and Routers", RFC 4213, 843 DOI 10.17487/RFC4213, October 2005, 844 . 846 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 847 Scenarios for IPv6 Deployment", RFC 6036, 848 DOI 10.17487/RFC6036, October 2010, 849 . 851 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 852 Transition Mechanisms during IPv6 Deployment", RFC 6180, 853 DOI 10.17487/RFC6180, May 2011, 854 . 856 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 857 Stack Lite Broadband Deployments Following IPv4 858 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 859 . 861 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 862 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 863 RFC 6540, DOI 10.17487/RFC6540, April 2012, 864 . 866 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 867 Neighbor Discovery Problems", RFC 6583, 868 DOI 10.17487/RFC6583, March 2012, 869 . 871 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 872 Combination of Stateful and Stateless Translation", 873 RFC 6877, DOI 10.17487/RFC6877, April 2013, 874 . 876 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 877 Content Providers and Application Service Providers", 878 RFC 6883, DOI 10.17487/RFC6883, March 2013, 879 . 881 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 882 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 883 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 884 . 886 [RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, 887 . 890 [RIPE2] RIPE, "IPv6 Security", 2019, 891 . 894 [W3TECHS] W3TECHS, "Historical yearly trends in the usage statistics 895 of site elements for websites", 2020, . 898 Appendix A. Summary of Questionnaire and Replies 900 This Appendix summarizes the questionnaire and the replies received. 902 1. Do you have plan to move more fixed or mobile or enterprise users 903 to IPv6 in the next 2 years? 905 a. If yes, fixed, or mobile, or enterprise? 907 b. What're the reasons to do so? 909 c. When to start: already on going, in 12 months, after 12 months? 911 d. Which transition solution will you use, Dual-Stack, DS-Lite, 912 464XLAT, MAP-T/E? 914 2. Do you need to change network devices for the above goal? 916 a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT? 918 b. Will you migrate your metro or backbone or backhaul network to 919 support IPv6? 921 Some answers below: 923 Answer 1: (1) Yes, IPv6 migration strategy relies upon the deployment 924 of Dual Stack architecture. IPv4 service continuity designs is based 925 on DS-Lite for fixed environments and 464XLAT for mobile 926 environments. No plans to move towards MAP-E or MAP-T solutions for 927 the time being. (2) Yes, it's a matter of upgrading CPE, routers 928 (including BNGs), etc. Tunneling options (ISATAP, TEREDO, 6rd) will 929 also be used for migration. 931 Answer 2: (1) Yes, at this moment we widely use IPv6 for mobile 932 services while we are using DS-Lite for fixed services (FTTH and 933 DSL). (2) We have no pressure to migrate to native IPv6 forwarding 934 in the short term and it would represent a significant work without 935 clear immediate benefit or business rationale. However we may see a 936 future benefit with SRv6 which may justify in the long term a 937 migration to native IPv6. 939 Answer 3: (1) Yes, fixed. The IP depletion topic is crucial, so we 940 need to speed up the DS-Lite deployment and also Carrier Grade Nat 941 introduction. (2) Yes, CGNAT introduction. 943 Answer 4: (1) No, we are rolling IPv6 users back to IPv4. DS-Lite. 944 (2) No, it was already done. IPv6 works worse than IPv4. it is 945 immature. 947 Answer 5: (1) Yes, all 3. Target is Dual-stack for fixed, mobile and 948 enterprise. (2) Yes, we are adding specific services cards inside our 949 FTTH equipment for dealing with CGNAT. Metro and backbone are 950 already Dual Stack. 952 Answer 6: (1) Yes, Enterprises customer demand is high and the 953 transition is on going through Dual-Stack. (2) No big plan for 954 transport network. 956 Answer 7: No such requirements 958 Answer 8: (1) Yes, mobile. The Internet APN is not yet enabled for 959 IPv6, this will be done soon. 464XLAT will be used to save on RFC1918 960 address space. (2) Yes, PGW; Metro is already IPv6 and Backbone is 961 currently IPv4/MPLS. No native IPv6 planned as for now. 963 Answer 9: (1) Yes, Dual-Stack for all 3. Not all services are 964 available on IPv6. IPv6 adoption has been stated from many years but 965 still not finished. Dual-Stack is used. (2) No, at the moment it is 966 6PE solution. No plan to migrate on native IPv6. 968 Answer 10: (1) Yes, all 3. Ongoing transition with Dual-stack and 969 464XLAT. (2) No plan for Metro and Backbone. 971 Answer 11: No such requirements. 973 Answer 12: (1) Yes, mobile and fixed. To mitigate IPv4 exhaustion in 974 12 months, Dual-Stack is used. (2) No (hopefully). Managed by 975 software upgrade. 977 Answer 13: (1) Yes, on Mobile and Fixed. Mobile: IPv4 exhaustion for 978 the RAN transport and IPv6 roll out ongoing. Fixed: Enterprises are 979 requesting IPv6 and also competitors are offering it. Mobile: dual 980 stack and 6VPE; Enterprise: Dual Stack and 6VPE. (2) No, maybe only a 981 software upgrade. 983 Answer 14: (1) Yes, fixed. IPv4 address depletion, on going, Dual- 984 Stack with NAT444. (2) No. 986 Answer 15: (1) Yes, Mobile. Running out of private IPv4 address 987 space and do not want to overlap addresses. Transition on going 988 through 464XLAT. (2) Not yet, this is not the most pressing concern 989 at the moment but it is planned. 991 Answer 16: No, already on Dual-Stack for many years. Discussing 992 IPv6-only. 994 Answer 17: (1) Yes, all 3, strategy on going, Dual-Stack, MAP-T. (2) 995 Yes, CPE, BR Dual-Stack. 997 Answer 18: (1) Yes, Mobile, due to address deficit. It would be very 998 likely 464XLAT. (2) It is not clear at the moment. Still under 999 investigation. CPE, Mobile Core, NAT. For IPv6 native support no 1000 plans for today. 1002 Answer 19: No. Difficult to do it for enterprises, and don't really 1003 care for residential customers. 1005 Answer 20: (1) Yes, fixed, mobile. IP space depletion. Mobile and 1006 Backbone are already done, Fixed is becoming Dual-Stack. (2) Yes, 1007 ordinary CPE and small routers. Some of them needs just software 1008 upgrade. Backbone done, no plan for metro and backhaul. 1010 Answer 21: No such requirements 1012 Answer 22: (1) Yes, mobile, we have few enterprise requests for IPv6; 1013 fixed already Dual-Stack. We are in the exhaustion point in public 1014 IPv4 usage in mobile so we need to move to IPv6 in the terminals. 1015 Dual-Stack deployment is ongoing. (2) No, all devices already support 1016 dual-stack mode. No migration needed. We already support IPv6 1017 forwarding in our backbone. 1019 Answer 23: No, already Dual-Stack 1021 Answer 24: (1) Yes, fixed. DS-Lite. (2) Yes, BNG supporting CGNAT. 1023 Answer 25: (1) Yes, fixed. DS-Lite will be deployed. (2) Yes. 1025 Answer 26: (1) Yes, Mobile (Fixed already Dual-Stack). IPv4 1026 depletion and Business customers are asking for it. Dual-Stack will 1027 be deployed. (2) No. 1029 Answer 27: (1) Yes, Mobile. Dual-Stack is on going. (2) Yes, MBH, 1030 mobile core. 1032 Answer 28: No such requirements. 1034 Answer 29: (1) Yes, fixed and mobile, enterprise is not certain. 1035 IPv4 addressing is not enough, fixed and mobile should be started in 1036 12 months. (2) Telco Cloud, BNG and PEs already support IPv6. 1038 Answer 30: (1) Yes, all 3. Government has pushed. Dual-Stack for 1039 FBB in 12 months. (2) Yes, RGs have not good readiness, but not much 1040 could be done about it. PPPoE access does not create problem in 1041 access and aggregation. BNG should only change configuration. 1043 Answer 31: (1) Yes, mobile for 5G sites. Plan to use IPv6 soon. 6VPE 1044 in the beginning, then migrate to Dual-stack. (2) IP BH devices 1045 already support IPv6. 1047 Answer 32: No. 1049 Answer 33: Yes, Enterprises. We are running short of IPV4 addresses. 1050 In our Internet Core IPV4/IPV6 Dual Stack was already introduced. 1051 The rollout of IPV6 services is slow and we started with business 1052 services. From customer perspective Dual Stack is still a "must 1053 have" and this will be true for many years to come. Another thought 1054 is related to regulatory obligations. Anyway a total switch from 1055 IPv4 to IPv6 will not be possible for many more years. 1057 Answer 34: No, we have no plans to introduce new wave of IPv6 in our 1058 network. 1060 Answer 35: (1) Yes. Fixed, Enterprise. IPv4 addressing is not 1061 enough. Dual Stack deployment is ongoing. (2) Yes, CPE for metro and 1062 backbone. 1064 Answer 36: (1) Yes, Fixed, Enterprise. Dual-Stack. (2) Yes, CPE for 1065 IPv6 service delivery support. 1067 Answer 37: Yes, mobile and enterprise. 6PE is deployed on the PEs, 1068 and dual-stack. The PE supports IPv6 by modifying the live network 1069 configuration or upgrading the software. 1071 Answer 38: Yes, both home broadband and enterprise services support 1072 IPv6. IPv6 services are basic capabilities of communication 1073 networks. Currently 6RD, dual stack (native IPv6) in the future. 1074 The dual-stack feature does not require device changes. The home 1075 gateway is connected to the switch and the BNG. The Dual Stack can 1076 be supported through configuration changes. Both the metro and 1077 backbone networks use MPLS to provide bearer services and do not 1078 require IPv6 capabilities. IPv6 is not enabled on both the metro and 1079 backbone networks. IPv6 services are implemented through 6VPE. 1081 Answer 39: (1) Yes, Enterprises B2B needs more IP addresses. Dual- 1082 Stack is already on going. (2) No, BNG/mobile core and NAT. Metro 1083 and Backbone already support today. 1085 Answer 40: Not for now. 1087 Authors' Addresses 1089 Giuseppe Fioccola 1090 Huawei Technologies 1091 Riesstrasse, 25 1092 Munich 80992 1093 Germany 1095 Email: giuseppe.fioccola@huawei.com 1097 Paolo Volpato 1098 Huawei Technologies 1099 Via Lorenteggio, 240 1100 Milan 20147 1101 Italy 1103 Email: paolo.volpato@huawei.com