draft-ietf-v6ops-3gpp-analysis-09.txt   draft-ietf-v6ops-3gpp-analysis-10.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-09.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-10.txt Nokia
Expires: September 2004 Expires: November 2004
March 2004 May 2004
Analysis on IPv6 Transition in 3GPP Networks Analysis on IPv6 Transition in 3GPP Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document analyzes the transition to IPv6 in Third Generation This document analyzes the transition to IPv6 in Third Generation
Partnership Project (3GPP) General Packet Radio Service (GPRS) Partnership Project (3GPP) packet networks. These networks are
packet networks. The focus is on analyzing different transition based on General Packet Radio Service (GPRS) technology, and the
scenarios, applicable transition mechanisms and finding solutions radio network architecture is based on Global System for Mobile
for those transition scenarios. In these scenarios, the User Communications (GSM), or Universal Mobile Telecommunications System
Equipment (UE) connects to other nodes, e.g. in the Internet, and (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology.
IPv6/IPv4 transition mechanisms are needed.
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.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
1.1 Scope of this Document....................................3 1.1 Scope of this Document....................................3
1.2 Abbreviations.............................................3 1.2 Abbreviations.............................................4
1.3 Terminology...............................................4 1.3 Terminology...............................................4
2. Transition Mechanisms and DNS Guidelines......................5 2. Transition Mechanisms and DNS Guidelines......................5
2.1 Dual Stack................................................5 2.1 Dual Stack................................................5
2.2 Tunneling.................................................5 2.2 Tunneling.................................................5
2.3 Protocol Translators......................................5 2.3 Protocol Translators......................................6
2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6
3. GPRS Transition Scenarios.....................................6 3. GPRS Transition Scenarios.....................................6
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6 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 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
..............................................................8 .............................................................8
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
.............................................................10 ............................................................10
3.4 IPv6 UE Connecting to an IPv4 Node.......................10 3.4 IPv6 UE Connecting to an IPv4 Node.......................10
3.5 IPv4 UE Connecting to an IPv6 Node.......................11 3.5 IPv4 UE Connecting to an IPv6 Node.......................11
4. IMS Transition Scenarios.....................................12 4. IMS Transition Scenarios.....................................12
4.1 UE Connecting to a Node in an IPv4 Network through IMS...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 4.2 Two IPv6 IMS Connected via an IPv4 Network...............14
5. About 3GPP UE IPv4/IPv6 Configuration........................14 5. About 3GPP UE IPv4/IPv6 Configuration........................14
6. Security Considerations......................................15 6. Summary and Recommendations..................................15
7. References...................................................16 7. Security Considerations......................................16
7.1 Normative................................................16 8. References...................................................16
7.2 Informative..............................................16 8.1 Normative................................................16
8. Contributors.................................................18 8.2 Informative..............................................17
9. Authors and Acknowledgements.................................18 9. Contributors.................................................19
10. Editor's Contact Information................................19 10. Authors and Acknowledgements................................19
11. Intellectual Property Statement.............................19 11. Editor's Contact Information................................20
12. Copyright...................................................19 12. Intellectual Property Statement.............................20
Appendix A...................................................20 13. Copyright...................................................20
Appendix A...................................................21
1. Introduction 1. Introduction
This document describes and analyzes the process of transition to This document describes and analyzes the process of transition to
IPv6 in Third Generation Partnership Project (3GPP) General Packet IPv6 in Third Generation Partnership Project (3GPP) General Packet
Radio Service (GPRS) packet networks. The authors can be found in Radio Service (GPRS) packet networks, in which the radio network
Authors and Acknowledgements section. 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 in 3GPP packet This document analyzes the transition scenarios that may come up in
data networks that might come up in the deployment phase of IPv6. the deployment phase of IPv6 in 3GPP packet data networks.
The transition scenarios are documented in [RFC3574] and this The 3GPP network architecture is described in [RFC3314], and
document will further analyze them. The scenarios are divided into relevant transition scenarios are documented in [RFC3574]. The
two categories: GPRS scenarios and IP Multimedia Subsystem (IMS) reader of this specification should be familiar with the material
scenarios. 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.
GPRS scenarios are the following: GPRS scenarios are the following:
- Dual Stack UE connecting to IPv4 and IPv6 nodes - Dual Stack UE connecting to IPv4 and IPv6 nodes
- IPv6 UE connecting to an IPv6 node through an IPv4 network - IPv6 UE connecting to an IPv6 node through an IPv4 network
- IPv4 UE connecting to an IPv4 node through an IPv6 network - IPv4 UE connecting to an IPv4 node through an IPv6 network
- IPv6 UE connecting to an IPv4 node - IPv6 UE connecting to an IPv4 node
- IPv4 UE connecting to an IPv6 node - IPv4 UE connecting to an IPv6 node
IMS scenarios are the following: IMS scenarios are the following:
- UE connecting to a node in an IPv4 network through IMS - UE connecting to a node in an IPv4 network through IMS
- Two IMS islands connected via IPv4 network - Two IPv6 IMS connected via an IPv4 network
The focus is on analyzing different transition scenarios, The focus is on analyzing different transition scenarios,
applicable transition mechanisms and finding solutions for those applicable transition mechanisms and finding solutions for those
transition scenarios. In the scenarios, the User Equipment (UE) transition scenarios. In the scenarios, the User Equipment (UE)
connects to nodes in other networks, e.g. in the Internet and connects to nodes in other networks, e.g. in the Internet and
IPv6/IPv4 transition mechanisms are needed. IPv6/IPv4 transition mechanisms are needed.
1.1 Scope of this Document 1.1 Scope of this Document
The scope of this Best Current Practices document is to analyze and The scope of this document is to analyze the possible transition
solve the possible transition scenarios in the 3GPP defined GPRS scenarios in the 3GPP defined GPRS network where a UE connects to,
network where a UE connects to, or is contacted from, the Internet or is contacted from, another node on the Internet. The document
or another UE. The document covers scenarios with and without the covers scenarios with and without the use of the SIP-based IP
use of the SIP based IP Multimedia Core Network Subsystem (IMS). Multimedia Core Network Subsystem (IMS). This document does not
This document does not focus on radio interface issues; both 3GPP focus on radio interface-specific issues; both 3GPP Second and
Second (GSM) and Third Generation (UMTS) radio network Third Generation radio network architectures (GSM, EDGE and
architectures will be covered by these scenarios. 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 The transition mechanisms specified by the IETF Ngtrans and v6ops
Working Groups shall be used. This document shall not specify any Working Groups shall be used. This memo shall not specify any new
new transition mechanisms, but if a need for a new mechanism is transition mechanisms, but only documents the need for new ones (if
found, that will be reported to the IETF v6ops Working Group. appropriate).
1.2 Abbreviations 1.2 Abbreviations
2G Second Generation Mobile Telecommunications, for 2G Second Generation Mobile Telecommunications, for
example GSM and GPRS technologies. example GSM and GPRS technologies.
3G Third Generation Mobile Telecommunications, for example 3G Third Generation Mobile Telecommunications, for example
UMTS technology. UMTS technology.
3GPP Third Generation Partnership Project 3GPP Third Generation Partnership Project
ALG Application Level Gateway ALG Application Level Gateway
APN Access Point Name. The APN is a logical name referring APN Access Point Name. The APN is a logical name referring
to a GGSN and an external network. to a GGSN and an external network.
CSCF Call Session Control Function (in 3GPP Release 5 IMS) CSCF Call Session Control Function (in 3GPP Release 5 IMS)
DNS Domain Name System DNS Domain Name System
GGSN Gateway GPRS Support Node (a default router for 3GPP GGSN Gateway GPRS Support Node (default router for 3GPP
User Equipment) User Equipment)
GPRS General Packet Radio Service GPRS General Packet Radio Service
GSM Global System for Mobile Communications GSM Global System for Mobile Communications
HLR Home Location Register HLR Home Location Register
IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5
IPv6-only part of the network IPv6-only part of the network
ISP Internet Service Provider ISP Internet Service Provider
NAT Network Address Translator NAT Network Address Translator
NAPT-PT Network Address Port Translation - Protocol Translation NAPT-PT Network Address Port Translation - Protocol Translation
NAT-PT Network Address Translation - Protocol Translation NAT-PT Network Address Translation - Protocol Translation
PCO-IE Protocol Configuration Options Information Element PCO-IE Protocol Configuration Options Information Element
PDP Packet Data Protocol PDP Packet Data Protocol
PPP Point-to-Point Protocol PPP Point-to-Point Protocol
SGSN Serving GPRS Support Node SGSN Serving GPRS Support Node
SIIT Stateless IP/ICMP Translation Algorithm SIIT Stateless IP/ICMP Translation Algorithm
SIP Session Initiation Protocol SIP Session Initiation Protocol
UE User Equipment, for example a UMTS mobile handset UE User Equipment, for example a UMTS mobile handset
UMTS Universal Mobile Telecommunications System UMTS Universal Mobile Telecommunications System
WCDMA Wideband Code Division Multiple Access
1.3 Terminology 1.3 Terminology
Some terms used in 3GPP transition scenarios and analysis documents Some terms used in 3GPP transition scenarios and analysis documents
are briefly defined here. are briefly defined here.
Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both
IPv4 and IPv6 stacks. It is capable of activating IPv4 and IPv6 stacks. It is capable of activating
both IPv4 and IPv6 Packet Data Protocol (PDP) both IPv4 and IPv6 Packet Data Protocol (PDP)
contexts. Dual stack UE may be capable of tunneling. contexts. Dual stack UE may be capable of tunneling.
skipping to change at page 5, line 5 skipping to change at page 5, line 15
IPv4 node IPv4 node is here defined to be IPv4 capable node IPv4 node IPv4 node is here defined to be IPv4 capable node
the UE is communicating with. The IPv4 node can the UE is communicating with. The IPv4 node can
be, for example, an application server or another be, for example, an application server or another
UE. UE.
IPv6 node IPv6 node is here defined to be IPv6 capable node IPv6 node IPv6 node is here defined to be IPv6 capable node
the UE is communicating with. The IPv6 node can the UE is communicating with. The IPv6 node can
be, for example, an application server or another be, for example, an application server or another
UE. 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 2. Transition Mechanisms and DNS Guidelines
This chapter briefly introduces some transition mechanisms This chapter briefly introduces these IETF IPv4/IPv6 transition
specified by the IETF. In addition to that, DNS recommendations are mechanisms:
given. The applicability of different transition mechanisms to 3GPP
networks is discussed in chapters 3 and 4.
The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack [RFC2893-bis]
- tunneling [RFC2893-bis]
- protocol translators [RFC 2766], [RFC2765]
- dual IPv4/IPv6 stack In addition, DNS recommendations are given. The applicability of
- tunneling different transition mechanisms to 3GPP networks is discussed in
- protocol translators chapters 3 and 4.
2.1 Dual Stack 2.1 Dual Stack
The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider The dual IPv4/IPv6 stack is specified in [RFC2893-bis]. If we
the 3GPP GPRS core network, dual stack implementation in the consider the 3GPP GPRS core network, dual stack implementation in
Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 the Gateway GPRS Support Node (GGSN) enables support for IPv4 and
PDP contexts. UEs with dual stack and public (global) IP addresses IPv6 PDP contexts. UEs with dual stack and public (global) IP
can typically access both IPv4 and IPv6 services without additional addresses can typically access both IPv4 and IPv6 services without
translators in the network. However, it is good to remember that additional translators in the network. However, it is good to
private IPv4 addresses and NATs have been used and will be used in remember that private IPv4 addresses and NATs have been used and
mobile networks. Public/global IP addresses are also needed for will be used in mobile networks. Public/global IP addresses are
peer-to-peer services: the node needs a public/global IP address also needed for peer-to-peer services: the node needs a
that is visible to other nodes. public/global IP address that is visible to other nodes.
2.2 Tunneling 2.2 Tunneling
Tunneling is a transition mechanism that requires dual IPv4/IPv6 Tunneling is a transition mechanism that requires dual IPv4/IPv6
stack functionality in the encapsulating and decapsulating nodes. stack functionality in the encapsulating and decapsulating nodes.
Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
Tunneling can be static or dynamic. Static (configured) tunnels are Tunneling can be static or dynamic. Static (configured) tunnels are
fixed IPv6 links over IPv4, and they are specified in [RFC2893]. fixed IPv6 links over IPv4, and they are specified in [RFC2893-
Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where bis]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4
the tunnel endpoints are not configured, i.e. the links are created where the tunnel endpoints are not configured, i.e. the links are
dynamically. created dynamically.
2.3 Protocol Translators 2.3 Protocol Translators
A translator can be defined as an intermediate component between a A translator can be defined as an intermediate component between a
native IPv4 node and a native IPv6 node to enable direct native IPv4 node and a native IPv6 node to enable direct
communication between them without requiring any modifications to communication between them without requiring any modifications to
the end nodes. the end nodes.
Header conversion is a translation mechanism. In header conversion, Header conversion is a translation mechanism. In header conversion,
IPv6 packet headers are converted to IPv4 packet headers, or vice IPv6 packet headers are converted to IPv4 packet headers, or vice
skipping to change at page 6, line 4 skipping to change at page 6, line 18
2.3 Protocol Translators 2.3 Protocol Translators
A translator can be defined as an intermediate component between a A translator can be defined as an intermediate component between a
native IPv4 node and a native IPv6 node to enable direct native IPv4 node and a native IPv6 node to enable direct
communication between them without requiring any modifications to communication between them without requiring any modifications to
the end nodes. the end nodes.
Header conversion is a translation mechanism. In header conversion, Header conversion is a translation mechanism. In header conversion,
IPv6 packet headers are converted to IPv4 packet headers, or vice IPv6 packet headers are converted to IPv4 packet headers, or vice
versa, and checksums are adjusted or recalculated if necessary. versa, and checksums are adjusted or recalculated if necessary.
NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] NAT-PT (Network Address Translator / Protocol Translator) [RFC2766]
using SIIT [RFC2765] is an example of such a mechanism. using Stateless IP/ICMP Translation [RFC2765] is an example of such
a mechanism.
Translators may be needed in some cases when the communicating Translators may be needed in some cases when the communicating
nodes do not share the same IP version; in others, it may be nodes do not share the same IP version; in others, it may be
possible to avoid such communication altogether. Translation can possible to avoid such communication altogether. Translation can
actually happen at Layer 3 (using NAT-like techniques), Layer 4 take place at the network layer (using NAT-like techniques), the
(using a TCP/UDP proxy) or Layer 7 (using application relays). transport layer (using a TCP/UDP proxy) or the application layer
(using application relays).
2.4 DNS Guidelines for IPv4/IPv6 Transition 2.4 DNS Guidelines for IPv4/IPv6 Transition
To avoid the DNS name space from fragmenting into parts where some To avoid the DNS name space from fragmenting into parts where some
parts of DNS are only visible using IPv4 (or IPv6) transport, the parts of DNS are only visible using IPv4 (or IPv6) transport, the
recommendation (as of this writing) is to always keep at least one recommendation (as of this writing) is to always keep at least one
authoritative server IPv4-enabled, and to ensure that recursive DNS authoritative server IPv4-enabled, and to ensure that recursive DNS
servers support IPv4. See DNS IPv6 transport guidelines [DNStrans] servers support IPv4. See DNS IPv6 transport guidelines [DNStrans]
for more information. for more information.
skipping to change at page 6, line 43 skipping to change at page 7, line 9
1) Dual Stack UE connecting to IPv4 and IPv6 nodes 1) Dual Stack UE connecting to IPv4 and IPv6 nodes
2) IPv6 UE connecting to an IPv6 node through an IPv4 network 2) IPv6 UE connecting to an IPv6 node through an IPv4 network
3) IPv4 UE connecting to an IPv4 node through an IPv6 network 3) IPv4 UE connecting to an IPv4 node through an IPv6 network
4) IPv6 UE connecting to an IPv4 node 4) IPv6 UE connecting to an IPv4 node
5) IPv4 UE connecting to an IPv6 node 5) IPv4 UE connecting to an IPv6 node
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes
In this scenario, the dual stack UE is capable of communicating In this scenario, the dual stack UE is capable of communicating
with both IPv4 and IPv6 nodes. It is recommended to activate an with both IPv4 and IPv6 nodes.
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 isn't good usage of network resources. It is recommended to activate an IPv6 PDP context when
Generally speaking, IPv6 PDP contexts should be preferred even if communicating with an IPv6 peer node and an IPv4 PDP context when
that meant IPv6-in-IPv4 tunneling would be needed in the network communicating with an IPv4 peer node. If the 3GPP network supports
(see section 3.2 for more details). Note that this is transparent both IPv4 and IPv6 PDP contexts, the UE activates the appropriate
to the UE. 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 isn't 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.
However, the UE may attach to a 3GPP network, in which the Serving Although the UE is dual-stack, the UE may find itself attached to a
GPRS Support Node (SGSN), the GGSN, and the Home Location Register 3GPP network in which the Serving GPRS Support Node (SGSN), the
(HLR) support IPv4 PDP contexts, but do not support IPv6 PDP GGSN, and the Home Location Register (HLR) support IPv4 PDP
contexts. This may happen in early phases of IPv6 deployment. If contexts, but do not support IPv6 PDP contexts. This may happen in
the 3GPP network does not support IPv6 PDP contexts, and an early phases of IPv6 deployment, or because the UE has "roamed"
application on the UE needs to communicate with an IPv6(-only) from a 3GPP network that supports IPv6 to one that does not. If the
node, the UE may activate an IPv4 PDP context and encapsulate IPv6 3GPP network does not support IPv6 PDP contexts, and an application
packets in IPv4 packets using a tunneling mechanism. 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 used tunneling mechanism may require public IPv4 addresses, but The tunneling mechanism may require public IPv4 addresses, but
there are tunneling mechanisms and deployment scenarios in which there are tunneling mechanisms and deployment scenarios in which
the usage of private IPv4 addresses is possible. If the tunnel private IPv4 addresses may be used; for instance, if the tunnel
endpoints are in the same private domain, or the tunneling endpoints are in the same private domain, or the tunneling
mechanism works through IPv4 NAT, private IPv4 addresses can be mechanism works through IPv4 NAT.
used. One deployment scenario example is using a laptop computer
and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 One deployment scenario uses a laptop computer and a 3GPP UE as a
packets in the laptop computer and an IPv4 PDP context is modem. IPv6 packets are encapsulated in IPv4 packets in the laptop
activated. The used tunneling mechanism in that case depends on the computer and an IPv4 PDP context is activated. The tunneling
support of tunneling mechanisms in the laptop computer. Another mechanism depends on the laptop computerís support of tunneling
deployment scenario is making IPv6-in-IPv4 tunneling in the UE mechanisms. Another deployment scenario is performing IPv6-in-IPv4
itself and activating an IPv4 PDP context. tunneling in the UE itself and activating an IPv4 PDP context.
Closer details for an applicable tunneling mechanism are not Closer details for an applicable tunneling mechanism are not
analyzed in this document. However, a simple host-to-router analyzed in this document. However, a simple host-to-router
(automatic) tunneling mechanism may be a good fit. There is not yet (automatic) tunneling mechanism may be a good fit. There is not yet
consensus on the right approach. Primarily, ISATAP [ISATAP] has consensus on the right approach, and proposed mechanisms so far
been proposed, but some issues have been raised about it, such as include [ISATAP] and [STEP]. Especially ISATAP has had some support
its unnecessary features and relative complexity for a simple task in the wg. However, further work is needed to find out the
like this, and its inadequacy in providing security when crossing requirements for the scenario and to specify the mechanism.
administrative domains. Proposed solution alternatives have been
(at least) a simplified, but probably non-interoperable, version of
ISATAP, and STEP [STEP]. In any case, further work is needed to
find out the requirements for the scenario and to specify the
mechanism.
To generally solve this problem (IPv6 not available in the 3GPP This document strongly recommends the 3GPP operators to deploy
network), this document strongly recommends the 3GPP operators to basic IPv6 support in their GPRS networks. That makes it possible
deploy basic IPv6 support in their GPRS networks. That also makes to lessen the transition effects in the UEs.
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 As a general guideline, IPv6 communication is preferred to IPv4
communication going through IPv4 NATs to the same dual stack peer communication going through IPv4 NATs to the same dual stack peer
node. node.
Public IPv4 addresses are often a scarce resource for the operator Public IPv4 addresses are often a scarce resource for the operator
and typically it is not possible for a UE to have a public IPv4 and usually it is not possible for a UE to have a public IPv4
address (continuously) allocated for its use. Use of private IPv4 address (continuously) allocated for its use. Use of private IPv4
addresses means use of NATs when communicating with a peer node addresses means use of NATs when communicating with a peer node
outside the operator's network. In large networks, NAT systems can outside the operator's network. In large networks, NAT systems can
become very complex, expensive and difficult to maintain. 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 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
The best solution for this scenario is obtained with tunneling, The best solution for this scenario is obtained with tunneling,
i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context 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 is activated between the UE and the GGSN. Tunneling is handled in
the network, because IPv6 UE is not capable of tunneling (it does the network, because IPv6 UE does not have the dual stack
not have the dual stack functionality needed for tunneling). The functionality needed for tunneling. The encapsulating node can be
encapsulating node can be the GGSN, the edge router between the the GGSN, the edge router between the border of the operator's IPv6
border of the operator's IPv6 network and the public Internet, or network and the public Internet, or any other dual stack node
any other dual stack node within the operator's IP network. The within the operator's IP network. The encapsulation (uplink) and
encapsulation (uplink) and decapsulation (downlink) can be handled decapsulation (downlink) can be handled by the same network
by the same network element. Typically the tunneling handled by the element. Typically the tunneling handled by the network elements is
network elements is transparent to the UEs and IP traffic looks transparent to the UEs and IP traffic looks like native IPv6
like native IPv6 traffic to them. For the applications, tunneling traffic to them. For the applications and transport protocols,
enables end-to-end IPv6 connectivity. tunneling enables end-to-end IPv6 connectivity.
IPv6-in-IPv4 tunnels between IPv6 islands can be either static or IPv6-in-IPv4 tunnels between IPv6 islands can be either static or
dynamic. The selection of the type of tunneling mechanism is up to dynamic. The selection of the type of tunneling mechanism is a
the operator / ISP deployment scenario and only generic policy decision for the operator / ISP deployment scenario and only
recommendations can be given in this document. generic recommendations can be given in this document.
The following subsections are focused on the usage of different The following subsections are focused on the usage of different
tunneling mechanisms when the peer node is in the operator's tunneling mechanisms when the peer node is in the operator's
network or outside the operator's network. The authors note that network or outside the operator's network. The authors note that
where the actual 3GPP network ends and which parts of the network where the actual 3GPP network ends and which parts of the network
belong to the ISP(s) also depends on the deployment scenario. The belong to the ISP(s) also depends on the deployment scenario. The
authors are not commenting how many ISP functions the 3GPP operator authors are not commenting how many ISP functions the 3GPP operator
should perform. However, many 3GPP operators are ISPs of some sort should perform. However, many 3GPP operators are ISPs of some sort
themselves. ISP networks' transition to IPv6 is analyzed in [ISP- themselves. ISP networks' transition to IPv6 is analyzed in [ISP-
sa]. sa].
skipping to change at page 9, line 23 skipping to change at page 9, line 25
operator's IPv4 network, manually configured tunnels can be used. operator's IPv4 network, manually configured tunnels can be used.
In a 3GPP network, one IPv6 island can contain the GGSN while In a 3GPP network, one IPv6 island can contain the GGSN while
another island can contain the operator's IPv6 application servers. another island can contain the operator's IPv6 application servers.
However, manually configured tunnels can be an administrative However, manually configured tunnels can be an administrative
burden when the number of islands and therefore tunnels rises. In burden when the number of islands and therefore tunnels rises. In
that case, upgrading parts of the backbone to dual stack may be the that case, upgrading parts of the backbone to dual stack may be the
simplest choice. The administrative burden could also be mitigated simplest choice. The administrative burden could also be mitigated
by using automated management tools. by using automated management tools.
Connection redundancy should also be noted as an important Connection redundancy should also be noted as an important
requirement in 3GPP networks. Static tunnels on their own don't requirement in 3GPP networks. Static tunnels alone don't provide a
provide a routing recovery solution for all scenarios where an IPv6 routing recovery solution for all scenarios where an IPv6 route
route goes down. However, they can provide an adequate solution goes down. However, they can provide an adequate solution depending
depending on the design of the network and in presence of other on the design of the network and the presence of other router
router redundancy mechanisms, such as the use of IPv6 routing redundancy mechanisms, such as the use of IPv6 routing protocols.
protocols.
3.2.2 Tunneling outside the 3GPP Operator's Network 3.2.2 Tunneling outside the 3GPP Operator's Network
This subsection includes the case in which the peer node is outside 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 the operator's network. In that case, IPv6-in-IPv4 tunneling can be
necessary to obtain IPv6 connectivity and reach other IPv6 nodes. necessary to obtain IPv6 connectivity and reach other IPv6 nodes.
In general, configured tunneling can be recommended. In general, configured tunneling can be recommended.
Tunnel starting point can be in the operator's network depending on Tunnel starting point can be in the operator's network depending on
how far the 3GPP operator has come in implementing IPv6. If the how far the 3GPP operator has come in implementing IPv6. If the
3GPP operator has not deployed IPv6 in its backbone, the 3GPP operator has not deployed IPv6 in its backbone, the
encapsulating node can be the GGSN. If the 3GPP operator has encapsulating node can be the GGSN. If the 3GPP operator has
deployed IPv6 in its backbone, but the upstream ISP does not deployed IPv6 in its backbone but the upstream ISP does not provide
provide IPv6 connectivity to the Internet, the encapsulating node IPv6 connectivity, the encapsulating node could be the 3GPP
can be the edge router. operator's border router.
The case is pretty straightforward if the upstream ISP provides The case is pretty straightforward if the upstream ISP provides
IPv6 connectivity to the Internet and the operator's backbone IPv6 connectivity to the Internet and the operator's backbone
network supports IPv6. Then the 3GPP operator does not have to network supports IPv6. Then the 3GPP operator does not have to
configure any tunnels, since the upstream ISP will take care of configure any tunnels, since the upstream ISP will take care of
routing IPv6 packets. If the upstream ISP does not provide IPv6 routing IPv6 packets. If the upstream ISP does not provide IPv6
connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from
the edge router to a dual stack border gateway operated by another the border router to a dual stack border gateway operated by
ISP which is offering IPv6 connectivity. another ISP which is offering IPv6 connectivity.
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 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 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 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 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- IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-
v4NODE. Therefore an IPv4-only UE will be able to use an IPv4 link v4NODE. This allows an IPv4-only UE to use an IPv4 link (an IPv4
(PDP context) to connect to the GGSN without the need to PDP context) to connect to the GGSN without communicating over an
communicate over an IPv6 network. IPv6 network.
Regarding the GGSN-to-v4NODE communication, typically the transport Regarding the GGSN-to-v4NODE communication, typically the transport
network between the GGSN and external networks will support only network between the GGSN and external networks will support only
IPv4 in the early stages and migrate to dual stack, since these IPv4 in the early stages and migrate to dual stack, since these
networks are already deployed. Therefore it is not envisaged that networks are already deployed. Therefore it is not envisaged that
tunneling of IPv4-in-IPv6 will be required from the GGSN to tunneling of IPv4-in-IPv6 will be required from the GGSN to
external IPv4 networks either. In the longer run, 3GPP operators external IPv4 networks either. In the longer run, 3GPP operators
may need to phase out IPv4 UEs and the IPv4 transport network. This may choose to phase out IPv4 UEs and the IPv4 transport network.
would leave only IPv6 UEs. This would leave only IPv6 UEs.
Therefore, overall, the transition scenario involving an IPv4 UE Therefore, overall, the transition scenario involving an IPv4 UE
communicating with an IPv4 peer through an IPv6 network is not communicating with an IPv4 peer through an IPv6 network is not
considered very likely in 3GPP networks. considered very likely in 3GPP networks.
3.4 IPv6 UE Connecting to an IPv4 Node 3.4 IPv6 UE Connecting to an IPv4 Node
Generally speaking, IPv6-only UEs may be easier to manage, but that 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 would require all services to be used over IPv6, and the universal
be realistic in the near future. Dual stack implementation requires deployment of IPv6 probably isnít realistic in the near future.
management of both IPv4 and IPv6 networks and one approach is that Dual stack implementation requires management of both IPv4 and IPv6
"legacy" applications keep using IPv4 for the foreseeable future networks and one approach is that "legacy" applications keep using
and new applications requiring end-to-end connectivity (for IPv4 for the foreseeable future and new applications requiring end-
example, peer-to-peer services) use IPv6. As a general guideline, to-end connectivity (for example, peer-to-peer services) use IPv6.
IPv6-only UEs are not recommended in the early phases of transition As a general guideline, IPv6-only UEs are not recommended in the
until the IPv6 deployment has become so prevalent that direct early phases of transition until the IPv6 deployment has become so
communication with IPv4(-only) nodes will no longer be necessary. prevalent that direct communication with IPv4(-only) nodes will be
It is assumed that IPv4 will remain useful for quite a long time, the exception, and not the rule. It is assumed that IPv4 will
so in general, dual-stack implementation in the UE can be remain useful for quite a long time, so in general, dual-stack
recommended. This recommendation naturally includes manufacturing implementation in the UE can be recommended. This recommendation
dual-stack UEs instead of IPv4-only UEs. 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 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 an IPv6-only UE, it is recommended to use specific translation and
proxying techniques; generic IP protocol translation is not proxying techniques; generic IP protocol translation is not
recommended. There are three main ways for IPv6(-only) nodes to recommended. There are three main ways for IPv6(-only) nodes to
communicate with IPv4(-only) nodes (excluding avoiding such communicate with IPv4(-only) nodes (excluding avoiding such
communication in the first place): communication in the first place):
1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766]) 1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766])
in the local network (not recommended as a general solution), in the local network (not recommended as a general solution),
2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4
TCP relay configured for a couple of ports only [RFC3142]) or TCP relay configured for a couple of ports only [RFC3142]) or
skipping to change at page 11, line 23 skipping to change at page 11, line 25
3. the use of specific-purpose mechanisms (as described above in 3. the use of specific-purpose mechanisms (as described above in
2) in the foreign network; these are indistinguishable from 2) in the foreign network; these are indistinguishable from
the IPv6-enabled services from the IPv6 UE's perspective, and the IPv6-enabled services from the IPv6 UE's perspective, and
not discussed further here. not discussed further here.
For many applications, application proxies can be appropriate (e.g. For many applications, application proxies can be appropriate (e.g.
HTTP proxies, SMTP relays, etc.). Such application proxies will not HTTP proxies, SMTP relays, etc.). Such application proxies will not
be transparent to the UE. Hence, a flexible mechanism with minimal be transparent to the UE. Hence, a flexible mechanism with minimal
manual intervention should be used to configure these proxies on manual intervention should be used to configure these proxies on
IPv6 UEs. Application proxies can be placed, for example, on the IPv6 UEs. Application proxies can be placed, for example, on the
GGSN external interface (Gi), or inside the service network. GGSN external interface ("Gi"), or inside the service network.
The authors note that [NATPTappl] discusses the applicability of The authors note that [NATPTappl] discusses the applicability of
NAT-PT. The problems related to NAT-PT usage in 3GPP networks are NAT-PT. The problems related to NAT-PT usage in 3GPP networks are
documented in appendix A. documented in appendix A.
3.5 IPv4 UE Connecting to an IPv6 Node 3.5 IPv4 UE Connecting to an IPv6 Node
The legacy IPv4 nodes are mostly nodes that support the The legacy IPv4 nodes are typically nodes that support the
applications that are popular today in the IPv4 Internet: mostly e- applications that are popular today in the IPv4 Internet: mostly e-
mail and web-browsing. These applications will, of course, be mail and web-browsing. These applications will, of course, be
supported in the future IPv6 Internet. However, the legacy IPv4 UEs supported in the future IPv6 Internet. However, the legacy IPv4 UEs
are not going to be updated to support the future applications. As are not going to be updated to support future applications. As
these applications are designed for IPv6, and to use the advantages these applications are designed for IPv6, and to use the advantages
of newer platforms, the legacy IPv4 nodes will not be able to of newer platforms, the legacy IPv4 nodes will not be able to take
profit from them. Thus, they will continue to support the legacy advantage of them. Thus, they will continue to support legacy
services. services.
Taking the above into account, the traffic to and from the legacy Taking the above into account, the traffic to and from the legacy
IPv4 UE is restricted to a few applications. These applications IPv4 UE is restricted to a few applications. These applications
already mostly rely on proxies or local servers to communicate already mostly rely on proxies or local servers to communicate
between private address space networks and the Internet. The same between private address space networks and the Internet. The same
methods and technology can be used for IPv4 to IPv6 transition. methods and technology can be used for IPv4 to IPv6 transition.
For DNS recommendations, we refer to section 2.4.
4. IMS Transition Scenarios 4. IMS Transition Scenarios
As the IMS is exclusively IPv6, the number of possible transition As IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically. The possible IMS scenarios are scenarios is reduced dramatically. The possible IMS scenarios are
listed below and analyzed in sections 4.1 and 4.2. listed below and analyzed in sections 4.1 and 4.2.
1) UE connecting to a node in an IPv4 network through IMS 1) UE connecting to a node in an IPv4 network through IMS
2) Two IMS islands connected over IPv4 network 2) Two IPv6 IMS connected via an IPv4 network
For DNS recommendations, we refer to section 2.4. As DNS traffic is For DNS recommendations, we refer to section 2.4. As DNS traffic is
not directly related to the IMS functionality, the recommendations not directly related to the IMS functionality, the recommendations
are not in contradiction with the IPv6-only nature of the IMS. 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 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 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 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 the other node is a part of a different system than 3GPP, e.g. a
fixed PC, with only IPv4 capabilities. fixed PC, with only IPv4 capabilities.
The first priority is to upgrade the legacy IPv4 nodes to dual- Over time, users will upgrade the legacy IPv4 nodes to dual-stack,
stack, eliminating this particular problem in that specific often by replacing the entire node, eliminating this particular
deployment. problem in that specific deployment.
Still, it is difficult to estimate how many non-upgradeable legacy Still, it is difficult to estimate how many non-upgradeable legacy
IPv4 nodes need to communicate with the IMS UEs. It is assumed that IPv4 nodes need to communicate with the IMS UEs. It is assumed that
the solution described here is used for limited cases, in which the solution described here is used for limited cases, in which
communications with a small number of legacy IPv4 SIP equipment are communications with a small number of legacy IPv4 SIP equipment are
needed. needed.
As the IMS is exclusively IPv6 [3GPP 23.221], translators have to As the IMS is exclusively IPv6 [3GPP 23.221], for many of the
be used in the communication between the IPv6 IMS and legacy IPv4 applications in the IMS, some kind of translators may need to
hosts, i.e. making a dual stack based solution is not feasible. be used in the communication between the IPv6 IMS and the legacy
This section aims to give a brief overview on how that interworking IPv4 hosts in cases where these legacy IPv4 hosts cannot be
can be handled. upgraded to support IPv6.
This section presents higher level details of a solution based on This section gives a brief analysis of the IMS interworking issues,
the use of a translator and SIP ALG. [3GPPtr] provides additional and presents a high level view of SIP within the IMS. The authors
information and presents a bit different solution proposal based on recommend that a detailed solution for the general SIP/SDP/media
SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to IPv4/IPv6 transition problem will be specified as soon as possible
solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF as a task within the SIP WGs in the IETF.
SIP wg(s).
As control (or signaling) and user (or data) traffic are separated As control (or signaling) and user (or data) traffic are separated
in SIP, and thus, the IMS, the translation of the IMS traffic has in SIP calls, and thus, the IMS, the transition of IMS traffic from
to be done at two levels: IPv6 to IPv4 must be handled at two levels:
1)Session Initiation Protocol (SIP) [RFC3261], and
Session Description Protocol (SDP) [RFC2327] [RFC3266]
(Mm-interface)
2)the user data traffic (Mb-interface)
SIP and SDP transition has to be made in an SIP/SDP Application 1. Session Initiation Protocol (SIP) [RFC3261], and Session
Level Gateway. The ALG has to change the IP addresses transported Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
in the SIP messages and the SDP payload of those messages to the 2. the user data traffic (Mb-interface)
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 SIP carries an SDP body containing the addressing and other
protocol translation, where the user data traffic transported is parameters for establishing the user data traffic (the media).
translated from IPv6 to IPv4, and vice versa.
The legacy IPv4 host's address can be mapped to an IPv6 address for Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP
the IMS, and this address is then used within the IMS to route the proxy at the border between the 3GPP IPv6-only IMS and the IPv4
traffic to the appropriate user traffic translator. This mapping systems.
can be done by the SIP/SDP ALG for the SIP traffic. The user
traffic translator would do the similar mapping for the user In a possible approach, this edge could contain a SIP ALG, which
traffic. However, in order to have an IPv4 address for the IMS UE, would change the IP addresses transported in the SIP messages and
and to be able to route the user traffic within the legacy IPv4 the SDP payload of those messages to the appropriate version. This
network to the correct translator, there has to be an IPv4 address approach would have the drawback (like other SDP rewriting
allocated for the duration of the session from the user traffic solutions) of impacting authentication mechanisms that may be
translator. The allocation of this address from the user traffic needed for other purposes. Moreover, this approach would not take
translator has to be done by the SIP/SDP ALG in order for the advantage of SIP's ability to use proxy routing, nor of SDP's
SIP/SDP ALG to know the correct IPv4 address. This can be achieved ability to carry multiple alternative addresses. These intrinsic
by using a protocol for the ALG to do the allocation. features of SIP and SDP require a more detailed analysis, but they
could yield benefits. The SIP ALG approach requires NAT-PT (with
the issues described in Appendix A), because the IMS-side IPv6
addresses must be assigned IPv4 addresses for reachability from the
legacy IPv4 side shown in Figure 1. The approach based on intrinsic
SIP proxy routing would not require assignment of temporary IPv4
addresses to the IPv6 IMS endpoints; instead they would be reached
via an IPv4-side address of a SIP proxy acting for them. This SIP
proxy would be doing normal SIP processing.
On the user data transport level, the analysis raises other issues:
the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol
translation (with the scalability concerns raised in Appendix A)
may look simplest, but needs a skeptical look. Alternatives include
routing to a transcoder, whose task is to terminate an IPv6 stream
and start an IPv4 stream. Again, this requires a more detailed
analysis.
For each of the protocols, there has to be interoperability for DNS
queries; see section 2.4 for details.
+-------------------------------+ +------------+ +-------------------------------+ +------------+
| +------+ | | +--------+ | | +------+ | | +--------+ |
| |S-CSCF|---| |SIP ALG | |\ | |S-CSCF|---| |SIP edge| |\
| | +------+ | | +--------+ | \ -------- | | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | | +-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |- | | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------ | | +------+ +------+ | |+----------+| / ------
| |-----------------------------------||Translator||/ | |-----------------------------------|| [ALG?] ||/
+--+ | IPv6 | |+----------+| IPv4 +--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking| UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit | | IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+ +-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone 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.
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 Figure 1 shows a generic SIP signaling edge - an ALG-like
replacement of the IPv6 addresses with IPv4 addresses using limited
subsets of NAT-PT [RFC2766]. This is a possible approach, but
exploiting SIP's proxy routing to allow the dual homed SIP edge to
make the address change without a translator could be a promising
alternative without the scaling problems of NAT-PT.
4.2 Two IPv6 IMS Connected via an IPv4 Network
At the early stages of IMS deployment, there may be cases where two 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 IMS islands are separated by an IPv4 network such as the legacy
Internet. Here both the UEs and the IMS islands are IPv6-only. Internet. Here both the UEs and the IMS islands are IPv6-only.
However, the IPv6 islands are not connected natively with IPv6. However, the IPv6 islands are not connected natively with IPv6.
In this scenario, the end-to-end SIP connections are based on 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 The only issue is to make connection between two IPv6-only IMS
islands over IPv4 network. This scenario is closely related to GPRS islands over IPv4 network. This scenario is closely related to GPRS
scenario represented in section 3.2. and similar tunneling scenario represented in section 3.2. and similar tunneling
solutions are applicable also in this scenario. solutions are applicable also in this scenario.
5. About 3GPP UE IPv4/IPv6 Configuration 5. About 3GPP UE IPv4/IPv6 Configuration
This informative section aims to give a brief overview on the This informative section aims to give a brief overview on the
configuration needed in the UE in order to access IP based configuration needed in the UE in order to access IP based
services. There can also be other application specific settings in services. There can also be other application specific settings in
the UE that are not described here. the UE that are not described here.
To be able to access IPv6 or IPv4 based services, settings need to UE configuration is required in order to access IPv6 or IPv4 based
be done in the UE. The GGSN Access Point has to be defined when services. The GGSN Access Point has to be defined when using, for
using, for example, the web browsing application. One possibility example, the web browsing application. One possibility is to use
is to use over the air configuration to configure the GPRS over the air configuration [OMA-CP] to configure the GPRS settings.
settings. The user can visit the operator WWW page and subscribe The user can, for example, visit the operator WWW page and
the GPRS Access Point settings to his/her UE and receive the subscribe the GPRS Access Point settings to his/her UE and receive
settings via Short Message Service (SMS). After the user has the settings via Short Message Service (SMS). After the user has
accepted the settings and a PDP context has been activated, the accepted the settings and a PDP context has been activated, he/she
user can start browsing. The Access Point settings can also be can start browsing. The Access Point settings can also be typed in
typed in manually or be pre-configured by the operator or the UE manually or be pre-configured by the operator or the UE
manufacturer. manufacturer.
DNS server addresses typically also need to be configured in the DNS server addresses typically also need to be configured in the
UE. In the case of IPv4 type PDP context, the (IPv4) DNS server UE. In the case of IPv4 type PDP context, the (IPv4) DNS server
addresses can be received in the PDP context activation (a control addresses can be received in the PDP context activation (a control
plane mechanism). Same kind of mechanism is also available for plane mechanism). A similar mechanism is also available for IPv6:
IPv6: so-called Protocol Configuration Options Information Element so-called Protocol Configuration Options Information Element (PCO-
(PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use
to use [DHCPv6-SL] or [RFC3315] and [RFC3646] for receiving DNS [RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server
server addresses. Active IETF work on DNS discovery mechanisms is addresses. Active IETF work on DNS discovery mechanisms is ongoing
ongoing and might result in other mechanisms becoming available and might result in other mechanisms becoming available over time.
over time. The DNS server addresses can also be received over the The DNS server addresses can also be received over the air (using
air (using SMS), or typed in manually in the UE. SMS) [OMA-CP], or typed in manually in the UE.
When accessing IMS services, the UE needs to know the P-CSCF IPv6 When accessing IMS services, the UE needs to know the Proxy-Call
address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism Session Control Function (P-CSCF) IPv6 address. Either a 3GPP-
([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. Manual specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736]
configuration or configuration over the air is also possible. IMS and [RFC3319]) can be used. Manual configuration or configuration
subscriber authentication and registration to the IMS and SIP over the air is also possible. IMS subscriber authentication and
integrity protection are not discussed here. registration to the IMS and SIP integrity protection are not
discussed here.
6. Security Considerations 6. Summary and Recommendations
There are some generic security considerations when moving to dual- This document has analyzed five GPRS and two IMS IPv6 transition
stack IPv4/IPv6 deployment which are not analyzed at length here. scenarios. Numerous 3GPP networks are using private IPv4 addresses
Two examples of these are ensuring that the access controls and today, and introducing IPv6 is an important thing. The two first
firewalls have similar (or known) security properties with both GPRS scenarios and both IMS scenarios are seen the most relevant.
IPv4 and IPv6, and that enabling IPv6 does not jeopardize the The authors summarize some main recommendations here:
access to the IPv4 services (e.g., in the form of misbehavior - Dual-stack UEs are recommended instead of IPv4-only or IPv6-
towards DNS AAAA record lookups or operationally worse quality IP only UEs. It is important to take care that the applications
transit services). in the UEs support IPv6. IPv6-only UEs can become feasible
when IPv6 is widely deployed in the networks, and most
services work on IPv6.
- It is recommended to activate an IPv6 PDP context when
communicating with an IPv6 peer node and an IPv4 PDP context
when communicating with an IPv4 peer node.
- IPv6 communication is preferred to IPv4 communication going
through IPv4 NATs to the same dual stack peer node.
- This document strongly recommends the 3GPP operators to 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.
- 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 [ISP-sa].
- We recommend that a detailed solution for the general
SIP/SDP/media IPv4/IPv6 transition problem will be specified
as soon as possible as a task within the SIP WGs in the IETF.
7. Security Considerations
Deploying IPv6 has some generic security considerations one should
be aware of [V6SEC]; however, these are not specific to 3GPP
transition, and are therefore out of the scope of this memo.
This memo recommends the use of a relatively small number of This memo recommends the use of a relatively small number of
techniques, which all of them have their own security techniques. Each technique has its own security considerations,
considerations, including: including:
- native upstream access or tunneling by the 3GPP network - native upstream access or tunneling by the 3GPP network
operator, operator,
- use of routing protocols to ensure redundancy, - use of routing protocols to ensure redundancy,
- use of locally-deployed specific-purpose protocol relays and - use of locally-deployed specific-purpose protocol relays and
application proxies to reach IPv4(-only) nodes from IPv6-only application proxies to reach IPv4(-only) nodes from IPv6-only
UEs, or UEs, or
- a specific mechanism for SIP signalling and media translation - a specific mechanism for SIP signalling and media translation
These (except for the last one, naturally) have relatively well- The threats of configured tunneling are described in [RFC2893-bis].
known security considerations, which are also discussed in the Attacks against routing protocols are described in the respective
specific documents. However, in particular one should note that a documents and in general in [ROUTESEC]. Threats related to
proper configuration of locally-deployed relays and proxies is very protocol relays have been described in [RFC3142]. The security
important, so that the outsiders will not have access to them, to properties of SIP internetworking are to be specified when the
be used for abuse, laundering attacks, or circumventing access mechanism is specified.
controls.
In particular, this memo does not recommend the following technique In particular, this memo does not recommend the following technique
which has security issues, not further analyzed here: which has security issues, not further analyzed here:
- NAT-PT or other translator as a generic-purpose transition - NAT-PT or other translator as a general-purpose transition
mechanism mechanism
7. References
7.1 Normative 8. References
[RFC2026] Bradner, S.: The Internet Standards Process -- Revision 8.1 Normative
3, RFC 2026, October 1996.
[RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address
Translator (NAT) Terminology and Considerations, RFC 2663, August Translator (NAT) Terminology and Considerations, August 1999.
1999.
[RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm
(SIIT), RFC 2765, February 2000. (SIIT), February 2000.
[RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation
- Protocol Translation (NAT-PT), RFC 2766, February 2000. - Protocol Translation (NAT-PT), 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, [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
RFC 3261, June 2002. June 2002.
[RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP
Networks, RFC 3574, August 2003. Networks, August 2003.
[RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004.
[RFC3668] Bradner, S.: Intellectual Property Rights in IETF
Technology, February 2004.
[RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition
Mechanisms for IPv6 Hosts and Routers", January 2004, draft-ietf-
v6ops-mech-v2-02.txt, work in progress.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)", December 2002. (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002. (Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", December 2002. (IMS); Stage 2 (Release 5)", December 2002.
[3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP [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)", multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
December 2002. December 2002.
[3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control [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. Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.
7.2 Informative 8.2 Informative
[RFC2327] Handley, M., Jacobson, V.: SDP: Session Description [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Protocol, RFC 2327, April 1998. Protocol, April 1998.
[RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay
Translator, RFC 3142, June 2001. Translator, June 2001.
[RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
in Session Description Protocol (SDP), June 2002. in Session Description Protocol (SDP), June 2002.
[RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP
Standards, September 2002. Standards, September 2002.
[RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for
IPv6 (DHCPv6), July 2003. IPv6 (DHCPv6), July 2003.
[RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers, July 2003. Servers, July 2003.
[RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6, [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6,
December 2003. December 2003.
[3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for [RFC3736] Droms, R.: Stateless Dynamic Host Configuration Protocol
SIP-based services in Third Generation Partnership Project (3GPP) (DHCP) Service for IPv6, April 2004.
Networks", December 2003, draft-elmalki-sipping-3gpp-translator-
00.txt, work in progress.
[DHCP-SL] Droms, R.: "Stateless DHCP Service for IPv6", January
2004, draft-ietf-dhc-dhcpv6-stateless-04.txt, work in progress.
[DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport
operational guidelines", November 2003, draft-ietf-dnsop-ipv6- operational guidelines", March 2004, draft-ietf-dnsop-ipv6-
transport-guidelines-01.txt, work in progress. transport-guidelines-02.txt, work in progress.
[ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.: [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.:
"Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April
February 2004, draft-ietf-ngtrans-isatap-20.txt, work in progress. 2004, draft-ietf-ngtrans-isatap-21.txt, work in progress.
[ISP-sa] Lind, M., Ksinant, V., Park, D., Baudot, A.: "Scenarios [ISP-sa] Lind, M., Ksinant, V., Park, D. and Baudot, A.: "Scenarios
and Analysis for Introducing IPv6 into ISP Networks", February and Analysis for Introducing IPv6 into ISP Networks", April 2004,
2004, draft-ietf-v6ops-isp-scenarios-analysis-01.txt, work in draft-ietf-v6ops-isp-scenarios-analysis-02.txt, work in progress.
progress.
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S., [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati- and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati-
v6ops-natpt-applicability-00.txt, work in progress. v6ops-natpt-applicability-00.txt, work in progress.
[NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", [ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to
January 2003, draft-durand-v6ops-natpt-dns-alg-issues-01.txt, work Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats-
in progress, the draft has expired. 06.txt, work in progress.
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup- Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup-
02.txt, work in progress. 02.txt, work in progress.
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security
Considerations", February 2004, draft-savola-v6ops-security-
overview-02.txt, work in progress.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer
3 specification; Core network protocols; Stage 3 (Release 5)", June 3 specification; Core network protocols; Stage 3 (Release 5)", June
2003. 2003.
8. Contributors [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 Pekka Savola has contributed both text and his IPv6 experience to
this document. He has provided a large number of helpful comments this document. He has provided a large number of helpful comments
on the v6ops mailing list. on the v6ops mailing list. Allison Mankin has contributed text for
IMS Scenario 1 (section 4.1).
9. Authors and Acknowledgements 10. Authors and Acknowledgements
This document is written by: This document is written by:
Alain Durand, Sun Microsystems Alain Durand, Sun Microsystems
<Alain.Durand@sun.com> <Alain.Durand@sun.com>
Karim El-Malki, Ericsson Radio Systems Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se> <Karim.El-Malki@era.ericsson.se>
Niall Richard Murphy, Enigma Consulting Limited Niall Richard Murphy, Enigma Consulting Limited
skipping to change at page 18, line 43 skipping to change at page 19, line 40
Hesham Soliman, Flarion Hesham Soliman, Flarion
<h.soliman@flarion.com> <h.soliman@flarion.com>
Margaret Wasserman, ThingMagic Margaret Wasserman, ThingMagic
<margaret@thingmagic.com> <margaret@thingmagic.com>
Juha Wiljakka, Nokia Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com> <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, Ajay The authors would like to thank Heikki Almay, Gabor Bajko, Ajay
Jain, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne, Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin,
Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred
Meter for their valuable input. Templin, Anand Thakur and Rod Van Meter for their valuable input.
10. Editor's Contact Information 11. Editor's Contact Information
Comments or questions regarding this document should be sent to the Comments or questions regarding this document should be sent to the
v6ops mailing list or directly to the document editor: v6ops mailing list or directly to the document editor:
Juha Wiljakka Juha Wiljakka
Nokia Nokia
Visiokatu 3 Phone: +358 7180 48372 Visiokatu 3 Phone: +358 7180 48372
FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com
11. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; nor does it represent that
has made any effort to identify any such rights. Information on the it has made any independent effort to identify any such rights.
IETF's procedures with respect to rights in standards-track and Information on the procedures with respect to rights in RFC
standards-related documentation can be found in BCP-11. Copies of documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementers or users of this specification attempt made to obtain a general license or permission for the use
can be obtained from the IETF Secretariat. of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
12. 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 March 24, 2004. All Rights 13. Copyright
Reserved.
This document and translations of it may be copied and furnished to The following copyright notice is copied from [RFC3667], Section
others, and derivative works that comment on or otherwise explain 5.4. It describes the applicable copyright for this document.
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
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 Copyright (C) The Internet Society (2004). This document is subject
revoked by the Internet Society or its successors or assignees. 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 is provided on This document and the information contained herein are provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 Appendix A - On the Use of Generic Translators in the 3GPP Networks
This appendix lists mainly 3GPP-specific arguments about generic This appendix lists mainly 3GPP-specific arguments about generic
translators, even though the use of generic translators is translators, even though the use of generic translators is
discouraged. The section may be removed in future versions of the discouraged. The section may be removed in future versions of the
memo. memo.
Due to the significant lack of IPv4 addresses in some domains, port Due to the significant lack of IPv4 addresses in some domains, port
multiplexing is likely to be a necessary feature for translators 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 (i.e. NAPT-PT). If NAPT-PT is used, it needs to be placed on the
GGSN external (Gi) interface, typically separate from the GGSN. GGSN external (Gi) interface, typically separate from the GGSN.
NA(P)T-PT can be installed, for example, on the edge of the NAPT-PT can be installed, for example, on the edge of the
operator's network and the public Internet. NA(P)T-PT will operator's network and the public Internet. NAPT-PT will intercept
intercept DNS requests and other applications that include IP DNS requests and other applications that include IP addresses in
addresses in their payloads, translate the IP header (and payload their payloads, translate the IP header (and payload for some
for some applications if necessary) and forward packets through its applications if necessary) and forward packets through its IPv4
IPv4 interface. interface.
NA(P)T-PT introduces limitations that are expected to be magnified NAPT-PT introduces limitations that are expected to be magnified
within the 3GPP architecture. Some of these limitations are listed within the 3GPP architecture. Some of these limitations are listed
below (notice that most of them are also relevant for IPv4 NAT). below (notice that most of them are also relevant for IPv4 NAT).
[NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTappl] discusses the applicability of NAT-PT in more detail.
1. NA(P)T-PT is a single point of failure for all ongoing 1. NAPT-PT is a single point of failure for all ongoing
connections. connections.
2. There are additional forwarding delays due to further 2. There are additional forwarding delays due to further
processing, when compared to normal IP forwarding. processing, when compared to normal IP forwarding.
3. There are problems with source address selection due to the 3. There are problems with source address selection due to the
inclusion of a DNS ALG on the same node [NATPT-DNS]. inclusion of a DNS ALG on the same node [NATPT-DNS].
4. NA(P)T-PT does not work (without application level gateways) 4. NAPT-PT does not work (without application level gateways) for
for applications that embed IP addresses in their payload. applications that embed IP addresses in their payload.
5. NA(P)T-PT breaks DNSSEC. 5. NAPT-PT breaks DNSSEC.
6. NA(P)T-PT does not scale very well in large networks. 6. NAPT-PT does not scale very well in large networks.
3GPP networks are expected to handle a very large number of 3GPP networks are expected to handle a very large number of
subscribers on a single GGSN (default router). Each GGSN is subscribers on a single GGSN (default router). Each GGSN is
expected to handle hundreds of thousands of connections. expected to handle hundreds of thousands of connections.
Furthermore, high reliability is expected for 3GPP networks. Furthermore, high reliability is expected for 3GPP networks.
Consequently, a single point of failure on the GGSN external Consequently, a single point of failure on the GGSN external
interface would raise concerns on the overall network reliability. interface would raise concerns on the overall network reliability.
In addition, IPv6 users are expected to use delay-sensitive In addition, IPv6 users are expected to use delay-sensitive
applications provided by IMS. Hence, there is a need to minimize applications provided by IMS. Hence, there is a need to minimize
forwarding delays within the IP backbone. Furthermore, due to the forwarding delays within the IP backbone. Furthermore, due to the
unprecedented number of connections handled by the default routers unprecedented number of connections handled by the default routers
(GGSN) in 3GPP networks, a network design that forces traffic to go (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 through a single node at the edge of the network (typical NAPT-PT
configuration) is not likely to scale. Translation mechanisms configuration) is not likely to scale. Translation mechanisms
should allow for multiple translators, for load sharing and should allow for multiple translators, for load sharing and
redundancy purposes. redundancy purposes.
To minimize the problems associated with NA(P)T-PT, the following To minimize the problems associated with NAPT-PT, the following
actions can be recommended: actions can be recommended:
1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to 1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to
IPv4" case). IPv4" case).
2. Ensure (if possible) that NA(P)T-PT does not become a single 2. Ensure (if possible) that NAPT-PT does not become a single
point of failure. point of failure.
3. Allow for load sharing between different translators. That is, 3. Allow for load sharing between different translators. That is,
it should be possible for different connections to go through it should be possible for different connections to go through
different translators. Note that load sharing alone does not different translators. Note that load sharing alone does not
prevent NA(P)T-PT from becoming a single point of failure. prevent NAPT-PT from becoming a single point of failure.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/