idnits 2.17.1 draft-xli-v6ops-cernet-deployment-03.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 (October 17, 2017) is 2380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6144' is defined on line 450, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops X. Li 3 Internet-Draft C. Bao 4 Intended status: Informational G. Han 5 Expires: April 20, 2018 M. Sheng 6 CERNET Center/Tsinghua 7 University 8 October 17, 2017 10 CERNET deployment of IVI/MAP-T in an IPv6-only network 11 draft-xli-v6ops-cernet-deployment-03 13 Abstract 15 This document presents the China Education and Research Network 16 (CERNET)'s IPv4 as a Service (IPv4aaS) design, deployment and 17 operation experience. 19 The techniques used are IPv4/IPv6 stateless translation both in the 20 forms of single translation (IVI, for IPv6-only servers) and double 21 translation (MAP-T, for dual-stack clients). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 20, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Major Motivation . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. IPv4-as-a-Service Requirements . . . . . . . . . . . . . . 3 60 2. Architecture and Methodology . . . . . . . . . . . . . . . . . 4 61 2.1. Major Design Considerations . . . . . . . . . . . . . . . 4 62 2.2. Regulatory Considerations . . . . . . . . . . . . . . . . 4 63 2.3. Security Considerations . . . . . . . . . . . . . . . . . 5 64 2.4. Operational Considerations . . . . . . . . . . . . . . . . 5 65 2.4.1. Subnet for the Servers . . . . . . . . . . . . . . . . 5 66 2.4.2. Subnet for the Clients . . . . . . . . . . . . . . . . 5 67 2.5. End-User Experience Considerations . . . . . . . . . . . . 6 68 3. Design and Deployment . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Single stateless translation for servers - IVI . . . . . . 6 70 3.2. Double stateless translation for clients - MAP-T . . . . . 7 71 4. Observations and Experiences . . . . . . . . . . . . . . . . . 9 72 4.1. Effects on End-User . . . . . . . . . . . . . . . . . . . 9 73 4.2. Effects on Internal Staff . . . . . . . . . . . . . . . . 9 74 4.3. Effects on Business . . . . . . . . . . . . . . . . . . . 9 75 5. Summary: Post-mortem Report . . . . . . . . . . . . . . . . . 9 76 5.1. Deviations from IETF Documents . . . . . . . . . . . . . . 9 77 5.2. The Suggestions for the IPv6 Transition . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The China Education and Research Network (CERNET) is an academic 88 network in mainland China, with the universities, institutes and 89 schools as the customers. The student population in mainland China 90 is about 320 million and there are no enough public IPv4 addresses 91 available. The cloud computing, the mobile Internet and the Internet 92 of Things make the IPv4 address exhaustion situation even worse. Ten 93 years ago, we have deployed an IPv6-only backbone named CERNET2 and 94 eight years ago, we have developed the IPv4/IPv6 stateless 95 translation technology called IVI [RFC6219], which becomes the 96 proposed IETF standard of the IPv4/IPv6 stateless translation 97 [RFC6145], [RFC6052], etc. In order to improve the customer 98 experience for the IPv4-only applications and application with the 99 address literals embedded, we have developed double IPv4/IPv6 100 stateless translation technology called dIVI, which becomes the 101 mapping address and port with translation (MAP-T) [RFC7599]. This 102 document presents our experience of IPv4 as a Service (IPv4aaS), the 103 techniques used are IVI [RFC6145], [RFC6052] and [RFC6219] and a 104 slightly modified version of MAP-T [RFC7599]. 106 1.1. Major Motivation 108 In order to extend the service in the case of IPv4 address depletion, 109 we need to provide IPv6 services and the still keep the ability for 110 users to access the global IPv4 Internet. Therefore, IPv4 as a 111 Service (IPv4aaS) is a natural choice for the new campus network 112 connected to IPv6-only CERNET2. 114 1.2. IPv4-as-a-Service Requirements 116 The design requirements for IPv4aaS in CERNET are: 118 1. Deploy IPv6-only single stack network as large as possible in 119 order to reduce CAPEX and OPEX. 121 2. The clients should have the same user experience compared with 122 the dual-stack network with NAT44. 124 3. The IPv6-only servers should be able to serve the IPv4-only 125 clients in the Internet. 127 4. Make the use of the IPv4 public address as much efficient as 128 possible. 130 5. Provide a path to allow IPv6-only clients to communicate to the 131 IPv4 Internet. 133 6. For the scalability, resilience and security, prefer stateless 134 technologies. 136 2. Architecture and Methodology 138 2.1. Major Design Considerations 140 For CERNET, we have the following situation: 142 o There are two nation-wide backbones, CERNET is an IPv4 backbone 143 and CERNET2 is an IPv6-only backbone. 145 o Most of the campus networks are dual stack. The IPv4 interfaces 146 of the border router of the campus networks are connected to 147 CERNET and various commodity ISPs. The IPv6 interfaces of the 148 border router of the campus networks are connected to CERNET2. 150 o For special purpose subnets which are providing service for the 151 servers, the subnets can be dual stack, IPv4-only or IPv6-only. 152 The IPv6-only subnets are recommended. 154 o For general purpose subnets which are providing services for the 155 clients (both wired Ethernet and the WLAN with multiple SSID), the 156 dual stack is recommended. Since it is the only way to maximize 157 the satisfaction for the users using various operating systems 158 (Windows XP, Windows 7/8, OSX, Linux, iOS, Android, etc.) and 159 different applications (IPv4-only, dual stack and with address 160 literals). 162 o Since we are running an academic network, we encourage users to 163 try new technologies and make some part of the network as the 164 testbeds. 166 o Ten years experience of deploying IPv6-only CERNET2, we strongly 167 believe that the killer application of the IPv6 is the ability to 168 communicate the global IPv4 Internet and therefore the translation 169 technology should be the first choice. In addition, due to the 170 scalability, security and manageability considerations, the 171 stateless technology should be preferred. Those considerations 172 result in the development and deployment of IVI [RFC6145], 173 [RFC6052], [RFC6219] and MAP-T [RFC7599]. 175 2.2. Regulatory Considerations 177 The government requires server operators to detect the packet sender 178 by source IP (and port) and therefore stateless address mapping 179 technologies are preferred. This will dramatically reduce the volume 180 of material required to be held for logging compliance. 182 In addition, the stateless translation technology is preferred, since 183 IPv6 addresses in the IPv6 packets everywhere in the network contain 184 both the IPv6 and IPv4 address information without the requirement of 185 decapsulation. 187 2.3. Security Considerations 189 From operation point of view, single stack (IPv6-only) is easier for 190 ensuring the security compared with the dual stack. 192 The stateless mechanism can help for the trace back and identifying 193 the source addresses (and port). 195 The translation mechanism can help for configuring the access list 196 and rate-limiting without decapsulation. 198 2.4. Operational Considerations 200 The IPv4aaS in CERNET is mainly for deploying new networks. The 201 existing IPv4 and dual stack networks will not be changed. The 202 methods for upgrading the existing networks in order to release the 203 public IPv4 addresses will be discussed in future documents. 205 2.4.1. Subnet for the Servers 207 For subnets for the servers, The IPv6-only subnet with stateless 208 translation is recommended. The configuration is statically 209 performed. 211 2.4.2. Subnet for the Clients 213 For general purpose subnets for the clients, dual stack is 214 recommended, with DHCP for the IPv4 and SLAAC for the IPv6. There is 215 no issue for the DNSSEC operation. 217 If IPv6-only subnet is required, the configuration should be done via 218 DHCPv6 stateful mode with stateless or stateful IPv4/IPv4 translation 219 service [RFC6145], [RFC6052], [RFC6146] [RFC6219] and DNS64 220 [RFC6147]. Note that there are issues for the DNSSEC operation. 222 We don't recommend mixing SLAAC and DHCPv6 stateful in the same 223 subnet. 225 For the WLAN environment, the users can decide which subnet to use 226 among the IPv4-only, the dual stack and the IPv6-only (with 227 translation) by selecting different SSIDs. 229 2.5. End-User Experience Considerations 231 Due to the public IPv4 address depletion problem, the modern 232 applications can fully support NAT44. Therefore, the end-users will 233 be satisfied if the IPv4aaS provides the same service as NAT44 with 234 IPv4 address sharing. 236 Besides TCP and UDP, concerning other protocols for example ICMP 237 (ping), we found that the end-users will be satisfied if the IPv4aaS 238 provides the same service as NAT44 with IPv4 address sharing. 240 3. Design and Deployment 242 Before the IPv4 address depletion, CERNET/CERNET2 has reserved a /17 243 public IPv4 address prefix and several /40s IPv6 prefixes for the 244 IPv4/IPv6 stateless translation. The current implementations of both 245 IPv6-only servers and dual-stack clients are still using these 246 prefix. The topology is shown in Figure 1. 248 ------ ----- ------ 249 / \ ----- / \ / \ 250 | CERNET |-----| IVI |------| CERNET2 |--+--|IPv6-only| 251 \ IPv4 / ----- \ IPv6 / | \servers / 252 ------ ----- | ------ 253 | ------ 254 | ------ / \ 255 +--|MAP-T |---|Dual-stack| 256 | ------ \clients / 257 | ------ 258 | 259 | ------ 260 | ------ / \ 261 .--|MAP-T |---|Dual-stack| 262 | ------ \clients / 263 | ------ 264 | 266 Figure 1: CERNET/CERNET2 Translation Topology 268 3.1. Single stateless translation for servers - IVI 270 The single stateless translation for servers using IVI is 271 straightforward, as shown in Figure 2. 273 ------ ----- ------ 274 / The \ ----- / \ / The \ 275 | IPv4 |-----| IVI |------|IPv6-only|-----| IPv6 | 276 \Internet/ ----- \servers / \Internet/ 277 ------ ----- ------ 279 Figure 2: IVI 281 The corresponding IETF documents are [RFC6145], [RFC6052] and 282 [RFC6219]. 284 The authoritive A record is derived from IPv6-only servers AAAA 285 recorded and manually configured in the DNS server. 287 Thanks to the stateless technology, there are multiple 10G IVI 288 translators and load balancing can be easily achieved. 290 3.2. Double stateless translation for clients - MAP-T 292 The double stateless translation for clients is a modified version of 293 MAP-T [RFC7599]. Note that the original MAP-T is as shown in 294 Figure 3. 296 User N 297 Private IPv4 298 | Network 299 | 300 O--+---------------O 301 | | MAP-T CE | 302 | +-----+--------+ | 303 | NAPT44| MAP-T | | 304 | +-----+ | +-._ ,-------. .------. 305 | +--------+ | ,-' `-. ,-' `-. 306 O------------------O / \ O---------O / Public \ 307 / IPv6 only \ | MAP-T |/ IPv4 \ 308 ( Network --+ Border +- Network ) 309 \ / | Relay |\ / 310 O------------------O \ / O---------O \ / 311 | MAP-T CE | ;". ,-' `-. ,-' 312 | +-----+--------+ | ," `----+--' ------' 313 | NAPT44| MAP-T | |, | 314 | +-----+ | + IPv6 node(s) 315 | | +--------+ | (w/ v4-embedded-v6 address) 316 O---+--------------O 317 | 318 User M 319 Private IPv4 320 Network 322 Figure 3: MAP-T Architecture 324 For the campus network environment, there are some modifications for 325 the MAP-T 327 o The IPv4 address sharing algorithm in the MAP-T BR is moved into 328 MAP-T CE. Therefore the first translator (IVI in Figure 1) is 329 with the public IPv4 sharing ratio=1, and the 1:N address sharing 330 function is performed in the second translator (MAPT in Figure 1). 332 o The IPv4-converted IPv6 addresses and IPv4-translatable IPv6 333 addresses have the same prefix and prefix length [RFC6052]. 335 o There are no additional IPv4 address sharing in NAPT44 of the 336 MAP-T CE. 338 Based on the measurement statistics, the public IPv4 address sharing 339 ratio is configured to 1024. 341 The multiple 10G IVI translators are shared with the single 342 translation, the MAP-T translators are 1G equipment. We have 343 deployed MAP-T translators in more than 100 campus networks. 345 4. Observations and Experiences 347 4.1. Effects on End-User 349 For the IVI/MAP-T end-users in more than 100 campus networks, they 350 are satisfied with IPv4aaS. They did not notice that the services 351 are provided via IPv4/IPv6 single/double translation. 353 4.2. Effects on Internal Staff 355 For IPv6-only servers provide IPv4 service via IVI, the management 356 software is IPv6-only. Note that the IPv4 addresses managed in the 357 system is a subset in the IPv6 address space and this will 358 dramatically reduce the programming load, since there is no need to 359 treat IPv4 and IPv6 differently. 361 For Dual-stack clients access IPv4 Internet via MAP-T, the management 362 software is dual stack. The existing dual stack user management 363 software can be used. The upper link of the second translator is 364 IPv6-only, the IPv6 management software should be developed. Note 365 that the IPv4 addresses managed in the system is a subset in the IPv6 366 address space and this will dramatically reduce the programming load, 367 since there is no need to treat IPv4 and IPv6 differently. 369 4.3. Effects on Business 371 The IPv6-only server can provide the service directly for the IPv6 372 Internet and to the IPv4 Internet via IVI. Both CAPEX and OPEX are 373 reduced compared with the dual stack. 375 The service for the clients is via MAP-T with address sharing ratio 376 1024. This greatly reduce the requirements of the public IPv4 377 addresses for deploying new networks. 379 5. Summary: Post-mortem Report 381 We are satisfied with the IVI/MAP-T deployment for IPv4aaS. More 382 campus networks are expected to move in this direction. 384 5.1. Deviations from IETF Documents 386 The base specifications the IPv4aaS in the deployment are defined in 387 [RFC6145], [RFC6052], [RFC6146], [RFC6219], [RFC6147] and [RFC7599]. 388 As we discussed in this document, there are enhancements and 389 modifications which will be presented in future documents. 391 5.2. The Suggestions for the IPv6 Transition 393 Based on ten years experience, we found that IPv4aaS is a good model 394 for the IPv6 transition. 396 1. The new networks should be IPv6. 398 2. Use native IPv6 if possible. 400 3. Use single stateless translation (IVI) for the IPv6-only servers 401 and clients. 403 4. Use double stateless translation (MAP-T) for the dual-stack 404 clients. 406 5. The practical IPv6 transition path should be from double 407 translation to single translation and finally to native IPv6. 409 6. IANA Considerations 411 This specification does not require any IANA actions. 413 7. Security Considerations 415 There are no other special security considerations. 417 8. Acknowledgements 419 9. References 421 9.1. Normative References 423 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 424 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 425 DOI 10.17487/RFC6052, October 2010, 426 . 428 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 429 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 430 . 432 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 433 NAT64: Network Address and Protocol Translation from IPv6 434 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 435 April 2011, . 437 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 438 Beijnum, "DNS64: DNS Extensions for Network Address 439 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 440 DOI 10.17487/RFC6147, April 2011, 441 . 443 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 444 and T. Murakami, "Mapping of Address and Port using 445 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, 446 July 2015, . 448 9.2. Informative References 450 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 451 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 452 April 2011, . 454 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 455 China Education and Research Network (CERNET) IVI 456 Translation Design and Deployment for the IPv4/IPv6 457 Coexistence and Transition", RFC 6219, DOI 10.17487/ 458 RFC6219, May 2011, 459 . 461 Authors' Addresses 463 Xing Li 464 CERNET Center/Tsinghua University 465 Room 225, Main Building, Tsinghua University 466 Beijing, 100084 467 China 469 Phone: +86 10-62785983 470 EMail: xing@cernet.edu.cn 472 Congxiao Bao 473 CERNET Center/Tsinghua University 474 Room 225, Main Building, Tsinghua University 475 Beijing, 100084 476 China 478 Phone: +86 10-62785983 479 EMail: congxiao@cernet.edu.cn 480 Guoliang Han 481 CERNET Center/Tsinghua University 482 Room 225, Main Building, Tsinghua University 483 Beijing 100084 484 CN 486 Phone: +86 10-62785983 487 EMail: bupthgl@gmail.com 489 Maojia Sheng 490 CERNET Center/Tsinghua University 491 Room 225, Main Building, Tsinghua University 492 Beijing 100084 493 CN 495 Phone: +86 10-62785983 496 EMail: ynsfsmj@foxmail.com