Internet DRAFT - draft-ietf-v6ops-ipv6-roaming-analysis

draft-ietf-v6ops-ipv6-roaming-analysis







Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: April 22, 2015                                       D. Michaud
                                                   Rogers Communications
                                                             J. Korhonen
                                                                Broadcom
                                                            M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                        October 19, 2014


          Analysis of Failure Cases in IPv6 Roaming Scenarios
               draft-ietf-v6ops-ipv6-roaming-analysis-07

Abstract

   This document identifies a set of failure cases that may be
   encountered by IPv6-enabled mobile customers in roaming scenarios.
   The analysis reveals that the failure causes include improper
   configurations, incomplete functionality support in equipment, and
   inconsistent IPv6 deployment strategies between the home and the
   visited networks.

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, 2015.

Copyright Notice

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




Chen, et al.             Expires April 22, 2015                 [Page 1]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Roaming Architecture: An Overview . . . . . . . . . . . .   4
       2.1.1.  Home Routed Mode  . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Local Breakout Mode . . . . . . . . . . . . . . . . .   5
     2.2.  Typical Roaming Scenarios . . . . . . . . . . . . . . . .   6
   3.  Failure Case in the Network Attachment  . . . . . . . . . . .   7
   4.  Failure Cases in the PDP/PDN Creation . . . . . . . . . . . .   8
     4.1.  Case 1: Splitting Dual-stack Bearer . . . . . . . . . . .   9
     4.2.  Case 2: IPv6 PDP/PDN Unsupported  . . . . . . . . . . . .  10
     4.3.  Case 3: Inappropriate Roaming APN Set . . . . . . . . . .  11
     4.4.  Case 4: Fallback Failure  . . . . . . . . . . . . . . . .  11
   5.  Failure Cases in the Service Requests . . . . . . . . . . . .  11
     5.1.  Lack of IPv6 Support in Applications  . . . . . . . . . .  11
     5.2.  464xlat Support . . . . . . . . . . . . . . . . . . . . .  12
   6.  HLR/HSS User Profile Setting  . . . . . . . . . . . . . . . .  12
   7.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Many Mobile Operators have deployed IPv6, or are about to, in their
   operational networks.  A customer in such a network can be provided
   IPv6 connectivity if their User Equipment (UE) is IPv6-compliant.
   Operators may adopt various approaches to deploy IPv6 in mobile
   networks such as the solutions described in [TR23.975]).  Depending
   on network conditions, either dual-stack or IPv6-only deployment
   schemes can be enabled.




Chen, et al.             Expires April 22, 2015                 [Page 2]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   A detailed overview of IPv6 support in 3GPP architectures is provided
   in [RFC6459].

   It has been observed and reported that a mobile subscriber roaming
   around a different operator's areas may experience service disruption
   due to inconsistent configurations and incomplete functionality of
   equipment in the network.  This document focuses on these issues.

1.1.  Terminology

   This document makes use of these terms:

   o  Mobile networks refer to 3GPP mobile networks.

   o  Mobile UE denotes a 3GPP device which can be connected to 3GPP
      mobile networks.

   o  The Public Land Mobile Network (PLMN) is a network that is
      operated by a single administrative entity.  A PLMN (and therefore
      also an operator) is identified by the Mobile Country Code (MCC)
      and the Mobile Network Code (MNC).  Each (telecommunications)
      operator providing mobile services has its own PLMN [RFC6459].

   o  The Home Location Register (HLR) is a pre-Release-5 database (but
      is also used in Release-5 and later networks in real deployments)
      that contains subscriber data and information related to call
      routing.  All subscribers of an operator and the subscribers'
      enabled services are provisioned in the HLR [RFC6459].

   o  The Home Subscriber Server (HSS) is a database for a given
      subscriber and was introduced in 3GPP Release-5.  It is the entity
      containing the subscription-related information to support the
      network entities actually handling calls/sessions [RFC6459].

   "HLR/HSS" is used collectively for the subscriber database unless
   referring to the failure case related to General Packet Radio Service
   (GPRS) Subscriber data from the HLR.

   An overview of key 3GPP functional elements is documented in
   [RFC6459].

   "Mobile device" and "mobile UE" are used interchangeably.

2.  Background







Chen, et al.             Expires April 22, 2015                 [Page 3]

Internet-Draft            IPv6 Roaming Analysis             October 2014


2.1.  Roaming Architecture: An Overview

   Roaming occurs in two scenarios:

   o  International roaming: a mobile UE enters a visited network
      operated by a different operator, where a different Public Land
      Mobile Network (PLMN) code is used.  The UEs could, either in an
      automatic mode or in a manual mode, attach to the visited PLMN.

   o  Intra-PLMN mobility: an operator may have one or multiple PLMN
      codes.  A mobile UE could pre-configure the codes to identify the
      Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN).  Intra-PLMN
      mobility allows the UE moving to a different area of HPLMN and
      EHPLMN.  When the subscriber profile is not stored in the visited
      area, HLR/HSS in the Home area will transmit the profile to
      Serving GPRS Support Node (SGSN)/Mobility Management Entity (MME)
      in the visited area so as to complete network attachment.

   When a UE is turned on or is transferred via a hand-over to a visited
   network, the mobile device will scan all radio channels and find
   available PLMNs to attach to.  The SGSN or the MME in the visited
   networks must contact the HLR or HSS to retrieve the subscriber
   profile.

   Steering of roaming may also be used by the HPLMN to further restrict
   which of the available networks the UE may be attached to.  Once the
   authentication and registration stage is completed, the Packet Data
   Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
   flows may be operated differently according to the subscriber profile
   stored in the HLR or the HSS.

   The following sub-sections describe two roaming modes: Home routed
   traffic (Section 2.1.1) and Local breakout (Section 2.1.2).

2.1.1.  Home Routed Mode

   In this mode, the subscriber's UE gets IP addresses from the home
   network.  All traffic belonging to that UE is therefore routed to the
   home network (Figure 1).

   GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
   networks [IR.34] are likely to be invoked as the transit network to
   deliver the traffic.  This is the main mode for international roaming
   of Internet data services to facilitate the charging process between
   the two involved operators.






Chen, et al.             Expires April 22, 2015                 [Page 4]

Internet-Draft            IPv6 Roaming Analysis             October 2014


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

                       Figure 1: Home Routed Traffic

2.1.2.  Local Breakout Mode

   In the local breakout mode, IP addresses are assigned by the visited
   network to a roaming mobile UE.  Unlike the home mode, the traffic
   doesn't have to traverse GRX/IPX; it is offloaded locally at a
   network node close to that device's point of attachment in the
   visited network.  This mode ensures a more optimized forwarding path
   for the delivery of packets belonging to a visiting UE (Figure 2).

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

                         Figure 2: Local Breakout

   The international roaming of IP Multimedia Subsystem (IMS) based
   services, e.g., Voice over LTE (VoLTE)[IR.92], is claimed to select
   the local breakout mode in [IR.65].  Data service roaming across
   different areas within an operator network might use local breakout
   mode in order to get more efficient traffic forwarding and also ease
   emergency services.  The local breakout mode could also be applied to
   an operator's alliance for international roaming of data service.

   EU Roaming Regulation III [EU-Roaming-III] involves local breakout
   mode allowing European subscribers roaming in European 2G/3G networks
   to have their Internet data routed directly to the Internet from
   their current VPLMN.



Chen, et al.             Expires April 22, 2015                 [Page 5]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   Specific local breakout-related configuration considerations are
   listed below:

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

   o  Operators may also configure the VPLMN-Dynamic-Address-Allowed
      flag [TS29.272] in the user's 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 a portion of the traffic at a
      network node close to the visiting UE's point of attachment to the
      visited network.

   o  GSMA has defined Roaming Architecture for Voice over LTE with
      Local Breakout (RAVEL) [IR.65] as the IMS international roaming
      architecture.  Local breakout mode has been adopted for the IMS
      roaming architecture.

2.2.  Typical Roaming Scenarios

   Three stages occur when a subscriber roams to a visited network and
   intends to invoke services:

   o  Network attachment: this occurs when the UE enters a visited
      network.  During the attachment phase, the visited network should
      authenticate the subscriber and make a location update to the HSS/
      HLR in the home network of the subscriber.  Accordingly, the
      subscriber profile is offered from the HSS/HLR.  The subscriber
      profile contains the allowed Access Point Names (APN), the allowed
      PDP/PDN Types and rules regarding the routing of data sessions
      (i.e., home routed or local breakout mode) [TS29.272].  The SGSN/
      MME in the visited network can use this information to facilitate
      the subsequent PDP/PDN session creation.

   o  PDP/PDN context creation: this occurs after the subscriber UE has
      been successfully attached to the network.  This stage is
      integrated with the attachment stage in the case of 4G, but is a
      separate process in 2/3G. 3GPP specifies three types of PDP/PDN to
      describe connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6
      and PDP/ PDN Type IPv4v6.  When a subscriber creates a data
      session, their device requests a particular PDP/PDN Type.  The



Chen, et al.             Expires April 22, 2015                 [Page 6]

Internet-Draft            IPv6 Roaming Analysis             October 2014


      allowed PDP/PDN types for that subscriber are learned in the
      attachment stage.  Hence, SGSN/MME could initiate PDP/PDN request
      to GGSN/PGW modulo subscription grants.

   o  Service requests: when the PDP/PDN context is created
      successfully, UEs may launch applications and request services
      based on the allocated IP addresses.  The service traffic will be
      transmitted via the visited network.

   Failures that occur at the attachment stage (Section 3) are
   independent of home routed and the local breakout mode.  Most failure
   cases in the PDP/PDN context creation (Section 4) and service
   requests (Section 5) occur in the local breakout mode.

3.  Failure Case in the Network Attachment

   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both an
   IPv4 address and an IPv6 prefix within a single PDP/PDN bearer.  This
   option is stored as a part of subscription data for a subscriber in
   the HLR/HSS.  PDP/PDN type IPv4v6 has been introduced at the
   inception of Evolved Packet System (EPS) in 4G networks.

   The nodes in 4G networks should present no issues with the handling
   of this PDN type.  However, the level of support varies in 2/3G
   networks depending on SGSN software version.  In theory, S4-SGSN
   (i.e., an SGSN with S4 interface) supports the PDP/PDN type IPv4v6
   since Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface)
   supports it since Release 9.  In most cases, operators normally use
   Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway
   (PGW) in 4G.

   The MAP (Mobile Application Part) protocol, as defined in 3GPP
   [TS29.002], is used over the Gr interface between SGSN and HLR.  The
   MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
   Type that is conveyed to SGSN from the HLR within the Insert
   Subscriber Data (ISD) MAP operation.  If the SGSN does not support
   the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and
   consequently it must silently discard that IE and continue processing
   of the rest of the ISD MAP message.  An issue that has been observed
   is that multiple SGSNs are unable to correctly process a subscriber's
   data received in the Insert Subscriber Data Procedure [TS23.060].  As
   a consequence, it will likely discard the subscriber attach request.
   This is erroneous behavior due to the equipment not being compliant
   with 3GPP Release 9.

   In order to avoid encountering this attach problem at a visited SGSN,
   both operators should make a comprehensive roaming agreement to
   support IPv6 and ensure that it aligns with the GSMA documents, e.g.,



Chen, et al.             Expires April 22, 2015                 [Page 7]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   [IR.33], [IR.88] and [IR.21].  Such an agreement requires the visited
   operator to get the necessary patch on all its SGSN nodes to support
   the "ext-pdp-Type" MAP IE sent by the HLR.  To ensure data session
   continuity in Radio Access Technology (RAT) handovers the PDN Type
   sent by the HSS to the MME could be consistent with the PDP Type sent
   by the HLR to the Gn-SGSN.  Where roaming agreements and visited SGSN
   nodes have not been updated, the HPLMN also has to make use of
   specific implementations (not standardized by 3GPP, discussed further
   in Section 6) in the HLR/HSS of the home network.  That is, when the
   HLR/HSS receives an Update Location message from a visited SGSN not
   known to support dual-stack in a single bearer, subscription data
   allowing only PDP/PDN type IPv4 or IPv6 will be sent to that SGSN in
   the Insert Subscriber Data procedure.  This guarantees that the user
   profile is compatible with the visited SGSN/MME capability.  In
   addition, HSS may not have to change, if the PGW is aware of
   subscriber's roaming status and only restricts the accepted PDN type
   consistent with PDP type sent by the HLR.  For example, an AAA server
   may coordinate with the PGW to decide the allowed PDN type.

   Alternatively, HPLMNs without the non-standardized capability to
   suppress the sending of "ext-pdp-Type" by the HLR may have to remove
   this attribute from APNs with roaming service.  PDN Type IPv4v6 must
   also be removed from the corresponding profile for the APN in the
   HSS.  This will restrict their roaming UEs to only IPv4 or IPv6 PDP/
   PDN activation.  This alternative has problems:

   o  The HPLMN cannot support dual-stack in a single bearer at home
      either where the APN profile in the HLR/HSS is also used for
      roaming.

   o  The UE may set-up separate parallel bearers for IPv4 and IPv6
      where only single stack IPv4 or IPv6 service is preferred by the
      operator.

4.  Failure Cases in the PDP/PDN Creation

   When a subscriber's UE succeeds in the attach stage, the IP
   allocation process takes place to retrieve IP addresses.  In general,
   a PDP/PDN type IPv4v6 request implicitly allows the network side to
   make several IP assignment options, including IPv4-only, IPv6-only,
   IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in separated
   PDP/PDN bearers.

   A PDP/PDN type IPv4 or IPv6 restricts the network side to only
   allocate requested IP address family.

   This section summarizes several failures in the Home Routed (HR) and
   Local Breakout (LBO) mode as shown in Table 1.



Chen, et al.             Expires April 22, 2015                 [Page 8]

Internet-Draft            IPv6 Roaming Analysis             October 2014


        +-------+-------------+------------------------+---------+
        | Case# | UE request  |  PDP/PDN IP Type       |  Mode   |
        |       |             |  permitted on GGSN/PGW |         |
        +-------+-------------+------------------------+---------+
        |       |    IPv4v6   |      IPv4v6            |  HR     |
        |  #1   |-------------+------------------------+---------+
        |       |    IPv4v6   |      IPv4 or IPv6      |  LBO    |
        +-------+-------------+------------------------+---------+
        |  #2   |     IPv6    |      IPv6              |  HR     |
        +-------+-------------+------------------------+---------+
        |  #3   |     IPv4    |      IPv6              |  HR     |
        +-------+-------------+------------------------+---------+
        |  #4   |     IPv6    |      IPv4              |  LBO    |
        +-------+-------------+------------------------+---------+

              Table 1: Failure Cases in the PDP/PDN Creation

4.1.  Case 1: Splitting Dual-stack Bearer

   Dual-stack capability is provided using separate PDP/PDN activation
   in the visited network that doesn't support PDP/PDN type IPv4v6.
   That means only separate parallel single-stack IPv4 and IPv6 PDP/PDN
   connections are allowed to be initiated to separately allocate an
   IPv4 address and an IPv6 prefix.  The SGSN does not support the Dual
   Address Bearer Flag (DAF) or does not set DAF because the operator
   uses single addressing per bearer to support interworking with nodes
   of earlier releases.  Regardless of home routed or local breakout
   mode, GGSN/PGW will change PDN/PDP type to a single address PDP/PDN
   type and return the Session Management (SM) Cause #52 "Single address
   bearers only allowed" or SM Cause #28 "Unknown PDP address or PDP
   type" as per [TS24.008] and [TS24.301] to the UE.  In this case, the
   UE may make another PDP/PDN request with a single address PDP type
   (IPv4 or IPv6) other than the one already activated.

   This approach suffers from the followings drawbacks:

   o  The parallel PDP/PDN activation would likely double PDP/PDN bearer
      resource on the network side and Radio Access Bearer (RAB)
      resource on the RAN side.  It also impacts the capacity of the
      GGSN/PGW, since only a certain amount of PDP/PDN activation is
      allowed on those nodes.

   o  Some networks may only allow one PDP/PDN be alive for each
      subscriber.  For example, an IPv6 PDP/PDN will be rejected if the
      subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
      would not be able to obtain the IPv6 connection in the visited
      network.  It is even worse as they may have a risk of losing all
      data connectivity if the IPv6 PDP gets rejected with a permanent



Chen, et al.             Expires April 22, 2015                 [Page 9]

Internet-Draft            IPv6 Roaming Analysis             October 2014


      error at the APN-level and not an error specific to the PDP-Type
      IPv6 requested.

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

   o  Policy and Charging Rules Function (PCRF) [TS29.212]/ Policy and
      Charging Enforcement Function (PCEF) treats the IPv4 and IPv6
      session as independent and performs 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 a limitation on allowed simultaneous PDP/
      PDN contexts.  Excessive PDP/PDN activation may result in service
      disruption.

   In order to avoid the issue, the roaming agreement in the home routed
   mode should make sure the visited SGSN supports and set the DAF.
   Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home
   network, it's expected that the visited SGSN/MME could create dual-
   stack bearer as UE requested.

   In the local breakout mode, the visited SGSN may only allow single IP
   version addressing.  In this case, DAF on visited SGSN/MME has to be
   unset.  One approach is to set a dedicated Access Point Name (APN)
   [TS23.003] profile to only request PDP/PDN type IPv4 in the roaming
   network.  Some operators may also consider not adopting the local
   breakout mode to avoid the risks.

4.2.  Case 2: IPv6 PDP/PDN Unsupported

   PDP/PDN type IPv6 has good compatibility to visited networks during
   the network attachment.  In order to support the IPv6-only visitors,
   SGSN/MME in the visited network is required to accept IPv6-only PDP/
   PDN activation requests and enable IPv6 on user plane towards the
   home network.

   In some cases, IPv6-only visitors may still be subject to the SGSN
   capability in visited networks.  This becomes especially risky if the
   home operator performs roaming steering targeted to an operator that
   doesn't allow IPv6.  The visited SGSN may just directly reject the
   PDP context activation.  Therefore, it's expected that visited
   network is IPv6 roaming-friendly to enable the functions on SGSN/MME
   by default.  Otherwise, operators may consider steering the roaming
   traffic to the IPv6-enable visited network that has IPv6 roaming
   agreement.





Chen, et al.             Expires April 22, 2015                [Page 10]

Internet-Draft            IPv6 Roaming Analysis             October 2014


4.3.  Case 3: Inappropriate Roaming APN Set

   If IPv6 single stack with the home routed mode is deployed, the
   requested PDP/PDN type should also be IPv6.  Some implementations
   that support roaming APN profile may set IPv4 as the default PDP/PDN
   type, since the visited network is incapable of supporting PDP/PDN
   types IPv4v6 (Section 4.1) and IPv6 (Section 4.2).  The PDP/PDN
   request will fail because the APN in the home network only allows
   IPv6.  Therefore, the roaming APN have to be compliant with the home
   network configuration when home routed mode is adopted.

4.4.  Case 4: Fallback Failure

   In the local breakout mode, PDP/PDN type IPv6 should have no issues
   to pass through network attachment process, since 3GPP specified the
   PDP/PDN type IPv6 as early as PDP/PDN type IPv4.  When a visitor
   requests PDP/PDN type IPv6, the network should only return the
   expected IPv6 prefix.  The UE may fail to get an IPv6 prefix if the
   visited network only allocates an IPv4 address.  In this case, the
   visited network will reject the request and send the cause code to
   the UE.

   A proper fallback scheme for PDP/PDN type IPv6 is desirable, however
   there is no standard way to specify this behavior.  Roaming APN
   profile could help to address the issue by setting PDP/PDN type IPv4.
   For instance, the Android system solves the issue by configuring the
   roaming protocol to IPv4 for the Access Point Name (APN).  It
   guarantees that UE will always initiate a PDP/PDN type IPv4 in the
   roaming area.

5.  Failure Cases in the Service Requests

   After the successful network attachment and IP address allocation,
   applications could start to request service based on the activated
   PDP/PDN context.  The service request may depend on specific IP
   family or network collaboration.  If traffic is offloaded locally
   (Section 2.1.2 ), the visited network may not be able to accommodate
   UE's service requests.  This section describes the failures.

5.1.  Lack of IPv6 Support in Applications

   Operators may only allow IPv6 in the IMS APN.  VoLTE [IR.92] or Rich
   Communication Suite (RCS) [RCC.07] use the APN to offer the voice
   service for visitors.  The IMS roaming in RAVEL architecture [IR.65]
   offloads voice and video traffic in the visited network, therefore a
   dual-stack visitor can only be assigned with an IPv6 prefix but no
   IPv4 address.  If the applications can't support IPv6, the service is
   likely to fail.



Chen, et al.             Expires April 22, 2015                [Page 11]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   Translation-based methods, for example 464xlat [RFC6877] or Bump-in-
   the-host (BIH) [RFC6535], may help to address the issue if there are
   IPv6 compatibility problems.  The translation function could be
   enabled in an IPv6-only network and disabled in a dual-stack or IPv4
   network, therefore the IPv4 applications only get the translation in
   the IPv6 network and perform normally in an IPv4 or dual-stack
   network.

5.2.  464xlat Support

   464xlat[RFC6877] is proposed to address the IPv4 compatibility issue
   in an IPv6-only connectivity environment.  The customer-side
   translator (CLAT) function on a mobile device is likely used in
   conjunction with a PDP/PDN IPv6 type request and cooperates with a
   remote NAT64 [RFC6146] device.

   464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to
   detect the presence of NAT64 devices and to learn the IPv6 prefix
   used for protocol translation[RFC6052].

   In the local breakout approach, when a UE with the 464xlat function
   roaming on an IPv6 visited network may encounter various situations.
   For example, the visited network may not deploy DNS64 [RFC6147] but
   only NAT64, CLAT may not be able to discover the provider-side
   translator (PLAT) translation IPv6 prefix used as a destination of
   the PLAT.  If the visited network doesn't deploy NAT64 and DNS64,
   464xlat can't perform successfully due to the lack of PLAT
   collaboration.  Even in the case of the presence of NAT64 and DNS64,
   pre-configured PLAT-side IPv6 prefix in the CLAT may cause the
   failure because it can't match the PLAT translation.

   Considering the various network's situations, operators may turn off
   local breakout and use the home routed mode to perform 464xlat.
   Alternatively, UE may support the different roaming profile
   configurations to adopt 464xlat in the home networks and use
   IPv4-only in the visited networks.

6.  HLR/HSS User Profile Setting

   A proper user profile configuration would provide a deterministic
   outcome to the PDP/PDN creation stage where dual-stack, IPv4-only and
   IPv6-only connectivity requests may come from devices.  The HLR/HSS
   may have to apply extra logic (not standardized by 3GPP) to achieve
   this.  It is also desirable that the network could set-up
   connectivity of any requested PDP/PDN context type.






Chen, et al.             Expires April 22, 2015                [Page 12]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   The following are examples to illustrate the settings for the
   scenarios and decision criteria to apply when returning user profile
   information to the visited SGSN.

                       user profile #1:

                       PDP-Context ::= SEQUENCE {
                       pdp-ContextId ContextId,
                       pdp-Type  PDP-Type-IPv4
                         ....
                       ext-pdp-Type PDP-Type-IPv4v6
                         ...
                       }


                       user profile #2:

                       PDP-Context ::= SEQUENCE {
                       pdp-ContextId ContextId,
                       pdp-Type  PDP-Type-IPv6
                         ....
                       }

    Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices.

   The full PDP-context parameters are referred to Section 17.7.1
   "Mobile Service date types" of [TS29.002].  User profiles #1 and #2
   share the same "ContextId".  The setting of user profile #1 enables
   IPv4-only and dual-stack devices to work.  And, the user profile #2
   fulfills the request if the device asks for IPv6 only PDP context.





















Chen, et al.             Expires April 22, 2015                [Page 13]

Internet-Draft            IPv6 Roaming Analysis             October 2014


                       user profile #1:

                       PDP-Context ::= SEQUENCE {
                       pdp-ContextId ContextId,
                       pdp-Type  PDP-Type-IPv4
                         ....
                       ext-pdp-Type PDP-Type-IPv4v6
                         ...
                       }


                       user profile #2:

                       PDP-Context ::= SEQUENCE {
                       pdp-ContextId ContextId,
                       pdp-Type  PDP-Type-IPv4
                         ....
                       }

    Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access.

   User profiles #1 and #2 share the same "ContextId".  If a visited
   SGSN is identified as early as pre-Release 9, the HLR/HSS should only
   send user profile#2 to the visited SGSN.

7.  Discussion

   Several failure cases have been discussed in this document.  It has
   been illustrated that the major problems happen at three stages,
   i.e., the initial network attachment, the PDP/PDN creation and
   service requests.

   In the network attachment stage, PDP/PDN type IPv4v6 is the major
   concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
   PDN type IPv4v6 in the earlier releases.  That PDP/PDN type is
   supported in new-built EPS network, but isn't supported well in the
   third generation network.  Visited SGSNs may discard the subscriber's
   attach requests because the SGSN is unable to correctly process PDP/
   PDN type IPv4v6.  Operators may have to adopt temporary solutions
   unless all the interworking nodes (i.e., the SGSN) in the visited
   network have been upgraded to support the ext-PDP-Type feature.

   In the PDP/PDN creation stage, PDP/PDN types IPv4v6 and IPv6 support
   on the visited SGSN is the major concern.  It has been observed that
   IPv6 single stack with the home routed mode is a viable approach to
   deploy IPv6.  It is desirable that the visited SGSN could enable IPv6
   on the user plane by default.  For support of the PDP/PDN type
   IPv4v6, it is suggested to set the DAF.  As a complementary function,



Chen, et al.             Expires April 22, 2015                [Page 14]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   the implementation of roaming APN configuration is useful to
   accommodate the visited network.  However, it should consider roaming
   architecture and permitted PDP/PDN type to make proper setting on the
   UE.  Roaming APN in the home routed mode is recommended to align with
   home network profile setting.  In the local breakout case, PDP/PDN
   type IPv4 could be selected as a safe way to initiate PDP/PDN
   activation.

   In the service requests stage, the failure cases mostly occur in the
   local breakout case.  The visited network may not be able to satisfy
   the requested capability from applications or UEs.  Operators may
   consider using home routed mode to avoid these problems.  Several
   solutions either in the network side or mobile device side can also
   help to address the issue.  For example,

   o  464xlat could help IPv4 applications access IPv6 visited networks.

   o  Networks can deploy an AAA server to coordinate the mobile device
      capability.  Once the GGSN/PGW receives the session creation
      request, it will initiate an Access-Request to an AAA server in
      the home network 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 and combine it with the
      visited network information to ultimately determine the type of
      session to be created, i.e., IPv4, IPv6 or IPv4v6.

8.  IANA Considerations

   This document makes no request of IANA.

9.  Security Considerations

   Although this document defines neither a new architecture nor a new
   protocol, the reader is encouraged to refer to [RFC6459] for a
   generic discussion on IPv6-related security considerations.

10.  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, Tore Anderson, Cameron Byrne,




Chen, et al.             Expires April 22, 2015                [Page 15]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   Holger Metschulat and Geir Egeland for their helpful discussions and
   comments.

   The authors especially thank Fred Baker and Ross Chandler for their
   efforts and contributions which substantially improved the
   readability of the document.

11.  References

11.1.  Normative References

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

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

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

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

   [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.12.0", December
              2009.





Chen, et al.             Expires April 22, 2015                [Page 16]

Internet-Draft            IPv6 Roaming Analysis             October 2014


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

11.2.  Informative References

   [EU-Roaming-III]
              "http://www.amdocs.com/Products/Revenue-
              Management/Documents/
              amdocs-eu-roaming-regulation-III-solution.pdf", July 2013.

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

   [IR.34]    Global System for Mobile Communications Association,
              GSMA., "Guidelines for IPX Provider networks", November
              2013.

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

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

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

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




Chen, et al.             Expires April 22, 2015                [Page 17]

Internet-Draft            IPv6 Roaming Analysis             October 2014


   [RFC7225]  Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
              Port Control Protocol (PCP)", RFC 7225, May 2014.

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

   [TS23.003]
              3rd Generation Partnership Project, 3GPP., "Numbering,
              addressing and identification v9.0.0", September 2009.

   [TS24.008]
              3rd Generation Partnership Project, 3GPP., "Mobile radio
              interface Layer 3 specification; Core network protocols;
              Stage 3 v9.00", September 2009.

   [TS24.301]
              3rd Generation Partnership Project, 3GPP., "Non-Access-
              Stratum (NAS) protocol for Evolved Packet System (EPS) ;
              Stage 3 v9.00", September 2009.

   [TS29.212]
              3rd Generation Partnership Project, 3GPP., "Policy and
              Charging Control (PCC); Reference points v9.0.0",
              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





Chen, et al.             Expires April 22, 2015                [Page 18]

Internet-Draft            IPv6 Roaming Analysis             October 2014


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

   Email: dave.michaud@rci.rogers.com


   Jouni Korhonen
   Broadcom
   Porkkalankatu 24
   FIN-00180 Helsinki, Finland

   Email: jouni.nospam@gmail.com


   Mohamed Boucadair
   France Telecom
   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


















Chen, et al.             Expires April 22, 2015                [Page 19]