[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4215

 Internet Draft                                            J. Wiljakka,
 Document: draft-ietf-v6ops-3gpp-analysis-00.txt                 Editor
 Expires: June 2003                                               Nokia
 
                                                          December 2002
 
                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 making 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 nodes in other networks, e.g. in
    the Internet, and IPv6/IPv4 transition mechanisms are needed.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 1]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
 Table of Contents
 
    1. Introduction..................................................2
       1.1 Scope of this Document....................................3
       1.2 Abbreviations.............................................3
       1.3 Terminology...............................................4
    2. Transition mechanisms.........................................4
       2.1 Dual Stack................................................5
       2.2 Tunneling.................................................5
       2.3 Protocol translators......................................5
    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
       3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network 9
       3.4 IPv6 UE connecting to an IPv4 node........................9
       3.5 IPv4 UE connecting to an IPv6 node.......................11
    4. Transition Scenarios with IMS................................12
       4.1 DNS interworking in IMS..................................12
       4.2 UE connecting to a node in an IPv4 network through IMS...12
       4.3 Two IMS islands connected over IPv4 network..............14
    5. Security Considerations......................................14
    6. Changes from draft-wiljakka-3gpp-ipv6-transition-02.txt......14
    7. References...................................................14
    8. Authors and Acknowledgements.................................16
    9. Editor's Contact Information.................................17
 
 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. Comments, input and feedback
    from the people in the IETF v6ops Working Group are appreciated.
 
    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 [3GPP-SCEN] and this
    document will further analyze them. The scenarios are divided into
    two categories: GPRS scenarios and 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
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 2]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    Two IMS scenarios are:
       - 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 informational 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 is not focused 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 / v6ops
    Working Group shall be used. This document shall not specify any
    new transition mechanisms, but if a need for a new mechanism is
    found, this will be reported to the 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)
    GGSN        Gateway GPRS Support Node (a default router for 3GPP
                 User Equipment)
    GPRS        General Packet Radio Service
    GSM         Global System for Mobile Communications
    IMS         IP Multimedia (Core Network) Subsystem, 3GPP Release 5
                 IPv6-only part of the network
    NAT         Network Address Translator
    NAPT-PT     Network Address Port Translation - Protocol Translation
    NAT-PT      Network Address Translation - Protocol Translation
    PDP         Packet Data Protocol
    PPP         Point-to-Point Protocol
    SIIT        Stateless IP/ICMP Translation Algorithm
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 3]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    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 dual
                   stack implemented. It is capable of activating
                   both IPv4 and IPv6 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
 
    This chapter briefly introduces some transition mechanisms
    specified by the IETF. Applicability of different transition
    mechanisms to 3GPP networks is discussed in chapters 3 and 4.
 
    The IPv4/IPv6 transition methods can be divided to:
 
       - dual IPv4/IPv6 stack
       - tunneling
       - protocol translators
 
 
 
 
 
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 4]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
 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
    enables support for both IPv4 and IPv6 and it is also needed to
    perform IPv6 in IPv4 tunneling. UEs with dual stack and public /
    global IP addresses can often access both IPv4 and IPv6 services
    without additional translators in the network.
 
 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.
    IPv6-in-IPv4 tunneling mechanisms are implemented by virtual
    interfaces that are configured over one or more physical IPv4
    interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets
    when the IPv6 routing table determines that the next hop toward the
    IPv6 destination address is via a tunnel interface. Receiving nodes
    decapsulate IPv6 packets from IPv4 packets that arrive on tunnel
    interfaces. Tunneling can be static or dynamic.
 
    Static (configured) tunnel interfaces are virtual IPv6 point-to-
    point links over IPv4. They require static configuration of the
    IPv6 source, IPv6 next-hop and IPv4 destination addresses for IPv6-
    in-IPv4 encapsulation. The IPv6 destination address is specified by
    the application and is used to determine the IPv6 next-hop address
    via longest-prefix-match in the IPv6 routing table. Configured
    tunnels are specified in [RFC2893].
 
    Dynamic (automatic) tunnel interfaces are virtual IPv6 point-to-
    multipoint links over IPv4. They require static configuration of
    the IPv6 source address only. Like in static tunneling, the IPv6
    destination address is specified by the application and is used to
    determine the IPv6 next-hop address via a longest-prefix-match
    lookup in the IPv6 routing table. But unlike static tunnels, the
    IPv4 destination address is derived from the IPv6 next-hop address
    in some way, for example, via direct encoding in the IPv6 next-hop
    address. This enables stateless encapsulation of IPv6-in-IPv4.
    This means that the IPv4 source address is taken from an IPv4
    interface over which the automatic tunnel is configured. Examples
    of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP],
    [DSTM] and [TEREDO].
 
 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
 
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 5]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    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, and 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 are typically needed when the two communicating nodes
    do not share the same IP version. Translation can actually happen
    at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP
    proxy) or Layer 7 (using application relays)
 
 3. GPRS Transition scenarios
 
    This section discusses the scenarios that might occur when a GPRS
    UE contacts services, or nodes outside the GPRS network, e.g. a web
    server in the Internet. Transition scenarios of the GPRS internal
    interfaces are outside of the scope of this document.
 
    The following scenarios 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. GGSN, and it 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 UE is capable of communicating with both IPv4
    and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also
    requires that the GGSN is supporting both IPv4 and IPv6. The dual
    stack UE may have both stacks or only one of them active
    simultaneously. If "IPv6 in IPv4" tunneling is needed, it is often
    beneficial to activate IPv6 PDP context and make encapsulation /
    decapsulation in the network (like described in section 3.2).
 
    However, if the GGSN does not support IPv6, and an application on
    the UE needs to communicate with an IPv6 node, the UE may activate
    an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a
    tunneling mechanism. Tunneling in the UE requires dual stack
    capability in the UE. The use of private IPv4 addresses in the UE
    depends on the support of these addresses by the tunneling
    mechanism and the deployment scenario. In some cases public IPv4
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 6]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    addresses are required, but if the tunnel endpoints are in the same
    private domain or the tunneling mechanism works through IPv4 NAT,
    private IPv4 addresses can be used. One deployment scenario example
    is using laptop computer and a UMTS UE as a modem. IPv6 packets are
    encapsulated in IPv4 packets in the laptop computer and IPv4 PDP
    context is activated. Although "IPv6 in IPv4" tunneling in the UE
    can be either automatic or configured (by the user), the first
    alternative is more probable, because it is expected that most UE
    users just want to use an application in their UE; they might not
    even care, whether the network connection is IPv4 or IPv6.
 
    When analyzing a dual stack UE behavior, an application running on
    a UE may obviously identify whether the endpoint required is an
    IPv4 or IPv6 capable node by examining the address to discover what
    address family category 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
    connection with the endpoint. Since the UE is capable of native
    communication with both protocols, one of the main concerns of an
    operator is correct address and routing management. The operator
    must maintain address spaces for both protocols. Public IPv4
    addresses may be a scarce resource for the operator. Typically it
    is not possible for a UE to have a globally unique IPv4 address
    continually allocated for its use. Use of private IPv4 addresses
    means use of NATs (Network Address Translators) 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.
 
    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. In this scenario, the UE talks to
    the DNS resolver using the IP version that is available via the
    activated PDP context. The DNS resolver in the network should be
    dual stack.
 
 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 is not capable of tunneling (it does
    not have the dual stack functionality needed for tunneling).
    Encapsulating node can be e.g. the GGSN or the edge router between
    the border of the operator's IPv6 network and the public Internet.
    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 the
    IP traffic looks like native IPv6 traffic to them. For the
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 7]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    applications, tunneling enables end-to-end IPv6 connections. Note
    that this scenario is comparable to 6bone [6BONE] network
    operation.
 
    "IPv6 in IPv4" tunnels between the IPv6 islands can be 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 initial, smaller scale IPv6 deployment, where a small number of
    IPv6 in IPv4 tunnels are required to connect the IPv6 islands over
    an IPv4 network, manually configured tunnels can be used. In a 3GPP
    network, one IPv6 island could contain the GGSN while another
    island contains the operator's IPv6 application servers or the
    dual-stack border gateway to the upstream ISP. However, manually
    configured tunnels can be an administrative burden when the number
    of islands and therefore tunnels rises. Therefore it is also
    possible to use dynamic tunneling mechanisms such as "6to4"
    [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms
    [BGP][IGP]. Routing protocol based mechanisms such as [BGP] consist
    in running BGP between the neighboring router tunnel endpoints and
    using multi-protocol BGP extensions to exchange reachability
    information of IPv6 prefixes. The routers use this information to
    create IPv6 in IPv4 tunnel interfaces and route IPv6 packets over
    the IPv4 network. It is possible to combine this with different
    types of tunnels. On the other hand, "6to4" [RFC3056] nodes use
    special IPv6 addresses with a "6to4" prefix containing the IPv4
    address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4"
    router) which performs encapsulation / decapsulation. When
    connecting two nodes with "6to4" addresses, the corresponding
    "6to4" routers use the IPv4 addresses specified in the "6to4"
    prefixes to tunnel IPv6 packets through the IPv4 network. But if
    only one of them has a "6to4" address, a "6to4" relay must be
    present to perform the missing "6to4" router functionality for the
    native-IPv6 node. In this case there are two deployment options for
    "IPv6 in IPv4" tunneling between the "6to4" router and the relay.
    The first option assumes that "6to4" routers using a given relay
    each have a default IPv6 route (configured tunnel) pointing to that
    relay. The other one consists in using an IPv6 exterior routing
    protocol; this way the set of "6to4" routers using a given relay
    obtain native IPv6 routes from it using a routing protocol such as
    BGP4+ [RFC2283]. Although this solution is more complex, it
    provides effective policy control, i.e. BGP4+ policy determines
    which "6to4" routers are able to use which relay.
 
    If we consider the "6to4" tunneling mechanism and the 3GPP
    addressing model (a unique /64 prefix allocated for each primary
    PDP context), a /48 "6to4" prefix would only be enough for
    approximately 65000 UEs. Thus, a few public IPv4 addresses would be
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 8]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    needed depending on the size of the operator. Other issues to keep
    in mind with respect to the "6to4" mechanism are that reverse DNS
    is not yet completely solved and there are some security
    considerations associated with the use of "6to4" relay routers (see
    [6to4SEC]). In a later phase of the transition period, there will
    be a need for assigning new (native IPv6) addresses to "6to4" nodes
    in order to enable native IPv6 connectivity in the future. In most
    3GPP scenarios it is preferred to use manually configured tunnels
    or EGP/IGP based tunneling mechanisms.
 
 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 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 nodes can communicate with IPv4 hosts by making use of a
    translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local
    network. For some applications, application proxies can be
    appropriate (e.g. HTTP, email relays, etc.). Such applications 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 possible
    applications, there is a need for translators that can translate
    headers independent of the type of application being used.
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                  [Page 9]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    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).
 
    When 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 [Unmaneval] section 3.2 analyzes the problem with
    address translation. However, the NAT-PT issues should be clearly
    documented in an RFC in the v6ops Working Group and a decision
    should be made, whether revisiting the NAT-PT RFC is necessary /
    what kind of update is needed.
 
       1. NA(P)T-PT is a single point of failure for all ongoing
         connections.
 
       2. Additional forwarding delays due to further processing, when
         compared to normal IP forwarding.
 
       3. 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
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 10]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    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.
 
    There are some ways to fix the problems with NA(P)T-PT, one
    suggestion is [NAT64].
 
    When thinking the DNS issues, the IPv6 UE needs to find the IPv4
    address in the DNS, thus the DNS resolver in the network must be
    dual stack. Note that DNSSEC is broken if NA(P)T-PT is used.
 
 3.5 IPv4 UE connecting to an IPv6 node
 
    The legacy IPv4 nodes are mostly 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 IPv6 Internet of the future. However, the legacy
    IPv4 UEs are not going to be updated to support the future
    applications. As these application are designed for IPv6, and to
    use the advantages of newer platforms, the legacy IPv4 nodes will
    not be able to profit from them. Thus, they will continue to
    support the legacy services.
 
    Taking the above into account, the traffic to and from the legacy
    IPv4 UE is restricted to a few applications. These applications
    already today 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.
 
    An alternative solution could be a general network address
    translation mechanisms such as NAT46 [NAT64].
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 11]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    When thinking the DNS issues, the DNS zones containing AAAA records
    for the IPv6 nodes need to be served by at least one IPv4
    accessible DNS server.
 
 4. Transition Scenarios with IMS
 
    As the IMS is exclusively IPv6, the number of possible transition
    scenarios is reduced dramatically. In the following, the possible
    transition scenarios are listed. Those scenarios are analyzed in
    sections 4.2 and 4.3.
 
       1) UE connecting to a node in an IPv4 network through IMS
       2) Two IMS islands connected over IPv4 network
 
 4.1 DNS interworking in IMS
 
    Currently, there is a consensus in the IETF that even in the IPv6
    Internet the DNS resolvers have to be dual stack.
 
    To perform DNS resolution in the IMS, the UE can be configured as a
    stub resolver pointing to a recursive DNS resolver. This
    communication can happen over IPv6. However, in the process to find
    the IPv6 address of a SIP server, the recursive DNS resolver may
    need to access data that is available only on some IPv4 DNS
    servers, see [v6namespace] and [DNSreq]. One way to achieve this is
    to make the DNS resolver be dual stack. As DNS traffic is not
    directly related to the IMS functionality, this is not in
    contradiction with the IPv6-only nature of the IMS.
 
 4.2 UE connecting to a node in an IPv4 network through IMS
 
    This scenario occurs when an IMS UE (IPv6) connects to a node in
    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.
 
    Apparently there will be a number of legacy IPv4 nodes in the
    Internet that will communicate with the IMS UEs. As the IMS is
    exclusively IPv6, translators have to be used in the communication
    between the IPv6 IMS and legacy IPv4 hosts. This section aims to
    give an overview on how that interworking can be handled.
 
    As control (or signaling) and user (or data) traffic are separated
    in SIP, and thus, the IMS, the translation of the IMS traffic 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 the other (Mb-interface).
 
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 12]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    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 4.1 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 for
    the IMS, and this address is then used within the IMS to route the
    traffic to the appropriate user traffic translator. This mapping
    can be done 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 for the IMS UE,
    and to be able 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 the allocation such as MEGACO
    [RFC3015].
 
          +-------------------------------+ +----------+
          |                      +------+ | |+--------+|
          |                      |S-CSCF|---||SIP ALG ||\
       |  |                      +------+ | |+--------+| \ --------
     +-|+ |                       /       | |    |     |  |        |
     |  | | +------+        +------+      | |    +     |   -|    |-
     |  |-|-|P-CSCF|--------|I-CSCF|      | |    |     |    | () |
     |  |   +------+        +------+      | |+--------+| /  ------
     |  |-----------------------------------|| NAT-PT ||/
     +--+ |            IPv6               | |+--------+|     IPv4
      UE  |                               | |          |
          |  IP Multimedia CN Subsystem   | |Translator|
          +-------------------------------+ +----------+
                Figure 1: UE using IMS to contact a legacy phone
 
    Figure 1 shows a possible configuration scenario where the SIP ALG
    is separate to the CSCFs. The translator can either be set up in a
    single device with both SIP translation and media translation, or
    those functionalities can be divided to two different entities with
    an interface in between.
 
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 13]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
 4.3 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.
 
    In this scenario, the end-to-end SIP connections would be based on
    IPv6. The only issue is to make connection between two IPv6-only
    IMS islands over IPv4 network. So, in practice, this scenario is
    very closely related to GPRS scenario represented in section 4.2.
 
    IPv4 / IPv6 interworking can be taken care of in the network; the
    basic options are static and dynamic tunneling. The tunnel starting
    point or endpoint should be located on the edge of the IMS domain.
    Static "IPv6 in IPv4" tunnels configured between different IMS
    domains would be a good solution. Note that this scenario is
    comparable to 6bone [6BONE] network operation.
 
 5. Security Considerations
 
         1. Problems have been identified in the case of the
            reachability of IPv4 and IPv6 nodes (use of DNS through
            NAT-PT). NAT-PT DNS ALG problems are described in [NATPT-
            DNS] and [Unmaneval].
 
         2. The 3GPP specifications do not currently define the usage
            of DNS Security. They neither disallow the usage of DNSSEC,
            nor do they mandate it.
 
         3. NAT-PT breaks DNSSEC.
 
 6. Changes from draft-wiljakka-3gpp-ipv6-transition-02.txt
 
       - Name changed from Solutions document to Analysis document
       - Tunneling text changes especially in section 3.2
       - Changes in NA(P)T-PT text in section 3.4
       - Editorial changes in some sections
 
 7. References
 
    [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.
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 14]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    [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.
 
    [RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015,
    November 2000.
 
    [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via
    IPv4 Clouds, RFC 3056, February 2001.
 
    [RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol,
    June 2002.
 
    [RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in
    Session Description Protocol (SDP), June 2002.
 
    [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP
    Standards", September 2002.
 
    [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP
    Networks", October 2002, draft-ietf-v6ops-3gpp-cases-00.txt, work
    in progress.
 
    [6to4SEC] Savola, P.: "Security Considerations for 6to4", December
    2002, draft-savola-v6ops-6to4-security-01.txt, work in progress.
 
    [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
    Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with
    BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in
    progress.
 
    [DNSreq] Durand, A., Ihren, J.: "NGtrans IPv6 DNS operational
    requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops-
    req-04.txt, work in progress, the draft has expired.
 
    [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)",
    July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress.
 
    [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica,
    C., Baudot, A., Diribarne, G.: "Connecting IPV6 islands within an
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 15]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
    IPV4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp-
    01.txt, work in progress, the draft has expired.
 
    [ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel
    Addressing Protocol (ISATAP)", October 2002, draft-ietf-ngtrans-
    isatap-05.txt, work in progress.
 
    [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand-
    ngtrans-nat64-nat46-00.txt, work in progress.
 
    [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766",
    January 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in
    progress, the draft has expired.
 
    [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through
    NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in
    progress.
 
    [Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S.,
    van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged
    Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt,
    work in progress.
 
    [v6namespace] Ihren, J.: "IPv4-to-IPv6 migration and DNS namespace
    fragmentation", March 2002, draft-ietf-dnsop-v6-name-space-
    fragmentation-01.txt, work in progress, the draft has expired.
 
    [3GPP-23.060] 3GPP TS 23.060 V5.2.0, "General Packet Radio Service
    (GPRS); Service description; Stage 2 (Release 5)", June 2002.
 
    [3GPP-23.228] 3GPP TS 23.228 V5.5.0, "IP Multimedia Subsystem
    (IMS); Stage 2 (Release 5)", June 2002.
 
    [3GPP 24.228] 3GPP TS 24.228 V5.0.0, "Signalling flows for the IP
    multimedia call control based on SIP and SDP; Stage 3 (Release 5)",
    March 2002.
 
    [3GPP 24.229] 3GPP TS 24.229 V5.0.0, "IP Multimedia Call Control
    Protocol based on SIP and SDP; Stage 3 (Release 5)", March 2002.
 
    [6BONE] http://www.6bone.net
 
 
 8. Authors and Acknowledgements
 
    This document is written by:
 
       Alain Durand, Sun Microsystems
       <Alain.Durand@sun.com>
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 16]
 

              Analysis on IPv6 Transition in 3GPP Networks     Dec 2002
 
 
 
       Karim El-Malki, Ericsson Radio Systems
       <Karim.El-Malki@era.ericsson.se>
 
       Paul Francis, Tahoe Networks
       <francis@tahoenetworks.com>
 
       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, Ericsson Radio Systems
       <hesham.soliman@era.ericsson.se>
 
       Margaret Wasserman, Wind River
       <mrw@windriver.com>
 
       Juha Wiljakka, Nokia
       <juha.wiljakka@nokia.com>
 
    The authors would like to thank Gabor Bajko, Ajay Jain, Ivan
    Laloux, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Meter
    for their valuable input.
 
 9. 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
    Sinitaival 5                   Phone:  +358 7180 47562
    FIN-33720 TAMPERE, Finland     Email:  juha.wiljakka@nokia.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wiljakka, Editor          Expires: June 2003                 [Page 17]
 

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/