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]