Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis-01

GangChen <phdgang@gmail.com> Tue, 29 July 2014 02:29 UTC

Return-Path: <phdgang@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD721A0AFD for <v6ops@ietfa.amsl.com>; Mon, 28 Jul 2014 19:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usFypV8Impa2 for <v6ops@ietfa.amsl.com>; Mon, 28 Jul 2014 19:29:03 -0700 (PDT)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12FA1A0B05 for <v6ops@ietf.org>; Mon, 28 Jul 2014 19:29:02 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id k15so8703832qaq.24 for <v6ops@ietf.org>; Mon, 28 Jul 2014 19:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qHzHbSFYMtcN7qcMJ/2pIewdNyCWbBp0unDubVXcl08=; b=RzrnKRc4R7EI+TNoWInVWO2xUzwi+PiVXsWDcKO4Q372eKverT0rFN+asyH7QuBWcW /KQHqEt1WU1r4hd8R9yVyVRQVzVQ6PFMK/m64QRo+w9l79JtfPz3hEhgA9E7xedrIrmV KZqWCyEKnn9AQ0rz/UnQqEeSKsDv+26l2kJ9tLiBJnd0WumnyRDlb14oYdJg9VjeJUGb smuOuR+Fx8DihNWOivgJioM9B6dHzZlhX3ivAhAuKord7mLrO6bUiCL6DfHQmv4h4IHI FgOCX9okIweQIJCVGgVZ8OOxqDt8PKWwWv88u1x+kBtZx0DPSTO1oTjmNJd0zBOsPF5J MgQA==
MIME-Version: 1.0
X-Received: by 10.224.123.8 with SMTP id n8mr66260660qar.40.1406600941941; Mon, 28 Jul 2014 19:29:01 -0700 (PDT)
Received: by 10.224.46.10 with HTTP; Mon, 28 Jul 2014 19:29:01 -0700 (PDT)
In-Reply-To: <038E10C7-A2F1-4E63-9A32-48C8A3C1F3DC@eircom.net>
References: <038E10C7-A2F1-4E63-9A32-48C8A3C1F3DC@eircom.net>
Date: Tue, 29 Jul 2014 10:29:01 +0800
Message-ID: <CAM+vMEStCDnTqQdBisdKwpN2A2O+5nJeaY_1=aC=_SUPxMqG0g@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Ross Chandler <ross@eircom.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AhOIhOM5sl_fg2OF6VYkgCc_C_g
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2014 02:29:07 -0000

Thank you for the comments.

It's useful to improve the readability.

We will incorporate your comments in the next update.

BRs

Gang

2014-07-28 13:58 GMT+08:00, Ross Chandler <ross@eircom.net>:
>
> Hi All,
> I’m very interested in and supportive of this draft and have gone through
> the draft and made updates for nits (spelling errors, minor suggested,
> wording changes etc) as per Fred’s last call. Hopefully, you’ll find these
> useful.
>
> I work for eircom including the Mobile network of Meteor (in Ireland). We
> have begun the process of enabling IPv6 in our production network. At this
> stage we are limiting our plans to Android UEs that support 464xlat because
> of the possibility of encountering the issues mentioned in this draft.
>
> Best regards,
> Ross
>
>
>
> The whole draft with my changes is below. There are too many to enumerate,
> suggest you diff it.
>
>
>
>
> Network Working Group                                            G. Chen
> Internet-Draft                                                   H. Deng
> Intended status: Informational                              China Mobile
> Expires: January 5, 2015                                      D. Michaud
>                                                    Rogers Communications
>                                                              J. Korhonen
>                                                           Renesas Mobile
>                                                             M. Boucadair
>                                                           France Telecom
>                                                                A. Vizdal
>                                                      Deutsche Telekom AG
>                                                             July 4, 2014
>
>
>                      IPv6 Roaming Behavior Analysis
>                draft-ietf-v6ops-ipv6-roaming-analysis-01
>
> Abstract
>
>    This document identifies a set of failure cases that may be encountered
>    by IPv6-enabled Mobile customers in roaming scenarios.  The failure
>    causes include improper configuration, incomplete equipment
>    functionality or inconsistent IPv6 introduction strategy.
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on January 5, 2015.
>
> Copyright Notice
>
>    Copyright (c) 2014 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 1]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 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
>    2.  Roaming Architecture Description  . . . . . . . . . . . . . .   3
>    3.  Roaming Scenario  . . . . . . . . . . . . . . . . . . . . . .   5
>    4.  Failure Case in Attachment Stage  . . . . . . . . . . . . . .   6
>    5.  Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . .   7
>      5.1.  Case 1: Splitting Dual-stack Bearer . . . . . . . . . . .   7
>      5.2.  Case 2: Lack of IPv6 support in applications  . . . . . .   8
>      5.3.  Case 3: Fallback Incapability . . . . . . . . . . . . . .   8
>      5.4.  Case 4: 464xlat Support . . . . . . . . . . . . . . . . .   9
>    6.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   9
>    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
>    8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
>    9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
>    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
>      10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
>      10.2.  Informative References . . . . . . . . . . . . . . . . .  11
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13
>
> 1.  Introduction
>
>    Many Mobile operators either have already deployed IPv6 or are in a
>    pre-deployment stage of supporting IPv6 in their production 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 the solutions described in [TR23.975].
>    Depending on network conditions either dual-stack or single-stack
>    IPv6 is selected.
>
>    In production networks it has been observed that a mobile subscriber
>    roaming around a different operator’s areas may experience service
>    degradations or interruptions due to inconsistent configurations and
>    incomplete functionality of equipment in the network.
>
>    This memo intends to document the observed failed cases and analyze
>    the causes.
>
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 2]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
> 2.  Roaming Architecture Description
>
>    The roaming process occurs in the following scenarios:
>
>    o  International roaming: a mobile UE enters a visited network,
>       where a different Public Land Mobile Network (PLMN) identity is
>       used.  The UE could, either in an automatic mode or a manual mode,
>       attach to the visited PLMN.
>
>    o  Intra-PLMN mobility: a mobile UE moves to a different area of the
>       Home Public Land Mobile Network (HPLMN).  However, the
>       subscriber profile may not be stored in the area. To allow network
>       attachment the subscribers profile needs to be downloaded from the
>       home network area.
>
>    When a UE is turned on or is transferred via a handover to a visited
>    network, the mobile device will scan all radio channels and find
>    available Public Land Mobile Networks (PLMNs) to attach to. The
>    Serving GPRS Support Node (SGSN) or the Mobility Management Entity (MME)
>    in the visited networks must contact the Home Location Register(HLR) or
>    Home Subscriber Server(HSS) and obtain the subscriber profile.  After
>    the authentication and registration process 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 HLR or HSS.  Two modes are shown in the figure to illustrate,
>    these are “Home routed traffic” (Figure 1) and “Local breakout"
>    (Figure 2).
>
> +---------------------------------+             +------------------------+
> |Visited Network                  |             |Home Network            |
> |  +----+           +--------+    |             |    +--------+ Traffic
> Flow
> |  | UE
> |==========>|SGSN/MME|======================>|GGSN/PGW|============>
> |  +----+           +--------+    | Signaling   |    +--------+          |
> |                        |-------------------------->+--------+          |
> |                                 |             |    |HLR/HSS |          |
> |                                 |             |    +--------+          |
> +---------------------------------+             +------------------------+
>
>                        Figure 1: Home Routed Traffic
>
>
>
>
>
>
>
>
>
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 3]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
> +---------------------------------+             +------------------------+
> |Visited Network                  |             |Home Network            |
> |  +----+           +--------+    | Signaling   |    +--------+          |
> |  | UE |==========>|SGSN/MME|---------------------->|HLR/HSS |          |
> |  +----+           +--------+    |             |    +--------+          |
> |                       ||        |             |                        |
> |                   +--------+    |             |                        |
> |                   |GGSN/PGW|    |             |                        |
> |                   +--------+    |             |                        |
> |         Traffic Flow  ||        |             |                        |
> +-----------------------||--------+             +------------------------+
>                         \/
>
>                          Figure 2: Local Breakout
>
>    In the home routed mode, the subscriber's UE activates the PDP/PDN
>    context and get an address from the home network. All traffic is routed
>    back to the home network.  This is likely to be the case international
>    roaming of Internet data services to facilitate the charging process
>    between the two operators concerned.
>
>    In the local breakout mode, the subscriber address is assigned by the
>    visited network.  The traffic flow is offloaded locally at a network
>    node close to that device's point of attachment in the visited network.
>
>    Therefore, a more efficient route to the data service is achieved. 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 a operator network could use local breakout mode in order to get
>    more efficient traffic routing.  The local breakout mode could be also
>    applied to an operators alliance for international roaming of data
>    service. EU Roaming Regulation III [EU-Roaming-III] involves local
>    breakout mode for European subscribers roaming in European 2G/3G
>    networks to choose to have their Internet data routed directly to the
>    Internet from their current VPLMN. The following enumerates the more
>    specific configuration considerations.
>
>    o  Operators may add the APN-OI-Replacement flag defined in 3GPP
>       [TS29.272] into user's subscription-data.  The visited network
>       indicates a local domain name to replace the user requested Access
>       Point Name (APN).  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 profile to enable local breakout mode
>       in a Visited Public Land Mobile Network (VPLMN).
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 4]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    o  3GPP specified Selected IP Traffic Offload (SIPTO)
>       function [TS23.401] since Release 10 in order to get efficient
>       route paths.  It enables an operator to offload certain types of
>       traffic at a network node close to that device's point of
>       attachment to the access network.
>
>    o  GSMA has defined RAVEL [IR.65] as the IMS international roaming
>       architecture.  Local breakout mode has been adopted for the IMS
>       roaming architecture.
>
> 3.  Roaming Scenario
>
>    Two stages occur when a subscriber roams to a visited network and
>    intends to start data services.
>
>    o  Nework attachment: this occurs when the subscriber enters a
>       visited network.  During an attachment, the visited network should
>       authenticate the subsriber and make a location update to the
>       HSS/HLR in the home network of the subsriber.  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 subsriber makes
>       a sucessful attachment.  It is worth nothing that this stage is
>       integrated with the attachment stage in the case of 4G, but a
>       seperated process with 2/3G. 3GPP specifies three types of Packet
>       Data Protocol (PDP)/Packet Data Networks (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 from the attachment stage.
>       If their subscription profile allows it the SGSN/MME may initiate
>       a PDP/PDN request to the GGSN/PGW.
>
>    The failures are likely to occur in both stages due to an incompliant
>    implementation in the visited network or a mismatch between the
>    subscriber requested and the capability of the visited network. The
>    failures in the attachment stage are independent of the home routed or
>    the local breakout mode, while most failure cases in the PDP/PDN
>    context creation stage occur in the local breakout cases. Section 4
>    and 5 describe each case. The below table lists several cases
>    concerning the the PDP/PDN creation stage.
>
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 5]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    +-------------+-------------------+--------------+
>    | UE request  |  PDN/PDP IP Type  |Local breakout|
>    |             |     permitted     |              |
>    +-------------+-------------------+--------------+
>    | IPv4v6      |  IPv4 or IPv6     |Failure case 1|
>    +-------------+-------------------+--------------+
>    | IPv4v6      |      IPv6         |Failure case 2|
>    +-------------+-------------------+--------------+
>    | IPv6        |      IPv4         |Failure case 3|
>    +-------------+-------------------+--------------+
>    | IPv6        |       IPv6        |Failure case 4|
>    | with 464xlat|   without NAT64   |              |
>    +-------------+-------------------+--------------+
>
>                   Table 1: Roaming Scenario Descriptions
>
> 4.  Failure Case in Attachment Stage
>
>    3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request
>    both IPv4 and IPv6 within a single PDP/PDN request.  This option is
>    stored as a part of subscription data for a subscriber in the HLR/
>    HSS. PDP/PDN type IPv4v6 was introduced at the inception of
>    Evolved Packet System (EPS) in 4G networks.  The nodes in 4G networks
>    should have no issues with the handling of this PDN type.  However,
>    support varies in 2/3G networks denpending on Serving GPRS
>    Support Node (SGSN) software version.  In theory the S4-SGSN (i.e.
>    an SGSN with a 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
>    the rest of the ISD MAP message. The issue we observe is that multiple
>    SGSNs will be unable to correctly process a subscriber's data received
>    in the Insert Subscriber Data procedure[TS23.060]. As a consequence,
>    it will likely refuse the subscriber attach request. This is erroneous
>    behaviour due to the equipment not being 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.  In order to avoid this situation, operators
>    should make a comprehensive roaming agreement to support IPv6 and
>    ensure that it aligns with the GSMA documents, e.g [IR.33], [IR.88]
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 6]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    and [IR.21].  Such an agreement requires the visited operator to get
>    the necessary patch on all their SGSN nodes to support PDP/PDN type
>    IPv4v6.
>
>    As an alternative solution there are some specific implementations
>    (not standardised by 3GPP) in the HLS/HSS of the home network.
>    When the HLR/HSS receives an Update Location message from a visited
>    SGSN known to not support the PDP type IPv4v6, subscription data with
>    only PDP/PDN type IPv4 will be sent to that SGSN in the Insert
>    Subscriber Data procedure.  It guarantees the user profile is
>    compatible with visited SGSN/MME capability.
>
> 5.  Failure Cases in PDP/PDN Creation
>
>    When a subscriber succeeds in the attach stage, the IP allocation
>    process takes place to allocate IP addresses to the subscriber.  This
>    section summarizes several failures in the break-out cases.
>
> 5.1.  Case 1: Splitting Dual-stack Bearer
>
>    Dual-stack capability can be provided using separate PDP/PDN
>    activations.  That means only separate parallel single-stack IPv4
>    and IPv6 PDP/PDN connections are allowed to be initiated to separately
>    allocate IPv4 and IPv6 addresses.
>    The cases are listed below:
>
>    o  The SGSN/MME returns Session Manamgement (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  The SGSN/MME does not set the Dual Address Bearer Flag 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 type has to change the
>    request into two separated PDP/PDN requests with a single IP version in
>    order to achieve equivalent results.
>    Some drawbacks of this case are listed below:
>
>    o  The parallel PDP/PDN activations would likely double PDP/PDN
>       resources consumption.  It also impacts the capacity of GGSN/PGW,
>       since a certain amount of PDP/PDN activations are only allowed on
>       those nodes.
>
>    o  Some networks may only allow one PDP/PDN is alive for each
>       subscriber.  For example, 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.
>
>
> Chen, et al.             Expires January 5, 2015                [Page 7]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    o  Additional correlations between those two PDP/PDN contexts are
>       required on the charging system.
>
>    o  Policy and Charging Rules Function(PCRF)/Policy and Charging
>       Enforcement Function (PCEF) 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 activations.  Too many active PDP/PDN connections may result
> in
>       other unrelated services broken.
>
>    Operators may have to disable the local-break mode to avoid the
>    risks.  Another approach is to set a dedicated Access Point Name
>    (APN) profile to only request PDP/PDN type IPv4 in the roaming
>    network.
>
> 5.2.  Case 2: Lack of IPv6 support in applications
>
>    Some operators may adopt an IPv6-only configuration for the IMS service,
>    e.g.  Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite
>    (RCS)[RCC.07].  Since the IMS roaming architecture will offload all
>    traffic in the visited network, a dual-stack subscriber can only be
>    assigned with an IPv6 prefix and no IPv4 address returned. This
>    requires that all the IMS based applications should be IPv6 capable.
>    A translation-based method, for example Bump-in-the-host (BIH)[RFC6535]
>    or 464xlat [RFC6877] may help to address the issue if there are IPv6
>    compatibility problems.  Those functions could be automatically
>    enabled in an IPv6-only network and disabled in a dual-stack or IPv4
>    network.
>
> 5.3.  Case 3: Fallback Incapability
>
>    3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4.
>    Therefore, the IPv6 single PDP/PDN type has been well supported and
>    interpretable in the 3GPP network nodes.  Roaming to IPv4-only
>    networks and making a IPv6 PDP/PDN request should guarantee that the
>    subscription data is compatible with the visited pre-Release 9 SGSN.
>    When a subscriber requests PDP/PDN type IPv6, the network should only
>    return the expected IPv6 prefix.  The mobile device may fail to get
>    an IPv6 prefix if the visited network can only allocate an IPv4 address
>    to the subscriber.  In that case, the request will be dropped and the
>    cause code should be sent to the user.
>
>    A proper fallback is desirable, however the behavior is implementation
>    specific.  There are some mobile devices have the ability to provide
>    a different configuration for home network and visited network
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 8]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    respectively.  For instance, the Android system solves the issue by
>    setting the roaming protocol to IPv4 for the Access Point Name(APN).
>    It guarantees that UE will always initiate an PDP/PDN of type IPv4 in
>    the roaming area.
>
> 5.4.  Case 4: 464xlat Support
>
>    464xlat[RFC6877] is proposed to address the IPv4 compatibility issue
>    in a IPv6 single-stack environment.  The function on a mobile device
>    is likely in conjunction with a PDP/PDN IPv6 type request and requires
>    a remote NAT64 [RFC6146] gateway. 464xlat may use the mechanism
>    defined in [RFC7050] to automatically detect the presence of DNS64 and
>    to learn the IPv6 prefix used for protocol translation. In the local
>    breakout approach when a mobile device roams to an IPv6 visited network
>    without the presence of NAT64 or DNS64, 464xlat will fail to function.
>
>    The issue has been found mostly in a intra-PLMN mobility case for the
>    time being.  Considering the various network's situations, operators
>    may turn off the local breakout and use the home routed mode to perform
>    464xlat.  Some devices may support the configuration to adopt 464xlat
>    in the home networks and use IPv4-only in the visited networks with
>    different roaming profile configurations.  This could also be a
>    solution to address this issue.
>
> 6.  Discussions
>
>    Several failure cases have been discussed in this document.  It has
>    been testified that the major issues happened at two stages, i.e.,
>    the initial network attach and the IP allocation process.
>
>    During the initial network attach, PDP/PDN type IPv4v6 is the major
>    problem to the visited pre-Release 9 SGSN.  The dual-stack deployment
>    is recommended in most cases.  However, it may take some times in a
>    mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the
>    early release.  Such PDP/PDN type is supported in new-built EPS
>    network, but didn't support well in the third generation network.
>    The situations discussed may cause the roaming issues dropping with
>    the attach request from dual-stack subscribers.  Operators may have to
> adopt
>    temporary solution unless all the interworking nodes(i.e. the SSGNs) in
>    the visited network have been upgraded to support the ext-PDP-Type
>    feature.
>
>    The issues in the IP address allocation process are caused by a local
>    breakout policy.  Since the IP address is allocated by the visited
>    GGSN or PGW, the mismatch is found in the following aspects.
>
>    o  The mismatch between the requested PDP/PDN type and the permitted
>       PDP/PDN type
>
>
>
> Chen, et al.             Expires January 5, 2015                [Page 9]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    o  The mismatch between the application capability and allowed network
>       connections
>
>    o  The mismatch between mobile device function (e.g., 464xlat) and
>       the support for that function in the vistited network
>
>    There are some solutions to overcome the issue.  Those solutions can
>    be made either in the network side or mobile device side.  The below
>    lists potential workarounds.
>
>    o  Change local breakout to the home routed mode
>
>    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.
>
>    o  Networks could deploy a 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.
>
> 7.  IANA Considerations
>
>    This document makes no request of IANA.
>
> 8.  Security Considerations
>
>    This document does not define a new architecture nor a new
>    protocol, but it is encouraged to refer to [RFC6459] for a generic
>    discussion on IPv6-related security considerations.
>
> 9.  Acknowledgements
>
>    Many thanks to F.  Baker and J.  Brzozowski for their support.
>
>    This document is the result of the IETF v6ops IPv6-Roaming design
>    team effort.
>
>    The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
>    Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for
>    their helpful comments.
>
>
>
>
> Chen, et al.             Expires January 5, 2015               [Page 10]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
> 10.  References
>
> 10.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
>               Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
>               October 2010.
>
>    [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
>               NAT64: Network Address and Protocol Translation from IPv6
>               Clients to IPv4 Servers", RFC 6146, April 2011.
>
>    [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
>               Beijnum, "DNS64: DNS Extensions for Network Address
>               Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
>               April 2011.
>
>    [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
>               Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
>
>    [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
>               Combination of Stateful and Stateless Translation", RFC
>               6877, April 2013.
>
>    [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
>               the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
>               7050, November 2013.
>
> 10.2.  Informative References
>
>    [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.65]    Global System for Mobile Communications Association,
>               GSMA., "IMS Roaming & Interworking Guidelines", May 2012.
>
>
>
>
> Chen, et al.             Expires January 5, 2015               [Page 11]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    [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.
>
>    [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
>               Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
>               Partnership Project (3GPP) Evolved Packet System (EPS)",
>               RFC 6459, January 2012.
>
>    [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
>               Network", RFC 6586, April 2012.
>
>    [TR23.975]
>               3rd Generation Partnership Project, 3GPP., "IPv6 migration
>               guidelines", June 2011.
>
>    [TS23.060]
>               3rd Generation Partnership Project, 3GPP., "General Packet
>               Radio Service (GPRS); Service description; Stage 2 v9.00",
>               March 2009.
>
>    [TS23.401]
>               3rd Generation Partnership Project, 3GPP., "General Packet
>               Radio Service (GPRS) enhancements for Evolved Universal
>               Terrestrial Radio Access Network (E-UTRAN) access v9.00",
>               March 2009.
>
>    [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.
>
>
>
>
>
>
>
> Chen, et al.             Expires January 5, 2015               [Page 12]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    [TS29.002]
>               3rd Generation Partnership Project, 3GPP., "Mobile
>               Application Part (MAP) specification v9.00", December
>               2009.
>
>    [TS29.272]
>               3rd Generation Partnership Project, 3GPP., "Mobility
>               Management Entity (MME) and Serving GPRS Support Node
>               (SGSN) related interfaces based on Diameter protocol
>               v9.00", September 2009.
>
> Authors' Addresses
>
>    Gang Chen
>    China Mobile
>    53A,Xibianmennei Ave.,
>    Xuanwu District,
>    Beijing  100053
>    China
>
>    Email: phdgang@gmail.com
>
>
>    Hui Deng
>    China Mobile
>    53A,Xibianmennei Ave.,
>    Xuanwu District,
>    Beijing  100053
>    China
>
>    Email: denghui@chinamobile.com
>
>
>    Dave Michaud
>    Rogers Communications
>    8200 Dixie Rd.
>    Brampton, ON L6T 0C1
>    Canada
>
>    Email: dave.michaud@rci.rogers.com
>
>
>    Jouni Korhonen
>    Renesas Mobile
>    Porkkalankatu 24
>    FIN-00180 Helsinki, Finland
>
>    Email: jouni.nospam@gmail.com
>
>
>
> Chen, et al.             Expires January 5, 2015               [Page 13]
>
>
> Internet-Draft            IPv6 Roaming Analysis                July 2014
>
>
>    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 January 5, 2015               [Page 14]