One document matched: draft-yang-v6ops-space6-icp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:43 |