From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4215.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc4215.txt (limited to 'doc/rfc/rfc4215.txt') diff --git a/doc/rfc/rfc4215.txt b/doc/rfc/rfc4215.txt new file mode 100644 index 0000000..dc45012 --- /dev/null +++ b/doc/rfc/rfc4215.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group J. Wiljakka, Ed. +Request for Comments: 4215 Nokia +Category: Informational October 2005 + + + Analysis on IPv6 Transition in + Third Generation Partnership Project (3GPP) Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +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) 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 and + 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 ..............................................3 + 1.3. Terminology ................................................5 + 2. Transition Mechanisms and DNS Guidelines ........................5 + 2.1. Dual Stack .................................................5 + 2.2. Tunneling ..................................................6 + 2.3. Protocol Translators .......................................6 + 2.4. DNS Guidelines for IPv4/IPv6 Transition ....................6 + 3. GPRS Transition Scenarios .......................................7 + 3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............7 + 3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4 + Network ....................................................8 + + + +Wiljakka Informational [Page 1] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 3.2.1. Tunneling Inside the 3GPP Operator's Network ........9 + 3.2.2. Tunneling Outside the 3GPP Operator's Network ......10 + 3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6 + Network ...................................................10 + 3.4. IPv6 UE Connecting to an IPv4 Node ........................11 + 3.5. IPv4 UE Connecting to an IPv6 Node ........................12 + 4. IMS Transition Scenarios .......................................12 + 4.1. UE Connecting to a Node in an IPv4 Network through IMS ....12 + 4.2. Two IPv6 IMS Connected via an IPv4 Network ................15 + 5. About 3GPP UE IPv4/IPv6 Configuration ..........................15 + 6. Summary and Recommendations ....................................16 + 7. Security Considerations ........................................17 + 8. References .....................................................17 + 8.1. Normative References ......................................17 + 8.2. Informative References ....................................18 + 9. Contributors ...................................................20 + 10. Authors and Acknowledgements ..................................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 [3GPP-23.060], in 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 that may come up in + the deployment phase of IPv6 in 3GPP packet data networks. + + The 3GPP network architecture is described in [RFC3314], and relevant + transition scenarios are documented in [RFC3574]. The reader of this + 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, which include Session Initiation Protocol (SIP) + considerations. For more information about IMS, see [3GPP-23.228], + [3GPP-24.228], and [3GPP-24.229]. + + GPRS scenarios are the following: + + - Dual Stack User Equipment (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 + + + +Wiljakka Informational [Page 2] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + - 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 connected via an IPv4 network + + The focus is on analyzing different transition scenarios and + 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 document is to analyze the possible transition + scenarios in the 3GPP-defined GPRS network in which a UE connects to, + or is contacted from, another node on the Internet. This document + covers scenarios with and without the use of the SIP-based IP + Multimedia Core Network Subsystem (IMS). This document does not + focus on radio-interface-specific issues; both 3GPP Second and Third + Generation radio network architectures (GSM, Enhanced Data rates for + GSM Evolution (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 + variations in its analysis. + + The transition mechanisms specified by the IETF Ngtrans and v6ops + Working Groups shall be used. This memo shall not specify any new + transition mechanisms, but only documents the need for new ones (if + appropriate). + +1.2. Abbreviations + + 2G Second Generation Mobile Telecommunications, e.g., GSM + and GPRS technologies + + 3G Third Generation Mobile Telecommunications, e.g., 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. + + + +Wiljakka Informational [Page 3] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + B2BUA Back-to-Back User Agent + + CSCF Call Session Control Function (in 3GPP Release 5 IMS) + + DNS Domain Name System + + EDGE Enhanced Data rates for GSM Evolution + + GGSN Gateway GPRS Support Node (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 Translation + + 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 + + SDP Session Description Protocol + + SGSN Serving GPRS Support Node + + SIIT Stateless IP/ICMP Translation Algorithm + + SIP Session Initiation Protocol + + UE User Equipment, e.g., a UMTS mobile handset + + UMTS Universal Mobile Telecommunications System + + WCDMA Wideband Code Division Multiple Access + + + + +Wiljakka Informational [Page 4] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +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 the IPv4-capable node + the UE is communicating with. The IPv4 node can be, + e.g., an application server or another UE. + + IPv6 node IPv6 node is here defined to be the IPv6-capable node + the UE is communicating with. The IPv6 node can be, + e.g., 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 section briefly introduces these IETF IPv4/IPv6 transition + mechanisms: + + - dual IPv4/IPv6 stack [RFC4213] + - tunneling [RFC4213] + - protocol translators [RFC2766], [RFC2765] + + In addition, DNS recommendations are given. The applicability of + different transition mechanisms to 3GPP networks is discussed in + sections 3 and 4. + +2.1. Dual Stack + + The dual IPv4/IPv6 stack is specified in [RFC4213]. 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 + + + +Wiljakka Informational [Page 5] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 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 [RFC2663] 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 [RFC4213]. + 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 Translation/Protocol Translation) [RFC2766] + using Stateless 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 take place at + the network layer (using NAT-like techniques), the transport layer + (using a TCP/UDP proxy), or the 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 visible only 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 [RFC3901] + for more information. + + + +Wiljakka Informational [Page 6] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +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 is not 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. + + Although the UE is dual stack, the UE may find itself attached to a + 3GPP 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, 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 + + + +Wiljakka Informational [Page 7] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 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 tunneling mechanism may require public IPv4 addresses, but there + are tunneling mechanisms and deployment scenarios in which private + IPv4 addresses may be used, for instance, if the tunnel endpoints are + in the same private domain, or the tunneling mechanism works through + IPv4 NAT. + + One deployment scenario uses 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 tunneling + mechanism depends on the laptop computer's support of tunneling + mechanisms. Another deployment scenario is performing 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 can be a good fit. There is not yet consensus on + the right approach, and proposed mechanisms so far include [ISATAP] + and [STEP]. Especially ISATAP has had some support in the working + group. Goals for 3GPP zero-configuration tunneling are documented in + [zeroconf]. + + This document strongly recommends that the 3GPP operators deploy + basic IPv6 support in their GPRS networks. That makes it possible to + lessen the transition effects in the 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 usually 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. + +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 does not have the dual stack functionality + needed for tunneling. The encapsulating node can be the GGSN, the + edge router between the border of the operator's IPv6 network and the + + + +Wiljakka Informational [Page 8] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 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 + 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 a + 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 depend on the deployment scenario. The authors are not + commenting on 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 + [RFC4029]. + +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 alone do not 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 the presence of other router redundancy + mechanisms, such as the use of IPv6 routing protocols. + + + + + +Wiljakka Informational [Page 9] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +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 but the upstream ISP does not provide IPv6 connectivity, the + encapsulating node could be the 3GPP 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 border + router to a dual stack border gateway operated by another ISP that 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. This + allows an IPv4-only UE to use an IPv4 link (an IPv4 PDP context) to + connect to the GGSN without communicating 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 choose 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. + + + + + + + +Wiljakka Informational [Page 10] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +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 the universal + deployment of IPv6 probably is not 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-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 be + 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-only + UEs. + + However, if there is a need to connect to an IPv4(-only) node from an + IPv6-only UE, it is recommended 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 are + 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"), or inside the service network. + + + + + + + +Wiljakka Informational [Page 11] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + The authors note that [NATPTappl] discusses the applicability of + NAT-PT, and [NATPTexp] discusses general issues with all forms of + IPv6-IPv4 translation. 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 typically 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 future 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 take + advantage of them. Thus, they will continue to support 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 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. + +4. IMS Transition Scenarios + + As IMS 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 connected via 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 (IPv6) IMS UE 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. + + Over time, users will upgrade the legacy IPv4 nodes to dual-stack, + often by replacing the entire node, eliminating this particular + problem in that specific deployment. + + + + + +Wiljakka Informational [Page 12] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + Still, it is difficult to estimate how many non-upgradable 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 may need to be used + in the communication between the IPv6 IMS and the legacy IPv4 hosts + in cases where these legacy IPv4 hosts cannot be upgraded to support + IPv6. + + This section gives a brief analysis of the IMS interworking issues + and presents a high-level view of SIP within the IMS. The authors + recommend that a detailed solution for the general SIP/SDP/media + IPv4/IPv6 transition problem will be specified as soon as possible as + a task within the SIP-related Working Groups in the IETF. + + The issue of the IPv4/IPv6 interworking in SIP is somewhat more + challenging than many other protocols. The control (or signaling) + and user (or data) traffic are separated in SIP calls, and thus, the + IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled + at two levels: + + 1. Session Initiation Protocol (SIP) [RFC3261], and Session + Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface) + + 2. the user data traffic (Mb-interface) + + In addition, SIP carries an SDP body containing the addressing and + other parameters for establishing the user data traffic (the media). + Hence, the two levels of interworking cannot be made independently. + + Figure 1 shows an example setup for IPv4 and IPv6 interworking in + IMS. The "Interworking Unit" comprises two internal elements a dual + stack SIP server and a transition gateway (TrGW) for the media + traffic. These two elements are interconnected for synchronizing the + interworking of the SIP signaling and the media traffic. + + + + + + + + + + + + + +Wiljakka Informational [Page 13] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + +-------------------------------+ +------------+ + | +------+ | | +--------+ | + | |S-CSCF|---| |SIP Serv| |\ + | | +------+ | | +--------+ | \ -------- + +-|+ | / | | | | | | + | | | +------+ +------+ | | + | -| |- + | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | + | | +------+ +------+ | |+----------+| / ------ + | |-----------------------------------|| TrGW ||/ + +--+ | IPv6 | |+----------+| IPv4 + UE | | |Interworking| + | IP Multimedia CN Subsystem | |Unit | + +-------------------------------+ +------------+ + + Figure 1: UE using IMS to contact a legacy phone + + On reception of an INVITE, the SIP server reserves an IP address and + a port from the TrGW both for IPv4 and IPv6. Then, the SIP server + acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the + INVITE to insert the transition gateway in the middle of the media + flow between the two endpoints. + + When performing its B2BUA role, the SIP server acts as a UA (User + Agent) toward both the IMS and the IPv4 host. Consequently, the SIP + server needs to support all the extensions that apply to the session, + which are listed in the Require header fields of the SIP messages. + + This approach has a number of important drawbacks, however. The + biggest drawback is that the rewriting of the SDP in the SIP + signaling prevents securing the SDP payload between the two + endpoints. In addition, it breaks the end-to-end negotiation of SIP + extensions required for each session. Therefore, the extensions to + be used in a particular session are limited by the extensions + supported by the SIP server acting as a B2BUA. That is, the + introduction of a new extension requires upgrading not only the UAs + but the B2BUAs as well. + + This analysis clearly shows that a new solution for IPv4-IPv6 + interworking in SIP networks is needed. The ability to convey + multiple alternative addresses in SDP session descriptions [RFC4091] + represents a step in this direction. + + Given the problems related to the use of B2BUAs, it is recommended + that the SIP-related Working Groups quickly work on a solution to + overcome the drawbacks of this approach. + + + + + + +Wiljakka Informational [Page 14] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +4.2. Two IPv6 IMS 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 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 of 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. + + UE configuration is required in order to access IPv6- or IPv4-based + 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 can, 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, he/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). A similar mechanism is also available for IPv6: so- + called Protocol Configuration Options Information Element (PCO-IE) + specified by the 3GPP [3GPP-24.008]. It is also possible to use + [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) [OMA-CP] or typed in manually in the UE. + + When accessing IMS services, the UE needs to know the Proxy-Call + Session Control Function (P-CSCF) IPv6 address. Either a 3GPP- + specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] and + [RFC3319]) can be used. Manual configuration or configuration over + + + + +Wiljakka Informational [Page 15] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 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 important. The two first GPRS + scenarios and both IMS scenarios are seen as 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 applications in + the UEs support IPv6. In other words, applications should be + IP version independent. 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 that the 3GPP operators + 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. See [zeroconf] for more details. + + - Tunneling mechanisms can be used in 3GPP networks, and only + generic recommendations are given in this document. More + details can be found, for example, in [RFC4029]. + + - The authors recommend that a detailed solution for the general + SIP/SDP/media IPv4/IPv6 transition problem be specified as soon + as possible as a task within the SIP-related Working Groups in + the IETF. + + + + + + + +Wiljakka Informational [Page 16] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +7. Security Considerations + + Deploying IPv6 has some generic security considerations one should be + aware of [V6SEC]; however, these are not specific to 3GPP transition + and are therefore out of the scope of this memo. + + This memo recommends the use of a relatively small number of + techniques. 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 signaling and media translation. + + The threats of configured tunneling are described in [RFC4213]. + Attacks against routing protocols are described in the respective + documents and in general in [ROUTESEC]. Threats related to protocol + relays have been described in [RFC3142]. The security properties of + SIP internetworking are to be 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 general-purpose transition + mechanism + +8. References + +8.1. Normative References + + [RFC2663] Srisuresh, P. and M. Holdrege, "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. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + + +Wiljakka Informational [Page 17] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", + RFC 3574, August 2003. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [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. + +8.2. Informative References + + [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport + Relay Translator", RFC 3142, June 2001. + + [RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for + IPv6 in Session Description Protocol (SDP)", RFC 3266, + June 2002. + + [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third + Generation Partnership Project (3GPP) Standards", RFC + 3314, September 2002. + + + + + + +Wiljakka Informational [Page 18] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host + Configuration Protocol (DHCPv6) Options for Session + Initiation Protocol (SIP) Servers", RFC 3319, July + 2003. + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, April + 2004. + + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport + Operational Guidelines", BCP 91, RFC 3901, September + 2004. + + [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. + Savola, "Scenarios and Analysis for Introducing IPv6 + into ISP Networks", RFC 4029, March 2005. + + [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative + Network Address Types (ANAT) Semantics for the Session + Description Protocol (SDP) Grouping Framework", RFC + 4091, June 2005. + + [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, + "Intra-Site Automatic Tunnel Addressing Protocol + (ISATAP)", RFC 4214, September 2005. + + [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. + and H. Wang, "NAT-PT Applicability", Work in Progress, + October 2003. + + [NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to + Experimental", Work in Progress, July 2005. + + [ROUTESEC] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats + to Routing Protocols", Work in Progress, April 2004. + + [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment + Procedure (STEP)", Work in Progress, January 2004. + + + + + +Wiljakka Informational [Page 19] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + [V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security + Considerations", Work in Progress, February 2004. + + [zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J., and + J. Wiljakka, "Goals for Zero-Configuration Tunneling in + 3GPP", Work in Progress, October 2004. + + [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. + + [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. Allison Mankin has contributed text for IMS + Scenario 1 (Section 4.1). + +10. Authors and Acknowledgements + + This document was written by: + + Alain Durand, Comcast + + + Karim El-Malki, Ericsson Radio Systems + + + Niall Richard Murphy, Enigma Consulting Limited + + + Hugh Shieh, AT&T Wireless + + + Jonne Soininen, Nokia + + + Hesham Soliman, Flarion + + + + + + + + + +Wiljakka Informational [Page 20] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + Margaret Wasserman, ThingMagic + + + Juha Wiljakka, Nokia + + + The authors would like to give special thanks to Spencer Dawkins for + proofreading. + + The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo + Camarillo, 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wiljakka Informational [Page 21] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +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. + + 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 NAPT-PT is used, it needs to be placed on the + GGSN external interface (Gi), typically separate from the GGSN. + NAPT-PT can be installed, for example, on the edge of the operator's + network and the public Internet. 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. + + NAPT-PT introduces limitations that are expected to be magnified + within the 3GPP architecture. [NATPTappl] discusses the + applicability of NAT-PT in more detail. [NATPTexp] discusses general + issues with all forms of IPv6-IPv4 translation. + + 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 can be recommended: + + 1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to + IPv4" case). + + 2. Ensure (if possible) that NAPT-PT does not become a single + point of failure. + + + + + + + +Wiljakka Informational [Page 22] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + + 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. + +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 + FIN-33720 TAMPERE, Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wiljakka Informational [Page 23] + +RFC 4215 IPv6 Transition in 3GPP Networks October 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are 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 DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to 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 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 that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Wiljakka Informational [Page 24] + -- cgit v1.2.3