draft-ietf-v6ops-3gpp-analysis-07.txt   draft-ietf-v6ops-3gpp-analysis-08.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-07.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-08.txt Nokia
Expires: April 2004 Expires: July 2004
October 2003 January 2004
Analysis on IPv6 Transition in 3GPP Networks Analysis on IPv6 Transition in 3GPP Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with 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 and DNS Guidelines......................4 2. Transition Mechanisms and DNS Guidelines......................5
2.1 Dual Stack................................................5 2.1 Dual Stack................................................5
2.2 Tunneling.................................................5 2.2 Tunneling.................................................5
2.3 Protocol Translators......................................5 2.3 Protocol Translators......................................5
2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6
3. GPRS Transition Scenarios.....................................6 3. GPRS Transition Scenarios.....................................6
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........7
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 8 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 10 .............................................................8
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
............................................................10
3.4 IPv6 UE Connecting to an IPv4 Node.......................10 3.4 IPv6 UE Connecting to an IPv4 Node.......................10
3.5 IPv4 UE Connecting to an IPv6 Node.......................11 3.5 IPv4 UE Connecting to an IPv6 Node.......................11
4. IMS Transition Scenarios.....................................12 4. IMS Transition Scenarios.....................................12
4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12
4.2 Two IMS Islands Connected over IPv4 Network..............14 4.2 Two IMS Islands Connected over IPv4 Network..............14
5. About 3GPP UE IPv4/IPv6 Configuration........................14 5. About 3GPP UE IPv4/IPv6 Configuration........................14
6. Security Considerations......................................15 6. Security Considerations......................................15
7. References...................................................15 7. References...................................................16
7.1 Normative................................................15 7.1 Normative................................................16
7.2 Informative..............................................16 7.2 Informative..............................................16
8. Contributors.................................................18 8. Contributors.................................................18
9. Authors and Acknowledgements.................................18 9. Authors and Acknowledgements.................................18
10. Editor's Contact Information................................19 10. Editor's Contact Information................................19
11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt..........19 11. Intellectual Property Statement.............................19
12. Intellectual Property Statement.............................19 12. Copyright...................................................19
13. Copyright...................................................19
Appendix A...................................................20 Appendix A...................................................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. Authors and Acknowledgements section.
This document analyzes the transition scenarios in 3GPP packet This document analyzes the transition scenarios in 3GPP packet
skipping to change at page 5, line 19 skipping to change at page 5, line 26
- 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 the 3GPP GPRS core network, dual stack implementation in the
Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6
PDP contexts. UEs with dual stack and public (global) IP addresses PDP contexts. UEs with dual stack and public (global) IP addresses
can typically access both IPv4 and IPv6 services without additional can typically access both IPv4 and IPv6 services without additional
translators in the network. However, it is good to remember that translators in the network. However, it is good to remember that
public IPv4 addresses are a scarce resource and in many cases IPv4 public IPv4 addresses are hard to come by and in many cases private
NATs are deployed. Public/global IP addresses are also needed for IPv4 addresses and NATs are deployed. Public/global IP addresses
peer-to-peer services: the node needs a public/global IP address are also needed for peer-to-peer services: the node needs a
that is visible to other nodes. public/global IP address that is visible to other nodes.
2.2 Tunneling 2.2 Tunneling
Tunneling is a transition mechanism that requires dual IPv4/IPv6 Tunneling is a transition mechanism that requires dual IPv4/IPv6
stack functionality in the encapsulating and decapsulating nodes. stack functionality in the encapsulating and decapsulating nodes.
Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
Tunneling can be static or dynamic. Static (configured) tunnels are Tunneling can be static or dynamic. Static (configured) tunnels are
fixed IPv6 links over IPv4, and they are specified in [RFC2893]. fixed IPv6 links over IPv4, and they are specified in [RFC2893].
Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where
skipping to change at page 6, line 18 skipping to change at page 6, line 27
IPv4 and IPv6 transport. The recommendations (including the IPv4 and IPv6 transport. The recommendations (including the
keywords) are copied verbatim from [DNStrans]: keywords) are copied verbatim from [DNStrans]:
"In order to preserve name space continuity, the following "In order to preserve name space continuity, the following
administrative policies are RECOMMENDED: administrative policies are RECOMMENDED:
- every recursive DNS server SHOULD be either IPv4-only or dual - every recursive DNS server SHOULD be either IPv4-only or dual
stack, stack,
- every single DNS zone SHOULD be served by at least one IPv4 - every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server. reachable DNS server.
This rules out IPv6-only DNS server performing full recursion and This rules out IPv6-only DNS servers performing full recursion and
DNS zones served only by IPv6-only DNS servers. This approach DNS zones served only by IPv6-only DNS servers. However, one could
could be revisited if/when translation techniques between IPv4 and very well design a configuration where a chain of IPv6 only DNS
IPv6 were to be widely deployed. servers forward queries to a set of dual stack DNS servers actually
performing those recursive queries. This approach could be
revisited if/when translation techniques between IPv4 and IPv6 were
to be widely deployed.
In order to enforce the second point, the zone validation process In order to help enforcing the second point, the optional
SHOULD ensure that there is at least one IPv4 address record operational zone validation processes SHOULD ensure that there is
available for the name servers of any child delegations within the at least one IPv4 address record available for the name servers of
zone." any child delegations within the zone."
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 [RFC3574] 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. the GGSN, and the at least one router of the same IP version, i.e. the GGSN, and the
skipping to change at page 7, line 5 skipping to change at page 7, line 16
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes
In this scenario, the dual stack UE is capable of communicating In this scenario, the dual stack UE is capable of communicating
with both IPv4 and IPv6 nodes. It is recommended to activate an with both IPv4 and IPv6 nodes. It is recommended to activate an
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. The authors leave the PDP
available and IPv6-in-IPv4 tunneling is needed, it is recommended context activation policy to be decided by UE implementers,
to activate an IPv6 PDP context and perform tunneling in the application developers and operators. One discussed possibility is
network. This case is described in more detail in section 3.2. to activate both IPv4 and IPv6 types of PDP contexts in advance,
because activation of a PDP context usually takes some time.
However, that probably isn't good usage of network resources.
Generally speaking, IPv6 PDP contexts should be preferred even if
that meant IPv6-in-IPv4 tunneling would be needed in the network
(see section 3.2 for more details). Note that this is transparent
to the UE.
However, the UE may attach to a 3GPP network, in which the Serving However, the UE may attach to a 3GPP network, in which the Serving
GPRS Support Node (SGSN), the GGSN, and the Home Location Register GPRS Support Node (SGSN), the GGSN, and the Home Location Register
(HLR) support IPv4 PDP contexts, but do not support IPv6 PDP (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP
contexts. This may happen in early phases of IPv6 deployment. If contexts. This may happen in early phases of IPv6 deployment. If
the 3GPP network does not support IPv6 PDP contexts, and an the 3GPP network does not support IPv6 PDP contexts, and an
application on the UE needs to communicate with an IPv6(-only) application on the UE needs to communicate with an IPv6(-only)
node, the UE may activate an IPv4 PDP context and encapsulate IPv6 node, the UE may activate an IPv4 PDP context and encapsulate IPv6
packets in IPv4 packets using a tunneling mechanism. packets in IPv4 packets using a tunneling mechanism.
The use of private IPv4 addresses in the UE depends on the support The used tunneling mechanism may require public IPv4 addresses, but
of these addresses by the tunneling mechanism and the deployment there are tunneling mechanisms and deployment scenarios in which
scenario. In some cases public IPv4 addresses are required, but if the usage of private IPv4 addresses is possible. If the tunnel
the tunnel endpoints are in the same private domain, or the endpoints are in the same private domain, or the tunneling
tunneling mechanism works through IPv4 NAT, private IPv4 addresses mechanism works through IPv4 NAT, private IPv4 addresses can be
can be used. One deployment scenario example is using a laptop used. One deployment scenario example is using a laptop computer
computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4
IPv4 packets in the laptop computer and IPv4 PDP context is packets in the laptop computer and an IPv4 PDP context is
activated. The used tunneling mechanism (automatic or configured) activated. The used tunneling mechanism in that case depends on the
in that case depends on the support of tunneling mechanisms in the support of tunneling mechanisms in the laptop computer. Another
laptop computer. deployment scenario is making IPv6-in-IPv4 tunneling in the UE
itself and activating an IPv4 PDP context.
Closer details for an applicable tunneling mechanism are not
analyzed in this document. However, a simple host-to-router
(automatic) tunneling mechanism may be a good fit. There is not yet
consensus on the right approach. Primarily, ISATAP [ISATAP] has
been proposed, but some issues have been raised about it, such as
its unnecessary features and relative complexity for a simple task
like this, and its inadequacy in providing security when crossing
administrative domains. Proposed solution alternatives have been
(at least) a simplified, but probably non-interoperable, version of
ISATAP, and STEP [STEP]. In any case, further work is needed to
find out the requirements for the scenario and to specify the
mechanism.
To generally solve this problem (IPv6 not available in the 3GPP To generally solve this problem (IPv6 not available in the 3GPP
network), this document strongly recommends the 3GPP operators to network), this document strongly recommends the 3GPP operators to
deploy basic IPv6 support in their GPRS networks. That also makes deploy basic IPv6 support in their GPRS networks. That also makes
it possible to burden the transition effects in the network and it possible to burden the transition effects in the network and
make the 3GPP UEs simpler. make the 3GPP UEs simpler.
As a general guideline, IPv6 communication is preferred to IPv4 As a general guideline, IPv6 communication is preferred to IPv4
communication going through IPv4 NATs to the same dual stack peer communication going through IPv4 NATs to the same dual stack peer
node. node.
An application running on a UE can identify whether the endpoint is Public IPv4 addresses are often a scarce resource for the operator
an IPv4 or IPv6 capable node by examining the destination address. and typically it is not possible for a UE to have a public IPv4
Alternatively, if a user supplies a name to be resolved, the DNS address (continuously) allocated for its use. Use of private IPv4
may contain records sufficient to identify which protocol should be addresses means use of NATs when communicating with a peer node
used to initiate the connection with the endpoint. In dual stack outside the operator's network. In large networks, NAT systems can
networks, one of the main concerns of an operator is the correct become very complex, expensive and difficult to maintain.
address space and routing management. The operator must maintain
address spaces for both protocols. Public IPv4 addresses are often
a scarce resource for the operator and typically it is not possible
for a UE to have a globally unique IPv4 address (continuously)
allocated for its use. Use of private IPv4 addresses means use of
NATs when communicating with a peer node outside the operator's
network. In large networks, NAT systems can become very complex,
expensive and difficult to maintain.
For DNS recommendations, we refer to section 2.4. For DNS recommendations, we refer to section 2.4.
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
The best solution for this scenario is obtained with tunneling, The best solution for this scenario is obtained with tunneling,
i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context
is activated between the UE and the GGSN. Tunneling is handled in is activated between the UE and the GGSN. Tunneling is handled in
the network, because IPv6 UE is not capable of tunneling (it does the network, because IPv6 UE 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
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
by the same network element. Typically the tunneling handled by the by the same network element. Typically the tunneling handled by the
network elements is transparent to the UEs and IP traffic looks network elements is transparent to the UEs and IP traffic looks
like native IPv6 traffic to them. For the applications, tunneling like native IPv6 traffic to them. For the applications, tunneling
enables end-to-end IPv6 connectivity. Note that this scenario is enables end-to-end IPv6 connectivity.
comparable to 6bone [6BONE] network operation.
IPv6-in-IPv4 tunnels between IPv6 islands can be either static or IPv6-in-IPv4 tunnels between IPv6 islands can be either static or
dynamic. The selection of the type of tunneling mechanism is up to dynamic. The selection of the type of tunneling mechanism is up to
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 networks' transition to IPv6 is analyzed in [ISP- themselves. ISP networks' transition to IPv6 is analyzed in [ISP-
scen] and [ISP-an]. sa].
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 GPRS operators today have typically deployed IPv4 backbone
and they are gradually migrating them while introducing IPv6 networks. 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.
phases of the transition. If the 3GPP operator already has IPv6
widely deployed in its network, this subsection is not so relevant.
In initial IPv6 deployment, where a small number of IPv6-in-IPv4 In initial IPv6 deployment, where a small number of IPv6-in-IPv4
tunnels are required to connect the IPv6 islands over the 3GPP tunnels are required to connect the IPv6 islands over the 3GPP
operator's IPv4 network, manually configured tunnels can be used. operator's IPv4 network, manually configured tunnels can be used.
In a 3GPP network, one IPv6 island can contain the GGSN while In a 3GPP network, one IPv6 island can contain the GGSN while
another island can contain the operator's IPv6 application servers. another island can contain the operator's IPv6 application servers.
However, manually configured tunnels can be an administrative However, manually configured tunnels can be an administrative
burden when the number of islands and therefore tunnels rises. In burden when the number of islands and therefore tunnels rises. In
that case, upgrading parts of the backbone to dual stack may be the that case, upgrading parts of the backbone to dual stack may be the
simplest choice. The administrative burden could also be mitigated simplest choice. The administrative burden could also be mitigated
by using automated management tools which are typically necessary by using automated management tools.
to manage large networks anyway.
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 can 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, routing protocol router redundancy mechanisms, such as the use of IPv6 routing
based mechanisms can provide redundancy. protocols.
3.2.2 Tunneling outside the 3GPP Operator's Network 3.2.2 Tunneling outside the 3GPP Operator's Network
This subsection includes the case in which the peer node is outside This subsection includes the case in which the peer node is outside
the operator's network. In that case IPv6-in-IPv4 tunneling can be the operator's network. In that case, IPv6-in-IPv4 tunneling can be
necessary to obtain IPv6 connectivity and reach other IPv6 nodes. necessary to obtain IPv6 connectivity and reach other IPv6 nodes.
In general, configured tunneling can be recommended.
Tunnel starting point can be in the operator's network depending on Tunnel starting point can be in the operator's network depending on
how far the 3GPP operator has come in implementing IPv6. If the how far the 3GPP operator has come in implementing IPv6. If the
3GPP operator does not have an IP backbone, or has not implemented 3GPP operator has not deployed IPv6 in its backbone, the
IPv6 in it, the encapsulating node can be the GGSN. If the 3GPP encapsulating node can be the GGSN. If the 3GPP operator has
operator has an IP backbone, and has implemented IPv6 in it, but deployed IPv6 in its backbone, but the upstream ISP does not
the upstream ISP does not provide IPv6 connectivity to the provide IPv6 connectivity to the Internet, the encapsulating node
Internet, the encapsulating node can be the edge router. can be the edge router.
The case is pretty straightforward if the upstream ISP provides The case is pretty straightforward if the upstream ISP provides
IPv6 connectivity to the Internet and the operator's backbone IPv6 connectivity to the Internet and the operator's backbone
network supports IPv6. Then the 3GPP operator does not have to network supports IPv6. Then the 3GPP operator does not have to
configure any tunnels, since the upstream ISP will take care of configure any tunnels, since the upstream ISP will take care of
routing IPv6 packets. If the upstream ISP does not provide IPv6 routing IPv6 packets. If the upstream ISP does not provide IPv6
connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from
the edge router to a dual stack border gateway operated by another the edge router to a dual stack border gateway operated by another
ISP which is offering IPv6 connectivity. ISP which is offering IPv6 connectivity.
In the tunneling scenarios above, usage of configured IPv6-in-IPv4
tunneling is recommended. As the number of the tunnels outside of
the 3GPP network is limited, no more than a couple of tunnels
should be needed.
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. Therefore an IPv4-only UE will be able to use an IPv4 link
IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 (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. communicate over an IPv6 network.
Regarding the GGSN-to-v4NODE communication, typically the transport Regarding the GGSN-to-v4NODE communication, typically the transport
network between the GGSN and external networks will support only network between the GGSN and external networks will support only
IPv4 in the early stages and migrate to dual stack, since these IPv4 in the early stages and migrate to dual stack, since these
networks are already deployed. Therefore it is not envisaged that networks are already deployed. Therefore it is not envisaged that
tunneling of IPv4-in-IPv6 will be required from the GGSN to tunneling of IPv4-in-IPv6 will be required from the GGSN to
external IPv4 networks either. In the longer run, 3GPP operators external IPv4 networks either. In the longer run, 3GPP operators
may need to phase out IPv4 UEs and the IPv4 transport network. This may need to phase out IPv4 UEs and the IPv4 transport network. This
would leave only IPv6 UEs. would leave only IPv6 UEs.
skipping to change at page 11, line 22 skipping to change at page 11, line 31
3. the use of specific-purpose mechanisms (as described above in 3. the use of specific-purpose mechanisms (as described above in
2) in the foreign network; these are indistinguishable from 2) in the foreign network; these are indistinguishable from
the IPv6-enabled services from the IPv6 UE's perspective, and the IPv6-enabled services from the IPv6 UE's perspective, and
not discussed further here. not discussed further here.
For many applications, application proxies can be appropriate (e.g. For many applications, application proxies can be appropriate (e.g.
HTTP proxies, SMTP relays, etc.). Such application proxies will not HTTP proxies, SMTP relays, etc.). Such application proxies will not
be transparent to the UE. Hence, a flexible mechanism with minimal be transparent to the UE. Hence, a flexible mechanism with minimal
manual intervention should be used to configure these proxies on manual intervention should be used to configure these proxies on
IPv6 UEs. Within the 3GPP architecture, application proxies can be IPv6 UEs. Application proxies can be placed, for example, on the
placed on the GGSN external interface (Gi), or inside the service GGSN external interface (Gi), or inside the service network.
network.
The authors note that [NATPTappl] discusses the applicability of The authors note that [NATPTappl] discusses the applicability of
NAT-PT. The problems related to NAT-PT usage in 3GPP networks are NAT-PT. The problems related to NAT-PT usage in 3GPP networks are
documented in appendix A. documented in appendix A.
3.5 IPv4 UE Connecting to an IPv6 Node 3.5 IPv4 UE Connecting to an IPv6 Node
The legacy IPv4 nodes are mostly nodes that support the The legacy IPv4 nodes are 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
skipping to change at page 14, line 46 skipping to change at page 14, line 52
user can start browsing. The Access Point settings can also be user can start browsing. The Access Point settings can also be
typed in manually or be pre-configured by the operator or the UE typed in manually or be pre-configured by the operator or the UE
manufacturer. manufacturer.
DNS server addresses typically also need to be configured in the DNS server addresses typically also need to be configured in the
UE. In the case of IPv4 type PDP context, the (IPv4) DNS server UE. In the case of IPv4 type PDP context, the (IPv4) DNS server
addresses can be received in the PDP context activation (a control addresses can be received in the PDP context activation (a control
plane mechanism). Same kind of mechanism is also available for plane mechanism). Same kind of mechanism is also available for
IPv6: so-called Protocol Configuration Options Information Element IPv6: so-called Protocol Configuration Options Information Element
(PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible (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 to use [DHCPv6-SL] or [RFC3315] and [RFC3646] for receiving DNS
server addresses. The authors note that the general IPv6 DNS server addresses. The authors note that the general IPv6 DNS
discovery problem is being solved by the IETF dnsop Working Group. discovery problem is being solved by the IETF dnsop Working Group.
The DNS server addresses can also be received over the air (using The DNS server addresses can also be received over the air (using
SMS), or typed in manually in the UE. SMS), or typed in manually in the UE.
When accessing IMS services, the UE needs to know the P-CSCF IPv6 When accessing IMS services, the UE needs to know the P-CSCF IPv6
address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism
([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. Manual ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. Manual
configuration or configuration over the air is also possible. IMS configuration or configuration over the air is also possible. IMS
subscriber authentication and registration to the IMS and SIP subscriber authentication and registration to the IMS and SIP
skipping to change at page 17, line 12 skipping to change at page 17, line 18
[RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP
Standards, September 2002. Standards, September 2002.
[RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for
IPv6 (DHCPv6), July 2003. IPv6 (DHCPv6), July 2003.
[RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers, July 2003. Servers, July 2003.
[RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6,
December 2003
[3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for
SIP-based services in Third Generation Partnership Project (3GPP) SIP-based services in Third Generation Partnership Project (3GPP)
Networks", October 2003, draft-elmalki-sipping-3gpp-translator- Networks", December 2003, draft-elmalki-sipping-3gpp-translator-
00.txt, work in progress. 00.txt, work in progress.
[DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6", [DHCP-SL] Droms, R.: "Stateless DHCP Service for IPv6", January
August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in 2004, draft-ietf-dhc-dhcpv6-stateless-04.txt, work in progress.
progress.
[DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6
Service", October 2003, draft-ietf-dhc-dhcpv6-stateless-01.txt,
work in progress.
[DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport
operational guidelines", June 2003, draft-ietf-dnsop-ipv6- operational guidelines", November 2003, draft-ietf-dnsop-ipv6-
transport-guidelines-00.txt, work in progress. transport-guidelines-01.txt, work in progress.
[ISP-an] Ksinant, V. (ed.): " Analysis of Transition Mechanisms for [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.:
Introducing IPv6 into ISP Networks", October 2003, draft-ksinant- "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-
v6ops-isp-analysis-00.txt, work in progress. ietf-ngtrans-isatap-17.txt, work in progress.
[ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into [ISP-sa] Lind, M., Ksinant, V., Park, D., Baudot, A.: "Scenarios
ISP Networks", October 2003, draft-lind-v6ops-isp-scenarios-01.txt, and Analysis for Introducing IPv6 into ISP Networks", December
work in progress. 2003, draft-ietf-v6ops-isp-scenarios-analysis-00.txt, work in
progress.
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S., [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.,
Wang, H.: " NAT-PT Applicability ", October 2003, draft-satapati- Wang, H.: " NAT-PT Applicability ", October 2003, draft-satapati-
v6ops-natpt-applicability-00.txt, work in progress. v6ops-natpt-applicability-00.txt, work in progress.
[NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", [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-01.txt, work
in progress, the draft has expired. in progress, the draft has expired.
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup-
02.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. the draft has expired.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer
3 specification; Core network protocols; Stage 3 (Release 5)", June 3 specification; Core network protocols; Stage 3 (Release 5)", June
2003. 2003.
[6BONE] http://www.6bone.net
8. Contributors 8. Contributors
Pekka Savola has contributed both text and his IPv6 experience to Pekka Savola has contributed both text and his IPv6 experience to
this document. He has provided a large number of helpful comments this document. He has provided a large number of helpful comments
on the v6ops mailing list. on the v6ops mailing list.
9. Authors and Acknowledgements 9. Authors and Acknowledgements
This document is written by: This document is written by:
skipping to change at page 18, line 35 skipping to change at page 18, line 42
Hugh Shieh, AT&T Wireless Hugh Shieh, AT&T Wireless
<hugh.shieh@attws.com> <hugh.shieh@attws.com>
Jonne Soininen, Nokia Jonne Soininen, Nokia
<jonne.soininen@nokia.com> <jonne.soininen@nokia.com>
Hesham Soliman, Flarion Hesham Soliman, Flarion
<h.soliman@flarion.com> <h.soliman@flarion.com>
Margaret Wasserman, Nokia Margaret Wasserman, ThingMagic
<margaret.wasserman@nokia.com> <margaret@thingmagic.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, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne, Jain, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne,
Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van
Meter for their valuable input. 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
Visiokatu 3 Phone: +358 7180 48372 Visiokatu 3 Phone: +358 7180 48372
FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com
11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt 11. Intellectual Property Statement
- 3.2.2 edited based on wg last call comments
- Editorial / textual changes in many sections
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
skipping to change at page 19, line 42 skipping to change at page 19, line 37
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
13. Copyright 12. 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 October 26, 2003. All Rights Copyright (C) The Internet Society January 27, 2004. 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 20, line 44 skipping to change at page 20, line 39
GGSN external (Gi) interface, typically separate from the GGSN. GGSN external (Gi) interface, typically separate from the GGSN.
NA(P)T-PT can be installed, for example, on the edge of the NA(P)T-PT can be installed, for example, on the edge of the
operator's network and the public Internet. NA(P)T-PT will operator's network and the public Internet. NA(P)T-PT will
intercept DNS requests and other applications that include IP intercept DNS requests and other applications that include IP
addresses in their payloads, translate the IP header (and payload addresses in their payloads, translate the IP header (and payload
for some applications if necessary) and forward packets through its for some applications if necessary) and forward packets through its
IPv4 interface. 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). below (notice that most of them are also relevant for IPv4 NAT).
[NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTappl] discusses the applicability of NAT-PT in more detail.
1. NA(P)T-PT is a single point of failure for all ongoing 1. NA(P)T-PT is a single point of failure for all ongoing
connections. connections.
2. There are additional forwarding delays due to further 2. There are additional forwarding delays due to further
processing, when compared to normal IP forwarding. processing, when compared to normal IP forwarding.
3. There are problems with source address selection due to the 3. There are problems with source address selection due to the
inclusion of a DNS ALG on the same node [NATPT-DNS]. inclusion of a DNS ALG on the same node [NATPT-DNS].
 End of changes. 

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