Internet Draft J. Wiljakka, Document: draft-wiljakka-3gpp-ipv6-transition-00.txt Editor Expires: December 2002 Nokia June 2002 IPv6 Transition Solutions for 3GPP Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. Wiljakka, Editor Expires - December 2002 [Page 1] IPv6 Transition Solutions for 3GPP Networks June 2002 Table of Contents 1. Introduction..................................................2 1.1 Scope of this Document....................................3 1.2 Abbreviations.............................................3 1.3 Terminology...............................................4 2. Transition mechanisms.........................................4 2.1 Dual Stack................................................5 2.2 Tunneling.................................................5 2.3 Protocol translators......................................5 2.4 Other transition mechanisms...............................5 3. Brief introduction to the 3GPP network model..................6 4. GPRS Transition scenarios.....................................7 4.1 Dual Stack UE connecting to IPv4 and IPv6 nodes...........7 4.2 IPv6 UE connecting to an IPv6 node through an IPv4 network 8 4.3 IPv4 UE connecting to an IPv4 node through an IPv6 network 9 4.4 IPv6 UE connecting to an IPv4 node.......................10 4.5 IPv4 UE connecting to an IPv6 node.......................12 5. Transition Scenarios with IMS................................12 5.1 DNS interworking in IMS..................................14 5.2 UE connecting to a node in an IPv4 network through IMS...15 5.3 Two IPv6 IMS UEs connected via an IPv4 network...........16 6. Recommendations for transition methods in 3GPP networks and terminals.......................................................16 7. Security Considerations......................................17 8. References...................................................17 9. Authors and Acknowledgements.................................19 10. Editor's Contact Information................................20 1. Introduction This document describes and analyzes the process of transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. This document has been submitted as an individual contribution to the IETF Ngtrans Working Group. The design team members can be found in Authors and Acknowledgements section. This document is mainly based on discussion held in the design team meetings and does not yet contain complete and well-defined solutions to the 3GPP transition scenarios. The document aims to generate discussion on these issues - comments and feedback from the people in the IETF Ngtrans Working Group are appreciated. This document analyzes the transition scenarios in 3GPP packet data networks that might come up in the deployment phase of IPv6. The transition scenarios are documented in [3GPP-SCEN] and this document will further analyze those aiming to find solutions. They are divided into two categories: GPRS scenarios and IMS scenarios. GPRS scenarios are the following: Dual Stack UE connecting to IPv4 Wiljakka, Editor Expires - December 2002 [Page 2] IPv6 Transition Solutions for 3GPP Networks June 2002 and IPv6 nodes, IPv6 UE connecting to an IPv6 node through an IPv4 network, IPv4 UE connecting to an IPv4 node through an IPv6 network, IPv6 UE connecting to an IPv4 node and IPv4 UE connecting to an IPv6 node. Two IMS scenarios are: UE connecting to a node in an IPv4 network through IMS and two IPv6 IMS islands connected via an IPv4 network. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In the scenarios, the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet and IPv6/IPv4 transition mechanisms are needed. This document also gives a very brief overview of the 3GPP architecture. A wider overview of the 3GPP specified GPRS architecture can be found in [IPv6-3GPP]. The GPRS architecture specification is [3GPP-23.060]. 1.1 Scope of this Document The scope of this informational document is to describe, analyze and solve the possible transition scenarios in the 3GPP defined GPRS network where a UE connects to, or is contacted from the Internet, or another UE. The document describes scenarios with and without the use of the SIP based IP Multimedia Core Network Subsystem (IMS). This document is not focused on radio interface issues; both 3GPP Second (GSM) and Third Generation (UMTS) radio network architectures will be covered by these scenarios. The scope of this document does not include scenarios inside the GPRS network, i.e. on the different interfaces of the GPRS network. The transition mechanisms specified by the IETF Ngtrans Working Group shall be used. This document shall not specify any new transition mechanisms, but if a need for a new mechanism is found, this will be reported to the Ngtrans Working group. 1.2 Abbreviations 2G Second Generation Mobile Telecommunications, for example GSM and GPRS technologies. 3G Third Generation Mobile Telecommunications, for example UMTS technology. 3GPP Third Generation Partnership Project ALG Application Level Gateway APN Access Point Name. The APN is a logical name referring to a GGSN and an external network. CSCF Call Session Control Function (in 3GPP Release 5 IMS) GGSN Gateway GPRS Support Node (a default router for 3GPP Wiljakka, Editor Expires - December 2002 [Page 3] IPv6 Transition Solutions for 3GPP Networks June 2002 User Equipment) GPRS General Packet Radio Service GSM Global System for Mobile Communications IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IPv6-only part of the network NAT Network Address Translator NAPT-PT Network Address Port Translation - Protocol Translation NAT-PT Network Address Translation - Protocol Translation PDP Packet Data Protocol SIIT Stateless IPv4-IPv6 Translator SIP Session Initiation Protocol UE User Equipment, for example a UMTS mobile handset UMTS Universal Mobile Telecommunications System 1.3 Terminology In the transition scenarios and solutions, some terms are used. These terms are briefly defined here. Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual stack implemented. It is capable of activating both IPv4 and IPv6 PDP contexts. Dual stack UE may be capable of tunneling. IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is only capable of activating IPv6 PDP contexts. IPv4 UE IPv4 UE is an IP4-only 3GPP mobile handset. It is only capable of activating IPv4 PDP contexts. IPv4 node IPv4 node is here defined to be IPv4 capable node the UE is communicating with. The IPv4 node can be, for example, an application server or another UE. IPv6 node IPv6 node is here defined to be IPv6 capable node the UE is communicating with. The IPv6 node can be, for example, an application server or another UE. 2. Transition mechanisms This chapter briefly introduces some transition mechanisms specified by the IETF. Applicability of different transition mechanisms to 3GPP networks is discussed in chapters 4 and 5. The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack Wiljakka, Editor Expires - December 2002 [Page 4] IPv6 Transition Solutions for 3GPP Networks June 2002 - tunneling - protocol translators 2.1 Dual Stack The dual IPv4/IPv6 stack is specified in [RFC-2893]. If we consider the 3GPP GPRS core network, implementation of dual stack capabilities in the GGSN enables both IPv4 and IPv6 Access Points and it is also needed to perform IPv6 in IPv4 tunneling. UEs with dual stack can access both IPv4 and IPv6 services without additional translators in the network. 2.2 Tunneling Tunneling means, for example, encapsulating IPv6 packets in IPv4 packets and decapsulating in the other end of the tunnel [RFC- 2893]. Tunneling requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. In configured tunneling, the endpoint of the tunnel is manually configured to a certain IPv4 address. In dynamic tunneling, the encapsulation is done automatically in the encapsulating router/ host, and the tunnel endpoint IPv4 address is included in the IPv6 destination address of the packet. An example of dynamic tunneling mechanism is the so- called "6to4" tunneling mechanism [RFC-3056]. 2.3 Protocol translators A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes. Header conversion is a translation mechanism. In header conversion, IPv6 packet headers are converted to IPv4 packet headers, and vice versa, and checksums are adjusted or recalculated if necessary. NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] is an example of such a mechanism. Translators are typically needed when the two communicating nodes do not share the same IP version. Translation can actually happen at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP proxy) or Layer 7 (using application relays). 2.4 Other transition mechanisms There are some transition mechanisms that can not be exactly put in one of those categories above. Such mechanisms are discussed here. Wiljakka, Editor Expires - December 2002 [Page 5] IPv6 Transition Solutions for 3GPP Networks June 2002 DSTM (Dual Stack Transition Mechanism) [DSTM] is a transition mechanism providing a method to assign temporary IPv4 addresses to dual stack nodes. This would allow either IPv6 nodes to communicate with IPv4-only nodes, or for IPv4-only applications to run without modification on an IPv6 node. The idea is to perform dynamic tunneling of an IPv4 packet inside an IPv6 packet to hide IPv4 packets in the native IPv6 domain. It is assumed that many 3GPP networks will be based on dual stack architecture and both IPv4 and IPv6 PDP contexts will be supported during the transition period. The availability of public IPv4 addresses needed in the DSTM mechanism also is an open question. ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) [ISATAP] connects IPv6 hosts and routers (nodes) within IPv4 sites. ISATAP is a transition mechanism that enables incremental deployment of IPv6 by treating the site's IPv4 infrastructure as a Non-Broadcast Multiple Access (NBMA) link layer for IPv6. ISATAP mechanisms use an IPv6 interface identifier format that embeds an IPv4 address - this enables automatic IPv6-in-IPv4 tunneling within a site, whether the site uses globally assigned or private IPv4 addresses. The new interface identifier format can be used with both local and global unicast IPv6 prefixes - this enables IPv6 routing both locally and globally. 3. Brief introduction to the 3GPP network model From the point of view of this document, the most relevant 3GPP architectural elements are the UE, the GGSN and the IP based network behind the GGSN. The peer node (that the UE is communicating with), its IP version and also the IP network between those two communicating nodes are also relevant. Figure 1 shows the simplified GPRS architecture. -- ---- ---- ************ --------- |UE|- ... -|SGSN|--+--|GGSN|--+--* IPv4/v6 NW *--+--|Peer node| -- ---- ---- ************ --------- Figure 1: Simplified GPRS Architecture The logical connection established between the UE and the GGSN Access Point (AP) is called a Packet Data Protocol (PDP) context. The mobile receives its IP address (IPv4 or IPv6) in the activation of the PDP context. 3GPP stateless address autoconfiguration is the addressing method typically used. According to the IPv6 addressing model in 3GPP Releases 99, 4 and 5 [3GPP-23.060],a globally unique /64 prefix is allocated to each primary PDP context. The GGSN also allocates Interface Identifier to the UE. The usage of privacy extensions (RFC 3041) is also possible. Wiljakka, Editor Expires - December 2002 [Page 6] IPv6 Transition Solutions for 3GPP Networks June 2002 The GGSN Access Points can support IPv4 or IPv6. The Access Point Name (APN) is a logical name referring to a GGSN and an external network. Different network domains and services can be found beyond the Access Points. When going outside the operatorĘs network, traffic goes through the operator network edge router. In this case, public IPv4 addresses and global IPv6 addresses are needed. Getting enough global IPv6 addresses is not a problem, but the typical situation is that the operator has a limited pool of public IPv4 addresses. 4. GPRS Transition scenarios This section describes the scenarios that might occur when a GPRS UE contacts services, or nodes outside the GPRS network, e.g. a web server in the Internet. Transition scenarios of the GPRS internal interfaces are outside of the scope of this document. The following scenarios are described here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e. GGSN, and it is connecting to a node in a different network. 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 4) IPv6 UE connecting to an IPv4 node 5) IPv4 UE connecting to an IPv6 node 4.1 Dual Stack UE connecting to IPv4 and IPv6 nodes Introduction to dual stack In this transition scenario, the UE communicates with both IPv4 and IPv6 capable nodes by virtue of both stacks being present in the OS of the UE, and the GGSNs in the network being connected to both IPv4 and IPv6 networks. The dual stack UE may have both stacks active simultaneously. Note that since present and future revisions of 3GPP standards [3GPP-23.228] mandate the use of IPv6 within the 3GPP Release 5 IMS, a 3GPP Rel5 UE will have at least the IPv6 stack active when having active communications. However, if the GGSN does not support IPv6 Access Points and IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6 node, the UE may tunnel IPv6 packets in IPv4 packets, using a variety of methods. This requires dual stack capability in the UE and also a public IPv4 address allocated to the UE. Wiljakka, Editor Expires - December 2002 [Page 7] IPv6 Transition Solutions for 3GPP Networks June 2002 Identifying which protocol to use An application running on a UE may obviously identify whether the endpoint required is an IPv4 or IPv6 capable node by examining the address to discover what address family category it falls into. Alternatively if a user supplies a name to be resolved, the DNS may contain records sufficient to identify which protocol should be used to initiate connection with the endpoint. It is expected that managing the PDP contexts required to initiate communication with either protocol on the UE side will be sufficiently lightweight as to render the process transparent to applications [COMMC1]. Address Management Since the UE is capable of native communication with both protocols, one of the main concerns of an operator in managing this scenario is correct address and routing management. Firstly, an operator must maintain address spaces for both protocols. Secondly, the operator must decide where public and private address space will be used. If private address space is to be used for fulfilling IPv4 PDP contexts, and a desired resource exists outside of the operator network, the operator must implement a network address translation gateway which will translate the non-globally routable addresses used by the UEs to an address space which can be reached by the recipient of any request. Furthermore, in very large networks, there may not be enough private IPv4 address space to uniquely number every necessary component, since real networks inevitably incorporate hierarchy and inefficiency and therefore never attain perfect usage of address spaces. In this case network address translation gateways may have to be deployed at multiple points in the network. Address scarcity However, both public or private addresses might be a scarce resource for the operator or ISP. In this case, it might not be possible for a UE to have a globally unique IPv4 address continually allocated for its use. Clearly, the UE can either activate an IPv4 PDP context with a public IPv4 address only when needed, or use an IPv4 address from some private address space, either by requesting a specific APN or by receiving it via some address allocation mechanism. 4.2 IPv6 UE connecting to an IPv6 node through an IPv4 network Especially in the first stages of IPv6 deployment, there are cases where an IPv6 node would need to connect to the IPv6 Internet Wiljakka, Editor Expires - December 2002 [Page 8] IPv6 Transition Solutions for 3GPP Networks June 2002 through a network that is IPv4. For instance, this can be seen in current fixed networks, where access is provided using IPv4 only, but there is an IPv6 network deeper in the Internet. In this scenario, the UE is IPv6 capable, and the GPRS network is also IPv6 capable (it has an IPv6 capable GGSN). It is also assumed that the UE is not capable of tunneling. The UE will be communicating with an IPv6 node that could be, for example, an application server. There is no end-to-end IPv6 connectivity between the UE and the IPv6 node, and this is why the IPv4 infrastructure has to be used. An IPv6 PDP context is activated between the IPv6 UE and the GGSN IPv6 Access Point. This scenario also requires "IPv6 in IPv4" tunneling. The tunneling can be configured (i.e. a fixed IPv6 in IPv4 tunnel) or dynamic. The encapsulating node can be e.g. the GGSN or the edge router between the border of the operator IPv6 network and the public Internet. The encapsulation (uplink) and decapsulation (downlink) can be handled by the same network element. Typically the tunneling handled by the network elements is transparent to the UEs and the IP traffic looks like native IPv6 traffic to them. For the applications, tunneling enables end-to-end IPv6 connections. The "IPv6 in IPv4" tunnels between the IPv6 islands can be static or dynamic. The operators or ISPs can use, for example, manually configured tunnels like in the 6bone network. Use of MPLS tunneling also is an alternative. An example of a dynamic tunneling mechanism is so-called "6to4" tunneling [RFC3056]. In that mechanism, only a couple of public IPv4 addresses are needed per site or operator IP network, if the tunneling is done in the network. Packets to the UE are sent using the 6to4 type of address of the UE, and the uplink packets are sent using the destination 6to4 address. However, 6to4 tunneling has some problems: - 6to4 reverse DNS is not yet completely solved. - 6to4 will require relay routers, and there are some security considerations associated with them, see [6to4SEC]. 4.3 IPv4 UE connecting to an IPv4 node through an IPv6 network Further in the future, there will be cases where some legacy UEs are still IPv4 only and capable of connecting to the IPv4 Internet. However, the GPRS operator network has since been upgraded to IPv6. In this case, the operator would still provide the IPv4 capable GGSN, and a connection through the IPv6 network to the IPv4 Internet. Wiljakka, Editor Expires - December 2002 [Page 9] IPv6 Transition Solutions for 3GPP Networks June 2002 3GPP networks are expected to support both IPv4 and IPv6 for a long time, on the UE-GGSN link and between the GGSN and external networks. For this scenario it is useful to split the end-to-end IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 link (PDP context) to connect to the GGSN without the need to communicate over an IPv6 network. Regarding the GGSN-to-V4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore it is not envisaged that tunneling of IPv4 in IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may need to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs. Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not likely to present itself in 3GPP networks. 4.4 IPv6 UE connecting to an IPv4 node In this scenario an IPv6 UE connects to an IPv4 node in the IPv4 Internet. As an example, an IPv6 UE connects to an IPv4 web server in the legacy Internet. IPv6 nodes can communicate with IPv4 hosts by making use of a translator (SIIT, NAT-PT) within the local network. For some applications, application proxies can be appropriate (e.g. HTTP, email relays, etc.). Such applications will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Within the 3GPP architecture, application proxies can be placed on the GGSN external interface (Gi), or inside the service network. However, since it is difficult to anticipate all possible applications, there is a need for translators that can translate headers independently on the type of application being used. Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e. NAPT-PT). When NAPT-PT is used, it needs to be placed on the GGSN external interface. NAPT-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary) and forward packets through its IPv4 interface. Wiljakka, Editor Expires - December 2002 [Page 10] IPv6 Transition Solutions for 3GPP Networks June 2002 NAPT-PT introduces a number of limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed here: 1. NAPT-PT is a single point of failure for all ongoing connections. 2. Additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. Problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. 4. NAPT-PT often is the only default router for both IPv4 and IPv6 traffic. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface, would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NAPT-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes. To minimize the problems associated with NAPT-PT, the following actions are recommended: 1. The separation of the DNS ALG from the NAPT-PT node. 2. Ensure that NAPT-PT does not become a single point of failure. 3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NAPT-PT from becoming a single point of failure. A recent NAT64 - NAT46 [NAT64] document may address these points. Wiljakka, Editor Expires - December 2002 [Page 11] IPv6 Transition Solutions for 3GPP Networks June 2002 4.5 IPv4 UE connecting to an IPv6 node The legacy IPv4 nodes are mostly nodes that support the applications that are popular today in the IPv4 Internet: mostly e- mail, and web-browsing. These applications will, of course, be supported in the IPv6 Internet of the future. However, the legacy IPv4 UEs are not going to be updated to support the future applications. As these application are designed for IPv6, and to use the advantages of newer platforms, the legacy IPv4 nodes will not be able to profit from them. Thus, they will continue to support the legacy services. Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already today mostly rely on proxies or local servers to communicate between private address space networks and the Internet. The same methods and technology can be used for IPv4 to IPv6 transition. An alternative solution could be a general network address translation mechanisms such as NAT46 [NAT64]. 5. Transition Scenarios with IMS IP Multimedia Core Network Subsystem (IMS) is a SIP based multimedia service architecture. It is specified in Release 5 of 3GPP. This section provides an overview of the 3GPP IMS and is not intended to be comprehensive. A more detailed description can be found in [3GPP-23.228], [3GPP-24.228] and [3GPP-24.229]. For a particular cellular device, the 3GPP IMS network is further composed of a home network and a visited network. An IMS subscriber belongs to a home network. Services are triggered and may be executed in the home network. One or more SIP servers are deployed in the SIP home network to support the IP Multimedia Subsystem. Among those SIP servers, there is a SIP serving proxy, which is also acting as a SIP registrar. Authentication and Authorization servers may be part of the home network as well. Users are authenticated in the home network. Three types of SIP proxies / servers are defined in IMS: - P-CSCF (Proxy-Call Session Control Function) is the first contact point within the IMS for the subscriber. - I-CSCF (Interrogating-CSCF) is the contact point within an operatorĘs network for all connections destined to a subscriber of that network operator, or a roaming subscriber Wiljakka, Editor Expires - December 2002 [Page 12] IPv6 Transition Solutions for 3GPP Networks June 2002 currently located within that network operatorĘs service area. - S-CSCF (Serving-CSCF) performs the session control services for the subscriber. It also behave as a SIP Registrar. The visited network contains a SIP outbound proxy to support the UE. The SIP outbound proxy in the visited network may translate locally dialed digits into international format, detect emergency sessions, maintain security associations between itself and the terminals, and interwork with the resource management in the packet network. The SIP outbound proxy is assigned after the mobile has connected to the access network. Once this proxy is assigned, it does not change while the mobile remains connected to the access network. Thus the mobile can move freely within the access network without SIP outbound proxy reassignment. The home network may support also a SIP entry proxy. This node may act as the first entry point for SIP signaling to the home network and may decide (with the help of location servers) which SIP registrar server to assign to a particular user. Typically the address of the home network SIP entry proxy is configured in DNS in the form of a DNS SRV record for SIP. Additionally, home and visited networks may deploy, if required, a SIP hiding proxy. The main purpose of the SIP hiding proxy is to hide the network configuration. The 3GPP IMS is designed to be access independent. Access is granted from 3GPP cellular terminals or from other terminals that use other accesses out of the scope of 3GPP. 3GPP cellular IP Multimedia terminals use the existing General Packet Radio Service (GPRS) as a transport network for IP datagrams. The terminals first connect to the GPRS network to get an IPv6 address. In order to do this, the terminals must perform a (GPRS) Attach procedure followed by a (GPRS) PDP Context Activation procedure. These GPRS procedures are required to be completed before any IP Multimedia session can be established. As a result of the above-mentioned GPRS procedures, the terminal has obtained an IPv6 address. In the case of non-roaming terminals, the IPv6 address belongs to the home network address space. In the case of a roaming terminal, the IPv6 address belongs to the visited network address space. The address does not change as the mobile terminal moves while still attached to the same network address space. Wiljakka, Editor Expires - December 2002 [Page 13] IPv6 Transition Solutions for 3GPP Networks June 2002 If the terminal moves from a GPRS access to another GPRS access, the above-mentioned GPRS procedures need to start from the beginning to allocate an IPv6 address to the terminal. Figure 2 shows an overview on the 3GPP architecture for IMS. +-------------+ +----------------+ +----------------+ | | | | | | | | | | | | | | | | | +------+ | | | | | | | SIP | | | | | | | |server| | | | | | | | +------+ | +-|+ | | | | | / | | | | | | +------+ | | +------+ | | | | | | | SIP | | | | SIP | | | | ---|-------------|--|----|server|----|---|-|server| | +--+ | | | +------+ | | +------+ | | | | | | | SIP | GPRS access | | Visited Network| | Home Network | dev. +-------------+ +----------------+ +----------------+ Figure 2: Overview of the 3GPP IMS architecture It comprises a set of SIP proxies, servers, and registrars. In addition, there are Media Gateways (MGWs) that offer connections to non-IP networks such as the Public Switched Telephony Network (PSTN). The IMS is exclusively IPv6. An 3GPP IP Multimedia terminal uses exclusively IPv6 to access the IMS, and the IMS SIP server and proxy support exclusively IPv6. Hence, all the traffic for the IMS is IPv6, even if the UE is dual stack capable. More information on IMS can be found in [3GPP-23.228]. As the IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. In the following, the possible transition scenarios are listed. Those scenarios are analyzed in sections 5.2 and 5.3. 1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS islands connected via an IPv4 network 5.1 DNS interworking in IMS Currently, there is a consensus in the IETF that even in the IPv6 Internet the DNS resolvers have to be dual stack. This might be a valid assumption in the early stages of the transition. However, Wiljakka, Editor Expires - December 2002 [Page 14] IPv6 Transition Solutions for 3GPP Networks June 2002 this will be a restrictive factor in the future, and hence is not a valid assumption for the IMS. To perform DNS resolution in the IMS, the UE can be configured as a stub resolver pointing to a recursive DNS resolver. This communication can happen over IPv6. However, in the process to find the IPv6 address of a SIP server, the recursive DNS resolver may need to access data that is available only on some IPv4 DNS servers, see [v6namespace] and [DNSreq]. One way to achieve this is to make the DNS resolver be dual stack. This may work in the early days of deployment, but this will be a restrictive factor in the future, and thus, is not a valid assumption for the IMS. As the IMS is IPv6 only, there has to be a mechanism to allow the DNS resolvers to be IPv6 only. A mechanism that could be used is NAT64 [NAT64]. 5.2 UE connecting to a node in an IPv4 network through IMS This scenario occurs when an IMS UE (IPv6) connects to a node in the IPv4 Internet through the IMS, or vice versa. This happens when the other node is a part of a different system than 3GPP, e.g. a fixed PC, with only IPv4 capabilities. Obviously there will be a number of legacy IPv4 nodes in the Internet that will communicate with the IMS UEs. As the IMS is exclusively IPv6, translators have to be used in the communication between the IPv6 IMS and legacy IPv4 hosts. This section aims to give an overview on how that interworking can be handled. As control (or signaling) and user (or data) traffic is separated in SIP, and thus, the IMS, the translation of the IMS traffic has to be done on two levels - Session Initiation Protocol (SIP)[RFC2543], and Session Description Protocol (SDP) [RFC2327] on the one hand (Mm-interface), and on the actual user data traffic level on the other (Mb-interface). SIP and SDP transition has to be made in an SIP/SDP Application Level Gateway. The ALG has to change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. If the S-CSCF is dual stack capable, the ALG specific functions can be done in the S-CSCF directly, i.e. changing the SIP message headers, and the SDP payload. In addition, there has to be interoperability for DNS queries; see section 5.1 for details. On the user data transport level, the translation is IPv4-IPv6 protocol translation, where the user data traffic transported is translated from IPv6 to IPv4, and vice versa. Wiljakka, Editor Expires - December 2002 [Page 15] IPv6 Transition Solutions for 3GPP Networks June 2002 The legacy IPv4 host's address can be mapped to an IPv6 address for the IMS, and this address is then used within the IMS to route the traffic to the appropriate user traffic translator. This mapping can be done by the SIP/SDP ALG for the SIP traffic. The user traffic translator would do the similar mapping for the user traffic. However, in order to have an IPv4 address for the IMS UE, and to be able to route the user traffic within the legacy IPv4 network to the correct translator, there has to be an IPv4 address allocated for the duration of the session from the user traffic translator. The allocation of this address from the user traffic translator has to be done by the SIP/SDP ALG in order for the SIP/SDP ALG to know the correct IPv4 address. This can be achieved by using a protocol for the ALG to do the allocation such as MEGACO [RFC3015]. 5.3 Two IPv6 IMS UEs connected via an IPv4 network At the early stages of IMS deployment, there may be cases where two IMS islands are separated by an IPv4 network such as the legacy Internet. Here both the UEs and the IMS islands are IPv6-only. However, the IPv6 islands are not native IPv6 connected. In this scenario, the end-to-end SIP connections would be based on IPv6. The only issue is to make connection between two IPv6-only IMS islands over IPv4 network. So, in practice, this scenario is very closely related to GPRS scenario represented in section 4.2. IPv4 / IPv6 interworking can be taken care of in the network; the basic options are static and dynamic tunneling. The tunnel starting point or endpoint should be located on the edge of the IMS domain. Static "IPv6 in IPv4" tunnels configured between different IMS domains would also be a solution. Note that this bears some similarity to the problems that 6bone users face [6BONE]. 6. Recommendations for transition methods in 3GPP networks and terminals Based on the transition scenarios analyzed in chapters 4 and 5, the following recommendations can be given. This recommendation list is not considered to be comprehensive. 1) If the dual stack UE is IPv4 capable, but cannot get a public IPv4 address (due to lack of public IPv4 addresses), it is recommended to use a global IPv6 address instead of using a private IPv4 address and a NAT. Two basic options are possible in the case of public IPv4 addresses not being available for a dual stack UE: a) allocating a private IPv4 address to the UE and then using a NAT when connecting to IPv4 Wiljakka, Editor Expires - December 2002 [Page 16] IPv6 Transition Solutions for 3GPP Networks June 2002 nodes over the public Internet; and b) allocating a globally unique IPv6 address and then using a protocol translator (such as NAT-PT or NAT64) to connect to IPv4 nodes. Approach a) is simpler initially, but becomes increasingly complex as the network grows. Alternative b) is more expensive in the beginning, but has better long-term potential. 2) "IPv6 in IPv4" tunneling should mainly be handled in the network, not in the UEs. 3) NAT-PT does not seem particularly applicable to 3GPP transition scenarios; NAT64 [NAT64] looks more promising. 4) Implementation of dual stack for the UEs is recommended, at least during the early phases of IPv6 transition. 5) The IPv4 / IPv6 interworking should be mainly handled in the network, not in the UEs. 7. Security Considerations 1. Problems have been identified in the case of the reachability of IPv4 and IPv6 nodes (use of DNS through NAT-PT). NAT-PT DNS ALG problems are described in [NATPT- DNS]. 2. In 3GPP Release 5 IMS, IPsec ESP [RFC2406] is used for protecting SIP signaling between the UE and the P-CSCF network element. For that service, authentication and key handling is done using UMTS AKA (Authentication and Key Agreement) [UMTS-AKA]. Additionally, IPsec ESP is used to protect SIP signaling between two security domains [3GPP- 33.210]. Traffic in and out of a security domain goes through a security gateway. ESP tunnel mode is used between security gateways. For this service, authentication and key handling is done using IKE [RFC2409]. 3. The 3GPP specifications do not currently define the usage of DNS Security. They neither disallow the usage of DNSSEC, nor do they mandate it. 8. References [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description Protocol, RFC 2327, April 1998. [RFC2406] Kent, S. and Atkinson, R.: "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998. Wiljakka, Editor Expires - December 2002 [Page 17] IPv6 Transition Solutions for 3GPP Networks June 2002 [RFC2409] Harkins, D., and Carrel, D.: "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2543] Handley, M., et al, SIP: Session Initiation Protocol, RFC 2543, March 1999. [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663, August 1999. [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation - Protocol Translation (NAT-PT), RFC 2766, February 2000. [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for IPv6 Hosts and Routers, RFC 2893, August 2000. [RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015, November 2000. [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001. [3GPP-SCEN] Soininen, J., et al: "Transition Scenarios for 3GPP Networks", April 2002, draft-soininen-ngtrans-3gpp-cases-00.txt, work in progress. [6to4SEC] Savola, P.: "Security Considerations for 6to4", February 2002, draft-savola-ngtrans-6to4-security-01.txt, work in progress. [DNSreq] Durand, A., Ihren, J.: "NGtrans IPv6 DNS operational requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops- req-04.txt, work in progress. [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", February 2002, draft-ietf-ngtrans-dstm-07.txt, work in progress. [IPv6-3GPP] Wasserman, M., et al: "Recommendations for IPv6 in 3GPP Standards", April 2002, draft-ietf-ipv6-3gpp-recommend-02.txt, work in progress. [ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April 2002, draft-ietf-ngtrans- isatap-04.txt, work in progress. [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- ngtrans-nat64-nat46-00.txt, work in progress. Wiljakka, Editor Expires - December 2002 [Page 18] IPv6 Transition Solutions for 3GPP Networks June 2002 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", January 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in progress. [v6namespace] Ihren, J.: "IPv4-to-IPv6 migration and DNS namespace fragmentation", March 2002, draft-ietf-dnsop-v6-name-space- fragmentation-01.txt, work in progress. [3GPP-23.060] 3GPP TS 23.060 V5.2.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", June 2002. [3GPP-23.228] 3GPP TS 23.228 V5.5.0, "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", June 2002. [3GPP 24.228] 3GPP TS 24.228 V5.0.0, "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)", March 2002. [3GPP 24.229] 3GPP TS 24.229 V5.0.0, "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", March 2002. [3GPP-33.210] 3GPP TS 33.210 V5.1.0, "Network Domain Security; IP network layer security (Release 5)", June 2002. [UMTS-AKA] 3GPP TS 33.102, "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 4)", December 2001. [COMMC1] Personal communication with author from Crevan Murply, a Core Networks employee in O2. [6BONE] http://www.6bone.net 9. Authors and Acknowledgements This document is written by the Ngtrans 3GPP IPv6 transition design team chaired by Jonne Soininen, Nokia. The members of the design team are: Alain Durand, Sun Microsystems Karim El-Malki, Ericsson Radio Systems Paul Francis, Tahoe Networks Niall Richard Murphy, Enigma Consulting Limited Wiljakka, Editor Expires - December 2002 [Page 19] IPv6 Transition Solutions for 3GPP Networks June 2002 Hugh Shieh, AT&T Wireless Jonne Soininen, Nokia Hesham Soliman, Ericsson Radio Systems Margaret Wasserman, Wind River Juha Wiljakka, Nokia The authors would like to thank Gabor Bajko and Vlad Stirbu for their input. 10. Editor's Contact Information Comments or questions regarding this document should be sent to the ngtrans mailing list or directly to the document editor: Juha Wiljakka Nokia Sinitaival 5 Phone: +358 7180 47562 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com Wiljakka, Editor Expires - December 2002 [Page 20]