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
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
- 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.
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
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
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.
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
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
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.
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.
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.