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]