Internet Draft J. Wiljakka (ed.) Document:
draft-ietf-v6ops-3gpp-analysis-09.txtdraft-ietf-v6ops-3gpp-analysis-10.txt Nokia Expires: SeptemberNovember 2004 MarchMay 2004 Analysis on IPv6 Transition in 3GPP Networks Status of this Memo This document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and isany of which I become aware will be disclosed, in full conformanceaccordance with all provisions of Section 10 of RFC2026.RFC 3668. 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 analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) packet networks.technology, and the radio network architecture is based on Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. 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 other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. Table of Contents 1. Introduction..................................................2 1.1 Scope of this Document....................................3 1.2 Abbreviations.............................................3Abbreviations.............................................4 1.3 Terminology...............................................4 2. Transition Mechanisms and DNS Guidelines......................5 2.1 Dual Stack................................................5 2.2 Tunneling.................................................5 2.3 Protocol Translators......................................5Translators......................................6 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 3. GPRS Transition Scenarios.....................................6 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6Nodes...........7 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network ..............................................................8.............................................................8 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network .............................................................10............................................................10 3.4 IPv6 UE Connecting to an IPv4 Node.......................10 3.5 IPv4 UE Connecting to an IPv6 Node.......................11 4. IMS Transition Scenarios.....................................12 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 4.2 Two IPv6 IMS IslandsConnected overvia an IPv4 Network..............14Network...............14 5. About 3GPP UE IPv4/IPv6 Configuration........................14 6. Security Considerations......................................15Summary and Recommendations..................................15 7. Security Considerations......................................16 8. References...................................................16 7.18.1 Normative................................................16 7.2 Informative..............................................16 8. Contributors.................................................188.2 Informative..............................................17 9. Contributors.................................................19 10. Authors and Acknowledgements.................................18 10.Acknowledgements................................19 11. Editor's Contact Information................................19 11.Information................................20 12. Intellectual Property Statement.............................19 12. Copyright...................................................19Statement.............................20 13. Copyright...................................................20 Appendix A...................................................20A...................................................21 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. The authors can be foundnetworks, in Authors and Acknowledgements section.which the radio network architecture is based on Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. This document analyzes the transition scenarios in 3GPP packet data networksthat mightmay come up in the deployment phase of IPv6.IPv6 in 3GPP packet data networks. The 3GPP network architecture is described in [RFC3314], and relevant transition scenarios are documented in [RFC3574] and[RFC3574]. The reader of this document will further analyze them.specification should be familiar with the material presented in these documents. The scenarios analyzed in this document are divided into two categories: general-purpose packet service scenarios, referred to as GPRS scenarios in this document, and IP Multimedia Subsystem (IMS) scenarios.scenarios, which include Session Initiation Protocol (SIP) considerations. GPRS scenarios are the following: - Dual Stack UE connecting to IPv4 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 - IPv4 UE connecting to an IPv6 node IMS scenarios are the following: - UE connecting to a node in an IPv4 network through IMS - Two IPv6 IMS islandsconnected 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. 1.1 Scope of this Document The scope of this Best Current Practicesdocument is to analyze and solvethe possible transition scenarios in the 3GPP defined GPRS network where a UE connects to, or is contacted from, the Internet oranother UE.node on the Internet. The document covers scenarios with and without the use of the SIP basedSIP-based IP Multimedia Core Network Subsystem (IMS). This document does not focus on radio interfaceinterface-specific issues; both 3GPP Second (GSM)and Third Generation (UMTS)radio network architectures (GSM, EDGE and UMTS/WCDMA) will be covered by this analysis. The 3GPP2 architecture is similar to 3GPP in many ways, but differs in enough details that this document does not include these scenarios.variations in its analysis. The transition mechanisms specified by the IETF Ngtrans and v6ops Working Groups shall be used. This documentmemo shall not specify any new transition mechanisms, but if aonly documents the need for anew mechanism is found, that will be reported to the IETF v6ops Working Group.ones (if appropriate). 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) DNS Domain Name System GGSN Gateway GPRS Support Node (a default(default router for 3GPP User Equipment) GPRS General Packet Radio Service GSM Global System for Mobile Communications HLR Home Location Register IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IPv6-only part of the network ISP Internet Service Provider NAT Network Address Translator NAPT-PT Network Address Port Translation - Protocol Translation NAT-PT Network Address Translation - Protocol Translation PCO-IE Protocol Configuration Options Information Element PDP Packet Data Protocol PPP Point-to-Point Protocol SGSN Serving GPRS Support Node SIIT Stateless IP/ICMP Translation Algorithm SIP Session Initiation Protocol UE User Equipment, for example a UMTS mobile handset UMTS Universal Mobile Telecommunications System WCDMA Wideband Code Division Multiple Access 1.3 Terminology Some terms used in 3GPP transition scenarios and analysis documents are briefly defined here. Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both IPv4 and IPv6 stacks. It is capable of activating both IPv4 and IPv6 Packet Data Protocol (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 IPv4-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. PDP Context Packet Data Protocol (PDP) Context is a connection between the UE and the GGSN, over which the packets are transferred. There are currently three PDP Types: IPv4, IPv6 and PPP. 2. Transition Mechanisms and DNS Guidelines This chapter briefly introduces some transition mechanisms specified by the IETF.these IETF IPv4/IPv6 transition mechanisms: - dual IPv4/IPv6 stack [RFC2893-bis] - tunneling [RFC2893-bis] - protocol translators [RFC 2766], [RFC2765] In addition to that,addition, DNS recommendations are given. The applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators2.1 Dual Stack The dual IPv4/IPv6 stack is specified in [RFC2893].[RFC2893-bis]. If we consider the 3GPP GPRS core network, dual stack implementation in the Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that private IPv4 addresses and NATs have been used and will be used in mobile networks. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address that is visible to other nodes. 2.2 Tunneling Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. Tunneling can be static or dynamic. Static (configured) tunnels are fixed IPv6 links over IPv4, and they are specified in [RFC2893].[RFC2893- bis]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e. the links are created dynamically. 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, or vice versa, and checksums are adjusted or recalculated if necessary. NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] using SIITStateless IP/ICMP Translation [RFC2765] is an example of such a mechanism. Translators may be needed in some cases when the communicating nodes do not share the same IP version; in others, it may be possible to avoid such communication altogether. Translation can actually happentake place at Layer 3the network layer (using NAT-like techniques), Layer 4the transport layer (using a TCP/UDP proxy) or Layer 7the application layer (using application relays). 2.4 DNS Guidelines for IPv4/IPv6 Transition To avoid the DNS name space from fragmenting into parts where some parts of DNS are only visible using IPv4 (or IPv6) transport, the recommendation (as of this writing) is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [DNStrans] for more information. 3. GPRS Transition Scenarios This section discusses the scenarios that might occur when a GPRS UE contacts services or other nodes, e.g. a web server in the Internet. The following scenarios described by [RFC3574] are analyzed 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. the GGSN, and the UE 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 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. The authors leave the PDP context activation policy to be decided by UE implementers, application developers and operators. One discussed possibility is to activate both IPv4 and IPv6 types of PDP contexts in advance, because activation of a PDP context usually takes some time. However, that probably isn't good usage of network resources. Generally speaking, IPv6 PDP contexts should be preferred even if that meant IPv6-in-IPv4 tunneling would be needed in the network (see section 3.2 for more details). Note that this is transparent to the UE. However,Although the UE is dual-stack, the UE may attachfind itself attached to a 3GPP network,network in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment.deployment, or because the UE has "roamed" from a 3GPP network that supports IPv6 to one that does not. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. The usedtunneling mechanism may require public IPv4 addresses, but there are tunneling mechanisms and deployment scenarios in which the usage ofprivate IPv4 addresses is possible. Ifmay be used; for instance, if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT, private IPv4 addresses can be used.NAT. One deployment scenario example is usinguses a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. The usedtunneling mechanism in that casedepends on the laptop computerís support of tunneling mechanisms in the laptop computer.mechanisms. Another deployment scenario is makingperforming IPv6-in-IPv4 tunneling in the UE itself and activating an IPv4 PDP context. Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism may be a good fit. There is not yet consensus on the right approach. Primarily, ISATAPapproach, and proposed mechanisms so far include [ISATAP] and [STEP]. Especially ISATAP has been proposed, buthad some issues have been raised about it, such as its unnecessary features and relative complexity for a simple task like this, and its inadequacysupport in providing security when crossing administrative domains. Proposed solution alternatives have been (at least) a simplified, but probably non-interoperable, version of ISATAP, and STEP [STEP]. In any case,the wg. However, further work is needed to find out the requirements for the scenario and to specify the mechanism. To generally solve this problem (IPv6 not available in the 3GPP network), thisThis document strongly recommends the 3GPP operators to deploy basic IPv6 support in their GPRS networks. That alsomakes it possible to burdenlessen the transition effects in the network and make the 3GPP UEs simpler.UEs. As a general guideline, IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. Public IPv4 addresses are often a scarce resource for the operator and typicallyusually it is not possible for a UE to have a public IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive and difficult to maintain. For DNS recommendations, we refer to section 188.8.131.52 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network The best solution for this scenario is obtained with tunneling, i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context is activated between the UE and the GGSN. Tunneling is handled in the network, because IPv6 UE is not capable of tunneling (itdoes not have the dual stack functionality needed for tunneling).tunneling. The encapsulating node can be the GGSN, the edge router between the border of the operator's IPv6 network and the public Internet, or any other dual stack node within the operator's IP network. 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 IP traffic looks like native IPv6 traffic to them. For the applications,applications and transport protocols, tunneling enables end-to-end IPv6 connectivity. IPv6-in-IPv4 tunnels between IPv6 islands can be either static or dynamic. The selection of the type of tunneling mechanism is up toa policy decision for the operator / ISP deployment scenario and only generic recommendations can be given in this document. The following subsections are focused on the usage of different tunneling mechanisms when the peer node is in the operator's network or outside the operator's network. The authors note that where the actual 3GPP network ends and which parts of the network belong to the ISP(s) also depends on the deployment scenario. The authors are not commenting how many ISP functions the 3GPP operator should perform. However, many 3GPP operators are ISPs of some sort themselves. ISP networks' transition to IPv6 is analyzed in [ISP- sa]. 3.2.1 Tunneling inside the 3GPP Operator's Network GPRS operators today have typically deployed IPv4 backbone networks. IPv6 backbones can be considered quite rare in the first phases of the transition. In initial IPv6 deployment, where a small number of IPv6-in-IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island can contain the GGSN while another island can contain the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. In that case, upgrading parts of the backbone to dual stack may be the simplest choice. The administrative burden could also be mitigated by using automated management tools. Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their ownalone don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they can provide an adequate solution depending on the design of the network and inthe presence of other router redundancy mechanisms, such as the use of IPv6 routing protocols. 3.2.2 Tunneling outside the 3GPP Operator's Network This subsection includes the case in which the peer node is outside the operator's network. In that case, IPv6-in-IPv4 tunneling can be necessary to obtain IPv6 connectivity and reach other IPv6 nodes. In general, configured tunneling can be recommended. Tunnel starting point can be in the operator's network depending on how far the 3GPP operator has come in implementing IPv6. If the 3GPP operator has not deployed IPv6 in its backbone, the encapsulating node can be the GGSN. If the 3GPP operator has deployed IPv6 in its backbone,backbone but the upstream ISP does not provide IPv6 connectivity to the Internet,connectivity, the encapsulating node cancould be the edge3GPP operator's border router. The case is pretty straightforward if the upstream ISP provides IPv6 connectivity to the Internet and the operator's backbone network supports IPv6. Then the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from the edgeborder router to a dual stack border gateway operated by another ISP which is offering IPv6 connectivity. 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 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. ThereforeThis allows an IPv4-only UE will be ableto use an IPv4 link (PDP(an IPv4 PDP context) to connect to the GGSN without the need to communicatecommunicating 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 needchoose 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 considered very likely in 3GPP networks. 3.4 IPv6 UE Connecting to an IPv4 Node Generally speaking, IPv6-only UEs may be easier to manage, but that would require all services to be used over IPv6, and that may not bethe universal deployment of IPv6 probably isnít realistic in the near future. Dual stack implementation requires management of both IPv4 and IPv6 networks and one approach is that "legacy" applications keep using IPv4 for the foreseeable future and new applications requiring end-to-endend- to-end connectivity (for example, peer-to-peer services) use IPv6. As a general guideline, IPv6-only UEs are not recommended in the early phases of transition until the IPv6 deployment has become so prevalent that direct communication with IPv4(-only) nodes will no longerbe necessary.the exception, and not the rule. It is assumed that IPv4 will remain useful for quite a long time, so in general, dual-stack implementation in the UE can be recommended. This recommendation naturally includes manufacturing dual-stack UEs instead of IPv4-onlyIPv4- only UEs. However, if there is a need to connect to an IPv4(-only) node from an IPv6-only UE, it is possiblerecommended to use specific translation and proxying techniques; generic IP protocol translation is not recommended. There are three main ways for IPv6(-only) nodes to communicate with IPv4(-only) nodes (excluding avoiding such communication in the first place): 1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766]) in the local network (not recommended as a general solution), 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 TCP relay configured for a couple of ports only [RFC3142]) or application proxies (e.g., HTTP proxy, SMTP relay) in the local network, or 3. the use of specific-purpose mechanisms (as described above in 2) in the foreign network; these are indistinguishable from the IPv6-enabled services from the IPv6 UE's perspective, and not discussed further here. For many applications, application proxies can be appropriate (e.g. HTTP proxies, SMTP relays, etc.). Such application proxies 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. Application proxies can be placed, for example, on the GGSN external interface (Gi),("Gi"), or inside the service network. The authors note that [NATPTappl] discusses the applicability of NAT-PT. The problems related to NAT-PT usage in 3GPP networks are documented in appendix A. 3.5 IPv4 UE Connecting to an IPv6 Node The legacy IPv4 nodes are mostlytypically 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 future IPv6 Internet. However, the legacy IPv4 UEs are not going to be updated to support thefuture applications. As these applications are designed for IPv6, and to use the advantages of newer platforms, the legacy IPv4 nodes will not be able to profit fromtake advantage of them. Thus, they will continue to support thelegacy services. Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already 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. For DNS recommendations, we refer to section 2.4.4. IMS Transition Scenarios As theIMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. The possible IMS scenarios are listed below and analyzed in sections 4.1 and 4.2. 1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS islandsconnected overvia an IPv4 network For DNS recommendations, we refer to section 2.4. As DNS traffic is not directly related to the IMS functionality, the recommendations are not in contradiction with the IPv6-only nature of the IMS. 4.1 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. The first priority is toOver time, users will upgrade the legacy IPv4 nodes to dual- stack,dual-stack, often by replacing the entire node, eliminating this particular problem in that specific deployment. Still, it is difficult to estimate how many non-upgradeable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. As the IMS is exclusively IPv6 [3GPP 23.221], for many of the applications in the IMS, some kind of translators havemay need to be used in the communication between the IPv6 IMS and the legacy IPv4 hosts, i.e. making a dual stack based solution is not feasible.hosts in cases where these legacy IPv4 hosts cannot be upgraded to support IPv6. This section aims to givegives a brief overview on how that interworking can be handled. This section presents higher level detailsanalysis of a solution based onthe use of a translator and SIP ALG. [3GPPtr] provides additional informationIMS interworking issues, and presents a bit different solution proposal based onhigh level view of SIP Edge Proxy and IP Address/Port Mapper.within the IMS. The authors recommend to solvethat a detailed solution for the general SIP/SDPSIP/SDP/media IPv4/IPv6 transition problem inwill be specified as soon as possible as a task within the IETFSIP wg(s).WGs in the IETF. As control (or signaling) and user (or data) traffic are separated in SIP,SIP calls, and thus, the IMS, the translationtransition of theIMS traffic hasfrom IPv6 to IPv4 must be donehandled at two levels: 1)Session1. Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface) 2)the2. the user data traffic (Mb-interface) SIP and SDP transition has to be made incarries an SIP/SDP Application Level Gateway. The ALG has toSDP body containing the addressing and other parameters for establishing the user data traffic (the media). Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP proxy at the border between the 3GPP IPv6-only IMS and the IPv4 systems. In a possible approach, this edge could contain a SIP ALG, which would change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. In addition, there has toThis approach would have the drawback (like other SDP rewriting solutions) of impacting authentication mechanisms that may be interoperability for DNS queries; see section 2.4needed for details. On the user data transport level, the translation is IPv4-IPv6 protocol translation, where the user data traffic transported is translated from IPv6other purposes. Moreover, this approach would not take advantage of SIP's ability to IPv4, and vice versa. The legacy IPv4 host's address can be mappeduse proxy routing, nor of SDP's ability to an IPv6 address for the IMS,carry multiple alternative addresses. These intrinsic features of SIP and this address is then used within the IMS to routeSDP require a more detailed analysis, but they could yield benefits. The SIP ALG approach requires NAT-PT (with the traffic toissues described in Appendix A), because the appropriate user traffic translator. This mapping canIMS-side IPv6 addresses must be done by the SIP/SDP ALGassigned IPv4 addresses for reachability from the SIP traffic.legacy IPv4 side shown in Figure 1. The user traffic translatorapproach based on intrinsic SIP proxy routing would do the similar mapping for the user traffic. However, in ordernot require assignment of temporary IPv4 addresses to havethe IPv6 IMS endpoints; instead they would be reached via an IPv4IPv4-side address of a SIP proxy acting for the IMS UE, and tothem. This SIP proxy would be able to routedoing normal SIP processing. On the user traffic withindata transport level, the legacy IPv4 network toanalysis raises other issues: the correct translator, there hasIMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol translation (with the scalability concerns raised in Appendix A) may look simplest, but needs a skeptical look. Alternatives include routing to bea transcoder, whose task is to terminate an IPv6 stream and start an IPv4 address allocated for the duration of the session from the user traffic translator. The allocation ofstream. Again, this address fromrequires a more detailed analysis. For each of the user traffic translatorprotocols, there has to be done by the SIP/SDP ALG in orderinteroperability for the SIP/SDP ALG to know the correct IPv4 address. This can be achieved by using a protocolDNS queries; see section 2.4 for the ALG to do the allocation.details. +-------------------------------+ +------------+ | +------+ | | +--------+ | | |S-CSCF|---| |SIP ALG |edge| |\ | | +------+ | | +--------+ | \ -------- +-|+ | / | | | | | | | | | +------+ +------+ | | + | -| |- | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | | +------+ +------+ | |+----------+| / ------ | |-----------------------------------||Translator||/|-----------------------------------|| [ALG?] ||/ +--+ | IPv6 | |+----------+| IPv4 UE | | |Interworking| | IP Multimedia CN Subsystem | |Unit | +-------------------------------+ +------------+ Figure 1: UE using IMS to contact a legacy phone Figure 1 shows a possible configuration scenario where the SIP ALG is separated from the CSCFs. The translator can either be set up in a single device with bothgeneric SIP translation and media translation, or those functionalities can be divided to two different entities with an interface in between. We call the combined network element on thesignaling edge - an ALG-like replacement of the IPv6-only IMS an "Interworking Unit" in this document. A SIP-specific translation mechanism, which could e.g. re-useIPv6 addresses with IPv4 addresses using limited subsets of NAT-PT [RFC2766], needs[RFC2766]. This is a possible approach, but exploiting SIP's proxy routing to allow the dual homed SIP edge to make the address change without a translator could be specified. Thea promising alternative without the scaling problems related to NAT-PT are discussed in appendix A.of NAT-PT. 4.2 Two IPv6 IMS IslandsConnected overvia 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 connected natively with IPv6. In this scenario, the end-to-end SIP connections are based on IPv6. The only issue is to make connection between two IPv6-only IMS islands over IPv4 network. This scenario is closely related to GPRS scenario represented in section 3.2. and similar tunneling solutions are applicable also in this scenario. 5. About 3GPP UE IPv4/IPv6 Configuration This informative section aims to give a brief overview on the configuration needed in the UE in order to access IP based services. There can also be other application specific settings in the UE that are not described here. To be abledescribed here. UE configuration is required in order to access IPv6 or IPv4 based services, settings need to be done in the UE.services. The GGSN Access Point has to be defined when using, for example, the web browsing application. One possibility is to use over the air configuration [OMA-CP] to configure the GPRS settings. The user cancan, for example, visit the operator WWW page and subscribe the GPRS Access Point settings to his/her UE and receive the settings via Short Message Service (SMS). After the user has accepted the settings and a PDP context has been activated, the userhe/she can start browsing. The Access Point settings can also be typed in manually or be pre-configured by the operator or the UE manufacturer. DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). Same kind ofA similar mechanism is also available for IPv6: so-called Protocol Configuration Options Information Element (PCO-IE)(PCO- IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [DHCPv6-SL] or [RFC3315][RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server addresses. Active IETF work on DNS discovery mechanisms is ongoing and might result in other mechanisms becoming available over time. The DNS server addresses can also be received over the air (using SMS),SMS) [OMA-CP], or typed in manually in the UE. When accessing IMS services, the UE needs to know the P-CSCFProxy-Call Session Control Function (P-CSCF) IPv6 address. 3GPP-specificEither a 3GPP- specific PCO-IE mechanism,mechanism or a DHCPv6-based mechanism ([DHCPv6-SL]([RFC3736] and [RFC3319]) can be used. Manual configuration or [RFC3315]configuration over the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here. 6. Summary and Recommendations This document has analyzed five GPRS and two IMS IPv6 transition scenarios. Numerous 3GPP networks are using private IPv4 addresses today, and introducing IPv6 is an important thing. The two first GPRS scenarios and both IMS scenarios are seen the most relevant. The authors summarize some main recommendations here: - Dual-stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that the applications in the UEs support IPv6. IPv6-only UEs can become feasible when IPv6 is widely deployed in the networks, and most services work on IPv6. - It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. - IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. - This document strongly recommends the 3GPP operators to deploy basic IPv6 support in their GPRS networks as soon as possible. That makes it possible to lessen the transition effects in the UEs. - A tunneling mechanism in the UE may be needed during the early phases of the IPv6 transition process. A lightweight, automatic tunneling mechanism should be standardized in the IETF. - Tunneling mechanisms can be used in 3GPP networks, and [RFC3319])only generic recommendations are given in this document. More details can be used. Manual configuration or configuration overfound, for example, in [ISP-sa]. - We recommend that a detailed solution for the air is also possible. IMS subscriber authentication and registration togeneral SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the IMS andSIP integrity protection are not discussed here. 6.WGs in the IETF. 7. Security Considerations There areDeploying IPv6 has some generic security considerations when moving to dual- stack IPv4/IPv6 deployment which are not analyzed at length here. Two examplesone should be aware of [V6SEC]; however, these are ensuring that the access controls and firewalls have similar (or known) security properties with both IPv4 and IPv6, and that enabling IPv6 doesnot jeopardize the accessspecific to 3GPP transition, and are therefore out of the IPv4 services (e.g., in the formscope of misbehavior towards DNS AAAA record lookups or operationally worse quality IP transit services).this memo. This memo recommends the use of a relatively small number of techniques, which all of them have theirtechniques. Each technique has its own security considerations, including: - native upstream access or tunneling by the 3GPP network operator, - use of routing protocols to ensure redundancy, - use of locally-deployed specific-purpose protocol relays and application proxies to reach IPv4(-only) nodes from IPv6-only UEs, or - a specific mechanism for SIP signalling and media translation These (except for the last one, naturally) have relatively well- known security considerations, whichThe threats of configured tunneling are also discusseddescribed in [RFC2893-bis]. Attacks against routing protocols are described in the specific documents. However,respective documents and in particular one should note that a proper configuration of locally-deployedgeneral in [ROUTESEC]. Threats related to protocol relays and proxies is very important, so that the outsiders will nothave access to them,been described in [RFC3142]. The security properties of SIP internetworking are to be used for abuse, laundering attacks, or circumventing access controls.specified when the mechanism is specified. In particular, this memo does not recommend the following technique which has security issues, not further analyzed here: - NAT-PT or other translator as a generic-purposegeneral-purpose transition mechanism 7.8. References 7.18.1 Normative [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 3, RFC 2026, October 1996.[RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663,August 1999. [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm (SIIT), RFC 2765,February 2000. [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.[RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, RFC 3261,June 2002. [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP Networks, RFC 3574,August 2003. [RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004. [RFC3668] Bradner, S.: Intellectual Property Rights in IETF Technology, February 2004. [RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition Mechanisms for IPv6 Hosts and Routers", January 2004, draft-ietf- v6ops-mech-v2-02.txt, work in progress. [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002. [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements (Release 5)", December 2002. [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", December 2002. [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)", December 2002. [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 7.28.2 Informative [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description Protocol, RFC 2327,April 1998. [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay Translator, RFC 3142,June 2001. [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 in Session Description Protocol (SDP), June 2002. [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP Standards, September 2002. [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), July 2003. [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers, July 2003. [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6, December 2003. [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks", December 2003, draft-elmalki-sipping-3gpp-translator- 00.txt, work in progress. [DHCP-SL][RFC3736] Droms, R.: "Stateless DHCPStateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", January 2004, draft-ietf-dhc-dhcpv6-stateless-04.txt, work in progress.IPv6, April 2004. [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport operational guidelines", November 2003,March 2004, draft-ietf-dnsop-ipv6- transport-guidelines-01.txt,transport-guidelines-02.txt, work in progress. [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.: "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", FebruaryApril 2004, draft-ietf-ngtrans-isatap-20.txt,draft-ietf-ngtrans-isatap-21.txt, work in progress. [ISP-sa] Lind, M., Ksinant, V., Park, D.,D. and Baudot, A.: "Scenarios and Analysis for Introducing IPv6 into ISP Networks", FebruaryApril 2004, draft-ietf-v6ops-isp-scenarios-analysis-01.txt,draft-ietf-v6ops-isp-scenarios-analysis-02.txt, work in progress. [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.,S. and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati- v6ops-natpt-applicability-00.txt, work in progress. [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", January 2003, draft-durand-v6ops-natpt-dns-alg-issues-01.txt,[ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats- 06.txt, work in progress, the draft has expired.progress. [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup- 02.txt, work in progress. [V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security Considerations", February 2004, draft-savola-v6ops-security- overview-02.txt, work in progress. [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003. 8.[OMA-CP] OMA Client Provisioning: Provisioning Architecture Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile Alliance, 12-Nov-2002. 9. Contributors Pekka Savola has contributed both text and his IPv6 experience to this document. He has provided a large number of helpful comments on the v6ops mailing list. 9.Allison Mankin has contributed text for IMS Scenario 1 (section 4.1). 10. Authors and Acknowledgements This document is written by: Alain Durand, Sun Microsystems <Alain.Durand@sun.com> Karim El-Malki, Ericsson Radio Systems <Karim.El-Malki@era.ericsson.se> Niall Richard Murphy, Enigma Consulting Limited <firstname.lastname@example.org> Hugh Shieh, AT&T Wireless <email@example.com> Jonne Soininen, Nokia <firstname.lastname@example.org> Hesham Soliman, Flarion <email@example.com> Margaret Wasserman, ThingMagic <firstname.lastname@example.org> Juha Wiljakka, Nokia <email@example.com> The authors would like to give special thanks to Spencer Dawkins for proofreading. The authors would like to thank Heikki Almay, Gabor Bajko, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Meter for their valuable input. 10.11. Editor's Contact Information Comments or questions regarding this document should be sent to the v6ops mailing list or directly to the document editor: Juha Wiljakka Nokia Visiokatu 3 Phone: +358 7180 48372 FIN-33720 TAMPERE, Finland Email: firstname.lastname@example.org 11.12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights whichthat may cover technology that may be required to practiceimplement this standard. Please address the information to the IETF Executive Director. 12.at ietf- email@example.com. 13. Copyright The following copyright notice is copied from [RFC2026],[RFC3667], Section 10.4.5.4. It describes the applicable copyright for this document. Copyright (C) The Internet Society March 24, 2004. All Rights Reserved.(2004). This document and translations of it may be copied and furnishedis subject to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided thatthe above copyright notice and this paragraph are included on all such copiesrights, licenses and derivative works. However, this document itself may not be modifiedrestrictions contained in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78, and except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked byset forth therein, the Internet Society or its successors or assignees.authors retain all their rights. This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A - On the Use of Generic Translators in the 3GPP Networks This appendix lists mainly 3GPP-specific arguments about generic translators, even though the use of generic translators is discouraged. The section may be removed in future versions of the memo. 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). If NA(P)T-PTNAPT-PT is used, it needs to be placed on the GGSN external (Gi) interface, typically separate from the GGSN. NA(P)T-PTNAPT-PT can be installed, for example, on the edge of the operator's network and the public Internet. NA(P)T-PTNAPT-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. NA(P)T-PTNAPT-PT introduces limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed below (notice that most of them are also relevant for IPv4 NAT). [NATPTappl] discusses the applicability of NAT-PT in more detail. 1. NA(P)T-PTNAPT-PT is a single point of failure for all ongoing connections. 2. There are additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. There are problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. 4. NA(P)T-PTNAPT-PT does not work (without application level gateways) for applications that embed IP addresses in their payload. 5. NA(P)T-PTNAPT-PT breaks DNSSEC. 6. NA(P)T-PTNAPT-PT does not scale very well in large networks. 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 NA(P)T-PTNAPT-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 NA(P)T-PT,NAPT-PT, the following actions can be recommended: 1. Separate the DNS ALG from the NA(P)T-PTNAPT-PT node (in the "IPv6 to IPv4" case). 2. Ensure (if possible) that NA(P)T-PTNAPT-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 NA(P)T-PTNAPT-PT from becoming a single point of failure.