Internet Engineering Task Force T. Tsou, Ed.
Internet-Draft T. Taylor
Intended status: Informational Huawei Technologies
Expires: April 22, 2011 October 19, 2010
IPv6 Transition Guide For A Large Mobile Operator
draft-tsou-v6ops-mobile-transition-guide-00
Abstract
This document provides a transition guide for a large-scale mobile
network operator migrating its network from IPv4 to IPv6.
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 22, 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.
Tsou & Taylor Expires April 22, 2011 [Page 1]
Internet-Draft Mobile Operator Transition October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Steps In the Transition Strategy . . . . . . . . . . . . . . . 3
2.1. Migration Of Operational Support Systems and AAA . . . . . 3
2.2. Transition of the Private Internal Network . . . . . . . . 4
2.3. Migrating the Portal to the Operator's Proprietary
Content and Applications . . . . . . . . . . . . . . . . . 4
2.4. User Devices . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Portals to the Partner Content and Application
Providers . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Tsou & Taylor Expires April 22, 2011 [Page 2]
Internet-Draft Mobile Operator Transition October 2010
1. Introduction
The use case for migration of a large mobile network to IPv6 is
described in [ID_mobile_use_case]. That document provides an
introduction to the network architecture and looks at possible
strategies and tools for migration. 3GPP has decided to use Gateway-
Initiated DS-lite [ID_GI_DS_lite] as the primary tool for subscriber
migration. Details as far as they have been thought out are provided
in [3GPP_TR_23_975]. However, they cover only a small part of the
total problem.
1.1. Requirements Language
This document contains no requirements language.
2. Steps In the Transition Strategy
The transition to IPv6 must be carried out over a number of different
segments within the total network:
o the operator's operational support systems, including AAA;
o the operator's private IP network;
o the portal to the operator's proprietary content and applications;
o the user devices;
o portals to the partner content and application providers.
These are listed in what is probably the preferred order for making
the transition, but in fact the operator will want to carry out a
number of activities in parallel.
2.1. Migration Of Operational Support Systems and AAA
The transition to IPv6 may have a number of consequences for AAA and
other support systems. First and most obvious, systems must be set
up for the provisioning of IPv6 addresses and associated
configuration data. AAA may be affected if the subscriber's IPv4
address has been used as a correlator for accounting records. Device
provisioning and configuration within the network to handle IPv6 has
to be tracked so that the engineering department can monitor the
progress of the necessary network upgrades and maintenance has the
information it needs to carry out routine testing and restoration
procedures. New maintenance procedures have to be developed.
Tsou & Taylor Expires April 22, 2011 [Page 3]
Internet-Draft Mobile Operator Transition October 2010
Given the time it takes to develop new support systems or modify old
ones, it is to be hoped that the most critical areas of the effort
have already been identified and are well on the way to being
implemented before any of the other activities begin.
2.2. Transition of the Private Internal Network
The private internal network includes signalling links between
network devices, but also the IP layer over which tunnels carry user
packets.
Conversion of the private internal network to pure IPv6 operation
should be an early objective, for at least two reasons. In the first
place, it provides the operator with experience that will be helpful
when making the transition in other segments of the network. In
addition, it relieves the operator of one source of demand for IPv4
addresses, at least some of which must be public to allow
communication with other operators.
Unfortunately, the need for IPv4 addresses will not go away
immediately. While the transition is in progress, until upgrades are
completed, a transition mechanism is needed to allow the upgraded
equipment to interoperate with the equipment that has not yet been
upgraded. The most obvious mechanism is to use dual-stack operation
with the devices being configured to use IPv6 whenever possible. It
may be possible to do the upgrades in blocks of devices, where
relatively few of the devices in a block need to communicate with
devices outside the block. These boundary devices will continue to
need IPv4 addresses until the other blocks with which they
communicate have been upgraded, but communications in the interior of
the block can use IPv6 and so interior devices need no IPv4 address.
Because IPv6 usage in the private network will build up as quickly as
the operator can upgrade the network equipment, an IPv6 version of
the internal DNS system will be needed early on. It seems likely, in
fact, that the most efficient mode of operation will be a dual-stack
DNS containing both A and AAAA records.
A key use of this DNS system is to allow the Serving Gateway to
locate a PDN Gateway providing access to the core network that the
subscriber will use. This may be operator's own core network or
the subscriber's home network.
2.3. Migrating the Portal to the Operator's Proprietary Content and
Applications
The operator needs to build up the availabilty of IPv6-accessible
applications and content as quickly as possible, to reduce the IPv4
Tsou & Taylor Expires April 22, 2011 [Page 4]
Internet-Draft Mobile Operator Transition October 2010
traffic on the network and thereby reduce the demand for public IPv4
addresses. One way to do this is to make the operator's own content
and applications IPv6-accessible early on in the transition period.
As usual, because of the time it will take to transition all users,
IPv4 access to the content and applications must continue to be
provided, until the last Windows XP computer ceases to be tethered to
a mobile device for Internet access. In the early days, until the
content can be fully converted, protocol translation may be used to
allow access to IPv6 users. Once the content and applications have
been converted to IPv6, dual stack operation will be possible and the
protocol converter (NAT64) can be removed.
2.4. User Devices
3GPP specifications for mobile devices have required dual stack
support for at least a year (i.e., as of Release 8.) The operator
can help things along by requiring that new devices connecting to the
operator's network conform to this requirement. It will still take
two or three years until the large majority of devices are capable of
dual stack operation.
The transition strategies considered in [3GPP_TR_23_975] relate
specifically to how user traffic is carried. That document offers
four different scenarios, or strategies, for achieving transition.
In the early stages, before a large portion of the content and
applications accessed by users can be reached by IPv6, the most
likely strategy will be to interpose Gateway-Initiated DS-lite
[ID_GI_DS_lite] using a minimal set of private IPv4 addresses at the
user devices and sharing public IPv4 addresses between multiple users
using some system of block port allocation as proposed in
[ID_natx4-log-reduction].
When the operator converts a given area to Gateway-Initiated DS-lite
access, a number of public IPv4 addresses are freed because of the
introduction of address sharing. This suggests that one strategy may
be to introduce Gateway-Initiated DS-lite initially in high-growth
areas, using the addresses thus freed to handle demand in lower-
growth-rate areas until they can be converted.
DNS access is an issue with Gateway-Initiated DS-lite. The original
DS-lite proposal had a point (the B4) at which all DNS queries could
be intercepted and sent to an IPv6 DNS. From here IPv4 queries could
be forwarded to an IPv4 DNS, or the IPv6 DNS could maintain both AAAA
and A records. It is not so obvious that such interception can be
carried out at the Gateway in Gateway-Initiated DS-lite, since the
Gateway is essentially performing a layer 2 operation.
[ID_GI_DS_lite] does not mention the issue.
Tsou & Taylor Expires April 22, 2011 [Page 5]
Internet-Draft Mobile Operator Transition October 2010
2.5. Portals to the Partner Content and Application Providers
As mentioned above, content conversion is the key to building up IPv6
traffic and thereby relieving pressure on the supply of public IPv4
addresses. To some extent the operator may be able to solve this at
a business level, through negotiations to encourage the content
provider to convert. However, technical solutions will also be
necessary.
One possible solution is to provide IPv6 access to the content
provider's site by installing protocol translation for traffic
between that site and IPv6 users. This would have to be accompanied
by the installation of AAAA records in DNS giving the address IPv6
address via which the site is reachable.
3. Conclusions
To be completed after review.
4. Acknowledgements
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
To be completed.
7. Informative References
[3GPP_TR_23_975]
3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects; IPv6
Migration Guidelines (Release 10)", TR 23.975, May 2010.
[ID_GI_DS_lite]
Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway Initiated Dual-Stack lite Deployment (Work in
progress)", May 2010.
[ID_mobile_use_case]
Zhou, C. and T. Taylor, "IPv6 Transition Use Case For a
Tsou & Taylor Expires April 22, 2011 [Page 6]
Internet-Draft Mobile Operator Transition October 2010
Large Mobile Network (Work in progress)", September 2010.
[ID_natx4-log-reduction]
Huang, J., "Port Management To Reduce Logging In Large-
Scale NATs (Work in progress)", August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Tina Tsou (editor)
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: tena@huawei.com
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.
Ottawa K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Tsou & Taylor Expires April 22, 2011 [Page 7]