Internet Draft J. Wiljakka, Document: draft-wiljakka-3gpp-ipv6-transition-02.txt Editor Expires: May 2003 Nokia November 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: May 2003 [Page 1]
IPv6 Transition Solutions for 3GPP Networks Nov. 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................................................4 2.2 Tunneling.................................................5 2.3 Protocol translators......................................5 3. GPRS Transition scenarios.....................................6 3.1 Dual Stack UE connecting to IPv4 and IPv6 nodes...........6 3.2 IPv6 UE connecting to an IPv6 node through an IPv4 network 7 3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network 8 3.4 IPv6 UE connecting to an IPv4 node........................9 3.5 IPv4 UE connecting to an IPv6 node.......................10 4. Transition Scenarios with IMS................................11 4.1 DNS interworking in IMS..................................11 4.2 UE connecting to a node in an IPv4 network through IMS...12 4.3 Two IPv6 IMS UEs connected via an IPv4 network...........13 5. Security Considerations......................................13 6. Changes from draft-wiljakka-3gpp-ipv6-transition-01.txt......14 7. References...................................................14 8. Authors and Acknowledgements.................................16 9. Editor's Contact Information.................................16 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 v6ops 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 - comments and feedback from the people in the IETF v6ops 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 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 Wiljakka, Editor Expires: May 2003 [Page 2]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 Two IMS scenarios are: - UE connecting to a node in an IPv4 network through IMS - 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. 1.1 Scope of this Document The scope of this informational document is to 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 covers 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 transition mechanisms specified by the IETF Ngtrans / v6ops 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 v6ops 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 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 PPP Point-to-Point Protocol Wiljakka, Editor Expires: May 2003 [Page 3]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 SIIT Stateless IP/ICMP Translation Algorithm 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 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. 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 3 and 4. The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators 2.1 Dual Stack The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider the 3GPP GPRS core network, dual stack implementation in the GGSN enables support for both IPv4 and IPv6 and it is also needed to perform IPv6 in IPv4 tunneling. UEs with dual stack and public / Wiljakka, Editor Expires: May 2003 [Page 4]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 global IP addresses can often access both IPv4 and IPv6 services without additional translators in the network. 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. IPv6-in-IPv4 tunneling mechanisms are implemented by virtual interfaces that are configured over one or more physical IPv4 interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets when the IPv6 routing table determines that the next hop toward the IPv6 destination address is via a tunnel interface. Receiving nodes decapsulate IPv6 packets from IPv4 packets that arrive on tunnel interfaces. Tunneling can be static or dynamic. Static (configured) tunnel interfaces are virtual IPv6 point-to- point links over IPv4. They require static configuration of the IPv6 source, IPv6 next-hop and IPv4 destination addresses for IPv6- in-IPv4 encapsulation. The IPv6 destination address is specified by the application and is used to determine the IPv6 next-hop address via longest-prefix-match in the IPv6 routing table. Configured tunnels are specified in [RFC2893]. Dynamic (automatic) tunnel interfaces are virtual IPv6 point-to- multipoint links over IPv4. They require static configuration of the IPv6 source address only. Like in static tunneling, the IPv6 destination address is specified by the application and is used to determine the IPv6 next-hop address via a longest-prefix-match lookup in the IPv6 routing table. But unlike static tunnels, the IPv4 destination address is derived from the IPv6 next-hop address in some way, for example, via direct encoding in the IPv6 next-hop address. This enables stateless encapsulation of IPv6-in-IPv4. This means that the IPv4 source address is taken from an IPv4 interface over which the automatic tunnel is configured. Examples of dynamic tunneling mechanisms are "6to4" [RFC3056], ISATAP [ISATAP] and DSTM [DSTM]. 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. Wiljakka, Editor Expires: May 2003 [Page 5]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] using SIIT [RFC2765] 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) 3. GPRS Transition scenarios This section discusses 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 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. 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 3.1 Dual Stack UE connecting to IPv4 and IPv6 nodes In this scenario, the UE is capable of communicating with both IPv4 and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also requires that the GGSN is supporting both IPv4 and IPv6. The dual stack UE may have both stacks or only one of them active simultaneously. However, if the GGSN does not support IPv6, and an application on the UE needs to communicate with an IPv6 node, the UE may activate an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a dynamic or static tunneling mechanism. Tunneling in the UE requires dual stack capability in the UE and in many cases also a public IPv4 address allocated to the UE. One example case is using laptop computer and a UMTS UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and IPv4 PDP context is activated. "IPv6 in IPv4" tunneling in the UE can be user configurable or automatic. The latter alternative is more probable, because it is expected that most UE users just want to use an application in their UE; they might not even care, whether the network connection is IPv4 or IPv6. Wiljakka, Editor Expires: May 2003 [Page 6]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 When analyzing a dual stack UE behavior, 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]. Since the UE is capable of native communication with both protocols, one of the main concerns of an operator 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 IPv4 PDP contexts, and a desired resource exists outside of the operator network, the operator must implement a network address translation (NAT) gateway which will translate the private IPv4 addresses used by the UEs to public IPv4 addresses. 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. Both public and private IPv4 addresses might be a scarce resource for the operator or ISP. In this case, it is not 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 a private address space, either by requesting a specific APN or by receiving it via some address allocation mechanism. In this scenario, the UE talks to the DNS resolver using the IP version that is available. The DNS resolver in the network should be dual stack. 3.2 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 (it does not have the dual stack functionality needed for tunneling). Wiljakka, Editor Expires: May 2003 [Page 7]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 Encapsulating node can be e.g. the GGSN or the edge router between the border of the operator's 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. Note that this scenario is comparable to 6bone [6BONE] network operation. 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 BGP tunneling [BGP] also is an alternative. The selection of the used tunneling mechanism is up to the operator / ISP deployment scenario and straightforward recommendation can not be given. In initial, smaller scale IPv6 deployment, dynamic tunneling mechanisms, such as "6to4" [RFC3056] can make sense. But in larger scale deployment, static tunneling might be the best solution (for example, static tunnels from the GGSN to the IPv6 Internet). Static tunnels can scale better than dynamic tunnels in very big networks; usually a number of configured tunnels is sufficient. In the case of dynamic tunneling, the number of needed tunnels easily becomes very much higher. If we consider "6to4" tunneling mechanism and 3GPP addressing model (a unique /64 prefix allocated for each primary PDP context), one /48 "6to4" prefix would be sufficient only for approximately 65000 UEs. If 6to4 mechanism is used, it is good to remember following issues: - 6to4 reverse DNS is not yet completely solved. - 6to4 will require relay routers, and there are some security considerations associated with them, see [6to4SEC]. 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. 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 Wiljakka, Editor Expires: May 2003 [Page 8]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 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 considered very likely in 3GPP networks. 3.4 IPv6 UE connecting to an IPv4 node IPv6 nodes can communicate with IPv4 hosts by making use of a translator (SIIT [RFC2765], NAT-PT [RFC2766]) 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 independent of 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. NA(P)T-PT). When NA(P)T-PT is used, it needs to be placed on the GGSN external (Gi) interface, typically separate from the GGSN. NA(P)T-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-PT introduces a number of limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed here: 1. NA(P)T-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. NA(P)T-PT does not work (without application level gateways) for applications that embed IP addresses in their payload. Wiljakka, Editor Expires: May 2003 [Page 9]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 5. NA(P)T-PT breaks DNSSEC. 6. NA(P)T-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-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, the following actions are recommended: 1. Separate the DNS ALG from the NA(P)T-PT node. 2. Ensure that NA(P)T-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-PT from becoming a single point of failure. There are certain ways to fix the problems with NA(P)T-PT, one suggestion is [NAT64]. When thinking the DNS issues, the IPv6 UE needs to find the IPv4 address in the DNS, thus the DNS resolver in the network must be dual stack. Note that DNSSEC is broken if NA(P)T-PT is used. 3.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 Wiljakka, Editor Expires: May 2003 [Page 10]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 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]. When thinking the DNS issues, the DNS zones containing AAAA records for the IPv6 nodes need to be served by at least one IPv4 accessible DNS server. 4. Transition Scenarios with IMS 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 4.2 and 4.3. 1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS islands connected via an IPv4 network 4.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. 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. As DNS traffic is not directly related to the IMS functionality, this is not in contradiction with the IPv6-only nature of the IMS. Wiljakka, Editor Expires: May 2003 [Page 11]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 4.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. Apparently 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 are separated in SIP, and thus, the IMS, the translation of the IMS traffic has to be done on two levels - Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] 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 4.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. 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]. Wiljakka, Editor Expires: May 2003 [Page 12]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 +-------------------------------+ +----------+ | +------+ | |+--------+| | |S-CSCF|---||SIP ALG ||\ | | +------+ | |+--------+| \ -------- +-|+ | / | | | | | | | | | +------+ +------+ | | + | -| |- | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | | +------+ +------+ | |+--------+| / ------ | |-----------------------------------|| NAT-PT ||/ +--+ | IPv6 | |+--------+| IPv4 UE | | | | | IP Multimedia CN Subsystem | |Translator| +-------------------------------+ +----------+ Figure 1: UE using IMS to contact a legacy phone Figure 1 shows a possible configuration scenario where the SIP ALG is separate to the CSCFs. The translator can either be set up in a single device with both SIP translation and media translation, or those functionalities can be divided to two different entities with an interface in between. 4.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 3.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 be a good solution. Note that this scenario is comparable to 6bone [6BONE] network operation. 5. 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]. Wiljakka, Editor Expires: May 2003 [Page 13]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 2. The 3GPP specifications do not currently define the usage of DNS Security. They neither disallow the usage of DNSSEC, nor do they mandate it. 3. NAT-PT breaks DNSSEC. 6. Changes from draft-wiljakka-3gpp-ipv6-transition-01.txt - Editorial changes in some sections 7. References [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description Protocol, RFC 2327, April 1998. [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. [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. [RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol, June 2002. [RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in Session Description Protocol (SDP), June 2002. [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP Standards", September 2002. [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP Networks", October 2002, draft-ietf-v6ops-3gpp-cases-00.txt, work in progress. [6to4SEC] Savola, P.: "Security Considerations for 6to4", October 2002, draft-savola-v6ops-6to4-security-00.txt, work in progress. Wiljakka, Editor Expires: May 2003 [Page 14]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 [BGP] De Clercq, J., Gastaud, G., Nguyen, T., Ooms, D., Prevost, S., Le Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with BGP", January 2002, draft-ietf-ngtrans-bgp-tunnel-04.txt, work in progress, the draft has expired. [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, the draft has expired. [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress. [ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", October 2002, draft-ietf-ngtrans- isatap-05.txt, work in progress. [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- ngtrans-nat64-nat46-00.txt, work in progress. [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, the draft has expired. [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, the draft has expired. [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. [COMMC1] Personal communication with author from Crevan Murply, a Core Networks employee in O2. [6BONE] http://www.6bone.net Wiljakka, Editor Expires: May 2003 [Page 15]
IPv6 Transition Solutions for 3GPP Networks Nov. 2002 8. Authors and Acknowledgements This document is written by the v6ops 3GPP IPv6 transition design team chaired by Jonne Soininen, Nokia. The members of the design team are: Alain Durand, Sun Microsystems <Alain.Durand@sun.com> Karim El-Malki, Ericsson Radio Systems <Karim.El-Malki@era.ericsson.se> Paul Francis, Tahoe Networks <francis@tahoenetworks.com> Niall Richard Murphy, Enigma Consulting Limited <niallm@enigma.ie> Hugh Shieh, AT&T Wireless <hugh.shieh@attws.com> Jonne Soininen, Nokia <jonne.soininen@nokia.com> Hesham Soliman, Ericsson Radio Systems <hesham.soliman@era.ericsson.se> Margaret Wasserman, Wind River <mrw@windriver.com> Juha Wiljakka, Nokia <juha.wiljakka@nokia.com> The authors would like to thank Gabor Bajko, Fred Templin and Rod Van Meter for their valuable input. 9. 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 Sinitaival 5 Phone: +358 7180 47562 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com Wiljakka, Editor Expires: May 2003 [Page 16]