ETSI TR V (201

Transcription

1 TR V ( ) TECHNICAL REPORT Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IPv6 migration guidelines (3GPP TR version Release 13)

2 1 TR V ( ) Reference RTR/TSGS vd00 Keywords GSM,LTE,UMTS 650 Route des Lucioles F Sophia Antipolis Cedex - FRANCE Tel.: Fax: Siret N NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at If you find errors in the present document, please send your comment to one of the following services: Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of. The content of the PDF version shall not be modified without the written authorization of. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute All rights reserved. DECT TM, PLUGTESTS TM, UMTS TM and the logo are Trade Marks of registered for the benefit of its Members. 3GPP TM and LTE are Trade Marks of registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.

3 2 TR V ( ) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR : "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server ( Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding deliverables. The cross reference between GSM, UMTS, 3GPP and identities can be found under Modal verbs terminology In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the Drafting Rules (Verbal forms for the expression of provisions). "must" and "must not" are NOT allowed in deliverables except when used in direct citation.

4 3 TR V ( ) Contents Intellectual Property Rights... 2 Foreword... 2 Modal verbs terminology... 2 Foreword... 5 Introduction Scope References Definitions, symbols and abbreviations Definitions Abbreviations Baseline Architecture for IPv4 and IPv6 Co-existence IPv6 migration scenarios Scenario 1: Dual-stack connectivity with Limited Public IPv4 Address Pools Scenario 2: Dual Stack connectivity with Limited Private IPv4 Address Pools Scenario 3: UEs with IPv6-only connection and applications using IPv Scenario 4: IPv4 applications running on a Dual-stack host with an assigned IPv6 prefix and a shared IPv4 address and having to access IPv4 services High level requirements Solutions and functional flows description Solution 1 Dual-stack deployment combined with NAPT Overview Description Functional Description Information flows Evaluation Applicability Transition Solution: Gateway-Initiated Dual-Stack Lite GI-DS-lite Overview GI-DS-lite Evaluation GI-DS-lite Applicability Solution 3 - MS/UE IPv6-only deployment with stateful NAT64 support Overview Description Functional Description Server Flow Example Evaluation Applicability Evaluation Summary Recommendations Annex A: Reference Scenarios for NAT in the EPC A.1 UE and AF In the same Address Realm A.2 NAT between UE and AF A.2.1 Overlapping IPv4 address realms Annex B: Overview of Solutions for IPv6 Transition... 28

5 4 TR V ( ) B.1 Solution 1 - Dual-Stack Lite Architecture B.1.1 Solution 1 Description B Plain IPv6 encapsulation in 3GPP architecture B GRE encapsulation B GTP encapsulation B DSMIP B.2 Solution 2 - A+P architecture B.2.4 Port Range Router (PRR) function B General B PRR in binding mode B PRR in stateless mode B.2.6 Requirement on UEs B.2.7 Updating legacy UEs B.2.8 Co-existence with other transition techniques B.2.9 Applicability B.2.10 Evaluation B.3 Solution 3 - Protocol translation B.4 Solution 4 - Per-interface NAT B.4.1 Overview B.4.2 Evaluation B.4.3 Applicability B.5 Void B.6 Void B.7 Solution 7 - BIH/NAT B.7.1 Overview B.7.2 Solution Description B.7.3 Service Flow Example B.7.4 Evaluation B.7.5 Applicability Annex C: Building Block: Dual-Stack EPS Bearer Contexts in EPS/GPRS C.1 Description C.2 Functional Description C.3 Information flows C.4 Applicability Annex D: Change history History... 42

6 5 TR V ( ) Foreword This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of Release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction With the depletion of IPv4 addresses and the development of data service, demands for deploying IPv6 are higher than before. This document analyzes different IPv6 migration scenarios and applicable mechanisms as well as identifies impacts on 3GPP network elements.

7 6 TR V ( ) 1 Scope The technical report identifies various scenarios of transition to IPv6 and co-existence of IPv4 and IPv6, deployment options and impacts on 3GPP network elements. In particular: - Identify the transition and co-existence scenarios of interest for operators and the respective assumptions and requirements. - Analyze existing IP address allocation mechanism for IPv6 migration if necessary. - Investigate IPv6 transition mechanisms for the scenarios identified during the study and investigate their applicability for 3GPP network, and identify the compatibility among applicable transition mechanisms. - Identify any impact on 3GPP network elements. - Provide recommendations on IPv6 transition and co-existence of IPv4 and IPv6 and identify if any normative work is needed. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TR : "Vocabulary for 3GPP Specifications". [2] [3] [4] [5] [6] [7] [8] [9] 3GPP TS : "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access". [10] 3GPP TS : "Architecture enhancements for non-3gpp accesses". [11] 3GPP TS : "General Packet Radio Service (GPRS) Service description; Stage 2". [12] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-stack Lite broadband deployments post IPv4 exhaustion", IETF draft, draft-ietf-softwire-dual-stack-lite-07 (work in progress). [13] Brockners, F., Gundavelli, S., Speicher, S., Ward, D. "Gateway Initiated Dual-Stack Lite Deployment", draft-ietf-softwire-gateway-init-ds-lite-03 (work in progress).

8 7 TR V ( ) [14] 3GPP TR "Interworking aspects and migration scenarios for IPv4 based IMS implementations". [15] [16] [17] IETF Internet-Draft, draft-ietf-behave-v6v4-xlate-stateful-12: " NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers" work in progress. [18] IETF Internet-Draft, draft-ietf-behave-dns64-05: "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers "work in progress. [19] IETF Internet-Draft, draft-arkko-dual-stack-extra-lite-05: "Scalable Operations of Address Translators with Per-Interface Bindings", work in progress. [20] IETF RFC 4364: "BGP/MPLS IP Virtual Private Networks (VPNs)". [21] 3GPP TS : 'Policy and charging control architecture'. [22] IETF Internet-Draft, draft-boucadair-behave-ipv6-portrange: "Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage" work in progress. [23] IETF Internet-Draft, draft-boucadair-behave-bittorrent-portrange-02: "Behaviour of BitTorrent service in an IP Shared Address Environment" work in progress. [24] Haverinen, H., Siren, J., and P. Eronen, 'Energy Consumption of Always-On Applications in WCDMA Networks', VTC'07-Spring, Dublin Ireland, April NOTE: The Italicised references are individual IETF drafts which have not yet been endorsed by IETF working groups. 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in TR [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR [1]. NAT: A function which provides NAT44, NAPT44, NAT64, NAPT64 or combinations of these. Attachment circuit: as used by RFC 4364 [20], term to refer generally to means of attaching to a router, such as: PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, Ethernet interfaces, Virtual Local Area Networks (VLANs) on Ethernet interfaces, GRE tunnels, Layer 2 Tunnelling Protocol (L2TP) tunnels, IPSec tunnels, etc. An attachment circuit identifies uniquely the MPLS VPN used by all traffic using that circuit. CE: as used by RFC 4364 [20], stands for Customer Edge router or Customer Edge device. It represents an IP device using a BGP/MPLS IP Virtual Private Networks (VPN) to communicate with other CE devices using the same VPN, without the need to be routing peers of each other and without visibility of MPLS or the MPLS backbone providing connectivity between CEs in different sites. CEs are connected to PEs using attachment circuits. If CEs use dynamic routing protocols (CE routers) to route traffic in the VPN, then they are routing peers of the directly attached PEs. PE: as used by RFC 4364 [20], stands for Provider Edge router. PEs use MPLS to tunnel traffic among each other enabling IP traffic between the CEs attached to them.

9 8 TR V ( ) 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR [1]. NAPT44 NAT44 NAPT64 NAT64 PCC Network Address and Port Translation IPv4 to IPv4 Network Address Translation IPv4 to IPv4 Network Address and Port Translation IPv6 to IPv4 Network Address Translation IPv6 to IPv4 Policy and Charging Control 4 Baseline Architecture for IPv4 and IPv6 Co-existence This clause describes how dual-stack connectivity has been specified for the EPS and GPRS networks. The Release 8 3GPP EPS architecture supports and optimises the co-existence of IPv4 and IPv6 with dual-stack operation. Dual-stack operation means that native IPv4 and native IPv6 packets are transported in parallel by tunnelling them from the UE to the PDN GW within a single EPS bearer/pdp context. This dual-stack EPS bearer/pdp context is associated with both an IPv4 address and an IPv6 prefix. In comparison, dual stack connectivity to a given PDN in the pre-release 9 GPRS network (with Gn/Gp SGSN and/or GGSN elements) requires the activation of two parallel PDP contexts, one for IPv4 traffic and one for IPv6 traffic. It should be noted that these parallel PDP contexts enable the same dual-stack connectivity for an application as the dualstack EPS Bearers/PDP Contexts in the Release 8 EPS. Dual-stack PDP Context UTRAN/ GERAN Dual-stack EPS Bearer SGSN HSS S3 S1-MME MME S6a S11 LTE-Uu S10 S4 UE E-UTRAN S1-U S GW S12 S5 (Gx) PDN Gateway (PCRF) SGi (Rx) Operator's IP Services (Rx); Other IP services Figure 4.1: EPS Non-roaming architecture for 3GPP accesses in Release 8 Figure 4.1 depicts the Release 8 3GPP reference architecture for EPS according to TS [9]. Upon request from the UE, the MME and S4-SGSN can activate a dual-stack EPS bearer/pdp context, which is identified in signalling by the PDN/PDP type 'v4v6'. A dual-stack EPS bearer tunnels IPv4 and IPv6 traffic in parallel from the UE to PDN GW. In order to support dual-stack connectivity where possible, it has been specified in the Release 8 EPS specifications TS [9], TS [11], that if a Release 8 UE/MS supports both IPv4 and IPv6, the UE/MS shall always start off by requesting for a dual-stack (PDN/PDP type v4v6) bearer. It is also assumed that the UE/MS has no knowledge of the IPv4 and/or IPv6 capabilities of a given PDN. Neither does the UE/MS have any awareness of whether dual-stack bearers/ contexts are supported by the network to which it is attaching. In Release 8, the EPS control plane elements (MME, S4-SGSN) and user plane elements (SGW, PGW) are all able to identify and handle requests to activate a dual-stack bearer/ context, and to enforce the type of bearers/ contexts that are allocated to the UE/MS. The network may downgrade the request for the PDN/PDP type v4v6 if a given PDN supports/allows only one of the address types (i.e. IPv4 or IPv6) as configured in the HSS. This limitation may stem from an operator policy. Another reason for downgrading may be that there are Gn/Gp SGSNs in the operator's network that have not been upgraded to support the PDP type 'v4v6'. The outcome of a PDN/PDP Type request depends on HSS provided subscription data, PGW configuration and home (and possibly visited) network core configuration. Any of these factors may downgrade the request to a single address type.

10 9 TR V ( ) The EPS interworking architecture for Gn/Gp SGSNs is shown in Figure 4.2. UTRAN/GERAN S1-MME Gn/Gp SGSN Gn MME S11 Gr S6a Single-stack PDP contexts OR Dual-stack PDP Context (R9) Gn HSS (Gx) (PCRF) (Rx) UE E-UTRAN S1u Single-stack EPS Bearers OR Dual-stack EPS Bearer (R9) S5 SGW PGW SGi Operator IP Services(Rx); Other IP Services Figure 4.2: EPS Non-roaming Architecture for interoperation with Gn/Gp SGSNs in Rel-8 Dual stack PDP context support for the GPRS core network (GGSN, Gn/Gp SGSN) is specified in Release 9. To use this functionality a MS need to support Release 8 or higher (same as S4-SGSN access in EPS) in order to successfully request a PDP type 'v4v6' connection in UTRAN/GERAN. A pre-release 9 Gn/Gp SGSN handles PDP type 'v4v6' as an 'unknown' PDP type, meaning that it handles a request for the PDP type 'v4v6' as if it were a request for the PDP type 'v4'. NOTE 1: The 3GPP specification TS is not entirely unambiguous on the treatment of unknown PDP types. Even if the information element coding for "PDP type" specifies that a request for an "unknown PDP type" shall be treated as if it were a request for PDP type v4, the error signalling elsewhere in the specification include the possibility to signal an error code "unknown PDP address or PDP type". In order to support inter-rat mobility to/from a pre-release 9 Gn/Gp SGSN, parallel v4 and v6 bearers/pdp contexts to a given PDN must to be used instead of dual-stack contexts. The request to activate two parallel single stack bearers/pdp contexts is always initiated by the UE/MS. If the Release 8 network assigns a single-stack bearer to the UE/MS in response to a request for a dual-stack bearer, the network also signals to the UE/MS an indication on whether parallel single stack bearers are allowed to the same PDN or not. If the UE/MS fails to activate a dual-stack bearer/context, and it receives a single-stack IPv4 or IPv6 bearer/context, it shall attempt to activate a parallel single-stack bearer/context for the other IP address type to the same PDN, unless the UE has received an explicit indication from the network that parallel single stack bearers/contexts are not allowed. In GPRS core networks, dual-stack connectivity is also possible with a pre-release 9 GGSN and SGSN. These network elements do not support dual-stack PDP contexts, but dual-stack usage may be possible by activating a parallel IPv4 PDP context and IPv6 PDP context to the same PDN. In order to establish dual-stack connectivity in this case, a dualstack UE shall attempt to open parallel single-stack v4/v6 PDP contexts to the same PDN even without receiving an explicit indication on support for parallel single stack bearers to the same PDN. For end-hosts, the activation and mobility of dual-stack bearers/ contexts is simpler in comparison to handling of parallel IPv4 and IPv6 bearers/contexts. The usage of dual stack bearers/ contexts also simplifies the handling of parallel IPv4 and IPv6 traffic within the network after early EPS deployment phase when SGSNs are upgraded to support the PDP type 'v4v6'. TR [14] describes a scenario where old SGSNs do not support PDP type IPv6. Considering the fact that PDP type IPv6 has been specified since R'97 and SGSNs shipped during the last couple of years have support for PDP type IPv6, the assumption is that all SGSNs support PDP type IPv6.

11 10 TR V ( ) 5 IPv6 migration scenarios 5.1 Scenario 1: Dual-stack connectivity with Limited Public IPv4 Address Pools In this IPv6 transition scenario, the operator runs the user plane in dual stack mode, i.e., the UEs are assigned both an IPv6 prefix and an IPv4 address in order to allow UEs to utilise both IPv4 and IPv6 capable applications. This scenario relies on the availability of dual-stack UEs, which are able to support parallel IPv4 and IPv6 connectivity to a single PDN. It is further assumed that the proportion of IPv6 capable applications will start to increase as soon as UEs and networks starts to become dual-stack capable. As popular services start to support IPv6, a part of IPv4 traffic will gradually be offloaded into the IPv6 domain. Services that are operator owned and deployed (for example LTE voice and other IMS based services) could be IPv6 enabled (in addition to IPv4) and hence accessible by the dual-stack capable UEs. During transition phase, the depletion of public IPv4 addresses may become an issue in some operators' networks. The lack of public IPv4 address availability in the near future will inhibit the growth of data services and mobile broadband networks. The shortage of public addresses will be aggravated by always-on packet data connectivity, which is expected to prevail in newer network deployments. To alleviate the shortage of public IPv4 addresses, the usage of private IPv4 addresses can be considered (e.g. the RFC 1918 addresses). The utilisation of private IPv4 addresses should not require new procedures to be specified for the UE in order to ensure maximum applicability in a network with an early dual-stack UE population. 5.2 Scenario 2: Dual Stack connectivity with Limited Private IPv4 Address Pools This migration scenario is based on the Dual stack model: The operator assigns both an IPv6 prefix and an IPv4 address to UEs in order to ensure that both IPv4 and IPv6 capable applications can be utilised. The IPv4 addresses assigned to UEs are taken from one of the private address ranges as specified in RFC To enable global connectivity, network address translation (NAT) is performed on the (S)Gi interface for IPv4 packets originated from or destined to the UEs. NOTE: Depletion of public IPv4 addresses while transitioning to IPv6 might be one reason for operators to assign private as opposed to public IPv4 addresses to UEs. The challenge of this scenario lies in the limited number of private IP addresses. In case more than 16 million UEs are active (i.e. have an active PDP context/eps bearer) in the same network at the same time, the network will run out of private IPv4 addresses. In order to avoid this, the operator may have to consider assigning the same IPv4 address to multiple UEs. Nevertheless, the operator expects that legacy IPv4 applications continue to work in this situation. When defining solutions for this scenario, it additionally needs to be taken into account that in existing deployments some operators currently use the private IPv4 address assigned to a given UE to identify the respective customer (note that for this reason private IPv4 addresses are currently unique within these networks). Therefore, a solution for this scenario needs to ensure that IPv4 flows on the Gi interface can be uniquely traced back to a given UE/customer. 5.3 Scenario 3: UEs with IPv6-only connection and applications using IPv6 The operator decides to only assign IPv6 prefixes to the UEs due to e.g. shortage of IPv4 addresses or to address use cases, in which it appears beneficial - from an operational perspective - to only assign IPv6 addresses (e.g. m2m scenarios). UEs with IPv6-only connectivity running applications using IPv6 should however still be able to access both IPv4- or IPv6-enabled services. Based on this scenario description, two use cases need to be considered: 1) The UE, configured only with an IPv6 prefix, has to be able to access IPv4 services.

12 11 TR V ( ) 2) The UE, configured only with an IPv6 prefix, has to be able to access IPv6 services. 5.4 Scenario 4: IPv4 applications running on a Dual-stack host with an assigned IPv6 prefix and a shared IPv4 address and having to access IPv4 services In this scenario an IPv4 application running on a dual-stack UE requires to access IPv4 services without the operator having to allocate a unique non-shared (private or public) IPv4 address to the UE. The dual-stack UE running these applications uses an IPv4 address that is shared amongst many other UEs, and uses an IPv6 prefix. 6 High level requirements The high-level requirements are to cover all the scenarios described in clause 5 in roaming and non-roaming cases. The IPv6 migration architecture should take into consideration any possible impacts to the policy architecture. 7 Solutions and functional flows description 7.1 Solution 1 Dual-stack deployment combined with NAPT Overview Enabling MS/UE dual stack communication and moving traffic from IPv4 to IPv6 can achieve a significant reduction of the number of dedicated public IPv4 addresses assigned to a NAPT44. Public IPv4 are assigned to the NAPT44 for the purpose of sharing this resource among several users at a specific ratio determined by the number of ports dynamically available to a single user as calculated by the operator. Real port usage is determined by the user applications and their need for connections which could range from one to several thousands per user. Offloading these IPv4 resources by moving the traffic to IPv6 will end up freeing a significant amount of public IPv4 addresses that can be used elsewhere in the operator network. The use of traditional NAT has a size limitation due to the maximum 16 million available RFC1918 private IPv4 addresses. The description below depicts possible solutions to how the operational impact of this limitation can be overcome Description Dual-stack deployment MS/UE attaches to network APN(s) using applicable procedures described in TS [9], TS [10] and TS [11] in order to get dual stack connectivity to Internet (IPv4 and IPv6). The operator assigns private IPv4 addresses to the UEs and uses NAPT44 to provide access to the Internet. The operator may multiplex multiple UEs onto a single public IPv4 address using traditional NAPTs. The operator assigns IPv6 prefixes to the UEs allowing native IPv6 access to the Internet. The MS/UE will now use IPv6 to communicate with dual stack reachable services/peers and thus offloading the NAPT44 assigned public IP address/ports resources that would have been made available for the UE if it not had been able to use IPv6. When communicating with Services/peers only served by IPv4, the UE/MS will use NAPT44 resources to enable communication. During the co-existence phase of the IPv6 migration, more IPv4 traffic will be offloaded from the NAPT44 as more and more services/peers become dual stack reachable or complete the transition and become IPv6 only reachable.

13 12 TR V ( ) NAPT44 deployment options Basic deployments Typically, a single physical PDN-GW can serve an order of few million UEs in maximum. As the amount of traffic per user increases it is not expected that there will be a major increase in this number. Therefore, we can expect a single PGW can hardly ever reach the point where a PDN-GW would need to hand out more than 16 million RFC 1918 addresses. It looks evident for time being that a single or even a small cluster of PGWs implementing collocated NAPT44 functions should not run out of RFC 1918 addresses for one APN. Figure illustrates a deployment discussed here. UE RFC 1918 IPv4 addresses ^'t PGW & Per APN NAPT44 Public IPv4 & Internet Figure 7.1.1: NAPT44 collocated in a PDN-GW for each APN In a case multiple PDN-GWs serve a single RFC 1918 addressed PDN identified by a single APN, the RFC 1918 address space must be partitioned so that overlapping does not happen between PDN-GWs serving the PDN. This is a pure address management issue and illustrated in Figure PGWs APN xyz /10 UE RFC 1918 IPv4 addresses SGW APN xyz /10 APN xyz /10 Private RFC 1918 Addressed PDN 10.x.x.x/8 NAPT44 Public IPv4 & Internet APN xyz /10 Figure 7.1.2: Private RFC 1918 addressed PDN with multiple PDN-GWs and non-overlapping address spaces Deployments with overlapping RFC 1918 address spaces However, it is also possible that multiple PDN-GWs serving the same APN would go beyond 16 million RFC 1918 addresses. In this situation the APN has to be partitioned into independent PDNs with overlapping RFC 1918 address spaces. This is a pure network deployment issue. In this deployment model the NAPT44 functionality can be located either in a PDN-GW or at the edge of the RFC 1918 addressed PDN and the public Internet. The model where NAPT44 functionality is collocated in a PDN-GW is illustrated in Figure

14 13 TR V ( ) PGW & APN xyz, NAPT /8 UE RFC 1918 IPv4 addresses SGW PGW & APN xyz, NAPT /8 Public IPv4 & Internet PGW & APN xyz, NAPT /8 Figure 7.1.3: Overlapping RFC 1918 address spaces for the same APN and NAPT44 collocated with a PDN-GW The deployment model where the APN has been partitioned multiple independent PDNs is illustrated in Figure 4. Here the NAPT44 functionality is distributed between each independent & private RFC 1918 PDN and the public Internet. PGW & APNxyz /8 Private RFC 1918 Addressed PDN 10.x.x.x/8 NAPT44 UE RFC 1918 IPv4 addresses SGW PGW & APNxyz /8 Private RFC 1918 Addressed PDN NAPT44 10.x.x.x/8 Public IPv4 & Internet PGW & APN xyz /8 Private RFC 1918 Addressed PDN NAPT44 10.x.x.x/8 Figure 7.1.4: Overlapping RFC 1918 address spaces for the same APN and distributed NAPT Identity considerations when using overlapping RFC 1918 address spaces If a PLMN needs to provide more than 16 million RFC 1918 addresses to its own subscribers, and wants to correlate a private RFC 1918 address to a specific UE, then additional functionality would be needed. This deployment model is actually the same what was already illustrated in Figure and If the service infrastructure needs to distinguish between subscribers with overlapping RFC1918 addresses but still only compare IP addresses, then the comparison has to include additional information or be context aware of the source of the used RFC1918 pool. For example, beyond knowledge of the NAT binding state to derive the private IPv4 address, the comparison could also take the public IP address of the GGSN/PGW into account where the NAPT44 takes place. If there need to be traffic inspecting devices within each PDN of Figure 4 with overlapping RFC1918 addresses then the IP address of the traffic inspecting device could be used to identify the PDN where the RFC1918 pool belongs to. Other solutions are also possible. If needed, a unique identity may be tied to the user packets on the outer/external/public address side of the NAT. This can be arranged, as an example, by using packet encapsulation where a unique identifier is included either in the packet encapsulation information or in the source address of the encapsulating packet Functional Description The MS/UE need to obtain dual stack connectivity in order to be able to reach both IPv4 and IPv6 services/peers. This can be arranged either by using a dual stack connection by requesting a connection of PDP Type IPv4v6 or PDN Type IPv4v6 depending on radio access technology and MS/UE capability. If these dual stack are not possible to obtain it is also possible to request two separate connections, one PDP context/pdn connection Type IPv4 and one PDP context/pdn connection Type IPv6 in parallel to the same dual-stack APN. The preferred way would be to use only one connection for both IP versions but the two connection approach could be used due when ether MS/UE or core does not allow for a single dual stack PDP context connection to be established.

15 14 TR V ( ) The following table lists the basic requirements for this scenario in an IP version co-existence phase referencing the user plane capabilities only. Table 7.1.1: IPv4 offload requirements Basic Components Name States PDP/PDN Types Terminal IP capability Dual stack (IPv6 preferred over IPv4 if both can be used for a remote endpoint) IPv4v6, IPv4 and IPv6 (NOTE 1) Type of application program Dual stack capable not applicable Type of assigned IP address, IPv4 and IPv6 not applicable Subscriber IP capability Dual stack APN in subscriber data IPv4v6, IPv4 and IPv6 Network IP capability Dual stack network IPv4v6, IPv4 and IPv6 (NOTE 2) Service/peer capability Dual stack (NOTE 3) not applicable The GGSN/PDN GW IPv4 Internet connectivity is provided over a NAPT44 solution either co-located with the GGSN/PDN GW or elsewhere placed in the operator network. NOTE 1: To be able to use PDP/PDN Type IPv4v6 the MS/UE need to be Release 8 or later NOTE 2: To be able to serve PDP/PDN Type IPv4v6 the core nodes need to be Release 8 or later except for SGSN/GGSN using Gn/Gp need to be Release 9 NOTE 3: If DNS is to be used to resolve the service/peer FQDN into an IP address the node DNS information need to contain both A and AAAA record entries for the service/peer Information flows See TS [11], TS [9] and TS [10] for the appropriate information flow details Evaluation The solution assumes that Internet content/services start becoming dual-stack capable and thus available via IPv6. The presented NAPT44 based solution and few other considerations are sufficient to support the migration period, more specifically to address the problems of limited private IPv4 address space. The 3GPP community should consider influencing major Internet content/service providers to make their services available via IPv6 in a user friendly manner. Offloading some traffic to IPv6 reduces the amount of active connections required in the NAPT44. This reduces the scalability issues with NAT and the number of public IPv4 addresses/ports needed to serve the UEs. Known issues of the solution: - The session binding between private and public IPv4 address/port is not known to the PCC architecture. Therefore, depending on deployment and if the application is NAT aware and has access to the binding (as e.g. in the case of IMS), there may or may not be issues with applying PCC to the session. - General NAT concerns, not specific to 3GPP networks, apply. For example, applications that embed IP addresses in the payload and are not NAT aware require additional functionality to work across NATs. Known benefits of the solution - This solution requires no changes to UEs, it can be used with legacy dual-stack UEs. - This solution has no impact to the 3GPP network architecture, no new interface or network element is needed. It can be deployed without any additional normative specification within 3GPP. The limitations described under 'known issues' above apply. - This solution does not introduce any additional tunnelling overhead on any interfaces. - This solution with the appropriate deployment supports UEs with overlapping address space, thus there is no limitation of the number of subscribers. - Support for UEs with public, private, and overlapping private IPv4 addresses. If so desired, all the UE's in the mobility domain can be assigned the same IPv4 private address.

16 15 TR V ( ) - No changes to the IPv4 / IPv6 address-assignment procedures required. - No bearing on the type of transport network: Transport network can be IPv4 or IPv6. - NAPT44 can be either co-located or separate from GGSN/PDN-GW. - Solution to the public IPv4 address exhaustion problem through the use of NAPT44. - Solution to the private IPv4 address exhaustion problem through the use of overlapping private IPv4 addresses. - This solution does not have any impact on the UE's roaming support. - No impact on QoS/bearer procedures between UE and PDN GW/SGW/GGSN Applicability This solution applies to scenario 1. This approach also suggests solutions to address scenario 2. Given the solution description above, the described functionality can be configured in currently deployed mobile networks as well as in future deployments regardless of 3GPP access technology. When to deploy such a setup in an operator's network is more of a business and operational decision. 7.2 Transition Solution: Gateway-Initiated Dual-Stack Lite GI-DS-lite Overview Gateway-Initiated Dual-Stack Lite [13] (GI-DS-lite) is a modified approach of the DS-Lite concept. The GI-DS-lite concept applies to EPC as well as GPRS. For reasons of simplicity, this clause uses EPC nomenclature. GPRS applies in a similar way. GI-DS-Lite builds on top of the current dual-stack deployment model of the 3GPP architecture which supports dualstack UEs and uses tunnelling technology between the Serving Gateway and the PDN Gateway, over GTP or PMIPv6 based S5/S8 interfaces, and between the UE and the PDN Gateway over the S2c interface. GI-DS-Lite lifts some of the restrictions of the DS-lite solution: - Carrier Grade NAPT (CGN) does not need to be co-resident with PDN-Gateway. - No added overhead for IPv4 user plane traffic transport on the airlink. - Support of IPv4 and IPv6 transport networks. - Support for deployments with public, private, and overlapping IPv4 addresses on the UEs. - No UE changes mandated for any of the deployment scenarios. With GI-DS-Lite, UE and access architecture remain unchanged. PDN Gateway and CGN are connected through a 'softwire' identified by a Softwire ID (SWID). The SWID does not need to be globally unique, i.e. different SWIDs could be used to identify a softwire at the different ends of a tunnel. A Context-Identifier (CID) is used to multiplex flows associated with the UE onto the softwire tunnel. Local policies at the PDN Gateway determine which part of the traffic received from an UE is sent via a softwire to the CGN. The combination of CID and SWID serves as common context between PDN Gateway and CGN to identify flows associated with an UE. The CID is typically a 32-bit wide identifier assigned by the gateway. It is retrieved either from a local or remote (e.g. AAA) repository. The CID ensures a unique identification (potentially along with other traffic identifiers such as e.g. interface, VLAN, port, etc.) of traffic flows at the Gateway and CGN. The embodiment of the CID and SWID depends on the technology used and the type of the network connecting PDN Gateway and CGN. If, for example GRE [RFC2784] with 'GRE Key and Sequence Number Extensions' [RFC2890] is used as softwire technology, the network connecting PDN Gateway and CGN could be either IPv4-only, IPv6-only, or a dual-stack IP network. The GRE-key field represents the CID.

17 16 TR V ( ) In case of MPLS VPN, RFC 4364 [20] used between PDN Gateway and CGN, the softwire identification is supplied by the VPN identifier of the MPLS VPN, whereas the IPv4 address serves as CID. Depending on if the PDN Gateway and CGN are connected as CEs or PEs, the VPN identifier could e.g. be an attachment circuit identifier (e.g.. a VLAN tag), a representation of the VPN route labels pointing to routes within the VPN, the VPN route distingisher etc. The combination of CID and SWID ensures a unique identification (potentially along with other traffic identifiers such as e.g. interface, VLAN, port, etc.) for traffic flows at the CGN, which should be associated with a single NAT-binding. Deployment dependent, the CID can also be used as an identifier for traffic flows or UEs in backend systems: Deployments which use non-overlapping private IPv4 addresses for the UE could e.g. choose to map private IPv4 addresses 1:1 to the CID. In a GI-DS-Lite deployment, the CGN combines DS-Lite softwire termination and NAT44. The outer/external IPv4 address of a NAT-binding at the CGN is either assigned autonomously by the CGN from a local address pool, configured on a per-binding basis (either by a remote control entity through a NAT control protocol or through manual configuration), or derived from the CID (e.g. the 32-bit CID could be mapped 1:1 to an external IPv4-address). The choice of the appropriate translation scheme for a traffic flow can take parameters such as destination IP-address, incoming interface, etc. into account. The IP-address of the CGN, which, depending on the transport network between the PDN Gateway and the CGN, will either be an IPv6 or an IPv4 address, is configured on the gateway. A variety of methods, such as out-of-band mechanisms, or manual configuration apply. ^'t hd D d ^ / d / d Eddd Eddd W't 'E Figure 7.2.2a: Gateway-Initiated Dual-Stack Lite deployment scenario Figure 7.2.2a shows an example of Gateway-Initiated DS-Lite applied to the EPC architecture when S5 or S8 interfaces are used. The PDN Gateway associates the mobility tunnels with the DS-Lite softwire to facilitate traffic forwarding to and from the CGN. ^D/W ed d hd hd ^ / d / d Eddd Eddd W' W't 'E Figure 7.2.2b: Gateway-Initiated Dual-Stack Lite deployment scenario over S2c Figure 7.2.2b shows an example of Gateway-Initiated DS-lite applied to the EPC architecture when the S2c interface is used. The PDN Gateway associates the mobility tunnels with the softwire to facilitate traffic forwarding to and from the CGN. In its simplest form, there could be a 1:1 relationship between mobile access tunnels (e.g. identified by a TEID or the DSMIPv6 HNP) and a combination of CID and SWID identifying the softwire facing the CGN resulting in a simple tunnel-stitching operation on the PDN Gateway. Deployment dependent (e.g. for deployments which use nonoverlapping private IP addresses on the UEs), the PDN Gateway could e.g. choose to only send Internet-bound traffic to the CGN - and route internal traffic locally.

18 17 TR V ( ) GI-DS-lite Evaluation Impact on the existing architecture: The following capabilities are used to support GI-DS-lite: - Softwire tunnelling on SGi, between the PDN Gateway and CGN, for instance: - GRE w/ GRE-key extensions (or alternative schemes, such as MPLS) tunnelling to/from the Carrier Grade NAT. - MPLS VPNs using attachment circuits according to RFC 4364 [20] between the PE devices and PDN Gateway, and between the PE devices and CGN. - MPLS VPNs using MPLS between PDN Gateway and CGN. The following capabilities are used to support GI-DS-lite using GRE: - Procedures for the PDN Gateway to support UE with overlapping IPv4 addresses - A tunnel with the appropriate encapsulation mode needs to be setup between the PDN Gateway and the CGN. It is established at the system startup time and is enabled based on the configuration. - PDN GW may assign overlapping private IPv4 addresses to all the UE's within that operational domain. - when overlapping IPv4 address assignment is supported and used in the softwire tunnel, the PDN GW shall associate the UE session with a CID. This identifier will be unique to the UE's PDN connection. - the PDN GW shall tunnel the IPv4 UE traffic using the appropriate encapsulation scheme on SGi to the CGN. It will use the CID associated with the UE's session. - CID management on the PDN Gateway - Maintenance of a CID key-space (possibly in conjunction with an external repository (e.g. AAA)). - PCC enhancements (to cover cases where the GRE-key would need to be used to identify IP-CAN sessions, which would be the case for deployments which use non-unique IP-addresses within the mobile domain and use the IP-address as IP-CAN session identifier). The following capabilities are used to support GI-DS-lite using MPLS VPNs: - PDN Gateway support for: - if deployed as CE, at least one type of attachment circuit according to RFC 4364 [20] - if deployed as combined CE and PE, MPLS VPNs according to RFC 4364 [20] - CGN support for: - if deployed as CE, at least one type of attachment circuit according to RFC 4364 [20] - if deployed as combined CE and PE, MPLS VPNs according to RFC 4364 [20] - Support for MPLS VPNs by the IP transport network connecting PDN Gateways and CGNs - Procedures for the PDN Gateway to support UE with overlapping IPv4 addresses - Support of different APNs with different routing/forwarding for each of them (different routing instances, or layer 2 binding to attachment circuits) Known issues of the solution: - If overlapping private IPv4 addresses are used within one operation domain for the UEs, all traffic needs to go through the CGN. This could potentially result in non-optimal communication patterns for the scenario of direct IPv4 communication between UEs that are attached to the same CGN.

19 18 TR V ( ) - GI-DS-lite involves the usage of NAT and therefore potential PCC issues due to NAT apply. Additional PCC issues may need to be considered for cases where meaningless or overlapping IPv4 addresses are used. Known issues of the GRE implementation: - GRE encapsulation overhead between the PDN Gateway and the CGN. - Deployment dependent (e.g. scenarios where all UEs are assigned the same address), enhancements to PCC may be required. Traffic between UEs connected to the same APN via different PDN-GWs needs to go through the CGN even if no overlapping IP addresses are used by those PDN-GWs, or alternatively PDN-GWs must be aware of each others UE IP address ranges used and tunnel traffic among each other. Known issues of the MPLS VPN implementation: - Overlapping IPv4 addresses are only supported between operational domains, i.e. using different MPLS VPNs, but not within the same VPN. - MPLS encapsulation overhead in the backbone. - MPLS has to be introduced in the IP network used as transport, if not deployed already. - If the PDN-GW or the CGN are deployed as CEs, attachment circuit overhead between PDN-GW or CGN and the backbone provider edge routers. - If the PDN-GW or CGN are deployed as CE, they may (deployment dependent) need to implement an appropriate routing protocol for CE-PE peering. - If the PDN-GW or the CGN are deployed as PEs: - MPLS overhead encapsulation overhead between each such node and the rest of the backbone - MP-BGP peering to all other PEs or to route reflectors, as well as MPLS encapsulation support in such nodes according to RFC 4364 [20] Known benefits of the solution: - Support for UEs with public, private, and overlapping private IPv4 addresses. - No changes to the UE required. - No changes to the IPv4 / IPv6 address-assignment procedures required. - The CGN can be placed on the service provide IPv4 network edge and is not required to be collocated with the PDN Gateway. - This solution does not introduce any additional tunnel overhead on the air-link, or on the access network for carrying the UE's IPv4 traffic. It leverages the tunnelling infrastructure existing between the UE and the PDN gateway. - Solution to the public IPv4 address exhaustion problem through the use of NAT44. The NAT44 function is only required at a single location within the architecture. - Solution to the private IPv4 address exhaustion problem through the use of overlapping private IPv4 addresses and softwires. - This solution does not have any impact on the UE's roaming support. - No impact on QoS/bearer procedures between UE and PGW/SGW. Known benefits of the GRE implementation: - If so desired, all the UE's in the mobility domain can be assigned the same IPv4 private address. - No bearing on the type of transport network: Transport network can be IPv4 or IPv6. This solution requires only a single IPv4 or an IPv6 transport tunnel between the PDN Gateway and the Carrier Grade NAT, with the GRE encapsulation mode. This single GRE tunnel is used for carrying all the IP traffic belonging to all

20 19 TR V ( ) the UEs supported on that PDN Gateway(i.e. the GRE-key is used to multiplex and differentiate traffic from multiple UEs onto the very same GRE-tunnel (which is identified by the addresses of the end-points)). Known benefits of the MPLS VPN implementation: - No additional tunnel overhead between the PDN-GW and CGN if MPLS is already deployed or only MPLS encapsulation on the backbone if not previously deployed. - By sharing the same MPLS VPN for the same APN by several PDN Gateways and CGNs, traffic between end-users can be sent directly without going via any CGN. - Different CGNs can be deployed in an MPLS VPN providing CGN redundancy by relaying on basic routing protocol mechanisms GI-DS-lite Applicability Gateway-initiated Dual-Stack Lite applies to the following IPv6 migration scenarios outlined in clause 5: - Scenario 1: Dual-stack connectivity with Limited Public IPv4 Address Pools - Scenario 2: Dual Stack connectivity with Limited Private IPv4 Address Pools 7.3 Solution 3 - MS/UE IPv6-only deployment with stateful NAT64 support Overview When deploying an MS/UE with IPv6-only connectivity it will be able to communicate with other IPv6 reachable servers and peers if they are either dual-stack or IPv6-only connected. Since the decision to deploy an IPv6-only communications model in many cases will be a unilateral decision, there may be a need for an IPv6 transition mechanisms designed to enable transition and to support IPv6-enabled hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. Introducing transition tools such as the functional elements DNS64 and NAT64 into the network will enable an IPv6-only MS/UE to communicate with IPv4-only reachable servers and peers Description MS/UE attaches to network APN(s) using applicable procedures described in TS [9], TS [10] and TS [11] in order to get IPv6 connectivity to Internet. The operator assigns IPv6 prefixes to the MS/UEs allowing native IPv6 access to IPv6 networks. The MS/UE is provisioned with DNS server address of the DNS64 server which is used to create and return synthetic AAAA records for a queried FQDN that would only return A records in a regular DNS lookup. The synthetic AAAA record is used by the MS/UE as a destination address effectively sending the packets to the NAT64 function which translates IPv6 packets to IPv4 packets and vice versa to enable the communication between the MS/UE and the IPv4-only destination Functional Description The MS/UE need to obtain IPv6 connectivity in order to be able to reach IPv6 services/peers including making queries to DNS and sending packets to NAT64. The DNS64 function needs dual-stack connectivity in order to perform DNS lookups and answer MS/UE DNS queries. The NAT64 function needs IPv6 and IPv4 connectivity to enable translated packet flows. The IPv4 Internet connectivity is provided over a NAT64 function either co-located with the GGSN/PDN GW or elsewhere placed in the network as show in the following figures.