idnits 2.17.1 draft-ietf-v6ops-v6-in-mobile-networks-05.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 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 (May 19, 2011) is 4725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group Rajeev. Koodli 3 Internet-Draft Cisco Systems 4 Intended status: Informational May 19, 2011 5 Expires: November 20, 2011 7 Mobile Networks Considerations for IPv6 Deployment 8 draft-ietf-v6ops-v6-in-mobile-networks-05.txt 10 Abstract 12 Mobile Internet access from smartphones and other mobile devices is 13 accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen 14 as crucial for the continued operation and growth of the Internet, 15 and in particular, it is critical in mobile networks. This document 16 discusses the issues that arise when deploying IPv6 in mobile 17 networks. Hence, this document can be a useful reference for service 18 providers and network designers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 20, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Reference Architecture and Terminology . . . . . . . . . . . . 3 56 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5 58 3.2. NAT Placement in the mobile networks . . . . . . . . . . . 7 59 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 10 60 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 13 61 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 65 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 66 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 1. Introduction 71 The dramatic growth of the Mobile Internet is accelerating the 72 exhaustion of the available IPv4 addresses. It is widely accepted 73 that IPv6 is necessary for the continued operation and growth of the 74 Internet in general, and that of the Mobile Internet in particular. 75 While IPv6 brings many benefits, certain unique challenges arise when 76 deploying it in mobile networks. This document describes such 77 challenges and outlines the applicability of the existing IPv6 78 deployment solutions. As such, it can be a useful reference document 79 for service providers as well as network designers. This document 80 does not propose any new protocols or suggest new protocol 81 specification work. 83 The primary considerations that we address in this document on IPv6 84 deployment in mobile networks are: 86 o Public and Private IPv4 address exhaustion and implications to 87 mobile network deployment architecture; 89 o Placement of Network Address Translation (NAT) functionality and 90 its implications; 92 o IPv6-only deployment considerations and roaming implications; 94 o Fixed-Mobile Convergence and implications to overall 95 architecture. 97 In the following sections, we discuss each of these in detail. 99 For the most part, we assume the 3GPP 3G and 4G network architectures 100 specified in [3gpp.3g] and [3gpp.4g]. However, the considerations 101 are general enough for other mobile network architectures as well 102 [3gpp2.ehrpd]. 104 2. Reference Architecture and Terminology 106 The following is a reference architecture of a mobile network. 108 +-----+ +-----+ 109 | AAA | | PCRF| 110 +-----+ +-----+ 111 Home Network \ / 112 \ / 113 \ / /- 114 MN BS \ / / 115 | /\ +-----+ /-----------\ +-----+ /-----------\ +-----+ / 116 +-+ /_ \---| ANG |/ Operator's \| MNG |/ Operator's \| BR |/Inte 117 | |---/ \ +-----+\ IP Network /+-----+\ IP Network /+-----+\rnet 118 +-+ \-----------/ / \-----------/ \ 119 ----------------/------ \- 120 Visited Network / 121 / 122 +-----+ /------------------\ 123 |ANG |/ Visited Operator's \ 124 +-----+\ IP Network / 125 \------------------/ 127 Figure 1: Mobile Network Architecture 129 A Mobile Node (MN) connects to the mobile network either via its Home 130 Network or via a Visited Network when the user is roaming outside of 131 the Home Network. In the 3GPP network architecture, a MN accesses 132 the network by connecting to an Access Point Name (APN), which maps 133 to a mobile gateway. Roughly speaking, an APN is similar to an SSID 134 in wireless LAN. An APN is a logical concept which can be used to 135 specify what kinds of services, such as Internet access, high- 136 definition video streaming, content-rich gaming, and so on, a MN is 137 entitled to. Each APN can specify what type of IP connectivity 138 (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN. 140 While an APN directs a MN to an appropriate gateway, the MN needs an 141 end-to-end "link" to that gateway. In the Long-Term Evolution (LTE) 142 networks, this link is realized through an Evolved Packet System 143 (EPS) bearer. In the 3G UMTS networks, such a link is realized 144 through a Packet Data Protocol (PDP) Context. The end-to-end link 145 traverses multiple nodes which are defined below: 147 o Base Station (BS): The radio Base Station provides wireless 148 connectivity to the MN. 150 o Access Network Gateway (ANG): The ANG forwards IP packets to and 151 from the MN. Typically, this is not the MN's default router, and 152 the ANG does not perform IP address allocation and management for 153 the mobile nodes. The ANG is located either in the Home Network 154 or in the Visited Network. 156 o The Mobile Network Gateway (MNG): The MNG is the MN's default 157 router which provides IP address management. The MNG performs 158 functions such as offering Quality of Service (QoS), applying 159 subscriber-specific policy, and enabling billing and accounting; 160 these functions are sometimes collectively referred to as 161 "subscriber-management" operations. The mobile network 162 architecture, as shown in the figure, defines the necessary 163 protocol interfaces to enable subscriber management operations. 164 The MNG is typically located in the Home Network. 166 o Border Router (BR): As the name implies, a BR borders the 167 Internet for the mobile network. The BR does not perform 168 subscriber management for the mobile network. 170 o Authentication, Authorization and Accounting (AAA): The general 171 functionality of AAA is used for subscriber authentication and 172 authorization for services, as well as for generating billing and 173 accounting information. 174 In the 3GPP network environments, the subscriber authentication 175 and the subsequent authorization for connectivity and services is 176 provided using the "Home Location Register" (HLR)/"Home Subscriber 177 Server" (HSS) functionality. 179 o Policy and Charging Rule Function (PCRF): The PCRF enables 180 applying policy and charging rules at the MNG. 182 In the rest of this document, we use the terms operator, service 183 provider or provider interchangeably. 185 3. IPv6 Considerations 187 3.1. IPv4 Address Exhaustion 189 It is generally agreed that the pool of public IPv4 addresses is 190 nearing its exhaustion. The IANA has exhausted the available '/8' 191 blocks for allocation to the Regional Internet Registries (RIRs). 192 The RIRs themselves have either "run-out" of their blocks or are 193 projected to exhaust them in the near future. This has led to a 194 heightened awareness among the service providers to consider 195 introducing technologies to keep the Internet operational. For 196 providers, there are two simultaneous approaches to addressing the 197 run-out problem: delaying the IPv4 address pool exhaustion (i.e., 198 conserving their existing pool) and introducing IPv6 in operational 199 networks. We consider both in the following. 201 Delaying the public IPv4 address exhaustion for providers involves 202 assigning private IPv4 addressing for end-users, or extending an IPv4 203 address with the use of port ranges which requires tunneling and 204 additional signaling. A mechanism such as the Network Address 205 Translator (NAT) is used at the provider premises (as opposed to 206 customer premises) to manage the private IP address assignment and 207 access to the Internet. In the following, we primarily focus on 208 translation based mechanisms such as NAT44 (i.e., translation from 209 public IPv4 to private IPv4 and vice versa) and NAT64 (i.e., 210 translation from public IPv6 to public IPv4 and vice versa). We do 211 this because the 3GPP architecture already defines a tunneling 212 infrastructure with the GPRS Tunneling Protocol (GTP), and the 213 architecture allows for dual-stack and IPv6-only deployments. 215 In a mobile network, the IPv4 address assignment for a MN is 216 performed by the MNG. In the 3GPP network architecture, this 217 assignment is performed in conjunction with the PDN connectivity 218 establishment. A PDN connection implies an end-end link (i.e., an 219 EPS bearer in 4G LTE or a PDP context in 3G UMTS) from the MN to the 220 MNG. There can be one or more PDN connections active at any given 221 time for each MN. A PDN connection may support both IPv4 and IPv6 222 traffic (as in a dual-stack PDN in 4G LTE networks) or it may support 223 only one of the two traffic types (as in the existing 3G UMTS 224 networks). The IPv4 address is assigned at the time of PDN 225 connectivity establishment, or is assigned using the DHCP protocol 226 after the PDN connectivity is established. In order to delay the 227 exhaustion of public IPv4 addresses, this IP address needs to be a 228 private IPv4 address which is translated into a shared public IPv4 229 address. Hence, there is a need for private - public IPv4 230 translation mechanism in the mobile network. 232 In the Long-Term Evolution (LTE) 4G network, there is a requirement 233 for an always-on PDN connection in order to reliably reach a mobile 234 user in the All-IP network. This requirement is due to the need for 235 supporting Voice over IP service in LTE which does not have circuit- 236 based infrastructure. If this PDN connection were to use IPv4 237 addressing, a private IPv4 address is needed for every MN that 238 attaches to the network. This could significantly affect the 239 availability and usage of private IPv4 addresses. One way to address 240 this is by making the always-on PDN (that requires voice service) to 241 be IPv6. The IPv4 PDN is only established when the user needs it. 243 The 3GPP standards also specify a deferred IPv4 address allocation on 244 a dual-stack IPv4v6 PDN at the time of connection establishment. 245 This has the advantage of a single PDN for IPv6 and IPv4 along with 246 deferring IPv4 address allocation until an application needs it. The 247 deferred address allocation requires support for a dyncamic 248 configuration protocol such as DHCP as well as appropriate triggers 249 to invoke the protocol. Such a support does not exist today in 250 mobile phones. The newer iterations of Smartphones could provide 251 such support. Also, the tethering of Smartphones to laptops (which 252 typically support DHCP) could use deferred allocation depending on 253 when a laptop attaches to the Smartphone. Until appropriate triggers 254 and host stack support is available, the applicability of the address 255 deferring option may be limited. 257 On the other hand, in the existing 3G UMTS networks, there is no 258 requirement for an always-on connection even though many SmartPhones 259 seldom relinquish an established PDP context. The existing so-called 260 pre-Release-8 deployments do not support the dual-stack PDP 261 connection. Hence, two separate PDP connections are necessary to 262 support IPv4 and IPv6 traffic. Even though some MNs, especially the 263 SmartPhones, in use today may have IPv6 stack, there are two 264 remaining considerations. First, there is little operational 265 experience and compliance testing with these existing stacks. Hence, 266 it is expected that their use in large deployments may uncover 267 software errors and interoperability problems which inhibit providing 268 services based on IPv6 for such hosts. Second, only a fraction of 269 current phones in use have such a stack. As a result, providers need 270 to test, deploy and operationalize IPv6 as they introduce new 271 handsets which also, continue to need, access to the predominantly 272 IPv4 Internet. 274 The considerations from the preceeding paragraphs lead to the 275 following observations. First, there is an increasing need to 276 support private IPv4 addressing in mobile networks because of the 277 public IPv4 address run-out problem. Correspondingly, there is a 278 greater need for private - public IPv4 translation in the mobile 279 networks. Second, there is support for IPv6 in both 3G and 4G LTE 280 networks already in the form of PDP context and PDN connections. To 281 begin with, the operators can introduce IPv6 for their own 282 applications and services. In other words, the IETF's recommended 283 model of dual-stack IPv6 and IPv4 networks is readily applicable to 284 mobile networks with the support for distinct APNs and the ability to 285 carry IPv6 traffic on PDP/PDN connections. The IETF dual-stack model 286 can be applied using a single IPv4v6 PDN connection in Release-8 and 287 onwards, but requires separate PDP contexts in the earlier releases. 288 Finally, operators can make IPv6 as the default for always-on mobile 289 connections using either the IPv4v6 PDN or the IPv6 PDN, and use IPv4 290 PDNs as necessary. 292 3.2. NAT Placement in the mobile networks 294 In the previous section, we observed that the NAT44 functionality is 295 needed in order to conserve the available pool and delay public IPv4 296 address exhaustion. However, the available private IPv4 pool itself 297 is not abundant for large networks such as mobile networks. For 298 instance, the so-called NET10 block [RFC1918] has approximately 16.7 299 million private IPv4 addresses starting with 10.0.0.0. A large 300 mobile service provider network can easily have more than 16.7 301 million subscribers attached to the network at a given time. Hence, 302 the private IPv4 address pool management and the placement of NAT44 303 functionality becomes important. 305 In addition to the developments cited above, NAT placement is 306 important for other reasons as well. Access networks generally need 307 to produce network and service usage records for billing and 308 accounting. This is true also for mobile networks where "subscriber 309 management" features (i.e., QoS, Policy, and Billing and Accounting) 310 can be fairly detailed. Since a NAT introduces a binding between two 311 addresses, the bindings themselves become necessary information for 312 subscriber management. For instance, the offered QoS on private IPv4 313 address and the (shared) public IPv4 address may need to be 314 correlated for accounting purposes. As another example, the 315 Application Servers within the provider network may need to treat 316 traffic based on policy provided by the PCRF. If the IP address seen 317 by these Application Servers is not unique, the PCRF needs to be able 318 to inspect the NAT binding to disambiguate among the individual MNs. 319 And, the subscriber session management information and the service 320 usage information also need to be correlated in order to produce 321 harmonized records. Furthermore, there may be legal requirements for 322 storing the NAT binding records. Indeed, these problems disappear 323 with the transition to IPv6. For now, it suffices to state that NAT 324 introduces state which needs to be correlated and possibly stored 325 with other routine subscriber information. 327 Mobile network deployments vary in their allocation of IP address 328 pools. Some network deployments use the "centralized model" where 329 the pool is managed by a common node, such as the PDN's BR, and the 330 pool shared by multiple MNGs all attached to the same BR. This model 331 has served well in the pre-3G deployments where the number of 332 subscribers accessing the mobile Internet at any given time has not 333 exceeded the available address pool. However, with the advent of 3G 334 networks and the subsequent dramatic growth in the number of users on 335 the mobile Internet, the service providers are increasingly forced to 336 consider their existing network design and choices. Specifically, 337 the providers are forced to address private IPv4 pool exhaustion as 338 well as scalable NAT solutions. 340 In order to tackle the private IPv4 exhaustion in the centralized 341 model, there would be a need to support overlapped private IPv4 342 addresses in the common NAT functionality as well as in each of the 343 gateways. In other words, the IP addresses used by two or more MNs 344 (which may be attached to the same MNG) are very likely to overlap at 345 the centralized NAT, which needs to be able to differentiate traffic. 346 Tunneling mechanisms such as Generic Routing Encapsulation (GRE) 347 [RFC2784], [RFC2890], MPLS [RFC3031] VPN tunnels or even IP-in-IP 348 encapsulation [RFC2003] which can provide a unique identifier for a 349 NAT session can be used to separate overlapping private IPv4 traffic 350 as described in [gi-ds-lite]. An advantage of centralizing the NAT 351 and using the overlapped private IPv4 addressing is conserving the 352 limited private IPv4 pool. It also enables the operator's enterprise 353 network to use IPv6 from the MNG to the BR; this (i.e., the need for 354 an IPv6-routed enterprise network) may be viewed as an additional 355 requirement by some providers. The disadvantages include the need 356 for additional protocol to correlate the NAT state (at the common 357 node) with subscriber session information (at each of the gateways), 358 suboptimal MN - MN communication, absence of subscriber-aware NAT 359 (and policy) function, and of course the need for a protocol from the 360 MNG to BR itself. Also, if the NAT function were to experience 361 failure, all the connected gateway service will be affected. These 362 drawbacks are not present in the "distributed" model which we discuss 363 in the following. 365 In a distributed model, the private IPv4 address management is 366 performed by the MNG which also performs the NAT functionality. In 367 this model, each MNG has a block of 16.7 million unique addresses, 368 which is sufficient compared to the number of mobile subscribers 369 active on each MNG. By distributing the NAT functionality to the 370 edge of the network, each MNG is allowed to re-use the available 371 NET10 block which avoids the problem of overlapped private IPv4 372 addressing at the network core. In addition, since the MNG is where 373 subscriber management functions are located, the NAT state 374 correlation is readily enabled. Furthermore, an MNG already has 375 existing interfaces to functions such as AAA and PCRF, which allows 376 it to perform subscriber management functions with the unique private 377 IPv4 addresses. Finally, the MNG can also pass-through certain 378 traffic types without performing NAT to the application servers 379 located within the service provider's domain, which allows the 380 servers to also identify subscriber sessions with unique private IPv4 381 addresses. The disadvantages of the "distributed model" include the 382 absence of centralized addressing and centralized management of NAT. 384 In addition to the two models described above, a hybrid model is to 385 locate NAT in a dedicated device other than the MNG or the BR. Such 386 a model would be similar to the distributed model if the IP pool 387 supports unique private addressing for the mobile nodes, or it would 388 be similar to the centralized model if it supports overlapped private 389 IP addresses. In any case, the NAT device has to be able to provide 390 the necessary NAT session binding information to an external entity 391 (such as AAA or PCRF) which then needs to be able to correlate those 392 records with the user's session state present at the MNG. 394 The foregoing discussion can be summarized as follows: First, the 395 management of available private IPv4 pool has become important given 396 the growth of the mobile Internet users. The mechanisms that enable 397 re-use of the available pool are required. Second, in the context of 398 private IPv4 pool management, the placement of NAT functionality has 399 implications to the network deployment and operations. The 400 centralized models with a common NAT have the advantages of 401 continuing their legacy deployments and the re-use of private IPv4 402 addressing. However, they need additional functions to enable 403 traffic differentiation and NAT state correlation with subscriber 404 state management at the MNG. The distributed models also achieve 405 private IPv4 address re-use and avoid overlapping private IPv4 406 traffic in the operator's core, but without the need for additional 407 mechanisms. Since the MNG performs (unique) IPv4 address assignment 408 and has standard interfaces to AAA and PCRF, the distributed model 409 also enables a single point for subscriber and NAT state reporting as 410 well as policy application. In summary, providers interested in 411 readily integrating NAT with other subscriber management functions, 412 as well as conserving and re-using their private IPv4 pool, may find 413 the distributed model compelling. On the other hand, those providers 414 interested in common management of NAT may find the cetralized model 415 more compelling. 417 3.3. IPv6-only Deployment Considerations 419 As we observed in the previous section, the presence of NAT 420 functionality in the network brings multiple issues which would 421 otherwise be absent. NAT should be viewed as an interim solution 422 until IPv6 is widely available, i.e., IPv6 is available for mobile 423 users for all (or most) practical purposes. Whereas NATs at provider 424 premises may slow down the exhaustion of public IPv4 addresses, 425 expeditious and simultaneous introduction of IPv6 in the operational 426 networks is necessary to keep the "Internet going and growing". 427 Towards this goal, it is important to understand the considerations 428 in deploying IPv6-only networks. 430 There are three dimensions to IPv6-only deployments: the network 431 itself, the mobile nodes and the applications, represented by the 432 3-tuple {nw, mn, ap}. The goal is to reach the co-ordinate {IPv6, 433 IPv6, IPv6} from {IPv4, IPv4, IPv4}. However, there are multiple 434 paths to arrive at the goal. The classic dual-stack model would 435 traverse the co-ordinate {IPv4v6, IPv4v6, IPv4v6}, where each 436 dimension supports co-existence of IPv4 and IPv6. This appears to be 437 the path of least disruption, although we are faced with the 438 implications of supoorting large-scale NAT in the network. There is 439 also the cost of supporting separate PDP contexts in the existing 3G 440 UMTS networks. The other intermediate co-ordinate of interest is 441 {IPv6, IPv6, IPv4}, where the network and the MN are IPv6-only, and 442 the Internet applications are recognized to be predominantly IPv4. 443 This transition path would, ironically, require interworking between 444 IPv6 and IPv4 in order for the IPv6-only MNs to be able to access 445 IPv4 services and applications on the Internet. In other words, in 446 order to disengage NAT (for IPv4 - IPv4), we need to introduce 447 another form of NAT (i.e., IPv6 - IPv4) to expedite the adoption of 448 IPv6. 450 It is interesting to consider the preceeding discussion surrounding 451 the placement of NAT for IPv6 - IPv4 interworking. There is no 452 overlapping private IPv4 address problem because each IPv6 address is 453 unique and there are plenty of them available. Hence, there is also 454 no requirement for (IPv6) address re-use, which means no protocol is 455 necessary in the centralized model to disambiguiate NAT sessions. 456 However, there is an additional requirement of DNS64 [dns64] 457 functionality for IPv6 - IPv4 translation. This DNS64 functionality 458 must ensure that the synthesized AAAA record correctly maps to the 459 IPv6 - IPv4 translator. 461 The IPv6-only deployments in mobile networks need to reckon with the 462 following considerations. First, both the network and the MNs need 463 to be IPv6-capable. Expedited network upgrades as well as roll-out 464 of MNs with IPv6 would greatly facilitate this. Fortunately, the 465 3GPP network design for LTE already requires the network nodes and 466 the mobile nodes to support IPv6. Even though there are no 467 requirements for the transport network to be IPv6, an operational 468 IPv6 connectivity service can be deployed with appropriate existing 469 tunneling mechanisms in the IPv4-only transport network. Hence a 470 service provider may choose to enforce IPv6-only PDN and address 471 assignment for their own subscribers in their Home Networks, see 472 Figure 1. This is feasible for the newer MNs when the mobile network 473 is able to provide IPv6-only PDN support and IPv6 - IPv4 interworking 474 for Internet access. For the existing MNs however, the provider 475 still needs to be able to support IPv4-only PDP/PDN connectivity. 477 Migration of applications to IPv6 in MNs with IPv6-only PDN 478 connectivity brings challenges. The applications and services 479 offered by the provider obviously need to be IPv6-capable. However, 480 a MN may host other applications which also need to be IPv6-capable 481 in IPv6-only deployments. This can be a "long-tail" phenomenon; 482 however, when a few prominant applications start offering IPv6, there 483 can be a strong incentive to provide application layer (e.g., socket 484 interface) upgrades to IPv6. Also, some IPv4-only applications may 485 be able to make use of alternative access such as WiFi when 486 available. A related challenge in the migration of applications is 487 the use of IPv4 literals in application layer protocols (such as 488 XMPP) or content (as in html or xml). Some Internet applications 489 expect their clients to supply IPv4 addresses as literals, and this 490 will not be possible with IPv6-only deployments. Some of these 491 experiences and the related considerations in deploying IPv6-only 492 network are documented in [arkko-v6]. In summary, migration of 493 applications to IPv6 needs to be done, and such a migration is not 494 expected to be uniform across all subsets of existing applications. 496 Voice over LTE (VoLTE) also brings some unique challenges. The 497 signaling for voice is generally expected to be available for free 498 while the actual voice call itself is typically charged on its 499 duration. Such a separation of signaling and the payload is unique 500 to voice, whereas an Internet connection is accounted without 501 specifically considering application signaling and payload traffic. 502 This model is expected to be supported even during roaming. 503 Furthermore, the providers and the users generally require the voice 504 service regardless of roaming whereas the Internet usage is subject 505 to subscriber preferences and roaming agreements. This requirement 506 to ubiquitously support voice service while providing the flexibility 507 for Internet usage exacerbates the addressing problem, and may hasten 508 provisioning of VoLTE using the IPv6-only PDN. 510 As seen earlier, roaming is unique to mobile networks and it 511 introduces new challenges. The service providers can control their 512 own network design but not their peer's networks which they rely on 513 for roaming. The users expect uniformity in experience even when 514 they are roaming. This imposes a constraint on providers interested 515 in IPv6-only deployments to also support IPv4 addressing when their 516 own (outbound) subscribers roam to networks which do not offer IPv6. 517 For instance, when an LTE deployment is IPv6-only, a roamed 3G 518 network may not offer IPv6 PDN connectivity. Since a PDN connection 519 involves the radio base station, the ANG and the MNG (See Figure 1), 520 it would not be possible to enable IPv6 PDN connectivity without the 521 roamed network support. These considerations also apply when the 522 visited network is used for offering services such as VoLTE in the 523 so-called Local Breakout model; the roaming MN's capability as well 524 as the roamed network capability to support VoLTE using IPv6 525 determine whether fallback to IPv4 would be necessary. Similarly, 526 there are inbound roamers to an IPv6-ready provider network whose 527 MN's are not capable of IPv6. The IPv6-ready provider network has to 528 be able to support IPv4 PDN connectivity for such inbound roamers. 529 There are encouraging signs that the existing deployed network nodes 530 in the 3GPP architecture already provide support for IPv6 PDP 531 context. It would be necessary to scale this support for a (very) 532 large number of mobile users and offer it as a ubiquitous service 533 which can be accounted for. 535 In summary, IPv6-only deployments should be encouraged along-side the 536 dual-stack model which is the recommended IETF approach. This is 537 relatively straightforward for an operator's own services and 538 applications, provisioned through an appropriate APN and the 539 corresponding IPv6-only PDP or EPS bearer. Some providers may 540 consider IPv6-only deployment for Internet access as well, and this 541 would require IPv6 - IPv4 interworking. When the IPv6 - IPv4 542 translation mechanisms are used in IPv6-only deployments, the 543 protocols and the associated considerations specified in 544 [xlate-stateful] and [xlate-stateless] apply. Finally, such IPv6- 545 only deployments can be phased-in for newer mobile nodes, while the 546 existing ones continue to demand IPv4-only connectivity. 548 Roaming is important in mobile networks and roaming introduces 549 diversity in network deployments. Until IPv6 connectivity is 550 available in all mobile networks, IPv6-only mobile network 551 deployments need to be prepared to support IPv4 connectivity (and 552 NAT44) for their own outbound roaming users as well as for inbound 553 roaming users. However, by taking the initiative to introduce IPv6- 554 only for the newer MNs, the mobile networks can significantly reduce 555 the demand for private IPv4 addresses. 557 3.4. Fixed - Mobile Convergence 559 Many service providers have both fixed broadband and mobile networks. 560 Access networks are generally disparate, with some common 561 characteristics but with enough differences to make it challenging to 562 achieve "convergence". For instance, roaming is not a consideration 563 in fixed access networks. An All-IP mobile network service provider 564 is required to provide voice service, whereas this is not required 565 for a fixed network provider. A "link" in fixed networks is 566 generally capable of carrying IPv6 and IPv4 traffic, whereas not all 567 mobile networks have "links" (i.e., PDP/PDN connections) capable of 568 supporting IPv6 and IPv4. Indeed roaming makes this problem worse 569 when a portion of the link (i.e., the Home Network in Figure 1) is 570 capable of supporting IPv6 and the other portion of the link (i.e., 571 the Visited Network in Figure 1) is not. Such architectural 572 differences, as well as policy and business model differences make 573 convergence challenging. 575 Nevertheless, within the same provider's space, some common 576 considerations may apply. For instance, IPv4 address management is a 577 common concern for both of the access networks. This implies that 578 the same mechanisms discussed earlier, i.e., delaying IPv4 address 579 exhaustion and introducing IPv6 in operational networks, apply for 580 the converged networks as well. However, the exact solutions 581 deployed for each access network can vary for a variety of reasons. 582 For instance: 584 o Tunneling of private IPv4 packets within IPv6 is feasible in 585 fixed networks where the end-point is often a cable or DSL modem. 586 This is not the case in mobile networks where the end-point is a 587 MN itself. 589 o Encapsulation-based mechanisms such as 6rd [RFC5969] are useful 590 where the operator is unable to provide native or direct IPv6 591 connectivity and a residential gateway can become a tunnel end- 592 point for providing this service. In mobile networks, the 593 operator could provide IPv6 connectivity using the existing mobile 594 network tunneling mechanisms without introducing an additional 595 layer of tunneling. 597 o A mobile network provider may have application servers (e.g., an 598 email server) in its network that require unique private IPv4 599 addresses for MN identification, whereas a fixed network provider 600 may not have such a requirement or the service itself. 602 These examples illustrate that the actual solutions used in an access 603 network are largely determined by the requirements specific to that 604 access network. Nevertheless, some sharing between access and core 605 network may be possible depending on the nature of the requirement 606 and the functionality itself. For example, when a fixed network does 607 not require a subscriber-aware feature such as NAT, the functionality 608 may be provided at a core router while the mobile access network 609 continues to provide the NAT functionality at the mobile gateway. If 610 a provider chooses to offer common subscriber management at the MNG 611 for both fixed and wireless networks, the MNG itself becomes a 612 convergence node that needs to support the applicable transition 613 mechanisms for both fixed and wireless access networks. 615 Different access networks of a provider are more likely to share a 616 common core network. Hence, common solutions can be more easily 617 applied in the core network. For instance, configured tunnels or 618 MPLS VPNs from the gateways from both mobile and fixed networks can 619 be used to carry traffic to the core routers, until the entire core 620 network is IPv6-enabled. 622 There can also be considerations due to the use of NAT in access 623 networks. Solutions such as Femto Networks rely on a fixed Internet 624 connection being available for the Femto Base Station to communicate 625 with its peer on the mobile network, typically via an IPsec tunnel. 626 When the Femto Base Station needs to use a private IPv4 address, the 627 mobile network access through the Femto Base Station will be subject 628 to NAT policy administration including periodic clean-up and purge of 629 NAT state. Such policies affect the usability of the Femto Network, 630 and has implications to the mobile network provider. Using IPv6 for 631 the Femto (or any other access technology) could alleviate some of 632 these concerns if the IPv6 communication could bypass the NAT. 634 In summary, there is interest in fixed-mobile convergence at least 635 among some providers. While there are benefits from harmonizing the 636 network as much as possible, there are also idiosyncrasies of 637 disparate access networks which influence the convergence. Perhaps 638 greater harmonization is feasible at the higher service layers, e.g., 639 in terms of offering unified user experience for services and 640 applications. Some harmonization of functions across access networks 641 into the core network may be feasible. A provider's core network 642 appears to the place where most convergence is feasible. 644 4. Summary and Conclusion 646 IPv6 deployment in mobile networks is crucial for the mobile 647 Internet. In this document, we discussed the considerations in 648 deploying IPv6 in mobile networks. We summarize the discussion in 649 the following: 651 o IPv4 address exhaustion and its implications to mobile networks: 652 As the mobile service providers begin to deploy IPv6, conserving 653 their available IPv4 pool implies the need for network address 654 translation in mobile networks. At the same time, providers can 655 make use of the 3GPP architecture constructs such as the APN and 656 PDN connectivity to introduce IPv6 without affecting the 657 predominantly IPv4 Internet access. The IETF dual-stack model 658 [RFC4213] can be applied to the mobile networks readily. 660 o The placement of NAT functionality in mobile networks: Both the 661 centralized and distributed models of private IPv4 address pool 662 management have their relative merits. By enabling each MNG to 663 manage its own NET10 pool, the distributed model achieves re-use 664 of available private IPv4 pool and avoids the problems associated 665 with the non-unique private IPv4 addresses for the MNs without 666 additional protocol mechanisms. The distributed model also 667 augments the "subscriber management" functions at an MNG, such as 668 readily enabling NAT session correlation with the rest of the 669 subscriber session state. On the other hand, the existing 670 deployments which have used the centralized IP address management 671 can continue their legacy architecture by placing the NAT at a 672 common node. The centralized model also achieves private IPv4 673 address re-use, but needs additional protocol extensions to 674 differentiate overlapping addresses at the common NAT as well as 675 to integrate with policy and billing infrastructure. 677 o IPv6-only mobile network deployments: This deployment model is 678 feasible in the LTE architecture for an operator's own services 679 and applications. The existing MNs still expect IPv4 address 680 assignment. And, roaming which is unique to mobile networks, 681 requires that a provider support IPv4 connectivity when their 682 (outbound) users roam into a mobile network that is not IPv6- 683 enabled. Similarly, a provider needs to support IPv4 connectivity 684 for (inbound) users whose MNs are not IPv6-capable. The IPv6 - 685 IPv4 interworking is necessary for IPv6-only MNs to access IPv4 686 Internet. 688 o Fixed-Mobile Convergence: The examples discussed illustrate the 689 differences in the requirements of fixed and mobile networks. 690 While some harmonization of functions may be possible across the 691 access networks, the service provider's core network is perhaps 692 better-suited for converged network architecture. Similar gains 693 in convergence are feasible in the service and application layers. 695 5. Security Considerations 697 This document does not introduce any new security vulnerabilities. 699 6. IANA Considerations 701 This document does not require any actions from IANA. 703 7. Acknowledgement 705 This document has benefitted from discussions with and reviews from 706 Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij, 707 Jouni Korhonen, Teemu Savolainen and Dan Wing; thanks to all of them. 708 Mohamed Boucadair provided an extensive review of individual draft 709 version 01 of this document; many thanks Mohamed. Cameron Byrne, 710 Kent Leung, Kathleen Moriarty and Jari Arkko provided reviews which 711 have helped improve this document. Thanks to Nick Heatley for 712 providing valuable review and input on VoLTE. 714 8. Informative References 716 [3gpp.3g] "General Packet Radio Service (GPRS); Service description; 717 Stage 2, 3GPP TS 23.060, December 2006", . 719 [3gpp.4g] "General Packet Radio Service (GPRS);enhancements for 720 Evolved Universal Terrestrial Radio Access Network 721 (E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.", 722 . 724 [3gpp2.ehrpd] 725 "E-UTRAN - eHRPD Connectivity and Interworking: Core 726 Network Aspects", http://www.3gpp2.org/Public_html/Misc/ 727 X.P0057-0_v0.13_E-UTRAN- 728 eHRPD_Interworking_VV_Due_5_December-2008.pdf. 730 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 731 E. Lear, "Address Allocation for Private Internets", 732 BCP 5, RFC 1918, February 1996. 734 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 735 October 1996. 737 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 738 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 739 March 2000. 741 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 742 RFC 2890, September 2000. 744 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 745 Label Switching Architecture", RFC 3031, January 2001. 747 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 748 for IPv6 Hosts and Routers", RFC 4213, October 2005. 750 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 751 Infrastructures (6rd) -- Protocol Specification", 752 RFC 5969, August 2010. 754 [arkko-v6] 755 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 756 Network", draft-arkko-ipv6-only-experience-01, Jul 2010. 758 [dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 759 Beijnum, "DNS64: DNS extensions for Network Address 760 Translation from IPv6 Clients to IPv4 Servers", 761 draft-ietf-behave-dns64-11, Mar 2010. 763 [gi-ds-lite] 764 Brockners et al., F., "Gateway Initiated Dual-stack Lite 765 Deployment", draft-ietf-softwire-gateway-init-ds-lite, 766 Oct 2009. 768 [xlate-stateful] 769 Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 770 NAT64: Network Address and Protocol Translation from IPv6 771 Clients to IPv4 Servers", 772 draft-ietf-behave-v6v4-xlate-stateful-11, Mar 2010. 774 [xlate-stateless] 775 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 776 Algorithm", draft-ietf-behave-v6v4-xlate-20, May 2010. 778 Appendix A. Change Log 780 Revisions (from draft-koodli-**), descending chronological order 782 o: More IESG reviews 784 o: Addressed IESG reviews 786 o: VoLTE related text 788 o: FMC, Femto Networks text 790 o: Dedicated NAT device model (in addition to the centralized and 791 distributed models) 793 o: IPv6-only deployment considerations: - IPv4 literals discussion 794 and reference, - IPv6 prefix assignment clarification, - DNS64 795 requirement and reference 797 o: Overall revisions based on comments from reviews (C. Byrne, K. 798 Leung) 800 o: Dual-stack being the recommended model, while encouraging IPv6- 801 only deployments. 803 o: Clarifications on on-demand IPv4 PDN usage, DHCP usage and on- 804 demand IPv4 assignment. 806 o: Clarifications regarding IPv6-only deployment: Roaming and 807 Applications considerations. 809 Author's Address 811 Rajeev Koodli 812 Cisco Systems 813 USA 815 Email: rkoodli@cisco.com