IPv6 Roaming Behavior Analysis
draft-chen-v6ops-ipv6-roaming-analysis-00

Network Working Group                                            G. Chen
Internet-Draft                                                   H. Deng
Intended status: Informational                              China Mobile
Expires: January 09, 2014                                  July 08, 2013

                     IPv6 Roaming Behavior Analysis
               draft-chen-v6ops-ipv6-roaming-analysis-00

Abstract

   This document intends to enumerate failed cases when a IPv6
   subscriber roams into visited network areas.  The investigations on
   those failed cases reveal the causes in order to notice improper
   configurations, equipment's incomplete functions or inconsistent IPv6
   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 09, 2014.

Copyright Notice

   Copyright (c) 2013 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.

Chen & Deng             Expires January 09, 2014                [Page 1]
Internet-Draft                ipv6-roaming                     July 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Roaming Descriptions  . . . . . . . . . . . . . . . . . . . .   2
   3.  Roaming Behaviors from a Dual-stack Network . . . . . . . . .   3
     3.1.  Roaming to IPv4-only networks with IPv4v6 requests  . . .   3
     3.2.  Roaming to early dual-stack networks  . . . . . . . . . .   3
     3.3.  Roaming to IPv6-only networks . . . . . . . . . . . . . .   4
   4.  Roaming Behaviors from a IPv6 Single-stack Network  . . . . .   4
     4.1.  Roaming to IPv4-only networks . . . . . . . . . . . . . .   4
     4.2.  Roaming to IPv6-only or dual-stack networks with 464xlat    4
   5.  Discussions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   IPv6 has been deployed globally to overcome the IPv4 depletion.
   Operators likely start or plan to upgrade the networks that allow
   IPv6 subscribers to access.  As the dramatical uses of Internet
   services with a mobile access, IPv6 is an essential part to be
   considered in the mobile network evolution. 3rd Generation
   Partnership Project (3GPP) published the IPv6 migration guidance
   [TR23.975], which describes different technical evolution paths.  In
   general, operators may deploy dual-stack or IPv6 single-stack
   depending on network's conditions.  It has been observed that those
   deployments are rolled out in multiple provisioning domains.  In the
   early IPv6 stage, a mobile subscriber roaming around the different
   areas may experience service degradations or interruptions due to the
   inconsistent configurations and incomplete functions in the networks
   nodes.  This memo intends to document the observed failed cases and
   analyze the causes.  It's expected that operators could notice the
   issues and prevent potential risks.

2.  Roaming Descriptions

   A mobile subscriber likely entries some network areas, that may be
   dual-tack, IPv6 single-stack and IPv4 single-stack.  The mobile
   terminal connecting to the network is formulated with a subscriber
   profile. 3GPP specified three type of Packet Data Protocol (PDP)/
   Packet Data Networks (PDN) to describe each connection.  That are
   IPv4 PDP/PDN, IPv6 PDP/PDN and IPv4v6 PDP/PDN.  Therein, the IPv4 and
   IPv6 PDP/PDN has been implemented at the early equipments.  IPv4v6 is
   only supported by Post-Release 8 equipments, which equip the feature

Chen & Deng             Expires January 09, 2014                [Page 2]
Internet-Draft                ipv6-roaming                     July 2013

   just in recent years.  Those PDP/PDN types should also be restored in
   Home Subscriber Server (HSS) as a part of subscriber profile.  When
   the mobile device is turned on or is transferred via a handover to
   the network, this new visited network sees the device, notices that
   it is not registered with its own system, and attempts to identify
   its home network.  Afterwards, the visited network would contact the
   home network and request the subscriber profile from HSS.  Since the
   visited network has different IPv6 supports, there may be a mismatch
   between the subscriber requires and network capability.  The
   following is like to document the failure cases.

3.  Roaming Behaviors from a Dual-stack Network

3.1.  Roaming to IPv4-only networks with IPv4v6 requests

   A mobile subscriber in a dual-stack network likely requests PDP/PDN
   type IPv4v6 to allocate address.  Such PDP/PDN type should be
   understandable in the network nodes, including SGSN(Serving GPRS
   Support Node), GGSN(Gateway GPRS Support Node), SGW(Serving Gateway),
   PGW(PDN Gateway), HLR(Home Location Registrar) and HSS(Home
   Subscriber Server).  When the subscriber roams to the IPv4 network,
   the visited SGSN or SGW has to communicate with HLR/HSS in the home
   land to retrieve the subscriber profile.  Roaming with IPv4v6 type in
   the subscriber profile may cause issues because the visited SGSN/SGW
   can't parse the information.  The subscriber is failed to register in
   this case.

3.2.  Roaming to early dual-stack networks

   Dual-stack capability can be provided in a early mobile network(i.e.
   Pre-Release 8 network) using separate PDP/PDN activations.  That
   means a single IPv4 and IPv6 PDP/PDN to be initiated to allocate IPv4
   and IPv6 address respectively.  A roaming subscriber with IPv4v6 PDP/
   PDN type should change the request to two separated PDP/PDN messages
   of single IP version in order to achieve equivalent results.  Some
   operators may turn off the function only allow one PDP/PDN is alive
   for each subscriber.  For example, IPv6 PDP/PDN would be rejected if
   the subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
   may lost IPv6 connection in the visited network.  Even the two
   parallel PDP/PDN activations are allowed, it will double the
   investment of core networks.  It requires additional correlation of
   those two sessions of single IP version on the charging system.  If
   there are PCRF(Policy and Charging Rules Function)/PCEF(Policy and
   Charging Enforcement Function) deployed, the system would treat IPv4
   and IPv6 session as independent and perform different QoS (Quality of
   Service) policies.  The subscriber may have unstable experiences due
   to different behaviors on each IP version connection.

Chen & Deng             Expires January 09, 2014                [Page 3]
Internet-Draft                ipv6-roaming                     July 2013

3.3.  Roaming to IPv6-only networks

   If the visited network is only IPv6 capable, a dual-stack subscriber
   can be assigned with IPv6 address.  There is no IPv4 address retured.
   Several IPv4 applications can't work in this case as reported in
   [RFC6586].  A translation-based method, for example Bump-in-the-host
   (BIH)[RFC6535] and 464xlat[RFC6877] , may help to address the issue.
   Those techniques are superior in a IPv6 single-stack environment.
   Operators may automatically enable the function in a IPv6-only
   network and disable in a dual-stack or IPv4 network.

4.  Roaming Behaviors from a IPv6 Single-stack Network

4.1.  Roaming to IPv4-only networks

   3GPP specified the PDP/PDN type IPv6 as early as IPv4 type.
   Therefore, the IPv6 single PDP/PDN type has been well supported and
   interpretable in the 3GPP network nodes.  When a subscriber requests
   IPv6 PDP/PDN type, the network should only return the expected IPv6
   address.  Otherwise, the request should be dropped and the error code
   should be sent to the user.  Roaming to IPv4-only networks with IPv6
   PDP/PDN request would fail to get addresses.  A proper fallback is
   desirable however the behavior is implementation specific.  Android
   system solves the issue by setting the roaming APN(Access Point
   Name).  The mobile terminal is allowed to ignore the original
   requested protocol and always adhere to IPv4 when roaming.  Those
   fallback mechanisms are deserved to be implemented and standardized
   timely.

4.2.  Roaming to IPv6-only or dual-stack networks with 464xlat

   464xlat[RFC6877] is proposed to address IPv4 compability issue in a
   IPv6 single-stack environment.  The function on a mobile terminal
   likely gets along with PDP/PDN IPv6 type request to cooperate with a
   remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined
   in [I-D.ietf-behave-nat64-discovery-heuristic] to automatically
   discover NAT64 prefixes.  Those behaviors depend on the network
   deployment, which may has three possibilities, i.e. DNS64/NAT64,
   NAT64 and non-NAT64.  In those cases, the mobile terminal could only
   use DNS64[RFC6147] to detect the existence of NAT64.  The alternative
   way is to manually configure the NAT64 prefix or Well-Known Prefix
   (i.e. 64:ff9b::/96)[RFC6052].  However, those configurations may
   mismatch the status of visited networks.  Considering the various
   network's situations, operators may adopt 464xlat in the home
   networks and use IPv4-only in the roaming networks.

5.  Discussions

Chen & Deng             Expires January 09, 2014                [Page 4]
Internet-Draft                ipv6-roaming                     July 2013

   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 LTE(Long Term Evolution)/SAE(System Architecture
   Evolution) network, but didn't support well in the third generation
   network.  The situations may cause the roaming issues dropping the
   attachment from dual-stack subscribers in the case of LTE to 3G and
   IPv6-enabled 3G to IPv4 3G.  It may be unsolvable unless all the
   interworking nodes(i.e. SSGN and SGW) have been upgraded to support
   IPv4v6 PDP/PDN type.

   Conversely, some operators may choose IPv6 PDP/PDN to start the
   communications in home networks and always use IPv4 in the roaming
   area.  Since IPv6 PDP/PDN has been introduced in 3GPP early release,
   it didn't require upgrading on the interworking nodes to parse such
   IPv6 PDP/PDN type.  But it requires IPv4 fallback should be supported
   either on the mobile terminal or network equipments.  It may be a
   workable solution given some terminals already support the function.

   As an alternative solution for dual-stack, operators may change a
   unified PDP/PDN request into two separated single IP version
   requests.  However, this approach is problematic in the Charging
   records and QoS policy enforcement.  In addition, it doubles the PDP
   resource uses.  It may be unappealing for the deployment.

   A roaming to IPv6-only network occurs when operators deploy IPv6
   single-stack networks.  A dual-stack terminal maybe like to
   experience the IPv6-single service in the visited network while it
   may only use IPv4 PDP/PDN type in the home network.  For those
   requests, a dual-stack terminal is recommended to populate
   translation-based function to enable the IPv4 service compatibility.
   Those functions should be turned off properly when the terminals roam
   back to dual-stack or IPv4 network.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   The draft didn't introduce additional security concerns to the
   networks.

Chen & Deng             Expires January 09, 2014                [Page 5]
Internet-Draft                ipv6-roaming                     July 2013

8.  References

8.1.  Normative References

   [I-D.ietf-behave-nat64-discovery-heuristic]
              Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
              ietf-behave-nat64-discovery-heuristic-17 (work in
              progress), April 2013.

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

8.2.  Informative References

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [TR23.975]
              3GPP, "IPv6 migration guidelines", June 2011.

Authors' Addresses

Chen & Deng             Expires January 09, 2014                [Page 6]
Internet-Draft                ipv6-roaming                     July 2013

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: phdgang@gmail.com

   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui@chinamobile.com

Chen & Deng             Expires January 09, 2014                [Page 7]