<pre>Network Working Group                                   J. Wiljakka, Ed.
Request for Comments: 4215                                         Nokia
Category: Informational                                     October 2005


                    <span class="h1">Analysis on IPv6 Transition in</span>
         <span class="h1">Third Generation Partnership Project (3GPP) Networks</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document analyzes the transition to IPv6 in Third Generation
   Partnership Project (3GPP) packet networks.  These networks are based
   on General Packet Radio Service (GPRS) technology, and the radio
   network architecture is based on Global System for Mobile
   Communications (GSM) or Universal Mobile Telecommunications System
   (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

   The focus is on analyzing different transition scenarios and
   applicable transition mechanisms and finding solutions for those
   transition scenarios.  In these scenarios, the User Equipment (UE)
   connects to other nodes, e.g., in the Internet, and IPv6/IPv4
   transition mechanisms are needed.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
      <a href="#section-1.1">1.1</a>. Scope of This Document .....................................<a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a>. Abbreviations ..............................................<a href="#page-3">3</a>
      <a href="#section-1.3">1.3</a>. Terminology ................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Transition Mechanisms and DNS Guidelines ........................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Dual Stack .................................................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Tunneling ..................................................<a href="#page-6">6</a>
      <a href="#section-2.3">2.3</a>. Protocol Translators .......................................<a href="#page-6">6</a>
      <a href="#section-2.4">2.4</a>. DNS Guidelines for IPv4/IPv6 Transition ....................<a href="#page-6">6</a>
   <a href="#section-3">3</a>. GPRS Transition Scenarios .......................................<a href="#page-7">7</a>
      <a href="#section-3.1">3.1</a>. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............<a href="#page-7">7</a>
      3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4
           Network ....................................................<a href="#page-8">8</a>



<span class="grey">Wiljakka                     Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


           <a href="#section-3.2.1">3.2.1</a>. Tunneling Inside the 3GPP Operator's Network ........<a href="#page-9">9</a>
           <a href="#section-3.2.2">3.2.2</a>. Tunneling Outside the 3GPP Operator's Network ......<a href="#page-10">10</a>
      3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6
           Network ...................................................<a href="#page-10">10</a>
      <a href="#section-3.4">3.4</a>. IPv6 UE Connecting to an IPv4 Node ........................<a href="#page-11">11</a>
      <a href="#section-3.5">3.5</a>. IPv4 UE Connecting to an IPv6 Node ........................<a href="#page-12">12</a>
   <a href="#section-4">4</a>. IMS Transition Scenarios .......................................<a href="#page-12">12</a>
      <a href="#section-4.1">4.1</a>. UE Connecting to a Node in an IPv4 Network through IMS ....<a href="#page-12">12</a>
      <a href="#section-4.2">4.2</a>. Two IPv6 IMS Connected via an IPv4 Network ................<a href="#page-15">15</a>
   <a href="#section-5">5</a>. About 3GPP UE IPv4/IPv6 Configuration ..........................<a href="#page-15">15</a>
   <a href="#section-6">6</a>. Summary and Recommendations ....................................<a href="#page-16">16</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-17">17</a>
   <a href="#section-8">8</a>. References .....................................................<a href="#page-17">17</a>
      <a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-17">17</a>
      <a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-18">18</a>
   <a href="#section-9">9</a>. Contributors ...................................................<a href="#page-20">20</a>
   <a href="#section-10">10</a>. Authors and Acknowledgements ..................................<a href="#page-20">20</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes and analyzes the process of transition to
   IPv6 in Third Generation Partnership Project (3GPP) General Packet
   Radio Service (GPRS) packet networks [<a href="#ref-3GPP-23.060" title="&quot;General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)&quot;">3GPP-23.060</a>], in which the
   radio network architecture is based on Global System for Mobile
   Communications (GSM) or Universal Mobile Telecommunications System
   (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

   This document analyzes the transition scenarios that may come up in
   the deployment phase of IPv6 in 3GPP packet data networks.

   The 3GPP network architecture is described in [<a href="./rfc3314" title="&quot;Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards&quot;">RFC3314</a>], and relevant
   transition scenarios are documented in [<a href="./rfc3574" title="&quot;Transition Scenarios for 3GPP Networks&quot;">RFC3574</a>].  The reader of this
   specification should be familiar with the material presented in these
   documents.

   The scenarios analyzed in this document are divided into two
   categories: general-purpose packet service scenarios, referred to as
   GPRS scenarios in this document, and IP Multimedia Subsystem (IMS)
   scenarios, which include Session Initiation Protocol (SIP)
   considerations.  For more information about IMS, see [<a href="#ref-3GPP-23.228" title="&quot;IP Multimedia Subsystem (IMS); Stage 2 (Release 5)&quot;">3GPP-23.228</a>],
   [<a href="#ref-3GPP-24.228" title="&quot;Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)&quot;">3GPP-24.228</a>], and [<a href="#ref-3GPP-24.229" title="&quot;IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)&quot;">3GPP-24.229</a>].

   GPRS scenarios are the following:

      - Dual Stack User Equipment (UE) connecting to IPv4 and IPv6 nodes
      - IPv6 UE connecting to an IPv6 node through an IPv4 network
      - IPv4 UE connecting to an IPv4 node through an IPv6 network
      - IPv6 UE connecting to an IPv4 node



<span class="grey">Wiljakka                     Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


      - IPv4 UE connecting to an IPv6 node

   IMS scenarios are the following:

      - UE connecting to a node in an IPv4 network through IMS
      - Two IPv6 IMS connected via an IPv4 network

   The focus is on analyzing different transition scenarios and
   applicable transition mechanisms and finding solutions for those
   transition scenarios.  In the scenarios, the User Equipment (UE)
   connects to nodes in other networks, e.g., in the Internet, and
   IPv6/IPv4 transition mechanisms are needed.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Scope of This Document</span>

   The scope of this document is to analyze the possible transition
   scenarios in the 3GPP-defined GPRS network in which a UE connects to,
   or is contacted from, another node on the Internet.  This document
   covers scenarios with and without the use of the SIP-based IP
   Multimedia Core Network Subsystem (IMS).  This document does not
   focus on radio-interface-specific issues; both 3GPP Second and Third
   Generation radio network architectures (GSM, Enhanced Data rates for
   GSM Evolution (EDGE) and UMTS/WCDMA) will be covered by this
   analysis.

   The 3GPP2 architecture is similar to 3GPP in many ways, but differs
   in enough details that this document does not include these
   variations in its analysis.

   The transition mechanisms specified by the IETF Ngtrans and v6ops
   Working Groups shall be used.  This memo shall not specify any new
   transition mechanisms, but only documents the need for new ones (if
   appropriate).

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Abbreviations</span>

   2G          Second Generation Mobile Telecommunications, e.g., GSM
               and GPRS technologies

   3G          Third Generation Mobile Telecommunications, e.g., UMTS
               technology

   3GPP        Third Generation Partnership Project

   ALG         Application Level Gateway

   APN         Access Point Name.  The APN is a logical name referring
               to a GGSN and an external network.



<span class="grey">Wiljakka                     Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   B2BUA       Back-to-Back User Agent

   CSCF        Call Session Control Function (in 3GPP Release 5 IMS)

   DNS         Domain Name System

   EDGE        Enhanced Data rates for GSM Evolution

   GGSN        Gateway GPRS Support Node (default router for 3GPP User
               Equipment)

   GPRS        General Packet Radio Service

   GSM         Global System for Mobile Communications

   HLR         Home Location Register

   IMS         IP Multimedia (Core Network) Subsystem, 3GPP Release 5
               IPv6-only part of the network

   ISP         Internet Service Provider

   NAT         Network Address Translation

   NAPT-PT     Network Address Port Translation - Protocol Translation

   NAT-PT      Network Address Translation - Protocol Translation

   PCO-IE      Protocol Configuration Options Information Element

   PDP         Packet Data Protocol

   PPP         Point-to-Point Protocol

   SDP         Session Description Protocol

   SGSN        Serving GPRS Support Node

   SIIT        Stateless IP/ICMP Translation Algorithm

   SIP         Session Initiation Protocol

   UE          User Equipment, e.g., a UMTS mobile handset

   UMTS        Universal Mobile Telecommunications System

   WCDMA       Wideband Code Division Multiple Access




<span class="grey">Wiljakka                     Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Terminology</span>

   Some terms used in 3GPP transition scenarios and analysis documents
   are briefly defined here.

   Dual Stack UE  Dual Stack UE is a 3GPP mobile handset having both
                  IPv4 and IPv6 stacks.  It is capable of activating
                  both IPv4 and IPv6 Packet Data Protocol (PDP)
                  contexts.  Dual stack UE may be capable of tunneling.

   IPv6 UE        IPv6 UE is an IPv6-only 3GPP mobile handset.  It is
                  only capable of activating IPv6 PDP contexts.

   IPv4 UE        IPv4 UE is an IPv4-only 3GPP mobile handset.  It is
                  only capable of activating IPv4 PDP contexts.

   IPv4 node      IPv4 node is here defined to be the IPv4-capable node
                  the UE is communicating with.  The IPv4 node can be,
                  e.g., an application server or another UE.

   IPv6 node      IPv6 node is here defined to be the IPv6-capable node
                  the UE is communicating with.  The IPv6 node can be,
                  e.g., an application server or another UE.

   PDP Context    Packet Data Protocol (PDP) Context is a connection
                  between the UE and the GGSN, over which the packets
                  are transferred.  There are currently three PDP types:
                  IPv4, IPv6, and PPP.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Transition Mechanisms and DNS Guidelines</span>

   This section briefly introduces these IETF IPv4/IPv6 transition
   mechanisms:

   -  dual IPv4/IPv6 stack [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>]
   -  tunneling [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>]
   -  protocol translators [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>], [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>]

   In addition, DNS recommendations are given.  The applicability of
   different transition mechanisms to 3GPP networks is discussed in
   sections <a href="#section-3">3</a> and <a href="#section-4">4</a>.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Dual Stack</span>

   The dual IPv4/IPv6 stack is specified in [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>].  If we consider
   the 3GPP GPRS core network, dual stack implementation in the Gateway
   GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP
   contexts.  UEs with dual stack and public (global) IP addresses can



<span class="grey">Wiljakka                     Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   typically access both IPv4 and IPv6 services without additional
   translators in the network.  However, it is good to remember that
   private IPv4 addresses and NATs [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>] have been used and will be
   used in mobile networks.  Public/global IP addresses are also needed
   for peer-to-peer services: the node needs a public/global IP address
   that is visible to other nodes.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Tunneling</span>

   Tunneling is a transition mechanism that requires dual IPv4/IPv6
   stack functionality in the encapsulating and decapsulating nodes.
   Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.

   Tunneling can be static or dynamic.  Static (configured) tunnels are
   fixed IPv6 links over IPv4, and they are specified in [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>].
   Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where
   the tunnel endpoints are not configured, i.e., the links are created
   dynamically.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Protocol Translators</span>

   A translator can be defined as an intermediate component between a
   native IPv4 node and a native IPv6 node to enable direct
   communication between them without requiring any modifications to the
   end nodes.

   Header conversion is a translation mechanism.  In header conversion,
   IPv6 packet headers are converted to IPv4 packet headers, or vice
   versa, and checksums are adjusted or recalculated if necessary.
   NAT-PT (Network Address Translation/Protocol Translation) [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>]
   using Stateless IP/ICMP Translation [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>] is an example of such a
   mechanism.

   Translators may be needed in some cases when the communicating nodes
   do not share the same IP version; in others, it may be possible to
   avoid such communication altogether.  Translation can take place at
   the network layer (using NAT-like techniques), the transport layer
   (using a TCP/UDP proxy), or the application layer (using application
   relays).

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  DNS Guidelines for IPv4/IPv6 Transition</span>

   To avoid the DNS name space from fragmenting into parts where some
   parts of DNS are visible only using IPv4 (or IPv6) transport, the
   recommendation (as of this writing) is to always keep at least one
   authoritative server IPv4-enabled, and to ensure that recursive DNS
   servers support IPv4.  See DNS IPv6 transport guidelines [<a href="./rfc3901" title="&quot;DNS IPv6 Transport Operational Guidelines&quot;">RFC3901</a>]
   for more information.



<span class="grey">Wiljakka                     Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  GPRS Transition Scenarios</span>

   This section discusses the scenarios that might occur when a GPRS UE
   contacts services or other nodes, e.g., a web server in the Internet.

   The following scenarios described by [<a href="./rfc3574" title="&quot;Transition Scenarios for 3GPP Networks&quot;">RFC3574</a>] are analyzed here.  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 UE
   is connecting to a node in a different network.

   1) Dual Stack UE connecting to IPv4 and IPv6 nodes

   2) IPv6 UE connecting to an IPv6 node through an IPv4 network

   3) IPv4 UE connecting to an IPv4 node through an IPv6 network

   4) IPv6 UE connecting to an IPv4 node

   5) IPv4 UE connecting to an IPv6 node

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Dual Stack UE Connecting to IPv4 and IPv6 Nodes</span>

   In this scenario, the dual stack UE is capable of communicating with
   both IPv4 and IPv6 nodes.

   It is recommended to activate an IPv6 PDP context when communicating
   with an IPv6 peer node and an IPv4 PDP context when communicating
   with an IPv4 peer node.  If the 3GPP network supports both IPv4 and
   IPv6 PDP contexts, the UE activates the appropriate PDP context
   depending on the type of application it has started or depending on
   the address of the peer host it needs to communicate with.  The
   authors leave the PDP context activation policy to be decided by UE
   implementers, application developers, and operators.  One discussed
   possibility is to activate both IPv4 and IPv6 types of PDP contexts
   in advance, because activation of a PDP context usually takes some
   time.  However, that probably is not 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
   <a href="#section-3.2">Section 3.2</a> for more details).  Note that this is transparent to the
   UE.

   Although the UE is dual stack, the UE may find itself attached to a
   3GPP network in which the Serving GPRS Support Node (SGSN), the GGSN,
   and the Home Location Register (HLR) support IPv4 PDP contexts, but
   do not support IPv6 PDP contexts.  This may happen in early phases of
   IPv6 deployment, or because the UE has "roamed" from a 3GPP network
   that supports IPv6 to one that does not.  If the 3GPP network does
   not support IPv6 PDP contexts, and an application on the UE needs to



<span class="grey">Wiljakka                     Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP
   context and encapsulate IPv6 packets in IPv4 packets using a
   tunneling mechanism.

   The tunneling mechanism may require public IPv4 addresses, but there
   are tunneling mechanisms and deployment scenarios in which private
   IPv4 addresses may be used, for instance, if the tunnel endpoints are
   in the same private domain, or the tunneling mechanism works through
   IPv4 NAT.

   One deployment scenario uses a laptop computer and a 3GPP UE as a
   modem.  IPv6 packets are encapsulated in IPv4 packets in the laptop
   computer and an IPv4 PDP context is activated.  The tunneling
   mechanism depends on the laptop computer's support of tunneling
   mechanisms.  Another deployment scenario is performing 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 can be a good fit.  There is not yet consensus on
   the right approach, and proposed mechanisms so far include [<a href="#ref-ISATAP" title="&quot;Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)&quot;">ISATAP</a>]
   and [<a href="#ref-STEP" title="&quot;Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)&quot;">STEP</a>].  Especially ISATAP has had some support in the working
   group.  Goals for 3GPP zero-configuration tunneling are documented in
   [<a href="#ref-zeroconf" title="&quot;Goals for Zero-Configuration Tunneling in 3GPP&quot;">zeroconf</a>].

   This document strongly recommends that the 3GPP operators deploy
   basic IPv6 support in their GPRS networks.  That makes it possible to
   lessen the transition effects in the UEs.

   As a general guideline, IPv6 communication is preferred to IPv4
   communication going through IPv4 NATs to the same dual stack peer
   node.

   Public IPv4 addresses are often a scarce resource for the operator,
   and usually it is not possible for a UE to have a public 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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  IPv6 UE Connecting to an IPv6 Node through an IPv4 Network</span>

   The best solution for this scenario is obtained with tunneling; 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 the
   network, because IPv6 UE does not have the dual stack functionality
   needed for tunneling.  The encapsulating node can be the GGSN, the
   edge router between the border of the operator's IPv6 network and the



<span class="grey">Wiljakka                     Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   public Internet, or any other dual stack node within the operator's
   IP network.  The encapsulation (uplink) and decapsulation (downlink)
   can be handled by the same network element.  Typically, the tunneling
   handled by the network elements is transparent to the UEs and IP
   traffic looks like native IPv6 traffic to them.  For the applications
   and transport protocols, tunneling enables end-to-end IPv6
   connectivity.

   IPv6-in-IPv4 tunnels between IPv6 islands can be either static or
   dynamic.  The selection of the type of tunneling mechanism is a
   policy decision for the operator/ISP deployment scenario, and only
   generic 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 depend on the deployment scenario.  The authors are not
   commenting on how many ISP functions the 3GPP operator should
   perform.  However, many 3GPP operators are ISPs of some sort
   themselves.  ISP networks' transition to IPv6 is analyzed in
   [<a href="./rfc4029" title="&quot;Scenarios and Analysis for Introducing IPv6 into ISP Networks&quot;">RFC4029</a>].

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Tunneling Inside the 3GPP Operator's Network</span>

   GPRS operators today have typically deployed IPv4 backbone networks.
   IPv6 backbones can be considered quite rare in the first phases of
   the transition.

   In initial IPv6 deployment, where a small number of IPv6-in-IPv4
   tunnels are required to connect the IPv6 islands over the 3GPP
   operator's IPv4 network, manually configured tunnels can be used.  In
   a 3GPP network, one IPv6 island can contain the GGSN while another
   island can contain the operator's IPv6 application servers.  However,
   manually configured tunnels can be an administrative burden when the
   number of islands and therefore tunnels rises.  In that case,
   upgrading parts of the backbone to dual stack may be the simplest
   choice.  The administrative burden could also be mitigated by using
   automated management tools.

   Connection redundancy should also be noted as an important
   requirement in 3GPP networks.  Static tunnels alone do not provide a
   routing recovery solution for all scenarios where an IPv6 route goes
   down.  However, they can provide an adequate solution depending on
   the design of the network and the presence of other router redundancy
   mechanisms, such as the use of IPv6 routing protocols.





<span class="grey">Wiljakka                     Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Tunneling Outside the 3GPP Operator's Network</span>

   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
   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
   how far the 3GPP operator has come in implementing IPv6.  If the 3GPP
   operator has not deployed IPv6 in its backbone, the encapsulating
   node can be the GGSN.  If the 3GPP operator has deployed IPv6 in its
   backbone but the upstream ISP does not provide IPv6 connectivity, the
   encapsulating node could be the 3GPP operator's border router.

   The case is pretty straightforward if the upstream ISP provides IPv6
   connectivity to the Internet and the operator's backbone network
   supports IPv6.  Then the 3GPP operator does not have to configure any
   tunnels, since the upstream ISP will take care of routing IPv6
   packets.  If the upstream ISP does not provide IPv6 connectivity, an
   IPv6-in-IPv4 tunnel should be configured, e.g., from the border
   router to a dual stack border gateway operated by another ISP that is
   offering IPv6 connectivity.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  IPv4 UE Connecting to an IPv4 Node through an IPv6 Network</span>

   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 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-v4NODE.  This
   allows an IPv4-only UE to use an IPv4 link (an IPv4 PDP context) to
   connect to the GGSN without communicating over an IPv6 network.

   Regarding the GGSN-to-v4NODE communication, typically the transport
   network between the GGSN and external networks will support only IPv4
   in the early stages and migrate to dual stack, since these networks
   are already deployed.  Therefore, it is not envisaged that tunneling
   of IPv4-in-IPv6 will be required from the GGSN to external IPv4
   networks either.  In the longer run, 3GPP operators may choose to
   phase out IPv4 UEs and the IPv4 transport network.  This would leave
   only IPv6 UEs.

   Therefore, overall, the transition scenario involving an IPv4 UE
   communicating with an IPv4 peer through an IPv6 network is not
   considered very likely in 3GPP networks.







<span class="grey">Wiljakka                     Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  IPv6 UE Connecting to an IPv4 Node</span>

   Generally speaking, IPv6-only UEs may be easier to manage, but that
   would require all services to be used over IPv6, and the universal
   deployment of IPv6 probably is not realistic in the near future.
   Dual stack implementation requires management of both IPv4 and IPv6
   networks, and one approach is that "legacy" applications keep using
   IPv4 for the foreseeable future and new applications requiring end-
   to-end connectivity (for example, peer-to-peer services) use IPv6.
   As a general guideline, IPv6-only UEs are not recommended in the
   early phases of transition until the IPv6 deployment has become so
   prevalent that direct communication with IPv4(-only) nodes will be
   the exception and not the rule.  It is assumed that IPv4 will remain
   useful for quite a long time, so in general, dual stack
   implementation in the UE can be recommended.  This recommendation
   naturally includes manufacturing dual stack UEs instead of IPv4-only
   UEs.

   However, if there is a need to connect to an IPv4(-only) node from an
   IPv6-only UE, it is recommended to use specific translation and
   proxying techniques; generic IP protocol translation is not
   recommended.  There are three main ways for IPv6(-only) nodes to
   communicate with IPv4(-only) nodes (excluding avoiding such
   communication in the first place):

      1. the use of generic-purpose translator (e.g., NAT-PT [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>])
         in the local network (not recommended as a general solution),

      2. the use of specific-purpose protocol relays (e.g., IPv6&lt;-&gt;IPv4
         TCP relay configured for a couple of ports only [<a href="./rfc3142" title="&quot;An IPv6-to-IPv4 Transport Relay Translator&quot;">RFC3142</a>]) or
         application proxies (e.g., HTTP proxy, SMTP relay) in the local
         network, or

      3. the use of specific-purpose mechanisms (as described above in
         2) in the foreign network; these are indistinguishable from the
         IPv6-enabled services from the IPv6 UE's perspective and are
         not discussed further here.

   For many applications, application proxies can be appropriate (e.g.,
   HTTP proxies, SMTP relays, etc.)  Such application proxies will not
   be transparent to the UE.  Hence, a flexible mechanism with minimal
   manual intervention should be used to configure these proxies on IPv6
   UEs.  Application proxies can be placed, for example, on the GGSN
   external interface ("Gi"), or inside the service network.







<span class="grey">Wiljakka                     Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   The authors note that [<a href="#ref-NATPTappl" title="&quot;NAT-PT Applicability&quot;">NATPTappl</a>] discusses the applicability of
   NAT-PT, and [<a href="#ref-NATPTexp" title="&quot;Reasons to Move NAT-PT to Experimental&quot;">NATPTexp</a>] discusses general issues with all forms of
   IPv6-IPv4 translation.  The problems related to NAT-PT usage in 3GPP
   networks are documented in <a href="#appendix-A">Appendix A</a>.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  IPv4 UE Connecting to an IPv6 Node</span>

   The legacy IPv4 nodes are typically nodes that support the
   applications that are popular today in the IPv4 Internet: mostly e-
   mail and web browsing.  These applications will, of course, be
   supported in the future IPv6 Internet.  However, the legacy IPv4 UEs
   are not going to be updated to support future applications.  As these
   applications are designed for IPv6, and to use the advantages of
   newer platforms, the legacy IPv4 nodes will not be able to take
   advantage of them.  Thus, they will continue to support legacy
   services.

   Taking the above into account, the traffic to and from the legacy
   IPv4 UE is restricted to a few applications.  These applications
   already mostly rely on proxies or local servers to communicate
   between private address space networks and the Internet.  The same
   methods and technology can be used for IPv4-to-IPv6 transition.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  IMS Transition Scenarios</span>

   As IMS is exclusively IPv6, the number of possible transition
   scenarios is reduced dramatically.  The possible IMS scenarios are
   listed below and analyzed in Sections <a href="#section-4.1">4.1</a> and <a href="#section-4.2">4.2</a>.

      1) UE connecting to a node in an IPv4 network through IMS
      2) Two IPv6 IMS connected via an IPv4 network

   For DNS recommendations, we refer to <a href="#section-2.4">Section 2.4</a>.  As DNS traffic is
   not directly related to the IMS functionality, the recommendations
   are not in contradiction with the IPv6-only nature of the IMS.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  UE Connecting to a Node in an IPv4 Network through IMS</span>

   This scenario occurs when an (IPv6) IMS UE connects to a node in 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 fixed
   PC, with only IPv4 capabilities.

   Over time, users will upgrade the legacy IPv4 nodes to dual-stack,
   often by replacing the entire node, eliminating this particular
   problem in that specific deployment.





<span class="grey">Wiljakka                     Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   Still, it is difficult to estimate how many non-upgradable legacy
   IPv4 nodes need to communicate with the IMS UEs.  It is assumed that
   the solution described here is used for limited cases, in which
   communications with a small number of legacy IPv4 SIP equipment are
   needed.

   As the IMS is exclusively IPv6 [<a href="#ref-3GPP-23.221" title="&quot;Architectural requirements (Release 5)&quot;">3GPP-23.221</a>], for many of the
   applications in the IMS, some kind of translators may need to be used
   in the communication between the IPv6 IMS and the legacy IPv4 hosts
   in cases where these legacy IPv4 hosts cannot be upgraded to support
   IPv6.

   This section gives a brief analysis of the IMS interworking issues
   and presents a high-level view of SIP within the IMS.  The authors
   recommend that a detailed solution for the general SIP/SDP/media
   IPv4/IPv6 transition problem will be specified as soon as possible as
   a task within the SIP-related Working Groups in the IETF.

   The issue of the IPv4/IPv6 interworking in SIP is somewhat more
   challenging than many other protocols.  The control (or signaling)
   and user (or data) traffic are separated in SIP calls, and thus, the
   IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled
   at two levels:

      1. Session Initiation Protocol (SIP) [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>], and Session
         Description Protocol (SDP) [<a href="./rfc2327" title="&quot;SDP: Session Description Protocol&quot;">RFC2327</a>] [<a href="./rfc3266" title="&quot;Support for IPv6 in Session Description Protocol (SDP)&quot;">RFC3266</a>] (Mm-interface)

      2. the user data traffic (Mb-interface)

   In addition, SIP carries an SDP body containing the addressing and
   other parameters for establishing the user data traffic (the media).
   Hence, the two levels of interworking cannot be made independently.

   Figure 1 shows an example setup for IPv4 and IPv6 interworking in
   IMS.  The "Interworking Unit" comprises two internal elements a dual
   stack SIP server and a transition gateway (TrGW) for the media
   traffic.  These two elements are interconnected for synchronizing the
   interworking of the SIP signaling and the media traffic.













<span class="grey">Wiljakka                     Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


           +-------------------------------+ +------------+
           |                      +------+ | | +--------+ |
           |                      |S-CSCF|---| |SIP Serv| |\
        |  |                      +------+ | | +--------+ | \ --------
      +-|+ |                       /       | |     |      |  |        |
      |  | | +------+        +------+      | |     +      |   -|    |-
      |  |-|-|P-CSCF|--------|I-CSCF|      | |     |      |    | () |
      |  |   +------+        +------+      | |+----------+| /  ------
      |  |-----------------------------------||   TrGW   ||/
      +--+ |            IPv6               | |+----------+|     IPv4
       UE  |                               | |Interworking|
           |  IP Multimedia CN Subsystem   | |Unit        |
           +-------------------------------+ +------------+

                Figure 1: UE using IMS to contact a legacy phone

   On reception of an INVITE, the SIP server reserves an IP address and
   a port from the TrGW both for IPv4 and IPv6.  Then, the SIP server
   acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the
   INVITE to insert the transition gateway in the middle of the media
   flow between the two endpoints.

   When performing its B2BUA role, the SIP server acts as a UA (User
   Agent) toward both the IMS and the IPv4 host.  Consequently, the SIP
   server needs to support all the extensions that apply to the session,
   which are listed in the Require header fields of the SIP messages.

   This approach has a number of important drawbacks, however.  The
   biggest drawback is that the rewriting of the SDP in the SIP
   signaling prevents securing the SDP payload between the two
   endpoints.  In addition, it breaks the end-to-end negotiation of SIP
   extensions required for each session.  Therefore, the extensions to
   be used in a particular session are limited by the extensions
   supported by the SIP server acting as a B2BUA.  That is, the
   introduction of a new extension requires upgrading not only the UAs
   but the B2BUAs as well.

   This analysis clearly shows that a new solution for IPv4-IPv6
   interworking in SIP networks is needed.  The ability to convey
   multiple alternative addresses in SDP session descriptions [<a href="./rfc4091" title="&quot;The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework&quot;">RFC4091</a>]
   represents a step in this direction.

   Given the problems related to the use of B2BUAs, it is recommended
   that the SIP-related Working Groups quickly work on a solution to
   overcome the drawbacks of this approach.






<span class="grey">Wiljakka                     Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Two IPv6 IMS Connected via an IPv4 Network</span>

   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
   Internet.  Here both the UEs and the IMS islands are IPv6 only.
   However, the IPv6 islands are not connected natively with IPv6.

   In this scenario, the end-to-end SIP connections are based on IPv6.
   The only issue is to make connection between two IPv6-only IMS
   islands over IPv4 network.  This scenario is closely related to GPRS
   scenario represented in <a href="#section-3.2">Section 3.2</a>. and similar tunneling solutions
   are applicable also in this scenario.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  About 3GPP UE IPv4/IPv6 Configuration</span>

   This informative section aims to give a brief overview of the
   configuration needed in the UE in order to access IP-based services.
   There can also be other application-specific settings in the UE that
   are not described here.

   UE configuration is required in order to access IPv6- or IPv4-based
   services.  The GGSN Access Point has to be defined when using, for
   example, the web-browsing application.  One possibility is to use
   over-the-air configuration [<a href="#ref-OMA-CP" title=" Open Mobile Alliance">OMA-CP</a>] to configure the GPRS settings.
   The user can, for example, visit the operator WWW page and subscribe
   the GPRS Access Point settings to his/her UE and receive the settings
   via Short Message Service (SMS).  After the user has accepted the
   settings and a PDP context has been activated, he/she can start
   browsing.  The Access Point settings can also be typed in manually or
   be pre-configured by the operator or the UE manufacturer.

   DNS server addresses typically also need to be configured in the UE.
   In the case of IPv4 type PDP context, the (IPv4) DNS server addresses
   can be received in the PDP context activation (a control plane
   mechanism).  A similar mechanism is also available for IPv6: so-
   called Protocol Configuration Options Information Element (PCO-IE)
   specified by the 3GPP [<a href="#ref-3GPP-24.008" title="&quot;Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)&quot;">3GPP-24.008</a>].  It is also possible to use
   [<a href="./rfc3736" title="&quot;Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6&quot;">RFC3736</a>] (or [<a href="./rfc3315" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3315</a>]) and [<a href="./rfc3646" title="&quot;DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)&quot;">RFC3646</a>] for receiving DNS server
   addresses.  Active IETF work on DNS discovery mechanisms is ongoing
   and might result in other mechanisms becoming available over time.
   The DNS server addresses can also be received over the air (using
   SMS) [<a href="#ref-OMA-CP" title=" Open Mobile Alliance">OMA-CP</a>] or typed in manually in the UE.

   When accessing IMS services, the UE needs to know the Proxy-Call
   Session Control Function (P-CSCF) IPv6 address.  Either a 3GPP-
   specific PCO-IE mechanism or a DHCPv6-based mechanism ([<a href="./rfc3736" title="&quot;Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6&quot;">RFC3736</a>] and
   [<a href="./rfc3319" title="&quot;Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers&quot;">RFC3319</a>]) can be used.  Manual configuration or configuration over




<span class="grey">Wiljakka                     Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   the air is also possible.  IMS subscriber authentication and
   registration to the IMS and SIP integrity protection are not
   discussed here.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Summary and Recommendations</span>

   This document has analyzed five GPRS and two IMS IPv6 transition
   scenarios.  Numerous 3GPP networks are using private IPv4 addresses
   today, and introducing IPv6 is important.  The two first GPRS
   scenarios and both IMS scenarios are seen as the most relevant.  The
   authors summarize some main recommendations here:

      -  Dual stack UEs are recommended instead of IPv4-only or IPv6-
         only UEs.  It is important to take care that applications in
         the UEs support IPv6.  In other words, applications should be
         IP version independent.  IPv6-only UEs can become feasible when
         IPv6 is widely deployed in the networks, and most services work
         on IPv6.

      -  It is recommended to activate an IPv6 PDP context when
         communicating with an IPv6 peer node and an IPv4 PDP context
         when communicating with an IPv4 peer node.

      -  IPv6 communication is preferred to IPv4 communication going
         through IPv4 NATs to the same dual stack peer node.

      -  This document strongly recommends that the 3GPP operators
         deploy basic IPv6 support in their GPRS networks as soon as
         possible.  That makes it possible to lessen the transition
         effects in the UEs.

      -  A tunneling mechanism in the UE may be needed during the early
         phases of the IPv6 transition process.  A lightweight,
         automatic tunneling mechanism should be standardized in the
         IETF.  See [<a href="#ref-zeroconf" title="&quot;Goals for Zero-Configuration Tunneling in 3GPP&quot;">zeroconf</a>] for more details.

      -  Tunneling mechanisms can be used in 3GPP networks, and only
         generic recommendations are given in this document.  More
         details can be found, for example, in [<a href="./rfc4029" title="&quot;Scenarios and Analysis for Introducing IPv6 into ISP Networks&quot;">RFC4029</a>].

      -  The authors recommend that a detailed solution for the general
         SIP/SDP/media IPv4/IPv6 transition problem be specified as soon
         as possible as a task within the SIP-related Working Groups in
         the IETF.







<span class="grey">Wiljakka                     Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   Deploying IPv6 has some generic security considerations one should be
   aware of [<a href="#ref-V6SEC" title="&quot;IPv6 Transition/Co-existence Security Considerations&quot;">V6SEC</a>]; however, these are not specific to 3GPP transition
   and are therefore out of the scope of this memo.

   This memo recommends the use of a relatively small number of
   techniques.  Each technique has its own security considerations,
   including:

      -  native upstream access or tunneling by the 3GPP network
         operator,

      -  use of routing protocols to ensure redundancy,

      -  use of locally deployed specific-purpose protocol relays and
         application proxies to reach IPv4(-only) nodes from IPv6-only
         UEs, or

      -  a specific mechanism for SIP signaling and media translation.

   The threats of configured tunneling are described in [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>].
   Attacks against routing protocols are described in the respective
   documents and in general in [<a href="#ref-ROUTESEC" title="&quot;Generic Threats to Routing Protocols&quot;">ROUTESEC</a>].  Threats related to protocol
   relays have been described in [<a href="./rfc3142" title="&quot;An IPv6-to-IPv4 Transport Relay Translator&quot;">RFC3142</a>].  The security properties of
   SIP internetworking are to be specified when the mechanism is
   specified.

   In particular, this memo does not recommend the following technique,
   which has security issues, not further analyzed here:

      -  NAT-PT or other translator as a general-purpose transition
         mechanism

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC2663">RFC2663</a>]     Srisuresh, P. and M. Holdrege, "IP Network Address
                 Translator (NAT) Terminology and Considerations", <a href="./rfc2663">RFC</a>
                 <a href="./rfc2663">2663</a>, August 1999.

   [<a id="ref-RFC2765">RFC2765</a>]     Nordmark, E., "Stateless IP/ICMP Translation Algorithm
                 (SIIT)", <a href="./rfc2765">RFC 2765</a>, February 2000.

   [<a id="ref-RFC2766">RFC2766</a>]     Tsirtsis, G. and P. Srisuresh, "Network Address
                 Translation - Protocol Translation (NAT-PT)", <a href="./rfc2766">RFC 2766</a>,
                 February 2000.



<span class="grey">Wiljakka                     Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   [<a id="ref-RFC3261">RFC3261</a>]     Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                 Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                 and E. Schooler, "SIP:  Session Initiation Protocol",
                 <a href="./rfc3261">RFC 3261</a>, June 2002.

   [<a id="ref-RFC3574">RFC3574</a>]     Soininen, J., "Transition Scenarios for 3GPP Networks",
                 <a href="./rfc3574">RFC 3574</a>, August 2003.

   [<a id="ref-RFC4213">RFC4213</a>]     Nordmark, E. and R. Gilligan, "Basic Transition
                 Mechanisms for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>,
                 October 2005.

   [<a id="ref-3GPP-23.060">3GPP-23.060</a>] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
                 (GPRS); Service description; Stage 2 (Release 5)",
                 December 2002.

   [<a id="ref-3GPP-23.221">3GPP-23.221</a>] 3GPP TS 23.221 V5.7.0, "Architectural requirements
                 (Release 5)", December 2002.

   [<a id="ref-3GPP-23.228">3GPP-23.228</a>] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS);
                 Stage 2 (Release 5)", December 2002.

   [<a id="ref-3GPP-24.228">3GPP-24.228</a>] 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.

   [<a id="ref-3GPP-24.229">3GPP-24.229</a>] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control
                 Protocol based on SIP and SDP; Stage 3 (Release 5)",
                 December 2002.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-RFC2327">RFC2327</a>]     Handley, M. and V. Jacobson, "SDP: Session Description
                 Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.

   [<a id="ref-RFC3142">RFC3142</a>]     Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
                 Relay Translator", <a href="./rfc3142">RFC 3142</a>, June 2001.

   [<a id="ref-RFC3266">RFC3266</a>]     Olson, S., Camarillo, G., and A. Roach, "Support for
                 IPv6 in Session Description Protocol (SDP)", <a href="./rfc3266">RFC 3266</a>,
                 June 2002.

   [<a id="ref-RFC3314">RFC3314</a>]     Wasserman, M., "Recommendations for IPv6 in Third
                 Generation Partnership Project (3GPP) Standards", <a href="./rfc3314">RFC</a>
                 <a href="./rfc3314">3314</a>, September 2002.






<span class="grey">Wiljakka                     Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   [<a id="ref-RFC3315">RFC3315</a>]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
                 and M. Carney, "Dynamic Host Configuration Protocol for
                 IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.

   [<a id="ref-RFC3319">RFC3319</a>]     Schulzrinne, H. and B. Volz, "Dynamic Host
                 Configuration Protocol (DHCPv6) Options for Session
                 Initiation Protocol (SIP) Servers", <a href="./rfc3319">RFC 3319</a>, July
                 2003.

   [<a id="ref-RFC3646">RFC3646</a>]     Droms, R., "DNS Configuration options for Dynamic Host
                 Configuration Protocol for IPv6 (DHCPv6)", <a href="./rfc3646">RFC 3646</a>,
                 December 2003.

   [<a id="ref-RFC3736">RFC3736</a>]     Droms, R., "Stateless Dynamic Host Configuration
                 Protocol (DHCP) Service for IPv6", <a href="./rfc3736">RFC 3736</a>, April
                 2004.

   [<a id="ref-RFC3901">RFC3901</a>]     Durand, A. and J. Ihren, "DNS IPv6 Transport
                 Operational Guidelines", <a href="https://www.rfc-editor.org/bcp/bcp91">BCP 91</a>, <a href="./rfc3901">RFC 3901</a>, September
                 2004.

   [<a id="ref-RFC4029">RFC4029</a>]     Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
                 Savola, "Scenarios and Analysis for Introducing IPv6
                 into ISP Networks", <a href="./rfc4029">RFC 4029</a>, March 2005.

   [<a id="ref-RFC4091">RFC4091</a>]     Camarillo, G. and J. Rosenberg, "The Alternative
                 Network Address Types (ANAT) Semantics for the Session
                 Description Protocol (SDP) Grouping Framework", <a href="./rfc4091">RFC</a>
                 <a href="./rfc4091">4091</a>, June 2005.

   [<a id="ref-ISATAP">ISATAP</a>]      Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
                 "Intra-Site Automatic Tunnel Addressing Protocol
                 (ISATAP)", <a href="./rfc4214">RFC 4214</a>, September 2005.

   [<a id="ref-NATPTappl">NATPTappl</a>]   Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
                 and H. Wang, "NAT-PT Applicability", Work in Progress,
                 October 2003.

   [<a id="ref-NATPTexp">NATPTexp</a>]    Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
                 Experimental", Work in Progress, July 2005.

   [<a id="ref-ROUTESEC">ROUTESEC</a>]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats
                 to Routing Protocols", Work in Progress, April 2004.

   [<a id="ref-STEP">STEP</a>]        Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
                 Procedure (STEP)", Work in Progress, January 2004.





<span class="grey">Wiljakka                     Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


   [<a id="ref-V6SEC">V6SEC</a>]       Savola, P.: "IPv6 Transition/Co-existence Security
                 Considerations", Work in Progress, February 2004.

   [<a id="ref-zeroconf">zeroconf</a>]    Nielsen, K., Morelli, M., Palet, J., Soininen, J., and
                 J. Wiljakka, "Goals for Zero-Configuration Tunneling in
                 3GPP", Work in Progress, October 2004.

   [<a id="ref-3GPP-24.008">3GPP-24.008</a>] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
                 specification; Core network protocols; Stage 3 (Release
                 5)", June 2003.

   [<a id="ref-OMA-CP">OMA-CP</a>]      OMA Client Provisioning: Provisioning Architecture
                 Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C,
                 Open Mobile Alliance, 12-Nov-2002.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Contributors</span>

   Pekka Savola has contributed both text and his IPv6 experience to
   this document.  He has provided a large number of helpful comments on
   the v6ops mailing list.  Allison Mankin has contributed text for IMS
   Scenario 1 (<a href="#section-4.1">Section 4.1</a>).

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Authors and Acknowledgements</span>

   This document was written by:

      Alain Durand, Comcast
      &lt;alain_durand@cable.comcast.com&gt;

      Karim El-Malki, Ericsson Radio Systems
      &lt;Karim.El-Malki@era.ericsson.se&gt;

      Niall Richard Murphy, Enigma Consulting Limited
      &lt;niallm@enigma.ie&gt;

      Hugh Shieh, AT&amp;T Wireless
      &lt;hugh.shieh@attws.com&gt;

      Jonne Soininen, Nokia
      &lt;jonne.soininen@nokia.com&gt;

      Hesham Soliman, Flarion
      &lt;h.soliman@flarion.com&gt;








<span class="grey">Wiljakka                     Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


      Margaret Wasserman, ThingMagic
      &lt;margaret@thingmagic.com&gt;

      Juha Wiljakka, Nokia
      &lt;juha.wiljakka@nokia.com&gt;

   The authors would like to give special thanks to Spencer Dawkins for
   proofreading.

   The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo
   Camarillo, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux,
   Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid,
   Pedro Serna, Fred Templin, Anand Thakur, and Rod Van Meter for their
   valuable input.





































<span class="grey">Wiljakka                     Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


Appendix A - On the Use of Generic Translators in the 3GPP Networks

   This appendix lists mainly 3GPP-specific arguments about generic
   translators, even though the use of generic translators is
   discouraged.

   Due to the significant lack of IPv4 addresses in some domains, port
   multiplexing is likely to be a necessary feature for translators
   (i.e., NAPT-PT).  If NAPT-PT is used, it needs to be placed on the
   GGSN external interface (Gi), typically separate from the GGSN.
   NAPT-PT can be installed, for example, on the edge of the operator's
   network and the public Internet.  NAPT-PT will intercept DNS requests
   and other applications that include IP addresses in their payloads,
   translate the IP header (and payload for some applications if
   necessary), and forward packets through its IPv4 interface.

   NAPT-PT introduces limitations that are expected to be magnified
   within the 3GPP architecture.  [<a href="#ref-NATPTappl" title="&quot;NAT-PT Applicability&quot;">NATPTappl</a>] discusses the
   applicability of NAT-PT in more detail.  [<a href="#ref-NATPTexp" title="&quot;Reasons to Move NAT-PT to Experimental&quot;">NATPTexp</a>] discusses general
   issues with all forms of IPv6-IPv4 translation.

   3GPP networks are expected to handle a very large number of
   subscribers on a single GGSN (default router).  Each GGSN is expected
   to handle hundreds of thousands of connections.  Furthermore, high
   reliability is expected for 3GPP networks.  Consequently, a single
   point of failure on the GGSN external interface would raise concerns
   on the overall network reliability.  In addition, IPv6 users are
   expected to use delay-sensitive applications provided by IMS.  Hence,
   there is a need to minimize forwarding delays within the IP backbone.
   Furthermore, due to the unprecedented number of connections handled
   by the default routers (GGSN) in 3GPP networks, a network design that
   forces traffic to go through a single node at the edge of the network
   (typical NAPT-PT configuration) is not likely to scale.  Translation
   mechanisms should allow for multiple translators, for load sharing
   and redundancy purposes.

   To minimize the problems associated with NAPT-PT, the following
   actions can be recommended:

      1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to
         IPv4" case).

      2. Ensure (if possible) that NAPT-PT does not become a single
         point of failure.







<span class="grey">Wiljakka                     Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


      3. Allow for load sharing between different translators.  That is,
         it should be possible for different connections to go through
         different translators.  Note that load sharing alone does not
         prevent NAPT-PT from becoming a single point of failure.

Editor's Contact Information

   Comments or questions regarding this document should be sent to the
   v6ops mailing list or directly to the document editor:

   Juha Wiljakka
   Nokia
   Visiokatu 3
   FIN-33720 TAMPERE, Finland

   Phone:  +358 7180 48372
   EMail:  juha.wiljakka@nokia.com


































<span class="grey">Wiljakka                     Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4215">RFC 4215</a>            IPv6 Transition in 3GPP Networks        October 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Wiljakka                     Informational                     [Page 24]
</pre>