Internet Engineering Task Force G. Yang Internet-Draft Z. Huang Intended status: Informational W. LI Expires: December 12, 2011 China Telecom June 10, 2011 Service-Provider Application Cloud-based Engine for IPv6 draft-yang-v6ops-space6-icp-00 Abstract Even though a lot of IPv6 transition solutions have been proposed and standardized during the past few years, the migration of ICPs are still much slower than expected, there is still a lack of a comprehensive transition tool for them. This document introduces a solution to help ICPs expedite their procedures, SPACE6, stands for Service-Provider Application Cloud-based Engine for 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 December 12, 2011. Copyright Notice Copyright (c) 2011 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 Yang, et al. Expires December 12, 2011 [Page 1] Internet-Draft SPACE6-ICP June 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. NAT64 in ISP . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. NAT64 in ICP . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Problems Conclusion . . . . . . . . . . . . . . . . . . . 6 4. SPACE6 Specification . . . . . . . . . . . . . . . . . . . . . 6 4.1. SPACE6 Architecture . . . . . . . . . . . . . . . . . . . 7 4.2. Deployment Scenario . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Yang, et al. Expires December 12, 2011 [Page 2] Internet-Draft SPACE6-ICP June 2011 1. Introduction At present, most ICPs (Internet Content Provider) are providing services based on IPv4; they have not begun the migration to IPv6 indeed, although IANA has announced the depletion of IPv4 addresses. In the near future, ISP (Internet Service Provider) will assign IPv6 addresses to their new subscribers, therefore there will exists both IPv4 users and IPv6 users, the network infrastructure and deployment scenario will be getting more and more complicated. When providing services to the public, ICPs always have to pay more attention to the network environment of their potential clients, they are facing a very important issue: how to offer the IPv4 and IPv6 services simultaneously, to be more precise, this means how to realize the interoperation between IPv4 and IPv6. The most ideal solution for an ICP is to upgrade the platform to support dual stacks from the code level, but the implementations of ICPs' business platforms differ in thousands of ways, and the difficulties of modification are various, so it's impossible to finish the migration to IPv6 in a short period of time. In these cases, there should be some tools or solutions to solve the intercommunication between IPv4 and IPv6, which would also be of great importance for dealing with the lack of IPv6 contents during the early transition stage. 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. Terminologies The following definitions apply for the purposes of this document (some definitions are from other RFCs): Stateful NAT64: A function that has per-flow state that translates IPv6 packets to IPv4 packets and vice versa, for TCP, UDP, and ICMP. The NAT64 uses binding state to perform the translation between IPv6 and IPv4 addresses. In this document, we also refer to stateful NAT64 simply as NAT64. DNS64: A logical function that synthesizes DNS resource records (e.g., AAAA records containing IPv6 addresses) from DNS resource records actually contained in the DNS (e.g., A records containing IPv4 addresses). Yang, et al. Expires December 12, 2011 [Page 3] Internet-Draft SPACE6-ICP June 2011 Authoritative server: A DNS server that can answer authoritatively a given DNS request. IDC: A place established by a service provider to provide stable and wide-band networks and high performance computers as a service to their customers Client-side solution: The solution that are operated and maintained by the end users. ISP network-side solution: The solution that are deployed in the ISP network and maintained by the ISP. ICP-side solution: The solution that are deployed in the ICP network and maintained by an specific ICP. Subscriber: The client that is purchasing the DSL circuit from the Service Provider and is receiving the billing. 3. Problem Statement According to the position of deployment, existing solutions are grouped into three categories: Client-side, ISP network-side and ICP- side solution. This article would analyze and compare the pros and cons of those mechanisms, and then introduce a new ICP-side solution called SPACE6, aim to help ICPs expedite their transition procedures. Client-side intercommunication mechanisms are implemented by installing and applying the protocol translation module, which would modify the socket API or act as a proxy to realize the protocol translation automatically. This group includes BIS [RFC2767] , BIA [RFC3338] and so on, they need to be deployed on the client terminal, but there are so many clients out there that it's even impossible to put them into practices, furthermore those methods are a little complicated and inextensible. ISP network-side mechanism is that ISPs deploy the translation gateway on their network, such as NAT64 and DNS64, providing the basic capability for IPv6 clients to access IPv4 service. These solutions are offered to all subscribers, since there are so many types of applications, some of which are not working correctly with the NAT devices, and the network throughput is far larger than the capacity of NAT devices. ICP-side mechanisms include that ICP upgrade their whole system to provide IPv6 access services, IPv6 clients are likely to access the service directly. The following section focuses on the comparison of Yang, et al. Expires December 12, 2011 [Page 4] Internet-Draft SPACE6-ICP June 2011 ISP network-side and ICP-side mechanisms. 3.1. NAT64 in ISP Stateful NAT64 and DNS64 are described in RFC6146 [RFC6146] and RFC6147 [RFC6147] respectively in detail. For the moment, the combination of NAT64 and DNS64 is the most popular solution for the intercommunication between IPv6 and IPv4, the best deployment position is the border of IPv6 and IPv4 network. Stateful NAT64 can only translate the traffic initiated by IPv6 side, while stateless NAT64 can deal with both. In practice, NAT64 and DNS64 are also used in ICP side; in this case, it can only serve the specific ICP within its domain. When an ISP is deploying NAT64 and DNS64, protocol translation is considered as a generic service, which is open to all IPv6 subscribers and IPv4 ICP, but it only supports a limited number of applications. As an ISP network-side solution, NAT64 and DNS64 have the following drawbacks: 1. Limited number of applications are supported: NAT64 do not analyze the application layer protocols, it only translates the IP header and maintains the state of TCP, UDP and ICMP sessions, but there are a lot of streaming media applications that based on RTP and RTCP as the transport layer protocols, which are not supported by NAT64 yet. 2. Imperfect support for application: NAT64 do not support HTTP perfectly, for example: it required that the URL of hyperlink must contain the domain name, rather than an IP address. 3. Difficulties of deployment: ISP should deploy and maintain extra DNS64 servers, whose stabilities have not been tested for a long enough period of time, so it's unacceptable to deploy a number of DNS64 servers for commercial business. 4. if the client is dual-stack, NAT64 and DNS64 will bring a series of problems, since DNS64 would always return answers for AAAA query, and client application would prefer IPv6 to initialize the communication, this result in dual-stack clients couldn't access ICP service via IPv4 directly. 3.2. NAT64 in ICP Most ICP are willing to provide stable and comprehensive IPv6 services to their clients, thus network-side solutions can't meet their requirements. From the technical aspect, the best way is to check and revise the system codes, but the costs are much more than Yang, et al. Expires December 12, 2011 [Page 5] Internet-Draft SPACE6-ICP June 2011 an ICP can afford, such as the manpower and economy. Most of them are seeking a quick and effective transition solution. As mentioned above, ICP can deploy the NAT64 as a gateway in front of their IPv4 system, but it also has the following issues: 1. if the DNS64 server is operated by an ICP, which means it would replace the original authoritative DNS server of that ICP, and then IPv6 client could never get the full content of a webpage, something on the webpage would not be displayed correctly, this phenomenon is called "dormer" problem. Normally a web page contains both interior and exterior hyperlinks; IPv6 browser can't get the content of exterior hyperlink if there are no AAAA records for that host. 2. NAT64 is unaware of the application layer protocols, so if IP address is hard-coding in the payload directly, or negotiated during the exchange of control signals, in those cases, the IPv6 client didn't resolve the domain name from the DNS64 server first, and the traffic will never go through the NAT64 gateway, then it will fail. 3. An ICP may provide multiple types of service, some of which are not supported by NAT64, such as streaming media and encryption with IPsec. 3.3. Problems Conclusion In conclusion, wherever NAT64 and DNS64 are deployed, there are still some issues to be solved, in the comparison, we found that ICP-side solutions are more focused and are more likely to help ICP migrate to IPv6 completely. The following section will describe the solution - SPACE6. It's a case-by-case solution, which means SPACE6 is designed and configured according to a particular ICP's requirements. SAPCE6 comes up with the assumption: 80 percents of the Internet traffic belong to a specific type of application, and 80 percents of which are from and toward the TOP10 ICP in the world. In fact, based on an analysis of real-time traffic of China, we found 60 percents are HTTP, and 80 percents of HTTP traffic are generated by TOP10 ICPs. Therefore, it's necessary to provide a customized IPv6 transition service, in accordance with application types and transition needs. 4. SPACE6 Specification Yang, et al. Expires December 12, 2011 [Page 6] Internet-Draft SPACE6-ICP June 2011 4.1. SPACE6 Architecture Compared with NAT64, SPACE6 solution processes the traffic from both applications and network layers; its architecture is as following: +------------------------------------------------------+ AAAA DNS+------------------------------------+ A DNS query | +----------+ +----------+ | query ----------|--| name |.......>| name |--|-------> <---------|--| modifier |<.......| resolver |--|<------- AAAA DNS| +----------+ +----------+ | A DNS response+------------------------------------+response SPACE6 DNS SPACE6 +-----------------------------------+ | +----------+ ........... | | | HTTP ALG | : XXX ALG : ... | | +----------+ ........... : | | ^ ^ : | | | / : | | | / : | | ............/ +-------+ : | | :Dispatcher:--->| NLG |-----: | | ............ +-------+ : | | ^ : | +-------|-----------------------:---+ IPv6 Interface | IPv4:Interface -------------| SPACE6 Gear :........> +------------------------------------------------------+ Figure 1: Architecture of SPACE6 SPACE6 consist of two components: SPACE6 Gear and SPACE6 DNS. Gear is in charge of the protocol translation from both application and network layers, while SPACE6 DNS is responsible for leading the traffic to SPACE6 gear. SPACE6 gear is dual-stack, it listens and receives HTTP request from IPv6 clients, afterwards it tries to get the contents from the IPv4- only ICP based on that request, and finally the contents are modified if necessary and returned back to the clients. The clients will never notice any differences with or without these processes, user experience wouldn't go down. Furthermore gear will scan the content of IP payload; so it can figure out the hard-coded IP address and any other issue that can't be solved by NAT64. Gear is composed of the Yang, et al. Expires December 12, 2011 [Page 7] Internet-Draft SPACE6-ICP June 2011 following modules: 1. Dispatcher is a virtual module, it may be the routing system or the embedded netfilter module of Linux, the duty is to identify the type of application of the received packets, and dispatch them to different ALG modules, for example, HTTP packets are sent to HTTP ALG. 2. ALG, short for Application Layer Gateway, is a module deals with one type of application, realizing some functionalities to help the intercommunication. An ALG is independent with another one; SPACE6 is extensible by the installation and removal of another ALG module. ALG can be implemented in many ways, such as a proxy, to receive an IPv6 request from the client and to send IPv4 request to the real server. 3. NLG represents Network Layer Gateway, its functionality is similar with NAT64; that is to translate the network layer protocols, and NLG supports TCP, UDP and ICMP for the moment. NLG and ALG are the core modules, they should work together, in most cases, the traffic go through SPACE6 platform are handled by the specific ALG, but there would be some ALGs that are not implemented yet, in that case, the traffic should be directed to the NLG module, for some unsupported transport layer protocols, such as media streaming, they should be handled by an ALG. As it's customized for each ICP, SPACE6 would satisfy most ICP service requirement. Regarding SPACE6 gear, the most important aspect is that how to let the IPv6 traffic accessing an ICP website to go through the SPACE6 platform, so that the gear can translate them. One possible way is to use a particular IPv6 prefix as NAT64 does, and the authoritative DNS has an AAAA record pointing to that address; but for an ALG, the only available method is to deploy a DNS server, rather than specifying an IP address directly. When applying the above method, the following factors must be taken into account: (1) The DNS servers that subscribers would use are only specified by the ISP, which means it's impossible to use an extra DNS server indicated by an third-party organization. (2) ISP's DNS servers are complicated and stability-oriented; it is not permitted to operate arbitrarily, so the ISPs are not willing to modify their existing stable DNS servers. (3) Modification of the authoritative DNS of an ICP is relatively easy, but the effective zone is only restricted within the domain of that ICP, this is the root cause of the problem "dormer". All of these above problems are concerning with the reasonable position of DNS64 deployment. Yang, et al. Expires December 12, 2011 [Page 8] Internet-Draft SPACE6-ICP June 2011 To avoid the aforementioned issues, SPACE6 DNS adopts an special implementation, it is an ordinary authoritative DNS server except for the additional module called "name modifier". SPACE6 DNS should work together with ALG modules of SPACE6 gear to lead the traffic to SPACE6 platform. Concretely speaking, SPACE6 DNS receives the AAAA query, revise the host name attribute, and then send an A query to the real DNS server of an ICP, the ICP need to add a new record pointing at SPACE6 platform. When the IPv6 traffic reaches the platform, they are translated into IPv4 traffic by the SPACE6 gear; the ALG modules of gear can rewrite the hyperlinks to make sure the subsequent DNS query are resolved by SPACE6 DNS; such DNS have some records corresponding to SPACE6 platform. SPACE6 DNS is composed of name modifier and name resolver; the first component will revise the hostname of a DNS query, while the second one synthesizes an AAAA answer responded to client. Based on the above architecture, SPACE6 is extensible and scalable. It's easy to provide new feature by installing a module, each ALG is independent with another. 4.2. Deployment Scenario SPACE6 is a transition tool to help ICP migrate to IPv6 in a fast way, this solution is customized by each ICP and is deployed in the ICP side, it's not necessary to check and recode the whole system. What is more, the solution is transparent for the IPv6 subscribers, they have nothing to configure, and the client will access the IPv6 service in the same way as IPv4. As an enclosed mechanism, SPACE6 has little impact on the ICP existing network, so it's deployment friendly. Furthermore SPACE6 is built upon cloud computing, it's flexible and extensible to support large-scale subscribers seamlessly. The deployment scenario of SPACE6 is as follow: +----------------+ +---------------+ | | +-------------+ | | +--------+ IPv4 | | IPv6 Client |---| IPv6 Internet |----| SPACE6 | | +-------------+ | | +--------+ IDC | +---------------+ | | +----------------+ Figure 2: Deployment Scenario It's recommended to deploy SPACE6 on the border of an IPv4-only IDC, Yang, et al. Expires December 12, 2011 [Page 9] Internet-Draft SPACE6-ICP June 2011 the ICP should make sure it has configured an AAAA record in the DNS pointing to SPACE6. Actually SPACE6 look like an IPv6 interface for that IPv4-only ICP, it receives the requests from the client, and send the response back to them like a real server. This draft described a scenario of communication initiated by IPv6 clients, in fact, as an application layer proxy; SPACE6 can support both directions of the intercommunication. During the early transition stage, new IPv6 subscribers would access the IPv4-only service, and upon the last stages, remaining IPv4 clients could visit the IPv6 contents, this kind of tools are very useful and necessary during the transition to IPv6. 5. Acknowledgements TBD... 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This document has no impact on the security properties of specific IPv6 transition tools. When applying SAPCE6, it is convenient and necessary to introduce the cloud-computing security mechanisms to protect the system against illegal attacks. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 8.2. Informative References [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Yang, et al. Expires December 12, 2011 [Page 10] Internet-Draft SPACE6-ICP June 2011 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. Authors' Addresses GuoLiang Yang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: iamyanggl@gmail.com Zhilan Huang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: santahzl@gmail.com Weibo LI China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: mweiboli@gmail.com Yang, et al. Expires December 12, 2011 [Page 11]