v6ops J. Qin Internet-Draft ZTE Intended status: Informational G. Liu Expires: April 22, 2010 China Telecom October 19, 2009 Recommendations for the ISPs' provision of IPv6 transition services to the ICPs draft-qin-v6ops-icp-transition-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The exhaustion of IPv4 addresses is coming, while due to many Qin & Liu Expires April 22, 2010 [Page 1] Internet-Draft ICP Transition October 2009 reasons, no significant IPv6 deployment has occured. The transition of users, networks and services from IPv4 to IPv6 is not so smoothly and expeditiously as expected. The solutions now available are not sufficient for all the scenarios, so the IPv6 deployment models are revisited, and some new methods used for transition have been developed to complement the existing ones. This document discusses the transition of services and the use of these new mechanisms from the ISP's point of view to provide approaches to the transition for ICPs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Dual Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 5 2.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 5 3. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 7 3.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 7 4. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 8 4.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Qin & Liu Expires April 22, 2010 [Page 2] Internet-Draft ICP Transition October 2009 1. Introduction The exhaustion of IPv4 addresses is coming, while due to many reasons, no significant IPv6 deployment has occured. The transition of users, networks and services from IPv4 to IPv6 is not so smoothly and expeditiously as expected. The solutions now available are not sufficient for all the scenarios, so the IPv6 deployment models are revisited, and some new methods used for transition have been developed to complement the existing ones. This document discusses the transition of services and the use of these new mechanisms from the ISP's point of view to provide approaches to the transition for ICPs. The transition of services to IPv6 will get started in succession from now or sooner in the future. As we all know, the IPv4 users or various Requests to IPv4 services dominate in current networks, and even in the future the co-existence of IPv4 and IPv6 will persist for a long time. so how to preserve the continuity and availability of legacy services while migrating to IPv6 concerns ICPs deeply. Since ICPs have different requirements of service level agreement, some care mostly about the stability and User Experience, and some care about the cost of migration mostly, the ISP should choose different migration solutions for ICPs to meet their needs and help them migrating to IPv6 rapidly. Some recommendations on how to do it are given in this document. Approaches Dual Stack In order to provide full functional services for both IPv4 and IPv6, Dual stack may be a good choice. It has less limitations and is suitable for ICPs that require high availability. While it may be not cost efficient compared to the utilization of the IPv6 stack especially at the early stage of transition, so may be not acceptable to all. NAT64 There must be some conservative ICPs that are sensitive to the cost and possible interruption caused by the migration. They want to make experimental provision of IPv6 services firstly based on current infrastructures with no change or the system platforms that are not upgradable. In this case, one could use some translation mechanism for the communication initiated from IPv6 Internet. IVI Qin & Liu Expires April 22, 2010 [Page 3] Internet-Draft ICP Transition October 2009 On the other hand, there are some radical ICPs relatively that wish to migrate to IPv6 purely without IPv4 stack enabled, or maybe at later stage more IPv6-only servers are put in the network, while under the pressure of large quantity of IPv4 users, the reachability for them needs to be preserved. IVI is fit for this case. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Dual Stack As specified in RFC4213, Dual Stack is the most well understood and recommended approach today providing complete implementations for both IPv4 and IPv6. Through Dual Stack routing infrastructure, the Dual Stack servers could interoperate with IPv4 and IPv6 user devices respectively using IPv4 and IPv6. Of course, both stack and application capabilities of IPv4 and IPv6 must be enabled on the "Dual Stack servers". For the application aspects of transition, please refer to RFC4038. Qin & Liu Expires April 22, 2010 [Page 4] Internet-Draft ICP Transition October 2009 +------------------------+ | IDC +------------+ | | | Dual-Stack | | | | servers | | | +------+-----+ | | IPv6 address |& IPv4 address | | | | +------+-----+ | | | Dual-Stack | | | | router | | | +--+------+--+ | +-----------|------|-----+ | | | | IPv6 prefix | | | | IPv4 prefix announced | | | | announced Y | | Y +----------------------|-+ +-|----------------------+ | +--------+ | | +--------+ | | | V6 DNS | | | | V4 DNS | | | | server | | | | server | | | +--------+ | | +--------+ | | | | | | IPv6 Network | | IPv4 Network | | | | | | | | | +------------------------+ +------------------------+ 2.1. Operational Issues For Dual stack mechanism, more issues may come from the business aspect rather than techniques, which are about how to better align the costs and benefits of the migration. We only discuss the technical issues of all these approaches here. The migration can not be done in one day, the issues of adding DNS records should be considered in cases where some services are more IPv6-ready than others. MORE, TBD.. 2.2. Requests to ICPs The system software of the servers should be upgradable, and the hardware may need to be upgraded to support both IPv4 and IPv6 capabilities, as more resources like memery are needed to run two sets of stacks and applications concurrently. Further more, based on new API, some service applications may need to Qin & Liu Expires April 22, 2010 [Page 5] Internet-Draft ICP Transition October 2009 be redeveloped, see RFC3493 and RFC3542 about the API for IPv6. 3. NAT64 NAT64 defines a stateful translation mechanism used for communication between IPv4 and IPv6 nodes, the suitable scenarios include "an IPv6 network to the IPv4 Internet" and "the IPv6 Internet to an IPv4 network", implying that the communication should be iniciated from the IPv6 side. The latter scenario applies to the case here. +------------------------+ | IDC +------------+ | Stateful | | IPv4 | | Translation: | | servers | | | +------+-----+ | | IPv4|address | | | | +-------------+ +------+-----+ | | v4 pool for | | Dual-Stack | | | v6 network | | router | | +-------------+ | with NAT64 | | | +--+------+--+ | +-----------|------|-----+ | | | | IPv6 prefix announced | | | | IPv4 prefix -of servers in IDC | | | | announced Y | | Y +----------------------|-+ +-|----------------------+ | +--------+ | | +--------+ | | | V6 DNS | | | | V4 DNS | | | | server | | | | server | | | +--------+ | | +--------+ | | | | | | IPv6 Network | | IPv4 Network | | | | | | | | | +--------------------\---+ +---/--------------------+ \ / \ / +--------+ | DNS64 | | server | +--------+ Qin & Liu Expires April 22, 2010 [Page 6] Internet-Draft ICP Transition October 2009 3.1. Operational Issues At least on IPv4 address pool used for translation should be configured on the GW and the capacity is limited by the size of the pool which is for the whole IPv6 Internet. Then one has to determine where and how to deploy the DNS64 server which is used for synthesizing AAAA records from A records using special IPv6 prefix. Moreover, all the limitations of translators apply here. MORE, TBD.. 3.2. Requests to ICPs Nearly no changes are required in the servers, while there will be information lost during the translation, so necessary functional tests may be needed before the migration and deployment of some services in this way. 4. IVI IVI is a stateless translation mechanism, the nodes are configured with IVI format IPv6 addresses which are formed by embedding IPv4 addresses in IPv6 prefixes. They appear as normal IPv6 nodes in the IPv6 network. Meantime, the IVI nodes are connected to the legacy IPv4 Internet by IVI boxes which appear as normal IPv4 routers or gateways. So the communications with IPv6 nodes could be achieved directly, and the communications with IPv4 Internet could be achieved via the stateless translator, IVI. | n | 32 | 96-n | +------------+--------------+--------+ |IPv6 prefix | IPv4 address | suffix | +------------+--------------+--------+ / / original address Qin & Liu Expires April 22, 2010 [Page 7] Internet-Draft ICP Transition October 2009 +------------------------+ | IDC +------------+ | | | IPv6 | | | | servers | | | +------+-----+ | | IPv6|address (IVI format) | | | | +------+-----+ | | | Dual-Stack | | Stateless | | router | | Translation: | | with IVI | | | +--+------+--+ | +-----------|------|-----+ | | | | IPv6 prefix | | | | IPv4 prefix announced announced | | | | -based on original addresses Y | | Y +----------------------|-+ +-|----------------------+ | +--------+ | | +--------+ | | | V6 DNS | | | | V4 DNS | | | | server | | | | server | | | +--------+ | | +--------+ | | | | | | IPv6 Network | | IPv4 Network | | | | | | | | | +------------------------+ +------------------------+ 4.1. Operational Issues One should better use the servers' original IPv4 addresses to form the IVI format IPv6 addresses, that will maintain the stability of the legacy IPv4 routing infrastructure. The part of network where the IVI nodes are located should be designed accordingly. 4.2. Requests to ICPs TBD. 5. IANA Considerations This document includes no request to IANA. 6. Security Considerations WILL BE ADDED IN THE NEXT VERSION.. Qin & Liu Expires April 22, 2010 [Page 8] Internet-Draft ICP Transition October 2009 7. References 7.1. Normative References [I-D.ietf-behave-address-format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-00 (work in progress), August 2009. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-00 (work in progress), July 2009. [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-01 (work in progress), September 2009. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in progress), September 2009. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work in progress), October 2009. [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-02 (work in progress), June 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. Qin & Liu Expires April 22, 2010 [Page 9] Internet-Draft ICP Transition October 2009 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. 7.2. Informative References [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008. Authors' Addresses Jacni Qin ZTE Shanghai, P.R.China Phone: +86 1391 861 9913 Email: jacniq@gmail.com Qin & Liu Expires April 22, 2010 [Page 10] Internet-Draft ICP Transition October 2009 Guangyi Liu China Telecom Guangzhou, P.R.China Phone: +86 20 3863 9762 Email: liugy@gsta.com Qin & Liu Expires April 22, 2010 [Page 11]