Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: January 5, February 4, 2015                                     D. Michaud
                                                   Rogers Communications
                                                             J. Korhonen
                                                          Renesas Mobile
                                                            M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                            July 4,
                                                          August 3, 2014

                     IPv6 Roaming Behavior Analysis
               draft-ietf-v6ops-ipv6-roaming-analysis-01
               draft-ietf-v6ops-ipv6-roaming-analysis-02

Abstract

   This document identifies a set of failure cases that may be
   encountered by an IPv6-enabled IPv6 mobile customers in roaming scenarios.
   The investigations on those failed cases reveal the causes in order
   to notice improper configurations, equipment's incomplete functions
   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, February 4, 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  . . . . . . . . . . . . . .   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.  HLR/HSS User Profile Setting  . . . . . . . . . . . . . . . .   9
   7.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10.  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13  15

1.  Introduction

   Many Mobile Operators have deployed IPv6, or are in a per-deployment stage of
   IPv6 about to, in their
   operational networks.  Customers will  A customer in such a network can be delivered with provided
   IPv6 connectivity if their User Equipment (UE) are 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]).  Dual-stack  Depending on network conditions either dual-stack or IPv6
   single-stack has been selected
   depending on network's conditions.  It 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 the inconsistent configurations and
   incomplete functions on functionality of equipment in the networks
   nodes.

   This memo intends network.

   A mobile subscriber roaming to document the observed failed cases different operator's network may
   experience service degradations or interruptions due to inconsistent
   configurations and analyze incomplete functions in the causes. visited network.

2.  Roaming Architecture Description

   The roaming process has been occurred

   Roaming occurs in the following several scenarios:

   o  International roaming: a mobile UE may entry enter a visited network,
      where a different Public Land Mobile Network (PLMN) identity is
      used.  The UEs 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 visited network as that different area of the
      Home Public Land Mobile Network (HPLMN).  However, the subscriber profiles
      profile may not be stored in the area.  Once the
      subscriber attached to the network,  To allow network
      attachment the subscriber subscribers profile should needs to be extracted downloaded from the
      home network for the network attachment. 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. 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.  Once  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 have been are shown at in the figure to illustrate, that 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

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

                         Figure 2: Local Breadkout Breakout

   In the home routed mode, subscribers will activate the subscriber's UE activates the PDP/PDN
   context and get an address from the home network.  All traffic would be is
   routed back to the home networks.  It's network.  This is likely most cases for to be the case
   international roaming of Internet data services to facilitate the
   charging process between the two operators. operators concerned.

   In the local breakout mode, the subscriber address will be is assigned
   from by the
   visited network.  The traffic flow is directly offloaded locally at a
   network node close to that device's point of attachment in the
   visited networks.  Therefore, 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 an operator network could
   might use local breakout mode in order to get more efficient traffic route.
   routing.  The local breakout mode could be also applied to an operators
   operator's alliance for international roaming of data service.  EU
   Roaming Regulation III[EU-Roaming-III] involves local breakout mode
   allowing european European subscribers roaming in european European 2G/3G networks can
   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).  As the consequence,  Consequently, the traffic would be steered to
      the visited network.  Those functions are normally deployed for
      the Intra-PLMN mobility cases.

   o  Operators could 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 Networks (VPLMNs).

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

   o  GSMA has defined RAVEL[IR.65] as the IMS international roaming
      architecture.  Local breakout mode has been adopted for the IMS
      roaming architecture.

3.  Roaming Scenario

   There are two

   Two stages happened occur when a subscriber roams to a visited network and
   intends to start data services.

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

   o  PDP/PDN context creation: it's occurred this occurs after the subsriber subscriber makes a sucessful
      successful attachment.  It's worth nothing that this  This stage is integrated with the
      attachment stage in the case of 4G, but is a
      seperated seperate process in
      2/3G. 3GPP specifies three types of Packet Data Protocol
      (PDP)/Packet Data Networks (PDN) to describe connections, i.e., i.e.
      PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6.
      When a subsriber subscriber creates a data session, a user their device is configured to request requests a
      particular PDP/PDN Type.  The allowed PDP/PDN types for the that
      subscriber are learned from in the attachment stage.  Hence, SGSN/MME
      could initiate PDP/PDN request to GGSN/PGW if the subscription
      profile is allowed.

   The failures are likely happened 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 capability. network.  The
   failures in the attachment stage is are independent with of home routed and or
   the local breakout mode, while most failure cases in the PDP/PDN
   context creation stage are appeared occur in the local breakout cases.  Section 4
   and 5 make further descriptions
   for describe each cases. case.  The below table lists the several cases regarding
   concerning the PDP/PDN creation stage.

   +-------------+-------------------+--------------+
   | 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 requesting request
   both IPv4 and IPv6 within a single PDP/PDN request.  This feature option is
   stored as a part of subscription data for a subscriber in the HLR/
   HSS.  PDP/PDN type IPv4v6 is has been introduced since at the inception of
   Evolved Packet System (EPS) in 4G network. networks.  The nodes in 4G networks
   should present no issues with the handling of this PDN type.
   However, it's
   of varing supports support varies in 2/3G networks denpending depending on Serving GPRS
   Support Node (SGSN) software version.  In theory, S4-SGSN (i.e., the (i.e. an
   SGSN with S4 interface) support supports the PDP/PDN type IPv4v6 since
   Release8 and a Gn-SGSN (i.e., (i.e. the SGSN with Gn interface) support 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 issue we observe is that
   multiple SGSNs will be unable to correctly process a subscriber subscriber's
   data received in the Insert Subscriber Data procedure[TS23.060]. Procedure[TS23.060].  As
   a consequence , consequence, it will likely refuse the subscriber attach request, which request.
   This is erroneous
   behaviour as they are behavior 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 initiates 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 document, e.g documents, e.g.  [IR.33], [IR.88]
   and [IR.21].  The  Such an agreement requires the visited operators operator to get
   the necessary patch on all their SGSN nodes to support PDP/PDN type
   IPv4v6.

   There

   As an alternative solution there are some specific implementation implementations
   (not standardised by 3GPP) in the HLS/HSS of the home network as
   an alternative solution.  Once network.  When
   the HLR/HSS receives an Update Location message from a visited SGSN
   known to not support the PDP type IPv4v6, only the subscription data with only
   PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber
   Data procedure.  It guarantee guarantees the user profile could is compatible with
   visited SGSN/MME capability.

5.  Failure Cases in PDP/PDN Creation

   Once

   When a subscriber succeed succeeds in the attach stage, the IP allocation
   process
   is taken takes place to allocate IP addresses to the subscriber.  This
   section has summarized 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 a single separate parallel single-stack IPv4 and
   IPv6 PDP/PDN is connections are allowed to be initiated to separately
   allocate IPv4 and IPv6 address separately. addresses.

   The below lists the cases. cases are listed below:

   o  The SGSN/MME returns Session Manamgement 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  The SGSN/MME does not set the Dual Address Bearer Flag due to because the
      operator using uses single addressing per bearer to support interworking
      with nodes of earlier releases

   A roaming subscriber subscriber's UE with IPv4v6 PDP/PDN type have has to change the
   request into two separated PDP/PDN requests with a single IP version
   in order to achieve equivalent results.  Some drawbacks in of this case
   are listed as following: below:

   o  The parallel PDP/PDN activations would likely double PDP/PDN
      resources consumptions.  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 lost lose the IPv6 connection in the visited network.  It's  It is even
      worse
      that it 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 and Charging
      Enforcement Function (PCEF) treat treats the IPv4 and IPv6 session as
      independent and perform 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 the a limitation of on allowed simultaneous
      PDP/PDN PDP/
      PDN activations.  Overmuch  Excessive PDP/PDN activation 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 address prefix and no IPv4 address returned.  It  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 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 with and making an IPv6 PDP/PDN request could 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 address. prefix.  The mobile device may be failed fail to get IP
   address
   an IPv6 prefix if the visited network only allocates an IPv4 address
   to a 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 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 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 PDP/
   PDN
   an PDP/PDN type IPv4 in the roaming area.

5.4.  Case 4: 464xlat Support

   464xlat[RFC6877] is proposed to address the IPv4 compatibility issue
   in a an IPv6 single-stack environment.  The function on a mobile terminal device
   is likely gets along in conjunction with a PDP/PDN IPv6 type request to cooperate and
   cooperates with 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.  When
   In the local breakout approach when a mobile device with 464xlat
   function roams to an IPv6 visited network without the presence of
   NAT64 or DNS64, 464xlat may get failed will fail to perform if
   traffic is undergoing the local breakout approach. function.

   The issue has been found mostly in a intra-PLMN mobility case cases for the
   time being.  Considering the various network's situations, operators
   may turn off the local breakout and take 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.  It  This could
   also be a solution to address this issue.

6.  HLR/HSS User Profile Setting

   A proper user profile configuration could provide deterministic
   network control of the connectivity requests from dual-stack,
   IPv4-only and IPv6-only devices.  It's desirable that the network
   could set-up proper connectivity for any type of the devices.The HLR/
   HSS may have to apply extra logic to achieve this.

   The following are examples to demonstrate the settings for the
   scenarios and decision criteria to apply when returning user profile
   information to 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
     ....
   }

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

   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
     ....
   }
   User profile 1 and 2 share the same contextId.  If a visited SGSN is
   identified as early as pre-Release 9, HLR/HSS should only send user
   profile#2 to visited SGSN.

7.  Discussions

   Several failure cases have been discussed in this document.  It has
   been testified that the major issues are occurred happened at the 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
   concern 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 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 SSGN)
   in the visited network have been upgraded to support the ext-PDP-Type
   feature.

   The issues in the IP address allocation process are caused due to the 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

   o  The mismatch between the application capability and allowed
      network connections

   o  The mismatch between mobile device function (e.g., 464xlat) and
      particular
      the support for that function in the vistited network deployment status

   There are some solutions to overcome the issue.  Those solutions can
   be done made either in the network side or mobile device side.  The below
   lists  There
   exist several 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 always
      to be always selected for session activation.

   o  Networks could deploy an AAA server to coordinate the mobile
      device capability.  Once the GGSN/PGW receive receives the session
      creation
      requests, request, it will initiate an Access-Request to an AAA
      server in the home land 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) and visited SGSN/MME location code, etc.  The AAA
      server could take mobile device capability combining 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.

8.  IANA Considerations

   This document makes no request of IANA.

8.

9.  Security Considerations

   Even if

   Although this document does not define 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.

9.

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 and Cameron Byrne for
   their helpful comments.

10.

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

11.  References

10.1.

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

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

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

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

   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