draft-ietf-v6ops-3gpp-analysis-00.txt   draft-ietf-v6ops-3gpp-analysis-01.txt 
Internet Draft J. Wiljakka, Internet Draft J. Wiljakka,
Document: draft-ietf-v6ops-3gpp-analysis-00.txt Editor Document: draft-ietf-v6ops-3gpp-analysis-01.txt Editor
Expires: June 2003 Nokia Expires: July 2003 Nokia
December 2002 January 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 1, line 39 skipping to change at page 1, line 39
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 making the transition to IPv6 in Third This document analyzes making the transition to IPv6 in Third
Generation Partnership Project (3GPP) General Packet Radio Service Generation Partnership Project (3GPP) General Packet Radio Service
(GPRS) packet networks. The focus is on analyzing different (GPRS) packet networks. The focus is on analyzing different
transition scenarios, applicable transition mechanisms and finding transition scenarios, applicable transition mechanisms and finding
solutions for those transition scenarios. In these scenarios, the solutions for those transition scenarios. In these scenarios, the
User Equipment (UE) connects to nodes in other networks, e.g. in User Equipment (UE) connects to other nodes, e.g. in the Internet,
the Internet, and IPv6/IPv4 transition mechanisms are needed. 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.............................................3
1.3 Terminology...............................................4 1.3 Terminology...............................................4
2. Transition mechanisms.........................................4 2. Transition mechanisms.........................................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.....................................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 9 3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network10
3.4 IPv6 UE connecting to an IPv4 node........................9 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.......................12
4. Transition Scenarios with IMS................................12 4. Transition Scenarios with IMS................................13
4.1 DNS interworking in IMS..................................12 4.1 DNS interworking in IMS..................................13
4.2 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.3 Two IMS islands connected over IPv4 network..............14 4.3 Two IMS islands connected over IPv4 network..............15
5. Security Considerations......................................14 5. Security Considerations......................................15
6. Changes from draft-wiljakka-3gpp-ipv6-transition-02.txt......14 6. Changes from draft-ietf-v6ops-3gpp-analysis-00.txt...........15
7. References...................................................14 7. Copyright....................................................15
8. Authors and Acknowledgements.................................16 8. References...................................................16
9. Editor's Contact Information.................................17 8.1 Normative................................................16
8.2 Informative..............................................17
9. Authors and Acknowledgements.................................19
10. 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. Comments, input and feedback Authors and Acknowledgements section. Comments, input and feedback
from the people in the IETF v6ops Working Group are appreciated. from the people in the IETF v6ops Working Group are appreciated.
This document analyzes the transition scenarios in 3GPP packet This document analyzes the transition scenarios in 3GPP packet
skipping to change at page 3, line 47 skipping to change at page 3, line 47
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)
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
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
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
PDP Packet Data Protocol PDP Packet Data Protocol
PPP Point-to-Point Protocol PPP Point-to-Point Protocol
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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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 are typically needed when the two communicating nodes
do not share the same IP version. Translation can actually happen do not share the same IP version. Translation can actually happen
at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP
proxy) or Layer 7 (using application relays) proxy) or Layer 7 (using application relays)
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 nodes outside the GPRS network, e.g. a web UE contacts services or other nodes, e.g. a web server in the
server in the Internet. Transition scenarios of the GPRS internal Internet.
interfaces are outside of the scope of this document.
The following scenarios are analyzed here. In all of the scenarios, The following scenarios described by [3GPP-SCEN] are analyzed here.
the UE is part of a network where there is at least one router of In all of the scenarios, the UE is part of a network where there is
the same IP version, i.e. GGSN, and it is connecting to a node in a at least one router of the same IP version, i.e. GGSN, and it is
different network. 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 UE is capable of communicating with both IPv4 In this scenario, the UE is capable of communicating with both IPv4
skipping to change at page 7, line 16 skipping to change at page 7, line 15
private IPv4 addresses can be used. One deployment scenario example private IPv4 addresses can be used. One deployment scenario example
is using laptop computer and a UMTS UE as a modem. IPv6 packets are is using laptop computer and a UMTS UE as a modem. IPv6 packets are
encapsulated in IPv4 packets in the laptop computer and IPv4 PDP encapsulated in IPv4 packets in the laptop computer and IPv4 PDP
context is activated. Although "IPv6 in IPv4" tunneling in the UE context is activated. Although "IPv6 in IPv4" tunneling in the UE
can be either automatic or configured (by the user), the first can be either automatic or configured (by the user), the first
alternative is more probable, because it is expected that most UE alternative is more probable, because it is expected that most UE
users just want to use an application in their UE; they might not users just want to use an application in their UE; they might not
even care, whether the network connection is IPv4 or IPv6. even care, whether the network connection is IPv4 or IPv6.
When analyzing a dual stack UE behavior, an application running on When analyzing a dual stack UE behavior, an application running on
a UE may obviously identify whether the endpoint required is an a UE can identify whether the endpoint required is an IPv4 or IPv6
IPv4 or IPv6 capable node by examining the address to discover what capable node by examining the address to discover what address
address family category it falls into. Alternatively if a user family category it falls into. Alternatively if a user supplies a
supplies a name to be resolved, the DNS may contain records name to be resolved, the DNS may contain records sufficient to
sufficient to identify which protocol should be used to initiate identify which protocol should be used to initiate connection with
connection with the endpoint. Since the UE is capable of native the endpoint. Since the UE is capable of native communication with
communication with both protocols, one of the main concerns of an both protocols, one of the main concerns of an operator is correct
operator is correct address and routing management. The operator address space and routing management. The operator must maintain
must maintain address spaces for both protocols. Public IPv4 address spaces for both protocols. Public IPv4 addresses often are
addresses may be a scarce resource for the operator. Typically it a scarce resource for the operator and typically it is not possible
is not possible for a UE to have a globally unique IPv4 address for a UE to have a globally unique IPv4 address continually
continually 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 (Network Address Translators) when communicating NATs (Network Address Translators) when communicating with a peer
with a peer node outside the operatorĘs network. In large networks, node outside the operator's network. In large networks, NAT systems
NAT systems can become very complex, expensive and difficult to can become very complex, expensive and difficult to maintain.
maintain.
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. In this scenario, the UE talks to
the DNS resolver using the IP version that is available via the the DNS resolver using the IP version that is available via the
activated PDP context. The DNS resolver in the network should be activated PDP context. The DNS resolver in the network should be
dual stack. dual stack. Also keeping the Internet name space unfragmented is an
important thing for the operation of the Internet [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). not have the dual stack functionality needed for tunneling).
Encapsulating node can be e.g. the GGSN or the edge router between Encapsulating node can be the GGSN, the edge router between the
the border of the operator's IPv6 network and the public Internet. border of the operator's IPv6 network and the public Internet, or
The encapsulation (uplink) and decapsulation (downlink) can be any other dual stack node within the operator's IP network. The
handled by the same network element. Typically the tunneling encapsulation (uplink) and decapsulation (downlink) can be handled
handled by the network elements is transparent to the UEs and the by the same network element. Typically the tunneling handled by the
IP traffic looks like native IPv6 traffic to them. For the network elements is transparent to the UEs and the IP traffic looks
applications, tunneling enables end-to-end IPv6 connections. Note like native IPv6 traffic to them. For the applications, tunneling
that this scenario is comparable to 6bone [6BONE] network enables end-to-end IPv6 connectivity. Note that this scenario is
operation. comparable to 6bone [6BONE] network operation.
"IPv6 in IPv4" tunnels between the IPv6 islands can be static or "IPv6 in IPv4" tunnels between the IPv6 islands can be static or
dynamic. The selection of the type of tunneling mechanism is up to dynamic. The selection of the type of tunneling mechanism is up to
the operator/ISP deployment scenario and only generic the operator/ISP deployment scenario and only generic
recommendations can be given. recommendations can be given in this document.
The following subsections are focused on the usage of different
tunneling mechanisms when the peer node is in the operator's
network or outside the operator's network. The authors note that
where the actual 3GPP network ends and which parts of the network
belong to the ISP(s) also depends on the deployment scenario. The
authors are also not commenting how many ISP functions the 3GPP
operator should perform. However, many 3GPP operators are ISPs of
some sort themselves.
3.2.1 Tunneling inside the 3GPP operator's network
Many GPRS operators already have IPv4 backbone networks deployed
and they are gradually migrating them while introducing IPv6
islands. IPv6 backbones can be considered quite rare in the first
phases of the transition. If the 3GPP operator already has IPv6
widely deployed in its network, this subsection is not so relevant.
In initial, smaller scale IPv6 deployment, where a small number of In initial, smaller scale IPv6 deployment, where a small number of
IPv6 in IPv4 tunnels are required to connect the IPv6 islands over IPv6 in IPv4 tunnels are required to connect the IPv6 islands over
an IPv4 network, manually configured tunnels can be used. In a 3GPP the 3GPP operator's IPv4 network, manually configured tunnels can
network, one IPv6 island could contain the GGSN while another be used. In a 3GPP network, one IPv6 island could contain the GGSN
island contains the operator's IPv6 application servers or the while another island contains the operator's IPv6 application
dual-stack border gateway to the upstream ISP. However, manually servers. However, manually configured tunnels can be an
configured tunnels can be an administrative burden when the number administrative burden when the number of islands and therefore
of islands and therefore tunnels rises. Therefore it is also tunnels rises.
possible to use dynamic tunneling mechanisms such as "6to4"
[RFC3056] and IGP/EGP routing protocol based tunneling mechanisms
[BGP][IGP]. Routing protocol based mechanisms such as [BGP] consist
in 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 interfaces and route IPv6 packets over
the IPv4 network. It is possible to combine this with different
types of tunnels. On the other hand, "6to4" [RFC3056] 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. In this case there are two deployment options for
"IPv6 in IPv4" tunneling between the "6to4" router and the relay.
The first option assumes that "6to4" routers using a given relay
each have a default IPv6 route (configured tunnel) pointing to that
relay. The other one consists in using an IPv6 exterior routing
protocol; this way the set of "6to4" routers using a given relay
obtain native IPv6 routes from it using a routing protocol such as
BGP4+ [RFC2283]. Although this solution is more complex, it
provides effective policy control, i.e. BGP4+ policy determines
which "6to4" routers are able to use which relay.
If we consider the "6to4" tunneling mechanism and the 3GPP It is also possible to use dynamic tunneling mechanisms such as
addressing model (a unique /64 prefix allocated for each primary "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling
PDP context), a /48 "6to4" prefix would only be enough for mechanisms [BGP][IGP]. Routing protocol based mechanisms such as
approximately 65000 UEs. Thus, a few public IPv4 addresses would be [BGP] consist of running BGP between the neighboring router tunnel
needed depending on the size of the operator. Other issues to keep endpoints and using multi-protocol BGP extensions to exchange
in mind with respect to the "6to4" mechanism are that reverse DNS reachability information of IPv6 prefixes. The routers use this
is not yet completely solved and there are some security information to create IPv6 in IPv4 tunnel interfaces and route IPv6
considerations associated with the use of "6to4" relay routers (see packets over the IPv4 network. It is possible to combine this with
[6to4SEC]). In a later phase of the transition period, there will different types of tunnels.
be a need for assigning new (native IPv6) addresses to "6to4" nodes
in order to enable native IPv6 connectivity in the future. In most "6to4" nodes use special IPv6 addresses with a "6to4" prefix
3GPP scenarios it is preferred to use manually configured tunnels containing the IPv4 address of the corresponding "IPv6 in IPv4"
or EGP/IGP based tunneling mechanisms. 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. In this case there are two
deployment options for "IPv6 in IPv4" tunneling between the "6to4"
router and the relay. The first option assumes that "6to4" routers
using a given relay each have a default IPv6 route (configured
tunnel) pointing to that relay. The other one consists of using an
IPv6 exterior routing protocol; this way the set of "6to4" routers
using a given relay obtain native IPv6 routes from it using a
routing protocol such as BGP4+ [RFC2283]. Although this solution is
more complex, it provides effective policy control, i.e. BGP4+
policy determines which "6to4" routers are able to use which relay.
The conclusion is that in most "internal" 3GPP scenarios it is
preferred to use manually configured tunnels or EGP/IGP based
tunneling mechanisms, if it is not feasible to enable IPv6 in the
network infrastructure yet.
3.2.2 Tunneling outside the 3GPP operator's network
This subsection includes the case when the peer node is outside the
operator's network. In that case the "IPv6 in IPv4" tunnel starting
point can be in the operator's network - encapsulating node can be
e.g. the GGSN or the edge router.
The case is pretty straightforward if the upstream ISP provides
native IPv6 connectivity to the Internet. If there is no native
IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4"
tunnel should be configured from e.g. the GGSN to the dual stack
border gateway in order to access the upstream ISP.
If the ISP only provides IPv4 connectivity, then the IPv6 traffic
initiated from the 3GPP network should be transported tunneled in
IPv4 to the ISP. Defining the tunnel endpoint depends on the
deployment scenario.
Usage of manually configured "IPv6 in IPv4" tunneling is sensible
if the number of the tunnels can be kept limited. It is assumed
that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the
3GPP network towards the ISP / Internet should be sufficient.
Usage of dynamic tunneling, such as "6to4", can also be considered,
but the scalability problems arise when thinking about the great
number of UEs in the 3GPP networks. 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. 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.
The conclusion is that in most "external" 3GPP scenarios it is
preferred to use a few manually configured tunnels.
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
skipping to change at page 11, line 28 skipping to change at page 12, line 29
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 There are some ways to fix the problems with NA(P)T-PT, one
suggestion is [NAT64]. suggestion is [NAT64].
When thinking the DNS issues, the IPv6 UE needs to find the IPv4 When thinking the DNS issues, the IPv6 UE needs to find the IPv4
address in the DNS, thus the DNS resolver in the network must be address in the DNS, thus the DNS resolver in the network must be
dual stack. Note that DNSSEC is broken if NA(P)T-PT is used. dual stack [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 application 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
skipping to change at page 12, line 7 skipping to change at page 13, line 7
already today mostly rely on proxies or local servers to already today mostly rely on proxies or local servers to
communicate between private address space networks and the communicate between private address space networks and the
Internet. The same methods and technology can be used for IPv4 to Internet. The same methods and technology can be used for IPv4 to
IPv6 transition. IPv6 transition.
An alternative solution could be a general network address An alternative solution could be a general network address
translation mechanisms such as NAT46 [NAT64]. translation mechanisms such as NAT46 [NAT64].
When thinking the DNS issues, the DNS zones containing AAAA records When thinking the DNS issues, the DNS zones containing AAAA records
for the IPv6 nodes need to be served by at least one IPv4 for the IPv6 nodes need to be served by at least one IPv4
accessible DNS server. accessible DNS server [DNStrans].
4. Transition Scenarios with IMS 4. Transition Scenarios with IMS
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. In the following, the possible
transition scenarios are listed. Those scenarios are analyzed in transition scenarios are listed. Those scenarios are analyzed in
sections 4.2 and 4.3. 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
skipping to change at page 12, line 29 skipping to change at page 13, line 29
4.1 DNS interworking in IMS 4.1 DNS interworking in IMS
Currently, there is a consensus in the IETF that even in the IPv6 Currently, there is a consensus in the IETF that even in the IPv6
Internet the DNS resolvers have to be dual stack. Internet the DNS resolvers have to be dual stack.
To perform DNS resolution in the IMS, the UE can be configured as a To perform DNS resolution in the IMS, the UE can be configured as a
stub resolver pointing to a recursive DNS resolver. This stub resolver pointing to a recursive DNS resolver. This
communication can happen over IPv6. However, in the process to find communication can happen over IPv6. However, in the process to find
the IPv6 address of a SIP server, the recursive DNS resolver may the IPv6 address of a SIP server, the recursive DNS resolver may
need to access data that is available only on some IPv4 DNS need to access data that is available only on some IPv4 DNS
servers, see [v6namespace] and [DNSreq]. One way to achieve this is servers, see [DNStrans], [v6namespace] and [DNSreq]. One way to
to make the DNS resolver be dual stack. As DNS traffic is not achieve this is to make the DNS resolver be dual stack. As DNS
directly related to the IMS functionality, this is not in traffic is not directly related to the IMS functionality, this is
contradiction with the IPv6-only nature of the IMS. 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.2 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.
Apparently there will be a number of legacy IPv4 nodes in the Apparently there will be a number of legacy IPv4 nodes in the
Internet that will communicate with the IMS UEs. As the IMS is Internet that will communicate with the IMS UEs. As the IMS is
exclusively IPv6, translators have to be used in the communication exclusively IPv6 [3GPP 23.221], translators have to be used in the
between the IPv6 IMS and legacy IPv4 hosts. This section aims to communication between the IPv6 IMS and legacy IPv4 hosts, i.e.
give an overview on how that interworking can be handled. making a dual stack based solution is not feasible. This section
aims to give an overview on how that interworking can be handled.
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
skipping to change at page 14, line 37 skipping to change at page 15, line 37
reachability of IPv4 and IPv6 nodes (use of DNS through reachability of IPv4 and IPv6 nodes (use of DNS through
NAT-PT). NAT-PT DNS ALG problems are described in [NATPT- NAT-PT). NAT-PT DNS ALG problems are described in [NATPT-
DNS] and [Unmaneval]. DNS] and [Unmaneval].
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-wiljakka-3gpp-ipv6-transition-02.txt 6. Changes from draft-ietf-v6ops-3gpp-analysis-00.txt
- Name changed from Solutions document to Analysis document
- Tunneling text changes especially in section 3.2
- Changes in NA(P)T-PT text in section 3.4
- Editorial changes in some sections - Editorial changes in some sections
- Copyright statement added
- References categorized to Normative and Informative
- Added and removed some references
- Splitting the analysis in two parts in 3.2
7. References 7. Copyright
[RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: The following copyright notice is copied from [RFC2026], Section
Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. 10.4. It describes the applicable copyright for this document.
Copyright (C) The Internet Society January 22, 2003. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References
8.1 Normative
[RFC2026] Bradner, S.: The Internet Standards Process -- Revision
3, RFC 2026, October 1996.
[RFC2327] Handley, M., Jacobson, V.: SDP: Session Description [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Protocol, RFC 2327, April 1998. 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.
skipping to change at page 15, line 30 skipping to change at page 17, line 14
[RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via
IPv4 Clouds, RFC 3056, February 2001. IPv4 Clouds, RFC 3056, February 2001.
[RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol, [RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol,
June 2002. June 2002.
[RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in [RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in
Session Description Protocol (SDP), June 2002. Session Description Protocol (SDP), June 2002.
[RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP
Standards", September 2002.
[3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP
Networks", October 2002, draft-ietf-v6ops-3gpp-cases-00.txt, work Networks", October 2002, draft-ietf-v6ops-3gpp-cases-02.txt, work
in progress. in progress.
[6to4SEC] Savola, P.: "Security Considerations for 6to4", December [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
2002, draft-savola-v6ops-6to4-security-01.txt, work in progress. (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", December 2002.
[3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP
multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
December 2002.
[3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control
Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.
8.2 Informative
[RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.:
Multiprotocol Extensions for BGP-4, RFC 2283, February 1998.
[RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP
Standards", September 2002.
[6to4SEC] Savola, P.: "Security Considerations for 6to4", January
2003, draft-savola-v6ops-6to4-security-02.txt, work in progress.
[BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with
BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in
progress. progress.
[DNSreq] Durand, A., Ihren, J.: "NGtrans IPv6 DNS operational [DNSreq] Durand, A., Ihren, J.: "NGtrans IPv6 DNS operational
requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops- requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops-
req-04.txt, work in progress, the draft has expired. req-04.txt, work in progress, the draft has expired.
[DNStrans] Durand, A.: "IPv6 DNS transition issues", October 2002,
draft-ietf-dnsop-ipv6-dns-issues-00.txt, work in progress.
[DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)",
July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress. July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the
draft has expired.
[IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica,
C., Baudot, A., Diribarne, G.: "Connecting IPV6 islands within an C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an
IPV4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp-
01.txt, work in progress, the draft has expired. 02.txt, work in progress, the draft has expired.
[ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel [ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", October 2002, draft-ietf-ngtrans- Addressing Protocol (ISATAP)", January 2003, draft-ietf-ngtrans-
isatap-05.txt, work in progress. isatap-11.txt, work in progress.
[NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand-
ngtrans-nat64-nat46-00.txt, work in progress. ngtrans-nat64-nat46-00.txt, work in progress, the draft has
expired.
[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 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in January 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in
progress, the draft has expired. progress, the draft has expired.
[TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through
NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in
progress. progress.
[Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S., [Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S.,
van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged
Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt, Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt,
work in progress. work in progress.
[v6namespace] Ihren, J.: "IPv4-to-IPv6 migration and DNS namespace [v6namespace] Ihren, J.: "IPv4-to-IPv6 migration and DNS namespace
fragmentation", March 2002, draft-ietf-dnsop-v6-name-space- fragmentation", March 2002, draft-ietf-dnsop-v6-name-space-
fragmentation-01.txt, work in progress, the draft has expired. fragmentation-01.txt, work in progress, the draft has expired.
[3GPP-23.060] 3GPP TS 23.060 V5.2.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)", June 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.5.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", June 2002.
[3GPP 24.228] 3GPP TS 24.228 V5.0.0, "Signalling flows for the IP
multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
March 2002.
[3GPP 24.229] 3GPP TS 24.229 V5.0.0, "IP Multimedia Call Control
Protocol based on SIP and SDP; Stage 3 (Release 5)", March 2002.
[6BONE] http://www.6bone.net [6BONE] http://www.6bone.net
9. Authors and Acknowledgements
8. 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>
Paul Francis, Tahoe Networks Paul Francis, Tahoe Networks
<francis@tahoenetworks.com> <francis@tahoenetworks.com>
Niall Richard Murphy, Enigma Consulting Limited Niall Richard Murphy, Enigma Consulting Limited
<niallm@enigma.ie> <niallm@enigma.ie>
Hugh Shieh, AT&T Wireless Hugh Shieh, AT&T Wireless
skipping to change at page 17, line 29 skipping to change at page 19, line 36
Hesham Soliman, Ericsson Radio Systems Hesham Soliman, Ericsson Radio Systems
<hesham.soliman@era.ericsson.se> <hesham.soliman@era.ericsson.se>
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 Gabor Bajko, Ajay Jain, Ivan The authors would like to thank Gabor Bajko, Ajay Jain, Ivan
Laloux, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Meter Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Thakur and
for their valuable input. Rod Van Meter for their valuable input.
9. Editor's Contact Information 10. 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
Sinitaival 5 Phone: +358 7180 47562 Sinitaival 5 Phone: +358 7180 47562
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/