Network Working Group J. Xu Internet Draft China Telecom Intended status: Informational S. Jiang Expires: October 8, 2009 Huawei Technologies Co., Ltd April 14, 2009 A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement draft-xu-v6ops-hybrid-platform-ps-00.txt 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 October 12, 2009. 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. Xu, et al. Expires October 12, 2009 [Page 1] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 Abstract Global IPv6 deployment is inevitable. There are many solutions have been specified in order to provide IPv6 connectivity services. In order to provide IPv6 connectivity services to all kinds of host/client devices, ISP networks need to support as many as possible IPv6 connectivity solutions. This document proposes a hybrid ISP platform that supports the coexistence of variable IPv6 connectivity solutions and analyses the configuration requirements raised by this platform. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed. Table of Contents 1. Introduction................................................3 2. Overview of A Hybrid ISP Platform.............................4 3. Configuration Mechanisms.....................................5 3.1. Manual configuration....................................5 3.2. DHCPv6.................................................6 3.3. Domain Name Service.....................................6 3.4. Others.................................................6 4. Security Considerations......................................6 5. IANA Considerations.........................................6 6. References..................................................6 6.1. Normative References....................................6 6.2. Informative References..................................7 Author's Addresses.............................................8 Xu, et al. Expires October 12, 2009 [Page 2] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 1. Introduction Global Internet has grown up rapidly in last 25 years. More and more devices are linked on the Internet. Internet Protocol (version 4 [RFC791]) plays an important role during the success of the Internet. IPv4 addresses identify the logic location of every device in the Internet so that data packets can be delivered to the right destination. However, giving the fact that the length of IPv4 addresses is only 32 bits, there is only less that 4 billion available IPv4 address. IPv4 address exhaustion is now confirmed to happen soon. The dynamically-updated IPv4 Address Report [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA unallocated address pool exhaustion and middle 2012 for RIR unallocated address pool exhaustion. Although there are a number of mechanisms trying to extend the life time of IPv4, the transition of the Internet to Internet Protocol version 6 [RFC2460] is the only practical and readily available long- term solution to IPv4 address exhaustion. The Internet industry appears to have reached consensus that global IPv6 deployment is inevitable and has to be done quite quickly. IPv4/IPv6 transition, including intercommunication between IPv4 and IPv6, therefore becomes more critical and complicated for the soon-coming global IPv6 deployment. On another side, there are many solutions have been specified in order to provide IPv6 connectivity services, include 6over4 [RFC3056], 6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing Protocol [RFC5214]), NAT-PT [RFC2663] (though NAT-PT has been obsoleted [RFC4966], NAT-PT-like technologies, for example NAT64 [NAT64], are still needed), SIIT (Stateless IP/ICMP Translation Algorithm [RFC2765]), BIS (Dual Stack Hosts using the Bump-In-the- Stack Technique [RFC2767]), Transport Replay Translator [RFC3142], Socks 64 Gateway [RFC3089], BIA (Dual Stack Hosts Using Bump-in-the- API [RFC3338]), etc. Each of them has different service scenarios and needs both Internet Service Provider (ISP) networks and host/client devices to support them at the same time. Furthermore, in the IPv6 global deployment, more issues or different scenarios may occur. Correspondently, more solutions may be developed to meet certain requirements in the future. 6RD (IPv6 Rapid Deployment [6RD]), Dual- Stack Lite [DSLite] and Incremental CGN [ICGN], TURN (Traversal Using Relays around NAT [TURN]) has been submitted to IETF. Up to now, there is not AN universal mechanism that can meet all IPv6 connectivity service scenarios, including connectivity between IPv6- only and IPv4-only, see table 1. Host/client devices may choose to Xu, et al. Expires October 12, 2009 [Page 3] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 support one or more certain solutions. But host/client devices with variable solution all require IPv6 connectivity through ISP network services. In order to provide IPv6 connectivity services to all kinds of host/client devices, ISP networks need to support as many as possible IPv6 connectivity solutions. Additionally beside availability, all these efforts should be transparent for end-user. +------------------------------------------------------------+ | |6o4|6to4| ISA |NAT|SIIT|BIS|Trans.|SOCKS|BIA| | | | |-TAP |-PT| | |Relay | G/W | | |---------------+---+----+-----+---+----+---+------+-----+---| |Dual Stack Host| X | | X | | | X | | | X | |---------------+---+----+-----+---+----+---+------+-----+---| | Upper Message | | | | | | | X | X | X | | Manipulation | | | | | | | | | | |---------------+---+----+-----+---+----+---+------+-----+---| | IP Header | | | | X | X | X | | | | | Translation | | | | | | | | | | |---------------+---+----+-----+---+----+---+------+-----+---| | Tunneling | X | X | X | | | | | | | |---------------+---+----+-----+---+----+---+------+-----+---| | In Host | X | | X | | | X | X | X | X | |---------------+---+----+-----+---+----+---+------+-----+---| | In Gate | | X | | X | | | X | X | | |---------------+---+----+-----+---+----+---+------+-----+---| | Consider APPs.| | | | | | | | | X | +------------------------------------------------------------+ Table 1: Characters of IPv6 connectivity mechanisms This document proposes a hybrid ISP platform that supports the coexistence of multiple IPv6 connectivity solutions and analyses the configuration requirements raised by this platform. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed. 2. Overview of A Hybrid ISP Platform The proposed hybrid ISP platform supports the co-existence of hybrid IPv6 connectivity and IPv6/IPv4 intercommunication solutions. It encourages that ISPs work together with Internet Content Providers (ICPs) to provide IPv6 connectivity and IPv6/IPv4 intercommunication services. ISPs provide as much as possible generic support. ICPs can design and implement their application specific traverse mechanisms utilizing ISP's generic services. Xu, et al. Expires October 12, 2009 [Page 4] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 First, ISP deploys required devices for IPv6 connectivity and IPv6/IPv4 intercommunication solutions in its ISP networks. Depending on each solution, the required devices may be located at different positions. For example, IPv6/IPv4 intercommunication devices should be placed at the edge between IPv4/IPv6 networks. CGNs may be deployed according to the ISP customer aggregation strategy. Application-specific gateways for IPv6/IPv4 intercommunication may be deployed as services by ICP within ISP network too. Each application may have their customized traversal mechanisms and servers. All information of deployed services, including IP addresses of devices, needs to be collected and distributed to ISP access devices, such as BRAS. Through standard protocols, which need to be extended based on existing DHCPv6, PPPoEv6 or other protocols, ISP access devices propagate the availability information to the host/client devices. The operation system on the host/client devices may filter IPv6 connectivity services according to its own supporting status. The OS should provide standard IPv6 connectivity invoking interface for the upper layer applications, for example, GetSocks64Address, GetNAT- PTAddress. Based on the availability, applications can choose the IPv6 connectivity services accordingly. This hybrid ISP platform provides the maximum IPv6 connectivity support for all different solutions. In order to fulfil this hybrid ISP platform, there are two technical gaps needs to be supplied: configuration mechanisms in which service information could be pushed to the host/client devices; standard IPv6 connectivity invoking interface on the hosts/client devices. The latter is out of scope of this document. The configuration mechanism is discussed below. 3. Configuration Mechanisms There are a number of configuration mechanisms that could be potentially used to propagate IPv6 connectivity service information to the host/client devices. 3.1. Manual configuration Manual configuration has already been used in many IPv6 connectivity solutions. However, this method requires expert knowledge for at least first time configuration. Its scalability is quite poor. Xu, et al. Expires October 12, 2009 [Page 5] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 Furthermore, this mechanism is lack of flexibility. For example, the connectivity service will become unavailable after a server changes its IP address. 3.2. DHCPv6 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can assign addresses statefully. Besides, DHCPv6 can also be used to distribute other configuration information. DHCPv6 can be extended to propagate IPv6 connectivity service information. A set of new options needs to be developed and their interaction behaviour need to be defined clearly. 3.3. Domain Name Service For well-known services, certain DNS records may be defined so that host/client devices can resolve their IP address through DNS query. For example, natpt.chinatelecom.com.cn can be used to point all China Telecom customers to available NATPT servers. With intelligence DNS mechanism, client requirements can be diverted to a suitable server among many available servers. 3.4. Others According to different access technologies, certain protocol, such as PPPOE or ICMP may be extended to propagate IPv6 connectivity service information. 4. Security Considerations The security issues for each solution that provides IPv6 connectivity services are out of scope. However, further security analysis will be needed to understand whether there are security issues for configuration mechanisms mentioned in this document. 5. IANA Considerations This draft does not request any IANA action. 6. References 6.1. Normative References [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. Xu, et al. Expires October 12, 2009 [Page 6] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 [RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT) ", RFC 2765, February 2000. [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. 6.2. Informative References [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2767] K. Tsuchiya, et al., "Dual Stack Hosts using the Bump-In- the-Stack Technique (BIS)", RFC 2767, February 2000. [RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism, RFC3089", April 2001. [RFC3142] J. Hagino, "An IPv6-to-IPv4 Transport Relay Translator" RFC 3142, June 2001. [RFC3338] S. Lee, et al., "Dual Stack Hosts Using Bump-in-the-API (BIA)", RFC 3338 October 2002 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, http://www.potaroo.net/tools/ipv4/index.html. [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", draft-despres-6rd-03.txt, working in progress, April 2009. [DSLite] A. Durand, et al., "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite- 00.txt, working in progress, March 2009. Xu, et al. Expires October 12, 2009 [Page 7] Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009 [ICGN] S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition" draft-jiang-incremental-cgn-00.txt, working in progress, March 2009. [NAT64] M. Bagnulo, et al., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft- bagnulo-behave-nat64-03.txt, work in progress, March 2009. [TURN] G. Camarillo and O.Novo, "Traversal Using Relays around NAT (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6- 06.txt, working in progress, March 2009. Author's Addresses Jianfeng Xu China Telecom No.109, West Zhongshan Street, Tian-He District, Guangzhou 510630 P.R. China Phone: 86-20-38639112 EMail: xujf@gsta.com Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836774 EMail: shengjiang@huawei.com Xu, et al. Expires October 12, 2009 [Page 8]