idnits 2.17.1 draft-xie-v6ops-ipv6-development-chinatelecom-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (July 7, 2020) is 1387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7219' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC7599' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 327, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS Working Group C. Xie 3 Internet-Draft C. Li 4 Intended status: Informational C. Ma 5 Expires: January 8, 2021 Q. Yuan 6 China Telecom 7 July 7, 2020 9 IPv6 development and current status of China Telecom 10 draft-xie-v6ops-ipv6-development-chinatelecom-00 12 Abstract 14 The draft presents China Telecom's deployment of IPv6 in multiple 15 scenarios for the whole network transition, including the history, 16 transition strategy, measurements and challenges. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 8, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Retrospection . . . . . . . . . . . . . . . . . . . . . . . . 2 55 4. IPv6 deployment in multiple scenarios . . . . . . . . . . . . 3 56 5. IPv6 measurement . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 As one of the 3 operators in China, China Telecom not only provides 66 voice, household broadband and mobile services to public customers, 67 but also provides leased-line, VPN, IDC and cloud computing services 68 to enterprise customers. Up to now, the quantities of mobile users 69 and household users have reached to 308 million and 123 million 70 respectively, of which 267 million are LTE/4G users. With the 71 evolution of mobile networks, China Telecom has begun to provide SA- 72 based 5G services. In addition, China Telecom also provides oversea 73 services in some regions, for instances, North America, Europe and 74 Australia, etc. 76 To support the services provisioning for tremendous amount of users 77 in different scenarios, a large-scale IP infrastructure has been 78 setup and operated. This document presents IPv6 deployment in the 79 large-scale IP infrastructure of China Telecom, including its 80 history, deployment strategy, measurements and challenges. 82 2. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 3. Retrospection 92 China Telecom's IPv6 work can trace back to 2001, considering that 93 IPv6 is the future of IP network and IPv4 address will be exhausted 94 sooner or later, China Telecom begun to test IPv6 over ADSL network, 95 and successfully tunneled through the workflow of IPv4/IPv6 dual- 96 stack service in broadband network then. 98 In 2012, IPv6 deployment field-trial for MANs (i.e., Metro Area 99 Network) was implemented in Jiangsu and Hunan Provinces, Dual- 100 stack([RFC4787]), DS-Lite([RFC6333]) and Lightweight 101 4over6([RFC7596]) and IVI([RFC6144]) were tested in the trial. After 102 the field trial IPv6 capability expanded and covered more than 10 103 million users. 105 Particularly, since Chinese government launched the IPv6 action plan 106 in 2017 November, IPv6 commercial deployment was accelerated and 107 extended to nearly every part of the network infrastructure, 108 including enable IPv6 in the cloud computing platform, which is 109 essential for customer to enable IPv6 in their application system. 110 After more than two years efforts, comprehensive IPv6 deployment in 111 the IP infrastructure have been achieved. 113 4. IPv6 deployment in multiple scenarios 115 China Telecom's IP infrastructure is an multi-AS system，as 116 shown in figure 1,it consists of backbone networks, MANs, IP RAN, 117 EPC(i.e., mobile core network of LTE), IDCs, cloud resource pools, 118 etc. 120 .------. .-----. .-----. 121 / \ / \ / \ 122 / Other \ / Foreign \ / Foreign \ 123 ( Domestic ) ( Operators ) ( Operators ) 124 \Operators / \ / \ / 125 \ / \ / \ / 126 `----- '\ /`-----' `--+--' 127 \ / | 128 \ / | 129 \ / | 130 \.-----./ .--+--. 131 / \ / \ 132 / \ / \ 133 ( ChinaNet )--------------------- ( CN2 ) 134 \ / \ / 135 \ / \ / 136 `------'\ /--+--' 137 | \ / | 138 | \ / | 139 | \ / | 140 _______|______ \ _________________ / ____|_________ 141 | | | | | | 142 | MANs/ | | IDCs/Cloud | | 4G/5G Mobile | 143 | IPRANs | | | | Core Networks| 144 +--------------+ +-----------------+ +--------------+ 146 Figure 1: Overall architecture of network infrastructure 148 There are two inter-connected backbone networks, ChinaNet and CN2, 149 both have not only nation-wide coverage, but also have some oversea 150 POPs. The two backbones provide high-speed data switching 151 domestically and overseas. MANs, EPCs, IDC and cloud resource pools 152 are connected to the two backbones. ChinaNet is native-IP network, 153 which provides high-speed data transfer for wireline and wireless 154 broadband Internet-access and communications between different 155 regions. In order to support IPv6 inter-connectivity for other local 156 networks, all the routers in ChinaNet have been IPv6-enabled and 157 operate in IPv4/IPv6 dual-stack mode. Different from ChinaNet, CN2 158 is a MPLS-based network, which mainly focuses on service provisioning 159 to enterprise customers and some services with high-quality 160 requirements. CN2 has enabled 6VPE and 6PE in its equipment, 161 therefore, it can provide high-speed IPv6 data switching and IPv6 VPN 162 to enterprise customers. 164 Currently MANs mainly uses dual-stack approaches, due to the shortage 165 of IPv4 address, most users are allocated with private address by 166 BRAS/BNGs. From 2012, multiple types of transition technologies, 167 such as Dual-stack, DS-Lite, Lightweight 4over6, and IVI, were 168 evaluated in the field trial, this process is nearly in parallel with 169 that of standardization in IETF, and most of the transition 170 techniques were in the stage of draft then. In order to support 171 multiple transition techniques, the supportive system of MANs was 172 upgraded to support dynamic selection of transition approaches based 173 on the type of CPEs and availability of the resource in the network 174 locally. However, due to the fact that most transition techniques do 175 not gain commercial support in CPEs, MANs later adopted dual-stack 176 approach for household users, and CGN module has been installed in 177 BRAS/BNGs for private and public address translation. 179 Same to the MANs, EPC of LTE also runs in dual-stack mode. When IPv6 180 deployment in LTE begun in 2015, it was required to switch on the 181 IPv6 protocol in the user plane of EPC and each user was allocated 182 one /64 Prefix of IPv6 and IPv4 address simultaneously. It should be 183 noted that EPC network of LTE is constructed on the provincial basis, 184 and each province has a set of EPC network, so for a given province, 185 when IPv6 capability is turned on in the EPC, every user's UE in this 186 province can get IPv6 address unless it does not support IPv6. Since 187 IPv6 has good support in the UEs of LTE, IPv6 penetration rate of 188 mobile user is higher than that of wireline user. 190 IDC is a place to provide stable and broadband networks with high 191 performance computers as a service to their customers it is another 192 scenario for IPv6. As the largest IDC providers, China Telecom has 193 upgraded all its IDCs to support IPv6. In addition, China Telecom 194 also provides cloud services and products based on the cloud resource 195 pools located in different regions of China, currently more than 50 196 cloud products are IPv6-capable,e.g., Elastic virtual machine, ELB, 197 Cloud desktop, Elastic IP, GPU virtual machine, which makes it 198 possible to provide IPv6-based network-cloud-convergence services to 199 customers. 201 Regarding to the IPv6 interconnection with other carriers, China 202 Telecom has setup IPv6-BGP peers with domestic partners, e.g., China 203 Mobile, China Unicom and CERNET, and the total bandwidth reaches to 204 5.4 Tbps in 13 inter-connection points, and also setup IPv6 BGP 205 connections with some giant global ISPs. 207 5. IPv6 measurement 209 In order to see how broadly IPv6 is being used in China, a 210 measurement system was developed by CAICT (i.e., Chinese Academy of 211 Information and Communications Technology). All the major networks, 212 including those of China Telecom, participate in the measurement. 213 The metrics that can be measured include user penetration rate, 214 traffic volume, end-to-end performance, etc. The measurement has 215 been running continuously and the result can be presented in real 216 time. 218 From the measurement, it can be seen that the quantity of user who 219 are allocated IPv6 address has increased dramatically during the last 220 two years. However, compared with the quantity of user who are 221 allocated IPv6 address, the quantity of active user deserves more 222 attention, herein, the term of "active IPv6 user" refers to the user 223 who have at least one visit of IPv6 content within one month. Recent 224 measurement shows that the rate of active IPv6 users in Mobile 225 network is about 79 percent. However, this metric in wireline 226 network is about 30 percent, much lower than that of LTE network. 227 This difference is mainly caused by the low rate of IPv6-capble home 228 routers. 230 It should be noted that the data in this draft only shows the current 231 status, the measurement result changes over time. 233 6. Challenges 235 Although IPv6 has gained widely deployment in China Telecom and most 236 users have been allocated IPv6 addresses, several challenges still 237 face operators. Regarding to the usage of IPv6, traffic volume of 238 IPv6 is still much lower than that of IPv4, and the rates of IPv6 239 traffic of mobile network and wireline network are about 8.8 percent 240 and 2 percent respectively, it is supposed that this is mainly due to 241 the reasons below. 243 1. Low rate of IPv6 support in home CPEs: As a matter of fact, a 244 portion of home CPEs are not customized by operators. CPE 245 routers can be purchased from online shop and installed at home 246 without any allowance of operators, some types do not support 247 IPv6 at all. This factor makes it difficult to improve the 248 penetrate rate and IPv6 traffic. However, there is good news 249 that after realizing this problem, the IPv6 community has jointly 250 pushed the vendors of CPE router to improve IPv6 support in their 251 products. 253 2. Slow transition on contents' side:Compared with the transition of 254 network operators, the transition of content's side is relatively 255 slow. One reason is that service layer transition depends on the 256 IPv6 capability of low-layer infrastructure, such as CDNs and 257 IDCs; they are required to support IPv6 in advance. Another 258 reason behind this is that content providers are very concerned 259 about the end-to-end performance of the IPv6 networks, so even 260 though IPv6 has been implemented in their products, they are 261 still very cautious to switch from IPv4 to IPv6 in clients 262 software, and the IPv6 coverage is increased step by step based 263 on the result of performance test. One the other side, some OTTs 264 has taken bold step to use IPv6, for instance, the measurement 265 show that the rate of IPv6 traffic of Youku, which is one of the 266 largest video providers in China, is more than 70 percent. 268 Although Challenges lies ahead, China Telecom will persistently push 269 forward the deployment and utilization of IPv6. Take advantages of 270 ubiquitous IPv6 deployment, SRv6 field trial has been implemented in 271 several use cases, including MAN, Mobile transport network, anti- 272 DDOS, etc. Particularly, IPv6 will be planned to be used in new 273 scenarios, such as IOT and network-cloud-convergence, and the 274 transition to IPv6-only will be explored in the coming future. 276 7. Security Considerations 278 None. 280 8. Acknowledgements 282 During the long period, China Telecom's IPv6 deployment has received 283 strong support from lots of people, some of them are Xing Li, Fred 284 Baker, Latif Ladid, Zhenbin Li, Hui Tian, Shucheng Liu, Geoff Huston, 285 Dong Liu, Yan Ma, etc. 287 9. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 295 Translation (NAT) Behavioral Requirements for Unicast 296 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 297 2007, . 299 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 300 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 301 April 2011, . 303 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 304 Stack Lite Broadband Deployments Following IPv4 305 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 306 . 308 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 309 Discovery (SEND) Source Address Validation Improvement 310 (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014, 311 . 313 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 314 Farrer, "Lightweight 4over6: An Extension to the Dual- 315 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 316 July 2015, . 318 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 319 and T. Murakami, "Mapping of Address and Port using 320 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 321 2015, . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 328 (IPv6) Specification", STD 86, RFC 8200, 329 DOI 10.17487/RFC8200, July 2017, 330 . 332 Authors' Addresses 334 Chongfeng Xie 335 China Telecom 336 China 338 Email: xiechf@chinatelecom.cn 340 Cong Li 341 China Telecom 342 China 344 Email: licong@chinatelecom.cn 346 Chenhao Ma 347 China Telecom 348 China 350 Email: machh@chinatelecom.cn 352 Quanxin Yuan 353 China Telecom 354 China 356 Email: yuanqx@chinatelecom.cn