Internet Engineering Task Force                             C. Zhou, Ed.
Internet-Draft                                                 T. Taylor
Intended status: Informational                       Huawei Technologies
Expires: April 22, 2011                                 October 19, 2010


          IPv6 Transition Use Case For a Large Mobile Network
                  draft-zhou-v6ops-mobile-use-case-00

Abstract

   This document describes an use case for migrating from IPv4 to IPv6
   in a very large mobile network.  Its purpose is to enhance general
   understanding of the challenges associated with the migration of such
   a network to IPv6 operation.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 22, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Zhou & Taylor            Expires April 22, 2011                 [Page 1]


Internet-Draft               Mobile Use Case                October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Overview of the Mobile Network Architecture  . . . . . . . . .  3
   3.  Approaches To IPv4 / IPv6 Coexistence  . . . . . . . . . . . .  6
     3.1.  IPv6 Coexistence Strategy 1: Dual-Stack Connectivity
           With Limited Public IPv4 Address Pools . . . . . . . . . .  7
     3.2.  IPv6Coexistence Strategy 2: Dual Stack Connectivity
           With Limited Private IPv4 Address Pools  . . . . . . . . .  7
     3.3.  IPv6 Coexistence Strategy 3: UEs With IPv6-only
           Transport and Applications Using IPv6  . . . . . . . . . .  8
     3.4.  IPv6 Coexistence Strategy 4: IPv4 Applications Running
           On a  Dual-Stack Host With an Assigned IPv6 Prefix and
           a Shared IPv4 Address  . . . . . . . . . . . . . . . . . .  8
   4.  Consideration of IPv4 / IPv6 Coexistence Solutions . . . . . .  8
     4.1.  Gateway-Initiated Dual-Stack Lite  . . . . . . . . . . . .  8
     4.2.  Protocol Translation . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





























Zhou & Taylor            Expires April 22, 2011                 [Page 2]


Internet-Draft               Mobile Use Case                October 2010


1.  Introduction

   Consider a major mobile network operator, with hundreds of millions
   of subscribers, currently growing at a rate in the order of 1% per
   month.  To assure continued revenue growth as market penetration
   approaches its limit, the operator has been deploying 3GPP
   technology.  Currently about 1.5 percent of the operator's
   subscribers use the third and fourth generation technology discussed
   in this document.

   The operator is looking to mobile data services for future revenue
   gains.  Mobile data services currently include mobile payments, music
   downloads, mobile reading (book downloads), streaming and broadcast
   video, and internet search services in partnership with content
   providers such as news agencies.  By their nature, these services
   require communication between the mobile subscriber and a third party
   application or content provider.  Given the importance of these third
   parties to the operator's business, the operator's IPv6 transition
   plans have to ensure continuity of service to the third party servers
   regardless of the IP version they run.

   At the subscriber end, mobile handsets are typically replaced within
   two to three years after purchase, apparently putting an upper limit
   on how long it will take to make IPv6 the preferred protocol for the
   majority of subscribers.  However, in some markets the most popular
   use of mobile data access is to provide access for personal computers
   attached to the mobile terminal.  This means the transition period at
   the subscriber end depends to an important extent on the rate at
   which personal computer operating systems and applications evolve to
   support IPv6.

   As a further complication for the migration to IPv6, the operator is
   facing a major upgrade of its access networks from the older 3GPP
   technology to LTE ("Long Term Evolution").  LTE flattens out the
   access network by bringing the IP edge closer to the user equipment.
   LTE will provide higher data rates, opening up the possibilities for
   improved services and increased revenue from them.

1.1.  Requirements Language

   This document is descriptive, and as such, contains no requirements
   language.


2.  Overview of the Mobile Network Architecture

   3GPP has specified layer 2 access for IPv6 in the legacy 3GPP
   architecture and in the LTE ("Long Term Evolution") version.  The



Zhou & Taylor            Expires April 22, 2011                 [Page 3]


Internet-Draft               Mobile Use Case                October 2010


   third generation architecture is shown in Figure 1.  Only the user
   data paths are shown.  The IP edge (of the core IP network) is
   located at the GGSN (Gateway GPRS Support Node, where GPRS itself
   stands for General Packet Radio Service).  Within this system, IPv6
   support requires separate bearers (i.e., links) for IPv4 and IPv6
   respectively, extending from the User Equipment through the radio
   network and the SGSN (Serving GPRS Support Node, at which the User
   Equipment is registered) and, finally, to the GGSN.

      The bearers are actually propagated from the SGSN to the GGSN
      using GTP-U, a 3GPP-specified tunneling protocol running over IP.
      The IP addresses assigned to the SGSN and GGSN for this purpose
      are not visible to the mobile station.  The SGSN locates the GGSN
      using a DNS service that is also not visible to the User
      Equipment.


                                  +-----+
                                  |     |
                                  | HSS |
                                  |     |
                                  +-----+
            IPv4 link                      +--------------+
           /                               |              |
   +----+ /  +-----+    +------+       +------+           |
   |    |....|     |....|      |.......|      |   Core    |
   | UE | L2 | RAN | L2 | SGSN |   \   | GGSN |    IP     |
   |    |....|     |....|      |....\..|      |  Network  |
   +----+ \  +-----+    +------+ \   \ +------+           |
           \                      \   \    |              |
            IPv6 link              \   \   +--------------+
                                  Links tunnelled
                                  over GTP-U over IP

   UE    = User Equipment
   RAN   = Radio access network
   SGSN  = Serving GPRS Support Node
   GGSN  = Gateway GPRS Support Node
   HSS   = Home Subscriber Server (holds subscriber profile)
   GTP   = GPRS Tunneling Protocol

           Figure 1: Third Generation GPRS Mobile Access Network

   The use of IPv4 and/or IPv6 is controlled by the combination of
   subscriber profile and core operator preference.  Address allocation
   to the User Equipment (UE) differs between IPv4 and IPv6.  For IPv4,
   addresses can be assigned in a number of ways.  From the point of
   view of the UE, the choice is between allocation during bearer



Zhou & Taylor            Expires April 22, 2011                 [Page 4]


Internet-Draft               Mobile Use Case                October 2010


   activation vs. DHCPv4 exchanges with the core network following
   bearer activation.  From the point of view of the network, the
   choices are between static and dynamic address allocation.  For
   dynamic allocation, the choice is between:

   o  allocation by the access network (with the GGSN responsible for
      managing the address pool);

   o  allocation by the core network (with the GGSN acting as DHCPv4 or
      RADIUS client and passing the configuration data on to the UE
      during bearer setup; or

   o  via DHCPv4 to the UE after bearer setup, as already mentioned.

   IPv6 prefix allocation is done by stateless address autoconfiguration
   (SLAAC), with the GGSN responsible for sending Router Announcements
   in response to the UE's Router Solicitation.  For further details see
   Sections 9.2.1 and 9.2.1.1 of [3GPP_TR_23_060].

   The fourth generation mobile access architecture is described in
   [3GPP_TR_23_401] and [3GPP_TR_23_402] and shown in Figure 2.  The
   SGSN has been split into a control part, the Mobile Management Entity
   (MME), and a forwarding part, the Serving Gateway (SGW).  The GGSN
   has been replaced by the Packet Data Network Gateway (PDN Gateway, or
   PGW).

   The user data path to the core network changes in several ways with
   LTE.  First, it becomes possible to carry both IPv4 and IPv6 over the
   same bearer.  Thus the figure shows only a single link from the User
   Equipment to the PDN Gateway.  The second change is that the layer 2
   protocol used in the third generation architecture to carry the link
   between the edge of the Radio Access Network and the SGSN is replaced
   by a tunnel over IP, the same protocol stack (User packets/GTP-
   U/IP/...) used between the SGSN and the GGSN.  Finally, the operator
   has the option to use PMIPv6 [RFC5213] instead of GTP-U tunneling
   between the SGW and the PDN Gateway.  The SGW acts in the role of
   Mobility Access Gateway (MAG), while the PDN Gateway acts in the role
   of Local Mobility Anchor (LMA).  PMIP is used only when the core IP
   network to which the UE is connected has the same operator as the
   access network.











Zhou & Taylor            Expires April 22, 2011                 [Page 5]


Internet-Draft               Mobile Use Case                October 2010


                                      +--------+
                                      |  HSS   |
                                      +--------+     +---------+
                                                     |  PCRF   |
                           +---------+               +---------+
                           |  MME    |
                           +---------+              +------------+
                                                    |            |
           +----+     +------     +-----+     +-----+    Core    |
           | UE |.....| RAN |.....| SGW |.....| PGW |     IP     |
           +----+     +-----+     +-----+     +-----+   Network  |
                                                    |            |
                                                    +------------+
         UE   = User Equipment
         RAN  = Radio Access Network
         SGW  = Serving Gateway
         PGW  = Packet Data Network (PDN) Gateway
         MME  = Mobility Management Entity
         PCRF = Policy and Charging Rules Function
         HSS  = Home Subscriber Server

         Figure 2: Long Term Evolution (LTE) Mobile Access Network

   Essentially the same options are available in LTE for address
   configuration of the User Equipment, except that the PDN Gateway
   replaces the GGSN as the entity responsible for obtaining and
   propagating that information.

   To ease the upgrade from third generation access to LTE, it is
   possible to mix equipment types in the same access network.  Traffic
   from the SGSN is forwarded to the SGW, which relays it to the PDN.
   If the Radio Access Network control is upgraded to use GTP tunneling,
   it is possible to tunnel traffic directly between the Radio Access
   Network and the SGW.  The SGSN retains a control function.  The final
   step is to replace the SGSN by an MME to carry out the control
   function.

   To achieve service continuity during handover, legacy mobile devices
   support MIPv4 [RFC3344].  The GGSN provides the Foreign Agent
   functionality.  More recent devices support DSMIPv6 [RFC5555].
   DSMIPv6 assumes that both the UE and the Home Agent are dual-stack.


3.  Approaches To IPv4 / IPv6 Coexistence

   This section discusses the coexistence of user-plane IPv4 and IPv6
   traffic.  The operator is also faced with the upgrade of the network
   equipment to use IPv6 for control signalling and for the IP wrapper



Zhou & Taylor            Expires April 22, 2011                 [Page 6]


Internet-Draft               Mobile Use Case                October 2010


   for PMIP and GTP-U tunnels carrying user data.  This upgrade can
   proceed independently of the work on user-plane traffic, but presents
   its own coexistence problem.  In the immediate case this is because
   it will take time to reconfigure all of the equipment in one network.
   Over the longer term the problem arises because different networks
   will upgrade at different times, and they must interoperate to
   support mobile roaming in the meantime.

3.1.  IPv6 Coexistence Strategy 1: Dual-Stack Connectivity With Limited
      Public IPv4 Address Pools

   In this IPv6 transition scenario, the UEs operate in dual stack mode
   and are assigned both an IPv6 prefix and an IPv4 address in order to
   allow them to utilise both IPv4- and IPv6-capable applications.
   Dual-stack UEs are able to support parallel IPv4 and IPv6
   connectivity to a single PDN.  As popular services start to support
   IPv6, IPv4 traffic will gradually be offloaded into the IPv6 domain.
   Services owned and deployed by the operator may be IPv6-enabled first
   (while retaining IPv4 capability) and hence will be accessible to
   dual-stack capable MSs running IPv6.

   Issue: In dual stack mode, every UE still needs an IPv4 address.  As
   the number of subscribers grows, the lack of additional public IPv4
   addresses will force the use of private rather than public IPv4
   addresses for some UEs.  Aside from anything else, this will
   complicate the operation of mobile IP.

3.2.  IPv6Coexistence Strategy 2: Dual Stack Connectivity With Limited
      Private IPv4 Address Pools

   In this scenario, UEs operate in dual stack mode and are assigned
   both an IPv6 prefix and a private IPv4 address in order to allow them
   to utilise both IPv4- and IPv6-capable applications.  The IPv4
   addresses assigned to UEs are taken from one of the private address
   ranges specified in RFC 1918.  NAT is performed on the interface
   between the PDN Gateway and the core IP network.

   Issue : The number of private IP addresses is limited.  If more than
   16 million UEs are active in the same network simultaneously, the
   network could run out of private IPv4 addresses to assign.

      The problem could be worse than this, depending on how many
      addresses are temporarily unused because they haven`t been
      reclaimed after the UE roamed out of the network or shut down.







Zhou & Taylor            Expires April 22, 2011                 [Page 7]


Internet-Draft               Mobile Use Case                October 2010


3.3.  IPv6 Coexistence Strategy 3: UEs With IPv6-only Transport and
      Applications Using IPv6

   In this scenario, the operator decides to assign only IPv6 prefixes
   to the UEs due to, e.g., shortage of IPv4 addresses or because the
   UEs support only IPv6.

   Issue: UEs with IPv6-only connectivity running applications using
   IPv6 should be able to access both IPv4- or IPv6-enabled services.
   NAT64 and DNS64 should be performed to let the IPv6-only UEs have
   access to IPv4 services.

3.4.  IPv6 Coexistence Strategy 4: IPv4 Applications Running On a  Dual-
      Stack Host With an Assigned IPv6 Prefix and a Shared IPv4 Address

   In this scenario an IPv4 application running on a dual-stack UE needs
   to access IPv4 services without the operator having to allocate a
   unique non-shared (private or public) IPv4 address to the UE.  The
   dual-stack UE running these applications uses an IPv4 address that is
   shared amongst many other UEs, and uses an IPv6 prefix.

   Issue: The obvious issue arises, that IPv4 services need to be able
   to distinguish between UEs using the same IPv4 address.  The source
   port may be used for this purpose.


4.  Consideration of IPv4 / IPv6 Coexistence Solutions

   The different strategies described above require support to make them
   work.

4.1.  Gateway-Initiated Dual-Stack Lite

   Dual-stack lite (DS-lite) [I-D.softwire-dual-stack-lite-06]
   transports IPv4 traffic from the user device in an IPv6 tunnel across
   an IPv6 provider network to a NAT44, where sharing of IPv4 public
   addresses can be implemented.  To prevent user DNS queries from going
   through the NAT44, all queries are intercepted and sent to an IPv6
   DNS server.  Gateway-initiated DS-lite
   [I-D.softwire-gateway-init-ds-lite-00] makes explicit use of the
   tunnel set up through the access network to carry user packets to the
   IP network.  The gateway at the IP end of this tunnel maintains a
   single tunnel between itself and the NAT44, to which it forwards
   packets from all of the user devices connected to it.  The inner
   source IP address of the individual packets is actually a 32-bit
   context identifier used with other information to retrieve forwarding
   state at the gateway and the NAT44.  Gateway-initiated DS-lite also
   reduces or in some configurations eliminates the need for a unique



Zhou & Taylor            Expires April 22, 2011                 [Page 8]


Internet-Draft               Mobile Use Case                October 2010


   IPv4 address, public or private, at the UE.

   As applied to the architectures described in Section 2, the gateway
   is represented by the PDN Gateway or GGSN.  The NAT44 is located
   beyond the gateway, in the core IP network.  The access tunnels are
   GTP over IP, and indeed the tunnel IP version may be either IPv4 or
   IPv6 without affecting the operation of gateway-initiated DS lite.
   Section 5.6.1.2 of [3GPP_TR_23_060] suggests that GTP tunnels run
   between the core nodes too, so the core network may run IPv4 or IPv6
   independently of what is used in the access network.

   By making the IPv4 address provisioned at the UE almost irrelevant,
   gateway-initiated DS-lite supports any of the strategies described in
   Section 3 except the all-IPv6 approach.  One issue is that, at the
   beginning when most traffic is IPv4, a large investment in NAT44
   capacity will be needed.  As traffic migrates to IPv6, this
   investment becomes stranded and not reusable.  Another issue is that
   all IPv4 traffic suffers the quality of service penalty imposed by
   the use of NAT.

   One issue that has to be resolved is how to handle DNS queries for
   IPv4 addresses.  [I-D.softwire-dual-stack-lite-06] requires that all
   DNS queries be sent to an IPv6 DNS server.  Discussion on the
   softwires list leading up to this suggested that from there, A record
   requests could be forwarded to an IPv4 server.  Alternatively, the
   IPv6 server could maintain both AAAA and A records.  A third
   possibility was that the address of an IPv4 DNS server could be
   configured manually at the UE.  This is messy, both on grounds of
   operational cost and because it would push DNS queries through the
   NAT44, greatly increasing its workload.

4.2.  Protocol Translation

   NAT-PT was first described in [RFC2766].  [RFC4966] summarized a
   number of issues identified with NAT-PT in the intervening years.  As
   a result, [RFC2766] was deprecated and given Historic status.

   The IETF has made a new attempt at solving the problem.
   [ID_v6v4_framework] explores a number of different translation
   scenarios.  Any particular application must identify which of the
   scenarios it is dealing with before it can choose stateless versus
   stateful translation.

   [ID_IVI] reports on an early implementation of stateless translation,
   operating in the two directions between an IPv6 network and the IPv4
   Internet.  This has been deployed in the China Education and Research
   Network (CERNET).  IVI predates the official IETF work in this area,
   references to which are given both in [ID_v6v4_framework] and



Zhou & Taylor            Expires April 22, 2011                 [Page 9]


Internet-Draft               Mobile Use Case                October 2010


   [ID_IVI].


5.  IANA Considerations

   This memo includes no request to IANA.


6.  Security Considerations

   This memo does not in itself introduce any security issues.


7.  informative References

   [3GPP_TR_23_060]
              3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS); Service description; Stage 2
              (Release 9)", TR 23.060, June 2010.

   [3GPP_TR_23_401]
              3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS) enhancements for Evolved
              Universal Terrestrial Radio Access Network (E-UTRAN)
              access (Release 9)", TR 23.401, March 2010.

   [3GPP_TR_23_402]
              3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects;
              Architecture enhancements for non-3GPP accesses (Release
              9)", TR 23.402, June 2010.

   [I-D.huang-behave-pnat-01]
              Huang, B., "Prefix NAT: Host based IPv6 translation",
              February 2010.

   [I-D.softwire-dual-stack-lite-06]
              Durand, A., "Dual-Stack Lite Broadband Deployments
              Following IPv4 Exhaustion", August 2010.

   [I-D.softwire-gateway-init-ds-lite-00]
              Brockners, F., "Gateway Initiated Dual-Stack Lite
              Deployment", May 2010.

   [ID_IVI]   Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "",
              January 2010.



Zhou & Taylor            Expires April 22, 2011                [Page 10]


Internet-Draft               Mobile Use Case                October 2010


   [ID_v6v4_framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation (Work in progress)", August 2010.

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

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.


Authors' Addresses

   Cathy Zhou (editor)
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathyzhou@huawei.com


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.
   Ottawa  K1H 6Z8
   Canada

   Phone:
   Email: tom111.taylor@bell.net









Zhou & Taylor            Expires April 22, 2011                [Page 11]