idnits 2.17.1 draft-ybai-v6ops-ipv6-for-openstack-04.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 abstract seems to contain references ([RFC1918]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 date (September 20, 2016) is 2772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Bai 3 Internet-Draft C. Bao 4 Intended status: Informational CERNET Center/Tsinghua University 5 Expires: March 24, 2017 K. Yin 6 Cisco Systems 7 X. Li 8 CERNET Center/Tsinghua University 9 September 20, 2016 11 IPv4/IPv6 Transition Practice in OpenStack 12 draft-ybai-v6ops-ipv6-for-openstack-04 14 Abstract 16 OpenStack is a free and open-source software cloud computing 17 platform. It is primarily deployed as an infrastructure as a service 18 (IaaS) solution. However, OpenStack is designed mainly for IPv4, it 19 internally uses [RFC1918] addresses and heavily relies on NAT to map 20 RFC1918 addresses to public IPv4 addresses known as floating IP 21 addresses for the external access. Due to the different nature of 22 IPv6 and IPv4, the IPv6 support for the OpenStack is still in the 23 early stage. In this document, two mechanisms are presented to 24 provide IPv4/IPv6 dual stack external access for the OpenStack, one 25 scenario is internal IPv4 and uses stateful IPv4/IPv6 translator for 26 the external IPv6 access, and another scenario is internal IPv6 and 27 uses stateless IPv4/IPv6 translation for the external IPv4 access. 28 Both mechanisms have been deployed in CERNET and providing services 29 to the global IPv4/IPv6 Internet. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 24, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. IPv4/IPv6 access to IPv4-only Cloud . . . . . . . . . . . . . 3 67 2.1. Current IPv4 OpenStack Network Structures . . . . . . . . 3 68 2.2. IPv4 Accessibility directly . . . . . . . . . . . . . . . 3 69 2.3. IPv6 Accessibility via IPv4/IPv6 translator . . . . . . . 4 70 3. IPv4/IPv6 access to IPv6-only Cloud . . . . . . . . . . . . . 5 71 3.1. Analysis and recommendations for the Internal Structure 72 of IPv6 OpenStack . . . . . . . . . . . . . . . . . . . . 5 73 3.2. IPv4 Accessibility via Translation . . . . . . . . . . . 6 74 3.2.1. 1:N Stateless Translation . . . . . . . . . . . . . . 7 75 3.2.2. HTTP Redirection for Web Servers . . . . . . . . . . 8 76 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The concept of cloud is growing rapidly, and open-source cloud 86 platforms such as OpenStack are more and more popular. The network 87 models inside OpenStack cloud requires public IPv4 addresses for 88 external access. It's foreseeable that the exhaustion of IPv4 global 89 addresses would be one of the bottlenecks on deploying clouds in the 90 future. While the important and urgency of IPv4/IPv6 transition has 91 been studied widely, the support of IPv6 in OpenStack is still in its 92 early stage. For example, the private addresses assigned to 93 instances are not favored in IPv6, and the concepts like "Floating 94 IP" have no counterparts in IPv6. Therefore, the structure of 95 OpenStack should be extended to meet the need of IPv6 clouds. This 96 document presents the analysis to extend OpenStack to IPv6. Based on 97 the extensions presented in this document, it can be shown that using 98 stateful IPv4/IPv6 translator, the external IPv6-only hosts can 99 access the existing IPv4-only VMs in OpenStack. We have installed a 100 new module in OpenStack which enables internal IPv6 support for 101 OpenStack. By using stateless IPv4/IPv6 translator, external 102 IPv4-only hosts can access the IPv6-only VMs in OpenStack. 104 2. IPv4/IPv6 access to IPv4-only Cloud 106 2.1. Current IPv4 OpenStack Network Structures 108 Current IPv4 OpenStack network structure can be described as follows. 109 Rather than directly connect to public network, VM instances are 110 resided in "Private networks" under their respective tenants and are 111 assigned with private addresses. To be accessed from the external 112 networks, those private networks should be linked to public networks 113 via a virtual device called "virtual router". Some key concepts and 114 typical techniques of this structure are: 116 VLAN: VLAN are used to accomplish the segregation of tenants, each 117 tenant receives one VLAN tag. 119 Subnets: Each tenant can further divide their networks into 120 "subnets" with different IP address pool. 122 NAT: When instances need to access external networks, they share a 123 public address that is owned by the virtual router. 125 Floating IP: This is the core concept of OpenStack network 126 structure. When instances need to be accessed from external 127 networks, each instance associates its private address with a 128 public address. The private address is mapped to the public 129 address on outgoing flow and the public address is mapped to the 130 private address on ingoing flow, and the mapping is implemented by 131 the virtual router. 133 2.2. IPv4 Accessibility directly 135 In this scenario, instances without Floating IPs could access 136 external IPv4 Internet via NAT as shown in Figure 1. Here, 137 40.40.40.40 is the address of the gateway of the virtual router, and 138 30.30.30.30 is the server that instance want to access. Port1 and 139 port2 are two different ports, the dynamic mapping relationship is 140 maintained by the virtual router. 142 +------------------+--------------+-----------------+ 143 | |Internal IPv4 |External IPv4 | 144 +------------------+--------------+-----------------+ 145 |src(IPv4 Cloud) |10.0.0.1:port1|40.40.40.40:port2| 146 +------------------+--------------+-----------------+ 147 |dst(IPv4 Internet)|30.30.30.30:80|30.30.30.30:80 | 148 +------------------+--------------+-----------------+ 149 40.40.40.40 is the gateway of the router 151 Figure 1: IPv4 cloud access the IPv4 Internet 153 With Floating IP, IPv4 Internet can access the VM instances as shown 154 in Figure 2. Here, address 10.0.0.1 is associated with address 155 40.40.40.41, their static mapping is implemented in the virtual 156 router. 158 +------------------+-----------------+-----------------+ 159 | |Internal cloud |External cloud | 160 +------------------+-----------------+-----------------+ 161 |src(IPv4 Internet)|30.30.30.30:port1|30.30.30.30:port1| 162 +------------------+-----------------+-----------------+ 163 |dst(IPv4 Cloud) |10.0.0.1:80 |40.40.40.41:80 | 164 +------------------+-----------------+-----------------+ 166 Figure 2: IPv4 Internet access IPv4 cloud 168 2.3. IPv6 Accessibility via IPv4/IPv6 translator 170 This scenario corresponds to the Scenario 3 defined in [RFC6144]: 171 IPv6 Internet accesses IPv4 network, where the cloud is considered as 172 an IPv4 network. 174 As described in [RFC6052], [RFC6145], [RFC6146] and [RFC6147], the 175 IPv6 prefix, an IPv4 pool to represent the external IPv6 hosts, the 176 pool for the floating IP, and the DNS AAAA record to represent 177 IPv4-converted floating IP are configured. The example is shown in 178 Figure 3, where the IPv6 prefix=2001:da8:e164::/48, the IPv4 pool to 179 represent the external IPv6 hosts=202.38.97.0/24, the pool for the 180 floating IP=121.194.167.196/24. 182 +------------------+-------------------------+-------------------------+ 183 | |External IPv6 |Xlate IPv6 side | 184 +------------------+-------------------------+-------------------------+ 185 |src(IPv6 Internet)|2001:250:3:0:7a26:cbff:: |2001:da8:e164:ca26:6118::| 186 |port |random port |random port | 187 +------------------+-------------------------+-------------------------+ 188 |dst(IPv4 Cloud) |2001:da8:e164:79c2:a7c4::|2001:da8:e164:79c2:a7c4::| 189 |port |80 |80 | 190 +------------------+-------------------------+-------------------------+ 192 (cont.) 193 +------------------+---------------+-------------+ 194 | |Xlate IPv4 side|Internal IPv4| 195 +------------------+---------------+-------------+ 196 |src(IPv6 Internet)|202.38.97.24 |202.38.97.24 | 197 |port |random port |random port | 198 +------------------+---------------+-------------+ 199 |dst(IPv4 Cloud) |121.194.167.196|10.10.1.5 | 200 |port |80 |80 | 201 +------------------+---------------+-------------+ 203 Figure 3: IPv6 Internet accesses IPv4 Cloud 205 In this scenario, IPv6 Internet could gain the ability to access 206 those IPv4 clouds, as long as the instances are associated with 207 Floating IPs. 209 3. IPv4/IPv6 access to IPv6-only Cloud 211 3.1. Analysis and recommendations for the Internal Structure of IPv6 212 OpenStack 214 Since the internal support for IPv6 on OpenStack is still in its very 215 early stage, the IPv6 extension must be developed inside the 216 OpenStack cloud. The building blocks for the extension includes the 217 IPv6 address assignment and the floating IPv4 equivalent mechanisms. 218 For address assignment, several different mechanisms like DHCPv6 and 219 SLAAC could be used. For external IPv6 access, three possible 220 solutions could be used, they're NAT66 (like NPT66 defined in 221 [RFC6296]), ND Proxy (defined in [RFC4389]) and enabling 222 autoconfiguration of the IPv6 routing protocols (OSPF, BGP). 224 For NAT66, private addresses like ULA could be used in internal 225 network, while they're associated to a public address, and this 226 structure is similar to the IPv4 structure. However, as NAT is 227 deprecated in IPv6 to ensure end-to-end transparency, this scheme is 228 strongly opposed by IPv6 community. 230 For ND Proxy, based on the hierarchical address structure, the proxy 231 rules can be set at the edge of the cloud. Therefore, the router 232 interface will take the responsibility to respond all the neighbour 233 discovery request for internal networks. At the current stage, it is 234 considered that this structure requires minimum changes to both the 235 OpenStack internal structure, as well as the IPv6 architecture. 237 For enabling and autoconfiguration of the IPv6 routing protocols 238 (OSPF, BGP), the virtual router of OpenStack may interact with the 239 external routers to exchange the routing information to create 240 routes. However, the function of virtual router in OpenStack is 241 based on Linux Kernel, and support for a complicated router protocol 242 would be overkilling for those virtual routers. 244 Therefore, it is clear that: 246 1. The NAT66 is almost identical to the current OpenStack IPv4 247 network structure, while the ND proxy and routing protocol are 248 not. 250 2. The NAT66 doesn't maintain the end-to-end transparency in IPv6, 251 while ND proxy and routing protocol do. 253 3. The NAT66 scheme will use ULA address inside the cloud, while ND 254 proxy and routing protocol are using global IPv6 addresses. 256 4. For ND Proxy, any global address with prefix longer than /64 257 could be used and therefore the SLAAC should not be used. 259 5. Routing protocol needs interation with the upstream router, while 260 NAT66 and ND proxy do not. 262 As a conclusion, we recommend ND Proxy as the best solution among the 263 three mentioned above, as it requires the minimum changes to both 264 internal and external networks, and no additional configurations are 265 required on upstream router. 267 3.2. IPv4 Accessibility via Translation 269 This scenario corresponds to Scenario 2 defined in [RFC6144], where 270 IPv6 Internet can access IPv6 cloud directly, and IPv4 Internet can 271 access IPv6 cloud using stateless translator. Using the ND proxy 272 mechanism described in Section 3.1, the IPv6 Internet Access IPv6 273 Cloud and the IPv4 Internet Access IPv6 Cloud are shown in Figure 4 274 and Figure 5, respectively. 276 +------------------+------------------------+------------------------+ 277 | |External IPv6 |Internal IPv6 | 278 +------------------+------------------------+------------------------+ 279 |src(IPv6 Internet)|2001:250:3:0:7a26:cbff::|2001:250:3:0:7a26:cbff::| 280 |port |random port |random port | 281 +------------------+------------------------+------------------------+ 282 |dst(IPv6 Cloud) |2001:250:ca26:6f05::400f|2001:250:ca26:6f05::400f| 283 |port |80 |80 | 284 +------------------+------------------------+------------------------+ 286 Figure 4: IPv6 Internet accesses IPv6 Cloud 288 +------------------+-------------+--------------------+ 289 | |External IPv4|Internal IPv6 | 290 +------------------+-------------+--------------------+ 291 |src(IPv4 Internet)|30.30.30.30 |2001:250:1e1e:1e1e::| 292 |port |random port |random port | 293 +------------------+-------------+--------------------+ 294 |dst(IPv6 Cloud) |202.38.111.5 |2001:250:ca26:6f05::| 295 |port |80 |80 | 296 +------------------+-------------+--------------------+ 298 Figure 5: IPv4 Internet accesses IPv6 Cloud 300 3.2.1. 1:N Stateless Translation 302 Due to the IPv4 address depletion, the public IPv4 addresses need to 303 be shared for the cloud environment. Using the method described in 304 [I-D.bcx-address-fmt-extension], the IPv4 address sharing ratio can 305 be achieved as high as 4096. The example is shown in Figure 6. 307 +------------------+-------------+-------------------------+ 308 | |External IPv4|Internal IPv6 | 309 +------------------+-------------+-------------------------+ 310 |src(IPv4 Internet)|30.30.30.30 |2001:250:1e1e:1e1e:: | 311 |port |random port |random port | 312 +------------------+-------------+-------------------------+ 313 |dst1(IPv6 Cloud) |202.38.111.5 |2001:250:ca26:6f05:4000::| 314 |port |80 |80 | 315 +------------------+-------------+-------------------------+ 316 |dst2(IPv6 Cloud) |202.38.111.5 |2001:250:ca26:6f05:4001::| 317 |port |81 |81 | 318 +------------------+-------------+-------------------------+ 319 dst1 and dst2 share the common IPv4 global addresses 320 202.38.111.5 by multiplexing ports. 322 Figure 6: IPv4 Internet Access IPv6 Cloud with IPv4 address sharing 324 3.2.2. HTTP Redirection for Web Servers 326 However, this address format limits the use of port in instances, for 327 example, the suffix of the port may be fixed to the offset defined in 328 the address. For a certain server, rather than use the standard port 329 numbers like 80 for HTTP server, the server must use non standard 330 ports like 81 or 82. To solve this problem, redirection could be 331 used for web servers. For web server, translator would look up the 332 domain name, then redirect to the corresponding VM instance. In this 333 way, different cloud servers could share the same IPv4 address and 334 the same (standard) port to provide service. An example is shown in 335 Figure 7. 337 +------------------+---------------+-------------------------+ 338 | |External IPv4 |Internal IPv6 | 339 +------------------+---------------+-------------------------+ 340 |src(IPv4 Internet)|30.30.30.30 |2001:250:1e1e:1e1e:: | 341 |port |random port |random port | 342 +------------------+---------------+-------------------------+ 343 |dst1(IPv6 Cloud) |202.38.111.5 |2001:250:ca26:6f05:4001::| 344 |port |80 |80 | 345 |domain name |vm1.example.com|vm1.example.com | 346 +------------------+---------------+-------------------------+ 347 |dst2(IPv6 Cloud) |202.38.111.5 |2001:250:ca26:6f05:4002::| 348 |port |80 |80 | 349 |domain name |vm2.example.com|vm2.example.com | 350 +------------------+---------------+-------------------------+ 351 dst1 and dst2 share the common IPv4 global addresses 352 202.38.111.5 and standard port 80, they provide services by 353 standard port 80. 355 Figure 7: IPv4 Internet Access IPv6 Cloud with HTTP redirection 357 4. Summary 359 In current IPv4-only OpenStack, by using extended translation 360 mechanisms, IPv6 Internet could access IPv4 cloud with little 361 modification inside the cloud, while native IPv4 accessibility is 362 remained. By extending IPv6 support in OpenStack, including address 363 assignment mechanisms and ND Proxy, IPv6 in OpenStack cloud is 364 enabled. By deploying improved translators and proxies, the 365 IPv6-only cloud can provide services like SSH (in the case of IPv4 366 address sharing, using address plus port) and HTTP (in the case of 367 IPv4 address sharing, using address plus port directly or DNS with 368 HTTP redirect) to both native IPv6 and IPv4 with IPv4 address sharing 369 ability. 371 5. Security Considerations 373 This document does not introduce any new security considerations. 375 6. IANA Considerations 377 None. 379 7. Acknowledgments 381 The authors would like to acknowledge the following contributors of 382 this document: Rong Jin, Qiuhan Ding and Weicai Wang. 384 8. Normative References 386 [I-D.bcx-address-fmt-extension] 387 Bao, C. and X. Li, "Extended IPv6 Addressing for Encoding 388 Port Range", draft-bcx-address-fmt-extension-02 (work in 389 progress), October 2011. 391 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 392 and E. Lear, "Address Allocation for Private Internets", 393 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 394 . 396 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 397 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 398 2006, . 400 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 401 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 402 DOI 10.17487/RFC6052, October 2010, 403 . 405 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 406 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 407 April 2011, . 409 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 410 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 411 . 413 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 414 NAT64: Network Address and Protocol Translation from IPv6 415 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 416 April 2011, . 418 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 419 Beijnum, "DNS64: DNS Extensions for Network Address 420 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 421 DOI 10.17487/RFC6147, April 2011, 422 . 424 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 425 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 426 . 428 Authors' Addresses 430 Yi Bai 431 CERNET Center/Tsinghua University 432 Room 225, Main Building, Tsinghua University 433 Beijing 100084 434 CN 436 Phone: +86 10-62785983 437 Email: yibai.thu@gmail.com 439 Congxiao Bao 440 CERNET Center/Tsinghua University 441 Room 225, Main Building, Tsinghua University 442 Beijing 100084 443 CN 445 Phone: +86 10-62785983 446 Email: congxiao@cernet.edu.cn 448 Kevin Yin 449 Cisco Systems 450 No. 2 Jianguomenwai Ave, Chaoyang District 451 Beijing 100022 452 China 454 Phone: +86-10-8515-5094 455 Email: kyin@cisco.com 457 Xing Li 458 CERNET Center/Tsinghua University 459 Room 225, Main Building, Tsinghua University 460 Beijing 100084 461 CN 463 Phone: +86 10-62785983 464 Email: xing@cernet.edu.cn