idnits 2.17.1 draft-zhou-v4v6tran-mobile-use-case-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2010) is 4960 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.huang-behave-pnat-01' is defined on line 426, but no explicit reference was found in the text -- No information found for draft-huang-behave-pnat-01 - is the name correct? -- No information found for draft-softwire-dual-stack-lite-06 - is the name correct? -- No information found for draft-softwire-gateway-init-ds-lite-00 - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Zhou, Ed. 3 Internet-Draft T. Taylor 4 Intended status: Informational Huawei Technologies 5 Expires: March 21, 2011 September 17, 2010 7 IPv6 Transition Use Case For a Large Mobile Network 8 draft-zhou-v4v6tran-mobile-use-case-00 10 Abstract 12 This document describes an use case for migrating from IPv4 to IPv6 13 in a very large mobile network. Its purpose is to enhance general 14 understanding of the challenges associated with the migration of such 15 a network to IPv6 operation. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 21, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Overview of the Mobile Network Architecture . . . . . . . . . 3 54 3. Approaches To IPv4 / IPv6 Coexistence . . . . . . . . . . . . 6 55 3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity 56 With Limited Public IPv4 Address Pools . . . . . . . . . . 7 57 3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity 58 With Limited Private IPv4 Address Pools . . . . . . . . . 7 59 3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only 60 Transport and Applications Using IPv6 . . . . . . . . . . 8 61 3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running 62 On a Dual-Stack Host With an Assigned IPv6 Prefix and 63 a Shared IPv4 Address . . . . . . . . . . . . . . . . . . 8 64 4. Consideration of IPv4 / IPv6 Coexistence Solutions . . . . . . 8 65 4.1. Gateway-Initiated Dual-Stack Lite . . . . . . . . . . . . 8 66 4.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 9 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. informative References . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Consider a major mobile network operator, with hundreds of millions 75 of subscribers, currently growing at a rate in the order of 1% per 76 month. To assure continued revenue growth as market penetration 77 approaches its limit, the operator has been deploying 3GPP 78 technology. Currently about 1.5 percent of the operator's 79 subscribers use the third and fourth generation technology discussed 80 in this document. 82 The operator is looking to mobile data services for future revenue 83 gains. Mobile data services currently include mobile payments, music 84 downloads, mobile reading (book downloads), streaming and broadcast 85 video, and internet search services in partnership with content 86 providers such as news agencies. By their nature, these services 87 require communication between the mobile subscriber and a third party 88 application or content provider. Given the importance of these third 89 parties to the operator's business, the operator's IPv6 transition 90 plans have to ensure continuity of service to the third party servers 91 regardless of the IP version they run. 93 At the subscriber end, mobile handsets are typically replaced within 94 two to three years after purchase, apparently putting an upper limit 95 on how long it will take to make IPv6 the preferred protocol for the 96 majority of subscribers. However, in some markets the most popular 97 use of mobile data access is to provide access for personal computers 98 attached to the mobile terminal. This means the transition period at 99 the subscriber end depends to an important extent on the rate at 100 which personal computer operating systems and applications evolve to 101 support IPv6. 103 As a further complication for the migration to IPv6, the operator is 104 facing a major upgrade of its access networks from the older 3GPP 105 technology to LTE ("Long Term Evolution"). LTE flattens out the 106 access network by bringing the IP edge closer to the user equipment. 107 LTE will provide higher data rates, opening up the possibilities for 108 improved services and increased revenue from them. 110 1.1. Requirements Language 112 This document is descriptive, and as such, contains no requirements 113 language. 115 2. Overview of the Mobile Network Architecture 117 3GPP has specified layer 2 access for IPv6 in the legacy 3GPP 118 architecture and in the LTE ("Long Term Evolution") version. The 119 third generation architecture is shown in Figure 1. Only the user 120 data paths are shown. The IP edge (of the core IP network) is 121 located at the GGSN (Gateway GPRS Support Node, where GPRS itself 122 stands for General Packet Radio Service). Within this system, IPv6 123 support requires separate bearers (i.e., links) for IPv4 and IPv6 124 respectively, extending from the User Equipment through the radio 125 network and the SGSN (Serving GPRS Support Node, at which the User 126 Equipment is registered) and, finally, to the GGSN. 128 The bearers are actually propagated from the SGSN to the GGSN 129 using GTP-U, a 3GPP-specified tunneling protocol running over IP. 130 The IP addresses assigned to the SGSN and GGSN for this purpose 131 are not visible to the mobile station. The SGSN locates the GGSN 132 using a DNS service that is also not visible to the User 133 Equipment. 135 +-----+ 136 | | 137 | HSS | 138 | | 139 +-----+ 140 IPv4 link +--------------+ 141 / | | 142 +----+ / +-----+ +------+ +------+ | 143 | |....| |....| |.......| | Core | 144 | UE | L2 | RAN | L2 | SGSN | \ | GGSN | IP | 145 | |....| |....| |....\..| | Network | 146 +----+ \ +-----+ +------+ \ \ +------+ | 147 \ \ \ | | 148 IPv6 link \ \ +--------------+ 149 Links tunnelled 150 over GTP-U over IP 152 UE = User Equipment 153 RAN = Radio access network 154 SGSN = Serving GPRS Support Node 155 GGSN = Gateway GPRS Support Node 156 HSS = Home Subscriber Server (holds subscriber profile) 157 GTP = GPRS Tunneling Protocol 159 Figure 1: Third Generation GPRS Mobile Access Network 161 The use of IPv4 and/or IPv6 is controlled by the combination of 162 subscriber profile and core operator preference. Address allocation 163 to the User Equipment (UE) differs between IPv4 and IPv6. For IPv4, 164 addresses can be assigned in a number of ways. From the point of 165 view of the UE, the choice is between allocation during bearer 166 activation vs. DHCPv4 exchanges with the core network following 167 bearer activation. From the point of view of the network, the 168 choices are between static and dynamic address allocation. For 169 dynamic allocation, the choice is between: 171 o allocation by the access network (with the GGSN responsible for 172 managing the address pool); 174 o allocation by the core network (with the GGSN acting as DHCPv4 or 175 RADIUS client and passing the configuration data on to the UE 176 during bearer setup; or 178 o via DHCPv4 to the UE after bearer setup, as already mentioned. 180 IPv6 prefix allocation is done by stateless address autoconfiguration 181 (SLAAC), with the GGSN responsible for sending Router Announcements 182 in response to the UE's Router Solicitation. For further details see 183 Sections 9.2.1 and 9.2.1.1 of [3GPP_TR_23_060]. 185 The fourth generation mobile access architecture is described in 186 [3GPP_TR_23_401] and [3GPP_TR_23_402] and shown in Figure 2. The 187 SGSN has been split into a control part, the Mobile Management Entity 188 (MME), and a forwarding part, the Serving Gateway (SGW). The GGSN 189 has been replaced by the Packet Data Network Gateway (PDN Gateway, or 190 PGW). 192 The user data path to the core network changes in several ways with 193 LTE. First, it becomes possible to carry both IPv4 and IPv6 over the 194 same bearer. Thus the figure shows only a single link from the User 195 Equipment to the PDN Gateway. The second change is that the layer 2 196 protocol used in the third generation architecture to carry the link 197 between the edge of the Radio Access Network and the SGSN is replaced 198 by a tunnel over IP, the same protocol stack (User packets/GTP- 199 U/IP/...) used between the SGSN and the GGSN. Finally, the operator 200 has the option to use PMIPv6 [RFC5213] instead of GTP-U tunneling 201 between the SGW and the PDN Gateway. The SGW acts in the role of 202 Mobility Access Gateway (MAG), while the PDN Gateway acts in the role 203 of Local Mobility Anchor (LMA). PMIP is used only when the core IP 204 network to which the UE is connected has the same operator as the 205 access network. 207 +--------+ 208 | HSS | 209 +--------+ +---------+ 210 | PCRF | 211 +---------+ +---------+ 212 | MME | 213 +---------+ +------------+ 214 | | 215 +----+ +------ +-----+ +-----+ Core | 216 | UE |.....| RAN |.....| SGW |.....| PGW | IP | 217 +----+ +-----+ +-----+ +-----+ Network | 218 | | 219 +------------+ 220 UE = User Equipment 221 RAN = Radio Access Network 222 SGW = Serving Gateway 223 PGW = Packet Data Network (PDN) Gateway 224 MME = Mobility Management Entity 225 PCRF = Policy and Charging Rules Function 226 HSS = Home Subscriber Server 228 Figure 2: Long Term Evolution (LTE) Mobile Access Network 230 Essentially the same options are available in LTE for address 231 configuration of the User Equipment, except that the PDN Gateway 232 replaces the GGSN as the entity responsible for obtaining and 233 propagating that information. 235 To ease the upgrade from third generation access to LTE, it is 236 possible to mix equipment types in the same access network. Traffic 237 from the SGSN is forwarded to the SGW, which relays it to the PDN. 238 If the Radio Access Network control is upgraded to use GTP tunneling, 239 it is possible to tunnel traffic directly between the Radio Access 240 Network and the SGW. The SGSN retains a control function. The final 241 step is to replace the SGSN by an MME to carry out the control 242 function. 244 To achieve service continuity during handover, legacy mobile devices 245 support MIPv4 [RFC3344]. The GGSN provides the Foreign Agent 246 functionality. More recent devices support DSMIPv6 [RFC5555]. 247 DSMIPv6 assumes that both the UE and the Home Agent are dual-stack. 249 3. Approaches To IPv4 / IPv6 Coexistence 251 This section discusses the coexistence of user-plane IPv4 and IPv6 252 traffic. The operator is also faced with the upgrade of the network 253 equipment to use IPv6 for control signalling and for the IP wrapper 254 for PMIP and GTP-U tunnels carrying user data. This upgrade can 255 proceed independently of the work on user-plane traffic, but presents 256 its own coexistence problem. In the immediate case this is because 257 it will take time to reconfigure all of the equipment in one network. 258 Over the longer term the problem arises because different networks 259 will upgrade at different times, and they must interoperate to 260 support mobile roaming in the meantime. 262 3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity With Limited 263 Public IPv4 Address Pools 265 In this IPv6 transition scenario, the UEs operate in dual stack mode 266 and are assigned both an IPv6 prefix and an IPv4 address in order to 267 allow them to utilise both IPv4- and IPv6-capable applications. 268 Dual-stack UEs are able to support parallel IPv4 and IPv6 269 connectivity to a single PDN. As popular services start to support 270 IPv6, IPv4 traffic will gradually be offloaded into the IPv6 domain. 271 Services owned and deployed by the operator may be IPv6-enabled first 272 (while retaining IPv4 capability) and hence will be accessible to 273 dual-stack capable MSs running IPv6. 275 Issue: In dual stack mode, every UE still needs an IPv4 address. As 276 the number of subscribers grows, the lack of additional public IPv4 277 addresses will force the use of private rather than public IPv4 278 addresses for some UEs. Aside from anything else, this will 279 complicate the operation of mobile IP. 281 3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity With Limited 282 Private IPv4 Address Pools 284 In this scenario, UEs operate in dual stack mode and are assigned 285 both an IPv6 prefix and a private IPv4 address in order to allow them 286 to utilise both IPv4- and IPv6-capable applications. The IPv4 287 addresses assigned to UEs are taken from one of the private address 288 ranges specified in RFC 1918. NAT is performed on the interface 289 between the PDN Gateway and the core IP network. 291 Issue : The number of private IP addresses is limited. If more than 292 16 million UEs are active in the same network simultaneously, the 293 network could run out of private IPv4 addresses to assign. 295 The problem could be worse than this, depending on how many 296 addresses are temporarily unused because they haven`t been 297 reclaimed after the UE roamed out of the network or shut down. 299 3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only Transport and 300 Applications Using IPv6 302 In this scenario, the operator decides to assign only IPv6 prefixes 303 to the UEs due to, e.g., shortage of IPv4 addresses or because the 304 UEs support only IPv6. 306 Issue: UEs with IPv6-only connectivity running applications using 307 IPv6 should be able to access both IPv4- or IPv6-enabled services. 308 NAT64 and DNS64 should be performed to let the IPv6-only UEs have 309 access to IPv4 services. 311 3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running On a Dual- 312 Stack Host With an Assigned IPv6 Prefix and a Shared IPv4 Address 314 In this scenario an IPv4 application running on a dual-stack UE needs 315 to access IPv4 services without the operator having to allocate a 316 unique non-shared (private or public) IPv4 address to the UE. The 317 dual-stack UE running these applications uses an IPv4 address that is 318 shared amongst many other UEs, and uses an IPv6 prefix. 320 Issue: The obvious issue arises, that IPv4 services need to be able 321 to distinguish between UEs using the same IPv4 address. The source 322 port may be used for this purpose. 324 4. Consideration of IPv4 / IPv6 Coexistence Solutions 326 The different strategies described above require support to make them 327 work. 329 4.1. Gateway-Initiated Dual-Stack Lite 331 Dual-stack lite (DS-lite) [I-D.softwire-dual-stack-lite-06] 332 transports IPv4 traffic from the user device in an IPv6 tunnel across 333 an IPv6 provider network to a NAT44, where sharing of IPv4 public 334 addresses can be implemented. To prevent user DNS queries from going 335 through the NAT44, all queries are intercepted and sent to an IPv6 336 DNS server. Gateway-initiated DS-lite 337 [I-D.softwire-gateway-init-ds-lite-00] makes explicit use of the 338 tunnel set up through the access network to carry user packets to the 339 IP network. The gateway at the IP end of this tunnel maintains a 340 single tunnel between itself and the NAT44, to which it forwards 341 packets from all of the user devices connected to it. The inner 342 source IP address of the individual packets is actually a 32-bit 343 context identifier used with other information to retrieve forwarding 344 state at the gateway and the NAT44. Gateway-initiated DS-lite also 345 reduces or in some configurations eliminates the need for a unique 346 IPv4 address, public or private, at the UE. 348 As applied to the architectures described in Section 2, the gateway 349 is represented by the PDN Gateway or GGSN. The NAT44 is located 350 beyond the gateway, in the core IP network. The access tunnels are 351 GTP over IP, and indeed the tunnel IP version may be either IPv4 or 352 IPv6 without affecting the operation of gateway-initiated DS lite. 353 Section 5.6.1.2 of [3GPP_TR_23_060] suggests that GTP tunnels run 354 between the core nodes too, so the core network may run IPv4 or IPv6 355 independently of what is used in the access network. 357 By making the IPv4 address provisioned at the UE almost irrelevant, 358 gateway-initiated DS-lite supports any of the strategies described in 359 Section 3 except the all-IPv6 approach. One issue is that, at the 360 beginning when most traffic is IPv4, a large investment in NAT44 361 capacity will be needed. As traffic migrates to IPv6, this 362 investment becomes stranded and not reusable. Another issue is that 363 all IPv4 traffic suffers the quality of service penalty imposed by 364 the use of NAT. 366 One issue that has to be resolved is how to handle DNS queries for 367 IPv4 addresses. [I-D.softwire-dual-stack-lite-06] requires that all 368 DNS queries be sent to an IPv6 DNS server. Discussion on the 369 softwires list leading up to this suggested that from there, A record 370 requests could be forwarded to an IPv4 server. Alternatively, the 371 IPv6 server could maintain both AAAA and A records. A third 372 possibility was that the address of an IPv4 DNS server could be 373 configured manually at the UE. This is messy, both on grounds of 374 operational cost and because it would push DNS queries through the 375 NAT44, greatly increasing its workload. 377 4.2. Protocol Translation 379 NAT-PT was first described in [RFC2766]. [RFC4966] summarized a 380 number of issues identified with NAT-PT in the intervening years. As 381 a result, [RFC2766] was deprecated and given Historic status. 383 The IETF has made a new attempt at solving the problem. 384 [ID_v6v4_framework] explores a number of different translation 385 scenarios. Any particular application must identify which of the 386 scenarios it is dealing with before it can choose stateless versus 387 stateful translation. 389 [ID_IVI] reports on an early implementation of stateless translation, 390 operating in the two directions between an IPv6 network and the IPv4 391 Internet. This has been deployed in the China Education and Research 392 Network (CERNET). IVI predates the official IETF work in this area, 393 references to which are given both in [ID_v6v4_framework] and 395 [ID_IVI]. 397 5. IANA Considerations 399 This memo includes no request to IANA. 401 6. Security Considerations 403 This memo does not in itself introduce any security issues. 405 7. informative References 407 [3GPP_TR_23_060] 408 3rd Generation Partnership Project, "Technical 409 Specification Group Services and System Aspects; General 410 Packet Radio Service (GPRS); Service description; Stage 2 411 (Release 9)", TR 23.060, June 2010. 413 [3GPP_TR_23_401] 414 3rd Generation Partnership Project, "Technical 415 Specification Group Services and System Aspects; General 416 Packet Radio Service (GPRS) enhancements for Evolved 417 Universal Terrestrial Radio Access Network (E-UTRAN) 418 access (Release 9)", TR 23.401, March 2010. 420 [3GPP_TR_23_402] 421 3rd Generation Partnership Project, "Technical 422 Specification Group Services and System Aspects; 423 Architecture enhancements for non-3GPP accesses (Release 424 9)", TR 23.402, June 2010. 426 [I-D.huang-behave-pnat-01] 427 Huang, B., "Prefix NAT: Host based IPv6 translation", 428 February 2010. 430 [I-D.softwire-dual-stack-lite-06] 431 Durand, A., "Dual-Stack Lite Broadband Deployments 432 Following IPv4 Exhaustion", August 2010. 434 [I-D.softwire-gateway-init-ds-lite-00] 435 Brockners, F., "Gateway Initiated Dual-Stack Lite 436 Deployment", May 2010. 438 [ID_IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 439 CERNET IVI Translation Design and Deployment for the IPv4/ 440 IPv6 Coexistence and Transition", January 2010. 442 [ID_v6v4_framework] 443 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 444 IPv4/IPv6 Translation (Work in progress)", August 2010. 446 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 447 Translation - Protocol Translation (NAT-PT)", RFC 2766, 448 February 2000. 450 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 451 August 2002. 453 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 454 Address Translator - Protocol Translator (NAT-PT) to 455 Historic Status", RFC 4966, July 2007. 457 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 458 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 460 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 461 Routers", RFC 5555, June 2009. 463 Authors' Addresses 465 Cathy Zhou (editor) 466 Huawei Technologies 467 Bantian, Longgang District 468 Shenzhen 518129 469 P.R. China 471 Phone: 472 Email: cathyzhou@huawei.com 474 Tom Taylor 475 Huawei Technologies 476 1852 Lorraine Ave. 477 Ottawa K1H 6Z8 478 Canada 480 Phone: 481 Email: tom111.taylor@bell.net