Network Working Group G. Chen
Internet-Draft H. Deng
Intended status: Informational China Mobile
Expires: April 24, 2014 D. Michaud
Rogers Communications
J. Korhonen
Renesas Mobile
M. Boucadair
France Telecom
A. Vizdal
Deutsche Telekom AG
C. Byrne
T-Mobile USA
October 21, 2013
IPv6 Roaming Behavior Analysis
draft-chen-v6ops-ipv6-roaming-analysis-01
Abstract
This document intends to enumerate failure 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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen, et al. Expires April 24, 2014 [Page 1]
Internet-Draft ipv6-roaming October 2013
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 Descriptions . . . . . . . . . . . . . . 3
3. Roaming Scenario Overview . . . . . . . . . . . . . . . . . . 4
4. Failure Cases with Dual-stack Requests . . . . . . . . . . . 5
4.1. Failure Case 1: Roaming to IPv4-only networks . . . . . . 5
4.2. Failure Case 2: Roaming to early dual-stack networks . . 6
4.3. Failure Case 3: Roaming to IPv6-only networks . . . . . . 6
5. Failure Cases with IPv6-only Requests . . . . . . . . . . . . 6
5.1. Failure Case 4: Roaming to IPv4-only networks . . . . . . 6
5.2. Failure Case 5: Roaming to IPv6-only or dual-stack
networks with 464xlat . . . . . . . . . . . . . . . . . . 7
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
Chen, et al. Expires April 24, 2014 [Page 2]
Internet-Draft ipv6-roaming October 2013
analyze the causes. It's expected that operators could notice the
issues and prevent potential risks.
2. Roaming Architecture Descriptions
When a mobile device 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). There are two
cases related to the roaming behavior.
o International roaming: a mobile subscriber may entry a visited
network, where different PLMN identity is used. The subscribers
could either in an automatic mode or a manual mode to attach a
PLMN cell.
o Intra-PLMN mobility: a subscriber moves to a visited network as
that of the Home Public Land Mobile Network (HPLMN). However, the
subscriber profiles may not be stored in the area. Once the
subscriber attaches to the network, the subscriber profile should
be traced from the home network for the network registration.
When the visited network receives the registration requests from a
subscriber, it should contact the home network and request the
subscriber profile from Home Location Register(HLR) or Home
Subscriber Server (HSS). Once the registration process is completed,
the traffic flows may transmitted differently according to the
subscriber data configuration. Two modes have been shown in the
figure to illustrate the traffic flow paths, that are "Home routed
traffic" and "Local breakout".
+---------------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +--------+ | | +--------+ Traffic Flow
| | UE |==========>|SGSN/SGW|======================>|GGSN/PGW|============>
| +----+ +--------+ | Signa ling | +--------+ |
| |-------------------------->+--------+ |
| | | |HLR/HSS | |
| | | +--------+ |
+---------------------------------+ +------------------------+
Figure 1: Home Routed Traffic
In the home routed mode, subscribers will get addresses from the home
network. All traffic would be routed back to the home networks.
That is the default case for an international roaming except for IMS
cases.
Chen, et al. Expires April 24, 2014 [Page 3]
Internet-Draft ipv6-roaming October 2013
+---------------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |==========>|SGSN/SGW|---------------------->|HLR/HSS | |
| +----+ +--------+ | | +--------+ |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+-----------------------||--------+ +------------------------+
\/
Figure2: Local Breakout
In the local breakout mode, the subscriber address will be assigned
in the visited network. The traffic flow would directly offloaded
locally at a network node close to that device's point of attachment
in the visited networks. Therefore, more efficient route would be
achieved. There are several usages for the local breakout mode.
o Operators may add the APN-OI-Replacement flag[TS29.272] into
user's subscription-data. The visited network could indicate the
domain name to replace the user requested Access Point Name (APN).
As a consequence, the traffic would be steered to the visited
network. Those functions normally deployed for the Intra-PLMN
mobility cases.
o Operators could also configure VPLMN-Dynamic-Address-Allowed
flag[TS29.272] in the user profile to enable local breakout mode
in Visited Public Land Mobile Networks (VPLMNs).
o 3GPP specified Selected IP Traffic Offload (SIPTO)
function[TS23401] 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 IMS international roaming
architecture. Local breakout mode has been adopted for the
roaming architecture.
3. Roaming Scenario Overview
3GPP specified three types of Packet Data Protocol (PDP)/Packet Data
Networks (PDN) to describe each connection, i.e. IPv4 PDP/PDN, IPv6
PDP/PDN and IPv4v6 PDP/PDN. Those PDP/PDN types should also be
restored in Home Subscriber Server (HSS) as a part of subscriber
Chen, et al. Expires April 24, 2014 [Page 4]
Internet-Draft ipv6-roaming October 2013
profile. When a subscriber roams to a visited network, the new
visited network notices that it is not registered with its own
system, and attempts to identify its home network. Afterwards, the
visited network will contact the home network and request the
subscriber profile from HSS. In this process, service may be
provided in a home routed or local breakout mode. The IP address can
be allocated from home network or visited network accordingly. There
may be a mismatch between the subscriber request and network
capability. The following table lists the potential failure cases.
+-------------+-------------------+--------------+--------------+
| UE Request | Visited Network | Home routed |Local Breakout|
| | Capability | | |
+-------------+-------------------+--------------+--------------+
| Dual stack | IPv4-only |Failure case 1|Failure case 1|
+-------------+-------------------+--------------+--------------+
| Dual stack |IPv4-only/IPv6-only| OK |Failure case 2|
+-------------+-------------------+--------------+--------------+
| Dual stack | IPv6-only | OK |Failure case 3|
+-------------+-------------------+--------------+--------------+
| IPv6-only | IPv4-only | OK |Failure case 4|
+-------------+-------------------+--------------+--------------+
| IPv6-only | Dual stack | OK |Failure case 5|
| with 464xlat| | | |
+-------------+-------------------+--------------+--------------+
| IPv6-only | IPv6-only | OK |Failure case 5|
| with 464xlat| | | |
+-------------+-------------------+--------------+--------------+
| IPv4-only | Dual stack | OK | OK |
+-------------+-------------------+--------------+--------------+
Table 1: Roaming Scenario Descriptions
4. Failure Cases with Dual-stack Requests
4.1. Failure Case 1: Roaming to IPv4-only networks
A mobile host 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 Serving GPRS Support
Node(SGSN), Gateway GPRS Support Node(GGSN), Serving Gateway(SGW),
PDN Gateway(PGW), Home Location Registrar(HLR) and Home Subscriber
Server(HSS). 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. The visited pre-R9 SGSN don't
understand the IPv4v6 PDP attribute for dual-stack, thus it refuse
the subscriber registration. Resolving the issue may request the
deletion of a IPv4v6 PDP attribute in home HLR/HSS. That may
Chen, et al. Expires April 24, 2014 [Page 5]
Internet-Draft ipv6-roaming October 2013
restrict UEs only initiates IPv4 PDP or IPv6 PDP activation. As
alternative, operators have to upgrade the visited SGSN and SGW to
support the IPv4v6 feature. However, operator may didn't control the
visited nodes which belong to different operators.
4.2. Failure Case 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 separately. 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 Policy and Charging Rules Function(PCRF)/Policy and
Charging Enforcement Function (PCEF) deployed, the system would treat
IPv4 and IPv6 session as independent and perform different Quality of
Service(QoS) policies. The subscriber may have unstable experiences
due to different behaviors on each IP version connection.
4.3. Failure Case 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
returned. 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.
5. Failure Cases with IPv6-only Requests
5.1. Failure Case 4: 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
Chen, et al. Expires April 24, 2014 [Page 6]
Internet-Draft ipv6-roaming October 2013
desirable however the behavior is implementation specific. Android
system solves the issue by setting the roaming Access Point
Name(APN). 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 timely.
5.2. Failure Case 5: 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.
6. Discussions
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 Long Term Evolution(LTE)/System Architecture
Evolution(SAE) 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, a user profile with IPv4-only PDP or IPv6 only PDP may
temporarily get easy through roaming areas. Some operators may
choose IPv6 PDP/PDN along with 464xlat in the home network to advance
IPv6 deployment. 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. Therefore, there is no working solution other than IPv4
to guarantee roaming if roaming has to be enabled.
Chen, et al. Expires April 24, 2014 [Page 7]
Internet-Draft ipv6-roaming October 2013
In general, home routed is the default mode for international roaming
cases. Local breakout or SIPTO may be only considered for some
specific services, for example IMS roaming or intra-PLMN mobility
optimization. Therefore, the most roaming scenairos may take less
risks if the host only initiate IPv4 or IPv6 PDP/PDN other than
extended IPv4v6 PDP/PDN for the time being.
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations
The draft didn't introduce additional security concerns to the
networks.
9. Acknowledgements
The authors would like to thank V6ops chairs(Fred Baker and John
Brzozowski) to encourage us to continue the work. This document is
the result of the IETF V6ops IPv6-Roaming design team effort.
10. References
10.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.
Chen, et al. Expires April 24, 2014 [Page 8]
Internet-Draft ipv6-roaming October 2013
[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.
10.2. Informative References
[IR.65] , "IMS Roaming & Interworking Guidelines", May 2012.
[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.
[TS23401] , "General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", .
[TS29.272]
, "Mobility Management Entity (MME) and Serving GPRS
Support Node (SGSN) related interfaces based on Diameter
protocol", .
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: phdgang@gmail.com
Chen, et al. Expires April 24, 2014 [Page 9]
Internet-Draft ipv6-roaming October 2013
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui@chinamobile.com
Dave Michaud
Rogers Communications
Email: Michaud@rci.rogers.com
Jouni Korhonen
Renesas Mobile
Porkkalankatu 24
FIN-00180 Helsinki
Finland
Email: jouni.nospam@gmail.com
Mohamed Boucadair
France Telecom
No.32 Xuanwumen West Street
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 April 24, 2014 [Page 10]
Internet-Draft ipv6-roaming October 2013
Cameron Byrne
T-Mobile USA
Bellevue
Washington 98105
USA
Email: cameron.byrne@t-mobile.com
Chen, et al. Expires April 24, 2014 [Page 11]