One document matched: draft-ietf-v6ops-3gpp-analysis-07.txt
Differences from draft-ietf-v6ops-3gpp-analysis-06.txt
Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-07.txt Nokia
Expires: April 2004
October 2003
Analysis on IPv6 Transition in 3GPP Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document analyzes the transition to IPv6 in Third Generation
Partnership Project (3GPP) General Packet Radio Service (GPRS)
packet networks. The focus is on analyzing different transition
scenarios, applicable transition mechanisms and finding solutions
for those transition scenarios. In these scenarios, the User
Equipment (UE) connects to other nodes, e.g. in the Internet, and
IPv6/IPv4 transition mechanisms are needed.
Wiljakka, Editor Expires: April 2004 [Page 1]
Analysis on IPv6 Transition in 3GPP Networks October 2003
Table of Contents
1. Introduction..................................................2
1.1 Scope of this Document....................................3
1.2 Abbreviations.............................................3
1.3 Terminology...............................................4
2. Transition Mechanisms and DNS Guidelines......................4
2.1 Dual Stack................................................5
2.2 Tunneling.................................................5
2.3 Protocol Translators......................................5
2.4 DNS Guidelines for IPv4/IPv6 Transition...................6
3. GPRS Transition Scenarios.....................................6
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 8
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 10
3.4 IPv6 UE Connecting to an IPv4 Node.......................10
3.5 IPv4 UE Connecting to an IPv6 Node.......................11
4. IMS Transition Scenarios.....................................12
4.1 UE Connecting to a Node in an IPv4 Network through IMS...12
4.2 Two IMS Islands Connected over IPv4 Network..............14
5. About 3GPP UE IPv4/IPv6 Configuration........................14
6. Security Considerations......................................15
7. References...................................................15
7.1 Normative................................................15
7.2 Informative..............................................16
8. Contributors.................................................18
9. Authors and Acknowledgements.................................18
10. Editor's Contact Information................................19
11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt..........19
12. Intellectual Property Statement.............................19
13. Copyright...................................................19
Appendix A...................................................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. The authors can be found in
Authors and Acknowledgements section.
This document analyzes the transition scenarios in 3GPP packet
data networks that might come up in the deployment phase of IPv6.
The transition scenarios are documented in [RFC3574] and this
document will further analyze them. The scenarios are divided into
two categories: GPRS scenarios and IP Multimedia Subsystem (IMS)
scenarios.
Wiljakka, Editor Expires: April 2004 [Page 2]
Analysis on IPv6 Transition in 3GPP Networks October 2003
GPRS scenarios are the following:
- Dual Stack UE connecting to IPv4 and IPv6 nodes
- IPv6 UE connecting to an IPv6 node through an IPv4 network
- IPv4 UE connecting to an IPv4 node through an IPv6 network
- IPv6 UE connecting to an IPv4 node
- IPv4 UE connecting to an IPv6 node
IMS scenarios are the following:
- UE connecting to a node in an IPv4 network through IMS
- Two IMS islands connected via IPv4 network
The focus is on analyzing different transition scenarios,
applicable transition mechanisms and finding solutions for those
transition scenarios. In the scenarios, the User Equipment (UE)
connects to nodes in other networks, e.g. in the Internet and
IPv6/IPv4 transition mechanisms are needed.
1.1 Scope of this Document
The scope of this Best Current Practices document is to analyze and
solve the possible transition scenarios in the 3GPP defined GPRS
network where a UE connects to, or is contacted from, the Internet
or another UE. The document covers scenarios with and without the
use of the SIP based IP Multimedia Core Network Subsystem (IMS).
This document does not focus on radio interface issues; both 3GPP
Second (GSM) and Third Generation (UMTS) radio network
architectures will be covered by these scenarios.
The transition mechanisms specified by the IETF Ngtrans and v6ops
Working Groups shall be used. This document shall not specify any
new transition mechanisms, but if a need for a new mechanism is
found, that will be reported to the IETF v6ops Working Group.
1.2 Abbreviations
2G Second Generation Mobile Telecommunications, for
example GSM and GPRS technologies.
3G Third Generation Mobile Telecommunications, for example
UMTS technology.
3GPP Third Generation Partnership Project
ALG Application Level Gateway
APN Access Point Name. The APN is a logical name referring
to a GGSN and an external network.
CSCF Call Session Control Function (in 3GPP Release 5 IMS)
DNS Domain Name System
GGSN Gateway GPRS Support Node (a default router for 3GPP
User Equipment)
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
Wiljakka, Editor Expires: April 2004 [Page 3]
Analysis on IPv6 Transition in 3GPP Networks October 2003
HLR Home Location Register
IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5
IPv6-only part of the network
ISP Internet Service Provider
NAT Network Address Translator
NAPT-PT Network Address Port Translation - Protocol Translation
NAT-PT Network Address Translation - Protocol Translation
PCO-IE Protocol Configuration Options Information Element
PDP Packet Data Protocol
PPP Point-to-Point Protocol
SGSN Serving GPRS Support Node
SIIT Stateless IP/ICMP Translation Algorithm
SIP Session Initiation Protocol
UE User Equipment, for example a UMTS mobile handset
UMTS Universal Mobile Telecommunications System
1.3 Terminology
Some terms used in 3GPP transition scenarios and analysis documents
are briefly defined here.
Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both
IPv4 and IPv6 stacks. It is capable of activating
both IPv4 and IPv6 Packet Data Protocol (PDP)
contexts. Dual stack UE may be capable of tunneling.
IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is
only capable of activating IPv6 PDP contexts.
IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is
only capable of activating IPv4 PDP contexts.
IPv4 node IPv4 node is here defined to be IPv4 capable node
the UE is communicating with. The IPv4 node can
be, for example, an application server or another
UE.
IPv6 node IPv6 node is here defined to be IPv6 capable node
the UE is communicating with. The IPv6 node can
be, for example, an application server or another
UE.
2. Transition Mechanisms and DNS Guidelines
This chapter briefly introduces some transition mechanisms
specified by the IETF. In addition to that, DNS recommendations are
given. The applicability of different transition mechanisms to 3GPP
networks is discussed in chapters 3 and 4.
Wiljakka, Editor Expires: April 2004 [Page 4]
Analysis on IPv6 Transition in 3GPP Networks October 2003
The IPv4/IPv6 transition methods can be divided to:
- dual IPv4/IPv6 stack
- tunneling
- protocol translators
2.1 Dual Stack
The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider
the 3GPP GPRS core network, dual stack implementation in the
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
public IPv4 addresses are a scarce resource and in many cases IPv4
NATs are deployed. Public/global IP addresses are also needed for
peer-to-peer services: the node needs a public/global IP address
that is visible to other nodes.
2.2 Tunneling
Tunneling is a transition mechanism that requires dual IPv4/IPv6
stack functionality in the encapsulating and decapsulating nodes.
Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
Tunneling can be static or dynamic. Static (configured) tunnels are
fixed IPv6 links over IPv4, and they are specified in [RFC2893].
Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where
the tunnel endpoints are not configured, i.e. the links are created
dynamically.
2.3 Protocol Translators
A translator can be defined as an intermediate component between a
native IPv4 node and a native IPv6 node to enable direct
communication between them without requiring any modifications to
the end nodes.
Header conversion is a translation mechanism. In header conversion,
IPv6 packet headers are converted to IPv4 packet headers, or vice
versa, and checksums are adjusted or recalculated if necessary.
NAT-PT (Network Address Translator / Protocol Translator) [RFC2766]
using SIIT [RFC2765] is an example of such a mechanism.
Translators may be needed in some cases when the communicating
nodes do not share the same IP version; in others, it may be
possible to avoid such communication altogether. Translation can
actually happen at Layer 3 (using NAT-like techniques), Layer 4
(using a TCP/UDP proxy) or Layer 7 (using application relays).
Wiljakka, Editor Expires: April 2004 [Page 5]
Analysis on IPv6 Transition in 3GPP Networks October 2003
2.4 DNS Guidelines for IPv4/IPv6 Transition
[DNStrans] provides guidelines to operate DNS in a mixed world of
IPv4 and IPv6 transport. The recommendations (including the
keywords) are copied verbatim from [DNStrans]:
"In order to preserve name space continuity, the following
administrative policies are RECOMMENDED:
- every recursive DNS server SHOULD be either IPv4-only or dual
stack,
- every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server.
This rules out IPv6-only DNS server performing full recursion and
DNS zones served only by IPv6-only DNS servers. This approach
could be revisited if/when translation techniques between IPv4 and
IPv6 were to be widely deployed.
In order to enforce the second point, the zone validation process
SHOULD ensure that there is at least one IPv4 address record
available for the name servers of any child delegations within the
zone."
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
Wiljakka, Editor Expires: April 2004 [Page 6]
Analysis on IPv6 Transition in 3GPP Networks October 2003
application it has started or depending on the address of the peer
host it needs to communicate with. If IPv6 PDP contexts are
available and IPv6-in-IPv4 tunneling is needed, it is recommended
to activate an IPv6 PDP context and perform tunneling in the
network. This case is described in more detail in section 3.2.
However, the UE may attach 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. 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 use of private IPv4 addresses in the UE depends on the support
of these addresses by the tunneling mechanism and the deployment
scenario. In some cases public IPv4 addresses are required, but if
the tunnel endpoints are in the same private domain, or the
tunneling mechanism works through IPv4 NAT, private IPv4 addresses
can be used. One deployment scenario example is using a laptop
computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in
IPv4 packets in the laptop computer and IPv4 PDP context is
activated. The used tunneling mechanism (automatic or configured)
in that case depends on the support of tunneling mechanisms in the
laptop computer.
To generally solve this problem (IPv6 not available in the 3GPP
network), this document strongly recommends the 3GPP operators to
deploy basic IPv6 support in their GPRS networks. That also makes
it possible to burden the transition effects in the network and
make the 3GPP UEs simpler.
As a general guideline, IPv6 communication is preferred to IPv4
communication going through IPv4 NATs to the same dual stack peer
node.
An application running on a UE can identify whether the endpoint is
an IPv4 or IPv6 capable node by examining the destination address.
Alternatively, if a user supplies a name to be resolved, the DNS
may contain records sufficient to identify which protocol should be
used to initiate the connection with the endpoint. In dual stack
networks, one of the main concerns of an operator is the correct
address space and routing management. The operator must maintain
address spaces for both protocols. Public IPv4 addresses are often
a scarce resource for the operator and typically it is not possible
for a UE to have a globally unique 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
Wiljakka, Editor Expires: April 2004 [Page 7]
Analysis on IPv6 Transition in 3GPP Networks October 2003
network. In large networks, NAT systems can become very complex,
expensive and difficult to maintain.
For DNS recommendations, we refer to section 2.4.
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
The best solution for this scenario is obtained with tunneling,
i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context
is activated between the UE and the GGSN. Tunneling is handled in
the network, because IPv6 UE is not capable of tunneling (it does
not have the dual stack functionality needed for tunneling). 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, tunneling
enables end-to-end IPv6 connectivity. Note that this scenario is
comparable to 6bone [6BONE] network operation.
IPv6-in-IPv4 tunnels between IPv6 islands can be either static or
dynamic. The selection of the type of tunneling mechanism is up to
the operator / ISP deployment scenario and only generic
recommendations can be given in this document.
The following subsections are focused on the usage of different
tunneling mechanisms when the peer node is in the operator's
network or outside the operator's network. The authors note that
where the actual 3GPP network ends and which parts of the network
belong to the ISP(s) also depends on the deployment scenario. The
authors are not commenting how many ISP functions the 3GPP operator
should perform. However, many 3GPP operators are ISPs of some sort
themselves. ISP networks' transition to IPv6 is analyzed in [ISP-
scen] and [ISP-an].
3.2.1 Tunneling inside the 3GPP Operator's Network
Many GPRS operators already have IPv4 backbone networks deployed
and they are gradually migrating them while introducing IPv6
islands. IPv6 backbones can be considered quite rare in the first
phases of the transition. If the 3GPP operator already has IPv6
widely deployed in its network, this subsection is not so relevant.
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.
Wiljakka, Editor Expires: April 2004 [Page 8]
Analysis on IPv6 Transition in 3GPP Networks October 2003
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 which are typically necessary
to manage large networks anyway.
Connection redundancy should also be noted as an important
requirement in 3GPP networks. Static tunnels on their own don't
provide a routing recovery solution for all scenarios where an IPv6
route goes down. However, they may provide an adequate solution
depending on the design of the network and in presence of other
router redundancy mechanisms. On the other hand, routing protocol
based mechanisms can provide redundancy.
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.
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 does not have an IP backbone, or has not implemented
IPv6 in it, the encapsulating node can be the GGSN. If the 3GPP
operator has an IP backbone, and has implemented IPv6 in it, but
the upstream ISP does not provide IPv6 connectivity to the
Internet, the encapsulating node can be the edge 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 edge router to a dual stack border gateway operated by another
ISP which is offering IPv6 connectivity.
In the tunneling scenarios above, usage of configured IPv6-in-IPv4
tunneling is recommended. As the number of the tunnels outside of
the 3GPP network is limited, no more than a couple of tunnels
should be needed.
Wiljakka, Editor Expires: April 2004 [Page 9]
Analysis on IPv6 Transition in 3GPP Networks October 2003
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
3GPP networks are expected to support both IPv4 and IPv6 for a long
time, on the UE-GGSN link and between the GGSN and external
networks. For this scenario, it is useful to split the end-to-end
IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-
v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and
IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4
link (PDP context) to connect to the GGSN without the need to
communicate over an IPv6 network.
Regarding the GGSN-to-v4NODE communication, typically the transport
network between the GGSN and external networks will support only
IPv4 in the early stages and migrate to dual stack, since these
networks are already deployed. Therefore it is not envisaged that
tunneling of IPv4-in-IPv6 will be required from the GGSN to
external IPv4 networks either. In the longer run, 3GPP operators
may need to phase out IPv4 UEs and the IPv4 transport network. This
would leave only IPv6 UEs.
Therefore, overall, the transition scenario involving an IPv4 UE
communicating with an IPv4 peer through an IPv6 network is not
considered very likely in 3GPP networks.
3.4 IPv6 UE Connecting to an IPv4 Node
Generally speaking, IPv6-only UEs may be easier to manage, but that
would require all services to be used over IPv6, and that may not
be 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 no longer be necessary.
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 possible 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):
Wiljakka, Editor Expires: April 2004 [Page 10]
Analysis on IPv6 Transition in 3GPP Networks October 2003
1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766])
in the local network (not recommended as a general solution),
2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4
TCP relay configured for a couple of ports only [RFC3142]) or
application proxies (e.g., HTTP proxy, SMTP relay) in the
local network, or
3. the use of specific-purpose mechanisms (as described above in
2) in the foreign network; these are indistinguishable from
the IPv6-enabled services from the IPv6 UE's perspective, and
not discussed further here.
For many applications, application proxies can be appropriate (e.g.
HTTP proxies, SMTP relays, etc.). Such application proxies will not
be transparent to the UE. Hence, a flexible mechanism with minimal
manual intervention should be used to configure these proxies on
IPv6 UEs. Within the 3GPP architecture, application proxies can be
placed on the GGSN external interface (Gi), or inside the service
network.
The authors note that [NATPTappl] discusses the applicability of
NAT-PT. The problems related to NAT-PT usage in 3GPP networks are
documented in appendix A.
3.5 IPv4 UE Connecting to an IPv6 Node
The legacy IPv4 nodes are mostly nodes that support the
applications that are popular today in the IPv4 Internet: mostly e-
mail and web-browsing. These applications will, of course, be
supported in the future IPv6 Internet. However, the legacy IPv4 UEs
are not going to be updated to support the 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
profit from them. Thus, they will continue to support the legacy
services.
Taking the above into account, the traffic to and from the legacy
IPv4 UE is restricted to a few applications. These applications
already mostly rely on proxies or local servers to communicate
between private address space networks and the Internet. The same
methods and technology can be used for IPv4 to IPv6 transition.
For DNS recommendations, we refer to section 2.4.
Wiljakka, Editor Expires: April 2004 [Page 11]
Analysis on IPv6 Transition in 3GPP Networks October 2003
4. IMS Transition Scenarios
As the 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 IMS islands connected over IPv4 network
For DNS recommendations, we refer to section 2.4. As DNS traffic is
not directly related to the IMS functionality, the recommendations
are not in contradiction with the IPv6-only nature of the IMS.
4.1 UE Connecting to a Node in an IPv4 Network through IMS
This scenario occurs when an IMS UE (IPv6) connects to a node in
the IPv4 Internet through the IMS, or vice versa. This happens when
the other node is a part of a different system than 3GPP, e.g. a
fixed PC, with only IPv4 capabilities.
The first priority is to upgrade the legacy IPv4 nodes to dual-
stack, eliminating this particular problem in that specific
deployment.
Still, it is difficult to estimate how many non-upgradeable legacy
IPv4 nodes need to communicate with the IMS UEs. It is assumed that
the solution described here is used for limited cases, in which
communications with a small number of legacy IPv4 SIP equipment are
needed.
As the IMS is exclusively IPv6 [3GPP 23.221], translators have to
be used in the communication between the IPv6 IMS and legacy IPv4
hosts, i.e. making a dual stack based solution is not feasible.
This section aims to give a brief overview on how that interworking
can be handled.
This section presents higher level details of a solution based on
the use of a translator and SIP ALG. [3GPPtr] provides additional
information and presents a bit different solution proposal based on
SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to
solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF
SIP wg(s).
As control (or signaling) and user (or data) traffic are separated
in SIP, and thus, the IMS, the translation of the IMS traffic has
to be done at two levels:
1)Session Initiation Protocol (SIP) [RFC3261], and
Session Description Protocol (SDP) [RFC2327] [RFC3266]
(Mm-interface)
Wiljakka, Editor Expires: April 2004 [Page 12]
Analysis on IPv6 Transition in 3GPP Networks October 2003
2)the user data traffic (Mb-interface)
SIP and SDP transition has to be made in an SIP/SDP Application
Level Gateway. The ALG has to change the IP addresses transported
in the SIP messages and the SDP payload of those messages to the
appropriate version. In addition, there has to be interoperability
for DNS queries; see section 2.4 for details.
On the user data transport level, the translation is IPv4-IPv6
protocol translation, where the user data traffic transported is
translated from IPv6 to IPv4, and vice versa.
The legacy IPv4 host's address can be mapped to an IPv6 address for
the IMS, and this address is then used within the IMS to route the
traffic to the appropriate user traffic translator. This mapping
can be done by the SIP/SDP ALG for the SIP traffic. The user
traffic translator would do the similar mapping for the user
traffic. However, in order to have an IPv4 address for the IMS UE,
and to be able to route the user traffic within the legacy IPv4
network to the correct translator, there has to be an IPv4 address
allocated for the duration of the session from the user traffic
translator. The allocation of this address from the user traffic
translator has to be done by the SIP/SDP ALG in order for the
SIP/SDP ALG to know the correct IPv4 address. This can be achieved
by using a protocol for the ALG to do the allocation.
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP ALG | |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------||Translator||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone
Figure 1 shows a possible configuration scenario where the SIP ALG
is separated from the CSCFs. The translator can either be set up in
a single device with both SIP translation and media translation, or
those functionalities can be divided to two different entities with
an interface in between. We call the combined network element on
the edge of the IPv6-only IMS an "Interworking Unit" in this
document. A SIP-specific translation mechanism, which could e.g.
Wiljakka, Editor Expires: April 2004 [Page 13]
Analysis on IPv6 Transition in 3GPP Networks October 2003
re-use limited subsets of NAT-PT [RFC2766], needs to be specified.
The problems related to NAT-PT are discussed in appendix A.
4.2 Two IMS Islands Connected over IPv4 Network
At the early stages of IMS deployment, there may be cases where two
IMS islands are separated by an IPv4 network such as the legacy
Internet. Here both the UEs and the IMS islands are IPv6-only.
However, the IPv6 islands are not connected natively with IPv6.
In this scenario, the end-to-end SIP connections are based on IPv6.
The only issue is to make connection between two IPv6-only IMS
islands over IPv4 network. This scenario is closely related to GPRS
scenario represented in section 3.2. and similar tunneling
solutions are applicable also in this scenario.
5. About 3GPP UE IPv4/IPv6 Configuration
This informative section aims to give a brief overview on the
configuration needed in the UE in order to access IP based
services. There can also be other application specific settings in
the UE that are not described here.
To be able to access IPv6 or IPv4 based services, settings need to
be done in the UE. 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 to configure the GPRS
settings. The user can visit the operator WWW page and subscribe
the GPRS Access Point settings to his/her UE and receive the
settings via Short Message Service (SMS). After the user has
accepted the settings and a PDP context has been activated, the
user can start browsing. The Access Point settings can also be
typed in manually or be pre-configured by the operator or the UE
manufacturer.
DNS server addresses typically also need to be configured in the
UE. In the case of IPv4 type PDP context, the (IPv4) DNS server
addresses can be received in the PDP context activation (a control
plane mechanism). Same kind of 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 [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS
server addresses. The authors note that the general IPv6 DNS
discovery problem is being solved by the IETF dnsop Working Group.
The DNS server addresses can also be received over the air (using
SMS), or typed in manually in the UE.
When accessing IMS services, the UE needs to know the P-CSCF IPv6
address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism
Wiljakka, Editor Expires: April 2004 [Page 14]
Analysis on IPv6 Transition in 3GPP Networks October 2003
([DHCPv6-SL] or [RFC3315] 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 are not discussed here.
6. Security Considerations
There are some generic security considerations when moving to dual-
stack IPv4/IPv6 deployment which are not analyzed at length here.
Two examples of these are ensuring that the access controls and
firewalls have similar (or known) security properties with both
IPv4 and IPv6, and that enabling IPv6 does not jeopardize the
access to the IPv4 services (e.g., in the form of misbehavior
towards DNS AAAA record lookups or operationally worse quality IP
transit services).
This memo recommends the use of a relatively small number of
techniques, which all of them have their own security
considerations, including:
- native upstream access or tunneling by the 3GPP network
operator,
- use of routing protocols to ensure redundancy,
- use of locally-deployed specific-purpose protocol relays and
application proxies to reach IPv4(-only) nodes from IPv6-only
UEs, or
- a specific mechanism for SIP signalling and media translation
These (except for the last one, naturally) have relatively well-
known security considerations, which are also discussed in the
specific documents. However, in particular one should note that a
proper configuration of locally-deployed relays and proxies is very
important, so that the outsiders will not have access to them, to
be used for abuse, laundering attacks, or circumventing access
controls.
In particular, this memo does not recommend the following technique
which has security issues, not further analyzed here:
- NAT-PT or other translator as a generic-purpose transition
mechanism,
7. References
7.1 Normative
[RFC2026] Bradner, S.: The Internet Standards Process -- Revision
3, RFC 2026, October 1996.
Wiljakka, Editor Expires: April 2004 [Page 15]
Analysis on IPv6 Transition in 3GPP Networks October 2003
[RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address
Translator (NAT) Terminology and Considerations, RFC 2663, August
1999.
[RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm
(SIIT), RFC 2765, February 2000.
[RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation
- Protocol Translation (NAT-PT), RFC 2766, February 2000.
[RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for
IPv6 Hosts and Routers, RFC 2893, August 2000.
[RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
RFC 3261, June 2002.
[RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP
Networks, RFC 3574, August 2003.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", December 2002.
[3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP
multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
December 2002.
[3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control
Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.
7.2 Informative
[RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Protocol, RFC 2327, April 1998.
[RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay
Translator, RFC 3142, June 2001.
[RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
in Session Description Protocol (SDP), June 2002.
[RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP
Standards, September 2002.
Wiljakka, Editor Expires: April 2004 [Page 16]
Analysis on IPv6 Transition in 3GPP Networks October 2003
[RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for
IPv6 (DHCPv6), July 2003.
[RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers, July 2003.
[3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for
SIP-based services in Third Generation Partnership Project (3GPP)
Networks", October 2003, draft-elmalki-sipping-3gpp-translator-
00.txt, work in progress.
[DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6",
August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in
progress.
[DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6
Service", October 2003, draft-ietf-dhc-dhcpv6-stateless-01.txt,
work in progress.
[DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport
operational guidelines", June 2003, draft-ietf-dnsop-ipv6-
transport-guidelines-00.txt, work in progress.
[ISP-an] Ksinant, V. (ed.): " Analysis of Transition Mechanisms for
Introducing IPv6 into ISP Networks", October 2003, draft-ksinant-
v6ops-isp-analysis-00.txt, work in progress.
[ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into
ISP Networks", October 2003, draft-lind-v6ops-isp-scenarios-01.txt,
work in progress.
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.,
Wang, H.: " NAT-PT Applicability ", October 2003, draft-satapati-
v6ops-natpt-applicability-00.txt, work in progress.
[NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766",
January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work
in progress, the draft has expired.
[v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.:
"Issues when translating between IPv4 and IPv6", January 2003,
draft-vanderpol-v6ops-translation-issues-00.txt, work in progress,
the draft has expired.
[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.
Wiljakka, Editor Expires: April 2004 [Page 17]
Analysis on IPv6 Transition in 3GPP Networks October 2003
[6BONE] http://www.6bone.net
8. Contributors
Pekka Savola has contributed both text and his IPv6 experience to
this document. He has provided a large number of helpful comments
on the v6ops mailing list.
9. Authors and Acknowledgements
This document is written by:
Alain Durand, Sun Microsystems
<Alain.Durand@sun.com>
Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se>
Niall Richard Murphy, Enigma Consulting Limited
<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, Nokia
<margaret.wasserman@nokia.com>
Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com>
The authors would like to thank Heikki Almay, Gabor Bajko, Ajay
Jain, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne,
Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van
Meter for their valuable input.
Wiljakka, Editor Expires: April 2004 [Page 18]
Analysis on IPv6 Transition in 3GPP Networks October 2003
10. Editor's Contact Information
Comments or questions regarding this document should be sent to the
v6ops mailing list or directly to the document editor:
Juha Wiljakka
Nokia
Visiokatu 3 Phone: +358 7180 48372
FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com
11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt
- 3.2.2 edited based on wg last call comments
- Editorial / textual changes in many sections
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Copyright
The following copyright notice is copied from [RFC2026], Section
10.4. It describes the applicable copyright for this document.
Copyright (C) The Internet Society October 26, 2003. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
Wiljakka, Editor Expires: April 2004 [Page 19]
Analysis on IPv6 Transition in 3GPP Networks October 2003
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A - On the Use of Generic Translators in the 3GPP Networks
This appendix lists mainly 3GPP-specific arguments about generic
translators, even though the use of generic translators is
discouraged. The section may be removed in future versions of the
memo.
Due to the significant lack of IPv4 addresses in some domains, port
multiplexing is likely to be a necessary feature for translators
(i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the
GGSN external (Gi) interface, typically separate from the GGSN.
NA(P)T-PT can be installed, for example, on the edge of the
operator's network and the public Internet. NA(P)T-PT will
intercept DNS requests and other applications that include IP
addresses in their payloads, translate the IP header (and payload
for some applications if necessary) and forward packets through its
IPv4 interface.
NA(P)T-PT introduces limitations that are expected to be magnified
within the 3GPP architecture. Some of these limitations are listed
below (notice that some of them are also relevant for IPv4 NAT).
[NATPTappl] discusses the applicability of NAT-PT in more detail.
1. NA(P)T-PT is a single point of failure for all ongoing
connections.
Wiljakka, Editor Expires: April 2004 [Page 20]
Analysis on IPv6 Transition in 3GPP Networks October 2003
2. There are additional forwarding delays due to further
processing, when compared to normal IP forwarding.
3. There are problems with source address selection due to the
inclusion of a DNS ALG on the same node [NATPT-DNS].
4. NA(P)T-PT does not work (without application level gateways)
for applications that embed IP addresses in their payload.
5. NA(P)T-PT breaks DNSSEC.
6. NA(P)T-PT does not scale very well in large networks.
3GPP networks are expected to handle a very large number of
subscribers on a single GGSN (default router). Each GGSN is
expected to handle hundreds of thousands of connections.
Furthermore, high reliability is expected for 3GPP networks.
Consequently, a single point of failure on the GGSN external
interface would raise concerns on the overall network reliability.
In addition, IPv6 users are expected to use delay-sensitive
applications provided by IMS. Hence, there is a need to minimize
forwarding delays within the IP backbone. Furthermore, due to the
unprecedented number of connections handled by the default routers
(GGSN) in 3GPP networks, a network design that forces traffic to go
through a single node at the edge of the network (typical NA(P)T-PT
configuration) is not likely to scale. Translation mechanisms
should allow for multiple translators, for load sharing and
redundancy purposes.
To minimize the problems associated with NA(P)T-PT, the following
actions can be recommended:
1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to
IPv4" case).
2. Ensure (if possible) that NA(P)T-PT does not become a single
point of failure.
3. Allow for load sharing between different translators. That is,
it should be possible for different connections to go through
different translators. Note that load sharing alone does not
prevent NA(P)T-PT from becoming a single point of failure.
Wiljakka, Editor Expires: April 2004 [Page 21] | PAFTECH AB 2003-2026 | 2026-04-23 09:24:57 |