idnits 2.17.1 draft-ietf-v6ops-3gpp-eps-03.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 (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GGSN' is mentioned on line 420, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-dhc-pd-exclude-02 -- 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: January 12, 2012 Renesas Mobile 6 B. Patil 7 T. Savolainen 8 G. Bajko 9 Nokia 10 K. Iisakkila 11 Renesas Mobile 12 July 11, 2011 14 IPv6 in 3GPP Evolved Packet System 15 draft-ietf-v6ops-3gpp-eps-03 17 Abstract 19 Use of data services in smart phones and broadband services via HSPA 20 and HSPA+, in particular Internet services, has increased rapidly and 21 operators that have deployed networks based on 3GPP network 22 architectures are facing IPv4 address shortages at the Internet 23 registries and are feeling a pressure to migrate to IPv6. This 24 document describes the support for IPv6 in 3GPP network 25 architectures. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 12, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 9 65 3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 10 66 3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 10 67 3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 13 70 4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 14 71 4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 14 72 5. Address Management . . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 15 74 5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 15 75 5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 16 76 5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 16 77 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 17 78 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 17 79 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 18 80 6.3. PDN Connection Establishment Process . . . . . . . . . . . 19 81 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 22 82 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 22 83 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 23 84 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 23 85 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 24 86 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 25 87 8.4. Operational Aspects of Running a Network with 88 IPv6-only Bearers . . . . . . . . . . . . . . . . . . . . 25 89 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 26 90 8.6. Inter-RAT Handovers and IP Versions . . . . . . . . . . . 27 91 8.7. Provisioning of IPv6 Subscribers and Various 92 Combinations During Initial Network Attachment . . . . . . 28 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 95 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 97 13. Informative References . . . . . . . . . . . . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 100 1. Introduction 102 IPv6 has been specified in the 3rd Generation Partnership Project 103 (3GPP) standards since the early architectures developed for R99 104 General Packet Radio Service (GPRS). However, the support for IPv6 105 in commercially deployed networks remains low. There are many 106 factors that can be attributed to the lack of IPv6 deployment in 3GPP 107 networks. The most relevant one is essentially the same as the 108 reason for IPv6 not being deployed by other networks as well, i.e. 109 the lack of business and commercial incentives for deployment. 3GPP 110 network architectures have also evolved since 1999 (since R99). The 111 most recent version of the 3GPP architecture, the Evolved Packet 112 System (EPS), which is commonly referred to as SAE, LTE or Release-8, 113 is a packet centric architecture. The number of subscribers and 114 devices that are using the 3GPP networks for Internet connectivity 115 and data services has also increased significantly. With the 116 subscriber growth numbers projected to increase even further and the 117 IPv4 addresses depletion problem looming in the near term, 3GPP 118 operators and vendors have started the process of identifying the 119 scenarios and solutions needed to transition to IPv6. 121 This document describes the establishment of IP connectivity in 3GPP 122 network architectures, specifically in the context of IP bearers for 123 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is 124 supported as per the current set of 3GPP specifications. Some of the 125 issues and concerns with respect to deployment and shortage of 126 private IPv4 addresses within a single network domain are also 127 discussed. 129 The IETF has specified a set of tools and mechanisms that can be 130 utilized for transitioning to IPv6. In addition to operating dual- 131 stack networks during the transition from IPv4 to IPv6 phase, the two 132 alternative categories for the transition are encapsulation and 133 translation. The IETF continues to specify additional solutions for 134 enabling the transition based on the deployment scenarios and 135 operator/ISP requirements. There is no single approach for 136 transition to IPv6 that can meet the needs for all deployments and 137 models. The 3GPP scenarios for transition, described in [TR.23975], 138 can be addressed using transition mechanisms that are already 139 available in the toolbox. The objective of transition to IPv6 in 140 3GPP networks is to ensure that: 142 1. Legacy devices and hosts which have an IPv4-only stack will 143 continue to be provided with IP connectivity to the Internet and 144 services, 146 2. Devices which are dual-stack can access the Internet either via 147 IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the 148 capability of: 150 A. the application on the host, 152 B. the support for IPv4 and IPv6 bearers by the network and/or, 154 C. the capability of the server(s) and other end points. 156 3GPP networks are capable of providing a host with IPv4 and IPv6 157 connectivity today, albeit in many cases with upgrades to network 158 elements such as the SGSN and GGSN. 160 2. 3GPP Terminology and Concepts 162 2.1. Terminology 164 Access Point Name 166 Access Point Name (APN) is a fully qualified domain name and 167 resolves to a specific gateway in an operators network. The APNs 168 are piggybacked on the administration of the DNS namespace. 170 Dual Address PDN/PDP Type 172 The Dual Address PDN/PDP Type (IPv4v6) is used in 3GPP context in 173 many cases as a synonym for dual-stack i.e. a connection type 174 capable of serving both IPv4 and IPv6 simultaneously. 176 Evolved Packet Core 178 Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system 179 characterized by higher-data-rate, lower-latency, packet-optimized 180 system. EPC comprises of subcomponents such as Mobility 181 Management Entity (MME), Serving Gateway (SGW), Packet Data 182 Network Gateway (PDN-GW) and Home Subscriber Server (HSS). 184 Evolved Packet System 186 Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 187 system characterized by higher-data-rate, lower-latency, packet- 188 optimized system that supports multiple Radio Access Technologies 189 (RAT). The EPS comprises the Evolved Packet Core (EPC) together 190 with the evolved radio access network (E-UTRA and E-UTRAN). 192 Evolved UTRAN 194 Evolved UTRAN (E-UTRAN) is communications network, sometimes 195 referred to as 4G, and consists of eNodeBs (4G base station) which 196 make up the E-UTRAN radio access network. The E-UTRAN allows 197 connectivity between the mobile host/device and the core network. 199 GPRS tunnelling protocol 201 GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] is a 202 tunnelling protocol defined by 3GPP. It is a network based 203 mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) 204 [RFC5213]. However, GTP also provides functionality beyond 205 mobility such as inband signaling related to Quality of Service 206 (QoS) and charging among others. 208 GSM EDGE Radio Access Network 210 GSM EDGE Radio Access Network (GERAN) is communications network, 211 commonly referred to as 2G or 2.5G, and consists of base stations 212 and Base Station Controllers (BSC) which make up the GSM EDGE 213 radio access network. The GERAN allows connectivity between the 214 mobile host/device and the core network. 216 Gateway GPRS Support Node 218 Gateway GPRS Support Node (GGSN) is a gateway function in GPRS, 219 which provides connectivity to Internet or other PDNs. The host 220 attaches to a GGSN identified by an APN assigned to it by an 221 operator. The GGSN also serves as the topological anchor for 222 addresses/prefixes assigned to the mobile host. 224 General Packet Radio Service 226 General Packet Radio Service (GPRS) is a packet oriented mobile 227 data service available to users of the 2G and 3G cellular 228 communication systems Global System for Mobile communications 229 (GSM), and specified by 3GPP. 231 High Speed Packet Access 233 The High Speed Packet Access (HSPA) and the Evolved High Speed 234 Packet Access (HSPA+) are enhanced versions of the WCDMA and 235 UTRAN, thus providing more data throughput and lower latencies. 237 Home Location Register 239 The Home Location Register (HLR) is a pre-Release-5 database (but 240 is also used in Release-5 and later networks in real deployments) 241 that contains subscriber data and call routing related 242 information. Every subscriber of an operator including 243 subscribers' enabled services are provisioned in the HLR. 245 Home Subscriber Server 247 The Home Subscriber Server (HSS) is a database for a given 248 subscriber and got introduced in 3GPP Release-5. It is the entity 249 containing the subscription-related information to support the 250 network entities actually handling calls/sessions. 252 Mobility Management Entity 254 Mobility Management Entity (MME) is a network element that is 255 responsible for control plane functionalities, including 256 authentication, authorization, bearer management, layer-2 257 mobility, etc. The MME is essentially the control plane part of 258 the SGSN in GPRS. The user plane traffic bypasses the MME. 260 Mobile Terminal 262 The Mobile Terminal (MT) is the modem and the radio part of the 263 Mobile Station (MS). 265 Public Land Mobile Network 267 The Public Land Mobile Network (PLMN) is a network that is 268 operated by a single administration. A PLMN (and therefore also 269 an operator) is identified by the Mobile Country Code (MCC) and 270 the Mobile Network Code (MNC). Each (telecommunications) operator 271 providing mobile services has its own PLMN. 273 Policy and Charging Control 275 The Policy and Charging Control (PCC) framework is used for QoS 276 policy and charging control. It has two main functions: flow 277 based charging including online credit control, and policy control 278 (e.g. gating control, QoS control and QoS signaling). It is 279 optional to 3GPP EPS but needed if dynamic policy and charging 280 control by means of PCC rules based on user and services are 281 desired. 283 Packet Data Network 285 Packet Data Network (PDN) is a packet based network that either 286 belongs to the operator or is an external network such as Internet 287 and corporate intranet. The user eventually accesses services in 288 one or more PDNs. The operator's packet core network are 289 separated from packet data networks either by GGSNs or PDN 290 Gateways (PDN-GW). 292 Packet Data Network Gateway 294 Packet Data Network Gateway (PDN-GW) is a gateway function in 295 Evolved Packet System (EPS), which provides connectivity to 296 Internet or other PDNs. The host attaches to a PDN-GW identified 297 by an APN assigned to it by an operator. The PDN-GW also serves 298 as the topological anchor for addresses/prefixes assigned to the 299 mobile host. 301 Packet Data Protocol Context 303 A Packet Data Protocol (PDP) Context is the equivalent of a 304 virtual connection between the host and a gateway. 306 S4 Serving Gateway Support Node 308 S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and 309 onwards) compliant SGSN that connects 2G/3G radio access network 310 to EPC via new Release-8 interfaces like S3, S4, and S6d. 312 Serving Gateway 314 Serving Gateway (SGW) is a gateway function in EPS, which 315 terminates the interface towards E-UTRAN. The SGW is the Mobility 316 Anchor point for layer-2 mobility (inter-eNodeB handovers). For 317 each User Equipment connected with the EPS, at any given point of 318 time, there is only one SGW. The SGW is essentially the user 319 plane part of the GPRS' SGSN forwarding packets between a PDN-GW. 321 Serving Gateway Support Node 323 Serving Gateway Support Node (SGSN) is a network element that is 324 located between the radio access network (RAN) and the gateway 325 (GGSN). A per mobile host point to point (p2p) tunnel between the 326 GGSN and SGSN transports the packets between the mobile host and 327 the gateway. 329 Terminal Equipment 331 The Terminal Equipment (TE) is any device/host connected to the 332 Mobile Terminal (MT) offering services to the use. A TE may 333 communicate to a MT, for example, over Point to Point Protocol 334 (PPP). 336 UE, MS, MN and Mobile 338 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 339 Node) and, mobile refer to the devices which are hosts with 340 ability to obtain Internet connectivity via a 3GPP network. A MS 341 comprises of a Terminal Equipment (TE) and a Mobile Terminal (MT). 342 The terms UE, MS, MN and devices are used interchangeably within 343 this document. 345 UMTS Terrestrial Radio Access Network 347 UMTS Terrestrial Radio Access Network (UTRAN) is communications 348 network, commonly referred to as 3G, and consists of NodeBs (3G 349 base station) and Radio Network Controllers (RNC) which make up 350 the UMTS radio access network. The UTRAN allows connectivity 351 between the mobile host/device and the core network. UTRAN 352 comprises of WCDMA, HSPA and HSPA+ radio technologies. 354 Wideband Code Division Multiple Access 356 The Wideband Code Division Multiple Access (WCDMA) is the radio 357 interface used in UMTS networks. 359 eNodeB 361 The eNodeB is a base station entity that supports the Long Term 362 Evolution (LTE) air interface. 364 2.2. The concept of APN 366 The Access Point Name (APN) essentially refers to a gateway in the 367 3GPP network. The 'complete' APN is expressed in a form of a Fully 368 Qualified Domain Name (FQDN) and also piggybacked on the 369 administration of the DNS namespace, thus effectively allowing the 370 discovery of gateways using the DNS. Mobile hosts/devices can choose 371 to attach to a specific gateway in the packet core. The gateway 372 provides connectivity to the Packet Data Network (PDN) such as the 373 Internet. An operator may also include gateways which do not provide 374 Internet connectivity, rather a connectivity to closed network 375 providing a set of operator's own services. A mobile host/device can 376 be attached to one or more gateways simultaneously. The gateway in a 377 3GPP network is the GGSN or PDN-GW. Figure 1 below illustrates the 378 APN-based network connectivity concept. 380 .--. 381 _(. `) 382 .--. +------------+ _( PDN `)_ 383 _(Core`. |GW1 |====( Internet `) 384 +---+ ( NW )------|APN=internet| ( ` . ) ) 385 [MN]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' 386 ^ +---+ `--(___.-' | 387 | | .--. 388 | | +----------+ _(.PDN`) 389 | +--|GW2 | _(Operator`)_ 390 | |APN=OpServ|====( Services `) 391 MN is attached +----------+ ( ` . ) ) 392 to GW1 and GW2 `--(_______)---' 393 simultaneously 395 Figure 1: Mobile host/device attached to multiple APNs simultaneously 397 3. IP over 3GPP GPRS 399 3.1. Introduction to 3GPP GPRS 401 A simplified 2G/3G GPRS architecture is illustrated in Figure 2. 402 This architecture basically covers the GPRS core network since R99 to 403 Release-7, and radio access technologies such as GSM (2G), EDGE (2G, 404 often referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred 405 as 3.5G). The architecture shares obvious similarities with the 406 Evolved Packet System (EPS) as will be seen in Section 4. Based on 407 Gn/Gp interfaces, the GPRS core network functionality is logically 408 implemented on two network nodes, the SGSN and the GGSN. 410 3G .--. 411 Uu +-----+ Iu +----+ +----+ _( `. 412 [TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) 413 +-----+ +----+ Gn +----+ Gi ( ` . ) ) 414 / | `--(___.-' 415 2G Gb-- | 416 +---+ / --Gp 417 [TE]+[MT]~~|~~~|BSS|___/ | 418 Um +---+ .--. 419 _(. `) 420 _( [GGSN] `)_ 421 ( other `) 422 ( ` . PLMN ) ) 423 `--(_______)---' 425 Figure 2: Overview of the 2G/3G GPRS Logical Architecture 427 Gn/Gp: These interfaces provide a network based mobility service for 428 a mobile host and are used between a SGSN and a GGSN. The Gn 429 interface is used when GGSN and SGSN are located inside one 430 operator (i.e. PLMN). The Gp-interface is used if the GGSN 431 and the SGSN are located in different operator domains (i.e. 432 'other' PLMN). GTP protocol is defined for the Gn/Gp 433 interfaces (both GTP-C for the control plane and GTP-U for 434 the user plane). 436 Gb: Is the Base Station System (BSS) to SGSN interface, which is 437 used to carry information concerning packet data transmission 438 and layer-2 mobility management. The Gb-interface is based 439 on either on Frame Relay or IP. 441 Iu: Is the Radio Network System (RNS) to SGSN interface, which is 442 used to carry information concerning packet data transmission 443 and layer-2 mobility management. The user plane part of the 444 Iu-interface (actually the Iu-PS) is based on GTP-U. The 445 control plane part of the Iu-interface is based on Radio 446 Access Network Application Protocol (RANAP). 448 Gi: It is the interface between the GGSN and a PDN. The PDN may 449 be an operator external public or private packet data network 450 or an intra-operator packet data network. 452 Uu/Um: Are either 2G or 3G radio interfaces between a mobile 453 terminal and a respective radio access network. 455 The SGSN is responsible for the delivery of data packets from and to 456 the mobile hosts within its geographical service area when a direct 457 tunnel option is not used. If the direct tunnel is used, then the 458 user plane goes directly between the RNS and the GGSN. The control 459 plane traffic always goes through the SGSN. For each mobile host 460 connected with the GPRS, at any given point of time, there is only 461 one SGSN. 463 3.2. PDP Context 465 A PDP context is an association between a mobile host represented by 466 one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by 467 an APN. Each PDN can be accessed via a gateway (typically a GGSN or 468 PDN-GW). On the device/mobile host a PDP context is equivalent to a 469 network interface. A host may hence be attached to one or more 470 gateways via separate connections, i.e. PDP contexts. Each primary 471 PDP context has its own IPv4 address and/or one /64 IPv6 prefix 472 assigned to it by the PDN and anchored in the corresponding gateway. 473 Applications on the host use the appropriate network interface (PDP 474 context) for connectivity to a specific PDN. Figure 3 represents a 475 high level view of what a PDP context implies in 3GPP networks. 477 Y 478 | +---------+ .--. 479 |--+ __________________________ | APNx in | _( `. 480 | |O______PDPc1_______________)| GGSN / |----(Internet) 481 |MS| | PDN-GW | ( ` . ) ) 482 |/ | +---------+ `--(___.-' 483 |UE| _______________________ +---------+ .--. 484 | |O______PDPc2____________)| APNy in | _(Priv`. 485 +--+ | GGSN / |-------(Network ) 486 | PDN-GW | ( ` . ) ) 487 +---------+ `--(___.-' 489 Figure 3: PDP contexts between the MS/UE and gateway 491 In the above figure there are two PDP contexts at the MS/UE (UE=User 492 Equipment in 3GPP parlance). The 'PDPc1' PDP context that is 493 connected to APNx provided Internet connectivity and the 'PDPc2' PDP 494 context provides connectivity to a private IP network via APNy (as an 495 example this network may include operator specific services such as 496 MMS (Multi media service). An application on the host such as a web 497 browser would use the PDP context that provides Internet connectivity 498 for accessing services on the Internet. An application such as MMS 499 would use APNy in the figure above because the service is provided 500 through the private network. 502 4. IP over 3GPP EPS 503 4.1. Introduction to 3GPP EPS 505 In its most basic form, the EPS architecture consists of only two 506 nodes on the user plane, a base station and a core network Gateway 507 (GW). The basic EPS architecture is illustrated in Figure 4. The 508 Mobility Management Entity (MME) node performs control-plane 509 functionality and is separated from the node(s) that performs bearer- 510 plane functionality (GW), with a well-defined open interface between 511 them (S11). The optional interface S5 can be used to split the 512 Gateway (GW) into two separate nodes, the Serving Gateway (SGW) and 513 the PDN-GW. This allows independent scaling and growth of traffic 514 throughput and control signal processing. The functional split of 515 gateways also allows for operators to choose optimized topological 516 locations of nodes within the network and enables various deployment 517 models including the sharing of radio networks between different 518 operators. 520 +--------+ 521 S1-MME +-------+ S11 | IP | 522 +----|----| MME |---|----+ |Services| 523 | | | | +--------+ 524 | +-------+ | |SGi 525 +----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+ 526 |MN |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | 527 | |========|=======|====================|=======|======| | 528 +----+ +-------+DualStack EPS Bearer+-------+ +-------+ 530 Figure 4: EPS Architecture for 3GPP Access 532 S5: It provides user plane tunnelling and tunnel management 533 between SGW and PDN-GW, using GTP or PMIPv6 as the network 534 based mobility management protocol. 536 S1-U: Provides user plane tunnelling and inter eNodeB path 537 switching during handover between eNodeB and SGW, using the 538 GTP-U protocol (GTP user plane). 540 S1-MME: Reference point for the control plane protocol between 541 eNodeB and MME. 543 SGi: It is the interface between the PDN-GW and the packet data 544 network. Packet data network may be an operator external 545 public or private packet data network or an intra operator 546 packet data network. 548 The eNodeB is a base station entity that supports the Long Term 549 Evolution (LTE) air interface and includes functions for radio 550 resource control, user plane ciphering, and other lower layer 551 functions. MME is responsible for control plane functionalities, 552 including authentication, authorization, bearer management, layer-2 553 mobility, etc. 555 The SGW is the Mobility Anchor point for layer-2 mobility. For each 556 MN connected with the EPS, at any given point of time, there is only 557 one SGW. 559 4.2. PDN Connection 561 A PDN connection is an association between a mobile host represented 562 by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented 563 by an APN. The PDN connection is the EPC equivalent of the GPRS PDP 564 context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is 565 responsible for the IP address/prefix allocation to the mobile host. 566 On the device/mobile host a PDN connection is equivalent to a network 567 interface. A host may hence be attached to one or more gateways via 568 separate connections, i.e. PDN connections. Each PDN connection has 569 its own IP address/prefix assigned to it by the PDN and anchored in 570 the corresponding gateway. Applications on the host use the 571 appropriate network interface (PDN connection) for connectivity. 573 4.3. EPS bearer model 575 The logical concept of a bearer has been defined to be an aggregate 576 of one or more IP flows related to one or more services. An EPS 577 bearer exists between the Mobile Node (MN i.e. a mobile host) and the 578 PDN-GW and is used to provide the same level of packet forwarding 579 treatment to the aggregated IP flows constituting the bearer. 580 Services with IP flows requiring a different packet forwarding 581 treatment would therefore require more than one EPS bearer. The 582 mobile host performs the binding of the uplink IP flows to the bearer 583 while the PDN-GW performs this function for the downlink packets. 585 In order to provide low latency for always on connectivity, a default 586 bearer will be provided at the time of startup and an IPv4 address 587 and/or IPv6 prefix gets assigned to the mobile host (this is 588 different from GPRS, where mobile hosts are not automatically 589 assigned with an IP address or prefix). This default bearer will be 590 allowed to carry all traffic which is not associated with a dedicated 591 bearer. Dedicated bearers are used to carry traffic for IP flows 592 that have been identified to require a specific packet forwarding 593 treatment. They may be established at the time of startup; for 594 example, in the case of services that require always-on connectivity 595 and better QoS than that provided by the default bearer. The default 596 bearer and the dedicated bearer(s) associated to it share the same IP 597 address(es)/prefix. 599 An EPS bearer is referred to as a GBR bearer if dedicated network 600 resources related to a Guaranteed Bit Rate (GBR) value that is 601 associated with the EPS bearer are permanently allocated (e.g. by an 602 admission control function in the eNodeB) at bearer establishment/ 603 modification. Otherwise, an EPS bearer is referred to as a non-GBR 604 bearer. The default bearer is always non-GBR, with the resources for 605 the IP flows not guaranteed at eNodeB, and with no admission control. 606 However, the dedicated bearer can be either GBR or non-GBR. A GBR 607 bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) 608 while more than one non-GBR bearer belonging to the same UE shares an 609 Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet 610 loss under congestion while GBR bearers are immune to such losses. 612 5. Address Management 614 5.1. IPv4 Address Configuration 616 Mobile host's IPv4 address configuration is always performed during 617 PDP context/EPS bearer setup procedures (on layer-2). DHCPv4-based 618 [RFC2131] address configuration is supported by the 3GPP 619 specifications, but is not used in wide scale. The mobile host must 620 always support layer-2 based address configuration, since DHCPv4 is 621 optional for both mobile hosts and networks. 623 5.2. IPv6 Address Configuration 625 IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in 626 [RFC4862] is the only supported address configuration mechanism. 627 Stateful DHCPv6-based address configuration is not supported by 3GPP 628 specifications [RFC3315]. On the other hand, Stateless DHCPv6- 629 service to obtain other configuration information is supported 630 [RFC3736]. This implies that the M-bit must always be set to zero 631 and the O-bit may be set to one in the Router Advertisement (RA) sent 632 to the UE. 634 3GPP network allocates each default bearer a unique /64 prefix, and 635 uses layer-2 signaling to suggest user equipment an Interface 636 Identifier that is guaranteed not to conflict with gateway's 637 Interface Identifier. The UE must configure its link-local address 638 using this Interface Identifier. The UE is allowed to use any 639 Interface Identifier it wishes for the other addresses it configures. 640 There is no restriction, for example, of using Privacy Extension for 641 SLAAC [RFC4941] or other similar types of mechanisms. 643 In the 3GPP link model the /64 prefix assigned to the UE cannot be 644 used for on-link determination (because the L-bit in the Prefix 645 Information Option (PIO) in the RA must always be set to zero). If 646 the advertised prefix is used for SLAAC then the A-bit in the PIO 647 must be set to one. The details of the 3GPP link-model and address 648 configuration is described in Section 11.2.1.3.2a of [TS.29061]. 649 More specifically, the GGSN/PDN-GW guarantees that the /64 prefix is 650 unique for the mobile host. Therefore, there is no need to perform 651 any Duplicate Address Detection (DAD) on addresses the mobile host 652 creates (i.e., the 'DupAddrDetectTransmits' variable in the mobile 653 host could be zero). The GGSN/PDN-GW is not allowed to generate any 654 globally unique IPv6 addresses for itself using the /64 prefix 655 assigned to the mobile host in the RA. 657 The current 3GPP architecture limits number of prefixes in each 658 bearer to a single /64 prefix. If the mobile host finds more than 659 one prefix in the RA, it only considers the first one and silently 660 discards the others [TS.29061]. Therefore, multi-homing within a 661 single bearer is not possible. Renumbering without closing layer-2 662 connection is also not possible. The lifetime of /64 prefix is bound 663 to lifetime of layer-2 connection even if the advertised prefix 664 lifetime is longer than the layer-2 connection lifetime. 666 5.3. Prefix Delegation 668 IPv6 prefix delegation is a part of Release-10 and is not covered by 669 any earlier release. However, the /64 prefix allocated for each 670 default bearer (and to the user equipment) may be shared to local 671 area network by user equipment implementing Neighbor Discovery proxy 672 (ND proxy) [RFC4389] functionality. 674 Release-10 prefix delegation uses the DHCPv6-based prefix delegation 675 [RFC3633]. The model defined for Release-10 requires aggregatable 676 prefixes, which means the /64 prefix allocated for the default bearer 677 (and to the user equipment) must be part of the shorter delegated 678 prefix. DHCPv6 prefix delegation has an explicit limitation 679 described in Section 12.1 of [RFC3633] that a prefix delegated to a 680 requesting router cannot be used by the delegating router (i.e., the 681 PDN-GW in this case). This implies the shorter 'delegated prefix' 682 cannot be given to the requesting router (i.e. the user equipment) as 683 such but has to be delivered by the delegating router (i.e. the 684 PDN-GW) in such a way the /64 prefix allocated to the default bearer 685 is not part of the 'delegated prefix'. IETF is working on a solution 686 for DHCPv6-based prefix delegation to exclude a specific prefix from 687 the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. 689 5.4. IPv6 Neighbor Discovery Considerations 691 3GPP link between the UE and the next hop router (e.g. GGSN) 692 resemble a point to point (p2p) link, which has no link-layer 693 addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. 695 The UE IP stack has to take this into consideration. When the 3GPP 696 PDP Context appears as a PPP interface/link to the UE, the IP stack 697 is usually prepared to handle Neighbor Discovery protocol and the 698 related Neighbor Cache state machine transitions in an appropriate 699 way, even though Neighbor Discovery protocol messages contain no link 700 layer address information. However, some operating systems discard 701 Router Advertisements on their PPP interface/link as a default 702 setting. This causes the SLAAC to fail when the 3GPP PDP Context 703 gets established, thus stalling all IPv6 traffic. 705 Currently several operating systems and their network drivers can 706 make the 3GPP PDP Context to appear as an IEEE802 interface/link to 707 the IP stack. This has few known issues, especially when the IP 708 stack is made to believe the underlying link has link-layer 709 addresses. First, the Neighbor Advertisement sent by a GGSN as a 710 response to an address resolution triggered Neighbor Solicitation may 711 not contain a Target Link-Layer address option (as suggested in 712 [RFC4861] Section 4.4). Then it is possible that the address 713 resolution never completes when the UE tries to resolve the link- 714 layer address of the GGSN, thus stalling all IPv6 traffic. 716 Second, the GGSN may simply discard all address resolution triggered 717 Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1 718 that address resolution and next-hop determination are not needed). 719 As a result the address resolution never completes when the UE tries 720 to resolve the link-layer address of the GGSN, thus stalling all IPv6 721 traffic. 723 6. 3GPP Dual-Stack Approach to IPv6 725 6.1. 3GPP Networks Prior to Release-8 727 3GPP standards prior to Release-8 provide IPv6 access for cellular 728 devices with PDP contexts of type IPv6 [TS.23060]. For dual-stack 729 access, a PDP context of type IPv6 is established in parallel to the 730 PDP context of type IPv4, as shown in Figure 5 and Figure 6. For 731 IPv4-only service, connections are created over the PDP context of 732 type IPv4 and for IPv6-only service connections are created over the 733 PDP context of type IPv6. The two PDP contexts of different type may 734 use the same APN (and the gateway), however, this aspect is not 735 explicitly defined in standards. Therefore, cellular device and 736 gateway implementations from different vendors may have varying 737 support for this functionality. 739 Y .--. 740 | _(IPv4`. 741 |---+ +---+ +---+ ( PDN ) 742 | D |~~~~~~~//-----| |====| |====( ` . ) ) 743 | S | IPv4 context | S | | G | `--(___.-' 744 | | | G | | G | .--. 745 | M | | S | | S | _(IPv6`. 746 | N | IPv6 context | N | | N | ( PDN ) 747 |///|~~~~~~~//-----| |====|(s)|====( ` . ) ) 748 +---+ +---+ +---+ `--(___.-' 750 Figure 5: A dual-stack mobile host connecting to both IPv4 and IPv6 751 Internet using parallel IPv4-only and IPv6-only PDP contexts 753 Y 754 | 755 |---+ +---+ +---+ 756 | D |~~~~~~~//-----| |====| | .--. 757 | S | IPv4 context | S | | G | _( DS `. 758 | | | G | | G | ( PDN ) 759 | M | | S | | S |====( ` . ) ) 760 | N | IPv6 context | N | | N | `--(___.-' 761 |///|~~~~~~~//-----| |====| | 762 +---+ +---+ +---+ 764 Figure 6: A dual-stack mobile host connecting to dual-stack Internet 765 using parallel IPv4-only and IPv6-only PDP contexts 767 The approach of having parallel IPv4 and IPv6 type of PDP contexts 768 open is not optimal, because two PDP contexts require double the 769 signaling and consume more network resources than a single PDP 770 context. In the figure above the IPv4 and IPv6 PDP contexts are 771 attached to the same GGSN. While this is possible, the dual-stack 772 (DS) MS may be attached to different GGSNs in the scenario where one 773 GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 774 PDN connectivity. 776 6.2. 3GPP Release-8 and -9 Networks 778 Since 3GPP Release-8, the powerful concept of a dual-stack type of 779 PDN connection and EPS bearer have been introduced [TS.23401]. This 780 enables parallel use of both IPv4 and IPv6 on a single bearer 781 (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler 782 than in earlier 3GPP releases. As of Release-9, GPRS network nodes 783 also support dual-stack type (IPv4v6) PDP contexts. 785 Y 786 | 787 |---+ +---+ +---+ 788 | D | | | | P | .--. 789 | S | | | | D | _( DS `. 790 | | IPv4v6 (DS) | S | | N | ( PDN ) 791 | M |~~~~~~~//-----| G |====| - |====( ` . ) ) 792 | N | bearer | W | | G | `--(___.-' 793 |///| | | | W | 794 +---+ +---+ +---+ 796 Figure 7: A dual-stack mobile host connecting to dual-stack Internet 797 using a single IPv4v6 type PDN connection 799 The following is a description of the various PDP contexts/PDN bearer 800 types that are specified by 3GPP: 802 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 803 two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to 804 get dual stack connectivity. 806 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 807 are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP 808 context is needed to get dual stack connectivity. 810 3. For 2G/3G access to EPC core (PDN-GW via S4-SGSN) from Release-8 811 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets 812 mapped to PDN Connection type. Minimum one PDP Context is needed 813 to get dual stack connectivity. 815 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are 816 three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN 817 Connection is needed to get dual stack connectivity. 819 6.3. PDN Connection Establishment Process 821 The PDN connection establishment process is specified in detail in 822 3GPP specifications. Figure 8 illustrates the high level process and 823 signaling involved in the establishment of a PDN connection. 825 UE eNb/ MME SGW PDN-GW HSS/ 826 | BS | | | AAA 827 | | | | | | 828 |---------->|(1) | | | | 829 | |---------->|(1) | | | 830 | | | | | | 831 |/---------------------------------------------------------\| 832 | Authentication and Authorization |(2) 833 |\---------------------------------------------------------/| 834 | | | | | | 835 | | |---------->|(3) | | 836 | | | |---------->|(3) | 837 | | | | | | 838 | | | |<----------|(4) | 839 | | |<----------|(4) | | 840 | |<----------|(5) | | | 841 |/---------\| | | | | 842 | RB setup |(6) | | | | 843 |\---------/| | | | | 844 | |---------->|(7) | | | 845 |---------->|(8) | | | | 846 | |---------->|(9) | | | 847 | | | | | | 848 |============= Uplink Data =========>==========>|(10) | 849 | | | | | | 850 | | |---------->|(11) | | 851 | | | | | | 852 | | |<----------|(12) | | 853 | | | | | | 854 |<============ Downlink Data =======<===========|(13) | 855 | | | | | | 857 Figure 8: Simplified PDN connection setup procedure in Release-8 859 1. The UE (i.e the MS) requires a data connection and hence decides 860 to establish a PDN connection with a PDN-GW. The UE sends an 861 "Attach Request" (layer-2) to the BS. The BS forwards this 862 attach request to the MME. 864 2. Authentication of the UE with the AAA server/HSS follows. If 865 the UE is authorized for establishing a data connection, the 866 following steps continue 868 3. The MME sends a "Create Session Request" message to the 869 Serving-GW. The SGW forwards the create session request to the 870 PDN-GW. The SGW knows the address of the PDN-GW to forward the 871 create session request to as a result of this information having 872 been obtained by the MME during the authentication/authorization 873 phase. 875 The UE IPv4 address and/or IPv6 prefix get assigned during this 876 step. If a subscribed IPv4 address and/or IPv6 prefix is 877 statically allocated for the UE for this APN, then the MME 878 already passes the address information to the SGW and eventually 879 to the PDN-GW in the "Create Session Request" message. 880 Otherwise, the PDN-GW manages the address assignment to the UE 881 (there is another variation to this where IPv4 address 882 allocation is delayed until the UE initiates a DHCPv4 exchange 883 but this is not discussed here). 885 4. The PDN-GW creates a PDN connection for the UE and sends "Create 886 Session Response" message to the SGW from which the session 887 request message was received from. The SGW forwards the 888 response to the corresponding MME which originated the request. 890 5. The MME sends the "Attach Accept/Initial Context Setup request" 891 message to the eNodeB/BS. 893 6. The radio bearer between the UE and the eNb is reconfigured 894 based on the parameters received from the MME. (See note 1 895 below) 897 7. The eNb sends "Initial Context Response" message to the MME. 899 8. The UE sends a "Direct Transfer" message to the eNodeB which 900 includes the Attach complete signal. 902 9. The eNodeB forwards the Attach complete message to the MME. 904 10. The UE can now start sending uplink packets to the PDN GW. 906 11. The MME sends a "Modify Bearer Request" message to the SGW. 908 12. The SGW responds with a "Modify Bearer Response" message. At 909 this time the downlink connection is also ready. 911 13. The UE can now start receiving downlink packets, including 912 possible SLAAC related IPv6 packets. 914 The type of PDN connection established between the UE and the PDN-GW 915 can be any of the types described in the previous section. The dual- 916 stack (DS) PDN connection, i.e the one which supports both IPv4 and 917 IPv6 packets is the default one that will be established if no 918 specific PDN connection type is specified by the UE in Release-8 919 networks. 921 Note 1: The UE receives the PDN Address Information Element 922 [TS.24301] at the end of radio bearer setup messaging. This 923 Information Element contains only the Interface Identifier of the 924 IPv6 address. In a case of GPRS the PDP Address Information 925 Element [TS.24008] would contain a complete IPv6 address. 926 However, the UE must ignore the IPv6 prefix if it receives one in 927 the message (see Section 11.2.1.3.2a of [TS.29061]). 929 6.4. Mobility of 3GPP IPv4v6 Type of Bearers 931 3GPP discussed at length various approaches to support mobility 932 between a Release-8 LTE network and a pre-Release-9 2G/3G network 933 without a S4-SGSN for the new dual-stack type of bearers. The chosen 934 approach for mobility is as follows, in short: if a mobile is allowed 935 for doing handovers between a Release-8 LTE network and a pre- 936 Release-9 2G/3G network without a S4-SGSN while having open PDN 937 connections, only single stack bearers are used. Essentially this 938 means following deployment options: 940 1. If a network knows a mobile may do handovers between a Release-8 941 LTE network and a pre-Release-9 2G/3G network without a S4-SGSN, 942 then the network is configured to provide only single stack 943 bearers, even if the mobile host requests dual-stack bearers. 945 2. If the network knows the mobile does handovers only between a 946 Release-8 LTE network and a Release-9 2G/3G network or a pre- 947 Release-9 network with a S4-SGSN, then the network is configured 948 to provide the mobile with dual-stack bearers on request. The 949 same also applies for LTE-only deployments. 951 When a network operator and their roaming partners have upgraded 952 their networks to Release-8, it is possible to use the new IPv4v6 953 dual-stack type of bearers. A Release-8 mobile device always 954 requests for a dual-stack bearer, but accepts what is assigned by the 955 network. 957 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 959 3GPP networks can natively transport IPv4 and IPv6 packets between 960 the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of 961 establishing either a dual-stack PDP context or parallel IPv4 and 962 IPv6 PDP contexts. 964 Current deployments of 3GPP networks primarily support IPv4-only. 965 These networks can be upgraded to also support IPv6 PDP contexts. By 966 doing so devices and applications that are IPv6 capable can start 967 utilizing the IPv6 connectivity. This will also ensure that legacy 968 devices and applications continue to work with no impact. As newer 969 devices start using IPv6 connectivity, the demand for actively used 970 IPv4 connections is expected to slowly decrease, helping operators 971 with a transition to IPv6. With a dual-stack approach, there is 972 always the potential to fallback to IPv4. A device which may be 973 roaming in a network wherein IPv6 is not supported by the visited 974 network could fall back to using IPv4 PDP contexts and hence the end 975 user would at least get some connectivity. Unfortunately, dual-stack 976 approach as such does not lower the number of used IPv4 addresses. 977 Every dual-stack bearer still needs to be given an IPv4 address, 978 private or public. This is a major concern with dual-stack bearers 979 concerning IPv6 transition. However, if the majority of active IP 980 communication has moved over to IPv6, then in case of NAT44 [RFC1918] 981 IPv4 connections the number of active IPv4 connections can still be 982 expected to gradually decrease and thus giving some level of relief 983 regarding NAT44 function scalability. 985 As the networks evolve to support Release-8 EPS architecture and the 986 dual-stack PDP contexts, newer devices will be able to leverage such 987 capability and have a single bearer which supports both IPv4 and 988 IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP 989 between the MS and the gateway (GGSN/PDN-GW) the transport network 990 capability in terms of whether it supports IPv4 or IPv6 on the 991 interfaces between the eNodeB and SGW or, SGW and PDN-GW is 992 immaterial. 994 8. Deployment issues 996 8.1. Overlapping IPv4 Addresses 998 Given the shortage of globally routable public IPv4 addresses, 999 operators tend to assign private IPv4 addresses [RFC1918] to hosts 1000 when they establish an IPv4-only PDP context or an IPv4v6 type PDN 1001 context. About 16 million hosts can be assigned a private IPv4 1002 address that is unique within a domain. However, in case of many 1003 operators the number of subscribers is greater than 16 million. The 1004 issue can be dealt with by assigning overlapping RFC 1918 IPv4 1005 addresses to hosts. As a result the IPv4 address assigned to a host 1006 within the context of a single operator realm would no longer be 1007 unique. This has the obvious and known issues of NATed IP connection 1008 in the Internet. Direct host to host connectivity becomes 1009 complicated, unless the hosts are within the same private address 1010 range pool and/or anchored to the same gateway, referrals using IP 1011 addresses will have issues and so forth. These are generic issues 1012 and not only a concern of the EPS. However, 3GPP as such does not 1013 have any mandatory language concerning NAT44 functionality in EPC. 1014 Obvious deployment choices apply also to EPC: 1016 1. Very large network deployments are partitioned, for example, 1017 based on a geographical areas. This partitioning allows for 1018 overlapping IPv4 addresses ranges to be assigned to hosts that 1019 are in different areas. Each area has its own pool of gateways 1020 that are dedicated for a certain overlapping IPv4 address range 1021 (referred here later as a zone). Standard NAT44 functionality 1022 allows for communication from the [RFC1918] private zone to the 1023 Internet. Communication between zones require special 1024 arrangement, such as using intermediate gateways (e.g. Back to 1025 Back User Agent (B2BUA) in case of SIP). 1027 2. A mobile host/device attaches to a gateway as part of the attach 1028 process. The number of hosts that a gateway supports is in the 1029 order of 1 to 10 million. Hence all the hosts assigned to a 1030 single gateway can be assigned private IPv4 addresses. Operators 1031 with large subscriber bases have multiple gateways and hence the 1032 same [RFC1918] IPv4 address space can be reused across gateways. 1033 The IPv4 address assigned to a host is unique within the scope of 1034 a single gateway. 1036 3. New services requiring direct connectivity between hosts should 1037 be build on IPv6. Possible existing IPv4-only services and 1038 applications requiring direct connectivity can be ported to IPv6. 1040 8.2. IPv6 for transport 1042 The various reference points of the 3GPP architecture such as S1-U, 1043 S5 and S8 are based on either GTP or PMIPv6. The underlying 1044 transport for these reference points can be IPv4 or IPv6. GTP has 1045 been able to operate over IPv6 transport (optionally) since R99 and 1046 PMIPv6 has supported IPv6 transport starting from its introduction in 1047 Release-8. The user plane traffic between the mobile host and the 1048 gateway can use either IPv4 or IPv6. These packets are essentially 1049 treated as payload by GTP/PMIPv6 and transported accordingly with no 1050 real attention paid to the information (at least from a routing 1051 perspective) contained in the IPv4 or IPv6 headers. The transport 1052 links between the eNodeB and the SGW, and the link between the SGW 1053 and PDN-GW can be migrated to IPv6 without any direct implications to 1054 the architecture. 1056 Currently, the inter-operator (for 3GPP technology) roaming networks 1057 are all IPv4-only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). 1058 Eventually these roaming networks will also get migrated to IPv6, if 1059 there is a business reason for that. The migration period can be 1060 prolonged considerably because the 3GPP protocols always tunnel user 1061 plane traffic in the core network and as described earlier the 1062 transport network IP version is not in any way tied to user plane IP 1063 version. Furthermore, the design of the inter-operator roaming 1064 networks is such that the user plane and transport network IP 1065 addressing is completely separated from each other. The inter- 1066 operator roaming network itself is also completely separated from the 1067 Internet. Only those core network nodes that must be connected to 1068 the inter-operator roaming networks are actually visible there, and 1069 be able to send and receive (tunneled) traffic within the inter- 1070 operator roaming networks. Obviously, in order the roaming to work 1071 properly, the operators have to agree on supported protocol versions 1072 so that the visited network does not, for example, unnecessarily drop 1073 user plane IPv6 traffic. 1075 8.3. Operational Aspects of Running Dual-Stack Networks 1077 Operating dual-stack networks does imply cost and complexity to a 1078 certain extent. However these factors are mitigated by the assurance 1079 that legacy devices and services are unaffected and there is always a 1080 fallback to IPv4 in case of issues with the IPv6 deployment or 1081 network elements. The model also enables operators to develop 1082 operational experience and expertise in an incremental manner. 1084 Running dual-stack networks requires the management of multiple IP 1085 address spaces. Tracking of hosts needs to be expanded since it can 1086 be identified by either an IPv4 address or IPv6 prefix. Network 1087 elements will also need to be dual-stack capable in order to support 1088 the dual-stack deployment model. 1090 Deployment and migration cases described in Section 6.1 for providing 1091 dual-stack like capability may mean doubled resource usage in 1092 operator's network. This is a major concern against providing dual- 1093 stack like connectivity using techniques discussed in Section 6.1. 1094 Also handovers between networks with different capabilities in terms 1095 of networks being dual-stack like service capable or not, may turn 1096 out hard to comprehend for users and for application/services to cope 1097 with. These facts may add other than just technical concerns for 1098 operators when planning to roll out dual-stack service offerings. 1100 8.4. Operational Aspects of Running a Network with IPv6-only Bearers 1102 It is possible to allocate IPv6-only type bearers to mobile hosts in 1103 3GPP networks. IPv6-only bearer type has been part of the 3GPP 1104 specification since the beginning. In 3GPP Release-8 (and later) it 1105 was defined that a dual-stack mobile host (or when the radio 1106 equipment has no knowledge of the host IP stack capabilities) must 1107 first attempt to establish a dual-stack bearer and then possibly fall 1108 back to single IP version bearer. A Release-8 (or later) mobile host 1109 with IPv6-only stack can directly attempt to establish an IPv6-only 1110 bearer. The IPv6-only behaviour is up to a subscription provisioning 1111 or a PDN-GW configuration, and the fallback scenarios do not 1112 necessarily cause additional signaling. 1114 Although the bullets below introduce IPv6 to IPv4 address translation 1115 and specifically discuss NAT64 technology [RFC6144], the current 3GPP 1116 Release-8 architecture does not describe the use of address 1117 translation or NAT64. It is up to a specific deployment whether 1118 address translation is part of the network or not. Some operational 1119 aspects to consider for running a network with IPv6-only bearers: 1121 o The mobile hosts must have an IPv6 capable stack and a radio 1122 interface capable of establishing an IPv6 PDP context or PDN 1123 connection. 1125 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 1126 bearers. Furthermore, the SGSN/MME must allow the creation of PDP 1127 Type or PDN Type of IPv6. 1129 o Many of the common applications are IP version agnostic and hence 1130 would work using an IPv6 bearer. However, applications that are 1131 IPv4 specific would not work. 1133 o Inter-operator roaming is another aspect which causes issues, at 1134 least during the ramp up phase of the IPv6 deployment. If the 1135 visited network to which outbound roamers attach to does not 1136 support PDP/PDN Type IPv6, then there needs to be a fallback 1137 option. The fallback option in this specific case is mostly up to 1138 the mobile host to implement. Several cases are discussed in the 1139 following sections. 1141 o If and when a mobile host using IPv6-only bearer needs to access 1142 to IPv4 Internet/network, a translation of some type from IPv6 to 1143 IPv4 has to be deployed in the network. NAT64 (and DNS64) is one 1144 solution that can be used for this purpose and works for a certain 1145 set of protocols (read TCP, UDP and ICMP, and when applications 1146 actually use DNS for resolving name to IP addresses). 1148 8.5. Restricting Outbound IPv6 Roaming 1150 Roaming was briefly touched upon in Sections 8.2 and 8.4. While 1151 there is interest in offering roaming service for IPv6 enabled mobile 1152 hosts and subscriptions, not all visited networks are prepared for 1153 IPv6 outbound roamers. There are basically two issues. First, the 1154 visited network SGSN does not support the IPv6 PDP Context or IPv4v6 1155 PDP Context types. These should mostly concern pre-Release-9 2G/3G 1156 networks without S4-SGSN but there is no definitive rule as the 1157 deployed feature sets vary depending on implementations and licenses. 1158 Second, the visited network might not be commercially ready for IPv6 1159 outbound roamers, while everything might work technically at the user 1160 plane level. This would lead to "revenue leakage" especially from 1161 the visited operator point of view (note that the use of visited 1162 network GGSN/PDN-GW does not really exist in real deployments today). 1163 Therefore, it might be in the interest of operators to prohibit 1164 roaming selectively within specific visited networks. 1166 Unfortunately, it is not mandatory to implement/deploy 3GPP standards 1167 based solution to selectively prohibit IPv6 roaming without also 1168 prohibiting other packet services (such as IPv4 roaming). However, 1169 there are few possibilities how this can be done in real deployments. 1170 The examples given below are either optional and/or vendor specific 1171 features to the 3GPP EPC: 1173 o Using Policy and Charging Control (PCC) [TS.23203] functionality 1174 and its rules to fail, for example, the bearer authorization when 1175 a desired criteria is met. In this case that would be PDN/PDP 1176 Type IPv6/IPv4v6 and a specific visited network. The rules can be 1177 provisioned either in the home network or locally in the visited 1178 network. 1180 o Some Home Location Register (HLR) and Home Subscriber Server (HSS) 1181 subscriber databases allow prohibiting roaming in a specific 1182 (visited) network for a specified PDN/PDP Type. 1184 The obvious problems are that these solutions are not mandatory, are 1185 not unified across networks, and therefore also lack well-specified 1186 fall back mechanism from the mobile host point of view. 1188 8.6. Inter-RAT Handovers and IP Versions 1190 It is obvious that operators start incrementally deploy EPS along 1191 with the existing UTRAN/GERAN, handovers between different radio 1192 technologies (inter-RAT handovers) become inevitable. In case of 1193 inter-RAT handovers 3GPP supports the following IP addressing 1194 scenarios: 1196 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 1197 bearer. 1199 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 1200 bearer. 1202 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 1203 bearer. 1205 Other types of configurations are considered network planning 1206 mistakes. What the above rules essentially imply is that the network 1207 migration has to be planned and subscriptions provisioned based on 1208 the lowest common nominator, if inter-RAT handovers are desired. For 1209 example, if some part of the UTRAN network cannot serve anything but 1210 IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 1211 bearers. Various combinations of subscriber provisioning regarding 1212 IP versions are discussed further in Section 8.7. 1214 8.7. Provisioning of IPv6 Subscribers and Various Combinations During 1215 Initial Network Attachment 1217 Subscribers' provisioned PDP/PDN Types have multiple configurations. 1218 The supported PDP/PDN Type is provisioned per each APN for every 1219 subscriber. The following PDN Types are possible in the HSS for a 1220 Release-8 subscription [TS.23401]: 1222 o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in a HLR 1223 and Mobile Applicatio Part (MAP) [TS.29002] signaling prior 1224 Release-9). 1226 o IPv6-only PDN Type 1228 o IPv4-only PDN Type. 1230 o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not 1231 exist in a HLR or MAP signaling. However, a HLR may have multiple 1232 APN configurations of different PDN Types, which effectively 1233 achieves the same functionality). 1235 A Release-8 dual-stack mobile host must always attempt to establish a 1236 PDP/PDN Type IPv4v6 bearer. The same also applies when the modem 1237 part of the mobile host does not have exact knowledge whether the 1238 host operating system IP stack is a dual-stack capable or not. A 1239 mobile host that is IPv6-only capable must attempt to establish a 1240 PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4-only 1241 capable must attempt to establish a PDN/PDP Type IPv4 bearer. 1243 In a case the PDP/PDN Type requested by a mobile host does not match 1244 what has been provisioned for the subscriber in the HSS (or HLR), the 1245 mobile host possibly falls back to a different PDP/PDN Type. The 1246 network (i.e. the MME or the S4-SGSN) is able to inform the mobile 1247 host during the network attachment signaling why it did not get the 1248 requested PDP/PDN Type. These response/cause codes are documented in 1249 [TS.24008] for requested PDP Types and [TS.24301] for requested PDN 1250 Types: 1252 o (E)SM cause #50 "PDN/PDP type IPv4-only allowed". 1254 o (E)SM cause #51 "PDN/PDP type IPv6-only allowed". 1256 o (E)SM cause #52 "single address bearers only allowed". 1258 The above response/cause codes apply to Release-8 and onwards. In 1259 pre-Release-8 networks used response/cause codes vary depending on 1260 the vendor, unfortunately. 1262 Possible fall back cases when the network deploys MMEs and/or S4- 1263 SGSNs include (as documented in [TS.23401]): 1265 o Requested and provisioned PDP/PDN Types match => requested. 1267 o Requested IPv4v6 and provisioned IPv6 => IPv6 and a mobile host 1268 receives indication that IPv6-only bearer is allowed. 1270 o Requested IPv4v6 and provisioned IPv4 => IPv4 and the mobile host 1271 receives indication that IPv4-only bearer is allowed. 1273 o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is 1274 selected by the MME/S4-SGSN based on an unspecified criteria. The 1275 mobile host may then attempt to establish, based on the mobile 1276 host implementation, a parallel bearer of a different PDP/PDN 1277 Type. 1279 o Other combinations cause the bearer establishment to fail. 1281 In addition to PDP/PDN Types provisioned in the HSS, it is also 1282 possible for a PDN-GW (and a MME/S4-SGSN) to affect the final 1283 selected PDP/PDN Type: 1285 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 1286 or IPv6. If the MME operator had included the "Dual Address 1287 Bearer Flag" into the bearer establishment signaling, then the 1288 mobile host receives an indication that IPv6-only or IPv4-only 1289 bearer is allowed. 1291 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 1292 or IPv6. If the MME operator had not included the "Dual Address 1293 Bearer Flag" into the bearer establishment signaling, then the 1294 mobile host may attempt to establish, based on the mobile host 1295 implementation, a parallel bearer of different PDP/PDN Type. 1297 A SGSN that does not understand the requested PDP Type is supposed to 1298 handle the requested PDP Type as IPv4. If for some reason a MME does 1299 not understand the requested PDN Type, then the PDN Type is handled 1300 as IPv6. 1302 9. IANA Considerations 1304 This document has no requests to IANA. 1306 10. Security Considerations 1308 This document does not introduce any security related concerns. 1310 11. Summary and Conclusion 1312 The 3GPP network architecture and specifications enable the 1313 establishment of IPv4 and IPv6 connections through the use of 1314 appropriate PDP context types. The current generation of deployed 1315 networks can support dual-stack connectivity if the packet core 1316 network elements such as the SGSN and GGSN have the capability. With 1317 Release-8, 3GPP has specified a more optimal PDP context type which 1318 enables the transport of IPv4 and IPv6 packets within a single PDP 1319 context between the mobile station and the gateway. 1321 As devices and applications are upgraded to support IPv6 they can 1322 start leveraging the IPv6 connectivity provided by the networks while 1323 maintaining the fall back to IPv4 capability. Enabling IPv6 1324 connectivity in the 3GPP networks by itself will provide some degree 1325 of relief to the IPv4 address space as many of the applications and 1326 services can start to work over IPv6. However without comprehensive 1327 testing of different applications and solutions that exist today and 1328 are widely used, for their ability to operate over IPv6 PDN 1329 connections, an IPv6-only access would cause disruptions. 1331 12. Acknowledgements 1333 The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and 1334 Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Cameron Byrne, Ales 1335 Vizdal and Frank Brockners for their reviews and comments on this 1336 document. 1338 13. Informative References 1340 [GSMA.IR.34] 1341 GSMA, "Inter-PLMN Backbone Guidelines", GSMA 1342 PRD IR.34.4.9, March 2010. 1344 [I-D.ietf-dhc-pd-exclude] 1345 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1346 "Prefix Exclude Option for DHCPv6-based Prefix 1347 Delegation", draft-ietf-dhc-pd-exclude-02 (work in 1348 progress), June 2011. 1350 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1351 E. Lear, "Address Allocation for Private Internets", 1352 BCP 5, RFC 1918, February 1996. 1354 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1355 RFC 2131, March 1997. 1357 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1358 and M. Carney, "Dynamic Host Configuration Protocol for 1359 IPv6 (DHCPv6)", RFC 3315, July 2003. 1361 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 1362 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 1363 Second and Third Generation Cellular Hosts", RFC 3316, 1364 April 2003. 1366 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1367 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1368 December 2003. 1370 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1371 (DHCP) Service for IPv6", RFC 3736, April 2004. 1373 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1374 Proxies (ND Proxy)", RFC 4389, April 2006. 1376 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1377 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1378 September 2007. 1380 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1381 Address Autoconfiguration", RFC 4862, September 2007. 1383 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1384 Extensions for Stateless Address Autoconfiguration in 1385 IPv6", RFC 4941, September 2007. 1387 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1388 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1390 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1391 IPv4/IPv6 Translation", RFC 6144, April 2011. 1393 [TR.23975] 1394 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, 1395 June 2010. 1397 [TS.23060] 1398 3GPP, "General Packet Radio Service (GPRS); Service 1399 description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. 1401 [TS.23203] 1402 3GPP, "Policy and charging control architecture (PCC)", 1403 3GPP TS 23.203 8.11.0, September 2010. 1405 [TS.23401] 1406 3GPP, "General Packet Radio Service (GPRS) enhancements 1407 for Evolved Universal Terrestrial Radio Access Network 1408 (E-UTRAN) access", 3GPP TS 23.401 10.4.0, June 2011. 1410 [TS.24008] 1411 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 1412 TS 24.008 8.12.0, December 2010. 1414 [TS.24301] 1415 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1416 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1418 [TS.29002] 1419 3GPP, "Mobile Application Part (MAP) specification", 3GPP 1420 TS 29.002 9.5.0, June 2011. 1422 [TS.29060] 1423 3GPP, "General Packet Radio Service (GPRS); GPRS 1424 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1425 3GPP TS 29.274 8.8.0, April 2010. 1427 [TS.29061] 1428 3GPP, "Interworking between the Public Land Mobile Network 1429 (PLMN) supporting packet based services and Packet Data 1430 Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. 1432 [TS.29274] 1433 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1434 Packet Radio Service (GPRS) Tunnelling Protocol for 1435 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 1436 December 2010. 1438 Authors' Addresses 1440 Jouni Korhonen (editor) 1441 Nokia Siemens Networks 1442 Linnoitustie 6 1443 FI-02600 Espoo 1444 FINLAND 1446 Email: jouni.nospam@gmail.com 1448 Jonne Soininen 1449 Renesas Mobile 1450 Porkkalankatu 24 1451 FI-00180 Helsinki 1452 FINLAND 1454 Email: jonne.soininen@renesasmobile.com 1456 Basavaraj Patil 1457 Nokia 1458 6021 Connection drive 1459 Irving, TX 75039 1460 USA 1462 Email: basavaraj.patil@nokia.com 1464 Teemu Savolainen 1465 Nokia 1466 Hermiankatu 12 D 1467 FI-33720 Tampere 1468 FINLAND 1470 Email: teemu.savolainen@nokia.com 1472 Gabor Bajko 1473 Nokia 1474 323 Fairchild drive 6 1475 Mountain view, CA 94043 1476 USA 1478 Email: gabor.bajko@nokia.com 1479 Kaisu Iisakkila 1480 Renesas Mobile 1481 Porkkalankatu 24 1482 FI-00180 Helsinki 1483 FINLAND 1485 Email: kaisu.iisakkila@renesasmobile.com