Skip to main content

IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7445.
Authors Gang Chen , DENG Hui , Dave Michaud , Jouni Korhonen , Mohamed Boucadair , Vizdal Ales , Cameron Byrne
Last updated 2014-01-13
Replaces draft-chen-v6ops-ipv6-roaming-analysis
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7445 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-v6ops-ipv6-roaming-analysis-00
Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: July 17, 2014                                        D. Michaud
                                                   Rogers Communications
                                                             J. Korhonen
                                                          Renesas Mobile
                                                            M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                                C. Byrne
                                                            T-Mobile USA
                                                        January 13, 2014

                     IPv6 Roaming Behavior Analysis
               draft-ietf-v6ops-ipv6-roaming-analysis-00

Abstract

   This document identifies as set of failure cases encountered by an
   IPv6-enabled IPv6 customers in roaming scenarios.  The investigations
   on those failed cases reveal the causes in order to notice improper
   configurations, equipment's incomplete functions or inconsistent IPv6
   introduction strategy.

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 July 17, 2014.

Chen, et al.              Expires July 17, 2014                 [Page 1]
Internet-Draft            IPv6 Roaming Analysis             January 2014

Copyright Notice

   Copyright (c) 2014 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Roaming Architecture Description  . . . . . . . . . . . . . .   3
   3.  Roaming Scenario: Overview  . . . . . . . . . . . . . . . . .   5
   4.  Failure Cases in the Attach Stage . . . . . . . . . . . . . .   6
   5.  Failure Cases in the IP Allocation Stage  . . . . . . . . . .   7
     5.1.  Case 1: Splitting Dual-stack Bearer . . . . . . . . . . .   7
     5.2.  Case 2: Lack of IPv6 support in applications  . . . . . .   8
     5.3.  Case 3: Fallback Incapability . . . . . . . . . . . . . .   8
     5.4.  Case 4: 464xlat Support . . . . . . . . . . . . . . . . .   9
   6.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Many Mobile Operators deployed or are in a per-deployment stage of
   IPv6 in their operational networks.  Customers will be delivered with
   IPv6 connectivity if their UE (User Equipment) are IPv6-compliant.
   Many strategies can be adopted for IPv6 introduction in mobile
   networks (see for example [TR23.975]).  A detailed overview of IPv6
   support in 3GPP architectures is provided in [RFC6459].

   Mobile Operators may deploy dual-stack or IPv6 single-stack depending
   on network's conditions.  It has been observed that those deployments
   are rolled out in multiple provisioning domains.  In the early IPv6
   stage, a mobile subscriber roaming around the different areas may

Chen, et al.              Expires July 17, 2014                 [Page 2]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   experience service degradations or interruptions due to the
   inconsistent configurations and incomplete functions in the networks
   nodes.

   This memo intends to document the observed failed cases and analyze
   the causes.

2.  Roaming Architecture Description

   The roaming process could be triggered in the following scenarios:

   o  International roaming: a mobile UE may entry a visited network,
      where different PLMN (Public Land Mobile Network) identity is
      used.  UEs could, either in an automatic mode or a manual mode,
      attach to the visited PLMN.

   o  Intra-PLMN mobility: a UE moves to a visited network as that of
      the Home Public Land Mobile Network (HPLMN).  However, the
      subscriber profiles may not be stored in the area.  Once the
      subscriber attached to the network, the subscriber profile should
      be extracted from the home network for the network registration.

   When a UE is turned on or is transferred via a handover to a visited
   network, the mobile device will scan all radio channels and find
   available Public Land Mobile Networks (PLMNs) to attach.  Serving
   GPRS Support Node (SGSN) or Mobility Management Entity (MME) in the
   visited networks must contact the Home Location Register(HLR) or Home
   Subscriber Server(HSS) and obtain the subscriber profile.  Once the
   authentication and registration process is completed, the PDP
   activation and traffic flows may be operated differently according to
   the subscriber data configuration.  Two modes have been shown at the
   figure to illustrate, that are "Home routed traffic" (Figure 1) and
   "Local breakout" (Figure 2).

+---------------------------------+             +------------------------+
|Visited Network                  |             |Home Network            |
|  +----+           +--------+    |             |    +--------+ Traffic Flow
|  | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============>
|  +----+           +--------+    | Signaling   |    +--------+          |
|                        |-------------------------->+--------+          |
|                                 |             |    |HLR/HSS |          |
|                                 |             |    +--------+          |
+---------------------------------+             +------------------------+

                       Figure 1: Home Routed Traffic

Chen, et al.              Expires July 17, 2014                 [Page 3]
Internet-Draft            IPv6 Roaming Analysis             January 2014

+---------------------------------+             +------------------------+
|Visited Network                  |             |Home Network            |
|  +----+           +--------+    | Signaling   |    +--------+          |
|  | UE |==========>|SGSN/MME|---------------------->|HLR/HSS |          |
|  +----+           +--------+    |             |    +--------+          |
|                       ||        |             |                        |
|                   +--------+    |             |                        |
|                   |GGSN/PGW|    |             |                        |
|                   +--------+    |             |                        |
|         Traffic Flow  ||        |             |                        |
+-----------------------||--------+             +------------------------+
                        \/

                         Figure 2: Local Breadkout

   In the home routed mode, subscribers will activate the PDP/PDN
   context and get address from the home network.  All traffic would be
   routed back to the home networks.  That is the default case for an
   international roaming except for the IP Multimedia Subsystem (IMS)
   scenario.

   In the local breakout mode, the subscriber address will be assigned
   from the visited network.  The traffic flow would directly offloaded
   locally at a network node close to that device's point of attachment
   in the visited networks.  Therefore, more efficient route would be
   achieved.  The following will describe the cases where there is local
   breakout mode adopted.

   o  Operators may add the APN-OI-Replacement flag defined in 3GPP
      [TS29.272] into user's subscription-data.  The visited network
      indicates a local domain name to replace the user requested Access
      Point Name (APN).  As the consequence, the traffic would be
      steered to the visited network.  Those functions are normally
      deployed for the Intra-PLMN mobility cases.

   o  Operators could also configure VPLMN-Dynamic-Address-Allowed
      flag[TS29.272] in the user profile to enable local breakout mode
      in Visited Public Land Mobile Networks (VPLMNs).

   o  3GPP specified Selected IP Traffic Offload (SIPTO)
      function[TS23.401] since Release 10 in order to get efficient
      route paths.  It enables an operator to offload certain types of
      traffic at a network node close to that device's point of
      attachment to the access network.

   o  GSMA has defined RAVEL[IR.65] as IMS international roaming
      architecture.  Local breakout mode has been adopted for the
      roaming architecture.

Chen, et al.              Expires July 17, 2014                 [Page 4]
Internet-Draft            IPv6 Roaming Analysis             January 2014

3.  Roaming Scenario: Overview

   3GPP specifies three types of Packet Data Protocol (PDP)/Packet Data
   Networks (PDN) to describe connections: PDP/PDN Type IPv4, PDP/PDN
   Type IPv6 and PDP/PDN Type IPv4v6.  When establishing a data session,
   user devices are configured to request a particular PDP/PDN Type.
   The allowed PDP/PDN types for a particular subscriber are stored in
   the Home Subscriber Server (HSS) or Home Location Register (HLR) as
   part of the subscriber profile as defined in [TS29.272].

   When a subscriber roams and attempts to attach to a visited network,
   the visited network identifies the subscriber's home network.
   Afterwards, the visited network will contact the home network and
   request the subscriber profile from the home HSS/HLR.  The subscriber
   profile contains the allowed Access Point Names (APN), allowed PDP/
   PDN Types and policies regarding the routing of data sessions (i.e.
   home routed or local breakout mode).  The failures are happened
   either in the initial network attach stage or the IP address
   allocation process due to the mismatch between the subscriber
   requested, allowed PDP/PDN Type and the visited network capability.

   The failures in the initial network process are likely occurred in
   both cases of home routed and the local breakout.  The visited
   network may not be able to parse the subscription information
   containing the PDP/PDN Type IPv4v6, therefore it would reject the
   attach request from roaming subscribers.  Section 4 provides the
   detailed discussion on the causes and known solutions.

   Even if roaming subscribers have a successful attach to the visited
   network, there are still some failures during the IP address
   allocation.  Those failures are mainly appeared in the local breakout
   cases.  The below table lists the potential cases.  Section 5 makes
   further descriptions for the each case.

Chen, et al.              Expires July 17, 2014                 [Page 5]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   +-------------+-------------------+--------------+
   | UE request  |  PDN/PDP IP Type  |Local breakout|
   |             |     permitted     |              |
   +-------------+-------------------+--------------+
   | IPv4v6      |  IPv4 or IPv6     |Failure case 1|
   +-------------+-------------------+--------------+
   | IPv4v6      |      IPv6         |Failure case 2|
   +-------------+-------------------+--------------+
   | IPv6        |      IPv4         |Failure case 3|
   +-------------+-------------------+--------------+
   | IPv6        |       IPv6        |Failure case 4|
   | with 464xlat|   without NAT64   |              |
   +-------------+-------------------+--------------+

                  Table 1: Roaming Scenario Descriptions

4.  Failure Cases in the Attach Stage

   3GPP specified PDP/PDN type IPv4v6 into 3G network since Release 9.
   It allows a User Equipment (UE) to request both IPv4 and IPv6 within
   a single PDP/PDN request.  This feature is stored as a part of
   subscription data for a subscriber in the Home Location
   Registrar(HLR) or Home Subscriber Server(HSS).  It should be
   understandable to the Serving GPRS Support Node (SGSN) during the
   network attach process.  However, operators may have different
   strategies to upgrade their network to support this new feature.  If
   the home network populates the PDP/PDN type IPv4v6 in the
   subscription data and the visited network just stay as early as pre-
   Release 9, the failure is likely to be encountered.

   When a subscriber roams to an IPv4 network, the visited SGSN has to
   communicate with HLR/HSS in the home land to retrieve the subscriber
   profile.  The issue we observe is that multiple SGSNs will be unable
   to correctly process a subscriber data received in the Insert
   Subscriber Data procedure[TS23.060] if it contains an Ext-PDP-Type
   defined in 3GPP [TS29.002].  As a consequence , it will likely refuse
   the subscriber attach request.

   Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in
   the home network, that will restrict UEs only initiates IPv4 PDP or
   IPv6 PDP activation.  In order to avoid this situation, operators
   should make a comprehensive roaming agreement to support IPv6 and
   ensure that aligns with GSMA document, e.g [IR.33], [IR.88] and
   [IR.21].  Since the agreement requires visited operators to upgrade
   all SGSN nodes, some short- or medium-term solutions have been
   implemented to fix the issue.  There are some specific configurations
   in HLS/HSS of home network.  Multiple PDP/PDN subscription
   information will be added in the subscriber profiles, for example it

Chen, et al.              Expires July 17, 2014                 [Page 6]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   may include both PDP/PDN type IPv4 and PDP/PDN type IPv4v6 for a user
   profile.  Once the HLR/HSS receives an Update Location message from
   visited SGSN, only the subscription data with PDP/PDN type IPv4 will
   be sent to SGSN/MME in the Insert Subscriber Data procedure.  It
   guarantee the user profile could compatible with visited SGSN/MME
   capability.

5.  Failure Cases in the IP Allocation Stage

   Once a subscriber succeed in the attach stage, IP allocation process
   is taken place to allocate IP addresses to the subscriber.  This
   section has summarized several failures in the break-out cases.

5.1.  Case 1: Splitting Dual-stack Bearer

   Dual-stack capability can be provided in a early mobile network (i.e.
   Pre-Release 8 network) using separate PDP/PDN activations.  That
   means only a single IPv4 and IPv6 PDP/PDN is allowed to be initiated
   to allocate IPv4 and IPv6 address separately.  The below demonstrates
   the cases.

   o  The GGSN/PGW preferences dictate the use of IPv4 addressing only
      or IPv6 prefix only for a specific APN.

   o  The SGSN/MME does not set the Dual Address Bearer Flag due to the
      operator using single addressing per bearer to support
      interworking with nodes of earlier releases

   A roaming subscriber with IPv4v6 PDP/PDN type have to change the
   request into two separated PDP/PDN requests with single IP version in
   order to achieve equivalent results.  Some drawbacks in this case are
   listed as following:

   o  The parallel PDP/PDN activations would likely double PDP/PDN
      resources consumptions.  It impacts the capacity of GGSN/PGW,
      since a certain amount of PDP/PDN activations are only allowed on
      those nodes.

   o  Some networks may only allow one PDP/PDN is alive for each
      subscriber.  For example, IPv6 PDP/PDN will be rejected if the
      subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
      will lost IPv6 connection in the visited network.

   o  Additional correlations between those two PDP/PDN contexts are
      required on the charging system.

   o  Policy and Charging Rules Function(PCRF)/Policy and Charging
      Enforcement Function (PCEF) treat IPv4 and IPv6 session as

Chen, et al.              Expires July 17, 2014                 [Page 7]
Internet-Draft            IPv6 Roaming Analysis             January 2014

      independent and perform different Quality of Service (QoS)
      policies.  The subscriber may have unstable experiences due to
      different behaviors on each IP version connection.

   o  Mobile devices may have the limitation of allowed simultaneous PDP
      /PDN activations.  Overmuch PDP/PDN activation may result in other
      unrelated services broken.

   Operators may have to disable the local-break mode to avoid the
   risks.  Another approach is to set a dedicated Access Point Name
   (APN) profile to only request IPv4 PDP/PDN type in the roaming
   network.

5.2.  Case 2: Lack of IPv6 support in applications

   Some operators may adopt IPv6-only configuration for the IMS service,
   e.g. Voice over LTE(VoLTE)[IR.92] or Rich Communication Suite
   (RCS)[RCC.07].  Since IMS roaming architecture will offload all
   traffic in the visited network, a dual-stack subscriber can only be
   assigned with IPv6 address and no IPv4 address returned.  It requires
   all the IMS based applications should be IPv6 capable.  A
   translation-based method, for example Bump-in-the-host (BIH)[RFC6535]
   or 464xlat [RFC6877] may help to address the issue if there are IPv6
   compatibility problems.  Those functions could be automatically
   enabled in an IPv6-only network and disabled in a dual-stack or IPv4
   network.

5.3.  Case 3: Fallback Incapability

   3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4.
   Therefore, the IPv6 single PDP/PDN type has been well supported and
   interpretable in the 3GPP network nodes.  Roaming to IPv4-only
   networks with IPv6 PDP/PDN request could guarantee the subscription
   data is compatible with the visited pre-Release 9 SGSN.  When a
   subscriber requests PDP/PDN type IPv6, the network should only return
   the expected IPv6 address.  The mobile device may be failed to get IP
   address if the visited network only allocates an IPv4 address to a
   subscriber.  In that case, the request will be dropped and the error
   code should be sent to the user.

   A proper fallback is desirable however the behavior is implementation
   specific.  There are some mobile devices have the ability to provide
   a different configuration for home network and visited network
   respectively.  It guarantees UE will always initiate PDP/PDN type
   IPv4 in the roaming area.  Android system solves the issue by setting
   the roaming Access Point Name(APN).  The mobile terminal is allowed
   to ignore the original requested protocol and always adhere to IPv4
   when roaming.

Chen, et al.              Expires July 17, 2014                 [Page 8]
Internet-Draft            IPv6 Roaming Analysis             January 2014

5.4.  Case 4: 464xlat Support

   464xlat[RFC6877] is proposed to address IPv4 compatibility issue in a
   IPv6 single-stack environment.  The function on a mobile terminal
   likely gets along with PDP/PDN IPv6 type request to cooperate with a
   remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined
   in [RFC7050] to automatically detect the presence of DNS64 and learn
   the IPv6 prefix used for protocol translation.  When a mobile device
   with 464xlat function roams to an IPv6 visited network without the
   presence of NAT64 or DNS64, 464xlat may get failed to perform if
   traffic is undergoing the local breakout approach.

   The issue has been found mostly in a intra-PLMN mobility case.
   Considering the various network's situations, operators may turn off
   the local breakout and take home routed mode to perform 464xlat.
   Some devices may support the configuration to adopt 464xlat in the
   home networks and use IPv4-only in the visited networks with
   different roaming profile configurations.  It could also be a
   solution to address this issue.

6.  Discussions

   Several failure cases have been discussed in this memo.  It has been
   testified the major issues are occurred at the two stages, i.e. the
   initial network attach and the IP allocation process.

   During the initial network attach, PDP/PDN type IPv4v6 is major
   concern to the visited pre-Release 9 SGSN.  The dual-stack deployment
   is recommended in most cases.  However, it may take some times in a
   mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the
   early release.  Such PDP/PDN type is supported in new-built Long Term
   Evolution(LTE)/System Architecture Evolution(SAE) network, but didn't
   support well in the third generation network.  The situations may
   cause the roaming issues dropping the attach request from dual-stack
   subscribers.  Operators may have to adopt temporary solution unless
   all the interworking nodes(i.e. SSGN) in the visited network have
   been upgraded to support Ext-PDP-Type feature.

   The issues in the IP address allocation process are caused due to the
   local breakout policy.  Since the IP address is allocated by the
   visited GGSN or PGW, the mismatch is found in the following aspects.

   o  The mismatch between requested PDP/PDN type and permitted PDP/PDN
      type

   o  The mismatch between application capability and allowed network
      connections

Chen, et al.              Expires July 17, 2014                 [Page 9]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   o  The mismatch between mobile device function (e.g., 464xlat) and
      particular network deployment status

   There are some solutions to overcome the issue.  Those solutions can
   be done either in the network side or mobile devices side.  The below
   lists potential workarounds.

   o  Change local breakout to the home routed mode

   o  A dedicated roaming APN profile is implemented for roamer.  When a
      subscriber roams to a visited network, PDP/PDN type IPv4 is always
      be selected for session activation.

   o  Networks could deploy AAA server to coordinate the mobile device
      capability.  Once the GGSN/PGW receive the session creation
      requests, it will initiate an Access-Request to an AAA server via
      the Radius protocol.  The Access-Request contains subscriber and
      visited network information, e.g. PDP/PDN Type, International
      Mobile Equipment Id (IMEI), Software Version(SV) and visited SGSN/
      MME location code, etc.  The AAA server could take mobile device
      capability combining with the visited network information to
      ultimately determine the type of session to be created, i.e. IPv4,
      IPv6 or IPv4v6.

7.  IANA Considerations

   This document makes no request of IANA.

8.  Security Considerations

   Even if this document does not define a new architecture nor a new
   protocol, it is encouraged to refer to [RFC6459] for a generic
   discussion on IPv6-related security considerations.

9.  Acknowledgements

   Many thanks to F. Baker and J. Brzozowski for their support.

   This document is the result of the IETF v6ops IPv6-Roaming design
   team effort.

   The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
   Heatley Nick, Alexandru Petrescu and Tore Anderson for their helpful
   comments.

Chen, et al.              Expires July 17, 2014                [Page 10]
Internet-Draft            IPv6 Roaming Analysis             January 2014

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
              7050, November 2013.

10.2.  Informative References

   [IR.21]    Global System for Mobile Communications Association,
              GSMA., "Roaming Database, Structure and Updating
              Procedures", July 2012.

   [IR.33]    Global System for Mobile Communications Association,
              GSMA., "GPRS Roaming Guidelines", July 2012.

   [IR.65]    Global System for Mobile Communications Association,
              GSMA., "IMS Roaming & Interworking Guidelines", May 2012.

   [IR.88]    Global System for Mobile Communications Association,
              GSMA., "LTE Roaming Guidelines", January 2012.

Chen, et al.              Expires July 17, 2014                [Page 11]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   [IR.92]    Global System for Mobile Communications Association
              (GSMA), , "IMS Profile for Voice and SMS Version 7.0",
              March 2013.

   [RCC.07]   Global System for Mobile Communications Association
              (GSMA), , "Rich Communication Suite 5.1 Advanced
              Communications Services and Client Specification Version
              4.0", November 2013.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [TR23.975]
              3rd Generation Partnership Project, 3GPP., "IPv6 migration
              guidelines", June 2011.

   [TS23.060]
              3rd Generation Partnership Project, 3GPP., "General Packet
              Radio Service (GPRS); Service description; Stage 2 v9.00",
              March 2009.

   [TS23.401]
              3rd Generation Partnership Project, 3GPP., "General Packet
              Radio Service (GPRS) enhancements for Evolved Universal
              Terrestrial Radio Access Network (E-UTRAN) access v9.00",
              March 2009.

   [TS29.002]
              3rd Generation Partnership Project, 3GPP., "Mobile
              Application Part (MAP) specification v9.00", December
              2009.

   [TS29.272]
              3rd Generation Partnership Project, 3GPP., "Mobility
              Management Entity (MME) and Serving GPRS Support Node
              (SGSN) related interfaces based on Diameter protocol
              v9.00", September 2009.

Chen, et al.              Expires July 17, 2014                [Page 12]
Internet-Draft            IPv6 Roaming Analysis             January 2014

Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: phdgang@gmail.com

   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui@chinamobile.com

   Dave Michaud
   Rogers Communications
   8200 Dixie Rd.
   Brampton, ON L6T 0C1
   Canada

   Email: dave.michaud@rci.rogers.com

   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki, Finland

   Email: jouni.nospam@gmail.com

   Mohamed Boucadair
   France Telecom
   Rennes,
   35000
   France

   Email: mohamed.boucadair@orange.com

Chen, et al.              Expires July 17, 2014                [Page 13]
Internet-Draft            IPv6 Roaming Analysis             January 2014

   Vizdal Ales
   Deutsche Telekom AG
   Tomickova 2144/1
   Prague 4,  149 00
   Czech Republic

   Email: ales.vizdal@t-mobile.cz

   Cameron Byrne
   T-Mobile USA
   Bellevue
   Washington  98105
   USA

   Email: cameron.byrne@t-mobile.com

Chen, et al.              Expires July 17, 2014                [Page 14]