idnits 2.17.1 draft-sarikaya-softwire-v6migration4cloud-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 17, 2011) is 4575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VM' is mentioned on line 260, but not defined == Missing Reference: 'Server' is mentioned on line 260, but not defined == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 383, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-03 ** Downref: Normative reference to an Informational draft: draft-xli-behave-divi (ref. 'I-D.xli-behave-divi') == Outdated reference: A later version (-04) exists of draft-sakura-6rd-datacenter-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track October 17, 2011 5 Expires: April 19, 2012 7 Dual Stack Lite and 4rd for Migrating Cloud Networks to IPv6 8 draft-sarikaya-softwire-v6migration4cloud-00.txt 10 Abstract 12 This document specifies how Dual Stack Lite or 4rd can be used to 13 support IPv4 users in a cloud network that is IPv6 based. The cloud 14 network is IPv6 only which simplifies the network operation and 15 management. IPv4 users are supported either one of the transition 16 technologies of DS-Lite or 4rd. This protocol is ideal for new cloud 17 deployments since no new public IPv4 addresses are needed. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 19, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. DS-Lite Architecture . . . . . . . . . . . . . . . . . . . 4 58 4.2. 4rd Architecture . . . . . . . . . . . . . . . . . . . . . 5 59 5. DS-Lite Operation . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. DS-Lite for Datacenter Considerations . . . . . . . . . . 8 61 6. 4rd Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. 4rd for Datacenter Considerations . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 10.2. Informative references . . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 Data center/cloud networks are being increasingly used by telecom 74 operators as well as by enterprises. Currently these networks are 75 using IPv4 addressing. However due to the depletion of public IPv4 76 addresses this practice can not go on indefinitely. 78 In this document we argue that data center/cloud network should use 79 IPv6. If IPv6 is used then it becomes an issue how to support IPv4 80 users which we address in this document. For this purpose dual stack 81 lite [RFC6333] or 4rd [I-D.murakami-softwire-4rd], 82 [I-D.xli-behave-divi], [I-D.despres-softwire-4rd] can be used. 84 Dual stack lite has two elements: Basic Bridging BroadBand (B4) 85 element which receives privately addressed IPv4 packets from the 86 users and encapsulates them in IPv6 and sends them to the Dual Stack 87 Lite Address Family Transition Router (AFTR) element which is in 88 charge of a central Network Address Translation (NAT) for the whole 89 cloud network. Packets received from public IPv4 network by AFTR are 90 tunneled to the destination B4s after NAT operation in IPv6. B4 91 decapsulates the packet and delivers it to the user. 93 4rd has two elements: Customer Edge (CE) device/router receives 94 privately addressed IPv4 packets from the users and after a NAT 95 operation sends them to the Border Relay (BR) either encapsulated 96 using IPv4-in-IPv6 encapsulation or translated into IPv6. BR 97 decapsulates or translates the packet before sending to IPv4 network. 98 The operation is stateless and the next packet from CE may be sent to 99 another BR. 101 In current data center deployments IPv4 is being used and 102 [I-D.sakura-6rd-datacenter] describes how IPv6 service can be 103 supported. IPv6 Rapid Deployment (6rd) [RFC5969] is used where 6rd 104 CE is located at the servers and 6rd Border Relay is located at the 105 backbone network. 107 2. Terminology 109 This document uses the terminology defined in [RFC6333] and in 110 [RFC6333] or 4rd [I-D.murakami-softwire-4rd], [I-D.xli-behave-divi], 111 [I-D.despres-softwire-4rd]. 113 3. Requirements 115 This section states requirements on data center/cloud network IPv4 116 and IPv6 support protocol. 118 Data center/cloud network MUST support IPv6 natively due to the 119 depletion of public IPv4 addresses. 121 IPv4 support SHOULD enable direct routing among the geographically 122 distributed data centers of the same network. 124 IPv4 support SHOULD minimize the use of public IPv4 addresses. 125 Network address translation (NAT) could be used on the customer side. 127 4. Architecture 129 Data center/cloud networks consists of thosands of servers in one 130 center and usually an organization operates more than one data center 131 each connected by a backbone IP network. Each server runs multiple 132 Virtual Machines (VM) each with its own IP address. Data center 133 could be Layer-2 based or Layer-3 based. 135 Datacenter is Layer-3 based if packets are routed among the subnets, 136 e.g. in between the racks and switched in a subnet, e.g. inside a 137 rack. Layer-3 based datacenter networks scale well for address 138 resolution protocols like ARP but they make is difficult to move 139 Virtual Machines as some sort of tunneling would be needed 140 [I-D.wkumari-dcops-l3-vmmobility]. 142 Datacenter is Layer-2 based if packets are switched inside a rack and 143 bridged among the racks, i.e. completely in Layer-2. From IP point 144 of view the nodes are connected to a single link. Layer-2 based 145 networks make it easy to move Virtual Machines from one server to 146 another but on the other hand they don't scale well for address 147 resolution protocols like ARP [I-D.narten-armd-problem-statement]. 149 In this document we assume L2-based datacenter/cloud network and 150 design Dual Stack Lite protocol, see Figure 1 and 4rd, see Figure 2. 152 4.1. DS-Lite Architecture 154 Virtual Machines connect to the network using a virtual interface 155 supported by the guest operating system. These VMs are mapped to the 156 physical servers in the rack. In VM based data center/cloud networks 157 B4 for VMs are placed in the guest OS using operating system patch 158 similar to 6rd CE in [I-D.sakura-6rd-datacenter]. 160 Some data center/cloud networks do not employ Virtual Machines. 161 These networks are server-based. In server-based data center/cloud 162 networks, B4 is placed in the access router. In the storage area 163 network B4 is also placed in the gateway router. 165 AFTR is at the border of IPv6 backbone. At B4s IPv4 packets are 166 tunneled to AFTR and then AFTR decapsulates and performs the NAT 167 operation and sends out IPv4 packet to the public internet, see 168 Figure 1. 170 .--. .--. 171 _(. `) _(. `) 172 _( IPv6 `)_ _( IPv4 `)_ 173 ( Internet `) ( Internet `) 174 ( ) ( ) 175 `--(_______)---' `--(_______)---' 176 | | 177 \ +----------+ 178 \ | AFTR | 179 \ +----------+ 180 \ | 181 \ .--. | 182 +----------+ (. `) / 183 | Cloud | _( IPv6 `)/_ +----------+ 184 | | ( Backbone `) |B4 on GW | 185 | Network |====( )====|----------| 186 +----------+ `--(_______)---' | Storage | 187 || | Network | 188 || +----------+ 189 +-------------+ 190 |Access Router| 191 |-------------| 192 | Aggregation | 193 | Switch | 194 +-------------+ 195 | 196 [VM] B4|-|L2 Network |- [Server] 197 [VM] on | | | 198 [VM] guest OS | [Server] [Server] 200 Figure 1: Architecture of DS-Lite for Cloud 202 4.2. 4rd Architecture 204 In VM based data center/cloud networks Customer Edge router of 4rd 205 for VMs are placed in the guest OS using operating system patch 206 similar to 6rd CE in [I-D.sakura-6rd-datacenter]. 208 Some data center/cloud networks do not employ Virtual Machines. 209 These networks are server-based. In server-based data center/cloud 210 networks, CE is placed in the access router. In the storage area 211 network CE is also placed in the gateway router. 213 CEs assign private IPv4 addresses to the virtual machines or users 214 and perform NAT towards the backbone network. On the outgoing 215 interface, CEs may share public IPv4 addresses with port space 216 sharing if there are not enough public IPv4 addresses to assign to 217 the individual CEs. Public IPv4 address sharing is optional, CEs may 218 be configured with a unique IPv4 public address. 220 4rd Border Relay is at the border of IPv6 backbone. There could be 221 more than one BRs and they all can have a single anycast address 222 which CEs are configured with. At CEs IPv4 packets are sent 223 encapsulated with an IPv6 header. In case of translation, IPv4 224 packet is translated into an IPv6 packet [RFC6145] and then sent to 225 BR, see Figure 2. 227 At the BR, IPv6 packet is received. In case of encapsulation, the 228 packet is decapsulated and then sent to IPv4 network. In case of 229 translation, BR translates IPv6 packet into IPv4 packet [RFC6145] and 230 then sends it to IPv4 network. 232 .--. .--. 233 _(. `) _(. `) 234 _( IPv6 `)_ _( IPv4 `)_ 235 ( Internet `) ( Internet `) 236 ( ) ( ) 237 `--(_______)---' `--(_______)---' 238 | | 239 \ +----------+ 240 \ | BR | 241 \ +----------+ 242 \ | 243 \ .--. | 244 +----------+ (. `) / 245 | Cloud | _( IPv6 `)/_ +----------+ 246 | | ( Backbone `) |CE on GW | 247 | Network |====( )====|----------| 248 +----------+ `--(_______)---' | Storage | 249 || | Network | 250 || +----------+ 251 +-------------+ 252 |Access Router| 253 |-------------| 254 | Aggregation | 255 | Switch | 256 +-------------+ 257 | 258 [VM] CE|-|L2 Network |- [Server] 259 [VM] on | | | 260 [VM] guest OS | [Server] [Server] 262 Figure 2: Architecture of 4rd for Cloud 264 5. DS-Lite Operation 266 AFTR IPv6 address must be provisioned in B4 elements. DHCPv6 can be 267 used for this purpose. B4 requests AFTR FQDN using the AFTR-Name 268 DHCPv6 Option defined in [RFC6334]. B4 gets IPv6 address from the 269 DNS using the AFTR-Name DHCPv6 Option and configures IPv4-in-IPv6 270 tunnel based on this address. 272 B4 operates its own DHCPv4 server and hands out private IPv4 273 addresses to the users. It is the default IPv4 router and advertizes 274 itself as the DNS server. It should also be DNS proxy and serves 275 IPv4 requests and sends the requests using IPv6 to the DNS servers. 277 B4 encapsulates IPv4 packets and sends them to AFTR. Fragmentation 278 and reassembly of these packets are as discussed in Section 5.3 of 280 [RFC6333]. 282 Users in the same data center may communicate with others in the same 283 center via certain applications like Skype. Local routing of IPv4 284 packets generated by such applications is needed at B4 to avoid a 285 round trip to AFTR. 287 AFTR receives IPv4 packets tunneled by B4s and decapsulates them. 288 AFTR performs NAT operation on IPv4 before forwarding it to public 289 IPv4 network. NAT binding table is extended with IPv6 source 290 address, i.e. WAN side address of the B4 which sent this packet. 292 For packets coming back from the Internet, AFTR does a reverse lookup 293 in the extended IPv4 NAT binding table and extracts IPv6 destination 294 address of the B4 and tunnels IPv4 packet to it. 296 5.1. DS-Lite for Datacenter Considerations 298 In DS-Lite B4 to B4 communication always goes through AFTR. This 299 could incur additional delays in datacenter/cloud networks because 300 such traffic is expected to be high, e.g. VMs/server may need 301 constant communication with the storage area network which is also 302 part of the same data center. 304 IPv6 hardware support in current switches is poor compared with IPv4. 305 Most commonly used switches reserve for IPv6 half of the memory 306 reserved for IPv4 and thus they are slow in processing IPv6 packets. 308 6. 4rd Operation 310 Instead of public IPv4 address sharing among the CEs of a data 311 center, each CE is assigned a unique public IPv4 address. This 312 simplifies port usage when doing NAT operation. IPv4 address is 313 derived from domain IPv4 prefix which is used by the BRs to receive 314 incoming traffic from IPv4 internet. 316 CEs configure their WAN interface (IPv6 backbone) using regular means 317 such as SLAAC, DHCPv6, etc. and get an IPv6 prefix assigned. Each CE 318 is configured with one or several mapping rules. Each CE uses a 319 reserved interface ID as part of its IPv6 source address to enable 320 marking 4rd traffic and also to effectively create a 4rd interface on 321 its WAN side. 323 On the LAN side (VMs or users), CE is dual stack and supports IPv4 by 324 assigning private IPv4 addresses. When CE receives an IPv4 packet it 325 performs NAT on the packet. CE looks up the destination IPv4 address 326 in the mapping rules. If the prefix matches domain IPv4 prefix then 327 this packet sent to another CE. CE derives an IPv6 destination 328 address from IPv4 destination address. Otherwise this packet is sent 329 to BR. CE derives a BR anycast address as destination IPv6 address. 330 Next the packet is either encapsulated in IPv6 [RFC2473] or 331 translated from IPv4 to IPv6 packet [RFC6145]. 333 BR receives IPv6 packet and checks to see if it is 4rd packet, either 334 using the interface ID of the source IPv6 address or looking up the 335 source IPv4 address in the mapping rules. BR decapsulates or 336 translates IPv6 packet and forwards resulting IPv4 packet using IPv4 337 interface. 339 For an incoming IPv4 packet BR checks if the destination IPv4 address 340 has a match in the mapping rules. Next, BR generates CE IPv6 address 341 from IPv4 destination address. BR either encapsulates IPv4 packet in 342 IPv6 and or translates it into IPv6 and then sends it to CE. 344 When CE receives an IPv6 packet it checks to see if IPv4 source 345 address matches a mapping rule, i.e. the packet is coming from 346 another CE or IPv6 source address matches BR IPv6 address, i.e. the 347 packet is coming from BR. CE decapsulates or translates the packet 348 to obtain IPv4 packet and then forwards it on the LAN interface. 350 6.1. 4rd for Datacenter Considerations 352 In 4rd CE to CE communication does not go through BR. This is a 353 significant advantage of 4rd over DS-Lite especially in data center 354 networks. 356 4rd CE and BR process each packet using 4rd mapping rules. There 357 could be over 1000 mapping rules. This per packet processing 358 naturally slows down users access to the internet especially at the 359 CEs which are much less resourceful than BRs. 361 7. Security Considerations 363 TBD. 365 8. IANA Considerations 367 TBD. 369 9. Acknowledgements 371 TBD. 373 10. References 375 10.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 381 June 1999. 383 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 384 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 385 October 2010. 387 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 388 Algorithm", RFC 6145, April 2011. 390 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 391 Stack Lite Broadband Deployments Following IPv4 392 Exhaustion", RFC 6333, August 2011. 394 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 395 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 396 RFC 6334, August 2011. 398 [I-D.murakami-softwire-4rd] 399 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 400 Deployment on IPv6 infrastructure - protocol 401 specification", draft-murakami-softwire-4rd-01 (work in 402 progress), September 2011. 404 [I-D.despres-softwire-4rd] 405 Despres, R., "IPv4 Residual Deployment across IPv6-Service 406 networks (4rd) A NAT-less solution", 407 draft-despres-softwire-4rd-00 (work in progress), 408 October 2010. 410 [I-D.xli-behave-divi] 411 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 412 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03 413 (work in progress), July 2011. 415 10.2. Informative references 417 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 418 Infrastructures (6rd) -- Protocol Specification", 419 RFC 5969, August 2010. 421 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 422 IPv6 Specification", RFC 2473, December 1998. 424 [I-D.narten-armd-problem-statement] 425 Narten, T., "Problem Statement for ARMD", 426 draft-narten-armd-problem-statement-00 (work in progress), 427 July 2011. 429 [I-D.sakura-6rd-datacenter] 430 Tsuchiya, S., Townsley, M., and S. Ohkubo, "IPv6 Rapid 431 Deployment (6rd) in a Large Data Center", 432 draft-sakura-6rd-datacenter-01 (work in progress), 433 July 2011. 435 [I-D.wkumari-dcops-l3-vmmobility] 436 Kumari, W. and J. Halpern, "Virtual Machine mobility in L3 437 Networks.", draft-wkumari-dcops-l3-vmmobility-00 (work in 438 progress), August 2011. 440 [sourceforge] 441 Source Forge, "OpenWRT DS-Lite Software", February 2011. 443 Author's Address 445 Behcet Sarikaya 446 Huawei USA 447 5340 Legacy Dr. Building 3 448 Plano, TX 75024 450 Email: sarikaya@ieee.org