draft-ietf-v6ops-3gpp-analysis-04.txt   draft-ietf-v6ops-3gpp-analysis-05.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-04.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-05.txt Nokia
Expires: December 2003 Expires: March 2004
June 2003 September 2003
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
for those transition scenarios. In these scenarios, the User for those transition scenarios. In these scenarios, the User
Equipment (UE) connects to other nodes, e.g. in the Internet, and Equipment (UE) connects to other nodes, e.g. in the Internet, and
IPv6/IPv4 transition mechanisms are needed. 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............................................. 3
1.3 Terminology............................................... 4 1.3 Terminology............................................... 4
2. Transition Mechanisms......................................... 4 2. Transition Mechanisms and DNS Guidelines......................4
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...................................... 5
3. GPRS Transition Scenarios..................................... 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.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes........... 6
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 7 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
..............................................................7
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 ..............................................................9
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....................... 12 3.5 IPv4 UE Connecting to an IPv6 Node.......................11
4. IMS Transition Scenarios..................................... 13 4. IMS Transition Scenarios.....................................12
4.1 DNS Interworking in IMS.................................. 13 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12
4.2 UE Connecting to a Node in an IPv4 Network through IMS... 13 4.2 Two IMS Islands Connected over IPv4 Network..............14
4.3 Two IMS Islands Connected over IPv4 Network.............. 15 5. About 3GPP UE IPv4/IPv6 Configuration........................14
5. Security Considerations...................................... 16 6. Security Considerations......................................15
6. Changes from draft-ietf-v6ops-3gpp-analysis-03.txt........... 16 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt...........15
7. Copyright.................................................... 16 8. Intellectual Property Statement..............................15
8. References................................................... 17 9. Copyright....................................................16
8.1 Normative................................................ 17 10. References..................................................17
8.2 Informative.............................................. 18 10.1 Normative...............................................17
9. Authors and Acknowledgements................................. 19 10.2 Informative.............................................17
10. Editor's Contact Information................................ 20 11. Authors and Acknowledgements................................19
12. Editor's Contact Information................................19
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. The authors can be found in
Authors and Acknowledgements section. Authors and Acknowledgements section.
This document analyzes the transition scenarios in 3GPP packet This document analyzes the transition scenarios in 3GPP packet
data networks that might come up in the deployment phase of IPv6. data networks that might come up in the deployment phase of IPv6.
The transition scenarios are documented in [3GPP-SCEN] and this The transition scenarios are documented in [RFC3574] and this
document will further analyze them. The scenarios are divided into document will further analyze them. The scenarios are divided into
two categories: GPRS scenarios and IMS scenarios. two categories: GPRS scenarios and IP Multimedia Subsystem (IMS)
scenarios.
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 IMS islands connected via 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.
skipping to change at page 3, line 16 skipping to change at page 3, line 21
- Two IMS islands connected via IPv4 network - Two IMS islands connected via 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 informational document is to analyze and solve The scope of this Best Current Practices document is to analyze and
the possible transition scenarios in the 3GPP defined GPRS network solve the possible transition scenarios in the 3GPP defined GPRS
where a UE connects to, or is contacted from the Internet, or network where a UE connects to, or is contacted from, the Internet
another UE. The document covers scenarios with and without the use or another UE. The document covers scenarios with and without the
of the SIP based IP Multimedia Core Network Subsystem (IMS). This use of the SIP based IP Multimedia Core Network Subsystem (IMS).
document is not focused on radio interface issues; both 3GPP Second This document does not focus on radio interface issues; both 3GPP
(GSM) and Third Generation (UMTS) radio network architectures will Second (GSM) and Third Generation (UMTS) radio network
be covered by these scenarios. architectures will be covered by these scenarios.
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 document shall not specify any
new transition mechanisms, but if a need for a new mechanism is new transition mechanisms, but if a need for a new mechanism is
found, that will be reported to the v6ops Working Group. found, that will be reported to the IETF v6ops Working Group.
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
EGP Exterior Gateway Protocol
GGSN Gateway GPRS Support Node (a default router for 3GPP GGSN Gateway GPRS Support Node (a 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
IGP Interior Gateway Protocol
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
OTA Over The Air
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
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
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 dual Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both
stack implemented. It is capable of activating IPv4 and IPv6 stacks. It is capable of activating
both IPv4 and IPv6 PDP contexts. Dual stack UE may both IPv4 and IPv6 Packet Data Protocol (PDP)
be capable of tunneling. contexts. Dual stack UE may be capable of tunneling.
IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is
only capable of activating IPv6 PDP contexts. only capable of activating IPv6 PDP contexts.
IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is
only capable of activating IPv4 PDP contexts. only capable of activating IPv4 PDP contexts.
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.
2. Transition Mechanisms 2. Transition Mechanisms and DNS Guidelines
This chapter briefly introduces some transition mechanisms This chapter briefly introduces some transition mechanisms
specified by the IETF. Applicability of different transition specified by the IETF. The applicability of different transition
mechanisms to 3GPP networks is discussed in chapters 3 and 4. mechanisms to 3GPP networks is discussed in chapters 3 and 4. DNS
recommendations related to IPv4/IPv6 transition are briefly
summarized in section 2.4.
The IPv4/IPv6 transition methods can be divided to: The IPv4/IPv6 transition methods can be divided to:
- dual IPv4/IPv6 stack - dual IPv4/IPv6 stack
- tunneling - tunneling
- protocol translators - protocol translators
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]. If we consider
the 3GPP GPRS core network, dual stack implementation in the GGSN the 3GPP GPRS core network, dual stack implementation in the GGSN
enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack
and public (global) IP addresses can often access both IPv4 and and public (global) IP addresses can often access both IPv4 and
IPv6 services without additional translators in the network. IPv6 services without additional translators in the network.
2.2 Tunneling 2.2 Tunneling
skipping to change at page 5, line 37 skipping to change at page 5, line 46
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 SIIT [RFC2765] is an example of such a mechanism.
Translators are typically needed when the two communicating nodes Translators may be needed in some cases when the communicating
do not share the same IP version. Translation can actually happen nodes do not share the same IP version; in others, it may be
at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP possible to avoid such communication altogether. Translation can
proxy) or Layer 7 (using application relays). actually happen at Layer 3 (using NAT-like techniques), Layer 4
(using a TCP/UDP proxy) or Layer 7 (using application relays).
2.4 DNS Guidelines for IPv4/IPv6 Transition
[DNStrans] provides guidelines to operate DNS in a mixed world of
IPv4 and IPv6 transport. The recommended administrative policies
are the following:
- 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 servers 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.
3. GPRS Transition Scenarios 3. GPRS Transition Scenarios
This section discusses the scenarios that might occur when a GPRS This section discusses the scenarios that might occur when a GPRS
UE contacts services or other nodes, e.g. a web server in the UE contacts services or other nodes, e.g. a web server in the
Internet. Internet.
The following scenarios described by [3GPP-SCEN] are analyzed here. The following scenarios described by [RFC3574] are analyzed here.
In all of the scenarios, the UE is part of a network where there is 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. GGSN, and it is at least one router of the same IP version, i.e. the GGSN, and the
connecting to a node in a different network. UE is connecting to a node in a different network.
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
skipping to change at page 6, line 25 skipping to change at page 6, line 51
IPv6 PDP context when communicating with an IPv6 peer node and 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 IPv4 PDP context when communicating with an IPv4 peer node. If the
3GPP network supports both IPv4 and IPv6 PDP contexts, the UE 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE
activates the appropriate PDP context depending on the type of activates the appropriate PDP context depending on the type of
application it has started or depending on the address of the peer application it has started or depending on the address of the peer
host it needs to communicate with. If IPv6 PDP contexts are host it needs to communicate with. If IPv6 PDP contexts are
available and "IPv6 in IPv4" tunneling is needed, it is recommended available and "IPv6 in IPv4" tunneling is needed, it is recommended
to activate an IPv6 PDP context and perform tunneling in the to activate an IPv6 PDP context and perform tunneling in the
network. This case is described in more detail in section 3.2. network. This case is described in more detail in section 3.2.
However, the UE may attach to a 3GPP network, in which the SGSN However, the UE may attach to a 3GPP network, in which the Serving
(Serving GPRS Support Node), the GGSN and the HLR (Home Location GPRS Support Node (SGSN), the GGSN and the Home Location Register
Register) support IPv4 PDP contexts by default, but may not support (HLR) support IPv4 PDP contexts, but may not support IPv6 PDP
IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP contexts,
contexts, and an application on the UE needs to communicate with an and an application on the UE needs to communicate with an IPv6(-
IPv6(-only) node, the UE may activate an IPv4 PDP context and only) node, the UE may activate an IPv4 PDP context and encapsulate
encapsulate IPv6 packets in IPv4 packets using a tunneling IPv6 packets in IPv4 packets using a tunneling mechanism. This
mechanism. This might happen in very early phases of IPv6 might happen in very early phases of IPv6 deployment. To generally
deployment, or in IPv6 demonstrations and trials. solve this problem (IPv6 not available in the 3GPP network), this
document strongly recommends the 3GPP operators to deploy basic
The UE may be assigned a private or public IPv4 address when the IPv6 support in their GPRS networks, which can in most cases be
IPv4 PDP context has been activated, although it is more likely handled by making software upgrades in the network elements.
that it will receive a private address (due to the lack of public
IPv4 addresses). 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 (one example is 6to4 [RFC3056]), but if the
tunnel endpoints are in the same private domain or the tunneling
mechanism works through IPv4 NAT (Network Address Translator),
private IPv4 addresses can be used (examples are [ISATAP] and
[TEREDO]). In general, if tunneling from the host is needed, ISATAP
and 6to4 are preferred and TEREDO is a mechanism of last resort
when neither of these are applicable.
One deployment scenario example is using laptop computer and a UMTS
UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the
laptop computer and an IPv4 PDP context is activated. Although
"IPv6 in IPv4" tunneling can be either automatic or configured (by
the user), the first alternative is favored, because it is expected
that most UE users just want to use an application in their UE;
they might not even care, whether the network connection is IPv4 or
IPv6.
As a general guideline, IPv6 communication (native or tunneled from As a general guideline, IPv6 communication (native or tunneled from
the UE) is preferred to IPv4 communication going through IPv4 NATs the UE) is preferred to IPv4 communication going through IPv4 NATs
to the same dual stack peer node. In this scenario, the UE talks to to the same dual stack peer node.
the DNS resolver using the IP version that is available via the
activated PDP context.
When analyzing a dual stack UE behavior, an application running on When analyzing a dual stack UE behavior, an application running on
a UE can identify whether the endpoint required is an IPv4 or IPv6 a UE can identify whether the endpoint required is an IPv4 or IPv6
capable node by examining the address to discover what address capable node by examining the address to discover what address
family category it falls into. Alternatively, if a user supplies a family it falls into. Alternatively, if a user supplies a name to
name to be resolved, the DNS may contain records sufficient to be resolved, the DNS may contain records sufficient to identify
identify which protocol should be used to initiate the connection which protocol should be used to initiate the connection with the
with the endpoint. Since the UE is capable of native communication endpoint. Since the UE is capable of native communication with both
with both protocols, one of the main concerns of an operator is protocols, one of the main concerns of an operator is the correct
correct address space and routing management. The operator must address space and routing management. The operator must maintain
maintain address spaces for both protocols. Public IPv4 addresses address spaces for both protocols. Public IPv4 addresses are often
are often a scarce resource for the operator and typically it is a scarce resource for the operator and typically it is not possible
not possible for a UE to have a globally unique IPv4 address for a UE to have a globally unique IPv4 address continuously
continuously allocated for its use. Use of private IPv4 addresses allocated for its use. Use of private IPv4 addresses means use of
means use of NATs when communicating with a peer node outside the NATs when communicating with a peer node outside the operator's
operator's network. In large networks, NAT systems can become very network. In large networks, NAT systems can become very complex,
complex, expensive and difficult to maintain. expensive and difficult to maintain.
Keeping the Internet name space unfragmented is another important For DNS recommendations, we refer to section 2.4.
issue for both IPv4 and IPv6. It means that any record in the
public Internet should be available unmodified to any nodes, IPv4
or IPv6, regardless of the transport being used. The recommended
approach is the following: every recursive DNS server should be
either IPv4-only or dual stack and every single DNS zone should be
served by at least an IPv4 reachable DNS server. This
recommendation rules out IPv6-only recursive DNS servers and DNS
zones served by IPv6-only DNS servers, and this approach could be
revisited if translation techniques between IPv4 and IPv6 were to
be widely deployed [DNStrans].
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 is not capable of tunneling (it does
not have the dual stack functionality needed for tunneling). The not have the dual stack functionality needed for tunneling). The
encapsulating node can be the GGSN, the edge router between the encapsulating node can be the GGSN, the edge router between the
border of the operator's IPv6 network and the public Internet, or border of the operator's IPv6 network and the public Internet, or
skipping to change at page 8, line 23 skipping to change at page 8, line 17
the operator / ISP deployment scenario and only generic the operator / ISP deployment scenario and only generic
recommendations can be given in this document. 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 transition scenarios are documented and analyzed in themselves. ISP transition scenarios are documented in [ISP-scen].
[ISP-scen], [ISP-analysis] and their future updates.
3.2.1 Tunneling inside the 3GPP Operator's Network 3.2.1 Tunneling inside the 3GPP Operator's Network
Many GPRS operators already have IPv4 backbone networks deployed Many GPRS operators already have IPv4 backbone networks deployed
and they are gradually migrating them while introducing IPv6 and they are gradually migrating them while introducing IPv6
islands. IPv6 backbones can be considered quite rare in the first islands. IPv6 backbones can be considered quite rare in the first
phases of the transition. If the 3GPP operator already has IPv6 phases of the transition. If the 3GPP operator already has IPv6
widely deployed in its network, this subsection is not so relevant. widely deployed in its network, this subsection is not so relevant.
In initial, smaller scale IPv6 deployment, where a small number of In initial IPv6 deployment, where a small number of IPv6 in IPv4
IPv6 in IPv4 tunnels are required to connect the IPv6 islands over tunnels are required to connect the IPv6 islands over the 3GPP
the 3GPP operator's IPv4 network, manually configured tunnels can operator's IPv4 network, manually configured tunnels can be used.
be used. In a 3GPP network, one IPv6 island could contain the GGSN In a 3GPP network, one IPv6 island can contain the GGSN while
while another island contains the operator's IPv6 application another island can contain the operator's IPv6 application servers.
servers. However, manually configured tunnels can be an However, manually configured tunnels can be an administrative
administrative burden when the number of islands and therefore burden when the number of islands and therefore tunnels rises. In
tunnels rises. In that case, upgrading parts of the backbone to that case, upgrading parts of the backbone to dual stack may be the
dual stack may be the simplest choice. The administrative burden simplest choice. The administrative burden could also be mitigated
could also be mitigated by using automated management tools which by using automated management tools which are typically necessary
are typically necessary to manage large networks anyway. to manage large networks anyway.
Even a dynamic tunneling mechanism, such as "6to4" [RFC3056] or an
IGP/EGP routing protocol based tunneling mechanism [BGP][IGP],
could be used if other methods are not suitable. Routing protocol
based mechanisms such as [BGP] consist of running BGP between the
neighboring router tunnel endpoints and using multi-protocol BGP
extensions to exchange reachability information of IPv6 prefixes.
The routers use this information to create IPv6 in IPv4 tunnel Even a dynamic tunneling mechanism or an IGP/EGP routing protocol
interfaces and route IPv6 packets over the IPv4 network. It is based tunneling mechanism can be considered if other methods are
possible to combine this with different types of tunnels. not suitable.
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 on their own don't
provide a routing recovery solution for all scenarios where an IPv6 provide a routing recovery solution for all scenarios where an IPv6
route goes down. However, they may provide an adequate solution route goes down. However, they may provide an adequate solution
depending on the design of the network and in presence of other depending on the design of the network and in presence of other
router redundancy mechanisms. On the other hand, IGP/EGP based router redundancy mechanisms. On the other hand, IGP/EGP based
mechanisms can provide redundancy. mechanisms can provide redundancy.
"6to4" nodes use special IPv6 addresses with a "6to4" prefix
containing the IPv4 address of the corresponding "IPv6 in IPv4"
tunnel endpoint ("6to4" router) which performs encapsulation /
decapsulation. When connecting two nodes with "6to4" addresses, the
corresponding "6to4" routers use the IPv4 addresses specified in
the "6to4" prefixes to tunnel IPv6 packets through the IPv4
network. But if only one of them has a "6to4" address, a "6to4"
relay must be present to perform the missing "6to4" router
functionality for the native-IPv6 node. If we consider the "6to4"
tunneling mechanism and the 3GPP addressing model (a unique /64
prefix allocated for each primary PDP context), a /48 "6to4" prefix
would only be enough for approximately 65000 UEs. Thus, a few
public IPv4 addresses would be needed depending on the size of the
operator.
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 when the peer node is outside the This subsection includes the case when the peer node is outside the
operator's network. In that case the "IPv6 in IPv4" tunnel starting operator's network. In that case the "IPv6 in IPv4" tunnel starting
point can be in the operator's network - encapsulating node can be point can be in the operator's network - encapsulating node can be
e.g. the GGSN or the edge router. e.g. the GGSN or the edge router.
The case is pretty straightforward if the upstream ISP provides The case is pretty straightforward if the upstream ISP provides
native IPv6 connectivity to the Internet. If there is no native native IPv6 connectivity to the Internet. If there is no native
IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4"
tunnel should be configured from e.g. the GGSN to the dual stack tunnel should be configured from e.g. the GGSN to the dual stack
border gateway in order to access the upstream ISP. border gateway in order to access the upstream ISP.
If the ISP only provides IPv4 connectivity, then the IPv6 traffic If the ISP only provides IPv4 connectivity, then the IPv6 traffic
initiated from the 3GPP network should be transported tunneled in initiated from the 3GPP network should be transported tunneled in
IPv4 to the ISP. Defining the tunnel endpoint depends on the IPv4 to the ISP.
deployment scenario. The authors want to avoid duplicating work and
note here that the ISP transition scenarios are analyzed in [ISP-
scen] and [ISP-analysis].
Usage of manually configured "IPv6 in IPv4" tunneling is sensible Usage of configured "IPv6 in IPv4" tunneling is recommended. As the
if the number of the tunnels can be kept limited. It is assumed number of the tunnels outside of the 3GPP network is limited, no
that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the more than a couple of tunnels should be needed.
3GPP network towards the ISP / Internet should be sufficient.
On the other hand, usage of dynamic tunneling, such as "6to4", can ISP transition scenarios are described in [ISP-scen].
also be considered, but scalability problems arise when thinking
about the great number of UEs in the 3GPP networks. The specific
limitation when applying "6to4" in 3GPP networks should also be
taken into account, as commented in 3.2.1. Other issues to keep in
mind with respect to the "6to4" mechanism are that reverse DNS is
not yet completely solved and there are some security
considerations associated with the use of "6to4" relay routers (see
[6to4SEC]). Moreover, in a later phase of the transition period,
there will be a need for assigning new, native IPv6 addresses to
all "6to4" nodes in order to enable native 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. An IPv6-capable GGSN is expected to support both IPv6 and 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 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 link (PDP context) to connect to the GGSN without the need to
communicate over an IPv6 network. Regarding the GGSN-to-v4NODE communicate over an IPv6 network.
communication, typically the transport network between the GGSN and
external networks will support only IPv4 in the early stages and Regarding the GGSN-to-v4NODE communication, typically the transport
migrate to dual stack, since these networks are already deployed. network between the GGSN and external networks will support only
Therefore it is not envisaged that tunneling of IPv4 in IPv6 will IPv4 in the early stages and migrate to dual stack, since these
be required from the GGSN to external IPv4 networks either. In the networks are already deployed. Therefore it is not envisaged that
longer run, 3GPP operators may need to phase out IPv4 UEs and the tunneling of IPv4 in IPv6 will be required from the GGSN to
IPv4 transport network. This would leave only IPv6 UEs. Therefore, external IPv4 networks either. In the longer run, 3GPP operators
overall, the transition scenario involving an IPv4 UE communicating may need to phase out IPv4 UEs and the IPv4 transport network. This
with an IPv4 peer through an IPv6 network is not considered very would leave only IPv6 UEs. Therefore, overall, the transition
likely in 3GPP networks. 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 3.4 IPv6 UE Connecting to an IPv4 Node
IPv6 nodes can communicate with IPv4 hosts by making use of a IPv6(-only) nodes can communicate with IPv4(-only) nodes by making
translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local use of a translator (e.g. SIIT [RFC2765], NAT-PT [RFC2766]) within
network. For some applications, application proxies can be the local network. For many applications, application proxies can
appropriate (e.g. HTTP, email relays, etc.). Such applications will be appropriate (e.g. HTTP, email relays, etc.). Such applications
not be transparent to the UE. Hence, a flexible mechanism with will not be transparent to the UE. Hence, a flexible mechanism with
minimal manual intervention should be used to configure these minimal manual intervention should be used to configure these
proxies on IPv6 UEs. Within the 3GPP architecture, application proxies on IPv6 UEs. Within the 3GPP architecture, application
proxies can be placed on the GGSN external interface (Gi), or proxies can be placed on the GGSN external interface (Gi), or
inside the service network. inside the service network.
However, since it is difficult to anticipate all possible However, since it is difficult to anticipate all the possible
applications, there is a need for translators that can translate applications, there can be a need for translators that can
headers independent of the type of application being used. translate headers independent of the type of application being
used. This section describes a solution based on the use of
translators, but does not strongly recommend using translators as a
general solution. The authors note that NAT-PT applicability
statement work is being done in the v6ops wg and that document will
be used as a reference in this document.
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). (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.
When NA(P)T-PT is used, it needs to be placed on the GGSN external NA(P)T-PT can be installed, for example, on the edge of the
(Gi) interface, typically separate from the GGSN. NA(P)T-PT can be operator's network and the public Internet. NA(P)T-PT will
installed, for example, on the edge of the operator's network and intercept DNS requests and other applications that include IP
the public Internet. NA(P)T-PT will intercept DNS requests and addresses in their payloads, translate the IP header (and payload
other applications that include IP addresses in their payloads, for some applications if necessary) and forward packets through its
translate the IP header (and payload for some applications if IPv4 interface.
necessary) and forward packets through its IPv4 interface.
NA(P)T-PT introduces limitations that are expected to be magnified NA(P)T-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 some of them are also relevant for IPv4 NAT). We below (notice that some of them are also relevant for IPv4 NAT). We
note here that [v4v6trans] analyzes the issues when translating note here that [v4v6trans] analyzes the issues when translating
between IPv4 and IPv6. However, the NAT-PT issues should be clearly between IPv4 and IPv6. NAT-PT applicability statement document
documented in an RFC in the v6ops Working Group and a decision (currently being written in v6ops wg) will also be used as a
should be made, whether revisiting the NAT-PT RFC is necessary / reference in this document.
what kind of update is needed.
1. NA(P)T-PT is a single point of failure for all ongoing 1. NA(P)T-PT is a single point of failure for all ongoing
connections. connections.
2. Additional forwarding delays due to further processing, when 2. There are additional forwarding delays due to further
compared to normal IP forwarding. processing, when compared to normal IP forwarding.
3. Problems with source address selection due to the inclusion of 3. There are problems with source address selection due to the
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. NA(P)T-PT does not work (without application level gateways)
for applications that embed IP addresses in their payload. for applications that embed IP addresses in their payload.
5. NA(P)T-PT breaks DNSSEC. 5. NA(P)T-PT breaks DNSSEC.
6. NA(P)T-PT does not scale very well in large networks. 6. NA(P)T-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 NA(P)T-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.
skipping to change at page 12, line 28 skipping to change at page 11, line 43
2. Ensure (if possible) that NA(P)T-PT does not become a 2. Ensure (if possible) that NA(P)T-PT does not become a
single point of failure. single point of failure.
3. Allow for load sharing between different translators. That 3. Allow for load sharing between different translators. That
is, it should be possible for different connections to go is, it should be possible for different connections to go
through different translators. Note that load sharing alone through different translators. Note that load sharing alone
does not prevent NA(P)T-PT from becoming a single point of does not prevent NA(P)T-PT from becoming a single point of
failure. failure.
There are some ways to fix the problems with NA(P)T-PT, one
suggestion is [NAT64].
When thinking the DNS issues, the IPv6 UE needs to find the IPv4
address in the DNS [DNStrans]. Note that DNSSEC is broken if
NA(P)T-PT is used.
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 mostly 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 IPv6 Internet of the future. However, the legacy supported in the IPv6 Internet of the future. However, the legacy
IPv4 UEs are not going to be updated to support the future IPv4 UEs are not going to be updated to support the future
applications. As these application are designed for IPv6, and to applications. As these applications are designed for IPv6, and to
use the advantages of newer platforms, the legacy IPv4 nodes will use the advantages of newer platforms, the legacy IPv4 nodes will
not be able to profit from them. Thus, they will continue to not be able to profit from them. Thus, they will continue to
support the legacy services. support the legacy 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 today mostly rely on proxies or local servers to already mostly rely on proxies or local servers to communicate
communicate between private address space networks and the between private address space networks and the Internet. The same
Internet. The same methods and technology can be used for IPv4 to methods and technology can be used for IPv4 to IPv6 transition.
IPv6 transition.
An alternative solution could be a general network address
translation mechanisms such as NAT46 [NAT64].
When thinking the DNS issues, the DNS zones containing AAAA records For DNS recommendations, we refer to section 2.4.
for the IPv6 nodes need to be served by at least one IPv4
accessible DNS server [DNStrans].
4. IMS Transition Scenarios 4. IMS Transition Scenarios
As the IMS is exclusively IPv6, the number of possible transition As the IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically. In the following, the possible scenarios is reduced dramatically. The possible IMS scenarios are
transition scenarios are listed. Those scenarios are analyzed in listed below and analyzed in sections 4.1 and 4.2.
sections 4.2 and 4.3.
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 IMS islands connected over IPv4 network
4.1 DNS Interworking in IMS For DNS recommendations, we refer to section 2.4. As DNS traffic is
not directly related to the IMS functionality, the recommendations
The recommended approach (as documented in [DNStrans]) currently is are not in contradiction with the IPv6-only nature of the IMS.
that every recursive DNS server should be either IPv4-only or dual
stack and every single DNS zone should be served by at least an
IPv4 reachable DNS server. The recommendation rules out IPv6-only
recursive DNS servers and DNS zones served by IPv6-only DNS
servers.
To perform DNS resolution in the IMS, the UE can be configured as a
stub resolver pointing to a recursive DNS resolver. This
communication can happen over IPv6. However, in the process to find
the IPv6 address of a SIP server, the recursive DNS resolver may
need to access data that is available only on some IPv4 DNS
servers, see [DNStrans]. One way to achieve this is to make the DNS
resolver be dual stack. As DNS traffic is not directly related to
the IMS functionality, this is not in contradiction with the IPv6-
only nature of the IMS.
4.2 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.
There will probably be few legacy IPv4 nodes in the Internet that There will probably be few legacy IPv4 nodes in the Internet that
will communicate with the IMS UEs. It is assumed that the solution will communicate with the IMS UEs. It is assumed that the solution
described here is used for limited cases, in which communications described here is used for limited cases, in which communications
with a small number of legacy IPv4 SIP equipment are needed. As the 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 IMS is exclusively IPv6 [3GPP 23.221], translators have to be used
in the communication between the IPv6 IMS and legacy IPv4 hosts, in the communication between the IPv6 IMS and legacy IPv4 hosts,
i.e. making a dual stack based solution is not feasible. This i.e. making a dual stack based solution is not feasible. This
section aims to give a brief overview on how that interworking can section aims to give a brief overview on how that interworking can
be handled. 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 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, and thus, the IMS, the translation of the IMS traffic has
to be done on two levels - Session Initiation Protocol (SIP) to be done on two levels - Session Initiation Protocol (SIP)
[RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3261], and Session Description Protocol (SDP) [RFC2327]
[RFC3266] on the one hand (Mm-interface), and on the actual user [RFC3266] on the one hand (Mm-interface), and on the actual user
data traffic level on the other (Mb-interface). data traffic level on the other (Mb-interface).
SIP and SDP transition has to be made in an SIP/SDP Application SIP and SDP transition has to be made in an SIP/SDP Application
Level Gateway. The ALG has to change the IP addresses transported Level Gateway. The ALG has to change the IP addresses transported
in the SIP messages and the SDP payload of those messages to the in the SIP messages and the SDP payload of those messages to the
appropriate version. In addition, there has to be interoperability appropriate version. In addition, there has to be interoperability
for DNS queries; see section 4.1 for details. for DNS queries; see section 2.4 for details.
On the user data transport level, the translation is IPv4-IPv6 On the user data transport level, the translation is IPv4-IPv6
protocol translation, where the user data traffic transported is protocol translation, where the user data traffic transported is
translated from IPv6 to IPv4, and vice versa. translated from IPv6 to IPv4, and vice versa.
The legacy IPv4 host's address can be mapped to an IPv6 address for 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 the IMS, and this address is then used within the IMS to route the
traffic to the appropriate user traffic translator. This mapping traffic to the appropriate user traffic translator. This mapping
can be done by the SIP/SDP ALG for the SIP traffic. The user 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 translator would do the similar mapping for the user
skipping to change at page 15, line 22 skipping to change at page 13, line 49
| | +------+ +------+ | |+----------+| / ------ | | +------+ +------+ | |+----------+| / ------
| |-----------------------------------||Translator||/ | |-----------------------------------||Translator||/
+--+ | 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 Figure 1 shows a possible configuration scenario where the SIP ALG
is separate to the CSCFs. The translator can either be set up in a is separated from the CSCFs. The translator can either be set up in
single device with both SIP translation and media translation, or a single device with both SIP translation and media translation, or
those functionalities can be divided to two different entities with those functionalities can be divided to two different entities with
an interface in between. We call the combined network element on an interface in between. We call the combined network element on
the edge of the IPv6-only IMS an "Interworking Unit" in this the edge of the IPv6-only IMS an "Interworking Unit" in this
document. One alternative is to use a suitable subset of NAT-PT document. One alternative is to use a suitable subset of NAT-PT
[RFC2766] in this network element to take care of the media (user [RFC2766] in this network element to take care of the media (user
data) IPv4/IPv6 translation. The problems related to NAT-PT are data) IPv4/IPv6 translation. The problems related to NAT-PT are
documented in section 3.4. documented in section 3.4.
The authors notify that work is being done on analyzing 3GPP 4.2 Two IMS Islands Connected over IPv4 Network
IPv4/IPv6 translators related to IMS scenario 1, and a personal
draft is expected shortly.
4.3 Two IMS Islands Connected over 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 native IPv6 connected. However, the IPv6 islands are not native IPv6 connected.
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. Security Considerations 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 (OTA) 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 using OTA
configuration, 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
([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA or manual
configuration can also be possible. IMS subscriber authentication
and registration to the IMS and SIP integrity protection are not
discussed here.
6. Security Considerations
Editor's note: This section may need updating.
1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and
[v4v6trans]. [v4v6trans].
2. The 3GPP specifications do not currently define the usage 2. The 3GPP specifications do not currently define the usage
of DNS Security. They neither disallow the usage of DNSSEC, of DNS Security. They neither disallow the usage of DNSSEC,
nor do they mandate it. nor do they mandate it.
3. NAT-PT breaks DNSSEC. 3. NAT-PT breaks DNSSEC.
6. Changes from draft-ietf-v6ops-3gpp-analysis-03.txt 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt
- Tunneling text in 2.2 shortened - (Major part of) The issues handled:
- Text changes in 3.1 http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-
- Text changes in 3.2 analysis/index
- Text changes in 4.2 - The only DNS reference now is draft-ietf-dnsop-ipv6-transport-
- Editorial changes in some sections guidelines-00.txt, all DNS discussion is now in section 2.4
- Section 5 "About 3GPP UE IPv4/IPv6 Configuration" added
- draft-elmalki-v6ops-3gpp-translator put as an informational
reference in section 4.1; a recommendation has been added to
solve the general SIP/SDP transition problem in SIP wg(s)
- NAT64 reference removed
- 6to4 references removed
- IGP and BGP references removed (expired drafts)
- Some abbreviations added
- Intellectual Property Statement added
- Editorial changes in many sections
7. Copyright 8. 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.
9. Copyright
The following copyright notice is copied from [RFC2026], Section The following copyright notice is copied from [RFC2026], Section
10.4. It describes the applicable copyright for this document. 10.4. It describes the applicable copyright for this document.
Copyright (C) The Internet Society June 13, 2003. All Rights Copyright (C) The Internet Society September 10, 2003. All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
skipping to change at page 17, line 7 skipping to change at page 17, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References 10. References
8.1 Normative 10.1 Normative
[RFC2026] Bradner, S.: The Internet Standards Process -- Revision [RFC2026] Bradner, S.: The Internet Standards Process -- Revision
3, RFC 2026, October 1996. 3, RFC 2026, October 1996.
[RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Protocol, RFC 2327, April 1998.
[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, RFC 2663, 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), RFC 2765, 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), RFC 2766, February 2000.
[RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for
IPv6 Hosts and Routers, RFC 2893, August 2000. IPv6 Hosts and Routers, RFC 2893, August 2000.
[RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via
IPv4 Clouds, RFC 3056, February 2001.
[RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
June 2002. RFC 3261, June 2002.
[RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
in Session Description Protocol (SDP), June 2002.
[3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP
Networks", March 2003, draft-ietf-v6ops-3gpp-cases-03.txt, work in Networks, RFC 3574, August 2003.
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.
8.2 Informative 10.2 Informative
[RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.:
Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. Multiprotocol Extensions for BGP-4, RFC 2283, February 1998.
[RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Standards", September 2002. Protocol, RFC 2327, April 1998.
[6to4SEC] Savola, P.: "Security Considerations for 6to4", January [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
2003, draft-savola-v6ops-6to4-security-02.txt, work in progress. in Session Description Protocol (SDP), June 2002.
[BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP
Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with Standards, September 2002.
BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in
progress, the draft has expired.
[DNStrans] Durand, A. and Ihren, J.: "IPv6 DNS transition issues", [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for
February 2003, draft-ietf-dnsop-ipv6-dns-issues-02.txt, work in IPv6 (DHCPv6), July 2003.
progress.
[IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- Servers, July 2003.
02.txt, work in progress, the draft has expired.
[ISATAP] Templin, F., et al.: "Intra-Site Automatic Tunnel [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translators in 3GPP
Addressing Protocol (ISATAP)", March 2003, draft-ietf-ngtrans- Networks", June 2003, draft-elmalki-v6ops-3gpp-translator-00.txt,
isatap-13.txt, work in progress. work in progress.
[ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP [DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6",
Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in
progress.
[DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6
Service", April 2003, draft-ietf-dhc-dhcpv6-stateless-00.txt, work
in progress. in progress.
[ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport
Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt, operational guidelines", June 2003, draft-ietf-dnsop-ipv6-
work in progress. transport-guidelines-00.txt, work in progress.
[NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- [ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into
ngtrans-nat64-nat46-00.txt, work in progress, the draft has ISP Networks", June 2003, draft-lind-v6ops-isp-scenarios-00.txt,
expired. work in progress.
[NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766",
January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work
in progress. in progress, the draft has expired.
[TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP through
NATs", June 2003, draft-huitema-v6ops-teredo-00.txt, work in
progress.
[v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.: [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.:
"Issues when translating between IPv4 and IPv6", January 2003, "Issues when translating between IPv4 and IPv6", January 2003,
draft-vanderpol-v6ops-translation-issues-00.txt, work in progress. draft-vanderpol-v6ops-translation-issues-00.txt, work in progress,
the draft has expired.
[6BONE] http://www.6bone.net [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.
9. Authors and Acknowledgements [6BONE] http://www.6bone.net
11. 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 19, line 48 skipping to change at page 19, line 33
Hesham Soliman, Flarion Hesham Soliman, Flarion
<h.soliman@flarion.com> <h.soliman@flarion.com>
Margaret Wasserman, Wind River Margaret Wasserman, Wind River
<mrw@windriver.com> <mrw@windriver.com>
Juha Wiljakka, Nokia Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com> <juha.wiljakka@nokia.com>
The authors would like to thank Heikki Almay, Gabor Bajko, Ajay The authors would like to thank Heikki Almay, Gabor Bajko, Ajay
Jain, Ivan Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Jain, Jarkko Jouppi, Ivan Laloux, Janne Rinne, Pekka Savola, Pedro
Thakur and Rod Van Meter for their valuable input. Serna, Fred Templin, Anand Thakur and Rod Van Meter for their
valuable input.
10. Editor's Contact Information 12. 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
 End of changes. 

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