idnits 2.17.1 draft-ietf-v6ops-3gpp-eps-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 date (March 31, 2011) is 4773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GGSN' is mentioned on line 381, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-dhc-pd-exclude-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Korhonen, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational J. Soininen 5 Expires: October 2, 2011 Renesas Mobile 6 B. Patil 7 T. Savolainen 8 G. Bajko 9 Nokia 10 K. Iisakkila 11 Renesas Mobile 12 March 31, 2011 14 IPv6 in 3GPP Evolved Packet System 15 draft-ietf-v6ops-3gpp-eps-00 17 Abstract 19 Internet connectivity and use of data services in 3GPP based mobile 20 networks has increased rapidly as a result of smart phones, broadband 21 service via HSPA and HSPA+ networks, competitive service offerings by 22 operators and a large number of applications. Operators who have 23 deployed networks based on 3GPP architectures are facing IPv4 address 24 shortages. With the impending exhaustion of available IPv4 addresses 25 from the registries there is an increased emphasis for operators to 26 migrate to IPv6. This document describes the support for IPv6 in 27 3GPP network architectures. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 2, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5 65 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 8 67 3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 9 69 3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 11 72 4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 13 74 5. Address Management . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 14 76 5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 14 77 5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 15 78 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 15 79 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 15 80 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 16 81 6.3. PDN Connection Establishment Process . . . . . . . . . . . 17 82 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 20 83 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 20 84 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 21 85 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 21 86 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 22 87 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 23 88 8.4. Operational Aspects of Running a Network with IPv6 89 Only Bearers . . . . . . . . . . . . . . . . . . . . . . . 23 90 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 24 91 8.6. Inter-rat Handovers and IP Versions . . . . . . . . . . . 25 92 8.7. Provisioning of IPv6 Subscribers and Various 93 Combinations During Initial Network Attachment . . . . . . 26 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 96 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 27 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 98 13. Informative References . . . . . . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 1. Introduction 103 IPv6 has been specified in the 3rd Generation Partnership Project 104 (3GPP) standards since the early architectures developed for R99 105 General Packet Radio Service (GPRS). However, the support for IPv6 106 in commercially deployed networks by the end of 2010 is nearly non- 107 existent. There are many factors that can be attributed to the lack 108 of IPv6 deployment in 3GPP networks. The most relevant one is 109 essentially the same as the reason for IPv6 not being deployed by 110 other networks as well, i.e. the lack of business and commercial 111 incentives for deployment. 3GPP network architectures have also 112 evolved since 1999 (since R99). The most recent version of the 3GPP 113 architecture, the Evolved Packet System (EPS), which is commonly 114 referred to as SAE, LTE or Release-8, is a packet centric 115 architecture. The number of subscribers and devices that are using 116 the 3GPP networks for Internet connectivity and data services has 117 also increased significantly. With the subscriber growth numbers 118 projected to increase even further and the IPv4 addresses depletion 119 problem looming in the near term, 3GPP operators and vendors have 120 started the process of identifying the scenarios and solutions needed 121 to transition to IPv6. 123 This document describes the establishment of IP connectivity in 3GPP 124 network architectures, specifically in the context of IP bearers for 125 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is 126 supported as per the current set of 3GPP specifications. Some of the 127 issues and concerns with respect to deployment and shortage of 128 private IPv4 addresses within a single network domain are also 129 discussed. 131 The IETF has specified a set of tools and mechanisms that can be 132 utilized for transitioning to IPv6. In addition to operating dual- 133 stack networks during the transition from IPv4 to IPv6 phase, the two 134 alternative categories for the transition are encapsulation and 135 translation. Most of the mechanisms available in the toolbox can be 136 categorized into either translation or encapsulation approaches. The 137 IETF continues to specify additional solutions for enabling the 138 transition based on the deployment scenarios and operator/ISP 139 requirements. There is no single approach for transition to IPv6 140 that can meet the needs for all deployments and models. The 3GPP 141 scenarios for transition, described in [3GPP.23.975], can be 142 addressed using transition mechanisms that are already available in 143 the toolbox. The objective of transition to IPv6 in 3GPP networks is 144 to ensure that: 146 1. Legacy devices and hosts which have an IPv4 only stack will 147 continue to be provided with IP connectivity to the Internet and 148 services, 150 2. Devices which are dual-stack can access the Internet either via 151 IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the 152 capability of: 154 A. the application on the host, 156 B. the support for IPv4 and IPv6 bearers by the network and/or, 158 C. the capability of the server(s) and other end points. 160 3GPP networks are capable of providing a host with IPv4 and IPv6 161 connectivity today, albeit in many cases with upgrades to network 162 elements such as the SGSN and GGSN. 164 2. 3GPP Terminology and Concepts 166 2.1. Terminology 168 Access Point Name 170 Access Point Name (APN) is a fully qualified domain name and 171 resolves to a specific gateway in an operators network. The APNs 172 are piggybacked on the administration of the DNS namespace. 174 Packet Data Protocol Context 176 A Packet Data Protocol (PDP) Context is the equivalent of a 177 virtual connection between the host and a gateway. 179 General Packet Radio Service 181 General Packet Radio Service (GPRS) is a packet oriented mobile 182 data service available to users of the 2G and 3G cellular 183 communication systems Global System for Mobile communications 184 (GSM), and specified by 3GPP. 186 Packet Data Network 188 Packet Data Network (PDN) is a packet based network that either 189 belongs to the operator or is an external network such as Internet 190 and corporate intranet. The user eventually accesses services in 191 one or more PDNs. The operator's packet domain network are 192 separated from packet data networks either by GGSNs or PDN 193 Gateways (PDN-GW). 195 Gateway GPRS Support Node 197 Gateway GPRS Support Node (GGSN) is a gateway function in GPRS, 198 which provides connectivity to Internet or other PDNs. The host 199 attaches to a GGSN identified by an APN assigned to it by an 200 operator. The GGSN also serves as the topological anchor for 201 addresses/prefixes assigned to the mobile host. 203 Packet Data Network Gateway 205 Packet Data Network Gateway (PDN-GW) is a gateway function in 206 Evolved Packet System (EPS), which provides connectivity to 207 Internet or other PDNs. The host attaches to a PDN-GW identified 208 by an APN assigned to it by an operator. The PDN-GW also serves 209 as the topological anchor for addresses/prefixes assigned to the 210 mobile host. 212 Serving Gateway 214 Serving Gateway (SGW) is a gateway function in EPS, which 215 terminates the interface towards E-UTRAN. The SGW is the Mobility 216 Anchor point for layer-2 mobility (inter-eNodeB handovers). For 217 each User Equipment connected with the EPS, at any given point of 218 time, there is only one SGW. The SGW is essentially the user 219 plane part of the GPRS' SGSN forwarding packets between a PDN-GW. 221 Serving Gateway Support Node 223 Serving Gateway Support Node (SGSN) is a network element that is 224 located between the radio access network (RAN) and the gateway 225 (GGSN). A per mobile host point to point (p2p) tunnel between the 226 GGSN and SGSN transports the packets between the mobile host and 227 the gateway. 229 GPRS tunnelling protocol 231 GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.274] is a 232 tunnelling protocol defined by 3GPP. It is a network based 233 mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) 234 [RFC5213]. However, GTP also provides functionality beyond 235 mobility such as inband signaling related to Quality of Service 236 (QoS) and charging among others. 238 Evolved Packet System 240 Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 241 system characterized by higher-data-rate, lower-latency, packet- 242 optimized system that supports multiple Radio Access Technologies 243 (RAT). The EPS comprises the Evolved Packet Core (EPC) together 244 with the evolved radio access network (E-UTRA and E-UTRAN). 246 Mobility Management Entity 248 Mobility Management Entity (MME) is a network element that is 249 responsible for control plane functionalities, including 250 authentication, authorization, bearer management, layer-2 251 mobility, etc. The MME is essentially the control plane part of 252 the GPRS' SGSN and not located on the user plane data path, i.e. 253 user plane traffic bypasses the MME. 255 UMTS Terrestrial Radio Access Network 257 UMTS Terrestrial Radio Access Network (UTRAN) is communications 258 network, commonly referred to as 3G, and consists of NodeBs (3G 259 base station) and Radio Network Controllers (RNC) which make up 260 the UMTS radio access network. The UTRAN allows connectivity 261 between the mobile host/device and the core network. UTRAN 262 comprises of WCDMA, HSPA and HSPA+ radio technologies. 264 Wideband Code Division Multiple Access 266 The Wideband Code Division Multiple Access (WCDMA) is the radio 267 interface used in UMTS networks. 269 High Speed Packet Access 271 The High Speed Packet Access (HSPA) and the Evolved High Speed 272 Packet Access (HSPA+) are enhanced versions of the WCDMA and 273 UTRAN, thus providing more data throughput and lower latencies. 275 Evolved UTRAN 277 Evolved UTRAN (E-UTRAN) is communications network, sometimes 278 referred to as 4G, and consists of eNodeBs (4G base station) which 279 make up the E-UTRAN radio access network. The E-UTRAN allows 280 connectivity between the mobile host/device and the core network. 282 eNodeB 284 The eNodeB is a base station entity that supports the Long Term 285 Evolution (LTE) air interface. 287 GSM EDGE Radio Access Network 289 GSM EDGE Radio Access Network (GERAN) is communications network, 290 commonly referred to as 2G or 2.5G, and consists of base stations 291 and Base Station Controllers (BSC) which make up the GSM EDGE 292 radio access network. The GERAN allows connectivity between the 293 mobile host/device and the core network. 295 UE, MS, MN and Mobile 297 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 298 Node) and, mobile refer to the devices which are hosts with 299 ability to obtain Internet connectivity via a 3GPP network. The 300 terms UE, MS, MN and devices are used interchangeably within this 301 document. 303 PCC 305 The Policy and Charging Control (PCC) framework is used for QoS 306 policy and charging control. It is optional for 3GPP EPS but 307 needed if dynamic policy and charging control by means of PCC 308 rules based on user and services are desired. 310 HLR 312 The Home Location Register (HLR) is a pre-Release-5 database (the 313 reality regarding releases is different, though) for a given 314 subscriber. It is the entity containing the subscription-related 315 information to support the network entities actually handling 316 calls/sessions. 318 HSS 320 The Home Subscriber Server (HSS) is a database for a given 321 subscriber and got introduced in 3GPP Release-5. It is the entity 322 containing the subscription-related information to support the 323 network entities actually handling calls/sessions. 325 2.2. The concept of APN 327 The Access Point Name (APN) essentially refers to a gateway in the 328 3GPP network. The 'complete' APN is expressed in a form of a Fully 329 Qualified Domain Name (FQDN) and also piggybacked on the 330 administration of the DNS namespace, thus effectively allowing the 331 discovery of gateways using the DNS. Mobile hosts/devices can choose 332 to attach to a specific gateway in the packet core. The gateway 333 provides connectivity to the Packet Data Network (PDN) such as the 334 Internet. An operator may also include gateways which do not provide 335 Internet connectivity, rather a connectivity to closed network 336 providing a set of operator's own services. A mobile host/device can 337 be attached to one or more gateways simultaneously. The gateway in a 338 3GPP network is the GGSN or PDN-GW. Figure 1 below illustrates the 339 APN-based network connectivity concept. 341 .--. 342 _(. `) 343 .--. +------------+ _( PDN `)_ 344 _(Core`. |GW1 |====( Internet `) 345 +---+ ( NW )------|APN=internet| ( ` . ) ) 346 [MN]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' 347 ^ +---+ `--(___.-' | 348 | | .--. 349 | | +----------+ _(.PDN`) 350 | +--|GW2 | _(Operator`)_ 351 | |APN=OpServ|====( Services `) 352 MN is attached +----------+ ( ` . ) ) 353 to GW1 and GW2 `--(_______)---' 354 simultaneously 356 Figure 1: Mobile host/device attached to multiple APNs simultaneously 358 3. IP over 3GPP GPRS 360 3.1. Introduction to 3GPP GPRS 362 A simplified 2G/3G GPRS architecture is illustrated in Figure 2. 363 This architecture basically covers the GPRS core network since R99 to 364 Release-7, and radio access technologies such as GSM (2G), EDGE (2G, 365 ofter referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred 366 as 3.5G). The architecture shares obvious similarities with the 367 Evolved Packet System (EPS) as will be seen in Section 4. Based on 368 Gn/Gp interfaces, the GPRS core network functionality is logically 369 implemented on two network nodes, the SGSN and the GGSN. 371 3G .--. 372 Uu +-----+ Iu +----+ +----+ _( `. 373 [TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) 374 +-----+ +----+ Gn +----+ Gi ( ` . ) ) 375 / | `--(___.-' 376 2G Gb-- | 377 +---+ / --Gp 378 [TE]+[MT]~~|~~~|BSS|___/ | 379 Um +---+ .--. 380 _(. `) 381 _( [GGSN] `)_ 382 ( other `) 383 ( ` . PLMN ) ) 384 `--(_______)---' 386 Figure 2: Overview of the 2G/3G GPRS Logical Architecture 388 Gn/Gp: These interfaces provide a network based mobility service for 389 a mobile host and are used between a SGSN and a GGSN. The Gn 390 interface is used when GGSN and SGSN are located inside one 391 operator (i.e. PLMN). The Gp-interface is used if the GGSN 392 and the SGSN are located in different operator domains (i.e. 393 'other' PLMN). GTP protocol is defined for the Gn/Gp 394 interfaces (both GTP-C for the control plane and GTP-U for 395 the user plane). 397 Gb: Is the Base Station System (BSS) to SGSN interface, which is 398 used to carry information concerning packet data transmission 399 and layer-2 mobility management. The Gb-interface is based 400 on either on Frame Relay or IP. 402 Iu: Is the Radio Network System (RNS) to SGSN interface, which is 403 used to carry information concerning packet data transmission 404 and layer-2 mobility management. The user plane part of the 405 Iu-interface (actually the Iu-PS) is based on GTP-U. The 406 control plane part of the Iu-interface is based on Radio 407 Access Network Application Protocol (RANAP). 409 Gi: It is the interface between the GGSN and a PDN. The PDN may 410 be an operator external public or private packet data network 411 or an intra-operator packet data network. 413 Uu/Um: Are either 2G or 3G radio interfaces between a mobile 414 terminal and a respective radio access network. 416 The SGSN is responsible for the delivery of data packets from and to 417 the mobile hosts within its geographical service area when a direct 418 tunnel option is not used. If the direct tunnel is used, then the 419 user plane goes directly between the RNS and the GGSN. The control 420 plane traffic always goes through the SGSN. For each mobile host 421 connected with the GPRS, at any given point of time, there is only 422 one SGSN. 424 3.2. PDP Context 426 A PDP context is an association between a mobile host represented by 427 one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by 428 an APN. Each PDN can be accessed via a gateway (typically a GGSN or 429 PDN-GW). On the device/mobile host a PDP context is equivalent to a 430 network interface. A host may hence be attached to one or more 431 gateways via separate connections, i.e. PDP contexts. Each primary 432 PDP context has its own IPv4 address and/or one /64 IPv6 prefix 433 assigned to it by the PDN and anchored in the corresponding gateway. 435 Applications on the host use the appropriate network interface (PDP 436 context) for connectivity to a specific PDN. Figure 3 represents a 437 high level view of what a PDP context implies in 3GPP networks. 439 Y 440 | +---------+ .--. 441 |--+ __________________________ | APNx in | _( `. 442 | |O______PDPc1_______________)| GGSN / |----(Internet) 443 |MS| | PDN-GW | ( ` . ) ) 444 |/ | +---------+ `--(___.-' 445 |UE| _______________________ +---------+ .--. 446 | |O______PDPc2____________)| APNy in | _(Priv`. 447 +--+ | GGSN / |-------(Network ) 448 | PDN-GW | ( ` . ) ) 449 +---------+ `--(___.-' 451 Figure 3: PDP contexts between the MS/UE and gateway 453 In the above figure there are two PDP contexts at the MS/UE (UE=User 454 Equipment in 3GPP parlance). The 'PDPc1' PDP context that is 455 connected to APNx provided Internet connectivity and the 'PDPc2' PDP 456 context provides connectivity to a private IP network via APNy (as an 457 example this network may include operator specific services such as 458 MMS (Multi media service). An application on the host such as a web 459 browser would use the PDP context that provides Internet connectivity 460 for accessing services on the Internet. An application such as MMS 461 would use APNy in the figure above because the service is provided 462 through the private network. 464 4. IP over 3GPP EPS 466 4.1. Introduction to 3GPP EPS 468 In its most basic form, the EPS architecture consists of only two 469 nodes on the user plane, a base station and a core network Gateway 470 (GW). The basic EPS architecture is illustrated in Figure 4. The 471 Mobility Management Entity (MME) node performs control-plane 472 functionality and is separated from the node(s) that performs bearer- 473 plane functionality (GW), with a well-defined open interface between 474 them (S11). The optional interface S5 can be used to split the 475 Gateway (GW) into two separate nodes, the Serving Gateway (SGW) and 476 the PDN-GW. This allows independent scaling and growth of traffic 477 throughput and control signal processing. The functional split of 478 gateways also allows for operators to choose optimized topological 479 locations of nodes within the network and enables various deployment 480 models including the sharing of radio networks between different 481 operators. 483 +--------+ 484 S1-MME +-------+ S11 | IP | 485 +----|----| MME |---|----+ |Services| 486 | | | | +--------+ 487 | +-------+ | |SGi 488 +----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+ 489 |MN |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | 490 | |========|=======|====================|=======|======| | 491 +----+ +-------+DualStack EPS Bearer+-------+ +-------+ 493 Figure 4: EPS Architecture for 3GPP Access 495 S5: It provides user plane tunnelling and tunnel management 496 between SGW and PDN-GW, using GTP or PMIPv6 as the network 497 based mobility management protocol. 499 S1-U: Provides user plane tunnelling and inter eNodeB path 500 switching during handover between eNodeB and SGW, using the 501 GTP-U protocol (GTP user plane). 503 S1-MME: Reference point for the control plane protocol between 504 eNodeB and MME. 506 SGi: It is the interface between the PDN-GW and the packet data 507 network. Packet data network may be an operator external 508 public or private packet data network or an intra operator 509 packet data network. 511 The eNodeB is a base station entity that supports the Long Term 512 Evolution (LTE) air interface and includes functions for radio 513 resource control, user plane ciphering, and other lower layer 514 functions. MME is responsible for control plane functionalities, 515 including authentication, authorization, bearer management, layer-2 516 mobility, etc. 518 The SGW is the Mobility Anchor point for layer-2 mobility. For each 519 MN connected with the EPS, at any given point of time, there is only 520 one SGW. 522 4.2. PDN Connection 524 A PDN connection is an association between a mobile host represented 525 by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented 526 by an APN. The PDN connection is the EPC equivalent of the GPRS PDP 527 context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is 528 responsible for the IP address/prefix allocation to the mobile host. 529 On the device/mobile host a PDN connection is equivalent to a network 530 interface. A host may hence be attached to one or more gateways via 531 separate connections, i.e. PDN connections. Each PDN connection has 532 its own IP address/prefix assigned to it by the PDN and anchored in 533 the corresponding gateway. Applications on the host use the 534 appropriate network interface (PDN connection) for connectivity. 536 4.3. EPS bearer model 538 The logical concept of a bearer has been defined to be an aggregate 539 of one or more IP flows related to one or more services. An EPS 540 bearer exists between the Mobile Node (MN i.e. a mobile host) and the 541 PDN-GW and is used to provide the same level of packet forwarding 542 treatment to the aggregated IP flows constituting the bearer. 543 Services with IP flows requiring a different packet forwarding 544 treatment would therefore require more than one EPS bearer. The 545 mobile host performs the binding of the uplink IP flows to the bearer 546 while the PDN-GW performs this function for the downlink packets. 548 In order to provide low latency for always on connectivity, a default 549 bearer will be provided at the time of startup and an IPv4 address 550 and/or IPv6 prefix gets assigned to the mobile host (this is 551 different from GPRS, where mobile hosts are not automatically 552 assigned with an IP address or prefix). This default bearer will be 553 allowed to carry all traffic which is not associated with a dedicated 554 bearer. Dedicated bearers are used to carry traffic for IP flows 555 that have been identified to require a specific packet forwarding 556 treatment. They may be established at the time of startup; for 557 example, in the case of services that require always-on connectivity 558 and better QoS than that provided by the default bearer. The default 559 bearer and the dedicated bearer(s) associated to it share the same IP 560 address(es)/prefix. 562 An EPS bearer is referred to as a GBR bearer if dedicated network 563 resources related to a Guaranteed Bit Rate (GBR) value that is 564 associated with the EPS bearer are permanently allocated (e.g. by an 565 admission control function in the eNodeB) at bearer establishment/ 566 modification. Otherwise, an EPS bearer is referred to as a non-GBR 567 bearer. The default bearer is always non-GBR, with the resources for 568 the IP flows not guaranteed at eNodeB, and with no admission control. 569 However, the dedicated bearer can be either GBR or non-GBR. A GBR 570 bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) 571 while more than one non-GBR bearer belonging to the same UE shares an 572 Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet 573 loss under congestion while GBR bearers are immune to such losses. 575 5. Address Management 576 5.1. IPv4 Address Configuration 578 Mobile host's IPv4 address configuration is always performed during 579 PDP context/EPS bearer setup procedures (on layer-2). DHCPv4-based 580 [RFC2131] address configuration is supported by the 3GPP 581 specifications, but is not used in wide scale. The mobile host must 582 always support layer-2 based address configuration, since DHCPv4 is 583 optional for both mobile hosts and networks. 585 5.2. IPv6 Address Configuration 587 IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in 588 [RFC4862] is the only supported address configuration mechanism. 589 Stateful DHCPv6-based address configuration is not supported by 3GPP 590 specifications [RFC3315]. On the other hand, Stateless DHCPv6- 591 service to obtain other configuration information is supported 592 [RFC3736]. This implies that the M-bit must always be set to zero 593 and the O-bit may be set to one in the Router Advertisement (RA) sent 594 to the UE. 596 3GPP network allocates each default bearer a unique /64 prefix, and 597 uses layer-2 signaling to suggest user equipment an Interface 598 Identifier that is guaranteed not to conflict with gateway's 599 Interface Identifier. The UE may configure link local address using 600 this Interface Identifier, but is allowed to use also other Interface 601 Identifiers and as many globally scoped addresses as it needs. There 602 is no restriction, for example, of using Privacy Extension for SLAAC 603 [RFC4941] or other similar types of mechanisms. 605 In the 3GPP link model the /64 prefix assigned to the UE is always 606 off-link (i.e. the L-bit in the Prefix Information Option (PIO) in 607 the RA must be set to zero). If the advertised prefix is used for 608 SLAAC then the A-bit in the PIO must be set to one. The details of 609 the 3GPP link-model and address configuration is described in Section 610 11.2.1.3.2a of [3GPP.29.061]. More specifically, the GGSN/PDN-GW 611 guarantees that the /64 prefix is unique for the mobile host. 612 Therefore, there is no need to perform any Duplicate Address 613 Detection (DAD) on addresses the mobile host creates (i.e., the 614 'DupAddrDetectTransmits' variable in the mobile host should be zero). 615 The GGSN/PDN-GW is not allowed to generate any globally unique IPv6 616 addresses for itself using the /64 prefix assigned to the mobile host 617 in the RA. 619 The current 3GPP architecture limits number of prefixes in each 620 bearer to a single /64 prefix. If the mobile host finds more than 621 one prefix in the RA, it only considers the first one and silently 622 discard the others [3GPP.29.061]. Therefore, multi-homing within a 623 single bearer is not possible. Renumbering without closing layer-2 624 connection is also not possible. The lifetime of /64 prefix is bound 625 to lifetime of layer-2 connection even if the advertised prefix 626 lifetime would be longer than the layer-2 connection lifetime. 628 5.3. Prefix Delegation 630 IPv6 prefix delegation is a part of Release-10 and is not covered by 631 any earlier release. However, the /64 prefix allocated for each 632 default bearer (and to the user equipment) may be shared to local 633 area network by user equipment implementing Neighbor Discovery proxy 634 (ND proxy) [RFC4389] functionality. 636 Release-10 prefix delegation uses the DHCPv6-based prefix delegation 637 [RFC3633]. The model defined for Release-10 requires aggregatable 638 prefixes, which means the /64 prefix allocated for the default bearer 639 (and to the user equipment) must be part of the shorter delegated 640 prefix. DHCPv6 prefix delegation has an explicit limitation 641 described in Section 12.1 of [RFC3633] that a prefix delegated to a 642 requesting router cannot be used by the delegating router (i.e., the 643 PDN-GW in this case). This implies the shorter 'delegated prefix' 644 cannot be given to the requesting router (i.e. the user equipment) as 645 such but has to be delivered by the delegating router (i.e. the 646 PDN-GW) in such a way the /64 prefix allocated to the default bearer 647 is not part of the 'delegated prefix'. IETF is working on a solution 648 for DHCPv6-based prefix delegation to exclude a specific prefix from 649 the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. 651 6. 3GPP Dual-Stack Approach to IPv6 653 6.1. 3GPP Networks Prior to Release-8 655 3GPP standards prior to Release-8 provide IPv6 access for cellular 656 devices with PDP contexts of type IPv6 [3GPP.23.060]. For dual-stack 657 access, a PDP context of type IPv6 is established in parallel to the 658 PDP context of type IPv4, as shown in Figure 5 and Figure 6. For 659 IPv4-only service, connections are created over the PDP context of 660 type IPv4 and for IPv6-only service connections are created over the 661 PDP context of type IPv6. The two PDP contexts of different type may 662 use the same APN (and the gateway), however, this aspect is not 663 explicitly defined in standards. Therefore, cellular device and 664 gateway implementations from different vendors may have varying 665 support for this functionality. 667 Y .--. 668 | _(IPv4`. 669 |---+ +---+ +---+ ( PDN ) 670 | D |~~~~~~~//-----| |====| |====( ` . ) ) 671 | S | IPv4 context | S | | G | `--(___.-' 672 | | | G | | G | .--. 673 | M | | S | | S | _(IPv6`. 674 | N | IPv6 context | N | | N | ( PDN ) 675 |///|~~~~~~~//-----| |====|(s)|====( ` . ) ) 676 +---+ +---+ +---+ `--(___.-' 678 Figure 5: A dual-stack mobile host connecting to both IPv4 and IPv6 679 Internet using parallel IPv4-only and IPv6-only PDP contexts 681 Y 682 | 683 |---+ +---+ +---+ 684 | D |~~~~~~~//-----| |====| | .--. 685 | S | IPv4 context | S | | G | _( DS `. 686 | | | G | | G | ( PDN ) 687 | M | | S | | S |====( ` . ) ) 688 | N | IPv6 context | N | | N | `--(___.-' 689 |///|~~~~~~~//-----| |====| | 690 +---+ +---+ +---+ 692 Figure 6: A dual-stack mobile host connecting to dual-stack Internet 693 using parallel IPv4-only and IPv6-only PDP contexts 695 The approach of having parallel IPv4 and IPv6 type of PDP contexts 696 open is not optimal, because two PDP contexts require double the 697 signaling and consume more network resources than a single PDP 698 context. In the figure above the IPv4 and IPv6 PDP contexts are 699 attached to the same GGSN. While this is possible, the DS MS may be 700 attached to different GGSNs in the scenario where one GGSN supports 701 IPv4 PDN connectivity while another GGSN provides IPv6 PDN 702 connectivity. 704 6.2. 3GPP Release-8 and -9 Networks 706 Since 3GPP Release-8, the powerful concept of a dual-stack type of 707 PDN connection and EPS bearer have been introduced [3GPP.23.401]. 708 This enables parallel use of both IPv4 and IPv6 on a single bearer 709 (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler 710 than in earlier 3GPP releases. As of Release-9, GPRS network nodes 711 also support dual-stack type (IPv4v6) PDP contexts. 713 Y 714 | 715 |---+ +---+ +---+ 716 | D | | | | P | .--. 717 | S | | | | D | _( DS `. 718 | | IPv4v6 (DS) | S | | N | ( PDN ) 719 | M |~~~~~~~//-----| G |====| - |====( ` . ) ) 720 | N | bearer | W | | G | `--(___.-' 721 |///| | | | W | 722 +---+ +---+ +---+ 724 Figure 7: A dual-stack mobile host connecting to dual-stack Internet 725 using a single IPv4v6 type PDN connection 727 The following is a description of the various PDP contexts/PDN bearer 728 types that are specified by 3GPP: 730 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 731 two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to 732 get dual stack connectivity. 734 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 735 are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP 736 context is needed to get dual stack connectivity. 738 3. For 2G/3G access to EPC core (PDN-GW via S4 Release-8 SGSN) from 739 Release-8 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 740 which gets mapped to PDN Connection type. Minimum one PDP 741 Context is needed to get dual stack connectivity. 743 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are 744 three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN 745 Connection is needed to get dual stack connectivity. 747 6.3. PDN Connection Establishment Process 749 The PDN connection establishment process is specified in detail in 750 3GPP specifications. Figure 8 illustrates the high level process and 751 signaling involved in the establishment of a PDN connection. 753 UE eNb/ MME SGW PDN-GW HSS/ 754 | BS | | | AAA 755 | | | | | | 756 |---------->|(1) | | | | 757 | |---------->|(1) | | | 758 | | | | | | 759 |/---------------------------------------------------------\| 760 | Authentication and Authorization |(2) 761 |\---------------------------------------------------------/| 762 | | | | | | 763 | | |---------->|(3) | | 764 | | | |---------->|(3) | 765 | | | | | | 766 | | | |<----------|(4) | 767 | | |<----------|(4) | | 768 | |<----------|(5) | | | 769 |/---------\| | | | | 770 | RB setup |(6) | | | | 771 |\---------/| | | | | 772 | |---------->|(7) | | | 773 |---------->|(8) | | | | 774 | |---------->|(9) | | | 775 | | | | | | 776 |============= UL Data =============>==========>|(10) | 777 | | | | | | 778 | | |---------->|(11) | | 779 | | | | | | 780 | | |<----------|(12) | | 781 | | | | | | 782 |<============ DL Data =============<===========|(13) | 783 | | | | | | 785 Figure 8: Simplified PDN connection setup procedure in Release-8 787 1. The UE (i.e the MS) requires a data connection and hence decides 788 to establish a PDN connection with a PDN-GW. The UE sends an 789 "Attach Request" (layer-2) to the BS. The BS forwards this 790 attach request to the MME. 792 2. Authentication of the UE with the AAA server/HSS follows. If 793 the UE is authorized for establishing a data connection, the 794 following steps continue 796 3. The MME sends a "Create Session Request" message to the 797 Serving-GW. The SGW forwards the create session request to the 798 PDN-GW. The SGW knows the address of the PDN-GW to forward the 799 create session request to as a result of this information having 800 been obtained by the MME during the authentication/authorization 801 phase. 803 The UE IPv4 address and/or IPv6 prefix get assigned during this 804 step. If a subscribed IPv4 address and/or IPv6 prefix is 805 statically allocated for the UE for this APN, then the MME 806 already passes the address information to the SGW and eventually 807 to the PDN-GW in the "Create Session Request" message. 808 Otherwise, the PDN-GW manages the address assignment to the UE 809 (there is another variation to this where IPv4 address 810 allocation is delayed until the UE initiates a DHCPv4 exchange 811 but this is not discussed here). 813 4. The PDN-GW creates a PDN connection for the UE and sends "Create 814 Session Response" message to the SGW from which the session 815 request message was received from. The SGW forwards the 816 response to the corresponding MME which originated the request. 818 5. The MME sends the "Attach Accept/Initial Context Setup request" 819 message to the eNodeB/BS. 821 6. The radio bearer between the UE and the eNb is reconfigured 822 based on the parameters received from the MME 824 7. The eNb sends "Initial Context Response" message to the MME. 826 8. The UE sends a "Direct Transfer" message to the eNodeB which 827 includes the Attach complete signal. 829 9. The eNodeB forwards the Attach complete message to the MME. 831 10. The UE can now start sending uplink packets to the PDN GW. 833 11. The MME sends a "Modify Bearer Request" message to the SGW. 835 12. The SGW responds with a "Modify Bearer Response" message. At 836 this time the downlink connection is also ready 838 13. The UE can now start receiving downlink packets 840 The type of PDN connection established between the UE and the PDN-GW 841 can be any of the types described in the previous section. The DS 842 PDN connection, i.e the one which supports both IPv4 and IPv6 packets 843 is the default one that will be established if no specific PDN 844 connection type is specified by the UE in Release-8 networks. 846 6.4. Mobility of 3GPP IPv4v6 Type of Bearers 848 3GPP discussed at length various approaches to support mobility 849 between Release-8 and pre-Release-8 networks for the new dual-stack 850 type of bearers. 852 The chosen approach for mobility is as follows, in short: if a mobile 853 is known to be at risk for doing handovers between Release-8 and pre- 854 Release-8 networks, only single stack bearers are used. Essentially 855 meaning: 857 1. If a network knows a mobile may do handovers between Release-8 858 and pre-Release-8 networks (segment), network will only provide 859 single stack bearers, even if the mobile host requests dual-stack 860 bearers. This can happen e.g. if an operator is using pre- 861 Release-8 SGSNs in some parts of the network. The single stack 862 bearers of Release-8 are easy to map one-to-one to pre-Release-8 863 bearers. 865 2. If a network knows a mobile will not be able to do handover to 866 pre-Release-8 network (segment), it will provide mobile with 867 dual-stack bearers on request. This can happen e.g. if an 868 operator has upgraded their SGSNs to support dual-stack bearers, 869 or if an operator is running LTE-only network. 871 When a network operator and their roaming partners have upgraded 872 their networks to Release-8, it is possible to use the new IPv4v6 873 dual-stack type of bearers. A Release-8 mobile device always 874 requests for a dual-stack bearer, but accepts what is assigned by the 875 network. 877 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 879 3GPP networks can natively transport IPv4 and IPv6 packets between 880 the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of 881 establishing either a dual-stack PDP context or parallel IPv4 and 882 IPv6 PDP contexts. 884 Current deployments of 3GPP networks primarily support IPv4 only. 885 These networks can be upgraded to also support IPv6 PDP contexts. By 886 doing so devices and applications that are IPv6 capable can start 887 utilizing the IPv6 connectivity. This will also ensure that legacy 888 devices and applications continue to work with no impact. As newer 889 devices start using IPv6 connectivity, the demand for actively used 890 IPv4 connections is expected to slowly decrease, helping operators 891 with a transition to IPv6. With a dual-stack approach, there is 892 always the potential to fallback to IPv4. A device which may be 893 roaming in a network wherein IPv6 is not supported by the visited 894 network could fall back to using IPv4 PDP contexts and hence the end 895 user would at least get some connectivity. Unfortunately, dual-stack 896 approach as such does not lower the number of used IPv4 addresses. 897 Every dual-stack bearer still needs to given an IPv4 address, private 898 or public. This is a major concern with dual-stack bearers 899 concerning IPv6 transition. However, if the majority of active IP 900 communication has moved over to IPv6, then in case of NAT44 [RFC1918] 901 IPv4 connections the number of active IPv4 connections can still be 902 expected to gradually decrease and thus giving some level of relief 903 regarding NAT44 function scalability. 905 As the networks evolve to support Release-8 EPS architecture and the 906 dual-stack PDP contexts, newer devices will be able to leverage such 907 capability and have a single bearer which supports both IPv4 and 908 IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP 909 between the MS and the gateway (GGSN/PDN-GW) the transport network 910 capability in terms of whether it supports IPv4 or IPv6 on the 911 interfaces between the eNodeB and SGW or, SGW and PDN-GW is 912 immaterial. 914 8. Deployment issues 916 8.1. Overlapping IPv4 Addresses 918 Given the shortage of globally routable public IPv4 addresses, 919 operators tend to assign private IPv4 addresses [RFC1918] to hosts 920 when they establish an IPv4 only PDP context or an IPv4v6 type PDN 921 context. About 16 million hosts can be assigned a private IPv4 922 address that is unique within a domain. However, in case of many 923 operators the number of subscribers is greater than 16 million. The 924 issue can be dealt with by assigning overlapping RFC 1918 IPv4 925 addresses to hosts. As a result the IPv4 address assigned to a host 926 within the context of a single operator realm would no longer be 927 unique. This has the obvious and know issues of NATed IP connection 928 in the Internet. Direct host to host connectivity becomes 929 complicated, unless the hosts are within the same private address 930 range pool and/or anchored to the same gateway, referrals using IP 931 addresses will have issues and so forth. These are generic issues 932 and not only a concern of the EPS. However, 3GPP as such does not 933 have any mandatory language concerning NAT44 functionality in EPC. 934 Obvious deployment choices apply also to EPC: 936 1. Very large network deployments are partitioned, for example, 937 based on a geographical areas. This partitioning allows 938 overlapping IPv4 addresses ranges to be assigned to hosts that 939 are in different areas. Each area has its own pool of gateways 940 that are dedicated for a certain overlapping IPv4 address range 941 (referred here later as a zone). Standard NAT44 functionality 942 enables the communication between hosts that are assigned the 943 same IPv4 address but belong to different zones, yet are part of 944 the same operator domain. 946 2. A mobile host/device attaches to a gateway as part of the attach 947 process. The number of hosts that a gateway supports is in the 948 order of 1 to 10 million. Hence all the hosts assigned to a 949 single gateway can be assigned private IPv4 addresses. Operators 950 with large subscriber bases have multiple gateways and hence the 951 same [RFC1918] IPv4 address space can be reused across gateways. 952 The IPv4 address assigned to a host is unique within the scope of 953 a single gateway. 955 3. New services requiring direct connectivity between hosts should 956 be build on IPv6. Possible existing IPv4-only services and 957 applications requiring direct connectivity can be ported to IPv6. 959 8.2. IPv6 for transport 961 The various reference points of the 3GPP architecture such as S1-U, 962 S5 and S8 are based on either GTP or PMIPv6. The underlying 963 transport for these reference points can be IPv4 or IPv6. GTP has 964 been able to operate over IPv6 transport (optionally) since R99 and 965 PMIPv6 has supported IPv6 transport starting from its introduction in 966 Release-8. The user plane traffic between the mobile host and the 967 gateway can use either IPv4 or IPv6. These packets are essentially 968 treated as payload by GTP/PMIPv6 and transported accordingly with no 969 real attention paid to the information (at least from a routing 970 perspective) contained in the IPv4 or IPv6 headers. The transport 971 links between the eNodeB and the SGW, and the link between the SGW 972 and PDN-GW can be migrated to IPv6 without any direct implications to 973 the architecture. 975 Currently, the inter-operator (for 3GPP technology) roaming networks 976 are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). 977 Eventually these roaming networks will also get migrated to IPv6, if 978 there is a business reason for that. The migration period can be 979 prolonged considerably because the 3GPP protocols always tunnel user 980 plane traffic in the core network and as described earlier the 981 transport network IP version is not in any way tied to user plane IP 982 version. Furthermore, the design of the inter-operator roaming 983 networks is such that the user plane and transport network IP 984 addressing is completely separated from each other. The inter- 985 operator roaming network itself is also completely separated from the 986 Internet. Only those core network nodes that must be connected to 987 the inter-operator roaming networks are actually visible there, and 988 be able to send and receive (tunneled) traffic within the inter- 989 operator roaming networks. Obviously, in order the roaming to work 990 properly, the operators have to agree on supported protocol versions 991 so that the visited network does not, for example, unnecessarily drop 992 user plane IPv6 traffic. 994 8.3. Operational Aspects of Running Dual-Stack Networks 996 Operating dual-stack networks does imply cost and complexity to a 997 certain extent. However these factors are mitigated by the assurance 998 that legacy devices and services are unaffected and there is always a 999 fallback to IPv4 in case of issues with the IPv6 deployment or 1000 network elements. The model also enables operators to develop 1001 operational experience and expertise in an incremental manner. 1003 Running dual-stack networks requires the management of multiple IP 1004 address spaces. Tracking of hosts needs to be expanded since it can 1005 be identified by either an IPv4 address or IPv6 prefix. Network 1006 elements will also need to be dual-stack capable in order to support 1007 the dual-stack deployment model. 1009 Deployment and migration cases described in Section 6.1 for providing 1010 dual-stack like capability may mean doubled resource usage in 1011 operator's network. This is a major concern against providing dual- 1012 stack like connectivity using techniques discussed in Section 6.1. 1013 Also handovers between networks with different capabilities in terms 1014 of networks being dual-stack like service capable or not, may turn 1015 out hard to comprehend for users and for application/services to cope 1016 with. These facts may add other than just technical concerns for 1017 operators when planning to roll out dual-stack service offerings. 1019 8.4. Operational Aspects of Running a Network with IPv6 Only Bearers 1021 It is possible to allocate IPv6 only type bearers to mobile hosts in 1022 3GPP networks. IPv6 only bearer type has been part of the 3GPP 1023 specification since the beginning. In 3GPP Release-8 (and later) it 1024 was defined that a dual-stack mobile host (or when the radio 1025 equipment has no knowledge of the host IP stack capabilities) must 1026 first attempt to establish a dual-stack bearer and then possibly fall 1027 back to single IP version bearer. A Release-8 (or later) mobile host 1028 with IPv6 only stack can directly attempt to establish an IPv6 only 1029 bearer. The IPv6 only behavior is up to a subscription provisioning 1030 or a PDN-GW configuration, and the fallback scenarios do not 1031 necessarily cause additional signaling. 1033 Although the bullets below introduce IPv6 to IPv4 address translation 1034 and specifically discuss NAT64 technology 1035 [I-D.ietf-behave-v6v4-framework], the current 3GPP Release-8 1036 architecture does not describe the use of address translation or 1037 NAT64. It is up to a specific deployment whether address translation 1038 is part of the network or not. Some operational aspects to consider 1039 for running a network with IPv6 only bearers: 1041 o The mobile hosts must have an IPv6 capable stack and a radio 1042 interface capable of establishing an IPv6 PDP context or PDN 1043 connection. 1045 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 1046 bearers. Furthermore, the SGSN/MME must allow the creation of PDP 1047 Type or PDN Type of IPv6. 1049 o Many of the common applications are IP version agnostic and hence 1050 would work using an IPv6 bearer. However, applications that are 1051 IPv4 specific would not work. 1053 o Inter-operator roaming is another aspect which causes issues, at 1054 least during the ramp up phase of the IPv6 deployment. If the 1055 visited network to which outbound roamers attach to does not 1056 support PDP/PDN Type IPv6, then there needs to be a fallback 1057 option. The fallback option in this specific case is mostly up to 1058 the mobile host to implement. Several cases are discussed in the 1059 following sections. 1061 o If and when a mobile host using IPv6 only bearer needs to access 1062 to IPv4 Internet/network, a translation of some type from IPv6 to 1063 IPv4 has to be deployed in the network. NAT64 (and DNS64) is one 1064 solution that can be used for this purpose and works for a certain 1065 set of protocols (read TCP and UDP, and when applications actually 1066 use DNS for resolving name to IP addresses). 1068 8.5. Restricting Outbound IPv6 Roaming 1070 Roaming was briefly touched upon in Sections 8.2 and 8.4. While 1071 there is interest in offering roaming service for IPv6 enabled mobile 1072 hosts and subscriptions, not all visited networks are prepared for 1073 IPv6 outbound roamers. There are basically two issues. First, the 1074 visited network (S4-)SGSN does not support the IPv6 PDP Context or 1075 IPv4v6 PDP Context types. These should mostly concern pre-Release-8 1076 networks but there is no definitive rule as the deployed feature sets 1077 vary depending on implementations and licenses. Second, the visited 1078 network might not be commercially ready for IPv6 outbound roamers, 1079 while everything might work technically at the user plane level. 1080 This would lead to "revenue leakage" especially from the visited 1081 operator point of view (note that the use of visited network GGSN/ 1082 PDN-GW does not really exist in real deployments today). Therefore, 1083 it might be in the interest of operators to prohibit roaming 1084 selectively within specific visited networks. 1086 Unfortunately, it is not mandatory to implement/deploy 3GPP standards 1087 based solution to selectively prohibit IPv6 roaming without also 1088 prohibiting other packet services (such as IPv4 roaming). However, 1089 there are few possibilities how this can be done in real deployments. 1090 The examples given below are either optional and/or vendor specific 1091 features to the 3GPP EPC: 1093 o Using Policy and Charging Control (PCC) [3GPP.23.203] 1094 functionality and its rules to fail, for example, the bearer 1095 authorization when a desired criteria is met. In this case that 1096 would be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. 1097 The rules can be provisioned either in the home network or locally 1098 in the visited network. 1100 o Some Home Location Register (HLR) and Home Subscriber Server (HSS) 1101 subscriber databases allow prohibiting roaming in a specific 1102 (visited) network for a specified PDN/PDP Type. 1104 The obvious problems are that these solutions are not mandatory, are 1105 not unified across networks, and therefore also lack well-specified 1106 fall back mechanism from the mobile host point of view. 1108 8.6. Inter-rat Handovers and IP Versions 1110 It is obvious that when operators start to incrementally deploy EPS 1111 (and E-UTRAN) along with the existing UTRAN/GERAN, handovers between 1112 different radio technologies (inter-rat handovers) become inevitable. 1113 In case of inter-rat handovers 3GPP supports the following IP 1114 addressing scenarios: 1116 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 1117 bearer. 1119 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 1120 bearer. 1122 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 1123 bearer. 1125 Other types of configurations are considered network planning 1126 mistakes. What the above rules essentially imply is that the network 1127 migration has to be planned and subscriptions provisioned based on 1128 the lowest common nominator, if inter-rat handovers are desired. For 1129 example, if some part of the UTRAN network cannot serve anything but 1130 IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 1131 bearers. Various combinations of subscriber provisioning regarding 1132 IP versions are discussed further in Section 8.7. 1134 8.7. Provisioning of IPv6 Subscribers and Various Combinations During 1135 Initial Network Attachment 1137 Subscribers' provisioned PDP/PDN Types have multiple configurations. 1138 The supported PDP/PDN Type is provisioned per each APN for every 1139 subscriber. The following PDN Types are possible in the HSS for a 1140 Release-8 subscription [3GPP.23.401]: 1142 o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in HLR). 1144 o IPv6 only PDN Type 1146 o IPv4 only PDN Type. 1148 o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not 1149 exist in HLR). 1151 A Release-8 dual-stack mobile host must always attempt to establish a 1152 PDP/PDN Type IPv4v6 bearer. The same also applies when the modem 1153 part of the mobile host does not have exact knowledge whether the 1154 host operating system IP stack is a dual-stack capable or not. A 1155 mobile host that is IPv6 only capable must attempt to establish a 1156 PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4 only 1157 capable must attempt to establish a PDN/PDP Type IPv4 bearer. 1159 In a case the PDP/PDN Type requested by a mobile host does not match 1160 what has been provisioned for the subscriber in the HSS (or HLR), the 1161 mobile host possibly falls back to a different PDP/PDN Type. The 1162 network (i.e. the MME or the SGSN) is able to inform the mobile host 1163 during the network attachment signaling why it did not get the 1164 requested PDP/PDN Type. These response/cause codes are documented in 1165 [3GPP.24.008][3GPP.24.301]. Possible fall back cases include (as 1166 documented in [3GPP.23.401]): 1168 o Requested & provisioned PDP/PDN Types match -> requested. 1170 o Requested IPv4v6 & provisioned IPv6 -> IPv6 and a mobile host 1171 receives indication that IPv6-only bearer is allowed. 1173 o Requested IPv4v6 & provisioned IPv4 -> IPv4 and the mobile host 1174 receives indication that IPv4-only bearer is allowed. 1176 o Requested IPv4v6 & provisioned IPv4_or_IPv6 -> IPv4 or IPv6 is 1177 selected by the MME based on an unspecified criteria. The mobile 1178 host may then attempt to establish, based on the mobile host 1179 implementation, a parallel bearer of a different PDP/PDN Type. 1181 o Other combinations cause the bearer establishment to fail. 1183 In addition to PDP/PDN Types provisioned in the HSS, it is also 1184 possible for a PDN-GW (and a MME) to affect the final selected PDP/ 1185 PDN Type: 1187 o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 1188 or IPv6. If the MME operator had included the "Dual Address 1189 Bearer Flag" into the bearer establishment signaling, then the 1190 mobile host receives an indication that IPv6-only or IPv4-only 1191 bearer is allowed. 1193 o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 1194 or IPv6. If the MME operator had not included the "Dual Address 1195 Bearer Flag" into the bearer establishment signaling, then the 1196 mobile host may attempt to establish, based on the mobile host 1197 implementation, a parallel bearer of different PDP/PDN Type. 1199 If for some reason a SGSN does not understand the requested PDP Type, 1200 then the PDP Type is handled as IPv4. If for some reason a MME does 1201 not understand the requested PDN Type, then the PDN Type is handled 1202 as IPv6. 1204 9. IANA Considerations 1206 This document has no requests to IANA. 1208 10. Security Considerations 1210 This document does not introduce any security related concerns. 1212 11. Summary and Conclusion 1214 The 3GPP network architecture and specifications enable the 1215 establishment of IPv4 and IPv6 connections through the use of 1216 appropriate PDP context types. The current generation of deployed 1217 networks can support dual-stack connectivity if the packet core 1218 network elements such as the SGSN and GGSN have the capability. With 1219 Release-8, 3GPP has specified a more optimal PDP context type which 1220 enables the transport of IPv4 and IPv6 packets within a single PDP 1221 context between the mobile station and the gateway. 1223 As devices and applications are upgraded to support IPv6 they can 1224 start leveraging the IPv6 connectivity provided by the networks while 1225 maintaining the fall back to IPv4 capability. Enabling IPv6 1226 connectivity in the 3GPP networks by itself will provide some degree 1227 of relief to the IPv4 address space as many of the applications and 1228 services can start to work over IPv6. However without comprehensive 1229 testing of different applications and solutions that exist today and 1230 are widely used, for their ability to operate over IPv6 PDN 1231 connections, an IPv6 only access would cause disruptions. 1233 12. Acknowledgements 1235 The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and 1236 Zhenqiang Li, Mikael Abrahamsson, James Woodyatt and Cameron Byrne 1237 for their reviews and comments on this document. 1239 13. Informative References 1241 [3GPP.23.060] 1242 3GPP, "General Packet Radio Service (GPRS); Service 1243 description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. 1245 [3GPP.23.203] 1246 3GPP, "Policy and charging control architecture (PCC)", 1247 3GPP TS 23.203 8.11.0, September 2010. 1249 [3GPP.23.401] 1250 3GPP, "General Packet Radio Service (GPRS) enhancements 1251 for Evolved Universal Terrestrial Radio Access Network 1252 (E-UTRAN) access", 3GPP TS 23.401 10.3.0, March 2011. 1254 [3GPP.23.975] 1255 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, 1256 June 2010. 1258 [3GPP.24.008] 1259 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 1260 TS 24.008 8.12.0, December 2010. 1262 [3GPP.24.301] 1263 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1264 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1266 [3GPP.29.060] 1267 3GPP, "General Packet Radio Service (GPRS); GPRS 1268 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1269 3GPP TS 29.274 8.8.0, April 2010. 1271 [3GPP.29.061] 1272 3GPP, "Interworking between the Public Land Mobile Network 1273 (PLMN) supporting packet based services and Packet Data 1274 Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. 1276 [3GPP.29.274] 1277 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1278 Packet Radio Service (GPRS) Tunnelling Protocol for 1279 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 1280 December 2010. 1282 [GSMA.IR.34] 1283 GSMA, "Inter-PLMN Backbone Guidelines", GSMA 1284 PRD IR.34.4.9, March 2010. 1286 [I-D.ietf-behave-v6v4-framework] 1287 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1288 IPv4/IPv6 Translation", 1289 draft-ietf-behave-v6v4-framework-10 (work in progress), 1290 August 2010. 1292 [I-D.ietf-dhc-pd-exclude] 1293 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1294 "Prefix Exclude Option for DHCPv6-based Prefix 1295 Delegation", draft-ietf-dhc-pd-exclude-01 (work in 1296 progress), January 2011. 1298 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1299 E. Lear, "Address Allocation for Private Internets", 1300 BCP 5, RFC 1918, February 1996. 1302 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1303 RFC 2131, March 1997. 1305 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1306 and M. Carney, "Dynamic Host Configuration Protocol for 1307 IPv6 (DHCPv6)", RFC 3315, July 2003. 1309 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1310 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1311 December 2003. 1313 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1314 (DHCP) Service for IPv6", RFC 3736, April 2004. 1316 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1317 Proxies (ND Proxy)", RFC 4389, April 2006. 1319 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1320 Address Autoconfiguration", RFC 4862, September 2007. 1322 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1323 Extensions for Stateless Address Autoconfiguration in 1324 IPv6", RFC 4941, September 2007. 1326 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1327 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1329 Authors' Addresses 1331 Jouni Korhonen (editor) 1332 Nokia Siemens Networks 1333 Linnoitustie 6 1334 FI-02600 Espoo 1335 FINLAND 1337 Email: jouni.nospam@gmail.com 1339 Jonne Soininen 1340 Renesas Mobile 1342 Email: jonne.soininen@renesasmobile.com 1344 Basavaraj Patil 1345 Nokia 1346 6021 Connection drive 1347 Irving, TX 75039 1348 USA 1350 Email: basavaraj.patil@nokia.com 1352 Teemu Savolainen 1353 Nokia 1354 Hermiankatu 12 D 1355 FI-33720 Tampere 1356 FINLAND 1358 Email: teemu.savolainen@nokia.com 1359 Gabor Bajko 1360 Nokia 1361 323 Fairchild drive 6 1362 Mountain view, CA 94043 1363 USA 1365 Email: gabor.bajko@nokia.com 1367 Kaisu Iisakkila 1368 Renesas Mobile 1370 Email: kaisu.iisakkila@renesasmobile.com