idnits 2.17.1 draft-xcf-v6ops-chinatelecom-deployment-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2017) is 2493 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops C. Xie 3 Internet-Draft C. Li 4 Intended status: Informational China Telecom Beijing Research 5 Expires: December 30, 2017 Institute 6 C. Bao 7 G. Han 8 X. Li 9 CERNET Center/Tsinghua 10 University 11 June 28, 2017 13 MAP-T Trail in ChinaTelecom 14 draft-xcf-v6ops-chinatelecom-deployment-02 16 Abstract 18 With the depletion of the IPv4 address space, large-scale SPs are now 19 faced with the real option to deploy IPv6 in a timely manner. In 20 order to achieve smooth transition to IPv6, migration tools should be 21 introduced for different deployment models. Among different IPv6 22 transition mechanisms, MAP-T is a stateless translation method which 23 can directly translate IPv4 packet to IPv6 packet. This document 24 describes the challenges and requirements for large SP to deploy IPv6 25 in operational network, the experimental results of MAP-T in our 26 laboratory and the field trials in large SP operational network. 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 http://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 December 30, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 (http://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 1.1. Major Motivation . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. IPv4-as-a-Service Requirements . . . . . . . . . . . . . . 3 65 2. Architecture and Methodology . . . . . . . . . . . . . . . . . 4 66 2.1. Major Design Considerations . . . . . . . . . . . . . . . . 4 67 2.2. Regulatory Considerations . . . . . . . . . . . . . . . . . 4 68 2.3. Security Considerations . . . . . . . . . . . . . . . . . . 4 69 2.4. Operational Considerations . . . . . . . . . . . . . . . . 5 70 2.5. End-User Experience Considerations . . . . . . . . . . . . 5 71 3. Design and Deployment . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Lab Test . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Field Trial . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Observations and Experiences . . . . . . . . . . . . . . . . . 6 75 4.1. Effects on End-User . . . . . . . . . . . . . . . . . . . . 6 76 4.2. Effects on Internal Staff . . . . . . . . . . . . . . . . . 6 77 4.3. Effects on Business . . . . . . . . . . . . . . . . . . . . 7 78 5. Summary: Post-mortem Report . . . . . . . . . . . . . . . . . . 7 79 5.1. Deviations from IETF Documents . . . . . . . . . . . . . . 7 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 The dramatic growth of the Internet is accelerating the exhaustion of 90 available IPv4 addressing pool. It is widely accepted that IPv6 is 91 the only real option on the table for the continued growth of the 92 Internet. However, IPv6 deployment is a huge systematic project and 93 a lot of challenges will arise especially in large SP operational 94 network. 96 1.1. Major Motivation 98 In order to achieve smooth transition to IPv6, migration tools should 99 be introduced for different deployment models, among which MAP-T 100 [RFC7599] is a stateless translation mechanism with good scalability. 101 This document describes the challenges and requirements for large SPs 102 in IPv6 transition period. Then, we introduce MAP-T experimental 103 results in our laboratory and the field trials in large SP 104 operational network. 106 1.2. IPv4-as-a-Service Requirements 108 In order to facilitate smooth IPv6 migration, some factors need to be 109 taken into consideration especially for large SPs. There are ten 110 major requirements: 112 1. It should deploy in an incremental fashion and the overall 113 transition process should be stable and operational. 115 2. It should largely reduce IPv4 public address consumption. 117 3. It should accelerate the deployment of IPv6, rather than just 118 prolonging the lifecycle of IPv4 by introducing multiple layers 119 of NAT. 121 4. There should be no perceived degradation of customer experience. 122 As a result, IPv6 transition mechanisms should provide IPv4 123 service continuity. 125 5. It should achieve scalability, simplicity and high availability, 126 especially for large-scale SPs. 128 6. It should have user management and network management ability. 130 7. It should support user authentication, authorization and 131 accounting as an essential part of operational network. 133 8. Most SPs need some kind of mechanisms to trace the origin of 134 traffic in their networks. This should also be available for 135 IPv6 traffic. 137 9. It should have good throughput performance and massive 138 concurrent session support. 140 10. It should maintain the deployment concepts and business models 141 which have been proven and used with existing revenue generating 142 IPv4 services. 144 2. Architecture and Methodology 146 2.1. Major Design Considerations 148 The major objective listed in the following is to verify the 149 functionality and performance of MAP-T: 151 o Verify how to deploy MAP-T in practical network. 153 o Verify what applications can be used in MAP-T. 155 o Verify what Operating Systems can be supported in MAP-T. 157 o Verify the effect of user experience with limited ports. 159 o Verify the performance of MAP-T. 161 2.2. Regulatory Considerations 163 The government requires server operators to detect the packet sender 164 by source IP (and port) and therefore stateless address mapping 165 technologies are preferred. This will dramatically reduce the volume 166 of material required to be held for logging compliance. 168 In addition, the stateless translation technology is preferred, since 169 IPv6 addresses in the IPv6 packets everywhere in the network contain 170 both the IPv6 and IPv4 address information without the requirement of 171 decapsulation. 173 2.3. Security Considerations 175 From operation point of view, single stack (IPv6-only) is easier for 176 ensuring the security compared with the dual stack. 178 The stateless mechanism can help for the trace-back and identifying 179 the source addresses (and port). 181 The translation mechanism can help for configuring the access list 182 and rate-limiting control without decapsulation. 184 2.4. Operational Considerations 186 The MAP-T deployment should support the DHCPv6-PD and MAP-T parameter 187 auto-configuration [RFC7598], the PPPoE authentication and source 188 address tracing back. 190 2.5. End-User Experience Considerations 192 The major issues are: 194 o Application test: The applications we have tested include web, 195 email, Instant Message, ftp, telnet, SSH, video, Video Camera, 196 P2P, online game, Voip, VPN and so on. 198 o Operating System test: The OS we have tested includes Win7/8, OSX, 199 windows XP, iOS, Android, and Linux. 201 o Performance test: We have measured the parameters of concurrent 202 session number, throughput performance. 204 3. Design and Deployment 206 3.1. Lab Test 208 The lab test topology is Figure 1 210 +-----+ +-----+ 211 |Host1+--+ CE1 +------+ ------ 212 +-----+ +-----+ | //// \\\\ 213 /-+--\ +----------+ // \\ 214 // \\ | | | | 215 +-----+ +-----+ | IPv6 | | MAP-T BR | | IPv4 Internet | 216 |Host2+--+ CE2 +-+ Network +---| +--+ | 217 +-----+ +-----+ \\ // | | \\ // 218 |---+/ +----------+ \\\\ //// 219 | | ------ 220 +-----+ +-----+ | | 221 |Host3+--+ CE3 +----+ | 222 +-----+ +-----+ | ------ 223 | //// \\\\\ 224 | |/ | 225 +----------------------+ IPv6 Internet | 226 | | 227 CEs are connted to the |\ / 228 IPv6 Network via BRAS \\\\ ///// 229 (PPPoE and DHCPv6) ------ 231 Figure 1: MAP-T Lab Test 233 3.2. Field Trial 235 The deployment model of MAP-T in operational network is depicted in 236 Figure 2 238 ---- ----- 239 // \\ // \\ --------- -------- 240 / \ / \ // \\ // CPN 241 | +-----+ +----+ \ / -------- 242 | | | Metro |BRAS| |-----|--End System 243 | Backbone|Core | Area |/SR | Access | | -------- 244 | Network |Route| Network +----+ Network | CPE | -------- 245 | | | |AAA | |-----|--End System 246 | +-----+ +----+ / | \ -------- 247 \ / \ / \\ // | \\ 248 \\ // \\ // -------- | --------- 249 ---- ----|-- | 250 | | 251 -----------------| | |----------------| | |---------| 252 \ | / \ | / | 253 \---|--- / \--|--/ | 254 IPv6/IPv4 | MAP-T | IPv6-only |MAP-T| IPv6/IPv4 | 255 Internet | BR | Network | CE | Network | 256 / ------- \ / ----- \ | 257 / \ / \ | 258 ----------------| |----------------| |--------| 260 Figure 2: MAP-T Field Trial 262 4. Observations and Experiences 264 4.1. Effects on End-User 266 o MAP-T can support all IPv4 applications, sam as NAT44. 268 o MAP-T can support a variety of Operating Systems. 270 o With the ratio of 128 (512 maximum concurrent sessions), there is 271 no perceived degradation of customer experience. 273 4.2. Effects on Internal Staff 275 o MAP-T can have good scalability. MAP-T BR does not need to 276 maintain any session state, and only limited session states have 277 to been maintained in CE for its customer. 279 o MAP-T can be deployed in an incremental way. 281 o MAP-T supports DHCPv6-PD and PPPoE user authentication and the 282 function of the source address trace back. 284 4.3. Effects on Business 286 MAP-T can help to promote IPv6 business and to use public IPv4 287 address more effectively.. 289 5. Summary: Post-mortem Report 291 MAP-T is a useful tool for IPv6 transition for large scale SPs. 293 5.1. Deviations from IETF Documents 295 The IETF RFCs for the testing and field trial are [RFC7597], 296 [RFC7599], [RFC7598] and [I-D.ietf-softwire-map-deployment] 298 6. IANA Considerations 300 This specification does not require any IANA actions. 302 7. Security Considerations 304 There are no other special security considerations. 306 8. Acknowledgements 308 9. References 310 9.1. Normative References 312 [RFC7597] Troan, O., Ed., Dec, W., Li, X., 313 Bao, C., Matsushima, S., 314 Murakami, T., and T. Taylor, Ed., 315 "Mapping of Address and Port with 316 Encapsulation (MAP-E)", RFC 7597, 317 DOI 10.17487/RFC7597, July 2015, 318 . 321 [RFC7598] Mrugalski, T., Troan, O., Farrer, 322 I., Perreault, S., Dec, W., Bao, 323 C., Yeh, L., and X. Deng, "DHCPv6 324 Options for Configuration of 325 Softwire Address and Port-Mapped 326 Clients", RFC 7598, DOI 10.17487/ 327 RFC7598, July 2015, . 330 [RFC7599] Li, X., Bao, C., Dec, W., Ed., 331 Troan, O., Matsushima, S., and T. 332 Murakami, "Mapping of Address and 333 Port using Translation (MAP-T)", 334 RFC 7599, DOI 10.17487/RFC7599, 335 July 2015, . 338 9.2. Informative References 340 [I-D.ietf-softwire-map-deployment] Qiong, Q., Chen, M., Chen, G., 341 Tsou, T., and S. Perreault, 342 "Mapping of Address and Port 343 (MAP) - Deployment 344 Considerations", draft-ietf- 345 softwire-map-deployment-06 (work 346 in progress), June 2015. 348 Authors' Addresses 350 Chongfeng Xie 351 China Telecom Beijing Research Institute 352 Room 708 No.118, Xizhimenneidajie, xicheng District 353 Beijing, 100035 354 China 356 Phone: +86-10-58552116 357 EMail: xiechf@ctbri.com.cn 359 Chen Li 360 China Telecom Beijing Research Institute 361 Room 708 No.118, Xizhimenneidajie, xicheng District 362 Beijing, 100035 363 China 365 Phone: +86-10-58552116 366 EMail: lichen@ctbri.com.cn 367 Congxiao Bao 368 CERNET Center/Tsinghua University 369 Room 225, Main Building, Tsinghua University 370 Beijing, 100084 371 China 373 Phone: +86 10-62785983 374 EMail: congxiao@cernet.edu.cn 376 Guoliang Han 377 CERNET Center/Tsinghua University 378 Room 225, Main Building, Tsinghua University 379 Beijing 100084 380 CN 382 Phone: +86 10-62785983 383 EMail: bupthgl@gmail.com 385 Xing Li 386 CERNET Center/Tsinghua University 387 Room 225, Main Building, Tsinghua University 388 Beijing, 100084 389 China 391 Phone: +86 10-62785983 392 EMail: xing@cernet.edu.cn