Internet Draft                                       J. Wiljakka (ed.)
 Document: draft-ietf-v6ops-3gpp-analysis-10.txt draft-ietf-v6ops-3gpp-analysis-11.txt                  Nokia
 Expires: November 2004

                                                               May April 2005

                                                           October 2004

                Analysis on IPv6 Transition in 3GPP Networks

 Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance
    with RFC 3668.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups. Note that
    other groups may also distribute working documents as Internet-

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time. It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in

    The list of current Internet-Drafts can be accessed at
    The list of Internet-Draft Shadow Directories can be accessed at


    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,
    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

    1. Introduction..................................................2
       1.1 Scope of this Document....................................3
       1.2 Abbreviations.............................................4
       1.3 Terminology...............................................4
    2. Transition Mechanisms and DNS Guidelines......................5
       2.1 Dual Stack................................................5
       2.2 Tunneling.................................................5
       2.3 Protocol Translators......................................6
       2.4 DNS Guidelines for IPv4/IPv6 Transition...................6
    3. GPRS Transition Scenarios.....................................6
       3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........7
       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 Network.
       3.4 IPv6 UE Connecting to an IPv4 Node.......................10
       3.5 IPv4 UE Connecting to an IPv6 Node.......................11
    4. IMS Transition Scenarios.....................................12
       4.1 UE Connecting to a Node in an IPv4 Network through IMS...12
       4.2 Two IPv6 IMS Connected via an IPv4 Network...............14
    5. About 3GPP UE IPv4/IPv6 Configuration........................14
    6. Summary and Recommendations..................................15
    7. Security Considerations......................................16 Considerations......................................15
    8. References...................................................16 References...................................................17
       8.1 Normative................................................16 Normative................................................17
       8.2 Informative..............................................17
    9. Contributors.................................................19
    10. Authors and Acknowledgements................................19
    11. Editor's Contact Information................................20
    12. Intellectual Property Statement.............................20
    13. Copyright...................................................20 Copyright...................................................21
       Appendix A...................................................21

 1. Introduction

    This document describes and analyzes the process of transition to
    IPv6 in Third Generation Partnership Project (3GPP) General Packet
    Radio Service (GPRS) packet networks, 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 [RFC3314], and
    relevant transition scenarios are documented in [RFC3574]. 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)

    GPRS scenarios are the following:
       - Dual Stack 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
       - 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,
    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.

 1.1 Scope of this Document

    The scope of this document is to analyze the possible transition
    scenarios in the 3GPP defined GPRS network where a UE connects to,
    or is contacted from, another node on the Internet. The 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, 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

 1.2 Abbreviations

    2G          Second Generation Mobile Telecommunications, for
                 example GSM and GPRS technologies.
    3G          Third Generation Mobile Telecommunications, for example
                 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.
    CSCF        Call Session Control Function (in 3GPP Release 5 IMS)
    DNS         Domain Name System
    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 Translator
    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
    SGSN        Serving GPRS Support Node
    SIIT        Stateless IP/ICMP Translation Algorithm
    SIP         Session Initiation Protocol
    UE          User Equipment, for example a UMTS mobile handset
    UMTS        Universal Mobile Telecommunications System
    WCDMA       Wideband Code Division Multiple Access

 1.3 Terminology

    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 IPv4 capable node
                   the UE is communicating with. The IPv4 node can
                   be, for example, an application server or another

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

    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.

 2. Transition Mechanisms and DNS Guidelines

    This chapter briefly introduces these IETF IPv4/IPv6 transition

    -  dual IPv4/IPv6 stack [RFC2893-bis]
    -  tunneling [RFC2893-bis]
    -  protocol translators [RFC 2766], [RFC2765]

    In addition, DNS recommendations are given. The applicability of
    different transition mechanisms to 3GPP networks is discussed in
    chapters 3 and 4.

 2.1 Dual Stack

    The dual IPv4/IPv6 stack is specified in [RFC2893-bis]. 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 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 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.

 2.2 Tunneling

    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 [RFC2893-
    bis]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4
    where the tunnel endpoints are not configured, i.e. the links are
    created dynamically.

 2.3 Protocol Translators

    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 Translator / Protocol Translator) [RFC2766]
    using Stateless IP/ICMP Translation [RFC2765] 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).

 2.4 DNS Guidelines for IPv4/IPv6 Transition

    To avoid the DNS name space from fragmenting into parts where some
    parts of DNS are only visible 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 [DNStrans] [RFC3901]
    for more information.

 3. GPRS Transition Scenarios

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

    The following scenarios described by [RFC3574] 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

 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes

    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 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.

    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 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 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 may can be a good fit. There is not yet
    consensus on the right approach, and proposed mechanisms so far
    include [ISATAP] and [STEP]. Especially ISATAP has had some support
    in the wg. However, further work is needed to find out the
    requirements Goals for the scenario and to specify the mechanism. 3GPP zero-configuration tunneling are
    documented in [zeroconf].

    This document strongly recommends the 3GPP operators to 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

    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.

 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network

    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 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 depends on the deployment scenario. The
    authors are not commenting 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 [ISP-

 3.2.1 Tunneling inside the 3GPP Operator's Network

    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 don't 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.

 3.2.2 Tunneling outside the 3GPP Operator's Network

    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 which is offering IPv6 connectivity.

 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
    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.

 3.4 IPv6 UE Connecting to an IPv4 Node

    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 isnít isn∆t 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 [RFC2766])
         in the local network (not recommended as a general solution),

       2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4
         TCP relay configured for a couple of ports only [RFC3142]) 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
         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.

    The authors note that [NATPTappl] discusses the applicability of
    NAT-PT and [NATPTdep] discusses the reasons to deprecate NAT-PT.
    The problems related to NAT-PT usage in 3GPP networks are
    documented in appendix A.

 3.5 IPv4 UE Connecting to an IPv6 Node

    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

    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.

 4. IMS Transition Scenarios

    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 4.1 and 4.2.

       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 section 2.4. 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.

 4.1 UE Connecting to a Node in an IPv4 Network through IMS

    This scenario occurs when an (IPv6) IMS UE (IPv6) 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.

    Still, it is difficult to estimate how many non-upgradeable 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

    As the IMS is exclusively IPv6 [3GPP 23.221], 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 WGs 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) [RFC3261], and Session
         Description Protocol (SDP) [RFC2327] [RFC3266] (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

    Figure 1 shows a signaling edge an example setup for SIP IPv4 and SDP, IPv6 interworking in
    IMS. The "Interworking Unit" comprises two internal elements a dual stack
    dual-stack SIP
    proxy at the border between the 3GPP IPv6-only IMS server and the IPv4

    In a possible approach, this edge could contain a SIP ALG, which
    would change the IP addresses transported in the SIP messages and
    the SDP payload of those messages to the appropriate  version. This
    approach would have the drawback (like other SDP rewriting
    solutions) of impacting authentication mechanisms that may be
    needed transition gateway (TrGW) for other purposes. Moreover, this approach would not take
    advantage of SIP's ability to use proxy routing, nor of SDP's
    ability to carry multiple alternative addresses. These intrinsic
    features of SIP and SDP require a more detailed analysis, but they
    could yield benefits. The SIP ALG approach requires NAT-PT (with the issues described in Appendix A), because the IMS-side IPv6
    addresses must be assigned IPv4 addresses media
    traffic. These two elements are interconnected for reachability from synchronizing
    legacy IPv4 side shown in Figure 1. The approach based on intrinsic
    SIP proxy routing would not require assignment interworking of temporary IPv4
    addresses to the IPv6 IMS endpoints; instead they would be reached
    via an IPv4-side address of a SIP proxy acting for them. This SIP
    proxy would be doing normal SIP processing.

    On the user data transport level, the analysis raises other issues:
    the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol
    translation (with the scalability concerns raised in Appendix A)
    may look simplest, but needs a skeptical look. Alternatives include
    routing to a transcoder, whose task is to terminate an IPv6 stream signaling and start an IPv4 stream.  Again, this requires a more detailed

    For each of the protocols, there has to be interoperability for DNS
    queries; see section 2.4 for details. media traffic.

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

               Figure 1: UE using IMS to contact a legacy phone

    Figure 1 shows a generic

    Currently the only way to make the IPv4-IPv6 interworking to work
    in the protocol level, is to have the SIP signaling edge - an ALG-like
    replacement of server reserve IP address
    and port from the IPv6 addresses with TrGW both for IPv4 addresses using limited
    subsets and IPv6. The SIP server then
    rewrites the SDP in the SIP signaling to insert the transition
    gateway in the middle of NAT-PT [RFC2766]. This the media flow between the two end-points.
    However, this approach has some drawbacks. The biggest drawback is a possible approach, but
    exploiting SIP's proxy routing to allow
    that the rewriting of SDP in the dual homed SIP edge to
    make signaling prevents securing
    the address change without SDP payload between the two end-points. Furthermore, this
    solution does not use some of newer features of SDP Ż such as
    carrying multiple alternative addresses in the SDP.

    This analysis clearly shows that a translator could be new solution for IPv4-IPv6
    interworking in SIP networks is needed. It is recommended that the
    SIP related WGs start working on a promising
    alternative without solution to overcome the scaling problems
    drawbacks of NAT-PT. the current solution.

 4.2 Two IPv6 IMS Connected via an IPv4 Network

    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 section 3.2. and similar tunneling
    solutions are applicable also in this scenario.

 5. About 3GPP UE IPv4/IPv6 Configuration

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

    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 [OMA-CP] 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

    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 [3GPP-24.008]. It is also possible to use
    [RFC3736] (or [RFC3315]) and [RFC3646] 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) [OMA-CP], 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 ([RFC3736]
    and [RFC3319]) can be used. Manual configuration or configuration
    over the air is also possible. IMS subscriber authentication and
    registration to the IMS and SIP integrity protection are not
    discussed here.

 6. Summary and Recommendations

    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 an important thing. The two first
    GPRS scenarios and both IMS scenarios are seen 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 the 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 the 3GPP operators to deploy
         basic IPv6 support in their GPRS networks as soon as possible.
         That makes it possible to lessen the transition effects in the
       - 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 [zeroconf] 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 [ISP-sa].
       - We 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 WGs in
         the IETF.

 7. Security Considerations

    Deploying IPv6 has some generic security considerations one should
    be aware of [V6SEC]; 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,

       - native upstream access or tunneling by the 3GPP network
       - 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 signalling and media translation

    The threats of configured tunneling are described in [RFC2893-bis].
    Attacks against routing protocols are described in the respective
    documents and in general in [ROUTESEC]. Threats related to protocol
    relays have been described in [RFC3142]. The security properties of
    SIP internetworking are to be specified when the mechanism is

    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
 8. References

 8.1 Normative

    [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address
    Translator (NAT) Terminology and Considerations, August 1999.

    [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm
    (SIIT), February 2000.

    [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation
    - Protocol Translation (NAT-PT), February 2000.

    [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
    June 2002.

    [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP
    Networks, August 2003.

    [RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004.

    [RFC3668] Bradner, S.: Intellectual Property Rights in IETF
    Technology, February 2004.

    [RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition
    Mechanisms for IPv6 Hosts and Routers", January September 2004, draft-ietf-
    v6ops-mech-v2-06.txt, work in progress.

    [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
    (GPRS); Service description; Stage 2 (Release 5)", December 2002.

    [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
    (Release 5)", December 2002.

    [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
    (IMS); Stage 2 (Release 5)", December 2002.

    [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP
    multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
    December 2002.

    [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control
    Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.

 8.2 Informative

    [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
    Protocol, April 1998.

    [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay
    Translator, June 2001.

    [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
    in Session Description Protocol (SDP), June 2002.

    [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP
    Standards, September 2002.

    [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for
    IPv6 (DHCPv6), July 2003.

    [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
    Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
    Servers, July 2003.

    [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6,
    December 2003.

    [RFC3736] Droms, R.: Stateless Dynamic Host Configuration Protocol
    (DHCP) Service for IPv6, April 2004.


    [RFC3901] Durand, A. and Ihren, J.: "DNS DNS IPv6 transport
    operational guidelines", March 2004, draft-ietf-dnsop-ipv6-
    transport-guidelines-02.txt, work in progress. Transport Operational
    Guidelines, September 2004.

    [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.:
    "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April
    2004, draft-ietf-ngtrans-isatap-21.txt, draft-ietf-ngtrans-isatap-22.txt, work in progress.

    [ISP-sa] Lind, M., Ksinant, V., Park, D. and Baudot, A.: "Scenarios
    and Analysis for Introducing IPv6 into ISP Networks", April June 2004,
    draft-ietf-v6ops-isp-scenarios-analysis-03.txt, work in progress.

    [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
    and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati-
    v6ops-natpt-applicability-00.txt, work in progress, the draft has

    [NATPTdep] Aoun, C. and Davies, E.: "Reasons to Deprecate NAT-PT",
    September 2004, draft-aoun-v6ops-natpt-deprecate-00.txt, work in

    [ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to
    Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats-
    06.txt, work in progress.

    [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
    Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup-
    02.txt, work in progress. progress, the draft has expired.

    [V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security
    Considerations", February 2004, draft-savola-v6ops-security-
    overview-02.txt, work in progress, the draft has expired.

    [zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J. and
    Wiljakka, J.: "Goals for Zero-Configuration Tunneling in 3GPP",
    October 2004, draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, work
    in progress.

    [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer
    3 specification; Core network protocols; Stage 3 (Release 5)", June

    [OMA-CP] OMA Client Provisioning: Provisioning Architecture
    Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile
    Alliance, 12-Nov-2002.

 9. Contributors

    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 (section 4.1).

 10. Authors and Acknowledgements

    This document is written by:

       Alain Durand, Sun Microsystems

       Karim El-Malki, Ericsson Radio Systems

       Niall Richard Murphy, Enigma Consulting Limited

       Hugh Shieh, AT&T Wireless

       Jonne Soininen, Nokia

       Hesham Soliman, Flarion

       Margaret Wasserman, ThingMagic
       Juha Wiljakka, Nokia

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

    The authors would like to thank Heikki Almay, Gabor Bajko, 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.

 11. 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
    Visiokatu 3                    Phone:  +358 7180 48372
    FIN-33720 TAMPERE, Finland     Email:

 12. Intellectual Property Statement

    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 BCP 78 and BCP 79.

    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

    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-

 13. Copyright

    The following copyright notice is copied from [RFC3667], Section
    5.4. It describes the applicable copyright for this document.

    Copyright (C) The Internet Society (2004). This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

    This document and the information contained herein are provided on

 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.  The section may be removed in future versions of the

    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 (Gi) interface, 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

    NAPT-PT introduces limitations that are expected to be magnified
    within the 3GPP architecture. Some of these limitations are listed
    below (notice that most of them are also relevant for IPv4 NAT).
    [NATPTappl] discusses the applicability of NAT-PT in more detail.
    [NATPTdep] discusses the reasons to deprecate NAT-PT.

       1. NAPT-PT is a single point of failure for all ongoing

       2. There are additional forwarding delays due to further
         processing, when compared to normal IP forwarding.

       3. There are problems with source address selection due to the
         inclusion of a DNS ALG on the same node [NATPT-DNS].

       4. NAPT-PT does not work (without application level gateways) for
         applications that embed IP addresses in their payload.

       5. NAPT-PT breaks DNSSEC.

       6. NAPT-PT does not scale very well in large networks.

    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.

      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.