draft-ietf-v6ops-3gpp-analysis-01.txt   draft-ietf-v6ops-3gpp-analysis-02.txt 
Internet Draft J. Wiljakka, Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-01.txt Editor Document: draft-ietf-v6ops-3gpp-analysis-02.txt Nokia
Expires: July 2003 Nokia Expires: September 2003
January 2003 March 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
solutions for those transition scenarios. In these scenarios, the solutions for those transition scenarios. In these scenarios, the
User Equipment (UE) connects to other nodes, e.g. in the Internet, User Equipment (UE) connects to other nodes, e.g. in 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 8
3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network10 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network10
3.4 IPv6 UE connecting to an IPv4 node.......................10 3.4 IPv6 UE Connecting to an IPv4 Node.......................11
3.5 IPv4 UE connecting to an IPv6 node.......................12 3.5 IPv4 UE Connecting to an IPv6 Node.......................12
4. Transition Scenarios with IMS................................13 4. Transition Scenarios with IMS................................13
4.1 DNS interworking in IMS..................................13 4.1 DNS Interworking in IMS..................................13
4.2 UE connecting to a node in an IPv4 network through IMS...13 4.2 UE Connecting to a Node in an IPv4 Network through IMS...14
4.3 Two IMS islands connected over IPv4 network..............15 4.3 Two IMS Islands Connected over IPv4 Network..............16
5. Security Considerations......................................15 5. Security Considerations......................................16
6. Changes from draft-ietf-v6ops-3gpp-analysis-00.txt...........15 6. Changes from draft-ietf-v6ops-3gpp-analysis-01.txt...........16
7. Copyright....................................................15 7. Copyright....................................................16
8. References...................................................16 8. References...................................................17
8.1 Normative................................................16 8.1 Normative................................................17
8.2 Informative..............................................17 8.2 Informative..............................................18
9. Authors and Acknowledgements.................................19 9. Authors and Acknowledgements.................................20
10. Editor's Contact Information................................19 10. Editor's Contact Information................................20
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 4, line 35 skipping to change at page 4, line 35
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
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. 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.
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
skipping to change at page 5, line 48 skipping to change at page 5, line 48
determine the IPv6 next-hop address via a longest-prefix-match determine the IPv6 next-hop address via a longest-prefix-match
lookup in the IPv6 routing table. But unlike static tunnels, the lookup in the IPv6 routing table. But unlike static tunnels, the
IPv4 destination address is derived from the IPv6 next-hop address IPv4 destination address is derived from the IPv6 next-hop address
in some way, for example, via direct encoding in the IPv6 next-hop in some way, for example, via direct encoding in the IPv6 next-hop
address. This enables stateless encapsulation of IPv6-in-IPv4. address. This enables stateless encapsulation of IPv6-in-IPv4.
This means that the IPv4 source address is taken from an IPv4 This means that the IPv4 source address is taken from an IPv4
interface over which the automatic tunnel is configured. Examples interface over which the automatic tunnel is configured. Examples
of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP],
[DSTM] and [TEREDO]. [DSTM] and [TEREDO].
2.3 Protocol translators 2.3 Protocol Translators
A translator can be defined as an intermediate component between a A translator can be defined as an intermediate component between a
native IPv4 node and a native IPv6 node to enable direct native IPv4 node and a native IPv6 node to enable direct
communication between them without requiring any modifications to communication between them without requiring any modifications to
the end nodes. the end nodes.
Header conversion is a translation mechanism. In header conversion, Header conversion is a translation mechanism. In header conversion,
IPv6 packet headers are converted to IPv4 packet headers, and vice IPv6 packet headers are converted to IPv4 packet headers, and 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 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 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 [3GPP-SCEN] 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. GGSN, and it is
connecting to a node in a 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
and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also
requires that the GGSN is supporting both IPv4 and IPv6. The dual requires that the GGSN is supporting both IPv4 and IPv6. The dual
stack UE may have both stacks or only one of them active stack UE may have both stacks or only one of them active
simultaneously. If "IPv6 in IPv4" tunneling is needed, it is often simultaneously. If "IPv6 in IPv4" tunneling is needed, it is often
beneficial to activate IPv6 PDP context and make encapsulation / beneficial to activate IPv6 PDP context and make encapsulation /
decapsulation in the network (like described in section 3.2). decapsulation in the network (like described in section 3.2).
However, if the GGSN does not support IPv6, and an application on However, if the GGSN does not support IPv6, and an application on
skipping to change at page 7, line 35 skipping to change at page 7, line 35
for a UE to have a globally unique IPv4 address continually for a UE to have a globally unique IPv4 address continually
allocated for its use. Use of private IPv4 addresses means use of allocated for its use. Use of private IPv4 addresses means use of
NATs (Network Address Translators) when communicating with a peer NATs (Network Address Translators) when communicating with a peer
node outside the operator's network. In large networks, NAT systems node outside the operator's network. In large networks, NAT systems
can become very complex, expensive and difficult to maintain. can become very complex, expensive and difficult to 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.
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 Keeping the Internet name space unfragmented is an important thing.
This covers 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: 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
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 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
any other dual stack node within the operator's IP network. The any other dual stack node within the operator's IP network. The
encapsulation (uplink) and decapsulation (downlink) can be handled encapsulation (uplink) and decapsulation (downlink) can be handled
skipping to change at page 8, line 21 skipping to change at page 8, line 36
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 also not commenting how many ISP functions the 3GPP authors are also not commenting how many ISP functions the 3GPP
operator should perform. However, many 3GPP operators are ISPs of operator should perform. However, many 3GPP operators are ISPs of
some sort themselves. some sort themselves.
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, 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
the 3GPP operator's IPv4 network, manually configured tunnels can the 3GPP operator's IPv4 network, manually configured tunnels can
skipping to change at page 9, line 24 skipping to change at page 9, line 39
using a given relay obtain native IPv6 routes from it using a using a given relay obtain native IPv6 routes from it using a
routing protocol such as BGP4+ [RFC2283]. Although this solution is routing protocol such as BGP4+ [RFC2283]. Although this solution is
more complex, it provides effective policy control, i.e. BGP4+ more complex, it provides effective policy control, i.e. BGP4+
policy determines which "6to4" routers are able to use which relay. policy determines which "6to4" routers are able to use which relay.
The conclusion is that in most "internal" 3GPP scenarios it is The conclusion is that in most "internal" 3GPP scenarios it is
preferred to use manually configured tunnels or EGP/IGP based preferred to use manually configured tunnels or EGP/IGP based
tunneling mechanisms, if it is not feasible to enable IPv6 in the tunneling mechanisms, if it is not feasible to enable IPv6 in the
network infrastructure yet. network infrastructure yet.
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
skipping to change at page 10, line 17 skipping to change at page 10, line 33
mechanism are that reverse DNS is not yet completely solved and mechanism are that reverse DNS is not yet completely solved and
there are some security considerations associated with the use of there are some security considerations associated with the use of
"6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of "6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of
the transition period, there will be a need for assigning new the transition period, there will be a need for assigning new
(native IPv6) addresses to all "6to4" nodes in order to enable (native IPv6) addresses to all "6to4" nodes in order to enable
native IPv6 connectivity. native IPv6 connectivity.
The conclusion is that in most "external" 3GPP scenarios it is The conclusion is that in most "external" 3GPP scenarios it is
preferred to use a few manually configured tunnels. 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
communicate over an IPv6 network. Regarding the GGSN-to-v4NODE communicate over an IPv6 network. Regarding the GGSN-to-v4NODE
communication, typically the transport network between the GGSN and communication, typically the transport network between the GGSN and
external networks will support only IPv4 in the early stages and external networks will support only IPv4 in the early stages and
migrate to dual stack, since these networks are already deployed. migrate to dual stack, since these networks are already deployed.
Therefore it is not envisaged that tunneling of IPv4 in IPv6 will Therefore it is not envisaged that tunneling of IPv4 in IPv6 will
be required from the GGSN to external IPv4 networks either. In the be required from the GGSN to external IPv4 networks either. In the
longer run, 3GPP operators may need to phase out IPv4 UEs and the longer run, 3GPP operators may need to phase out IPv4 UEs and the
IPv4 transport network. This would leave only IPv6 UEs. Therefore, IPv4 transport network. This would leave only IPv6 UEs. Therefore,
overall, the transition scenario involving an IPv4 UE communicating overall, the transition scenario involving an IPv4 UE communicating
with an IPv4 peer through an IPv6 network is not considered very with an IPv4 peer through an IPv6 network is not considered very
likely in 3GPP networks. 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 nodes can communicate with IPv4 hosts by making use of a
translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local
network. For some applications, application proxies can be network. For some applications, application proxies can be
appropriate (e.g. HTTP, email relays, etc.). Such applications will appropriate (e.g. HTTP, email relays, etc.). Such applications will
not be transparent to the UE. Hence, a flexible mechanism with 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.
skipping to change at page 12, line 28 skipping to change at page 12, line 44
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 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 [DNStrans]. Note that DNSSEC is broken if
dual stack [DNStrans]. Note that DNSSEC is broken if NA(P)T-PT is NA(P)T-PT is used.
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
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.
skipping to change at page 13, line 19 skipping to change at page 13, line 33
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
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 The recommended approach (as documented in [DNStrans]) currently is
Internet the DNS resolvers have to be dual stack. 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 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 [DNStrans], [v6namespace] and [DNSreq]. One way to servers, see [DNStrans]. One way to achieve this is to make the DNS
achieve this is to make the DNS resolver be dual stack. As DNS resolver be dual stack. As DNS traffic is not directly related to
traffic is not directly related to the IMS functionality, this is the IMS functionality, this is not in contradiction with the IPv6-
not in contradiction with the IPv6-only nature of the IMS. 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 There will probably be few legacy IPv4 nodes in the Internet that
Internet that will communicate with the IMS UEs. As the IMS is will communicate with the IMS UEs. It is assumed that the solution
exclusively IPv6 [3GPP 23.221], translators have to be used in the described here is used for limited cases, in which communications
communication between the IPv6 IMS and legacy IPv4 hosts, i.e. with a small number of legacy IPv4 SIP equipment are needed. As the
making a dual stack based solution is not feasible. This section IMS is exclusively IPv6 [3GPP 23.221], translators have to be used
aims to give an overview on how that interworking can be handled. in the communication between the IPv6 IMS and legacy IPv4 hosts,
i.e. making a dual stack based solution is not feasible. This
section aims to give 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 45 skipping to change at page 15, line 18
| | +------+ | |+--------+| \ -------- | | +------+ | |+--------+| \ --------
+-|+ | / | | | | | | +-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |- | | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+--------+| / ------ | | +------+ +------+ | |+--------+| / ------
| |-----------------------------------|| NAT-PT ||/ | |-----------------------------------|| NAT-PT ||/
+--+ | IPv6 | |+--------+| IPv4 +--+ | IPv6 | |+--------+| IPv4
UE | | | | UE | | | |
| IP Multimedia CN Subsystem | |Translator| | IP Multimedia CN Subsystem | |Translator|
+-------------------------------+ +----------+ +-------------------------------+ +----------+
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 separate to the CSCFs. The translator can either be set up in a
single device with both SIP translation and media translation, or 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. an interface in between.
4.3 Two IMS islands connected over IPv4 network A special situation is when the IPv4-only destination node is
registered to a SIP proxy that happens to be dual stack. In such a
case, the connection from the edge of the IMS to the destination
network could be either IPv4 or IPv6, as the SIP INVITE message
sent by the IMS UE involves DNS address resolution only for the
destination SIP proxy (and not for the destination node). If IPv4
is used (from the edge of the IMS to the destination SIP proxy),
then no further IPv4-IPv6 interworking is needed outside the IMS
domain, as IPv4-IPv6 translation will be performed on the edge of
the IMS.
On the other hand, when IPv6 is used to connect both SIP proxies
(that is more likely), translation is not taken care of in the IMS
because there is no way of detecting that the destination node is
IPv4-only (i.e., only the IP version of the destination SIP proxy
can be detected from the DNS reply). Thus, IPv6 to IPv4 translation
should be performed in the destination SIP domain (for example,
implemented in the dual stack SIP proxy). In addition, it could
also happen (especially in the initial stages of IPv6 deployment)
that end-to-end IPv6 connectivity between the IMS and the
destination domain is not yet available. Thus, this would be
equivalent to the scenario described in 4.3 (two IPv6 islands
connecting through an IPv4 network) and an IPv6 in IPv4 tunneling
mechanism should be used (in addition to IPv4-IPv6 translation in
the destination domain).
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 would be based on In this scenario, the end-to-end SIP connections would be based on
IPv6. The only issue is to make connection between two IPv6-only IPv6. The only issue is to make connection between two IPv6-only
IMS islands over IPv4 network. So, in practice, this scenario is IMS islands over IPv4 network. So, in practice, this scenario is
very closely related to GPRS scenario represented in section 4.2. very closely related to GPRS scenario represented in section 4.2.
skipping to change at page 15, line 37 skipping to change at page 16, 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-ietf-v6ops-3gpp-analysis-00.txt 6. Changes from draft-ietf-v6ops-3gpp-analysis-01.txt
- Editorial changes in some sections - Editorial changes in some sections
- Copyright statement added - Subsection 4.2: adding short description on destination
- References categorized to Normative and Informative network dual stack SIP proxy case
- Added and removed some references
- Splitting the analysis in two parts in 3.2
7. Copyright 7. 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 January 22, 2003. All Rights Copyright (C) The Internet Society March 01, 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 15 skipping to change at page 18, line 15
[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.
[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-02.txt, work Networks", January 2003, draft-ietf-v6ops-3gpp-cases-02.txt, work
in progress. in progress.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)", December 2002. (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002. (Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", December 2002. (IMS); Stage 2 (Release 5)", December 2002.
skipping to change at page 17, line 50 skipping to change at page 18, line 50
Standards", September 2002. Standards", September 2002.
[6to4SEC] Savola, P.: "Security Considerations for 6to4", January [6to4SEC] Savola, P.: "Security Considerations for 6to4", January
2003, draft-savola-v6ops-6to4-security-02.txt, work in progress. 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
requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops-
req-04.txt, work in progress, the draft has expired.
[DNStrans] Durand, A.: "IPv6 DNS transition issues", October 2002, [DNStrans] Durand, A.: "IPv6 DNS transition issues", October 2002,
draft-ietf-dnsop-ipv6-dns-issues-00.txt, work in progress. 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, the July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the
draft has expired. 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-
02.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)", January 2003, draft-ietf-ngtrans- Addressing Protocol (ISATAP)", January 2003, draft-ietf-ngtrans-
isatap-11.txt, work in progress. isatap-12.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, the draft has ngtrans-nat64-nat46-00.txt, work in progress, the draft has
expired. 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
fragmentation", March 2002, draft-ietf-dnsop-v6-name-space-
fragmentation-01.txt, work in progress, the draft has expired.
[6BONE] http://www.6bone.net [6BONE] http://www.6bone.net
9. Authors and Acknowledgements 9. 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>
skipping to change at page 19, line 46 skipping to change at page 20, line 46
Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Thakur and Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Thakur and
Rod Van Meter for their valuable input. Rod Van Meter for their valuable input.
10. 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 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/