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

                     IPv6 Roaming Behavior Analysis
               draft-ietf-v6ops-ipv6-roaming-analysis-03
               draft-ietf-v6ops-ipv6-roaming-analysis-04

Abstract

   This document identifies a set of failure cases that may be
   encountered by IPv6-enabled mobile customers in roaming scenarios.
   The investigations on those failed cases reveal analysis reveals that the failure causes in order
   to notice include improper
   configurations, equipment's incomplete functions
   or functionality support in equipment, and
   inconsistent IPv6 introduction strategy. 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 February 10, 22, 2015.

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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Home Routed Mode
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Local Breakout Mode
     2.1.  Roaming Architecture: An Overview . . . . . . . . . . . .   3
       2.1.1.  Home Routed Mode  . . . . . . . . . .   4
   3.  Roaming Scenario . . . . . . . .   4
       2.1.2.  Local Breakout Mode . . . . . . . . . . . . . . . . .   5
   4.  Failure Case in Attachment Stage
     2.2.  Typical Roaming Scenarios . . . . . . . . . . . . . . . .   6
   5.
   3.  Failure Case in the Network Attachment  . . . . . . . . . . .   7
   4.  Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . . .   7
     5.1.   8
     4.1.  Case 1: Splitting Dual-stack Bearer . . . . . . . . . . .   7
     5.2.   9
     4.2.  Case 2: Lack of IPv6 support in applications PDP/PDN Unsupported  . . . . . . .   8
     5.3.  Case 3: Fallback Incapability . . . . .  10
     4.3.  Case 3: Inappropriate Roaming APN Set . . . . . . . . .   9
     5.4. .  11
     4.4.  Case 4: 464xlat Support . Fallback Failure  . . . . . . . . . . . . . . . .   9
   6.  HLR/HSS User Profile Setting  11
   5.  Failure Cases in the Service Requests . . . . . . . . . . . .  11
     5.1.  Lack of IPv6 Support in Applications  . . . .   9
   7.  Discussion . . . . . .  11
     5.2.  464xlat Support . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . .  12
   6.  HLR/HSS User Profile Setting  . . . . . . . . . . . . . . . .  12
   7.  Discussion  . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . .  13
   11. References . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgements  . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  15
   11. Informative References  . . . . . . . . . . . . . . . . .  13 . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15  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.  A
   detailed overview of IPv6 support in 3GPP architectures is provided
   in [RFC6459].
   Operators may adopt various approaches to deploy IPv6 in mobile networks, for example
   networks such as the solutions described in [TR23.975]).  Depending
   on network conditions conditions, either dual-stack or
   single-stack IPv6-only deployment
   schemes can be enabled.

   A detailed overview of IPv6 support in 3GPP architectures is selected.

   In production networks, it provided
   in [RFC6459].

   It has been observed and reported that a mobile subscriber roaming
   around a different operator's areas may experience service
   degradation or interruptions disruption
   due to inconsistent configurations and incomplete functionality of
   equipment in the network.

2.  Roaming Architecture Description

   Roaming occurs in two scenarios:  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

2.1.  Roaming Architecture: An Overview

   Roaming occurs in two scenarios:

   o  International roaming: a mobile UE may enter enters a visited network, network
      operated by a different operator, where a different Public Land
      Mobile Network (PLMN) identity 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: a an operator may have one or multiple PLMN
      codes.  A mobile UE moves 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 the
      Home Public Land Mobile Network (HPLMN).  However, HPLMN and
      EHPLMN.  When the subscriber profile may is not be stored in the area.  To allow network
      attachment visited
      area, HLR/HSS in the Home area will transmit the subscribers profile needs to be downloaded from
      Serving GPRS Support Node (SGSN)/Mobility Management Entity (MME)
      in the
      home visited area so as to complete network area. attachment.

   When a UE is turned on or is transferred via a handover hand-over to a visited
   network, the mobile device will scan all radio channels and find
   available Public Land Mobile Networks (PLMNs) PLMNs to attach to.  The
   Serving GPRS Support Node (SGSN) SGSN or the Mobility Management Entity
   (MME) MME in the visited
   networks must contact the Home Location
   Register(HLR) HLR or Home Subscriber Server(HSS) and obtain HSS to retrieve the subscriber
   profile.  After

   Steering of roaming may also be used by the authentication HPLMN to further restrict
   which of the available networks the UE may be attached to.  Once the
   authentication and registration
   process 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.

   There are

   The following sub-sections describe two roaming modes illustrated below, i.e.  "Home modes: Home routed
   traffic" (Figure 1)
   traffic (Section 2.1.1) and "Local breakout" (Figure 2).

2.1. Local breakout (Section 2.1.2).

2.1.1.  Home Routed Mode

   In the home routed this mode, the subscriber's UE activates the PDP/PDN
   context and get an address gets IP addresses from the home
   network.  All traffic belonging to that UE is therefore routed back to the
   home network.  This network (Figure 1).

   GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
   networks [IR.34] is likely to be invoked as the case 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 operators concerned. involved operators.

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

                       Figure 1: Home Routed Traffic

2.2.

2.1.2.  Local Breakout Mode

   In the local breakout mode, the subscriber address is IP addresses are assigned by the visited network.  The
   network to a roaming mobile UE.  Unlike the home mode, the traffic flow
   doesn't have to traverse GRX/IPX; it is directly offloaded locally at a
   network node close to that device's point of attachment in the
   visited network.  Therefore,a  This mode ensures a more efficient route to optimized forwarding path
   for the data
   service is achieved. 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] , (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
   routing. forwarding and also ease
   emergency services.  The local breakout mode could be also be applied to
   an operator's alliance for international roaming of data service.

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

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

                         Figure 2: Local Breakout

   The following enumerates the more specific

   Specific local breakout related configuration
   considerations.

   o 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 intra-PLMN mobility cases.

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

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

   o  GSMA has defined RAVEL[IR.65] 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.

3.

2.2.  Typical Roaming Scenario

   Two Scenarios

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

   o  Network attachment: this occurs when the subscriber UE enters a visited
      network.  During an attachment, 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.
      (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 makes a
      successful attachment. UE has
      been successfully attached to the network.  This stage is
      integrated with the attachment stage in the case of 4G, but is a seperate
      separate process in 2/3G. 3GPP specifies three types of Packet Data Protocol
      (PDP)/Packet Data Networks (PDN) 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
      allowed PDP/PDN types for that subscriber are learned in the
      attachment stage.  Hence, SGSN/MME could initiate PDP/PDN request
      to GGSN/PGW if the modulo subscription
      profile is allowed.

   In both stages, the failure cases described are likely to occur due
   to an incompliant implementation in the visited network or a mismatch
   between grants.

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

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

4.

3.  Failure Case in the Network Attachment Stage

   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both an
   IPv4 address and an IPv6 address prefix within a single PDP/PDN bearer.  This
   option is stored as a part of subscription data for a subscriber in
   the HLR/
   HSS. 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 Serving GPRS
   Support Node (SGSN) SGSN software version.  In theory, S4-SGSN (i.e.
   (i.e., an SGSN with S4 interface) supports the PDP/PDN type IPv4v6
   since
   Release8 Release 8 and a Gn-SGSN (i.e. (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.  The  An issue we observe that has been observed
   is that multiple SGSNs will be are unable to correctly process a subscriber's
   data received in the Insert Subscriber Data Procedure[TS23.060]. Procedure [TS23.060].  As
   a consequence, it will likely refuse discard the subscriber attach request.
   This is erroneous behavior due to the equipment not being compliant
   with 3GPP Release 9 compliant.

   Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS
   in the home network, that will restrict UEs to only initiate IPv4 PDP
   or IPv6 PDP activation. 9.

   In order to avoid encountering this situation, 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. e.g.,

   [IR.33], [IR.88] and [IR.21].  Such an agreement requires the visited
   operator to get the necessary patch on all their its SGSN nodes to support PDP/PDN type
   IPv4v6.

   As an alternative solution there are some specific implementations
   (not standardized
   the "ext-pdp-Type" MAP IE sent by 3GPP) in the HLS/HSS of HLR.  To ensure data session
   continuity in Radio Access Technology (RAT) handovers the home network.  When PDN Type
   sent by the HLR/HSS receives an Update Location message from a visited SGSN
   known HSS to not support the PDP type IPv4v6, subscription data 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.  It  This guarantees that the user
   profile is compatible with the visited SGSN/MME capability.

5.  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 subscriber's UE succeeds in the attach stage, the IP
   allocation process takes place to allocate retrieve IP addresses to the subscriber. addresses.  In general,
   a PDP/PDN type IPv4v6 request implicitly allows a 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 allocates
   allocate requested IP address family.

   This section summarizes several failures in the Home Routed (HR) and
   Local Breakout mode.

   +-------------+-------------------+--------------+ (LBO) mode as shown in Table 1.

        +-------+-------------+------------------------+---------+
        | Case# | UE request  |  PDN/PDP  PDP/PDN IP Type  |Local breakout|       |  Mode   |
        |       |             |  permitted on GGSN/PGW |         |
   +-------------+-------------------+--------------+
        +-------+-------------+------------------------+---------+
        | IPv4v6       |  IPv4 or IPv6     |Failure case 1|
   +-------------+-------------------+--------------+    IPv4v6   |      IPv4v6            |      IPv6         |Failure case 2|
   +-------------+-------------------+--------------+  HR     | IPv6
        |      IPv4         |Failure case 3|
   +-------------+-------------------+--------------+  #1   |-------------+------------------------+---------+
        | IPv6       |       IPv6        |Failure case 4|    IPv4v6   | with 464xlat|   without NAT64      IPv4 or IPv6      |  LBO    |
        +-------+-------------+------------------------+---------+
        |  #2   |     IPv6    |      IPv6              |  HR     |
   +-------------+-------------------+--------------+
        +-------+-------------+------------------------+---------+
        |  #3   |     IPv4    |      IPv6              |  HR     |
        +-------+-------------+------------------------+---------+
        |  #4   |     IPv6    |      IPv4              |  LBO    |
        +-------+-------------+------------------------+---------+

              Table 1: Local Breakout Failure Cases

5.1. in the PDP/PDN Creation

4.1.  Case 1: Splitting Dual-stack Bearer

   Dual-stack capability can be is provided using separate PDP/PDN
   activation. 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 and IPv6 addresses.

   The cases are listed below:

   o  The SGSN/MME returns 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].

   o an IPv6 prefix.  The SGSN/MME SGSN does not set 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

   A roaming subscriber's UE with IPv4v6 PDP/PDN releases.  Regardless of home routed or local breakout
   mode, visited SGSN will change PDN/PDP type has to change a single address PDP/
   PDN type and return the
   request into two separated 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 requests request with a single IP version
   in order to achieve equivalent results.  Some drawbacks of this case
   are listed as below: 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
      resources consumption. 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
      only allowed on those nodes.

   o  Some networks may only allow one PDP/PDN is 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
      will lose 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 error at the APN-level
      and not 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)/Policy 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 activation. contexts.  Excessive PDP/PDN activation may result in other
      unrelated services broken.

   Operators may have service
      disruption.

   In order to disable avoid the local-break issue, the roaming agreement in the home routed
   mode to avoid should make sure the
   risks.  Another approach is to visited SGSN support and set a dedicated Access Point Name
   (APN) profile to only request the DAF.
   Since the PDP/PDN type IPv4 IPv4v6 is supported in the roaming
   network.

5.2.  Case 2: Lack GGSN/PGW of IPv6 support home
   network, the visited SGSN/MME should create dual-stack bearer as UE
   requested.

   In the local breakout mode, the visited GGSN 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 applications the roaming
   network.  Some operators may adopt an IPv6-only configuration for also consider not adopting the IMS
   service, e.g.  Voice over LTE (VoLTE)[IR.92] or Rich Communication
   Suite (RCS)[RCC.07].  Since local
   breakout mode to avoid the IMS roaming architecture will offload
   all traffic 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, a dual-stack subscriber can only
   be assigned with an IPv6 prefix network is required to accept IPv6-only PDP/
   PDN activation requests and no IPv4 address returned.  This
   requires that all the IMS based applications should be enable IPv6 capable.
   A translation-based method, for example Bump-in-the-host
   (BIH)[RFC6535] or 464xlat [RFC6877] on user plane towards the
   home network.

   In some cases, IPv6-only visitors may help still be subject to address the issue SGSN
   capability in visited networks.  This becomes especially risky if
   there are 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 compatibility problems.  Those roaming friendly to enable the functions could be
   automatically enabled in an IPv6-only on SGSN/MME
   by default.  Otherwise, operators may consider steering the roaming
   traffic to the IPv6-enable visited network and disabled in a dual-
   stack or IPv4 network.

5.3. that has IPv6 roaming
   agreement.

4.3.  Case 3: Fallback Incapability

   3GPP specified Inappropriate Roaming APN Set

   If IPv6 single stack with the home routed mode is deployed, the
   requested PDP/PDN type IPv6 as early 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 to support PDP/PDN type IPv4.
   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 single should have no issues
   to pass through network attachment process, since 3GPP specified the
   PDP/PDN type has been well supported and
   interpretable in the 3GPP network nodes.  Roaming to IPv4-only
   networks and making an IPv6 as early as PDP/PDN request could guarantee that the
   subscription data is compatible with the visited pre-Release 9 SGSN. type IPv4.  When a subscriber visitor
   requests PDP/PDN type IPv6, the network should only return the
   expected IPv6 prefix.  The mobile device UE may fail to get an IPv6 prefix if the
   visited network only allocates an IPv4 address
   to the subscriber. address.  In that this case, the request
   visited network will be dropped reject the request and send the cause code should be sent to
   the user. UE.

   A proper fallback scheme for PDP/PDN type IPv6 is desirable, however
   there is no the behavior standard way to specify the 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 an 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
   implementation specific.  There are some mobile devices have offloaded locally
   (Section 2.1.2 ), the
   ability visited network may not be able to provide 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 different configuration
   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 failed .

   Translation-based methods, for home 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
   visited network respectively.  For instance, the Android system
   solves the issue by setting the roaming protocol to disabled in a dual-stack or IPv4 for
   network, therefore the
   Access Point Name(APN).  It guarantees that UE will always initiate
   an PDP/PDN type IPv4 applications only get the translation in
   the roaming area.

5.4.  Case 4: 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 single-stack IPv6-only connectivity environment.  The customer-side
   translator (CLAT) function on a mobile device is likely in
   conjunction with a PDP/PDN IPv6 type request and cooperates with a
   remote NAT64[RFC6146] gateway. NAT64 [RFC6146] device.

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

   In the local breakout approach approach, when a mobile device UE with the 464xlat function roams
   roaming to an IPv6 visited network without may encounter various situations.
   For example, the presence 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 or and DNS64,
   464xlat will fail can't perform successfully due to function.

   The issue has been found mostly the lack of PLAT
   collaboration.  Even in intra-PLMN mobility cases for the
   time being. 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
   the local breakout and use the home routed mode to perform 464xlat.  Some devices
   Alternatively, UE may support the configuration different roaming profile
   configurations to adopt 464xlat in the home networks and use
   IPv4-only in the visited
   networks with different roaming profile configurations.  This could
   also be a solution to address this issue. networks.

6.  HLR/HSS User Profile Setting

   A proper user profile configuration would provide a deterministic
   outcome to the PDP/PDN Creation 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's  It is also desirable that the network could set-up
   connectivity of any requested PDP/PDN context type.

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

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

                       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 is referred to Section 17.7.1 "Mobile
   Sevice
   Service date types" of [TS29.002].  User profile 1 profiles #1 and 2 #2 share the
   same contextId. "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.

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

                       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 profile 1 profiles #1 and 2 #2 share the same contextId. "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 testified that the major issues happened at two three stages, i.e.,
   the initial network attachment attachment, the PDP/PDN creation and service
   requests.

   In the IP allocation process.

   During stage of the initial network attach, attachment, PDP/PDN type IPv4v6 is the
   major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
   PDN
   PDP/PDN type IPv4v6 in the early release.  Such PDP/PDN type is
   supported in new-built EPS network, but didn't support well in the
   third generation network.  The situations may cause the roaming
   issues dropping with the attach request from dual-stack subscribers.
   Operators may have to adopt temporary solution solutions unless all the
   interworking nodes(i.e. nodes (i.e., the SSGN) in the visited network have been
   upgraded to support the ext-PDP-Type feature.

   In the stage of the PDP/PDN creation, PDP/PDN type IPv4v6 and IPv6 has good compatibility to
   support on the visited networks during SGSN is the network attachment. major concern.  It has been
   observed that IPv6 single stack with the home routed mode is a viable
   approach to deploy IPv6.  In
   order to support the IPv6-only visitors, SGSN/MME in  It is desirable the visited
   network is required to accept IPv6-only PDP/PDN activation requests
   and SGSN could
   enable IPv6 on the user plane towards by default.  For the home network.  In some
   cases, IPv6-only visitors may still be subject to PDP/PDN type
   IPv4v6 supporting, the SGSN capability
   in visited networks.  This becomes especially apparent if DAF is suggested to be set.  As a
   complementary function, the home
   operator performs implementation of roaming steering targeted APN
   configuration is useful to an operator that
   doesn't allow IPv6.  Therefore, it's expected that accommodate the visited network is
   IPv6 network.  However,
   it should consider roaming friendly architecture and permitted PDP/PDN type to enable the functions
   make proper setting on SGSN/MME by default.

   In the local breakout mode, the IP address is allocated by the
   visited GGSN or PGW.  The mismatch is found UE.  Roaming APN in the following aspects.

   o  The mismatch between home routed mode
   is recommended to align with home network profile setting.  In the requested
   local breakout case, PDP/PDN type and the permitted IPv4 could be selected as a safe
   way to initiate PDP/PDN type

   o  The mismatch between activation.

   In the application capability and allowed
      network connections

   o  The mismatch between mobile device function (e.g., 464xlat) and stage of service requests, the support for that function failure cases are mostly
   occurred in the local breakout case.  The visited network

   There are some solutions may not be
   able to overcome satisfy the issue.  Those requested capability from applications or UEs.
   Operators may consider to use home routed to avoid the risks.
   Several solutions can
   be made either in the network side or mobile device side.

   o  Change local breakout side
   can also help to address the home routed mode issue.  For example,

   o  A dedicated roaming APN profile is implemented for the roamer.
      When a subscriber roams to a visited network, PDP/PDN type IPv4 is
      to be always selected for session activation.  464xlat could help IPv4 applications access IPv6 visited networks.

   o  Networks could 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 Access-Request
      contains subscriber and visited network information, e.g.  PDP/PDN
      Type, International Mobile Equipment Id (IMEI), Software
      Version(SV) 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. 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, it 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 and Byrne,
   Holger Metschulat and Geir Egeland for their helpful discussions and
   comments.

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

11.  References

11.1.  Normative References

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

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

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.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.34]    Global System for Mobile Communications Association,
              GSMA., "Guidelines for IPX Provider networks", November
              2013.

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

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

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

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

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

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

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

   [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.002]
              3rd Generation Partnership Project, 3GPP., "Mobile
              Application Part (MAP) specification v9.12.0", December
              2009.

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

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