Network Working Group J. Xu Internet Draft China Telecom Intended status: Informational S. Jiang Expires: December 26, 2009 Huawei Technologies Co., Ltd B. Carpenter University of Auckland June 30, 2009 A Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Inter- communication draft-xu-v6ops-hybrid-framework-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 December 26, 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 December 26, 2009 [Page 1] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 Abstract Global IPv6 deployment is expected. Many solutions have been specified in order to provide IPv6 connectivity service. In order to provide IPv6 connectivity service to all kinds of host/client devices, ISP networks may need to support as many as possible IPv6 connectivity solutions. This document proposes a hybrid ISP framework that supports the coexistence of various IPv6 connectivity solutions and analyses the configuration requirements raised by this framework. 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 Framework...........................5 3. APPs/ICPs Involvement........................................6 4. Configuration Mechanisms.....................................7 4.1. Manual configuration....................................7 4.2. DHCPv6.................................................7 4.3. Domain Name Service.....................................7 4.4. Others.................................................8 5. Security Considerations......................................8 6. IANA Considerations.........................................8 7. References..................................................8 7.1. Normative References....................................8 7.2. Informative References..................................9 Author's Addresses............................................11 Xu, et al. Expires December 26, 2009 [Page 2] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 1. Introduction Global Internet has grown up rapidly in last 25 years. More and more devices are connected to the global Internet infrastructure. Internet Protocol (version 4 [RFC0791]) played an essential role during the success of the Internet. IPv4 addresses identify the logical 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 are fewer than 4 billion available IPv4 addresses, and the address space is used inefficiently. 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. Individual ISPs will experience address shortage at a date depending on their own situation after the RIRs can make no more allocations. 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 perennial 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 inter- communication between IPv4 and IPv6, therefore becomes more critical and complicated for the soon-coming global IPv6 deployment. On the other hand, many solutions have been specified in order to provide IPv6 connectivity service. The most basic is the deployment of dual stack hosts and routers [RFC4213] including the support of configured IPv6-over-IPv4 tunnels. However, the dual stack approach cannot be sufficient once IPv4 addresses have run out, because it does not allow IPv6-only hosts to communicate with IPv4-only hosts. Techniques that extend the dual stack model include 6over4 [RFC2529], 6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing Protocol [RFC5214]), and tunnel brokers [RFC3053]. Techniques that address the interworking problem include SIIT (Stateless IP/ICMP Translation Algorithm [RFC2765]) and NAT-PT [RFC2663]. Although NAT-PT has been obsoleted [RFC4966], NAT-PT-like technologies, for example NAT64 [NAT64], are still needed. Other translation techniques include BIS (Dual Stack Hosts using the Bump- In-the-Stack Technique [RFC2767]), Transport Replay Translator [RFC3142], BIA (Dual Stack Hosts Using Bump-in-the-API [RFC3338]), and SOCKS 64 Gateway [RFC3089]. Interworking for specific application Xu, et al. Expires December 26, 2009 [Page 3] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 services such as HTTP proxy or SMTP, IMAP and POP3 can also easily be provided by dual stack servers. Each technique has different service scenarios and may need both Internet Service Provider (ISP) networks and host/client devices to support them at the same time. Furthermore, in the expected IPv6 global deployment, new issues or different scenarios may occur. Correspondingly, more solutions may be developed to meet some of these requirements in the future. For example, 6RD (IPv6 Rapid Deployment [6RD]), Port Range [PortRange, PRv6], Dual-Stack Lite [DSLite], Incremental CGN [ICGN], and TURN (Traversal Using Relays around NAT [TURN] Extension for IPv6) have been also submitted to the IETF recently. Up to now, there is not one universal mechanism that can meet all IPv6 connectivity service scenarios, including connectivity between IPv6-only and IPv4-only. Table 1 gives a partial summary. Host/client devices may choose to support one or several mechanisms. But host/client devices with various solutions all require IPv6 connectivity through ISP network services. In order to provide IPv6 connectivity service to different kinds of host/client devices, ISP networks need to support as many IPv6 connectivity solutions as is operationally reasonable. Additionally, all these efforts should be transparent for the average end-user. +------------------------------------------------------------+ | |6o4|6to4| ISA |ST-|STLS|BIS|Trans.|SOCKS|BIA| | | | |-TAP |Trs|-Trs| |Relay | G/W | | |---------------+---+----+-----+---+----+---+------+-----+---| |Dual Stack Host| X | | X | | | X | | | X | |---------------+---+----+-----+---+----+---+------+-----+---| | Upper Message | | | | | | | X | X | X | | Manipulation | | | | | | | | | | |---------------+---+----+-----+---+----+---+------+-----+---| | IP Header | | | | X | X | X | | | | | Translation | | | | | | | | | | |---------------+---+----+-----+---+----+---+------+-----+---| | Tunnelling | X | X | X | | | | | X | | |---------------+---+----+-----+---+----+---+------+-----+---| | In Host | X | | X | | | X | X | X | X | |---------------+---+----+-----+---+----+---+------+-----+---| | In Gate | | X | | X | | | X | X | | +------------------------------------------------------------+ Table 1: Characters of IPv6 connectivity mechanisms Xu, et al. Expires December 26, 2009 [Page 4] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 In table 1, each column means: 6o4 = IPv6 over IPv4 [RFC2529] 6to4 = [RFC3056] ISATAP = Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] ST-Trs = Stateful Translation, such as NAT-PT [RFC2663], NAT64 [NAT64] STLS-Trs = Stateless Translation, such as Stateless IP/ICMP Translation Algorithm [RFC2765] BIS = Dual Stack Hosts using the Bump-In-the-Stack Technique [RFC2767] Trans. Relay = Transport Replay Translator [RFC3142] SOCKS G/W = SOCKS 64 Gateway [RFC3089] BIA = Dual Stack Hosts Using Bump-in-the-API [RFC3338] In table 1, each row means: Dual Stack Host = supporting dual-stack hosts Upper Message Manipulation = modifying application messages IP Header Translation = translating IP header Tunnelling = using Tunnel technology In Host = involving host support In Gate = involving gateway support This document proposes a hybrid ISP framework that supports the co- existence of multiple IPv6 connectivity solutions, and analyses the configuration requirements raised by this framework. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed. 2. Overview of A Hybrid ISP Framework The proposed hybrid ISP framework supports the co-existence of hybrid IPv6 connectivity and IPv6/IPv4 inter-communication solutions. It encourages ISPs to work together with Internet Content Providers (ICPs) to provide IPv6 connectivity and IPv6/IPv4 inter-communication service. ISPs provide as much as possible generic support. ICPs can design and implement their application specific interworking mechanisms utilizing their ISP's generic services. First, ISPs should deploy required resources for offering IPv6 connectivity and IPv6/IPv4 inter-communication solutions in their operational networks. Depending on each solution, the required devices may be located at different network segments. For example, IPv6/IPv4 inter-communication 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 (ALGs) for IPv6/IPv4 inter-communication may be deployed as services by ICP within ISP network too. Each application may have its customized traversal or interworking mechanisms and servers. As noted above, Xu, et al. Expires December 26, 2009 [Page 5] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 this is very straightforward for "relay" applications like mail and HTTP proxy. All information about deployed services, including IP addresses of servers, needs to be collected and distributed to ISP access devices, such as BRAS. Then, this information, include availability information, can be propagated to the host/client devices through standard protocols, which need to be extended, based on existing Dynamic Host Configure Protocol for IPv6 (DHCPv6) [RFC3315], IPv6 over PPP [RFC5072], Network Configuration Protocol (NETCONF) [RFC4741], Simple Network Management Protocol (SNMP) [RFC3411] or other protocols. Note that IPv6 autoconfiguration is not powerful enough for this purpose. Based on the availability information received, applications on the host/client devices can choose the IPv6 connectivity services they can use or prefer. The operating system (OS) on the host/client devices may filter/drop some IPv6 connectivity services according to its own capability. The OS should provide a standard IPv6 connectivity invoking interface for the upper layer applications. The hybrid ISP framework provides support for as many as possible different IPv6 connectivity solutions. CPEs and host/client devices may need to be configured or updated to get maximum benefit, but they must all get basic connectivity in a standard way. In order to realise this hybrid ISP framework, there are two technical gaps that need to be filled: 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. APPs/ICPs Involvement This framework assumes applications or ICPs would ideally be aware of IPv4/IPv6 inter-communication; it requests applications or ICPs to choose among the different inter-communication technologies. This seems to be in conflict with the traditional layered network model. However, the reality is that applications/ICPs, particularly peer-to- peer applications, have already broken the layered network model so that they can traverse the ubiquitous NAT devices. In the IPv4 networks, the existence of NAT breaks the end-to-end transparency. In order to find NATs and traverse them, applications have to understand Xu, et al. Expires December 26, 2009 [Page 6] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 network protocols deeply, invoke or interact with network protocols directly and analyse network behaviours by themselves, since the protocol stack on the end user devices is not aware of NATs. Furthermore, since NAT is not standardized, applications have to handle many different NAT technologies. The scenarios between IPv4-only hosts and IPv6-only hosts are partly similar to above discussed NAT scenarios. Due to the differences, there can not be pure end-to-end transparency between them. Based on this reality, the better way is to standardize IPv4/IPv6 inter- communication technologies, also mechanisms which propagate relevant information from networks to end hosts. Then, applications could learn inter-communication information from the protocol stack on the hosts instead of detecting by themselves. This learning process may be through a standard API between network layer and application layer on the hosts. This design actually maintains the traditional layered network model. 4. 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. 4.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. Its operational burden would be too large when there are many users. Furthermore, this mechanism is very exposed to human errors. 4.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 behaviour must be defined clearly. 4.3. Domain Name Service For well-known services, certain DNS records may be defined so that host/client devices can resolve their IP addresses through DNS queries using DNS SRV [RFC2782]. For example, natpt.isp1.example.net can be used to point all ISP1 customers to available NAT-PT servers. Xu, et al. Expires December 26, 2009 [Page 7] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 With a suitable DNS mechanism, client load can be distributed among many available servers. 4.4. Others According to different access technologies, certain protocols, such as PPPoE or ICMP [RFC0792], may be extended to propagate IPv6 connectivity service information to subscribers. Note that router and switch configuration protocols such as NETCONF and SNMP are not considered relevant here. 5. Security Considerations The security issues for each solution that provides IPv6 connectivity service are discussed in their own specifications. However, further security analysis will be needed to understand whether there are security issues for configuration mechanisms mentioned in this document. 6. IANA Considerations This draft does not request any IANA action. 7. References 7.1. Normative References [RFC0791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC0792] J. Postel, "Internet Control Message Protocol", RFC 792, September 1981. [RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT) ", RFC 2765, February 2000. [RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC2782, February 2000. [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel Broker", RFC3053, January 2001. Xu, et al. Expires December 26, 2009 [Page 8] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 [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. [RFC3411] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [RFC4213] E. Nordmark, R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC4213, October 2005. [RFC4741] R. Enns, et al., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC5072] S.Varada, Ed., D. Haskins, E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. 7.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. Xu, et al. Expires December 26, 2009 [Page 9] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 2009 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", draft-despres-6rd, working in progress. [PortRange] B. Storer, et al., "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion", draft-boucadair-port- range, work in progress. [PRv6] M. Boucadair, et al., "Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage", draft-boucadair- behave-ipv6-portrange, work in progress. [DSLite] A. Durand, et al., "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite, working in progress. [ICGN] S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition" draft-jiang-v6ops-incremental-cgn, working in progress. [NAT64] M. Bagnulo, et al., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft- bagnulo-behave-nat64, work in progress. [TURN] G. Camarillo and O.Novo, "Traversal Using Relays around NAT (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6, working in progress. Xu, et al. Expires December 26, 2009 [Page 10] Internet-Draft draft-xu-v6ops-hybrid-framework-00.txt June 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 Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand Email: brian.e.carpenter@gmail.com Xu, et al. Expires December 26, 2009 [Page 11]