idnits 2.17.1 draft-ietf-v6ops-3gpp-eps-01.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 (May 2, 2011) is 4736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GGSN' is mentioned on line 382, 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 3316 (Obsoleted by RFC 7066) -- 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 (==), 6 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: November 3, 2011 Renesas Mobile 6 B. Patil 7 T. Savolainen 8 G. Bajko 9 Nokia 10 K. Iisakkila 11 Renesas Mobile 12 May 2, 2011 14 IPv6 in 3GPP Evolved Packet System 15 draft-ietf-v6ops-3gpp-eps-01 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 November 3, 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 5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 15 79 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 16 80 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 16 81 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 17 82 6.3. PDN Connection Establishment Process . . . . . . . . . . . 18 83 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 21 84 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 21 85 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 22 86 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 22 87 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 23 88 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 24 89 8.4. Operational Aspects of Running a Network with IPv6 90 Only Bearers . . . . . . . . . . . . . . . . . . . . . . . 24 91 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 25 92 8.6. Inter-rat Handovers and IP Versions . . . . . . . . . . . 26 93 8.7. Provisioning of IPv6 Subscribers and Various 94 Combinations During Initial Network Attachment . . . . . . 27 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 28 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 99 13. Informative References . . . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 102 1. Introduction 104 IPv6 has been specified in the 3rd Generation Partnership Project 105 (3GPP) standards since the early architectures developed for R99 106 General Packet Radio Service (GPRS). However, the support for IPv6 107 in commercially deployed networks by the end of 2010 is nearly non- 108 existent. There are many factors that can be attributed to the lack 109 of IPv6 deployment in 3GPP networks. The most relevant one is 110 essentially the same as the reason for IPv6 not being deployed by 111 other networks as well, i.e. the lack of business and commercial 112 incentives for deployment. 3GPP network architectures have also 113 evolved since 1999 (since R99). The most recent version of the 3GPP 114 architecture, the Evolved Packet System (EPS), which is commonly 115 referred to as SAE, LTE or Release-8, is a packet centric 116 architecture. The number of subscribers and devices that are using 117 the 3GPP networks for Internet connectivity and data services has 118 also increased significantly. With the subscriber growth numbers 119 projected to increase even further and the IPv4 addresses depletion 120 problem looming in the near term, 3GPP operators and vendors have 121 started the process of identifying the scenarios and solutions needed 122 to transition to IPv6. 124 This document describes the establishment of IP connectivity in 3GPP 125 network architectures, specifically in the context of IP bearers for 126 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is 127 supported as per the current set of 3GPP specifications. Some of the 128 issues and concerns with respect to deployment and shortage of 129 private IPv4 addresses within a single network domain are also 130 discussed. 132 The IETF has specified a set of tools and mechanisms that can be 133 utilized for transitioning to IPv6. In addition to operating dual- 134 stack networks during the transition from IPv4 to IPv6 phase, the two 135 alternative categories for the transition are encapsulation and 136 translation. Most of the mechanisms available in the toolbox can be 137 categorized into either translation or encapsulation approaches. The 138 IETF continues to specify additional solutions for enabling the 139 transition based on the deployment scenarios and operator/ISP 140 requirements. There is no single approach for transition to IPv6 141 that can meet the needs for all deployments and models. The 3GPP 142 scenarios for transition, described in [3GPP.23.975], can be 143 addressed using transition mechanisms that are already available in 144 the toolbox. The objective of transition to IPv6 in 3GPP networks is 145 to ensure that: 147 1. Legacy devices and hosts which have an IPv4 only stack will 148 continue to be provided with IP connectivity to the Internet and 149 services, 151 2. Devices which are dual-stack can access the Internet either via 152 IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the 153 capability of: 155 A. the application on the host, 157 B. the support for IPv4 and IPv6 bearers by the network and/or, 159 C. the capability of the server(s) and other end points. 161 3GPP networks are capable of providing a host with IPv4 and IPv6 162 connectivity today, albeit in many cases with upgrades to network 163 elements such as the SGSN and GGSN. 165 2. 3GPP Terminology and Concepts 167 2.1. Terminology 169 Access Point Name 171 Access Point Name (APN) is a fully qualified domain name and 172 resolves to a specific gateway in an operators network. The APNs 173 are piggybacked on the administration of the DNS namespace. 175 Packet Data Protocol Context 177 A Packet Data Protocol (PDP) Context is the equivalent of a 178 virtual connection between the host and a gateway. 180 General Packet Radio Service 182 General Packet Radio Service (GPRS) is a packet oriented mobile 183 data service available to users of the 2G and 3G cellular 184 communication systems Global System for Mobile communications 185 (GSM), and specified by 3GPP. 187 Packet Data Network 189 Packet Data Network (PDN) is a packet based network that either 190 belongs to the operator or is an external network such as Internet 191 and corporate intranet. The user eventually accesses services in 192 one or more PDNs. The operator's packet domain network are 193 separated from packet data networks either by GGSNs or PDN 194 Gateways (PDN-GW). 196 Gateway GPRS Support Node 198 Gateway GPRS Support Node (GGSN) is a gateway function in GPRS, 199 which provides connectivity to Internet or other PDNs. The host 200 attaches to a GGSN identified by an APN assigned to it by an 201 operator. The GGSN also serves as the topological anchor for 202 addresses/prefixes assigned to the mobile host. 204 Packet Data Network Gateway 206 Packet Data Network Gateway (PDN-GW) is a gateway function in 207 Evolved Packet System (EPS), which provides connectivity to 208 Internet or other PDNs. The host attaches to a PDN-GW identified 209 by an APN assigned to it by an operator. The PDN-GW also serves 210 as the topological anchor for addresses/prefixes assigned to the 211 mobile host. 213 Serving Gateway 215 Serving Gateway (SGW) is a gateway function in EPS, which 216 terminates the interface towards E-UTRAN. The SGW is the Mobility 217 Anchor point for layer-2 mobility (inter-eNodeB handovers). For 218 each User Equipment connected with the EPS, at any given point of 219 time, there is only one SGW. The SGW is essentially the user 220 plane part of the GPRS' SGSN forwarding packets between a PDN-GW. 222 Serving Gateway Support Node 224 Serving Gateway Support Node (SGSN) is a network element that is 225 located between the radio access network (RAN) and the gateway 226 (GGSN). A per mobile host point to point (p2p) tunnel between the 227 GGSN and SGSN transports the packets between the mobile host and 228 the gateway. 230 GPRS tunnelling protocol 232 GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.274] is a 233 tunnelling protocol defined by 3GPP. It is a network based 234 mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) 235 [RFC5213]. However, GTP also provides functionality beyond 236 mobility such as inband signaling related to Quality of Service 237 (QoS) and charging among others. 239 Evolved Packet System 241 Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 242 system characterized by higher-data-rate, lower-latency, packet- 243 optimized system that supports multiple Radio Access Technologies 244 (RAT). The EPS comprises the Evolved Packet Core (EPC) together 245 with the evolved radio access network (E-UTRA and E-UTRAN). 247 Mobility Management Entity 249 Mobility Management Entity (MME) is a network element that is 250 responsible for control plane functionalities, including 251 authentication, authorization, bearer management, layer-2 252 mobility, etc. The MME is essentially the control plane part of 253 the GPRS' SGSN and not located on the user plane data path, i.e. 254 user plane traffic bypasses the MME. 256 UMTS Terrestrial Radio Access Network 258 UMTS Terrestrial Radio Access Network (UTRAN) is communications 259 network, commonly referred to as 3G, and consists of NodeBs (3G 260 base station) and Radio Network Controllers (RNC) which make up 261 the UMTS radio access network. The UTRAN allows connectivity 262 between the mobile host/device and the core network. UTRAN 263 comprises of WCDMA, HSPA and HSPA+ radio technologies. 265 Wideband Code Division Multiple Access 267 The Wideband Code Division Multiple Access (WCDMA) is the radio 268 interface used in UMTS networks. 270 High Speed Packet Access 272 The High Speed Packet Access (HSPA) and the Evolved High Speed 273 Packet Access (HSPA+) are enhanced versions of the WCDMA and 274 UTRAN, thus providing more data throughput and lower latencies. 276 Evolved UTRAN 278 Evolved UTRAN (E-UTRAN) is communications network, sometimes 279 referred to as 4G, and consists of eNodeBs (4G base station) which 280 make up the E-UTRAN radio access network. The E-UTRAN allows 281 connectivity between the mobile host/device and the core network. 283 eNodeB 285 The eNodeB is a base station entity that supports the Long Term 286 Evolution (LTE) air interface. 288 GSM EDGE Radio Access Network 290 GSM EDGE Radio Access Network (GERAN) is communications network, 291 commonly referred to as 2G or 2.5G, and consists of base stations 292 and Base Station Controllers (BSC) which make up the GSM EDGE 293 radio access network. The GERAN allows connectivity between the 294 mobile host/device and the core network. 296 UE, MS, MN and Mobile 298 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 299 Node) and, mobile refer to the devices which are hosts with 300 ability to obtain Internet connectivity via a 3GPP network. The 301 terms UE, MS, MN and devices are used interchangeably within this 302 document. 304 PCC 306 The Policy and Charging Control (PCC) framework is used for QoS 307 policy and charging control. It is optional for 3GPP EPS but 308 needed if dynamic policy and charging control by means of PCC 309 rules based on user and services are desired. 311 HLR 313 The Home Location Register (HLR) is a pre-Release-5 database (the 314 reality regarding releases is different, though) for a given 315 subscriber. It is the entity containing the subscription-related 316 information to support the network entities actually handling 317 calls/sessions. 319 HSS 321 The Home Subscriber Server (HSS) is a database for a given 322 subscriber and got introduced in 3GPP Release-5. It is the entity 323 containing the subscription-related information to support the 324 network entities actually handling calls/sessions. 326 2.2. The concept of APN 328 The Access Point Name (APN) essentially refers to a gateway in the 329 3GPP network. The 'complete' APN is expressed in a form of a Fully 330 Qualified Domain Name (FQDN) and also piggybacked on the 331 administration of the DNS namespace, thus effectively allowing the 332 discovery of gateways using the DNS. Mobile hosts/devices can choose 333 to attach to a specific gateway in the packet core. The gateway 334 provides connectivity to the Packet Data Network (PDN) such as the 335 Internet. An operator may also include gateways which do not provide 336 Internet connectivity, rather a connectivity to closed network 337 providing a set of operator's own services. A mobile host/device can 338 be attached to one or more gateways simultaneously. The gateway in a 339 3GPP network is the GGSN or PDN-GW. Figure 1 below illustrates the 340 APN-based network connectivity concept. 342 .--. 343 _(. `) 344 .--. +------------+ _( PDN `)_ 345 _(Core`. |GW1 |====( Internet `) 346 +---+ ( NW )------|APN=internet| ( ` . ) ) 347 [MN]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' 348 ^ +---+ `--(___.-' | 349 | | .--. 350 | | +----------+ _(.PDN`) 351 | +--|GW2 | _(Operator`)_ 352 | |APN=OpServ|====( Services `) 353 MN is attached +----------+ ( ` . ) ) 354 to GW1 and GW2 `--(_______)---' 355 simultaneously 357 Figure 1: Mobile host/device attached to multiple APNs simultaneously 359 3. IP over 3GPP GPRS 361 3.1. Introduction to 3GPP GPRS 363 A simplified 2G/3G GPRS architecture is illustrated in Figure 2. 364 This architecture basically covers the GPRS core network since R99 to 365 Release-7, and radio access technologies such as GSM (2G), EDGE (2G, 366 ofter referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred 367 as 3.5G). The architecture shares obvious similarities with the 368 Evolved Packet System (EPS) as will be seen in Section 4. Based on 369 Gn/Gp interfaces, the GPRS core network functionality is logically 370 implemented on two network nodes, the SGSN and the GGSN. 372 3G .--. 373 Uu +-----+ Iu +----+ +----+ _( `. 374 [TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) 375 +-----+ +----+ Gn +----+ Gi ( ` . ) ) 376 / | `--(___.-' 377 2G Gb-- | 378 +---+ / --Gp 379 [TE]+[MT]~~|~~~|BSS|___/ | 380 Um +---+ .--. 381 _(. `) 382 _( [GGSN] `)_ 383 ( other `) 384 ( ` . PLMN ) ) 385 `--(_______)---' 387 Figure 2: Overview of the 2G/3G GPRS Logical Architecture 389 Gn/Gp: These interfaces provide a network based mobility service for 390 a mobile host and are used between a SGSN and a GGSN. The Gn 391 interface is used when GGSN and SGSN are located inside one 392 operator (i.e. PLMN). The Gp-interface is used if the GGSN 393 and the SGSN are located in different operator domains (i.e. 394 'other' PLMN). GTP protocol is defined for the Gn/Gp 395 interfaces (both GTP-C for the control plane and GTP-U for 396 the user plane). 398 Gb: Is the Base Station System (BSS) to SGSN interface, which is 399 used to carry information concerning packet data transmission 400 and layer-2 mobility management. The Gb-interface is based 401 on either on Frame Relay or IP. 403 Iu: Is the Radio Network System (RNS) to SGSN interface, which is 404 used to carry information concerning packet data transmission 405 and layer-2 mobility management. The user plane part of the 406 Iu-interface (actually the Iu-PS) is based on GTP-U. The 407 control plane part of the Iu-interface is based on Radio 408 Access Network Application Protocol (RANAP). 410 Gi: It is the interface between the GGSN and a PDN. The PDN may 411 be an operator external public or private packet data network 412 or an intra-operator packet data network. 414 Uu/Um: Are either 2G or 3G radio interfaces between a mobile 415 terminal and a respective radio access network. 417 The SGSN is responsible for the delivery of data packets from and to 418 the mobile hosts within its geographical service area when a direct 419 tunnel option is not used. If the direct tunnel is used, then the 420 user plane goes directly between the RNS and the GGSN. The control 421 plane traffic always goes through the SGSN. For each mobile host 422 connected with the GPRS, at any given point of time, there is only 423 one SGSN. 425 3.2. PDP Context 427 A PDP context is an association between a mobile host represented by 428 one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by 429 an APN. Each PDN can be accessed via a gateway (typically a GGSN or 430 PDN-GW). On the device/mobile host a PDP context is equivalent to a 431 network interface. A host may hence be attached to one or more 432 gateways via separate connections, i.e. PDP contexts. Each primary 433 PDP context has its own IPv4 address and/or one /64 IPv6 prefix 434 assigned to it by the PDN and anchored in the corresponding gateway. 436 Applications on the host use the appropriate network interface (PDP 437 context) for connectivity to a specific PDN. Figure 3 represents a 438 high level view of what a PDP context implies in 3GPP networks. 440 Y 441 | +---------+ .--. 442 |--+ __________________________ | APNx in | _( `. 443 | |O______PDPc1_______________)| GGSN / |----(Internet) 444 |MS| | PDN-GW | ( ` . ) ) 445 |/ | +---------+ `--(___.-' 446 |UE| _______________________ +---------+ .--. 447 | |O______PDPc2____________)| APNy in | _(Priv`. 448 +--+ | GGSN / |-------(Network ) 449 | PDN-GW | ( ` . ) ) 450 +---------+ `--(___.-' 452 Figure 3: PDP contexts between the MS/UE and gateway 454 In the above figure there are two PDP contexts at the MS/UE (UE=User 455 Equipment in 3GPP parlance). The 'PDPc1' PDP context that is 456 connected to APNx provided Internet connectivity and the 'PDPc2' PDP 457 context provides connectivity to a private IP network via APNy (as an 458 example this network may include operator specific services such as 459 MMS (Multi media service). An application on the host such as a web 460 browser would use the PDP context that provides Internet connectivity 461 for accessing services on the Internet. An application such as MMS 462 would use APNy in the figure above because the service is provided 463 through the private network. 465 4. IP over 3GPP EPS 467 4.1. Introduction to 3GPP EPS 469 In its most basic form, the EPS architecture consists of only two 470 nodes on the user plane, a base station and a core network Gateway 471 (GW). The basic EPS architecture is illustrated in Figure 4. The 472 Mobility Management Entity (MME) node performs control-plane 473 functionality and is separated from the node(s) that performs bearer- 474 plane functionality (GW), with a well-defined open interface between 475 them (S11). The optional interface S5 can be used to split the 476 Gateway (GW) into two separate nodes, the Serving Gateway (SGW) and 477 the PDN-GW. This allows independent scaling and growth of traffic 478 throughput and control signal processing. The functional split of 479 gateways also allows for operators to choose optimized topological 480 locations of nodes within the network and enables various deployment 481 models including the sharing of radio networks between different 482 operators. 484 +--------+ 485 S1-MME +-------+ S11 | IP | 486 +----|----| MME |---|----+ |Services| 487 | | | | +--------+ 488 | +-------+ | |SGi 489 +----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+ 490 |MN |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | 491 | |========|=======|====================|=======|======| | 492 +----+ +-------+DualStack EPS Bearer+-------+ +-------+ 494 Figure 4: EPS Architecture for 3GPP Access 496 S5: It provides user plane tunnelling and tunnel management 497 between SGW and PDN-GW, using GTP or PMIPv6 as the network 498 based mobility management protocol. 500 S1-U: Provides user plane tunnelling and inter eNodeB path 501 switching during handover between eNodeB and SGW, using the 502 GTP-U protocol (GTP user plane). 504 S1-MME: Reference point for the control plane protocol between 505 eNodeB and MME. 507 SGi: It is the interface between the PDN-GW and the packet data 508 network. Packet data network may be an operator external 509 public or private packet data network or an intra operator 510 packet data network. 512 The eNodeB is a base station entity that supports the Long Term 513 Evolution (LTE) air interface and includes functions for radio 514 resource control, user plane ciphering, and other lower layer 515 functions. MME is responsible for control plane functionalities, 516 including authentication, authorization, bearer management, layer-2 517 mobility, etc. 519 The SGW is the Mobility Anchor point for layer-2 mobility. For each 520 MN connected with the EPS, at any given point of time, there is only 521 one SGW. 523 4.2. PDN Connection 525 A PDN connection is an association between a mobile host represented 526 by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented 527 by an APN. The PDN connection is the EPC equivalent of the GPRS PDP 528 context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is 529 responsible for the IP address/prefix allocation to the mobile host. 530 On the device/mobile host a PDN connection is equivalent to a network 531 interface. A host may hence be attached to one or more gateways via 532 separate connections, i.e. PDN connections. Each PDN connection has 533 its own IP address/prefix assigned to it by the PDN and anchored in 534 the corresponding gateway. Applications on the host use the 535 appropriate network interface (PDN connection) for connectivity. 537 4.3. EPS bearer model 539 The logical concept of a bearer has been defined to be an aggregate 540 of one or more IP flows related to one or more services. An EPS 541 bearer exists between the Mobile Node (MN i.e. a mobile host) and the 542 PDN-GW and is used to provide the same level of packet forwarding 543 treatment to the aggregated IP flows constituting the bearer. 544 Services with IP flows requiring a different packet forwarding 545 treatment would therefore require more than one EPS bearer. The 546 mobile host performs the binding of the uplink IP flows to the bearer 547 while the PDN-GW performs this function for the downlink packets. 549 In order to provide low latency for always on connectivity, a default 550 bearer will be provided at the time of startup and an IPv4 address 551 and/or IPv6 prefix gets assigned to the mobile host (this is 552 different from GPRS, where mobile hosts are not automatically 553 assigned with an IP address or prefix). This default bearer will be 554 allowed to carry all traffic which is not associated with a dedicated 555 bearer. Dedicated bearers are used to carry traffic for IP flows 556 that have been identified to require a specific packet forwarding 557 treatment. They may be established at the time of startup; for 558 example, in the case of services that require always-on connectivity 559 and better QoS than that provided by the default bearer. The default 560 bearer and the dedicated bearer(s) associated to it share the same IP 561 address(es)/prefix. 563 An EPS bearer is referred to as a GBR bearer if dedicated network 564 resources related to a Guaranteed Bit Rate (GBR) value that is 565 associated with the EPS bearer are permanently allocated (e.g. by an 566 admission control function in the eNodeB) at bearer establishment/ 567 modification. Otherwise, an EPS bearer is referred to as a non-GBR 568 bearer. The default bearer is always non-GBR, with the resources for 569 the IP flows not guaranteed at eNodeB, and with no admission control. 570 However, the dedicated bearer can be either GBR or non-GBR. A GBR 571 bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) 572 while more than one non-GBR bearer belonging to the same UE shares an 573 Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet 574 loss under congestion while GBR bearers are immune to such losses. 576 5. Address Management 577 5.1. IPv4 Address Configuration 579 Mobile host's IPv4 address configuration is always performed during 580 PDP context/EPS bearer setup procedures (on layer-2). DHCPv4-based 581 [RFC2131] address configuration is supported by the 3GPP 582 specifications, but is not used in wide scale. The mobile host must 583 always support layer-2 based address configuration, since DHCPv4 is 584 optional for both mobile hosts and networks. 586 5.2. IPv6 Address Configuration 588 IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in 589 [RFC4862] is the only supported address configuration mechanism. 590 Stateful DHCPv6-based address configuration is not supported by 3GPP 591 specifications [RFC3315]. On the other hand, Stateless DHCPv6- 592 service to obtain other configuration information is supported 593 [RFC3736]. This implies that the M-bit must always be set to zero 594 and the O-bit may be set to one in the Router Advertisement (RA) sent 595 to the UE. 597 3GPP network allocates each default bearer a unique /64 prefix, and 598 uses layer-2 signaling to suggest user equipment an Interface 599 Identifier that is guaranteed not to conflict with gateway's 600 Interface Identifier. The UE must configure its link-local address 601 using this Interface Identifier. The UE is allowed to use any 602 Interface Identifier it wishes for the other addresses it configures. 603 There is no restriction, for example, of using Privacy Extension for 604 SLAAC [RFC4941] or other similar types of mechanisms. 606 In the 3GPP link model the /64 prefix assigned to the UE is always 607 off-link (i.e. the L-bit in the Prefix Information Option (PIO) in 608 the RA must be set to zero). If the advertised prefix is used for 609 SLAAC then the A-bit in the PIO must be set to one. The details of 610 the 3GPP link-model and address configuration is described in Section 611 11.2.1.3.2a of [3GPP.29.061]. More specifically, the GGSN/PDN-GW 612 guarantees that the /64 prefix is unique for the mobile host. 613 Therefore, there is no need to perform any Duplicate Address 614 Detection (DAD) on addresses the mobile host creates (i.e., the 615 'DupAddrDetectTransmits' variable in the mobile host should be zero). 616 The GGSN/PDN-GW is not allowed to generate any globally unique IPv6 617 addresses for itself using the /64 prefix assigned to the mobile host 618 in the RA. 620 The current 3GPP architecture limits number of prefixes in each 621 bearer to a single /64 prefix. If the mobile host finds more than 622 one prefix in the RA, it only considers the first one and silently 623 discard the others [3GPP.29.061]. Therefore, multi-homing within a 624 single bearer is not possible. Renumbering without closing layer-2 625 connection is also not possible. The lifetime of /64 prefix is bound 626 to lifetime of layer-2 connection even if the advertised prefix 627 lifetime would be longer than the layer-2 connection lifetime. 629 5.3. Prefix Delegation 631 IPv6 prefix delegation is a part of Release-10 and is not covered by 632 any earlier release. However, the /64 prefix allocated for each 633 default bearer (and to the user equipment) may be shared to local 634 area network by user equipment implementing Neighbor Discovery proxy 635 (ND proxy) [RFC4389] functionality. 637 Release-10 prefix delegation uses the DHCPv6-based prefix delegation 638 [RFC3633]. The model defined for Release-10 requires aggregatable 639 prefixes, which means the /64 prefix allocated for the default bearer 640 (and to the user equipment) must be part of the shorter delegated 641 prefix. DHCPv6 prefix delegation has an explicit limitation 642 described in Section 12.1 of [RFC3633] that a prefix delegated to a 643 requesting router cannot be used by the delegating router (i.e., the 644 PDN-GW in this case). This implies the shorter 'delegated prefix' 645 cannot be given to the requesting router (i.e. the user equipment) as 646 such but has to be delivered by the delegating router (i.e. the 647 PDN-GW) in such a way the /64 prefix allocated to the default bearer 648 is not part of the 'delegated prefix'. IETF is working on a solution 649 for DHCPv6-based prefix delegation to exclude a specific prefix from 650 the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. 652 5.4. IPv6 Neighbor Discovery Considerations 654 3GPP link between the UE and the next hop router (e.g. GGSN) 655 resemble a point to point (p2p) link, which has no link-layer 656 addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. 657 The UE IP stack has to take this into consideration. When the 3GPP 658 PDP Context appears as a PPP interface/link to the UE, the IP stack 659 is usually prepared to handle Neighbor Discovery protocol and the 660 related Neighbor Cache state machine transitions in an appropriate 661 way, even thought Neighbor Discovery protocol messages contain no 662 link layer address information. However, some operating systems 663 discard Router Advertisements on their PPP interface/link as a 664 default setting. This causes the SLAAC to fail when the 3GPP PDP 665 Context gets established, thus stalling all IPv6 traffic. 667 Currently several operating systems and their network drivers can 668 make the 3GPP PDP Context to appear as an IEEE802 interface/link to 669 the IP stack. This has few known issues, especially when the IP 670 stack is made to believe the underlying link has link-layer 671 addresses. First, the Neighbor Advertisement sent by a GGSN as a 672 response to an address resolution triggered Neighbor Solicitation may 673 not contain a Target Link-Layer address option (as suggested in 674 [RFC4861] Section 4.4). Then it is possible that the address 675 resolution never completes when the UE tries to resolve the link- 676 layer address of the GGSN, thus stalling all IPv6 traffic. 678 Second, the GGSN may simply discard all address resolution triggered 679 Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1 680 that address resolution and next-hop determination are not needed). 681 As a result the address resolution never completes when the UE tries 682 to resolve the link-layer address of the GGSN, thus stalling all IPv6 683 traffic. 685 6. 3GPP Dual-Stack Approach to IPv6 687 6.1. 3GPP Networks Prior to Release-8 689 3GPP standards prior to Release-8 provide IPv6 access for cellular 690 devices with PDP contexts of type IPv6 [3GPP.23.060]. For dual-stack 691 access, a PDP context of type IPv6 is established in parallel to the 692 PDP context of type IPv4, as shown in Figure 5 and Figure 6. For 693 IPv4-only service, connections are created over the PDP context of 694 type IPv4 and for IPv6-only service connections are created over the 695 PDP context of type IPv6. The two PDP contexts of different type may 696 use the same APN (and the gateway), however, this aspect is not 697 explicitly defined in standards. Therefore, cellular device and 698 gateway implementations from different vendors may have varying 699 support for this functionality. 701 Y .--. 702 | _(IPv4`. 703 |---+ +---+ +---+ ( PDN ) 704 | D |~~~~~~~//-----| |====| |====( ` . ) ) 705 | S | IPv4 context | S | | G | `--(___.-' 706 | | | G | | G | .--. 707 | M | | S | | S | _(IPv6`. 708 | N | IPv6 context | N | | N | ( PDN ) 709 |///|~~~~~~~//-----| |====|(s)|====( ` . ) ) 710 +---+ +---+ +---+ `--(___.-' 712 Figure 5: A dual-stack mobile host connecting to both IPv4 and IPv6 713 Internet using parallel IPv4-only and IPv6-only PDP contexts 715 Y 716 | 717 |---+ +---+ +---+ 718 | D |~~~~~~~//-----| |====| | .--. 719 | S | IPv4 context | S | | G | _( DS `. 720 | | | G | | G | ( PDN ) 721 | M | | S | | S |====( ` . ) ) 722 | N | IPv6 context | N | | N | `--(___.-' 723 |///|~~~~~~~//-----| |====| | 724 +---+ +---+ +---+ 726 Figure 6: A dual-stack mobile host connecting to dual-stack Internet 727 using parallel IPv4-only and IPv6-only PDP contexts 729 The approach of having parallel IPv4 and IPv6 type of PDP contexts 730 open is not optimal, because two PDP contexts require double the 731 signaling and consume more network resources than a single PDP 732 context. In the figure above the IPv4 and IPv6 PDP contexts are 733 attached to the same GGSN. While this is possible, the DS MS may be 734 attached to different GGSNs in the scenario where one GGSN supports 735 IPv4 PDN connectivity while another GGSN provides IPv6 PDN 736 connectivity. 738 6.2. 3GPP Release-8 and -9 Networks 740 Since 3GPP Release-8, the powerful concept of a dual-stack type of 741 PDN connection and EPS bearer have been introduced [3GPP.23.401]. 742 This enables parallel use of both IPv4 and IPv6 on a single bearer 743 (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler 744 than in earlier 3GPP releases. As of Release-9, GPRS network nodes 745 also support dual-stack type (IPv4v6) PDP contexts. 747 Y 748 | 749 |---+ +---+ +---+ 750 | D | | | | P | .--. 751 | S | | | | D | _( DS `. 752 | | IPv4v6 (DS) | S | | N | ( PDN ) 753 | M |~~~~~~~//-----| G |====| - |====( ` . ) ) 754 | N | bearer | W | | G | `--(___.-' 755 |///| | | | W | 756 +---+ +---+ +---+ 758 Figure 7: A dual-stack mobile host connecting to dual-stack Internet 759 using a single IPv4v6 type PDN connection 761 The following is a description of the various PDP contexts/PDN bearer 762 types that are specified by 3GPP: 764 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 765 two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to 766 get dual stack connectivity. 768 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 769 are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP 770 context is needed to get dual stack connectivity. 772 3. For 2G/3G access to EPC core (PDN-GW via S4 Release-8 SGSN) from 773 Release-8 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 774 which gets mapped to PDN Connection type. Minimum one PDP 775 Context is needed to get dual stack connectivity. 777 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are 778 three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN 779 Connection is needed to get dual stack connectivity. 781 6.3. PDN Connection Establishment Process 783 The PDN connection establishment process is specified in detail in 784 3GPP specifications. Figure 8 illustrates the high level process and 785 signaling involved in the establishment of a PDN connection. 787 UE eNb/ MME SGW PDN-GW HSS/ 788 | BS | | | AAA 789 | | | | | | 790 |---------->|(1) | | | | 791 | |---------->|(1) | | | 792 | | | | | | 793 |/---------------------------------------------------------\| 794 | Authentication and Authorization |(2) 795 |\---------------------------------------------------------/| 796 | | | | | | 797 | | |---------->|(3) | | 798 | | | |---------->|(3) | 799 | | | | | | 800 | | | |<----------|(4) | 801 | | |<----------|(4) | | 802 | |<----------|(5) | | | 803 |/---------\| | | | | 804 | RB setup |(6) | | | | 805 |\---------/| | | | | 806 | |---------->|(7) | | | 807 |---------->|(8) | | | | 808 | |---------->|(9) | | | 809 | | | | | | 810 |============= UL Data =============>==========>|(10) | 811 | | | | | | 812 | | |---------->|(11) | | 813 | | | | | | 814 | | |<----------|(12) | | 815 | | | | | | 816 |<============ DL Data =============<===========|(13) | 817 | | | | | | 819 Figure 8: Simplified PDN connection setup procedure in Release-8 821 1. The UE (i.e the MS) requires a data connection and hence decides 822 to establish a PDN connection with a PDN-GW. The UE sends an 823 "Attach Request" (layer-2) to the BS. The BS forwards this 824 attach request to the MME. 826 2. Authentication of the UE with the AAA server/HSS follows. If 827 the UE is authorized for establishing a data connection, the 828 following steps continue 830 3. The MME sends a "Create Session Request" message to the 831 Serving-GW. The SGW forwards the create session request to the 832 PDN-GW. The SGW knows the address of the PDN-GW to forward the 833 create session request to as a result of this information having 834 been obtained by the MME during the authentication/authorization 835 phase. 837 The UE IPv4 address and/or IPv6 prefix get assigned during this 838 step. If a subscribed IPv4 address and/or IPv6 prefix is 839 statically allocated for the UE for this APN, then the MME 840 already passes the address information to the SGW and eventually 841 to the PDN-GW in the "Create Session Request" message. 842 Otherwise, the PDN-GW manages the address assignment to the UE 843 (there is another variation to this where IPv4 address 844 allocation is delayed until the UE initiates a DHCPv4 exchange 845 but this is not discussed here). 847 4. The PDN-GW creates a PDN connection for the UE and sends "Create 848 Session Response" message to the SGW from which the session 849 request message was received from. The SGW forwards the 850 response to the corresponding MME which originated the request. 852 5. The MME sends the "Attach Accept/Initial Context Setup request" 853 message to the eNodeB/BS. 855 6. The radio bearer between the UE and the eNb is reconfigured 856 based on the parameters received from the MME 858 7. The eNb sends "Initial Context Response" message to the MME. 860 8. The UE sends a "Direct Transfer" message to the eNodeB which 861 includes the Attach complete signal. 863 9. The eNodeB forwards the Attach complete message to the MME. 865 10. The UE can now start sending uplink packets to the PDN GW. 867 11. The MME sends a "Modify Bearer Request" message to the SGW. 869 12. The SGW responds with a "Modify Bearer Response" message. At 870 this time the downlink connection is also ready 872 13. The UE can now start receiving downlink packets 874 The type of PDN connection established between the UE and the PDN-GW 875 can be any of the types described in the previous section. The DS 876 PDN connection, i.e the one which supports both IPv4 and IPv6 packets 877 is the default one that will be established if no specific PDN 878 connection type is specified by the UE in Release-8 networks. 880 6.4. Mobility of 3GPP IPv4v6 Type of Bearers 882 3GPP discussed at length various approaches to support mobility 883 between Release-8 and pre-Release-8 networks for the new dual-stack 884 type of bearers. 886 The chosen approach for mobility is as follows, in short: if a mobile 887 is known to be at risk for doing handovers between Release-8 and pre- 888 Release-8 networks, only single stack bearers are used. Essentially 889 meaning: 891 1. If a network knows a mobile may do handovers between Release-8 892 and pre-Release-8 networks (segment), network will only provide 893 single stack bearers, even if the mobile host requests dual-stack 894 bearers. This can happen e.g. if an operator is using pre- 895 Release-8 SGSNs in some parts of the network. The single stack 896 bearers of Release-8 are easy to map one-to-one to pre-Release-8 897 bearers. 899 2. If a network knows a mobile will not be able to do handover to 900 pre-Release-8 network (segment), it will provide mobile with 901 dual-stack bearers on request. This can happen e.g. if an 902 operator has upgraded their SGSNs to support dual-stack bearers, 903 or if an operator is running LTE-only network. 905 When a network operator and their roaming partners have upgraded 906 their networks to Release-8, it is possible to use the new IPv4v6 907 dual-stack type of bearers. A Release-8 mobile device always 908 requests for a dual-stack bearer, but accepts what is assigned by the 909 network. 911 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 913 3GPP networks can natively transport IPv4 and IPv6 packets between 914 the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of 915 establishing either a dual-stack PDP context or parallel IPv4 and 916 IPv6 PDP contexts. 918 Current deployments of 3GPP networks primarily support IPv4 only. 919 These networks can be upgraded to also support IPv6 PDP contexts. By 920 doing so devices and applications that are IPv6 capable can start 921 utilizing the IPv6 connectivity. This will also ensure that legacy 922 devices and applications continue to work with no impact. As newer 923 devices start using IPv6 connectivity, the demand for actively used 924 IPv4 connections is expected to slowly decrease, helping operators 925 with a transition to IPv6. With a dual-stack approach, there is 926 always the potential to fallback to IPv4. A device which may be 927 roaming in a network wherein IPv6 is not supported by the visited 928 network could fall back to using IPv4 PDP contexts and hence the end 929 user would at least get some connectivity. Unfortunately, dual-stack 930 approach as such does not lower the number of used IPv4 addresses. 931 Every dual-stack bearer still needs to given an IPv4 address, private 932 or public. This is a major concern with dual-stack bearers 933 concerning IPv6 transition. However, if the majority of active IP 934 communication has moved over to IPv6, then in case of NAT44 [RFC1918] 935 IPv4 connections the number of active IPv4 connections can still be 936 expected to gradually decrease and thus giving some level of relief 937 regarding NAT44 function scalability. 939 As the networks evolve to support Release-8 EPS architecture and the 940 dual-stack PDP contexts, newer devices will be able to leverage such 941 capability and have a single bearer which supports both IPv4 and 942 IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP 943 between the MS and the gateway (GGSN/PDN-GW) the transport network 944 capability in terms of whether it supports IPv4 or IPv6 on the 945 interfaces between the eNodeB and SGW or, SGW and PDN-GW is 946 immaterial. 948 8. Deployment issues 950 8.1. Overlapping IPv4 Addresses 952 Given the shortage of globally routable public IPv4 addresses, 953 operators tend to assign private IPv4 addresses [RFC1918] to hosts 954 when they establish an IPv4 only PDP context or an IPv4v6 type PDN 955 context. About 16 million hosts can be assigned a private IPv4 956 address that is unique within a domain. However, in case of many 957 operators the number of subscribers is greater than 16 million. The 958 issue can be dealt with by assigning overlapping RFC 1918 IPv4 959 addresses to hosts. As a result the IPv4 address assigned to a host 960 within the context of a single operator realm would no longer be 961 unique. This has the obvious and know issues of NATed IP connection 962 in the Internet. Direct host to host connectivity becomes 963 complicated, unless the hosts are within the same private address 964 range pool and/or anchored to the same gateway, referrals using IP 965 addresses will have issues and so forth. These are generic issues 966 and not only a concern of the EPS. However, 3GPP as such does not 967 have any mandatory language concerning NAT44 functionality in EPC. 968 Obvious deployment choices apply also to EPC: 970 1. Very large network deployments are partitioned, for example, 971 based on a geographical areas. This partitioning allows 972 overlapping IPv4 addresses ranges to be assigned to hosts that 973 are in different areas. Each area has its own pool of gateways 974 that are dedicated for a certain overlapping IPv4 address range 975 (referred here later as a zone). Standard NAT44 functionality 976 enables the communication between hosts that are assigned the 977 same IPv4 address but belong to different zones, yet are part of 978 the same operator domain. 980 2. A mobile host/device attaches to a gateway as part of the attach 981 process. The number of hosts that a gateway supports is in the 982 order of 1 to 10 million. Hence all the hosts assigned to a 983 single gateway can be assigned private IPv4 addresses. Operators 984 with large subscriber bases have multiple gateways and hence the 985 same [RFC1918] IPv4 address space can be reused across gateways. 986 The IPv4 address assigned to a host is unique within the scope of 987 a single gateway. 989 3. New services requiring direct connectivity between hosts should 990 be build on IPv6. Possible existing IPv4-only services and 991 applications requiring direct connectivity can be ported to IPv6. 993 8.2. IPv6 for transport 995 The various reference points of the 3GPP architecture such as S1-U, 996 S5 and S8 are based on either GTP or PMIPv6. The underlying 997 transport for these reference points can be IPv4 or IPv6. GTP has 998 been able to operate over IPv6 transport (optionally) since R99 and 999 PMIPv6 has supported IPv6 transport starting from its introduction in 1000 Release-8. The user plane traffic between the mobile host and the 1001 gateway can use either IPv4 or IPv6. These packets are essentially 1002 treated as payload by GTP/PMIPv6 and transported accordingly with no 1003 real attention paid to the information (at least from a routing 1004 perspective) contained in the IPv4 or IPv6 headers. The transport 1005 links between the eNodeB and the SGW, and the link between the SGW 1006 and PDN-GW can be migrated to IPv6 without any direct implications to 1007 the architecture. 1009 Currently, the inter-operator (for 3GPP technology) roaming networks 1010 are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). 1011 Eventually these roaming networks will also get migrated to IPv6, if 1012 there is a business reason for that. The migration period can be 1013 prolonged considerably because the 3GPP protocols always tunnel user 1014 plane traffic in the core network and as described earlier the 1015 transport network IP version is not in any way tied to user plane IP 1016 version. Furthermore, the design of the inter-operator roaming 1017 networks is such that the user plane and transport network IP 1018 addressing is completely separated from each other. The inter- 1019 operator roaming network itself is also completely separated from the 1020 Internet. Only those core network nodes that must be connected to 1021 the inter-operator roaming networks are actually visible there, and 1022 be able to send and receive (tunneled) traffic within the inter- 1023 operator roaming networks. Obviously, in order the roaming to work 1024 properly, the operators have to agree on supported protocol versions 1025 so that the visited network does not, for example, unnecessarily drop 1026 user plane IPv6 traffic. 1028 8.3. Operational Aspects of Running Dual-Stack Networks 1030 Operating dual-stack networks does imply cost and complexity to a 1031 certain extent. However these factors are mitigated by the assurance 1032 that legacy devices and services are unaffected and there is always a 1033 fallback to IPv4 in case of issues with the IPv6 deployment or 1034 network elements. The model also enables operators to develop 1035 operational experience and expertise in an incremental manner. 1037 Running dual-stack networks requires the management of multiple IP 1038 address spaces. Tracking of hosts needs to be expanded since it can 1039 be identified by either an IPv4 address or IPv6 prefix. Network 1040 elements will also need to be dual-stack capable in order to support 1041 the dual-stack deployment model. 1043 Deployment and migration cases described in Section 6.1 for providing 1044 dual-stack like capability may mean doubled resource usage in 1045 operator's network. This is a major concern against providing dual- 1046 stack like connectivity using techniques discussed in Section 6.1. 1047 Also handovers between networks with different capabilities in terms 1048 of networks being dual-stack like service capable or not, may turn 1049 out hard to comprehend for users and for application/services to cope 1050 with. These facts may add other than just technical concerns for 1051 operators when planning to roll out dual-stack service offerings. 1053 8.4. Operational Aspects of Running a Network with IPv6 Only Bearers 1055 It is possible to allocate IPv6 only type bearers to mobile hosts in 1056 3GPP networks. IPv6 only bearer type has been part of the 3GPP 1057 specification since the beginning. In 3GPP Release-8 (and later) it 1058 was defined that a dual-stack mobile host (or when the radio 1059 equipment has no knowledge of the host IP stack capabilities) must 1060 first attempt to establish a dual-stack bearer and then possibly fall 1061 back to single IP version bearer. A Release-8 (or later) mobile host 1062 with IPv6 only stack can directly attempt to establish an IPv6 only 1063 bearer. The IPv6 only behavior is up to a subscription provisioning 1064 or a PDN-GW configuration, and the fallback scenarios do not 1065 necessarily cause additional signaling. 1067 Although the bullets below introduce IPv6 to IPv4 address translation 1068 and specifically discuss NAT64 technology [RFC6144], the current 3GPP 1069 Release-8 architecture does not describe the use of address 1070 translation or NAT64. It is up to a specific deployment whether 1071 address translation is part of the network or not. Some operational 1072 aspects to consider for running a network with IPv6 only bearers: 1074 o The mobile hosts must have an IPv6 capable stack and a radio 1075 interface capable of establishing an IPv6 PDP context or PDN 1076 connection. 1078 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 1079 bearers. Furthermore, the SGSN/MME must allow the creation of PDP 1080 Type or PDN Type of IPv6. 1082 o Many of the common applications are IP version agnostic and hence 1083 would work using an IPv6 bearer. However, applications that are 1084 IPv4 specific would not work. 1086 o Inter-operator roaming is another aspect which causes issues, at 1087 least during the ramp up phase of the IPv6 deployment. If the 1088 visited network to which outbound roamers attach to does not 1089 support PDP/PDN Type IPv6, then there needs to be a fallback 1090 option. The fallback option in this specific case is mostly up to 1091 the mobile host to implement. Several cases are discussed in the 1092 following sections. 1094 o If and when a mobile host using IPv6 only bearer needs to access 1095 to IPv4 Internet/network, a translation of some type from IPv6 to 1096 IPv4 has to be deployed in the network. NAT64 (and DNS64) is one 1097 solution that can be used for this purpose and works for a certain 1098 set of protocols (read TCP and UDP, and when applications actually 1099 use DNS for resolving name to IP addresses). 1101 8.5. Restricting Outbound IPv6 Roaming 1103 Roaming was briefly touched upon in Sections 8.2 and 8.4. While 1104 there is interest in offering roaming service for IPv6 enabled mobile 1105 hosts and subscriptions, not all visited networks are prepared for 1106 IPv6 outbound roamers. There are basically two issues. First, the 1107 visited network (S4-)SGSN does not support the IPv6 PDP Context or 1108 IPv4v6 PDP Context types. These should mostly concern pre-Release-8 1109 networks but there is no definitive rule as the deployed feature sets 1110 vary depending on implementations and licenses. Second, the visited 1111 network might not be commercially ready for IPv6 outbound roamers, 1112 while everything might work technically at the user plane level. 1113 This would lead to "revenue leakage" especially from the visited 1114 operator point of view (note that the use of visited network GGSN/ 1115 PDN-GW does not really exist in real deployments today). Therefore, 1116 it might be in the interest of operators to prohibit roaming 1117 selectively within specific visited networks. 1119 Unfortunately, it is not mandatory to implement/deploy 3GPP standards 1120 based solution to selectively prohibit IPv6 roaming without also 1121 prohibiting other packet services (such as IPv4 roaming). However, 1122 there are few possibilities how this can be done in real deployments. 1123 The examples given below are either optional and/or vendor specific 1124 features to the 3GPP EPC: 1126 o Using Policy and Charging Control (PCC) [3GPP.23.203] 1127 functionality and its rules to fail, for example, the bearer 1128 authorization when a desired criteria is met. In this case that 1129 would be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. 1130 The rules can be provisioned either in the home network or locally 1131 in the visited network. 1133 o Some Home Location Register (HLR) and Home Subscriber Server (HSS) 1134 subscriber databases allow prohibiting roaming in a specific 1135 (visited) network for a specified PDN/PDP Type. 1137 The obvious problems are that these solutions are not mandatory, are 1138 not unified across networks, and therefore also lack well-specified 1139 fall back mechanism from the mobile host point of view. 1141 8.6. Inter-rat Handovers and IP Versions 1143 It is obvious that when operators start to incrementally deploy EPS 1144 (and E-UTRAN) along with the existing UTRAN/GERAN, handovers between 1145 different radio technologies (inter-rat handovers) become inevitable. 1146 In case of inter-rat handovers 3GPP supports the following IP 1147 addressing scenarios: 1149 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 1150 bearer. 1152 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 1153 bearer. 1155 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 1156 bearer. 1158 Other types of configurations are considered network planning 1159 mistakes. What the above rules essentially imply is that the network 1160 migration has to be planned and subscriptions provisioned based on 1161 the lowest common nominator, if inter-rat handovers are desired. For 1162 example, if some part of the UTRAN network cannot serve anything but 1163 IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 1164 bearers. Various combinations of subscriber provisioning regarding 1165 IP versions are discussed further in Section 8.7. 1167 8.7. Provisioning of IPv6 Subscribers and Various Combinations During 1168 Initial Network Attachment 1170 Subscribers' provisioned PDP/PDN Types have multiple configurations. 1171 The supported PDP/PDN Type is provisioned per each APN for every 1172 subscriber. The following PDN Types are possible in the HSS for a 1173 Release-8 subscription [3GPP.23.401]: 1175 o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in HLR). 1177 o IPv6 only PDN Type 1179 o IPv4 only PDN Type. 1181 o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not 1182 exist in HLR). 1184 A Release-8 dual-stack mobile host must always attempt to establish a 1185 PDP/PDN Type IPv4v6 bearer. The same also applies when the modem 1186 part of the mobile host does not have exact knowledge whether the 1187 host operating system IP stack is a dual-stack capable or not. A 1188 mobile host that is IPv6 only capable must attempt to establish a 1189 PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4 only 1190 capable must attempt to establish a PDN/PDP Type IPv4 bearer. 1192 In a case the PDP/PDN Type requested by a mobile host does not match 1193 what has been provisioned for the subscriber in the HSS (or HLR), the 1194 mobile host possibly falls back to a different PDP/PDN Type. The 1195 network (i.e. the MME or the SGSN) is able to inform the mobile host 1196 during the network attachment signaling why it did not get the 1197 requested PDP/PDN Type. These response/cause codes are documented in 1198 [3GPP.24.008][3GPP.24.301]: 1200 o ESM cause #50 "PDN type IPv4 only allowed". 1202 o ESM cause #51 "PDN type IPv6 only allowed". 1204 o ESM cause #52 "single address bearers only allowed". 1206 The above respone/cause codes apply to Release-8 and onwards. In 1207 pre-Release-8 networks used response/cause codes vary depending on 1208 the vendor, unfortunately. 1210 Possible fall back cases include (as documented in [3GPP.23.401]): 1212 o Requested & provisioned PDP/PDN Types match -> requested. 1214 o Requested IPv4v6 & provisioned IPv6 -> IPv6 and a mobile host 1215 receives indication that IPv6-only bearer is allowed. 1217 o Requested IPv4v6 & provisioned IPv4 -> IPv4 and the mobile host 1218 receives indication that IPv4-only bearer is allowed. 1220 o Requested IPv4v6 & provisioned IPv4_or_IPv6 -> IPv4 or IPv6 is 1221 selected by the MME based on an unspecified criteria. The mobile 1222 host may then attempt to establish, based on the mobile host 1223 implementation, a parallel bearer of a different PDP/PDN Type. 1225 o Other combinations cause the bearer establishment to fail. 1227 In addition to PDP/PDN Types provisioned in the HSS, it is also 1228 possible for a PDN-GW (and a MME) to affect the final selected PDP/ 1229 PDN Type: 1231 o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 1232 or IPv6. If the MME operator had included the "Dual Address 1233 Bearer Flag" into the bearer establishment signaling, then the 1234 mobile host receives an indication that IPv6-only or IPv4-only 1235 bearer is allowed. 1237 o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 1238 or IPv6. If the MME operator had not included the "Dual Address 1239 Bearer Flag" into the bearer establishment signaling, then the 1240 mobile host may attempt to establish, based on the mobile host 1241 implementation, a parallel bearer of different PDP/PDN Type. 1243 If for some reason a SGSN does not understand the requested PDP Type, 1244 then the PDP Type is handled as IPv4. If for some reason a MME does 1245 not understand the requested PDN Type, then the PDN Type is handled 1246 as IPv6. 1248 9. IANA Considerations 1250 This document has no requests to IANA. 1252 10. Security Considerations 1254 This document does not introduce any security related concerns. 1256 11. Summary and Conclusion 1258 The 3GPP network architecture and specifications enable the 1259 establishment of IPv4 and IPv6 connections through the use of 1260 appropriate PDP context types. The current generation of deployed 1261 networks can support dual-stack connectivity if the packet core 1262 network elements such as the SGSN and GGSN have the capability. With 1263 Release-8, 3GPP has specified a more optimal PDP context type which 1264 enables the transport of IPv4 and IPv6 packets within a single PDP 1265 context between the mobile station and the gateway. 1267 As devices and applications are upgraded to support IPv6 they can 1268 start leveraging the IPv6 connectivity provided by the networks while 1269 maintaining the fall back to IPv4 capability. Enabling IPv6 1270 connectivity in the 3GPP networks by itself will provide some degree 1271 of relief to the IPv4 address space as many of the applications and 1272 services can start to work over IPv6. However without comprehensive 1273 testing of different applications and solutions that exist today and 1274 are widely used, for their ability to operate over IPv6 PDN 1275 connections, an IPv6 only access would cause disruptions. 1277 12. Acknowledgements 1279 The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and 1280 Zhenqiang Li, Mikael Abrahamsson, James Woodyatt and Cameron Byrne 1281 for their reviews and comments on this document. 1283 13. Informative References 1285 [3GPP.23.060] 1286 3GPP, "General Packet Radio Service (GPRS); Service 1287 description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. 1289 [3GPP.23.203] 1290 3GPP, "Policy and charging control architecture (PCC)", 1291 3GPP TS 23.203 8.11.0, September 2010. 1293 [3GPP.23.401] 1294 3GPP, "General Packet Radio Service (GPRS) enhancements 1295 for Evolved Universal Terrestrial Radio Access Network 1296 (E-UTRAN) access", 3GPP TS 23.401 10.3.0, March 2011. 1298 [3GPP.23.975] 1299 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, 1300 June 2010. 1302 [3GPP.24.008] 1303 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 1304 TS 24.008 8.12.0, December 2010. 1306 [3GPP.24.301] 1307 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1308 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1310 [3GPP.29.060] 1311 3GPP, "General Packet Radio Service (GPRS); GPRS 1312 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1313 3GPP TS 29.274 8.8.0, April 2010. 1315 [3GPP.29.061] 1316 3GPP, "Interworking between the Public Land Mobile Network 1317 (PLMN) supporting packet based services and Packet Data 1318 Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. 1320 [3GPP.29.274] 1321 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1322 Packet Radio Service (GPRS) Tunnelling Protocol for 1323 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 1324 December 2010. 1326 [GSMA.IR.34] 1327 GSMA, "Inter-PLMN Backbone Guidelines", GSMA 1328 PRD IR.34.4.9, March 2010. 1330 [I-D.ietf-dhc-pd-exclude] 1331 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1332 "Prefix Exclude Option for DHCPv6-based Prefix 1333 Delegation", draft-ietf-dhc-pd-exclude-01 (work in 1334 progress), January 2011. 1336 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1337 E. Lear, "Address Allocation for Private Internets", 1338 BCP 5, RFC 1918, February 1996. 1340 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1341 RFC 2131, March 1997. 1343 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1344 and M. Carney, "Dynamic Host Configuration Protocol for 1345 IPv6 (DHCPv6)", RFC 3315, July 2003. 1347 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 1348 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 1349 Second and Third Generation Cellular Hosts", RFC 3316, 1350 April 2003. 1352 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1353 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1354 December 2003. 1356 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1357 (DHCP) Service for IPv6", RFC 3736, April 2004. 1359 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1360 Proxies (ND Proxy)", RFC 4389, April 2006. 1362 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1363 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1364 September 2007. 1366 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1367 Address Autoconfiguration", RFC 4862, September 2007. 1369 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1370 Extensions for Stateless Address Autoconfiguration in 1371 IPv6", RFC 4941, September 2007. 1373 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1374 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1376 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1377 IPv4/IPv6 Translation", RFC 6144, April 2011. 1379 Authors' Addresses 1381 Jouni Korhonen (editor) 1382 Nokia Siemens Networks 1383 Linnoitustie 6 1384 FI-02600 Espoo 1385 FINLAND 1387 Email: jouni.nospam@gmail.com 1389 Jonne Soininen 1390 Renesas Mobile 1391 Porkkalankatu 24 1392 FI-00180 Helsinki 1393 FINLAND 1395 Email: jonne.soininen@renesasmobile.com 1396 Basavaraj Patil 1397 Nokia 1398 6021 Connection drive 1399 Irving, TX 75039 1400 USA 1402 Email: basavaraj.patil@nokia.com 1404 Teemu Savolainen 1405 Nokia 1406 Hermiankatu 12 D 1407 FI-33720 Tampere 1408 FINLAND 1410 Email: teemu.savolainen@nokia.com 1412 Gabor Bajko 1413 Nokia 1414 323 Fairchild drive 6 1415 Mountain view, CA 94043 1416 USA 1418 Email: gabor.bajko@nokia.com 1420 Kaisu Iisakkila 1421 Renesas Mobile 1422 Porkkalankatu 24 1423 FI-00180 Helsinki 1424 FINLAND 1426 Email: kaisu.iisakkila@renesasmobile.com