idnits 2.17.1 draft-ietf-v6ops-3gpp-eps-08.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 (September 30, 2011) is 4586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GGSN' is mentioned on line 434, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-dhc-pd-exclude-03 -- 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: April 2, 2012 Renesas Mobile 6 B. Patil 7 T. Savolainen 8 G. Bajko 9 Nokia 10 K. Iisakkila 11 Renesas Mobile 12 September 30, 2011 14 IPv6 in 3GPP Evolved Packet System 15 draft-ietf-v6ops-3gpp-eps-08 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 April 2, 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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . 17 77 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 18 78 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 18 79 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 19 80 6.3. PDN Connection Establishment Process . . . . . . . . . . . 20 81 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 22 82 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 23 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 . . . . . . . . . . . . . . . . . . . . 26 89 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . 31 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 97 13. Informative References . . . . . . . . . . . . . . . . . . . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 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 User Equipment 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 User Equipment 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 User Equipment. 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 User Equipment. 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 Packet Data Protocol Type 308 A Packet Data Protocol Type (PDP Type) identifies the used/allowed 309 protocols within the PDP Context. Examples are IPv4, IPv6 and 310 IPv4v6 (dual stack). 312 S4 Serving Gateway Support Node 314 S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and 315 onwards) compliant SGSN that connects 2G/3G radio access network 316 to EPC via new Release-8 interfaces like S3, S4, and S6d. 318 Serving Gateway 320 Serving Gateway (SGW) is a gateway function in EPS, which 321 terminates the interface towards E-UTRAN. The SGW is the Mobility 322 Anchor point for layer-2 mobility (inter-eNodeB handovers). For 323 each User Equipment connected with the EPS, at any given point of 324 time, there is only one SGW. The SGW is essentially the user 325 plane part of the GPRS' SGSN forwarding packets between a PDN-GW. 327 Serving Gateway Support Node 329 Serving Gateway Support Node (SGSN) is a network element that is 330 located between the radio access network (RAN) and the gateway 331 (GGSN). A per User Equipment point to point (p2p) tunnel between 332 the GGSN and SGSN transports the packets between the User 333 Equipment and the gateway. 335 Terminal Equipment 337 The Terminal Equipment (TE) is any device/host connected to the 338 Mobile Terminal (MT) offering services to the user. A TE may 339 communicate to a MT, for example, over Point to Point Protocol 340 (PPP). 342 UE, MS, MN and Mobile 344 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 345 Node) and, mobile refer to the devices which are hosts with 346 ability to obtain Internet connectivity via a 3GPP network. A MS 347 comprises of a Terminal Equipment (TE) and a Mobile Terminal (MT). 348 The terms UE, MS, MN and devices are used interchangeably within 349 this document. 351 UMTS Terrestrial Radio Access Network 353 UMTS Terrestrial Radio Access Network (UTRAN) is communications 354 network, commonly referred to as 3G, and consists of NodeBs (3G 355 base station) and Radio Network Controllers (RNC) which make up 356 the UMTS radio access network. The UTRAN allows connectivity 357 between the User Equipment and the core network. UTRAN comprises 358 of WCDMA, HSPA and HSPA+ radio technologies. 360 User Plane 362 Data traffic and the required bearers for the data traffic. In 363 practice IP is the only data traffic protocol used in user plane. 365 Wideband Code Division Multiple Access 367 The Wideband Code Division Multiple Access (WCDMA) is the radio 368 interface used in UMTS networks. 370 eNodeB 372 The eNodeB is a base station entity that supports the Long Term 373 Evolution (LTE) air interface. 375 2.2. The concept of APN 377 The Access Point Name (APN) essentially refers to a gateway in the 378 3GPP network. The 'complete' APN is expressed in a form of a Fully 379 Qualified Domain Name (FQDN) and also piggybacked on the 380 administration of the DNS namespace, thus effectively allowing the 381 discovery of gateways using the DNS. User Equipment (UE) can choose 382 to attach to a specific gateway in the packet core. The gateway 383 provides connectivity to the Packet Data Network (PDN) such as the 384 Internet. An operator may also include gateways which do not provide 385 Internet connectivity, rather a connectivity to closed network 386 providing a set of operator's own services. A UE can be attached to 387 one or more gateways simultaneously. The gateway in a 3GPP network 388 is the GGSN or PDN-GW. Figure 1 below illustrates the APN-based 389 network connectivity concept. 391 .--. 392 _(. `) 393 .--. +------------+ _( PDN `)_ 394 _(Core`. |GW1 |====( Internet `) 395 +---+ ( NW )------|APN=internet| ( ` . ) ) 396 [UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' 397 ^ +---+ `--(___.-' | 398 | | .--. 399 | | +----------+ _(.PDN`) 400 | +--|GW2 | _(Operator`)_ 401 | |APN=OpServ|====( Services `) 402 UE is attached +----------+ ( ` . ) ) 403 to GW1 and GW2 `--(_______)---' 404 simultaneously 406 Figure 1: User Equipment attached to multiple APNs simultaneously 408 3. IP over 3GPP GPRS 410 3.1. Introduction to 3GPP GPRS 412 A simplified 2G/3G GPRS architecture is illustrated in Figure 2. 413 This architecture basically covers the GPRS core network since R99 to 414 Release-7, and radio access technologies such as GSM (2G), EDGE (2G, 415 often referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred 416 as 3.5G). The architecture shares obvious similarities with the 417 Evolved Packet System (EPS) as will be seen in Section 4. Based on 418 Gn/Gp interfaces, the GPRS core network functionality is logically 419 implemented on two network nodes, the SGSN and the GGSN. 421 3G 422 .--. .--. 423 Uu _( `. Iu +----+ +----+ _( `. 424 [UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN ) 425 ( ` . ) ) +----+ Gn +----+ Gi ( ` . ) ) 426 `--(___.-' / | `--(___.-' 427 / | 428 2G Gb-- | 429 .--. / | 430 _( `. / --Gp 431 [UE]~~|~~~( PDN )__/ | 432 Um ( ` . ) ) .--. 433 `--(___.-' _(. `) 434 _( [GGSN] `)_ 435 ( other `) 436 ( ` . PLMN ) ) 437 `--(_______)---' 439 Figure 2: Overview of the 2G/3G GPRS Logical Architecture 441 Gn/Gp: These interfaces provide a network based mobility service for 442 a UE and are used between a SGSN and a GGSN. The Gn 443 interface is used when GGSN and SGSN are located inside one 444 operator (i.e. PLMN). The Gp-interface is used if the GGSN 445 and the SGSN are located in different operator domains (i.e. 446 'other' PLMN). GTP protocol is defined for the Gn/Gp 447 interfaces (both GTP-C for the control plane and GTP-U for 448 the user plane). 450 Gb: Is the Base Station System (BSS) to SGSN interface, which is 451 used to carry information concerning packet data transmission 452 and layer-2 mobility management. The Gb-interface is based 453 on either on Frame Relay or IP. 455 Iu: Is the Radio Network System (RNS) to SGSN interface, which is 456 used to carry information concerning packet data transmission 457 and layer-2 mobility management. The user plane part of the 458 Iu-interface (actually the Iu-PS) is based on GTP-U. The 459 control plane part of the Iu-interface is based on Radio 460 Access Network Application Protocol (RANAP). 462 Gi: It is the interface between the GGSN and a PDN. The PDN may 463 be an operator external public or private packet data network 464 or an intra-operator packet data network. 466 Uu/Um: Are either 2G or 3G radio interfaces between a UE and a 467 respective radio access network. 469 The SGSN is responsible for the delivery of data packets from and to 470 the UE within its geographical service area when a direct tunnel 471 option is not used. If the direct tunnel is used, then the user 472 plane goes directly between the RNC (in the RNS) and the GGSN. The 473 control plane traffic always goes through the SGSN. For each UE 474 connected with the GPRS, at any given point of time, there is only 475 one SGSN. 477 3.2. PDP Context 479 A PDP (Packet Data Protocol) context is an association between a UE 480 represented by one IPv4 address and/or one /64 IPv6 prefix and a PDN 481 represented by an APN. Each PDN can be accessed via a gateway 482 (typically a GGSN or PDN-GW). On the UE a PDP context is equivalent 483 to a network interface. A UE may hence be attached to one or more 484 gateways via separate connections, i.e. PDP contexts. 3GPP GPRS 485 supports PDP Types IPv4, IPv6 and since Release-9 also PDP Type 486 IPv4v6 (dual-stack). 488 Each primary PDP context has its own IPv4 address and/or one /64 IPv6 489 prefix assigned to it by the PDN and anchored in the corresponding 490 gateway. The GGSN or PDN-GW is the first hop router for the UE. 491 Applications on the UE use the appropriate network interface (PDP 492 context) for connectivity to a specific PDN. Figure 3 represents a 493 high level view of what a PDP context implies in 3GPP networks. 495 Y 496 | +---------+ .--. 497 |--+ __________________________ | APNx in | _( `. 498 | |O______PDPc1_______________)| GGSN / |----(Internet) 499 | | | PDN-GW | ( ` . ) ) 500 |UE| +---------+ `--(___.-' 501 | | _______________________ +---------+ .--. 502 | |O______PDPc2____________)| APNy in | _(Priv`. 503 +--+ | GGSN / |-------(Network ) 504 | PDN-GW | ( ` . ) ) 505 +---------+ `--(___.-' 507 Figure 3: PDP contexts between the MS/UE and gateway 509 In the above figure there are two PDP contexts at the MS/UE (UE=User 510 Equipment in 3GPP parlance). The 'PDPc1' PDP context that is 511 connected to APNx provided Internet connectivity and the 'PDPc2' PDP 512 context provides connectivity to a private IP network via APNy (as an 513 example this network may include operator specific services such as 514 MMS (Multi media service). An application on the host such as a web 515 browser would use the PDP context that provides Internet connectivity 516 for accessing services on the Internet. An application such as MMS 517 would use APNy in the figure above because the service is provided 518 through the private network. 520 4. IP over 3GPP EPS 522 4.1. Introduction to 3GPP EPS 524 In its most basic form, the EPS architecture consists of only two 525 nodes on the user plane, a base station and a core network Gateway 526 (GW). The basic EPS architecture is illustrated in Figure 4. The 527 functional split of gateways allows for operators to choose optimized 528 topological locations of nodes within the network and enables various 529 deployment models including the sharing of radio networks between 530 different operators. This also allows independent scaling and growth 531 of traffic throughput and control signal processing. 533 +--------+ 534 S1-MME +-------+ S11 | IP | 535 +----|----| MME |---|----+ |Services| 536 | | | | +--------+ 537 | +-------+ | S5/ |SGi 538 +----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+ 539 |UE |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | 540 | |========|=======|====================|=======|======| | 541 +----+ +-------+DualStack EPS Bearer+-------+ +-------+ 543 Figure 4: EPS Architecture for 3GPP Access 545 S5/S8: It provides user plane tunnelling and tunnel management 546 between SGW and PDN-GW, using GTP (both GTP-U and GTP-C) or 547 PMIPv6 [RFC5213][TS.23402] as the network based mobility 548 management protocol. The S5 interface is used when PDN-GW 549 and SGW are located inside one operator (i.e. PLMN). The 550 S8-interface is used if the PDN-GW and the SGW are located 551 in different operator domains (i.e. 'other' PLMN). 553 S1-U: Provides user plane tunnelling and inter eNodeB path 554 switching during handover between eNodeB and SGW, using the 555 GTP-U protocol (GTP user plane). 557 S1-MME: Reference point for the control plane protocol between 558 eNodeB and MME. 560 SGi: It is the interface between the PDN-GW and the packet data 561 network. Packet data network may be an operator external 562 public or private packet data network or an intra operator 563 packet data network. 565 4.2. PDN Connection 567 A PDN connection is an association between a UE represented by one 568 IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an 569 APN. The PDN connection is the EPC equivalent of the GPRS PDP 570 context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is 571 responsible for the IP address/prefix allocation to the UE. On the 572 UE a PDN connection is equivalent to a network interface. A UE may 573 hence be attached to one or more gateways via separate connections, 574 i.e. PDN connections. 3GPP EPS supports PDN Types IPv4, IPv6 and 575 IPv4v6 (dual-stack) since the beginning of EPS i.e. Release-8. 577 Each PDN connection has its own IP address/prefix assigned to it by 578 the PDN and anchored in the corresponding gateway. In case of GTP- 579 based S5/S8 interface, the PDN-GW is the first hop router for the UE 580 and in case of PMIPv6-based S5/S8 the SGW is the first hop router. 581 Applications on the UE use the appropriate network interface (PDN 582 connection) for connectivity. 584 4.3. EPS bearer model 586 The logical concept of a bearer has been defined to be an aggregate 587 of one or more IP flows related to one or more services. An EPS 588 bearer exists between the UE and the PDN-GW and is used to provide 589 the same level of packet forwarding treatment to the aggregated IP 590 flows constituting the bearer. Services with IP flows requiring a 591 different packet forwarding treatment would therefore require more 592 than one EPS bearer. The UE performs the binding of the uplink IP 593 flows to the bearer while the PDN-GW performs this function for the 594 downlink packets. 596 In order to provide low latency for always on connectivity, a default 597 bearer will be provided at the time of startup and an IPv4 address 598 and/or IPv6 prefix gets assigned to the UE (this is different from 599 GPRS, where UEs are not automatically assigned with an IP address or 600 prefix). This default bearer will be allowed to carry all traffic 601 which is not associated with a dedicated bearer. Dedicated bearers 602 are used to carry traffic for IP flows that have been identified to 603 require a specific packet forwarding treatment. They may be 604 established at the time of startup; for example, in the case of 605 services that require always-on connectivity and better QoS than that 606 provided by the default bearer. The default bearer and the dedicated 607 bearer(s) associated to it share the same IP address(es)/prefix. 609 An EPS bearer is referred to as a GBR bearer if dedicated network 610 resources related to a Guaranteed Bit Rate (GBR) value that is 611 associated with the EPS bearer are permanently allocated (e.g. by an 612 admission control function in the eNodeB) at bearer establishment/ 613 modification. Otherwise, an EPS bearer is referred to as a non-GBR 614 bearer. The default bearer is always non-GBR, with the resources for 615 the IP flows not guaranteed at eNodeB, and with no admission control. 616 However, the dedicated bearer can be either GBR or non-GBR. A GBR 617 bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) 618 while more than one non-GBR bearer belonging to the same UE shares an 619 Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet 620 loss under congestion while GBR bearers are immune to such losses. 622 5. Address Management 624 5.1. IPv4 Address Configuration 626 UE's IPv4 address configuration is always performed during PDP 627 context/EPS bearer setup procedures (on layer-2). DHCPv4-based 628 [RFC2131] address configuration is supported by the 3GPP 629 specifications, but is not used in wide scale. The UE must always 630 support address configuration as part of the bearer setup signaling, 631 since DHCPv4 is optional for both UEs and networks. 633 The 3GPP standards also specify a 'deferred IPv4 address allocation' 634 on a PMIPv6-based dual-stack IPv4v6 PDN connection at the time of 635 connection establishment as described in Section 4.7.1 of [TS.23402]. 636 This has the advantage of a single PDN Connection for IPv6 and IPv4 637 along with deferring IPv4 address allocation until an application 638 needs it. The deferred address allocation is based on the use of 639 DHCPv4 as well as appropriate UE side implementation dependant 640 triggers to invoke the protocol. 642 5.2. IPv6 Address Configuration 644 IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in 645 [RFC4861][RFC4862] is the only supported address configuration 646 mechanism. Stateful DHCPv6-based address configuration [RFC3315] is 647 not supported by 3GPP specifications. On the other hand, Stateless 648 DHCPv6-service to obtain other configuration information is supported 649 [RFC3736]. This implies that the M-bit is always zero and the O-bit 650 may be set to one in the Router Advertisement (RA) sent to the UE. 652 3GPP network allocates each default bearer a unique /64 prefix, and 653 uses layer-2 signaling to suggest user equipment an Interface 654 Identifier that is guaranteed not to conflict with gateway's 655 Interface Identifier. The UE must configure its link-local address 656 using this Interface Identifier. The UE is allowed to use any 657 Interface Identifier it wishes for the other addresses it configures. 658 There is no restriction, for example, of using Privacy Extension for 659 SLAAC [RFC4941] or other similar types of mechanisms. However, there 660 are network drivers that fail to pass the Interface Identifier to the 661 stack and instead synthesize their own Interface Identifier (usually 662 a MAC address equivalent). If the UE skips the Duplicate Address 663 Detection (DAD) and also has other issues with the Neighbor Discovery 664 Protocol (see Section 5.4), then there is a small theoretical chance 665 that the UE configures exactly the same link-local address as the 666 GGSN/PDN-GW. The address collision may then cause issues in the IP 667 connectivity, for instance, the UE not being able to forward any 668 packets to uplink. 670 In the 3GPP link model the /64 prefix assigned to the UE cannot be 671 used for on-link determination (because the L-bit in the Prefix 672 Information Option (PIO) in the RA must always be set to zero). If 673 the advertised prefix is used for SLAAC then the A-bit in the PIO 674 must be set to one. The details of the 3GPP link-model and address 675 configuration is described in Section 11.2.1.3.2a of [TS.29061]. 676 More specifically, the GGSN/PDN-GW guarantees that the /64 prefix is 677 unique for the UE. Therefore, there is no need to perform any 678 Duplicate Address Detection (DAD) on addresses the UE creates (i.e., 679 the 'DupAddrDetectTransmits' variable in the UE could be zero). The 680 GGSN/PDN-GW is not allowed to generate any globally unique IPv6 681 addresses for itself using the /64 prefix assigned to the UE in the 682 RA. 684 The current 3GPP architecture limits number of prefixes in each 685 bearer to a single /64 prefix. If the UE finds more than one prefix 686 in the RA, it only considers the first one and silently discards the 687 others [TS.29061]. Therefore, multi-homing within a single bearer is 688 not possible. Renumbering without closing layer-2 connection is also 689 not possible. The lifetime of /64 prefix is bound to lifetime of 690 layer-2 connection even if the advertised prefix lifetime is longer 691 than the layer-2 connection lifetime. 693 5.3. Prefix Delegation 695 IPv6 prefix delegation is a part of Release-10 and is not covered by 696 any earlier release. However, the /64 prefix allocated for each 697 default bearer (and to the user equipment) may be shared to local 698 area network by user equipment implementing Neighbor Discovery proxy 699 (ND proxy) [RFC4389] functionality. 701 Release-10 prefix delegation uses the DHCPv6-based prefix delegation 702 [RFC3633]. The model defined for Release-10 requires aggregatable 703 prefixes, which means the /64 prefix allocated for the default bearer 704 (and to the user equipment) must be part of the shorter delegated 705 prefix. DHCPv6 prefix delegation has an explicit limitation 706 described in Section 12.1 of [RFC3633] that a prefix delegated to a 707 requesting router cannot be used by the delegating router (i.e., the 708 PDN-GW in this case). This implies the shorter 'delegated prefix' 709 cannot be given to the requesting router (i.e. the user equipment) as 710 such but has to be delivered by the delegating router (i.e. the 711 PDN-GW) in such a way the /64 prefix allocated to the default bearer 712 is not part of the 'delegated prefix'. An option to exclude a prefix 713 from delegation [I-D.ietf-dhc-pd-exclude] prevents this problem. 715 5.4. IPv6 Neighbor Discovery Considerations 717 3GPP link between the UE and the next hop router (e.g. GGSN) 718 resemble a point to point (p2p) link, which has no link-layer 719 addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. 720 The UE IP stack has to take this into consideration. When the 3GPP 721 PDP Context appears as a PPP interface/link to the UE, the IP stack 722 is usually prepared to handle Neighbor Discovery protocol and the 723 related Neighbor Cache state machine transitions in an appropriate 724 way, even though Neighbor Discovery protocol messages contain no link 725 layer address information. However, some operating systems discard 726 Router Advertisements on their PPP interface/link as a default 727 setting. This causes the SLAAC to fail when the 3GPP PDP Context 728 gets established, thus stalling all IPv6 traffic. 730 Currently several operating systems and their network drivers can 731 make the 3GPP PDP Context to appear as an IEEE802 interface/link to 732 the IP stack. This has few known issues, especially when the IP 733 stack is made to believe the underlying link has link-layer 734 addresses. First, the Neighbor Advertisement sent by a GGSN as a 735 response to an address resolution triggered Neighbor Solicitation may 736 not contain a Target Link-Layer address option (as suggested in 737 [RFC4861] Section 4.4). Then it is possible that the address 738 resolution never completes when the UE tries to resolve the link- 739 layer address of the GGSN, thus stalling all IPv6 traffic. 741 Second, the GGSN may simply discard all address resolution triggered 742 Neighbor Solicitation messages (as sometimes misinterpreted from 743 [RFC3316] Section 2.4.1 that responding to address resolution and 744 next-hop determination are not needed). As a result the address 745 resolution never completes when the UE tries to resolve the link- 746 layer address of the GGSN, thus stalling all IPv6 traffic. There is 747 little that can be done about this in the GGSN, assuming the Neighbor 748 Discovery implementation already does the right thing. But the UE 749 stacks must be able to handle address resolution in the manner that 750 they have chosen to represent the interface. In other words, if they 751 emulate IEEE802 type interfaces, they also need to process Neighbor 752 Discovery messages correctly. 754 6. 3GPP Dual-Stack Approach to IPv6 756 6.1. 3GPP Networks Prior to Release-8 758 3GPP standards prior to Release-8 provide IPv6 access for cellular 759 devices with PDP contexts of type IPv6 [TS.23060]. For dual-stack 760 access, a PDP context of type IPv6 is established in parallel to the 761 PDP context of type IPv4, as shown in Figure 5 and Figure 6. For 762 IPv4-only service, connections are created over the PDP context of 763 type IPv4 and for IPv6-only service connections are created over the 764 PDP context of type IPv6. The two PDP contexts of different type may 765 use the same APN (and the gateway), however, this aspect is not 766 explicitly defined in standards. Therefore, cellular device and 767 gateway implementations from different vendors may have varying 768 support for this functionality. 770 Y .--. 771 | _(IPv4`. 772 |---+ +---+ +---+ ( PDN ) 773 | D |~~~~~~~//-----| |====| |====( ` . ) ) 774 | S | IPv4 context | S | | G | `--(___.-' 775 | | | G | | G | .--. 776 | U | | S | | S | _(IPv6`. 777 | E | IPv6 context | N | | N | ( PDN ) 778 |///|~~~~~~~//-----| |====|(s)|====( ` . ) ) 779 +---+ +---+ +---+ `--(___.-' 781 Figure 5: A dual-stack User Equipment connecting to both IPv4 and 782 IPv6 Internet using parallel IPv4-only and IPv6-only PDP contexts 784 Y 785 | 786 |---+ +---+ +---+ 787 | D |~~~~~~~//-----| |====| | .--. 788 | S | IPv4 context | S | | G | _( DS `. 789 | | | G | | G | ( PDN ) 790 | U | | S | | S |====( ` . ) ) 791 | E | IPv6 context | N | | N | `--(___.-' 792 |///|~~~~~~~//-----| |====| | 793 +---+ +---+ +---+ 795 Figure 6: A dual-stack User Equipment connecting to dual-stack 796 Internet using parallel IPv4-only and IPv6-only PDP contexts 798 The approach of having parallel IPv4 and IPv6 type of PDP contexts 799 open is not optimal, because two PDP contexts require double the 800 signaling and consume more network resources than a single PDP 801 context. In the figure above the IPv4 and IPv6 PDP contexts are 802 attached to the same GGSN. While this is possible, the dual-stack 803 (DS) MS may be attached to different GGSNs in the scenario where one 804 GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 805 PDN connectivity. 807 6.2. 3GPP Release-8 and -9 Networks 809 Since 3GPP Release-8, the powerful concept of a dual-stack type of 810 PDN connection and EPS bearer have been introduced [TS.23401]. This 811 enables parallel use of both IPv4 and IPv6 on a single bearer 812 (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler 813 than in earlier 3GPP releases. As of Release-9, GPRS network nodes 814 also support dual-stack type (IPv4v6) PDP contexts. 816 Y 817 | 818 |---+ +---+ +---+ 819 | D | | | | P | .--. 820 | S | | | | D | _( DS `. 821 | | IPv4v6 (DS) | S | | N | ( PDN ) 822 | U |~~~~~~~//-----| G |====| - |====( ` . ) ) 823 | E | bearer | W | | G | `--(___.-' 824 |///| | | | W | 825 +---+ +---+ +---+ 827 Figure 7: A dual-stack User Equipment connecting to dual-stack 828 Internet using a single IPv4v6 type PDN connection 830 The following is a description of the various PDP contexts/PDN bearer 831 types that are specified by 3GPP: 833 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 834 two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to 835 get dual stack connectivity. 837 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 838 are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP 839 context is needed to get dual stack connectivity. 841 3. For 2G/3G access to EPC core (PDN-GW via S4-SGSN) from Release-8 842 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets 843 mapped to PDN Connection type. Minimum one PDP Context is needed 844 to get dual stack connectivity. 846 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are 847 three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN 848 Connection is needed to get dual stack connectivity. 850 6.3. PDN Connection Establishment Process 852 The PDN connection establishment process is specified in detail in 853 3GPP specifications. Figure 8 illustrates the high level process and 854 signaling involved in the establishment of a PDN connection. 856 UE eNb/ MME SGW PDN-GW HSS/ 857 | BS | | | AAA 858 | | | | | | 859 |---------->|(1) | | | | 860 | |---------->|(1) | | | 861 | | | | | | 862 |/---------------------------------------------------------\| 863 | Authentication and Authorization |(2) 864 |\---------------------------------------------------------/| 865 | | | | | | 866 | | |---------->|(3) | | 867 | | | |---------->|(3) | 868 | | | | | | 869 | | | |<----------|(4) | 870 | | |<----------|(4) | | 871 | |<----------|(5) | | | 872 |/---------\| | | | | 873 | RB setup |(6) | | | | 874 |\---------/| | | | | 875 | |---------->|(7) | | | 876 |---------->|(8) | | | | 877 | |---------->|(9) | | | 878 | | | | | | 879 |============= Uplink Data =========>==========>|(10) | 880 | | | | | | 881 | | |---------->|(11) | | 882 | | | | | | 883 | | |<----------|(12) | | 884 | | | | | | 885 |<============ Downlink Data =======<===========|(13) | 886 | | | | | | 888 Figure 8: Simplified PDN connection setup procedure in Release-8 890 1. The UE (i.e the MS) requires a data connection and hence decides 891 to establish a PDN connection with a PDN-GW. The UE sends an 892 "Attach Request" (layer-2) to the BS. The BS forwards this 893 attach request to the MME. 895 2. Authentication of the UE with the AAA server/HSS follows. If 896 the UE is authorized for establishing a data connection, the 897 following steps continue 899 3. The MME sends a "Create Session Request" message to the 900 Serving-GW. The SGW forwards the create session request to the 901 PDN-GW. The SGW knows the address of the PDN-GW to forward the 902 create session request to as a result of this information having 903 been obtained by the MME during the authentication/authorization 904 phase. 906 The UE IPv4 address and/or IPv6 prefix get assigned during this 907 step. If a subscribed IPv4 address and/or IPv6 prefix is 908 statically allocated for the UE for this APN, then the MME 909 already passes the address information to the SGW and eventually 910 to the PDN-GW in the "Create Session Request" message. 911 Otherwise, the PDN-GW manages the address assignment to the UE 912 (there is another variation to this where IPv4 address 913 allocation is delayed until the UE initiates a DHCPv4 exchange 914 but this is not discussed here). 916 4. The PDN-GW creates a PDN connection for the UE and sends "Create 917 Session Response" message to the SGW from which the session 918 request message was received from. The SGW forwards the 919 response to the corresponding MME which originated the request. 921 5. The MME sends the "Attach Accept/Initial Context Setup request" 922 message to the eNodeB/BS. 924 6. The radio bearer between the UE and the eNb is reconfigured 925 based on the parameters received from the MME. (See note 1 926 below) 928 7. The eNb sends "Initial Context Response" message to the MME. 930 8. The UE sends a "Direct Transfer" message to the eNodeB which 931 includes the Attach complete signal. 933 9. The eNodeB forwards the Attach complete message to the MME. 935 10. The UE can now start sending uplink packets to the PDN GW. 937 11. The MME sends a "Modify Bearer Request" message to the SGW. 939 12. The SGW responds with a "Modify Bearer Response" message. At 940 this time the downlink connection is also ready. 942 13. The UE can now start receiving downlink packets, including 943 possible SLAAC related IPv6 packets. 945 The type of PDN connection established between the UE and the PDN-GW 946 can be any of the types described in the previous section. The dual- 947 stack (DS) PDN connection, i.e the one which supports both IPv4 and 948 IPv6 packets is the default one that will be established if no 949 specific PDN connection type is specified by the UE in Release-8 950 networks. 952 Note 1: The UE receives the PDN Address Information Element 953 [TS.24301] at the end of radio bearer setup messaging. This 954 Information Element contains only the Interface Identifier of the 955 IPv6 address. In a case of GPRS the PDP Address Information 956 Element [TS.24008] would contain a complete IPv6 address. 957 However, the UE must ignore the IPv6 prefix if it receives one in 958 the message (see Section 11.2.1.3.2a of [TS.29061]). 960 6.4. Mobility of 3GPP IPv4v6 Type of Bearers 962 3GPP discussed at length various approaches to support mobility 963 between a Release-8 LTE network and a pre-Release-9 2G/3G network 964 without a S4-SGSN for the new dual-stack type of bearers. The chosen 965 approach for mobility is as follows, in short: if a UE is allowed for 966 doing handovers between a Release-8 LTE network and a pre-Release-9 967 2G/3G network without a S4-SGSN while having open PDN connections, 968 only single stack bearers are used. Essentially this means following 969 deployment options: 971 1. If a network knows a UE may do handovers between a Release-8 LTE 972 network and a pre-Release-9 2G/3G network without a S4-SGSN, then 973 the network is configured to provide only single stack bearers, 974 even if the UE requests dual-stack bearers. 976 2. If the network knows the UE does handovers only between a 977 Release-8 LTE network and a Release-9 2G/3G network or a pre- 978 Release-9 network with a S4-SGSN, then the network is configured 979 to provide the UE with dual-stack bearers on request. The same 980 also applies for LTE-only deployments. 982 When a network operator and their roaming partners have upgraded 983 their networks to Release-8, it is possible to use the new IPv4v6 984 dual-stack type of bearers. A Release-8 UE always requests for a 985 dual-stack bearer, but accepts what is assigned by the network. 987 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 989 3GPP networks can natively transport IPv4 and IPv6 packets between 990 the UE and the gateway (GGSN or PDN-GW) as a result of establishing 991 either a dual-stack PDP context or parallel IPv4 and IPv6 PDP 992 contexts. 994 Current deployments of 3GPP networks primarily support IPv4-only. 995 These networks can be upgraded to also support IPv6 PDP contexts. By 996 doing so devices and applications that are IPv6 capable can start 997 utilizing the IPv6 connectivity. This will also ensure that legacy 998 devices and applications continue to work with no impact. As newer 999 devices start using IPv6 connectivity, the demand for actively used 1000 IPv4 connections is expected to slowly decrease, helping operators 1001 with a transition to IPv6. With a dual-stack approach, there is 1002 always the potential to fallback to IPv4. A device which may be 1003 roaming in a network wherein IPv6 is not supported by the visited 1004 network could fall back to using IPv4 PDP contexts and hence the end 1005 user would at least get some connectivity. Unfortunately, dual-stack 1006 approach as such does not lower the number of used IPv4 addresses. 1007 Every dual-stack bearer still needs to be given an IPv4 address, 1008 private or public. This is a major concern with dual-stack bearers 1009 concerning IPv6 transition. However, if the majority of active IP 1010 communication has moved over to IPv6, then in case of Network Address 1011 Translation from IPv4 to IPv4 (NAT44) [RFC1918] IPv4 connections the 1012 number of active IPv4 connections can still be expected to gradually 1013 decrease and thus giving some level of relief regarding NAT44 1014 function scalability. 1016 As the networks evolve to support Release-8 EPS architecture and the 1017 dual-stack PDP contexts, newer devices will be able to leverage such 1018 capability and have a single bearer which supports both IPv4 and 1019 IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP 1020 between the MS and the gateway (GGSN/PDN-GW) the transport network 1021 capability in terms of whether it supports IPv4 or IPv6 on the 1022 interfaces between the eNodeB and SGW or, SGW and PDN-GW is 1023 immaterial. 1025 8. Deployment issues 1027 8.1. Overlapping IPv4 Addresses 1029 Given the shortage of globally routable public IPv4 addresses, 1030 operators tend to assign private IPv4 addresses [RFC1918] to UEs when 1031 they establish an IPv4-only PDP context or an IPv4v6 type PDN 1032 context. About 16 million UEs can be assigned a private IPv4 address 1033 that is unique within a domain. However, in case of many operators 1034 the number of subscribers is greater than 16 million. The issue can 1035 be dealt with by assigning overlapping RFC 1918 IPv4 addresses to 1036 UEs. As a result the IPv4 address assigned to a UE within the 1037 context of a single operator realm would no longer be unique. This 1038 has the obvious and known issues of NATed IP connection in the 1039 Internet. Direct UE to UE connectivity becomes complicated, unless 1040 the UEs are within the same private address range pool and/or 1041 anchored to the same gateway, referrals using IP addresses will have 1042 issues and so forth. These are generic issues and not only a concern 1043 of the EPS. However, 3GPP as such does not have any mandatory 1044 language concerning NAT44 functionality in EPC. Obvious deployment 1045 choices apply also to EPC: 1047 1. Very large network deployments are partitioned, for example, 1048 based on a geographical areas. This partitioning allows for 1049 overlapping IPv4 addresses ranges to be assigned to UEs that are 1050 in different areas. Each area has its own pool of gateways that 1051 are dedicated for a certain overlapping IPv4 address range 1052 (referred here later as a zone). Standard NAT44 functionality 1053 allows for communication from the [RFC1918] private zone to the 1054 Internet. Communication between zones require special 1055 arrangement, such as using intermediate gateways (e.g. Back to 1056 Back User Agent (B2BUA) in case of SIP). 1058 2. A UE attaches to a gateway as part of the attach process. The 1059 number of UEs that a gateway supports is in the order of 1 to 10 1060 million. Hence all the UEs assigned to a single gateway can be 1061 assigned private IPv4 addresses. Operators with large subscriber 1062 bases have multiple gateways and hence the same [RFC1918] IPv4 1063 address space can be reused across gateways. The IPv4 address 1064 assigned to a UE is unique within the scope of a single gateway. 1066 3. New services requiring direct connectivity between UEs should be 1067 built on IPv6. Possible existing IPv4-only services and 1068 applications requiring direct connectivity can be ported to IPv6. 1070 8.2. IPv6 for transport 1072 The various reference points of the 3GPP architecture such as S1-U, 1073 S5 and S8 are based on either GTP or PMIPv6. The underlying 1074 transport for these reference points can be IPv4 or IPv6. GTP has 1075 been able to operate over IPv6 transport (optionally) since R99 and 1076 PMIPv6 has supported IPv6 transport starting from its introduction in 1077 Release-8. The user plane traffic between the UE and the gateway can 1078 use either IPv4 or IPv6. These packets are essentially treated as 1079 payload by GTP/PMIPv6 and transported accordingly with no real 1080 attention paid to the information (at least from a routing 1081 perspective) contained in the IPv4 or IPv6 headers. The transport 1082 links between the eNodeB and the SGW, and the link between the SGW 1083 and PDN-GW can be migrated to IPv6 without any direct implications to 1084 the architecture. 1086 Currently, the inter-operator (for 3GPP technology) roaming networks 1087 are all IPv4-only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). 1088 Eventually these roaming networks will also get migrated to IPv6, if 1089 there is a business reason for that. The migration period can be 1090 prolonged considerably because the 3GPP protocols always tunnel user 1091 plane traffic in the core network and as described earlier the 1092 transport network IP version is not in any way tied to user plane IP 1093 version. Furthermore, the design of the inter-operator roaming 1094 networks is such that the user plane and transport network IP 1095 addressing is completely separated from each other. The inter- 1096 operator roaming network itself is also completely separated from the 1097 Internet. Only those core network nodes that must be connected to 1098 the inter-operator roaming networks are actually visible there, and 1099 be able to send and receive (tunneled) traffic within the inter- 1100 operator roaming networks. Obviously, in order the roaming to work 1101 properly, the operators have to agree on supported protocol versions 1102 so that the visited network does not, for example, unnecessarily drop 1103 user plane IPv6 traffic. 1105 8.3. Operational Aspects of Running Dual-Stack Networks 1107 Operating dual-stack networks does imply cost and complexity to a 1108 certain extent. However these factors are mitigated by the assurance 1109 that legacy devices and services are unaffected and there is always a 1110 fallback to IPv4 in case of issues with the IPv6 deployment or 1111 network elements. The model also enables operators to develop 1112 operational experience and expertise in an incremental manner. 1114 Running dual-stack networks requires the management of multiple IP 1115 address spaces. Tracking of UEs needs to be expanded since it can be 1116 identified by either an IPv4 address or IPv6 prefix. Network 1117 elements will also need to be dual-stack capable in order to support 1118 the dual-stack deployment model. 1120 Deployment and migration cases described in Section 6.1 for providing 1121 dual-stack like capability may mean doubled resource usage in 1122 operator's network. This is a major concern against providing dual- 1123 stack like connectivity using techniques discussed in Section 6.1. 1124 Also handovers between networks with different capabilities in terms 1125 of networks being dual-stack like service capable or not, may turn 1126 out hard to comprehend for users and for application/services to cope 1127 with. These facts may add other than just technical concerns for 1128 operators when planning to roll out dual-stack service offerings. 1130 8.4. Operational Aspects of Running a Network with IPv6-only Bearers 1132 It is possible to allocate IPv6-only type bearers to UEs in 3GPP 1133 networks. IPv6-only bearer type has been part of the 3GPP 1134 specification since the beginning. In 3GPP Release-8 (and later) it 1135 was defined that a dual-stack UE (or when the radio equipment has no 1136 knowledge of the UE IP stack capabilities) must first attempt to 1137 establish a dual-stack bearer and then possibly fall back to single 1138 IP version bearer. A Release-8 (or later) UE with IPv6-only stack 1139 can directly attempt to establish an IPv6-only bearer. The IPv6-only 1140 behaviour is up to a subscription provisioning or a PDN-GW 1141 configuration, and the fallback scenarios do not necessarily cause 1142 additional signaling. 1144 Although the bullets below introduce IPv6 to IPv4 address translation 1145 and specifically discuss NAT64 technology [RFC6144], the current 3GPP 1146 Release-8 architecture does not describe the use of address 1147 translation or NAT64. It is up to a specific deployment whether 1148 address translation is part of the network or not. Some operational 1149 aspects to consider for running a network with IPv6-only bearers: 1151 o The UE must have an IPv6 capable stack and a radio interface 1152 capable of establishing an IPv6 PDP context or PDN connection. 1154 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 1155 bearers. Furthermore, the SGSN/MME must allow the creation of PDP 1156 Type or PDN Type of IPv6. 1158 o Many of the common applications are IP version agnostic and hence 1159 would work using an IPv6 bearer. However, applications that are 1160 IPv4 specific would not work. 1162 o Inter-operator roaming is another aspect which causes issues, at 1163 least during the ramp up phase of the IPv6 deployment. If the 1164 visited network to which outbound roamers attach to does not 1165 support PDP/PDN Type IPv6, then there needs to be a fallback 1166 option. The fallback option in this specific case is mostly up to 1167 the UE to implement. Several cases are discussed in the following 1168 sections. 1170 o If and when a UE using IPv6-only bearer needs to access to IPv4 1171 Internet/network, a translation of some type from IPv6 to IPv4 has 1172 to be deployed in the network. NAT64 (and DNS64) is one solution 1173 that can be used for this purpose and works for a certain set of 1174 protocols (read TCP, UDP and ICMP, and when applications actually 1175 use DNS for resolving name to IP addresses). 1177 8.5. Restricting Outbound IPv6 Roaming 1179 Roaming was briefly touched upon in Sections 8.2 and 8.4. While 1180 there is interest in offering roaming service for IPv6 enabled UEs 1181 and subscriptions, not all visited networks are prepared for IPv6 1182 outbound roamers: 1184 o The visited network SGSN does not support the IPv6 PDP Context or 1185 IPv4v6 PDP Context types. These should mostly concern pre- 1186 Release-9 2G/3G networks without S4-SGSN but there is no 1187 definitive rule as the deployed feature sets vary depending on 1188 implementations and licenses. 1190 o The visited network might not be commercially ready for IPv6 1191 outbound roamers, while everything might work technically at the 1192 user plane level. This would lead to "revenue leakage" especially 1193 from the visited operator point of view (note that the use of 1194 visited network GGSN/PDN-GW does not really exist in commercial 1195 deployments today for data roaming). 1197 It might be in the interest of operators to prohibit roaming 1198 selectively within specific visited networks until IPv6 roaming is in 1199 place. 3GPP does not specify a mechanism whereby IPv6 roaming is 1200 prohibited without also disabling IPv4 access and other packet 1201 services. The following options for disabling IPv6 access for 1202 roaming subscribers could be available in some network deployments: 1204 o Using Policy and Charging Control (PCC) [TS.23203] functionality 1205 and its rules to fail, for example, the bearer authorization when 1206 a desired criteria is met. In this case that would be PDN/PDP 1207 Type IPv6/IPv4v6 and a specific visited network. The rules can be 1208 provisioned either in the home network or locally in the visited 1209 network. 1211 o Some Home Location Register (HLR) and Home Subscriber Server (HSS) 1212 subscriber databases allow prohibiting roaming in a specific 1213 (visited) network for a specified PDN/PDP Type. 1215 The obvious problems are that these solutions are not mandatory, are 1216 not unified across networks, and therefore also lack well-specified 1217 fall back mechanism from the UE point of view. 1219 8.6. Inter-RAT Handovers and IP Versions 1221 It is obvious that operators start incrementally deploy EPS along 1222 with the existing UTRAN/GERAN, handovers between different radio 1223 technologies (inter-RAT handovers) become inevitable. In case of 1224 inter-RAT handovers 3GPP supports the following IP addressing 1225 scenarios: 1227 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 1228 bearer. 1230 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 1231 bearer. 1233 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 1234 bearer. 1236 Other types of configurations are not standardized. What the above 1237 rules essentially imply is that the network migration has to be 1238 planned and subscriptions provisioned based on the lowest common 1239 nominator, if inter-RAT handovers are desired. For example, if some 1240 part of the UTRAN network cannot serve anything but IPv4 bearers, 1241 then the E-UTRAN is also forced to provide only IPv4 bearers. 1242 Various combinations of subscriber provisioning regarding IP versions 1243 are discussed further in Section 8.7. 1245 8.7. Provisioning of IPv6 Subscribers and Various Combinations During 1246 Initial Network Attachment 1248 Subscribers' provisioned PDP/PDN Types have multiple configurations. 1249 The supported PDP/PDN Type is provisioned per each APN for every 1250 subscriber. The following PDN Types are possible in the HSS for a 1251 Release-8 subscription [TS.23401]: 1253 o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in a HLR 1254 and Mobile Application Part (MAP) [TS.29002] signaling prior 1255 Release-9). 1257 o IPv6-only PDN Type 1259 o IPv4-only PDN Type. 1261 o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not 1262 exist in a HLR or MAP signaling. However, a HLR may have multiple 1263 APN configurations of different PDN Types, which effectively 1264 achieves the same functionality). 1266 A Release-8 dual-stack UE must always attempt to establish a PDP/PDN 1267 Type IPv4v6 bearer. The same also applies when the modem part of the 1268 UE does not have exact knowledge whether the UE operating system IP 1269 stack is a dual-stack capable or not. A UE that is IPv6-only capable 1270 must attempt to establish a PDP/PDN Type IPv6 bearer. Last, a UE 1271 that is IPv4-only capable must attempt to establish a PDN/PDP Type 1272 IPv4 bearer. 1274 In a case the PDP/PDN Type requested by a UE does not match what has 1275 been provisioned for the subscriber in the HSS (or HLR), the UE 1276 possibly falls back to a different PDP/PDN Type. The network (i.e. 1277 the MME or the S4-SGSN) is able to inform the UE during the network 1278 attachment signaling why it did not get the requested PDP/PDN Type. 1279 These response/cause codes are documented in [TS.24008] for requested 1280 PDP Types and [TS.24301] for requested PDN Types: 1282 o (E)SM cause #50 "PDN/PDP type IPv4-only allowed". 1284 o (E)SM cause #51 "PDN/PDP type IPv6-only allowed". 1286 o (E)SM cause #52 "single address bearers only allowed". 1288 The above response/cause codes apply to Release-8 and onwards. In 1289 pre-Release-8 networks used response/cause codes vary depending on 1290 the vendor, unfortunately. 1292 Possible fall back cases when the network deploys MMEs and/or S4- 1293 SGSNs include (as documented in [TS.23401]): 1295 o Requested and provisioned PDP/PDN Types match => requested. 1297 o Requested IPv4v6 and provisioned IPv6 => IPv6 and a UE receives 1298 indication that IPv6-only bearer is allowed. 1300 o Requested IPv4v6 and provisioned IPv4 => IPv4 and the UE receives 1301 indication that IPv4-only bearer is allowed. 1303 o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is 1304 selected by the MME/S4-SGSN based on an unspecified criteria. The 1305 UE may then attempt to establish, based on the UE implementation, 1306 a parallel bearer of a different PDP/PDN Type. 1308 o Other combinations cause the bearer establishment to fail. 1310 In addition to PDP/PDN Types provisioned in the HSS, it is also 1311 possible for a PDN-GW (and a MME/S4-SGSN) to affect the final 1312 selected PDP/PDN Type: 1314 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 1315 or IPv6. If the MME operator had included the "Dual Address 1316 Bearer Flag" into the bearer establishment signaling, then the UE 1317 receives an indication that IPv6-only or IPv4-only bearer is 1318 allowed. 1320 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 1321 or IPv6. If the MME operator had not included the "Dual Address 1322 Bearer Flag" into the bearer establishment signaling, then the UE 1323 may attempt to establish, based on the UE implementation, a 1324 parallel bearer of different PDP/PDN Type. 1326 A SGSN that does not understand the requested PDP Type is supposed to 1327 handle the requested PDP Type as IPv4. If for some reason a MME does 1328 not understand the requested PDN Type, then the PDN Type is handled 1329 as IPv6. 1331 9. IANA Considerations 1333 This document has no requests to IANA. 1335 10. Security Considerations 1337 This document does not introduce any security related concerns. 1338 Section 5 of [RFC3316] already contains in depth discussion of IPv6 1339 related security considerations in 3GPP networks prior Release-8. 1340 This section discusses few additional security concerns to take into 1341 consideration. 1343 In 3GPP access the UE and the network always perform a mutual 1344 authentication during the network attachment [TS.33102][TS.33401]. 1345 Furthermore, each time a PDP Context/PDN Connection gets created, a 1346 new connection, a modification of an existing connection and an 1347 assignment of an IPv6 prefix or an IP address can be authorized 1348 against the PCC infrastructure [TS.23203] and/or PDN's AAA server. 1350 The wireless part of the 3GPP link between the UE and the (e)NodeB as 1351 well as the signaling messages between the UE and the MME/SGSN can be 1352 protected depending on the regional regulation and operators' 1353 deployment policy. User plane traffic can be confidentiality 1354 protected. The control plane is always at least integrity and replay 1355 protected, and may also be confidentiality protected. The protection 1356 within the transmission part of the network depends on operators' 1357 deployment policy. [TS.33401] 1359 Several of the on-link and neighbor discovery related attacks can be 1360 mitigated due the nature of 3GPP point to point link model, and the 1361 fact the UE and the first hop router (PGW/GGSN or SGW) being the only 1362 nodes on the link. For off-link IPv6 attacks the 3GPP EPS is as 1363 vulnerable as any IPv6 system. 1365 There have also been concerns that the UE IP stack might use 1366 permanent subscriber identities, such as IMSI, as the source for IPv6 1367 address Interface Identifier. This would be a privacy threat and 1368 allow tracking of subscribers, and therefore use of IMSI (or any 1369 [TS.23003] defined identity) as the Interface Identifier is 1370 prohibited [TS.23401]. However, there is no standardized method to 1371 block such misbehaving UEs. 1373 11. Summary and Conclusion 1375 The 3GPP network architecture and specifications enable the 1376 establishment of IPv4 and IPv6 connections through the use of 1377 appropriate PDP context types. The current generation of deployed 1378 networks can support dual-stack connectivity if the packet core 1379 network elements such as the SGSN and GGSN have the capability. With 1380 Release-8, 3GPP has specified a more optimal PDP context type which 1381 enables the transport of IPv4 and IPv6 packets within a single PDP 1382 context between the UE and the gateway. 1384 As devices and applications are upgraded to support IPv6 they can 1385 start leveraging the IPv6 connectivity provided by the networks while 1386 maintaining the fall back to IPv4 capability. Enabling IPv6 1387 connectivity in the 3GPP networks by itself will provide some degree 1388 of relief to the IPv4 address space as many of the applications and 1389 services can start to work over IPv6. However without comprehensive 1390 testing of different applications and solutions that exist today and 1391 are widely used, for their ability to operate over IPv6 PDN 1392 connections, an IPv6-only access would cause disruptions. 1394 12. Acknowledgements 1396 The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, 1397 Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Wes George, Martin 1398 Thomson, Russ Mundy, Cameron Byrne, Ales Vizdal, Frank Brockners, 1399 Adrian Farrel, Stephen Farrell, and Jari Arkko for their reviews and 1400 comments on this document. 1402 13. Informative References 1404 [GSMA.IR.34] 1405 GSMA, "Inter-PLMN Backbone Guidelines", GSMA 1406 PRD IR.34.4.9, March 2010. 1408 [I-D.ietf-dhc-pd-exclude] 1409 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1410 "Prefix Exclude Option for DHCPv6-based Prefix 1411 Delegation", draft-ietf-dhc-pd-exclude-03 (work in 1412 progress), August 2011. 1414 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1415 E. Lear, "Address Allocation for Private Internets", 1416 BCP 5, RFC 1918, February 1996. 1418 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1419 RFC 2131, March 1997. 1421 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1422 and M. Carney, "Dynamic Host Configuration Protocol for 1423 IPv6 (DHCPv6)", RFC 3315, July 2003. 1425 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 1426 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 1427 Second and Third Generation Cellular Hosts", RFC 3316, 1428 April 2003. 1430 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1431 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1432 December 2003. 1434 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1435 (DHCP) Service for IPv6", RFC 3736, April 2004. 1437 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1438 Proxies (ND Proxy)", RFC 4389, April 2006. 1440 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1441 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1442 September 2007. 1444 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1445 Address Autoconfiguration", RFC 4862, September 2007. 1447 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1448 Extensions for Stateless Address Autoconfiguration in 1449 IPv6", RFC 4941, September 2007. 1451 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1452 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1454 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1455 IPv4/IPv6 Translation", RFC 6144, April 2011. 1457 [TR.23975] 1458 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, 1459 June 2010. 1461 [TS.23003] 1462 3GPP, "Numbering, addressing and identification", 3GPP 1463 TS 23.003 10.2.0, June 2011. 1465 [TS.23060] 1466 3GPP, "General Packet Radio Service (GPRS); Service 1467 description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. 1469 [TS.23203] 1470 3GPP, "Policy and charging control architecture (PCC)", 1471 3GPP TS 23.203 8.11.0, September 2010. 1473 [TS.23401] 1474 3GPP, "General Packet Radio Service (GPRS) enhancements 1475 for Evolved Universal Terrestrial Radio Access Network 1476 (E-UTRAN) access", 3GPP TS 23.401 10.4.0, June 2011. 1478 [TS.23402] 1479 3GPP, "Architecture enhancements for non-3GPP accesses", 1480 3GPP TS 23.402 10.5.0, September 2011. 1482 [TS.24008] 1483 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 1484 TS 24.008 8.12.0, December 2010. 1486 [TS.24301] 1487 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1488 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1490 [TS.29002] 1491 3GPP, "Mobile Application Part (MAP) specification", 3GPP 1492 TS 29.002 9.5.0, June 2011. 1494 [TS.29060] 1495 3GPP, "General Packet Radio Service (GPRS); GPRS 1496 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1497 3GPP TS 29.274 8.8.0, April 2010. 1499 [TS.29061] 1500 3GPP, "Interworking between the Public Land Mobile Network 1501 (PLMN) supporting packet based services and Packet Data 1502 Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. 1504 [TS.29274] 1505 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1506 Packet Radio Service (GPRS) Tunnelling Protocol for 1507 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 1508 December 2010. 1510 [TS.33102] 1511 3GPP, "3G Security; Security architecture", 3GPP 1512 TS 33.102 10.0.0, December 2010. 1514 [TS.33401] 1515 3GPP, "3GPP System Architecture Evolution (SAE); Security 1516 architecture", 3GPP TS 33.401 10.1.1, June 2011. 1518 Authors' Addresses 1520 Jouni Korhonen (editor) 1521 Nokia Siemens Networks 1522 Linnoitustie 6 1523 FI-02600 Espoo 1524 FINLAND 1526 Email: jouni.nospam@gmail.com 1528 Jonne Soininen 1529 Renesas Mobile 1530 Porkkalankatu 24 1531 FI-00180 Helsinki 1532 FINLAND 1534 Email: jonne.soininen@renesasmobile.com 1536 Basavaraj Patil 1537 Nokia 1538 6021 Connection drive 1539 Irving, TX 75039 1540 USA 1542 Email: basavaraj.patil@nokia.com 1544 Teemu Savolainen 1545 Nokia 1546 Hermiankatu 12 D 1547 FI-33720 Tampere 1548 FINLAND 1550 Email: teemu.savolainen@nokia.com 1551 Gabor Bajko 1552 Nokia 1553 323 Fairchild drive 6 1554 Mountain view, CA 94043 1555 USA 1557 Email: gabor.bajko@nokia.com 1559 Kaisu Iisakkila 1560 Renesas Mobile 1561 Porkkalankatu 24 1562 FI-00180 Helsinki 1563 FINLAND 1565 Email: kaisu.iisakkila@renesasmobile.com