[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-v6ops-ipv6-roaming-analysis

Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: May 08, 2014                                         D. Michaud
                                                                  Rogers
                                                             J. Korhonen
                                                          Renesas Mobile
                                                            M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                                C. Byrne
                                                            T-Mobile USA
                                                       November 04, 2013


                     IPv6 Roaming Behavior Analysis
               draft-chen-v6ops-ipv6-roaming-analysis-02

Abstract

   This document intends to enumerate failure cases when a IPv6
   subscriber roams into visited network areas.  The investigations on
   those failed cases reveal the causes in order to notice improper
   configurations, equipment's incomplete functions or inconsistent IPv6
   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 May 08, 2014.

Copyright Notice

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



Chen, et al.              Expires May 08, 2014                  [Page 1]


Internet-Draft                ipv6-roaming                 November 2013


   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 Descriptions . . . . . . . . . . . . . .   3
   3.  Roaming Scenario Overview . . . . . . . . . . . . . . . . . .   4
   4.  Failure Cases Descriptions  . . . . . . . . . . . . . . . . .   5
     4.1.  Failure Case 1: Incompatible with Extended PDP/PDN Type .   5
     4.2.  Failure Case 2: Splitting Dual-stack Bearer . . . . . . .   6
     4.3.  Failure Case 3: Shortage of IPv6 support  . . . . . . . .   7
     4.4.  Failure Case 4: Fallback Incapability . . . . . . . . . .   7
     4.5.  Failure Case 5: 464xlat Support . . . . . . . . . . . . .   7
   5.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   IPv6 has been deployed globally to overcome the IPv4 depletion.
   Operators likely start or plan to upgrade the networks that allow
   IPv6 subscribers to access.  As the dramatical uses of Internet
   services with a mobile access, IPv6 is an essential part to be
   considered in the mobile network evolution. 3rd Generation
   Partnership Project (3GPP) published the IPv6 migration guidance
   [TR23.975], which describes different technical evolution paths.  In
   general, 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 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.  It's expected that operators could notice the
   issues and prevent potential risks.



Chen, et al.              Expires May 08, 2014                  [Page 2]


Internet-Draft                ipv6-roaming                 November 2013


2.  Roaming Architecture Descriptions

   The roaming process could be triggered in the following scenarios:

   o  International roaming: a mobile subscriber may entry a visited
      network, where different PLMN identity is used.  The subscribers
      could either in an automatic mode or a manual mode to attach a
      PLMN cell.

   o  Intra-PLMN mobility: a subscriber 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 attaches to the network, the subscriber profile should
      be extracted from the home network for the network registration.

   When a mobile device 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 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" and "Local breakout".

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

                       Figure 1: Home Routed Traffic

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



Chen, et al.              Expires May 08, 2014                  [Page 3]


Internet-Draft                ipv6-roaming                 November 2013


   |         Traffic Flow  ||        |             |                        |
   +-----------------------||--------+             +------------------------+
                           \/

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

3.  Roaming Scenario Overview

   3GPP specified three types of Packet Data Protocol (PDP)/Packet Data
   Networks (PDN) to describe each connection, i.e. PDP/PDN Type IPv4,
   PDP/PDN Type IPv6 and PDP/PDN Type IPv4v6.  User devices can be set
   to request a particular PDP/PDN Type.  Those PDP/PDN types should
   also be restored in Home Subscriber Server (HSS) as a part of
   subscriber profile, as defined in [TS29.272].  When a subscriber



Chen, et al.              Expires May 08, 2014                  [Page 4]


Internet-Draft                ipv6-roaming                 November 2013


   roams to a visited network, the new visited network notices that it
   is not registered with its own system, and attempts to identify its
   home network.  Afterwards, the visited network will contact the home
   network and request the subscriber profile from HSS.  In this
   process, service may be provided in a home routed or local breakout
   mode.  The IP address can be allocated from home network or visited
   network accordingly.  There may be a mismatch between the subscriber
   request and network capability.  The following table lists the
   potential failure cases.

   +-------------+-------------------+--------------+--------------+
   | UE Request  |  Visited Network  | Home routed  |Local Breakout|
   |             |     Capability    |              |              |
   +-------------+-------------------+--------------+--------------+
   | Dual stack  |    IPv4-only      |Failure case 1|Failure case 1|
   +-------------+-------------------+--------------+--------------+
   | Dual stack  |IPv4-only/IPv6-only|Failure case 1|Failure case 2|
   +-------------+-------------------+--------------+--------------+
   | Dual stack  |    IPv6-only      |Failure case 1|Failure case 3|
   +-------------+-------------------+--------------+--------------+
   | IPv6-only   |    IPv4-only      |    OK        |Failure case 4|
   +-------------+-------------------+--------------+--------------+
   | IPv6-only   |   Dual stack      |    OK        |Failure case 5|
   | with 464xlat|                   |              |              |
   +-------------+-------------------+--------------+--------------+
   | IPv6-only   |   IPv6-only       |    OK        |      OK      |
   | with 464xlat|                   |              |              |
   +-------------+-------------------+--------------+--------------+
   | IPv4-only   |    Dual stack     |    OK        |     OK       |
   +-------------+-------------------+--------------+--------------+

                  Table 1: Roaming Scenario Descriptions

4.  Failure Cases Descriptions

4.1.  Failure Case 1: Incompatible with Extended PDP/PDN Type

   A mobile device in a dual-stack network likely requests PDP/PDN type
   IPv4v6 to allocate address.  Such PDP/PDN type should be
   understandable in the network nodes, including Serving GPRS Support
   Node(SGSN), Gateway GPRS Support Node(GGSN), Mobility Management
   Entity (MME), Serving Gateway(SGW), PDN Gateway(PGW), Home Location
   Registrar(HLR) and Home Subscriber Server(HSS).  When a subscriber
   roams to the IPv4 network, the visited SGSN or MME has to communicate
   with HLR/HSS in the home land to retrieve the subscriber profile.
   The issue we observe is that multiple SGSN/MME will be unable to
   correctly process a subscriber profile received in the Insert
   Subscriber Data procedure if it contains an Ext-PDP-Type defined in



Chen, et al.              Expires May 08, 2014                  [Page 5]


Internet-Draft                ipv6-roaming                 November 2013


   3GPP [TS29.002].  Therefore, it will likely refuse the subscriber
   registration.

   Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in
   home networks, 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 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/MME,
   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.

4.2.  Failure Case 2: Splitting Dual-stack Bearer

   Dual-stack capability can also 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 can be
   initiated to allocate IPv4 and IPv6 address separately.  Once a UE
   with PDP/PDN type IPv4v6 request roams to those networks, same issue
   described in failure case 1 will be occurred if the UE initiate a
   network attachment process.

   If networks could allow UE to make a success attachment, a roaming
   subscriber with IPv4v6 PDP/PDN type should change the request to two
   separated PDP/PDN request with single IP version in order to achieve
   equivalent results.  This restriction may be occurred in the below
   two 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

   Above process would likely double PDP/PDN allocation costs.  Some
   operators may only allow one PDP/PDN is alive for each subscriber.
   For example, IPv6 PDP/PDN would be rejected if the subscriber has an
   active IPv4 PDP/PDN.  Therefore, the subscriber will lost IPv6
   connection in the visited network.  Even the two parallel PDP/PDN
   activations are allowed, it will require additional correlation of



Chen, et al.              Expires May 08, 2014                  [Page 6]


Internet-Draft                ipv6-roaming                 November 2013


   those two sessions of single IP version on the charging system.  If
   there are Policy and Charging Rules Function(PCRF)/Policy and
   Charging Enforcement Function (PCEF) deployed, the system would treat
   IPv4 and IPv6 session as independent and perform different Quality of
   Service(QoS) policies.  The subscriber may have unstable experiences
   due to different behaviors on each IP version connection.

4.3.  Failure Case 3: Shortage of IPv6 support

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

4.4.  Failure Case 4: 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.  When a subscriber requests
   PDP/PDN type IPv6, the network should only return the expected IPv6
   address.  Otherwise, the request should be dropped and the error code
   should be sent to the user.  Roaming to IPv4-only networks with IPv6
   PDP/PDN request would fail to get addresses.  A proper fallback is
   desirable however the behavior is implementation specific.  There are
   some UE 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.  Those
   fallback mechanisms are deserved to be implemented timely.

4.5.  Failure Case 5: 464xlat Support

   464xlat[RFC6877] is proposed to address IPv4 compability 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 [I-D.ietf-behave-nat64-discovery-heuristic] to automatically
   discover NAT64 prefixes.  Those behaviors depend on the network
   deployment.  If the DNS64 or NAT64 is not deployed in the visited



Chen, et al.              Expires May 08, 2014                  [Page 7]


Internet-Draft                ipv6-roaming                 November 2013


   networks, 464xlat may be failed to perform.  Considering the various
   network's situations, operators may adopt 464xlat in the home
   networks and use IPv4-only in the roaming networks with different
   roaming profile configurations.

   As an alternative solution, an AAA Server could be deployed to
   connect with GGSN/PGW.  Once the GGSN/PGW receive the session
   creation requests, it will initiate an Access-Request to an AAA
   server via 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 IMEI and SV components
   to verify if device has 464XLAT support.  Combining with the visited
   network information, the AAA server will ultimately decide to enable
   464xlat in an IPv6-only roaming or fallback to IPv4.

5.  Discussions

   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 attachment from dual-stack subscribers in the case of
   LTE to 3G and IPv6-enabled 3G to IPv4 3G. Operators may have to adopt
   temporary solution unless all the interworking nodes(i.e. SSGN and
   SGW) in the visited network have been upgraded to support Ext-PDP-
   Type feature.

   As an alternative solution for dual-stack, operators may change a
   unified PDP/PDN request into two separated single IP version
   requests.  However, this approach is problematic in the Charging
   records and QoS policy enforcement.  In addition, it doubles the PDP
   resource uses.  It may be unappealing for the deployment.

   Conversely, some operators may choose PDP/PDN Type IPv6 to start the
   communications in home networks and use different profile in the
   roaming area.  Since PDP/PDN Type IPv6 has been introduced in 3GPP
   early release, it didn't require upgrading on the interworking nodes
   to make compatibility.  The proper IPv4 fallback mechanism should be
   supported either on the mobile terminal or network equipment.









Chen, et al.              Expires May 08, 2014                  [Page 8]


Internet-Draft                ipv6-roaming                 November 2013


   A roaming to IPv6-only network occurs when operators deploy roaming
   function for IMS service.  A dual-stack capable device could
   implement translation-based function to support the IPv4
   applications.  Those inserted translation function can be turned off
   properly when the terminals roam back to dual-stack or IPv4 networks.
   Operators can also deploy AAA servers to make final decision

6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   The draft didn't introduce additional security concerns to the
   networks.

8.  Acknowledgements

   The authors would like to thank V6ops chairs(Fred Baker and John
   Brzozowski) to encourage us to continue the work.  This document is
   the result of the IETF V6ops IPv6-Roaming design team effort.

9.  References

9.1.  Normative References

   [I-D.ietf-behave-nat64-discovery-heuristic]
              Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
              ietf-behave-nat64-discovery-heuristic-17 (work in
              progress), April 2013.

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




Chen, et al.              Expires May 08, 2014                  [Page 9]


Internet-Draft                ipv6-roaming                 November 2013


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

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

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

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






Chen, et al.              Expires May 08, 2014                 [Page 10]


Internet-Draft                ipv6-roaming                 November 2013


              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.

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

   Email: Michaud@rci.rogers.com


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

   Email: jouni.nospam@gmail.com












Chen, et al.              Expires May 08, 2014                 [Page 11]


Internet-Draft                ipv6-roaming                 November 2013


   Mohamed Boucadair
   France Telecom
   No.32 Xuanwumen West Street
   Rennes,
   35000
   France

   Email: mohamed.boucadair@orange.com


   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 May 08, 2014                 [Page 12]


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