Internet Engineering Task Force C. Zhou, Ed.
Internet-Draft T. Taylor
Intended status: Informational Huawei Technologies
Expires: March 21, 2011 September 17, 2010
IPv6 Transition Use Case For a Large Mobile Network
draft-zhou-v4v6tran-mobile-use-case-00
Abstract
This document describes an use case for migrating from IPv4 to IPv6
in a very large mobile network. Its purpose is to enhance general
understanding of the challenges associated with the migration of such
a network to IPv6 operation.
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 March 21, 2011.
Copyright Notice
Copyright (c) 2010 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.
Zhou & Taylor Expires March 21, 2011 [Page 1]
Internet-Draft Mobile Use Case September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of the Mobile Network Architecture . . . . . . . . . 3
3. Approaches To IPv4 / IPv6 Coexistence . . . . . . . . . . . . 6
3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity
With Limited Public IPv4 Address Pools . . . . . . . . . . 7
3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity
With Limited Private IPv4 Address Pools . . . . . . . . . 7
3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only
Transport and Applications Using IPv6 . . . . . . . . . . 8
3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running
On a Dual-Stack Host With an Assigned IPv6 Prefix and
a Shared IPv4 Address . . . . . . . . . . . . . . . . . . 8
4. Consideration of IPv4 / IPv6 Coexistence Solutions . . . . . . 8
4.1. Gateway-Initiated Dual-Stack Lite . . . . . . . . . . . . 8
4.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhou & Taylor Expires March 21, 2011 [Page 2]
Internet-Draft Mobile Use Case September 2010
1. Introduction
Consider a major mobile network operator, with hundreds of millions
of subscribers, currently growing at a rate in the order of 1% per
month. To assure continued revenue growth as market penetration
approaches its limit, the operator has been deploying 3GPP
technology. Currently about 1.5 percent of the operator's
subscribers use the third and fourth generation technology discussed
in this document.
The operator is looking to mobile data services for future revenue
gains. Mobile data services currently include mobile payments, music
downloads, mobile reading (book downloads), streaming and broadcast
video, and internet search services in partnership with content
providers such as news agencies. By their nature, these services
require communication between the mobile subscriber and a third party
application or content provider. Given the importance of these third
parties to the operator's business, the operator's IPv6 transition
plans have to ensure continuity of service to the third party servers
regardless of the IP version they run.
At the subscriber end, mobile handsets are typically replaced within
two to three years after purchase, apparently putting an upper limit
on how long it will take to make IPv6 the preferred protocol for the
majority of subscribers. However, in some markets the most popular
use of mobile data access is to provide access for personal computers
attached to the mobile terminal. This means the transition period at
the subscriber end depends to an important extent on the rate at
which personal computer operating systems and applications evolve to
support IPv6.
As a further complication for the migration to IPv6, the operator is
facing a major upgrade of its access networks from the older 3GPP
technology to LTE ("Long Term Evolution"). LTE flattens out the
access network by bringing the IP edge closer to the user equipment.
LTE will provide higher data rates, opening up the possibilities for
improved services and increased revenue from them.
1.1. Requirements Language
This document is descriptive, and as such, contains no requirements
language.
2. Overview of the Mobile Network Architecture
3GPP has specified layer 2 access for IPv6 in the legacy 3GPP
architecture and in the LTE ("Long Term Evolution") version. The
Zhou & Taylor Expires March 21, 2011 [Page 3]
Internet-Draft Mobile Use Case September 2010
third generation architecture is shown in Figure 1. Only the user
data paths are shown. The IP edge (of the core IP network) is
located at the GGSN (Gateway GPRS Support Node, where GPRS itself
stands for General Packet Radio Service). Within this system, IPv6
support requires separate bearers (i.e., links) for IPv4 and IPv6
respectively, extending from the User Equipment through the radio
network and the SGSN (Serving GPRS Support Node, at which the User
Equipment is registered) and, finally, to the GGSN.
The bearers are actually propagated from the SGSN to the GGSN
using GTP-U, a 3GPP-specified tunneling protocol running over IP.
The IP addresses assigned to the SGSN and GGSN for this purpose
are not visible to the mobile station. The SGSN locates the GGSN
using a DNS service that is also not visible to the User
Equipment.
+-----+
| |
| HSS |
| |
+-----+
IPv4 link +--------------+
/ | |
+----+ / +-----+ +------+ +------+ |
| |....| |....| |.......| | Core |
| UE | L2 | RAN | L2 | SGSN | \ | GGSN | IP |
| |....| |....| |....\..| | Network |
+----+ \ +-----+ +------+ \ \ +------+ |
\ \ \ | |
IPv6 link \ \ +--------------+
Links tunnelled
over GTP-U over IP
UE = User Equipment
RAN = Radio access network
SGSN = Serving GPRS Support Node
GGSN = Gateway GPRS Support Node
HSS = Home Subscriber Server (holds subscriber profile)
GTP = GPRS Tunneling Protocol
Figure 1: Third Generation GPRS Mobile Access Network
The use of IPv4 and/or IPv6 is controlled by the combination of
subscriber profile and core operator preference. Address allocation
to the User Equipment (UE) differs between IPv4 and IPv6. For IPv4,
addresses can be assigned in a number of ways. From the point of
view of the UE, the choice is between allocation during bearer
Zhou & Taylor Expires March 21, 2011 [Page 4]
Internet-Draft Mobile Use Case September 2010
activation vs. DHCPv4 exchanges with the core network following
bearer activation. From the point of view of the network, the
choices are between static and dynamic address allocation. For
dynamic allocation, the choice is between:
o allocation by the access network (with the GGSN responsible for
managing the address pool);
o allocation by the core network (with the GGSN acting as DHCPv4 or
RADIUS client and passing the configuration data on to the UE
during bearer setup; or
o via DHCPv4 to the UE after bearer setup, as already mentioned.
IPv6 prefix allocation is done by stateless address autoconfiguration
(SLAAC), with the GGSN responsible for sending Router Announcements
in response to the UE's Router Solicitation. For further details see
Sections 9.2.1 and 9.2.1.1 of [3GPP_TR_23_060].
The fourth generation mobile access architecture is described in
[3GPP_TR_23_401] and [3GPP_TR_23_402] and shown in Figure 2. The
SGSN has been split into a control part, the Mobile Management Entity
(MME), and a forwarding part, the Serving Gateway (SGW). The GGSN
has been replaced by the Packet Data Network Gateway (PDN Gateway, or
PGW).
The user data path to the core network changes in several ways with
LTE. First, it becomes possible to carry both IPv4 and IPv6 over the
same bearer. Thus the figure shows only a single link from the User
Equipment to the PDN Gateway. The second change is that the layer 2
protocol used in the third generation architecture to carry the link
between the edge of the Radio Access Network and the SGSN is replaced
by a tunnel over IP, the same protocol stack (User packets/GTP-
U/IP/...) used between the SGSN and the GGSN. Finally, the operator
has the option to use PMIPv6 [RFC5213] instead of GTP-U tunneling
between the SGW and the PDN Gateway. The SGW acts in the role of
Mobility Access Gateway (MAG), while the PDN Gateway acts in the role
of Local Mobility Anchor (LMA). PMIP is used only when the core IP
network to which the UE is connected has the same operator as the
access network.
Zhou & Taylor Expires March 21, 2011 [Page 5]
Internet-Draft Mobile Use Case September 2010
+--------+
| HSS |
+--------+ +---------+
| PCRF |
+---------+ +---------+
| MME |
+---------+ +------------+
| |
+----+ +------ +-----+ +-----+ Core |
| UE |.....| RAN |.....| SGW |.....| PGW | IP |
+----+ +-----+ +-----+ +-----+ Network |
| |
+------------+
UE = User Equipment
RAN = Radio Access Network
SGW = Serving Gateway
PGW = Packet Data Network (PDN) Gateway
MME = Mobility Management Entity
PCRF = Policy and Charging Rules Function
HSS = Home Subscriber Server
Figure 2: Long Term Evolution (LTE) Mobile Access Network
Essentially the same options are available in LTE for address
configuration of the User Equipment, except that the PDN Gateway
replaces the GGSN as the entity responsible for obtaining and
propagating that information.
To ease the upgrade from third generation access to LTE, it is
possible to mix equipment types in the same access network. Traffic
from the SGSN is forwarded to the SGW, which relays it to the PDN.
If the Radio Access Network control is upgraded to use GTP tunneling,
it is possible to tunnel traffic directly between the Radio Access
Network and the SGW. The SGSN retains a control function. The final
step is to replace the SGSN by an MME to carry out the control
function.
To achieve service continuity during handover, legacy mobile devices
support MIPv4 [RFC3344]. The GGSN provides the Foreign Agent
functionality. More recent devices support DSMIPv6 [RFC5555].
DSMIPv6 assumes that both the UE and the Home Agent are dual-stack.
3. Approaches To IPv4 / IPv6 Coexistence
This section discusses the coexistence of user-plane IPv4 and IPv6
traffic. The operator is also faced with the upgrade of the network
equipment to use IPv6 for control signalling and for the IP wrapper
Zhou & Taylor Expires March 21, 2011 [Page 6]
Internet-Draft Mobile Use Case September 2010
for PMIP and GTP-U tunnels carrying user data. This upgrade can
proceed independently of the work on user-plane traffic, but presents
its own coexistence problem. In the immediate case this is because
it will take time to reconfigure all of the equipment in one network.
Over the longer term the problem arises because different networks
will upgrade at different times, and they must interoperate to
support mobile roaming in the meantime.
3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity With Limited
Public IPv4 Address Pools
In this IPv6 transition scenario, the UEs operate in dual stack mode
and are assigned both an IPv6 prefix and an IPv4 address in order to
allow them to utilise both IPv4- and IPv6-capable applications.
Dual-stack UEs are able to support parallel IPv4 and IPv6
connectivity to a single PDN. As popular services start to support
IPv6, IPv4 traffic will gradually be offloaded into the IPv6 domain.
Services owned and deployed by the operator may be IPv6-enabled first
(while retaining IPv4 capability) and hence will be accessible to
dual-stack capable MSs running IPv6.
Issue: In dual stack mode, every UE still needs an IPv4 address. As
the number of subscribers grows, the lack of additional public IPv4
addresses will force the use of private rather than public IPv4
addresses for some UEs. Aside from anything else, this will
complicate the operation of mobile IP.
3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity With Limited
Private IPv4 Address Pools
In this scenario, UEs operate in dual stack mode and are assigned
both an IPv6 prefix and a private IPv4 address in order to allow them
to utilise both IPv4- and IPv6-capable applications. The IPv4
addresses assigned to UEs are taken from one of the private address
ranges specified in RFC 1918. NAT is performed on the interface
between the PDN Gateway and the core IP network.
Issue : The number of private IP addresses is limited. If more than
16 million UEs are active in the same network simultaneously, the
network could run out of private IPv4 addresses to assign.
The problem could be worse than this, depending on how many
addresses are temporarily unused because they haven`t been
reclaimed after the UE roamed out of the network or shut down.
Zhou & Taylor Expires March 21, 2011 [Page 7]
Internet-Draft Mobile Use Case September 2010
3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only Transport and
Applications Using IPv6
In this scenario, the operator decides to assign only IPv6 prefixes
to the UEs due to, e.g., shortage of IPv4 addresses or because the
UEs support only IPv6.
Issue: UEs with IPv6-only connectivity running applications using
IPv6 should be able to access both IPv4- or IPv6-enabled services.
NAT64 and DNS64 should be performed to let the IPv6-only UEs have
access to IPv4 services.
3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running On a Dual-
Stack Host With an Assigned IPv6 Prefix and a Shared IPv4 Address
In this scenario an IPv4 application running on a dual-stack UE needs
to access IPv4 services without the operator having to allocate a
unique non-shared (private or public) IPv4 address to the UE. The
dual-stack UE running these applications uses an IPv4 address that is
shared amongst many other UEs, and uses an IPv6 prefix.
Issue: The obvious issue arises, that IPv4 services need to be able
to distinguish between UEs using the same IPv4 address. The source
port may be used for this purpose.
4. Consideration of IPv4 / IPv6 Coexistence Solutions
The different strategies described above require support to make them
work.
4.1. Gateway-Initiated Dual-Stack Lite
Dual-stack lite (DS-lite) [I-D.softwire-dual-stack-lite-06]
transports IPv4 traffic from the user device in an IPv6 tunnel across
an IPv6 provider network to a NAT44, where sharing of IPv4 public
addresses can be implemented. To prevent user DNS queries from going
through the NAT44, all queries are intercepted and sent to an IPv6
DNS server. Gateway-initiated DS-lite
[I-D.softwire-gateway-init-ds-lite-00] makes explicit use of the
tunnel set up through the access network to carry user packets to the
IP network. The gateway at the IP end of this tunnel maintains a
single tunnel between itself and the NAT44, to which it forwards
packets from all of the user devices connected to it. The inner
source IP address of the individual packets is actually a 32-bit
context identifier used with other information to retrieve forwarding
state at the gateway and the NAT44. Gateway-initiated DS-lite also
reduces or in some configurations eliminates the need for a unique
Zhou & Taylor Expires March 21, 2011 [Page 8]
Internet-Draft Mobile Use Case September 2010
IPv4 address, public or private, at the UE.
As applied to the architectures described in Section 2, the gateway
is represented by the PDN Gateway or GGSN. The NAT44 is located
beyond the gateway, in the core IP network. The access tunnels are
GTP over IP, and indeed the tunnel IP version may be either IPv4 or
IPv6 without affecting the operation of gateway-initiated DS lite.
Section 5.6.1.2 of [3GPP_TR_23_060] suggests that GTP tunnels run
between the core nodes too, so the core network may run IPv4 or IPv6
independently of what is used in the access network.
By making the IPv4 address provisioned at the UE almost irrelevant,
gateway-initiated DS-lite supports any of the strategies described in
Section 3 except the all-IPv6 approach. One issue is that, at the
beginning when most traffic is IPv4, a large investment in NAT44
capacity will be needed. As traffic migrates to IPv6, this
investment becomes stranded and not reusable. Another issue is that
all IPv4 traffic suffers the quality of service penalty imposed by
the use of NAT.
One issue that has to be resolved is how to handle DNS queries for
IPv4 addresses. [I-D.softwire-dual-stack-lite-06] requires that all
DNS queries be sent to an IPv6 DNS server. Discussion on the
softwires list leading up to this suggested that from there, A record
requests could be forwarded to an IPv4 server. Alternatively, the
IPv6 server could maintain both AAAA and A records. A third
possibility was that the address of an IPv4 DNS server could be
configured manually at the UE. This is messy, both on grounds of
operational cost and because it would push DNS queries through the
NAT44, greatly increasing its workload.
4.2. Protocol Translation
NAT-PT was first described in [RFC2766]. [RFC4966] summarized a
number of issues identified with NAT-PT in the intervening years. As
a result, [RFC2766] was deprecated and given Historic status.
The IETF has made a new attempt at solving the problem.
[ID_v6v4_framework] explores a number of different translation
scenarios. Any particular application must identify which of the
scenarios it is dealing with before it can choose stateless versus
stateful translation.
[ID_IVI] reports on an early implementation of stateless translation,
operating in the two directions between an IPv6 network and the IPv4
Internet. This has been deployed in the China Education and Research
Network (CERNET). IVI predates the official IETF work in this area,
references to which are given both in [ID_v6v4_framework] and
Zhou & Taylor Expires March 21, 2011 [Page 9]
Internet-Draft Mobile Use Case September 2010
[ID_IVI].
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This memo does not in itself introduce any security issues.
7. informative References
[3GPP_TR_23_060]
3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS); Service description; Stage 2
(Release 9)", TR 23.060, June 2010.
[3GPP_TR_23_401]
3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access (Release 9)", TR 23.401, March 2010.
[3GPP_TR_23_402]
3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects;
Architecture enhancements for non-3GPP accesses (Release
9)", TR 23.402, June 2010.
[I-D.huang-behave-pnat-01]
Huang, B., "Prefix NAT: Host based IPv6 translation",
February 2010.
[I-D.softwire-dual-stack-lite-06]
Durand, A., "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion", August 2010.
[I-D.softwire-gateway-init-ds-lite-00]
Brockners, F., "Gateway Initiated Dual-Stack Lite
Deployment", May 2010.
[ID_IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
Zhou & Taylor Expires March 21, 2011 [Page 10]
Internet-Draft Mobile Use Case September 2010
IPv6 Coexistence and Transition", January 2010.
[ID_v6v4_framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation (Work in progress)", August 2010.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
Authors' Addresses
Cathy Zhou (editor)
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.
Ottawa K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Zhou & Taylor Expires March 21, 2011 [Page 11]