Internet Draft                                       J. Wiljakka (ed.)
 Document: draft-ietf-v6ops-3gpp-analysis-05.txt draft-ietf-v6ops-3gpp-analysis-06.txt                  Nokia
 Expires: March 2004

                                                         September 2003

                Analysis on IPv6 Transition in 3GPP Networks

 Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

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

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

    The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.

 Abstract

    This document analyzes the transition to IPv6 in Third Generation
    Partnership Project (3GPP) General Packet Radio Service (GPRS)
    packet networks. 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.............................................3
       1.3 Terminology...............................................4
    2. Transition Mechanisms and DNS Guidelines......................4
       2.1 Dual Stack................................................5
       2.2 Tunneling.................................................5
       2.3 Protocol Translators......................................5
       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...........6
       3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
       ..............................................................7 7
       3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
       ..............................................................9 9
       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 Scenarios.....................................11
       4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 IMS...11
       4.2 Two IMS Islands Connected over IPv4 Network..............14 Network..............13
    5. About 3GPP UE IPv4/IPv6 Configuration........................14 Configuration........................13
    6. Security Considerations......................................15 Considerations......................................14
    7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt...........15 References...................................................15
       7.1 Normative................................................15
       7.2 Informative..............................................16
    8. Intellectual Property Statement..............................15 Contributors.................................................17
    9. Copyright....................................................16
    10. References..................................................17
       10.1 Normative...............................................17
       10.2 Informative.............................................17
    11. Authors and Acknowledgements................................19
    12. Acknowledgements.................................17
    10. Editor's Contact Information................................19 Information................................18
    11. Changes from draft-ietf-v6ops-3gpp-analysis-05.txt..........18
    12. Intellectual Property Statement.............................18
    13. Copyright...................................................19
    Appendix A - On the Use of Generic Translators in the 3GPP Networks
    .................................................................20

 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. The authors can be found in
    Authors and Acknowledgements section.

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

    The transition scenarios are documented in [RFC3574] and this
    document will further analyze them. The scenarios are divided into
    two categories: GPRS scenarios and IP Multimedia Subsystem (IMS)
    scenarios.

    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 IMS islands connected via 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 Best Current Practices document is to analyze and
    solve the possible transition scenarios in the 3GPP defined GPRS
    network where a UE connects to, or is contacted from, the Internet
    or another UE. 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 issues; both 3GPP
    Second (GSM) and Third Generation (UMTS) radio network
    architectures will be covered by these scenarios.

    The transition mechanisms specified by the IETF Ngtrans and v6ops
    Working Groups shall be used. This document shall not specify any
    new transition mechanisms, but if a need for a new mechanism is
    found, that will be reported to the IETF v6ops Working Group.

 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
    EGP         Exterior Gateway Protocol
    GGSN        Gateway GPRS Support Node (a default router for 3GPP
                 User Equipment)
    GPRS        General Packet Radio Service
    GSM         Global System for Mobile Communications
    HLR         Home Location Register
    IGP         Interior Gateway Protocol
    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
    OTA         Over The Air
    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

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

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

 2. Transition Mechanisms and DNS Guidelines

    This chapter briefly introduces some transition mechanisms
    specified by the IETF. In addition to that, DNS recommendations are
    given. The applicability of different transition mechanisms to 3GPP
    networks is discussed in chapters 3 and 4. DNS
    recommendations related to IPv4/IPv6 transition are briefly
    summarized in section 2.4.

    The IPv4/IPv6 transition methods can be divided to:

       - dual IPv4/IPv6 stack
       - tunneling
       - protocol translators

 2.1 Dual Stack

    The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider
    the 3GPP GPRS core network, dual stack implementation in the GGSN
    Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6
    PDP contexts. UEs with dual stack and public (global) IP addresses
    can often typically access both IPv4 and IPv6 services without additional
    translators in the network. However, it is good to remember that
    public IPv4 addresses are a scarce resource and in many cases IPv4
    NATs are deployed. 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].
    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 SIIT [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
    actually happen at Layer 3 (using NAT-like techniques), Layer 4
    (using a TCP/UDP proxy) or Layer 7 (using application relays).

 2.4 DNS Guidelines for IPv4/IPv6 Transition

    [DNStrans] provides guidelines to operate DNS in a mixed world of
    IPv4 and IPv6 transport. The recommended recommendations (including the
    keywords) are copied verbatim from [DNStrans]:

    "In order to preserve name space continuity, the following
    administrative policies are the following: RECOMMENDED:
          - every recursive DNS server SHOULD be either IPv4-only or
            dual stack,
          - every single DNS zone SHOULD be served by at least one IPv4
            reachable DNS server.

    This rules out IPv6-only DNS servers server performing full recursion and
    DNS zones served only by IPv6-only DNS servers.  This approach
    could be revisited if/when translation techniques between IPv4 and
    IPv6 were to be widely deployed.

    In order to enforce the second point, the zone validation process
    SHOULD ensure that there is at least one IPv4 address record
    available for the name servers of any child delegations within the
    zone."

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

    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. If IPv6 PDP contexts are
    available and "IPv6 in IPv4" IPv6-in-IPv4 tunneling is needed, it is recommended
    to activate an IPv6 PDP context and perform tunneling in the
    network. This case is described in more detail in section 3.2.

    However, the UE may attach to a 3GPP network, in which the Serving
    GPRS Support Node (SGSN), the GGSN GGSN, and the Home Location Register
    (HLR) support IPv4 PDP contexts, but may do not support IPv6 PDP
    contexts. 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. This
    might happen in very early phases of IPv6 deployment. To generally
    solve this problem (IPv6 not available in the 3GPP network), this
    document strongly recommends the 3GPP operators to deploy basic
    IPv6 support in their GPRS networks, which can in most cases be
    handled by making software upgrades in the network elements.

    As a general guideline, IPv6 communication (native or tunneled from
    the UE) is preferred to IPv4
    communication going through IPv4 NATs to the same dual stack peer
    node.

    When analyzing a dual stack UE behavior, an application running on
    a UE can identify whether the endpoint required is an IPv4 or IPv6
    capable node by examining the address to discover what address
    family it falls into. Alternatively, if a user supplies a name to
    be resolved, the DNS may contain records sufficient to identify
    which protocol should be used to initiate the connection with the
    endpoint. Since the UE is capable of native communication with both
    protocols, one of the main concerns of an operator is the correct
    address space and routing management. The operator must maintain
    address spaces for both protocols. Public IPv4 addresses are often
    a scarce resource for the operator and typically it is not possible
    for a UE to have a globally unique IPv4 address continuously
    allocated for its use. Use of private IPv4 addresses means use of
    NATs when communicating with a peer node outside the operator's
    network. In large networks, NAT systems can become very complex,
    expensive and difficult to maintain.

    For DNS recommendations, we refer to section 2.4.

 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" 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 is not capable of tunneling (it 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, tunneling
    enables end-to-end IPv6 connectivity. Note that this scenario is
    comparable to 6bone [6BONE] network operation.

    "IPv6 in IPv4"

    IPv6-in-IPv4 tunnels between IPv6 islands can be either static or
    dynamic. The selection of the type of tunneling mechanism is up to
    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 transition scenarios are documented in [ISP-scen].

 3.2.1 Tunneling inside the 3GPP Operator's Network

    Many GPRS operators already have IPv4 backbone networks deployed
    and they are gradually migrating them while introducing IPv6
    islands. IPv6 backbones can be considered quite rare in the first
    phases of the transition. If the 3GPP operator already has IPv6
    widely deployed in its network, this subsection is not so relevant.

    In initial IPv6 deployment, where a small number of IPv6 in IPv4 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 which are typically necessary
    to manage large networks anyway.

    Even a dynamic tunneling mechanism or an IGP/EGP routing protocol
    based tunneling mechanism can be considered if other methods are
    not suitable.

    Connection redundancy should also be noted as an important
    requirement in 3GPP networks. Static tunnels on their own don't
    provide a routing recovery solution for all scenarios where an IPv6
    route goes down. However, they may provide an adequate solution
    depending on the design of the network and in presence of other
    router redundancy mechanisms. On the other hand, IGP/EGP routing protocol
    based mechanisms can provide redundancy.

 3.2.2 Tunneling outside the 3GPP Operator's Network

    This subsection includes the case when the peer node is outside the
    operator's network. In that case the "IPv6 in IPv4" IPv6-in-IPv4 tunnel starting
    point can be in the operator's network - encapsulating node can be
    e.g. the GGSN or the edge router.

    The case is pretty straightforward if the upstream ISP provides
    native IPv6 connectivity to the Internet. If there is no native
    IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" IPv6-in-IPv4
    tunnel should be configured from e.g. the GGSN to the dual stack
    border gateway in order to access the upstream ISP.

    If the ISP only provides IPv4 connectivity, then the IPv6 traffic
    initiated from the 3GPP network should be transported tunneled in
    IPv4 to the ISP.

    Usage of configured "IPv6 in IPv4" IPv6-in-IPv4 tunneling is recommended. As the
    number of the tunnels outside of the 3GPP network is limited, no
    more than a couple of tunnels should be needed.

    ISP transition scenarios are described in [ISP-scen].

 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. An IPv6-capable GGSN is expected to support both IPv6 and
    IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4
    link (PDP context) to connect to the GGSN without the need to
    communicate 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 IPv4-in-IPv6 will be required from the GGSN to
    external IPv4 networks either. In the longer run, 3GPP operators
    may need to phase out IPv4 UEs and the 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

    IPv6(-only) nodes can communicate

    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 by making
    use of a translator (e.g. SIIT [RFC2765], NAT-PT [RFC2766]) within
    the local network. For many applications, application proxies can
    be appropriate (e.g. HTTP, email relays, etc.). Such applications will not no
    longer be transparent to the UE. Hence, necessary. 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 possible 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. Within the 3GPP architecture, application proxies can be
    placed on the GGSN external interface (Gi), or inside the service
    network.

    However, since it is difficult to anticipate all the possible
    applications, there can be a need for translators that can
    translate headers independent of the type of application being
    used. This section describes a solution based on the use of
    translators, but does not strongly recommend using translators as a
    general solution.

    The authors note that NAT-PT applicability statement work is being
    done in the v6ops wg and that document will
    be used as a reference wg. The problems related to NAT-PT usage in this document.

    Due 3GPP
    networks are documented in appendix A.

 3.5 IPv4 UE Connecting to the significant lack of an IPv6 Node

    The legacy IPv4 addresses nodes are mostly nodes that support the
    applications that are popular today in some domains, port
    multiplexing is likely to be a necessary feature for translators
    (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the
    GGSN external (Gi) interface, typically separate from the GGSN.
    NA(P)T-PT can be installed, for example, on the edge of the
    operator's network and the public Internet. NA(P)T-PT will
    intercept DNS requests IPv4 Internet: mostly e-
    mail and other web-browsing. These applications that include IP
    addresses will, of course, be
    supported in their payloads, translate the IP header (and payload
    for some applications if necessary) and forward packets through its future IPv6 Internet. However, the legacy IPv4 interface.

    NA(P)T-PT introduces limitations that UEs
    are expected not going to be magnified
    within updated to support the 3GPP architecture. Some of future applications. As
    these limitations are listed
    below (notice that some of them applications are also relevant designed for IPv4 NAT). We
    note here that [v4v6trans] analyzes IPv6, and to use the issues when translating
    between advantages
    of newer platforms, the legacy IPv4 and IPv6. NAT-PT applicability statement document
    (currently being written in v6ops wg) nodes will also not be used as a
    reference in this document.

       1. NA(P)T-PT is a single point of failure for all ongoing
         connections.

       2. There are additional forwarding delays due able to further
         processing, when compared
    profit from them. Thus, they will continue to normal IP forwarding.

       3. There are problems with source address selection due support the legacy
    services.

    Taking the above into account, the traffic to and from the
         inclusion of legacy
    IPv4 UE is restricted to a DNS ALG few applications. These applications
    already mostly rely on the same node [NATPT-DNS].

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

       5. NA(P)T-PT breaks DNSSEC.

       6. NA(P)T-PT does not scale very well in large networks.

    3GPP proxies or local servers to communicate
    between private address space networks are expected and the Internet. The same
    methods and technology can be used for IPv4 to handle a very large IPv6 transition.

    For DNS recommendations, we refer to section 2.4.

 4. IMS Transition Scenarios

    As the IMS is exclusively IPv6, the number of
    subscribers on a single GGSN (default router). Each GGSN possible transition
    scenarios is
    expected reduced dramatically. The possible IMS scenarios are
    listed below and analyzed in sections 4.1 and 4.2.

       1) UE connecting 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 node in an IPv4 network reliability.
    In addition, IPv6 users are expected through IMS
       2) Two IMS islands connected over IPv4 network

    For DNS recommendations, we refer to use delay-sensitive
    applications provided by IMS. Hence, there section 2.4. As DNS traffic is a need
    not directly related to minimize
    forwarding delays within the IP backbone. Furthermore, due to IMS functionality, the
    unprecedented number recommendations
    are not in contradiction with the IPv6-only nature of connections handled by the default routers
    (GGSN) in 3GPP networks, a network design that forces traffic IMS.

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

    This scenario occurs when an IMS UE (IPv6) connects to a single node at in
    the edge of IPv4 Internet through the network (typical NA(P)T-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 NA(P)T-PT, the following
    actions can be recommended:

         1. Separate the DNS ALG from IMS, or vice versa. This happens when
    the NA(P)T-PT other node (in the "IPv6
            to IPv4" case).

         2. Ensure (if possible) that NA(P)T-PT does not become is a
            single point part of failure.

         3. Allow for load sharing between different translators. That
            is, it should be possible for different connections to go
            through a different translators. Note that load sharing alone
            does not prevent NA(P)T-PT from becoming system than 3GPP, e.g. a single point of
            failure.

 3.5
    fixed PC, with only IPv4 UE Connecting to an IPv6 Node capabilities.

    The first priority is to upgrade the legacy IPv4 nodes are mostly nodes to dual-
    stack, eliminating this particular problem in that support specific
    deployment.

    Still, it is difficult to estimate how many non-upgradeable legacy
    IPv4 nodes need to communicate with the
    applications IMS UEs. It is assumed that are popular today in
    the IPv4 Internet: mostly e-
    mail and web-browsing. These applications will, of course, be
    supported solution described here is used for limited cases, in the IPv6 Internet which
    communications with a small number of the future. However, the legacy IPv4 UEs SIP equipment are not going to be updated to support the future
    applications.
    needed.

    As these applications are designed for IPv6, and the IMS is exclusively IPv6 [3GPP 23.221], translators have to
    use
    be used in the advantages of newer platforms, communication between the IPv6 IMS and legacy IPv4 nodes will
    hosts, i.e. making a dual stack based solution is not be able feasible.
    This section aims to profit from them. Thus, they will continue to
    support the legacy services.

    Taking the above into account, give a brief overview on how that interworking
    can be handled.

    This section presents higher level details of a solution based on
    the traffic to use of a translator and from the legacy
    IPv4 UE is restricted to SIP ALG. [3GPPtr] provides additional
    information and presents a few applications. These applications
    already mostly rely bit different solution proposal based on proxies or local servers to communicate
    between private address space networks
    SIP Edge Proxy and the Internet. IP Address/Port Mapper. The same
    methods and technology can be used for IPv4 to IPv6 transition.

    For DNS recommendations, we refer authors recommend to section 2.4.

 4. IMS Transition Scenarios
    solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF
    SIP wg(s).

    As control (or signaling) and user (or data) traffic are separated
    in SIP, and thus, the IMS is exclusively IPv6, IMS, the number translation of possible transition
    scenarios is reduced dramatically. The possible the IMS scenarios are
    listed below traffic has
    to be done at two levels:
              1)Session Initiation Protocol (SIP) [RFC3261], and analyzed in sections 4.1
                 Session Description Protocol (SDP) [RFC2327] [RFC3266]
                 (Mm-interface)
              2)the user data traffic (Mb-interface)

    SIP and 4.2.

       1) UE connecting SDP transition has to a node be made in an IPv4 network through IMS
       2) Two IMS islands connected over IPv4 network

    For DNS recommendations, we refer to section 2.4. As DNS traffic is
    not directly related SIP/SDP Application
    Level Gateway. The ALG has to change the IMS functionality, the recommendations
    are not IP addresses transported
    in contradiction with the IPv6-only nature of SIP messages and the IMS.

 4.1 UE Connecting SDP payload of those messages to a Node in an IPv4 Network through IMS

    This scenario occurs when an IMS UE (IPv6) connects the
    appropriate version. In addition, there has to a node in be interoperability
    for DNS queries; see section 2.4 for details.

    On the IPv4 Internet through user data transport level, the IMS, or vice versa. This happens when translation is IPv4-IPv6
    protocol translation, where the other node user data traffic transported is a part of a different system than 3GPP, e.g. a
    fixed PC, with only IPv4 capabilities.

    There will probably be few
    translated from IPv6 to IPv4, and vice versa.

    The legacy IPv4 nodes in host's address can be mapped to an IPv6 address for
    the Internet that
    will communicate with IMS, and this address is then used within the IMS UEs. It is assumed that to route the solution
    described here is used
    traffic to the appropriate user traffic translator. This mapping
    can be done by the SIP/SDP ALG for limited cases, the SIP traffic. The user
    traffic translator would do the similar mapping for the user
    traffic. However, in which communications
    with a small number of legacy order to have an IPv4 SIP equipment are needed. As address for the IMS is exclusively IPv6 [3GPP 23.221], translators have UE,
    and to be used
    in able to route the communication between user traffic within the IPv6 IMS and legacy IPv4 hosts,
    i.e. making a dual stack based solution is not feasible. This
    section aims
    network to the correct translator, there has to give a brief overview on how that interworking can be handled.

    This section presents higher level details of a solution based on an IPv4 address
    allocated for the use duration of a translator and SIP ALG. [3GPPtr] provides additional
    information and presents a bit different solution proposal based on
    SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to
    solve the general SIP/SDP IPv4/IPv6 transition problem in session from the IETF
    SIP wg(s).

    As control (or signaling) and user (or data) traffic are separated
    in SIP, and thus, the IMS, the translation
    translator. The allocation of this address from the IMS user traffic
    translator has to be done on two levels - Session Initiation Protocol (SIP)
    [RFC3261], and Session Description Protocol (SDP) [RFC2327]
    [RFC3266] on the one hand (Mm-interface), and on the actual user
    data traffic level on by the other (Mb-interface).

    SIP and SDP transition has to be made in an SIP/SDP Application
    Level Gateway. The ALG has to change the IP addresses transported in the SIP messages and the SDP payload of those messages to the
    appropriate version. In addition, there has to be interoperability
    for DNS queries; see section 2.4 for details.

    On the user data transport level, the translation is IPv4-IPv6
    protocol translation, where the user data traffic transported is
    translated from IPv6 to IPv4, and vice versa.

    The legacy IPv4 host's address can be mapped to an IPv6 address order for the IMS, and this address is then used within the IMS to route the
    traffic
    SIP/SDP ALG to know the appropriate user traffic translator. correct IPv4 address. This mapping can be done achieved
    by the SIP/SDP ALG for the SIP traffic. The user
    traffic translator would do the similar mapping for the user
    traffic. However, in order to have an IPv4 address using a protocol for the IMS UE,
    and to be able ALG to route the user traffic within the legacy IPv4
    network to the correct translator, there has to be an IPv4 address
    allocated for the duration of the session from the user traffic
    translator. The allocation of this address from the user traffic
    translator has to be done by the SIP/SDP ALG in order for the
    SIP/SDP ALG to know the correct IPv4 address. This can be achieved
    by using a protocol for the ALG to do do the allocation.

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

           Figure 1: UE using IMS to contact a legacy phone

    Figure 1 shows a possible configuration scenario where the SIP ALG
    is separated from the CSCFs. The translator can either be set up in
    a single device with both SIP translation and media translation, or
    those functionalities can be divided to two different entities with
    an interface in between. We call the combined network element on
    the edge of the IPv6-only IMS an "Interworking Unit" in this
    document. One alternative is to use a suitable subset A SIP-specific translation mechanism, which could e.g.
    re-use limited subsets of NAT-PT
    [RFC2766] in this network element [RFC2766], needs to take care of the media (user
    data) IPv4/IPv6 translation. be specified.
    The problems related to NAT-PT are
    documented discussed in section 3.4. appendix A.

 4.2 Two IMS Islands Connected over 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 native IPv6 connected. 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.

    To be able to access IPv6 or IPv4 based services, settings need to
    be done in the UE. The GGSN Access Point has to be defined when
    using, for example, the web browsing application. One possibility
    is to use Over The Air (OTA) over the air configuration to configure the GPRS
    settings. The user can 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, the
    user 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). Same kind of 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 [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS
    server addresses. The authors note that the general IPv6 DNS
    discovery problem is being solved by the IETF dnsop Working Group.
    The DNS server addresses can also be received using OTA
    configuration, over the air (using
    SMS), or typed in manually in the UE.

    When accessing IMS services, the UE needs to know the P-CSCF IPv6
    address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism
    ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA Manual
    configuration or manual configuration can over the air is also be possible. IMS
    subscriber authentication and registration to the IMS and SIP
    integrity protection are not discussed here.

 6. Security Considerations

    Editor's note: This section may need updating.

         1. NAT-PT DNS ALG problems

    There are described in [NATPT-DNS] some generic security considerations when moving to dual-
    stack IPv4/IPv6 deployment which are not analyzed at length here.
    Two examples of these are ensuring that the access controls and
            [v4v6trans].

         2. The 3GPP specifications do
    firewalls have similar (or known) security properties with both
    IPv4 and IPv6, and that enabling IPv6 does not currently define jeopardize the usage
    access to the IPv4 services (e.g., in the form of misbehavior
    towards DNS Security. They neither disallow AAAA record lookups or operationally worse quality IP
    transit services).

    This memo recommends the usage use of DNSSEC,
            nor do they mandate it.

         3. NAT-PT breaks DNSSEC.

 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt

       - (Major part of) The issues handled:
         http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-
         analysis/index
       - The only DNS reference now is draft-ietf-dnsop-ipv6-transport-
         guidelines-00.txt, a relatively small number of
    techniques, which all DNS discussion is now in section 2.4 of them have their own security
    considerations, including:

       - Section 5 "About native upstream access or tunneling by the 3GPP UE IPv4/IPv6 Configuration" added network
          operator,
       - draft-elmalki-v6ops-3gpp-translator put as an informational
         reference in section 4.1; a recommendation has been added use of routing protocols to
         solve the general SIP/SDP transition problem in SIP wg(s)
       - NAT64 reference removed
       - 6to4 references removed ensure redundancy,
       - IGP use of locally-deployed specific-purpose protocol relays and BGP references removed (expired drafts)
       - Some abbreviations added
       - Intellectual Property Statement added
          application proxies to reach IPv4(-only) nodes from IPv6-only
          UEs, or
       - Editorial changes a specific mechanism for SIP signalling and media translation

    These (except for the last one, naturally) have relatively well-
    known security considerations, which are also discussed in many sections

 8. Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights
    specific documents.  However, in particular one should note that might be claimed to
    pertain to the implementation or use a
    proper configuration of locally-deployed relays and proxies is very
    important, so that the technology described in
    this document or the extent to which any license under such rights
    might or might outsiders will not be available; neither does it represent that it
    has made any effort have access to identify any such rights. Information on the
    IETF's procedures with respect them, to rights in standards-track and
    standards-related documentation can
    be found in BCP-11. Copies of
    claims of rights made available used for publication and any assurances
    of licenses to be made available, abuse, laundering attacks, or circumventing access
    controls.

    In particular, this memo does not recommend the result of an attempt made
    to obtain following
    techniques which each have a general license number of security issues, not further
    analyzed here:

       - NAT-PT or permission for other translator as a generic-purpose transition
          mechanism,
       - the use of such
    proprietary rights by implementers or users of this specification
    can be obtained from IPv6 transition mechanisms (except dual stack) at
          the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

 9. Copyright

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

    Copyright (C) The Internet Society September 10, 2003. All Rights
    Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain
    it or assist in its implementation may be prepared, copied,
    published and distributed, in whole or in part, without restriction
    of any kind, provided that the above copyright notice and this
    paragraph are included on all such copies and derivative works.
    However, this document itself may not be modified in any way, such
    as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the
    purpose of developing Internet standards in which case the
    procedures for copyrights defined in the Internet Standards process
    must be followed, or as required to translate it into languages
    other than English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assignees.

    This document and the information contained herein is provided on
    an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 10. References

 10.1 Normative

    [RFC2026] Bradner, S.: UEs.

 7. References

 7.1 Normative

    [RFC2026] Bradner, S.: The Internet Standards Process -- Revision
    3, RFC 2026, October 1996.

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

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

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

    [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for
    IPv6 Hosts and Routers, RFC 2893, August 2000.

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

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

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

 10.2

 7.2 Informative

    [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.:
    Multiprotocol Extensions for BGP-4, RFC 2283, February 1998.

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

    [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay
    Translator, RFC 3142, 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.

    [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translators in 3GPP
    Networks", June 2003, draft-elmalki-v6ops-3gpp-translator-00.txt,
    work in progress.

    [DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6",
    August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in
    progress.

    [DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6
    Service", April 2003, draft-ietf-dhc-dhcpv6-stateless-00.txt, work
    in progress.

    [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport
    operational guidelines", June 2003, draft-ietf-dnsop-ipv6-
    transport-guidelines-00.txt, work in progress.

    [ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into
    ISP Networks", June 2003, draft-lind-v6ops-isp-scenarios-00.txt,
    work in progress.

    [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766",
    January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work
    in progress, the draft has expired.

    [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.:
    "Issues when translating between IPv4 and IPv6", January 2003,
    draft-vanderpol-v6ops-translation-issues-00.txt, work in progress,
    the draft has expired.

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

    [6BONE] http://www.6bone.net
 11.

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

 9. Authors and Acknowledgements

    This document is written by:

       Alain Durand, Sun Microsystems
       <Alain.Durand@sun.com>
       <alain.durand@sun.com>

       Karim El-Malki, Ericsson Radio Systems
       <Karim.El-Malki@era.ericsson.se>

       Niall Richard Murphy, Enigma Consulting Limited
       <niallm@enigma.ie>

       Hugh Shieh, AT&T Wireless
       <hugh.shieh@attws.com>

       Jonne Soininen, Nokia
       <jonne.soininen@nokia.com>
       Hesham Soliman, Flarion
       <h.soliman@flarion.com>

       Margaret Wasserman, Wind River
       <mrw@windriver.com>

       Juha Wiljakka, Nokia
       <juha.wiljakka@nokia.com>

    The authors would like to thank Heikki Almay, Gabor Bajko, Ajay
    Jain, Jarkko Jouppi, Ivan Laloux, Janne Rinne, Pekka Savola, Pedro Serna, Fred
    Templin, Anand Thakur and Rod Van Meter for their valuable input.

 12.

 10. 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                    Phone:  +358 7180 48372
    FIN-33720 TAMPERE, Finland     Email:  juha.wiljakka@nokia.com

 11. Changes from draft-ietf-v6ops-3gpp-analysis-05.txt

       - Handled issues from:
         http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-
         analysis/index
       - Security considerations section updated
       - Editorial / textual changes in many sections
       - Appendix A created

 12. Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property 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; neither does it represent that it
    has made any effort to identify any such rights. Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11. Copies of
    claims of rights made available for publication 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 Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard. Please address the information to the IETF Executive
    Director.

 13. Copyright

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

    Copyright (C) The Internet Society September 26, 2003. All Rights
    Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain
    it or assist in its implementation may be prepared, copied,
    published and distributed, in whole or in part, without restriction
    of any kind, provided that the above copyright notice and this
    paragraph are included on all such copies and derivative works.
    However, this document itself may not be modified in any way, such
    as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the
    purpose of developing Internet standards in which case the
    procedures for copyrights defined in the Internet Standards process
    must be followed, or as required to translate it into languages
    other than English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assignees.

    This document and the information contained herein is provided on
    an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

    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 NA(P)T-PT is used, it needs to be placed on the
    GGSN external (Gi) interface, typically separate from the GGSN.
    NA(P)T-PT can be installed, for example, on the edge of the
    operator's network and the public Internet. NA(P)T-PT will
    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.

    NA(P)T-PT introduces limitations that are expected to be magnified
    within the 3GPP architecture. Some of these limitations are listed
    below (notice that some of them are also relevant for IPv4 NAT). We
    note here that [v4v6trans] analyzes the issues when translating
    between IPv4 and IPv6. NAT-PT applicability statement document
    (currently being written in v6ops wg) will also be used as a
    reference in this document.

       1. NA(P)T-PT is a single point of failure for all ongoing
         connections.

       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. NA(P)T-PT does not work (without application level gateways)
         for applications that embed  IP addresses in their payload.

       5. NA(P)T-PT breaks DNSSEC.

       6. NA(P)T-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 NA(P)T-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 NA(P)T-PT, the following
    actions can be recommended:

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

      2. Ensure (if possible) that NA(P)T-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 NA(P)T-PT from becoming a single point of failure.