RFC 4215
Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
Analysis on IPv6 Transition in 3GPP Networks (RFC 4215) 📡
Okay bestie, let's get into it! 🎀 This one is RFC 4215, titled Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. It was written by J. Wiljakka, Ed. from Nokia and published in October 2005. It's labelled Informational, which means it's here to inform the Internet community and does not define a standard. 🦋 Its header doesn't list anything it obsoletes or updates, so it's a standalone analysis. 💅
Status of This Memo ✨
Quick vibe check: this memo provides information for the Internet community. It does not specify an Internet standard of any kind, and distribution of it 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 built on General Packet Radio Service (GPRS) technology, and the radio network side is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The main focus is looking at different transition scenarios, the transition mechanisms that apply to them, and finding solutions for each one. 🔥 In these scenarios, the User Equipment (UE) connects to other nodes, for example on 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
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 ..................................201. Introduction ✨
This document describes and analyzes the process of moving to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks [3GPP-23.060]. The radio network architecture in these is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. 🌈
It analyzes the transition scenarios that MAY come up while IPv6 is being deployed in 3GPP packet data networks. 🫶
The 3GPP network architecture is described in [RFC3314], and the relevant transition scenarios are documented in [RFC3574]. The reader of this specification SHOULD be familiar with the material in these documents. 📚
The scenarios in this document fall into two categories. The first is general-purpose packet service scenarios, called GPRS scenarios here. The second is IP Multimedia Subsystem (IMS) scenarios, which include Session Initiation Protocol (SIP) considerations. For more on IMS, check out [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
- 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
Again, the main focus is on analyzing the different transition scenarios, the transition mechanisms that apply, and finding solutions for them. 🦋 In these scenarios the User Equipment (UE) connects to nodes in other networks, for example on the Internet, and IPv6/IPv4 transition mechanisms are needed. 👑
1.1. Scope of This Document 🎯
The scope here is analyzing the possible transition scenarios in the 3GPP-defined GPRS network, where a UE connects to another node on the Internet, or gets contacted from one. 🌸 It covers scenarios both with and without the SIP-based IP Multimedia Core Network Subsystem (IMS). It 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) are covered by this analysis. 💅
The 3GPP2 architecture is pretty similar to 3GPP in lots of ways, but it differs in enough details that this document does not include those 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. It only documents the need for new ones, if that's 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.
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 Access1.3. Terminology 📖
Here are some terms used in 3GPP transition scenarios and analysis documents, briefly defined so we're all on the same page. 🧸
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 gives a quick intro to these IETF IPv4/IPv6 transition mechanisms:
On top of that, DNS recommendations are given. 🌷 How the different transition mechanisms apply to 3GPP networks is discussed in sections 3 and 4. 💫
2.1. Dual Stack 🥞
The dual IPv4/IPv6 stack is specified in [RFC4213]. Now, if we look at the 3GPP GPRS core network, a dual stack implementation in the Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP contexts. 🍰 UEs with a dual stack and public (global) IP addresses can typically reach both IPv4 and IPv6 services without any additional translators in the network. 🙌
BUT it's 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, because 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. 🫧 The 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, which means the links get created dynamically. ⭐
2.3. Protocol Translators 🦋
okay so a translator is basically a middleman sitting between a native IPv4 node and a native IPv6 node 🧚 so they can talk directly to each other, and neither end node has to be modified at all. iconic, right?
Header conversion is one kind of translation mechanism 💅. IPv6 packet headers get converted into IPv4 packet headers (or the other way around), and checksums get adjusted or recalculated if needed. NAT-PT (Network Address Translation/Protocol Translation) [RFC2766], using Stateless IP/ICMP Translation [RFC2765], is an example of this.
Translators may be needed when the communicating nodes don't share the same IP version. In other cases, it may be possible to avoid that communication altogether ✨. Translation can happen 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 🌸
The goal here is to stop the DNS name space from splitting into chunks where some parts of DNS are only visible over IPv4 transport (or only over IPv6) 😭. The recommendation (as of this writing) is to always keep at least one authoritative server IPv4-enabled, and to make sure recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information.
3. GPRS Transition Scenarios 📱
This section looks at the scenarios that can come up 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 them, the UE is part of a network that has 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. The five scenarios are:
- 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
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. Lovely.
It is recommended to activate an IPv6 PDP context when talking to an IPv6 peer node, and an IPv4 PDP context when talking to an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate one depending on the type of application it has started, or depending on the address of the peer host it needs to reach. The authors leave the PDP context activation policy up to UE implementers, application developers, and operators. One discussed possibility is to activate both IPv4 and IPv6 types of PDP contexts in advance, because activating 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 means 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, it may find itself attached to a 3GPP network where the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts but not IPv6 PDP contexts. This can happen in early phases of IPv6 deployment, or because the UE has "roamed" from a 3GPP network that supports IPv6 to one that doesn't 💀. 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 tunneling mechanism may require public IPv4 addresses. But there are tunneling mechanisms and deployment scenarios where private IPv4 addresses may be used, for instance, if the tunnel endpoints are in the same private domain, or if 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 the proposed mechanisms so far include [ISATAP] and [STEP]. ISATAP in particular has had some support in the working group. Goals for 3GPP zero-configuration tunneling are documented in [zeroconf].
This document strongly recommends that 3GPP operators deploy basic IPv6 support in their GPRS networks. That makes it possible to lessen the transition effects on 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 a UE can't have a public IPv4 address allocated for its use (continuously). Using private IPv4 addresses means using 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 an IPv6 UE doesn't 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 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. Choosing 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 focus on using different tunneling mechanisms when the peer node is inside the operator's network or outside it. 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 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 contains the operator's IPv6 application servers. However, manually configured tunnels can become 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 eased 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 🧠.
3.2.2. Tunneling Outside the 3GPP Operator's Network 🌍
This subsection covers 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.
Where the tunnel starts can depend 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 doesn't 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.
As for GGSN-to-v4NODE communication, the transport network between the GGSN and external networks will typically support only IPv4 in the early stages, and migrate to dual stack later, 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.
3.4. IPv6 UE Connecting to an IPv4 Node ✨
okay so IPv6-only UEs might be easier to manage, bestie 🧚 but that would mean every single service has to run over IPv6, and honestly? Universal IPv6 probably isn't realistic anytime soon 😭 Dual stack means you're managing both IPv4 and IPv6 networks, which is a lot. One approach is that "legacy" apps keep using IPv4 for the foreseeable future, while new apps that need end-to-end connectivity (like peer-to-peer services) go with IPv6 💖 As a general guideline, IPv6-only UEs are not recommended in the early phases of transition, until IPv6 is so everywhere that talking to IPv4(-only) nodes is the exception and not the rule. It's assumed IPv4 will stick around for quite a long time, so in general, dual stack in the UE can be recommended 🫶 That naturally includes manufacturing dual stack UEs instead of IPv4-only ones, obviously 💅
BUT if you do need to reach an IPv4(-only) node from an IPv6-only UE, it's recommended to use specific translation and proxying techniques, and generic IP protocol translation is not recommended 🙈 There are three main ways IPv6(-only) nodes can talk to IPv4(-only) nodes (not counting just avoiding that communication in the first place, which is honestly iconic):
- the use of generic-purpose translator (e.g., NAT-PT [RFC2766]) in the local network (not recommended as a general solution),
- 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
- 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 lots of apps, application proxies can be a great fit (HTTP proxies, SMTP relays, etc.) 🍓 Just know that these proxies won't be transparent to the UE, so you'll want a flexible mechanism with minimal manual intervention to configure them on IPv6 UEs. No one wants to babysit that 😤 Application proxies can be placed, for example, on the GGSN external interface ("Gi"), or inside the service network.
The authors note that [NATPTappl] discusses the applicability of NAT-PT, and [NATPTexp] covers 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 🦋
okay so legacy IPv4 nodes are usually the ones running the apps that are popular on today's IPv4 Internet: mostly e-mail and web browsing 📧 These apps will, of course, still be supported on the future IPv6 Internet. BUT legacy IPv4 UEs aren't going to get updated to support future apps 😭 Those apps are designed for IPv6 and take advantage of newer platforms, so legacy IPv4 nodes won't be able to use them. So they'll just keep supporting legacy services, main character energy for the past 🎀
Taking all that into account, traffic to and from a legacy IPv4 UE is restricted to a few applications. These apps already mostly rely on proxies or local servers to talk between private address space networks and the Internet, and the same methods and technology can be used for IPv4-to-IPv6 transition ✨
4. IMS Transition Scenarios 💜
okay so IMS is exclusively IPv6, which means the number of possible transition scenarios drops dramatically 🫢 The possible IMS scenarios are listed below and analyzed in Sections 4.1 and 4.2:
- UE connecting to a node in an IPv4 network through IMS
- Two IPv6 IMS connected via an IPv4 network
For DNS recommendations, we refer to Section 2.4. DNS traffic isn't directly related to IMS functionality, so those recommendations don't contradict the IPv6-only nature of IMS 🧚
4.1. UE Connecting to a Node in an IPv4 Network through IMS 🌈
this scenario happens when an (IPv6) IMS UE connects to a node on the IPv4 Internet through IMS, or the other way around 📞 It shows up when the other node belongs to a system that isn't 3GPP, like a fixed PC with only IPv4 capabilities 💻
Over time, users will upgrade legacy IPv4 nodes to dual-stack, often by replacing the entire node, which clears up this problem in that specific deployment. yay 🙌
Still, it's hard to estimate how many non-upgradable legacy IPv4 nodes need to talk to IMS UEs. It's assumed the solution described here will only be used for limited cases, where a small number of legacy IPv4 SIP devices need to communicate 🤏
As IMS is exclusively IPv6 [3GPP-23.221], many IMS applications may need some kind of translators between the IPv6 IMS and legacy IPv4 hosts, in cases where those legacy IPv4 hosts can't be upgraded to support IPv6 😩
This section gives a brief analysis of the IMS interworking issues and a high-level view of SIP within IMS. 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 🫶
The IPv4/IPv6 interworking problem in SIP is a bit more challenging than with many other protocols 🥺 In SIP calls, the control (or signaling) traffic and the user (or data) traffic are separated. So the transition of IMS traffic from IPv6 to IPv4 has to be handled at two levels:
- Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
- the user data traffic (Mb-interface)
On top of that, SIP carries an SDP body containing the addressing and other parameters for setting up the user data traffic (the media). So the two levels of interworking cannot be handled independently 🤯
Figure 1 shows an example setup for IPv4 and IPv6 interworking in IMS. The "Interworking Unit" has two internal elements: a dual stack SIP server and a transition gateway (TrGW) for the media traffic. These two elements are interconnected so the SIP signaling and media traffic stay in sync 🔁
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |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 phoneWhen a INVITE comes in, 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 put the transition gateway in the middle of the media flow between the two endpoints 🔀
When it's doing its B2BUA role, the SIP server acts as a UA (User Agent) toward both the IMS and the IPv4 host. So 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 few important drawbacks, though 🚩 The biggest one is that rewriting the SDP in the SIP signaling prevents securing the SDP payload between the two endpoints. It also breaks the end-to-end negotiation of SIP extensions required for each session. So the extensions usable in a particular session are limited by what the SIP server acting as a B2BUA supports. In other words, introducing a new extension means 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] is a step in this direction 🪜
Given the problems with using B2BUAs, it's recommended that the SIP-related Working Groups quickly work on a solution to overcome the drawbacks of this approach 🙏
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, like the legacy Internet 🏝️ Here both the UEs and the IMS islands are IPv6 only. However, the IPv6 islands aren't connected natively with IPv6 🙃
In this scenario, the end-to-end SIP connections are based on IPv6. The only issue is connecting two IPv6-only IMS islands over an IPv4 network. This scenario is closely related to the GPRS scenario in Section 3.2. and similar tunneling solutions are applicable here too 🚇
5. About 3GPP UE IPv4/IPv6 Configuration 🎀
This informative section gives a brief overview of the configuration needed in the UE to access IP-based services. There can also be other application-specific settings in the UE that aren't described here 🧁
UE configuration is required to access IPv6- or IPv4-based services. The GGSN Access Point has to be defined when using, for example, the web-browsing app 🌐 One option is to use over-the-air configuration [OMA-CP] to set up the GPRS settings. The user can, for example, visit the operator's WWW page, subscribe the GPRS Access Point settings to their UE, and receive the settings via Short Message Service (SMS) 📲 After the user accepts the settings and a PDP context has been activated, they 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 🔍 For an IPv4 type PDP context, the (IPv4) DNS server addresses can be received during PDP context activation (a control plane mechanism). A similar mechanism is also available for IPv6: the so-called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It's 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 bring other mechanisms over time 👀 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 the air is also possible. IMS subscriber authentication and registration to the IMS, and SIP integrity protection, aren't discussed here 🔐
6. Summary and Recommendations 🎀
okay so this doc just did a deep dive on five GPRS and two IMS IPv6 transition scenarios 🧚 ngl that's a lot of scenarios bestie. Plenty of 3GPP networks are still using private IPv4 addresses today, so bringing in IPv6 is a big deal 💅. The two first GPRS scenarios and both IMS scenarios are the most relevant ones ✨. The authors wrap up with some main recommendations:
- Dual stack UEs are recommended instead of IPv4-only or IPv6-only UEs 💖. It's really important to make sure applications in the UEs support IPv6 🫶. In other words, applications should be IP version independent 🦋. IPv6-only UEs can become feasible once 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 🦋.
7. Security Considerations 🔐
okay bestie, this part is serious, so read it carefully 🙈. Deploying IPv6 has some generic security considerations you should be aware of [V6SEC]. However, these aren't specific to 3GPP transition, so they're out of scope for 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 that are 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.[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.[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.[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 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
<alain_durand@cable.comcast.com> - Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se> - 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, Flarion
<h.soliman@flarion.com> - Margaret Wasserman, ThingMagic
<margaret@thingmagic.com> - Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com>
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 🌸.
Appendix A - On the Use of Generic Translators in the 3GPP Networks ✨
okay so this appendix is basically the 3GPP-specific case against generic translators 🫶 even though the spec itself is like "eh, try not to use them" 💅
Port multiplexing is probably going to be a necessary feature for translators 😭 because some domains are seriously short on IPv4 addresses. That's where NAPT-PT (i.e., NAPT-PT) comes in. If you use it, it has to sit on the GGSN external interface (Gi), usually separate from the GGSN itself 🧚 For example, it can live on the edge between the operator's network and the public Internet. It'll intercept DNS requests and any other applications that stuff IP addresses into their payloads, translate the IP header (and the payload too, for some apps, if needed), and then forward packets out its IPv4 interface 🦋
NAPT-PT comes with limitations that are expected to be magnified inside the 3GPP architecture 💀 [NATPTappl] digs into how NAT-PT applies here, and [NATPTexp] covers the general issues with every form of IPv6-IPv4 translation 📚
Now the scale situation is kinda wild 😳 3GPP networks are expected to handle a massive number of subscribers on one GGSN (default router), with each GGSN expected to handle hundreds of thousands of connections. High reliability is also expected, so a single point of failure on the GGSN external interface would be a real concern for the whole network's reliability 🚨 IPv6 users are also expected to run delay-sensitive apps through IMS, so there's a need to minimize forwarding delays across the IP backbone ⚡ And because the default routers (GGSNs) are dealing with an unprecedented number of connections, a design that forces all traffic through one node at the edge (the typical NAPT-PT setup) is not likely to scale 📉 So translation mechanisms should allow for multiple translators, for load sharing and redundancy 🌈
To cut down on the NAPT-PT problems, here's what can be recommended 💖
- Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to IPv4" case).
- Ensure (if possible) that NAPT-PT does not become a single point of failure.
- 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 about this document should go to the v6ops mailing list, or straight to the document editor 💌
Juha Wiljakka
Nokia
Visiokatu 3
FIN-33720 TAMPERE, Finland
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.comFull 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 on whether any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document are valid or in scope, or whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. ✨ Info on how RFC documents deal with rights can be found in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification can all be found in the IETF online 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4215 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms