Rapid Transition of IPv4 contents to be IPv6-accessible
draft-sunq-v6ops-contents-transition-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qiong Sun , Dong Liu , Qin Zhao , Qian Liu , Chongfeng Xie , Xing Li , Jacni Qin | ||
| Last updated | 2011-10-29 (Latest revision 2011-07-11) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sunq-v6ops-contents-transition-02
v6ops Q. Sun
Internet-Draft C. Xie
Intended status: Informational Q. Liu
Expires: May 1, 2012 China Telecom
X. Li
Tsinghua University
J. Qin
ZTE
D. Liu
BII Group
Q. Zhao
BUPT
October 29, 2011
Rapid Transition of IPv4 contents to be IPv6-accessible
draft-sunq-v6ops-contents-transition-02
Abstract
This document describes several deployment models for the transition
of IPv4 services to IPv6, aiming at rapidly increasing the amount of
IPv6 accessible contents for users from IPv6 Internet while
preserving the continuity of IPv4 service delivery.
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 May 1, 2012.
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
Sun, et al. Expires May 1, 2012 [Page 1]
Internet-Draft Contents Transition October 2011
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Sun, et al. Expires May 1, 2012 [Page 2]
Internet-Draft Contents Transition October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Transition As A Service . . . . . . . . . . . . . . . . . 4
4. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 5
5. IPv6-to-IPv4 communication scenario . . . . . . . . . . . . . 6
5.1. Mapping and Addressing . . . . . . . . . . . . . . . . . . 6
5.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5. Geographically aware services . . . . . . . . . . . . . . 7
5.6. ALG issues . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IPv4-to-IPv6 communication scenario . . . . . . . . . . . . . 8
6.1. Mapping and Addressing . . . . . . . . . . . . . . . . . . 8
6.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Geographically aware services . . . . . . . . . . . . . . 8
6.5. ALG issues . . . . . . . . . . . . . . . . . . . . . . . . 9
7. CDN considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix 1. Implementation Example . . . . . . . . . . . . . . . 10
1.1. Practical Deployment . . . . . . . . . . . . . . . . . . . 10
1.2. Test results for TOP 100 Websites in China . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Sun, et al. Expires May 1, 2012 [Page 3]
Internet-Draft Contents Transition October 2011
1. Introduction
The global IPv4 address depletion becomes a reality. Although the
IPv4 to IPv6 transition is considered inevitable, deployments of IPv6
are still quite limited as this document is written. Facing the
pressure of IPv4 address shortage, the operators may like to provide
services through IPv6 in some ways. However, compared to the
readiness of operators' infrastructures, the IPv6 transition on the
content provider and end user sides moves even more slowly. The lack
of IPv6-reachable contents becomes one of the main obstacles.
This document describes several deployment models for the transition
of IPv4 services to IPv6 based on the approaches specified by IETF
(e.g., NAT64 [RFC6146], Dual-Stack [RFC4213], IVI [RFC6219], etc.),
targeting different use cases or conditions.
2. 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 [RFC2119].
3. Motivations
There have been statements from several popular content providers
that they have turned on IPv6 (no matter by which means), which do
have a beneficial effect on encouraging end users' transition to
IPv6. Given the operational cost, it is difficult to convince much
more content providers (especially the great many ones of small-to-
medium size) to immediately make their publically-facing services
accessible through both IPv4 and IPv6 natively. While from the
users' perspective, the IPv6 reachability of resources required for
their daily lives is one of the foremost concerns when making the
decision on whether or not to access Internet using IPv6. It is a
chicken or egg dilemma, but the two perspectives are interdependent.
If the transition of one side passes the point of inflexion, the
other side will be speeded up after. So, more efforts are needed to
encourage the IPv6 adoption and reach the point. On the other hand,
the guarantee of IPv4 service offering continuity must be always
taken into account under any conditions.
3.1. Transition As A Service
The deployment models described in this document can be regarded as
transition services offered by the operators, to small-to-medium size
content providers (e.g. , those who rent servers from the operators).
Sun, et al. Expires May 1, 2012 [Page 4]
Internet-Draft Contents Transition October 2011
The content providers can take different approaches according to
their scenarios and business strategies. For the conservative ones,
the IPv4 services can be still offered natively, and the IPv6
services can be offered by the stateful IPv4/IPv6 translation
[RFC6146]. While for progressive ones and newly incomers, the
stateless IVI [RFC6219], [RFC6052] can be employed to offer native
IPv6 services reachable via IPv4.
4. Deployment Model
The NAT64 gateway is deployed between the IPv6 Internet and the IPv4
servers[RFC6144], as shown in the figure below.
+----------------+
+ Data Center + +--------------+
| +--------+ | | IPv6 |
| | IPv4 +--+--+ +--+ Internet |
| | Server | | | +---------+ / +--------------+
| +--------+ | | | NAT64 |/
| | +--+ Gateway |\ +--------------+
| +--------+ | | +---------+ \ | IPv4 |
| | IPv6 | | | +--+ Internet |
| | Server +--+--+ +--------------+
| +--------+ |
| |
+----------------+
Figure 1: Overall Deployment Model
In this deployment model, the NAT64 gateway is deployed in server-
side, translating IPv6 packets to IPv4 and vice versa. It is a
shared platform which can serve multiple IPv4/IPv6 servers in one
Data Center. The guidance in
[RFC6146],[RFC6052],[RFC6144],[RFC6145],[RFC6146] and [RFC6052]
should be followed. However, since NAT64 is now deployed in server-
side, some special considerations should be taken into considerations
(discussed in Section 5, and 6).
For communications initiated from the IPv6 side to an IPv4 server, a
stateful NAT64 would be needed to perform IPv6-to-IPv4 translation.
Notice that the server-side deployment is independent of the client-
side deployment, which encourages that IPv6 traffic should be
preferred from the beginning when IPv6 users are available. So, IPv6
traffic will be routed to the NAT64 gateway even when NAT444/DS-Lite
is deployed in client-side.
For communications initiated from the IPv4 side to an IPv6 server , a
Sun, et al. Expires May 1, 2012 [Page 5]
Internet-Draft Contents Transition October 2011
stateless IVI can be performed with 1:1 mapping. In both situations,
A/AAAA addresses can be added directly in DNS authoritative servers
in advance, which is the most straightforward way to deploy.
5. IPv6-to-IPv4 communication scenario
In this scenario, the IPv6 node will firstly get A/AAAA records of
the content server from DNS, and then the communication will follow
the path to NAT64 Gateway. When an IPv6 packet arrives at NAT64
Gateway, a lookup of the mapping table will be carried out to get the
IPv4 address used for the translation. If there is no one matched, a
new entry will be created.
When deploying stateful NAT64 in server side, special considerations
should be taken into with regard to address mapping, DNS
implementation, Fragmentation, logging, geographically aware
services, and ALG issues.
5.1. Mapping and Addressing
The Stateful NAT64 can be operated in either of the two mapping
modes:
o 1:1, one IPv6 address is mapped to one IPv4 address (exclusively
for given lifetime);
o N:1, each of the IPv4 addresses (i.e. IPv4 address pool) will be
shared by multiple IPv6 users from Internet.
To save global IPv4 addresses which has become scarce resource ,
private blocks, for instance 10.0.0.0/8 may be used for the Stateful
NAT64. This private address block can only be seen within the IDC in
question. In addition, an IPv6 prefix is needed to represent the
IPv4 server, and the route of the prefix should be advertised to the
IPv6 Internet. The IPv4 address of the server can be embedded in the
IPv6 prefix following the algorithm specified in [RFC6052].
Considering the scale of traffic in the foreseeable future, the 1:1
Mapping Mode with private blocks (one IPv6 address mapped to one
private IPv4 address within 10.0.0.0/8) is selected for the Stateful
NAT64. By this mean, the efficiency of stateful operations could be
improved and the problems introduced by the address sharing could be
alleviated (for example, the burden of logging will be reduced in
this mode).
However, there may be conflicts if the same private space is used
internally for the interconnection of servers (e.g. multiple servers
Sun, et al. Expires May 1, 2012 [Page 6]
Internet-Draft Contents Transition October 2011
for load balancing). In this case, N:1 mode with public blocks can
be used. In order to reduce state management burden in N:1 stateful
NAT64 gateway as well as logging system, a bulk of ports can be
allocated for each subscriber.
Additionally, an IPv6 prefix from the Service Provider's space is
assigned to represent the servers and form the IPv4-translated AAAA
records.
5.2. DNS
To make sure the addresses of servers can be retrieved by IPv6 users
before initiating sessions, the AAAA records which formed through
IPv4-translated addresses should be added directly on the domain's
authoritative DNS, or upgrade authoritative DNS to support DNS64. In
this way, the AAAA records under one domain name could be retrieved
by IPv6 users around the world.
Please note that if the authoritative DNS of given Content Providers'
domain names are maintained by some third-party DNS Providers but not
by themselves or the operator from whom this transition service (i.e.
the deployment model of Stateful NAT64 discussed herein) is
purchased, the Content Providers must make sure the authoritative
AAAA records can be added.
5.3. Fragmentation
Basically, the processing of packets carrying fragments follows the
guidance specified in [RFC6145] and [RFC6146] with exceptions that
fragmented IPv4/IPv6 packets will be firstly reassembled to an
integrated packet before doing packet translation and so on.
5.4. Logging
The logging is essential for tracing back specific users in stateful
NAT64. In 1:1 mode, only per-user logging events need to be recorded
as {IPv6 address, IPv4 address, timestamp}. However, for N:1 mode,
it is recommended that subscriber-based logging with port range
should be adopted, e.g. {IPv4 address, IPv6 address, port range,
timestamp}.
5.5. Geographically aware services
Since converted IPv4 address would not represent any geographical
feature anymore, applications that assume such geographic information
may not work as intended.
One possible solution is to maintain the above logging information in
Sun, et al. Expires May 1, 2012 [Page 7]
Internet-Draft Contents Transition October 2011
geographic server as well, and offer an open API to Content Providers
to retrieve its original IPv6 address when necessary. Another
possibility the application could rely on location information such
as GPS co-ordination to identify the user's location, which is
commonly used in mobile deployment.
5.6. ALG issues
Since the types of applications are relatively limited due to the
deployment policy, it would be easier to solve the ALG issue compared
to client-side deployment. For example, Web-based content providers
might be introduced in the first stage, and so specific ALGs can be
applied according. Note that the connections may fail in case of
IPv4 address literals. Refer to
[I-D.wing-behave-http-ip-address-literals] for more details.
6. IPv4-to-IPv6 communication scenario
In this scenario, the IPv4 node will firstly get A/AAAA records of
the server from DNS, and then the communication will follow the path
to NAT64 Gateway. When an IPv4 packet arrives at NAT64 Gateway, it
would be translated to an IPv6 packet based on stateless 1:1 mapping
algorithm [RFC6219].
6.1. Mapping and Addressing
In stateless IVI, IPv6-only server should be configured with an IPv4-
translatable address. Then, both source address and destination
address are applied with 1:1 mapping to keep the simplicity and
transparency.
6.2. DNS
To make sure that addresses of servers can be retrieved by IPv4 users
before initiating sessions, the A records which are extracted from
IPv4-translated addresses should be added directly on the domain's
authoritative DNS, or upgrade authoritative DNS to support DNS64.
Other considerations are actually the same with Section 3.
6.3. Logging
There is no logging issue in stateless IVI translation.
6.4. Geographically aware services
When a content provider gets an IPv4-converted IPv6 addresses with a
pre-defined Prefix, it should extract the embedded IPv4 address which
Sun, et al. Expires May 1, 2012 [Page 8]
Internet-Draft Contents Transition October 2011
would reflects its original geographical information.
6.5. ALG issues
ALG issues would be the same with section 5.6.
7. CDN considerations
Currently, content delivery networks have widely deployed address-
based scheduling policy for load balancing, server selection, etc.,
and address-embedded URL would be carried in HTTP payload directly.
This would have great impact on a great many applications (as
indicated in Appendix experimental result). Thus, the scheduler may
need to integrate with NAT64 module to reply IPv4-translatable IPv6
addresses in HTTP payload, when receiving IPv4 requests from
translated source address within a configured NAT64 IPv4 address
pool.
However, when Content Service Providers only supports IPv6 at some of
their POPs, the situation would be complicated. In this case, the
scheduler needs to determine the network environment of different
POPs and then return IPv4-translatable IPv6 address when necessary.
8. IANA Considerations
This document includes no request to IANA.
9. Security Considerations
The security issues and considerations discussed in [RFC6146] apply
to the deployment model described in this document. However, when
deploying stateful NAT64 in server side, it is hard to apply source-
based filtering policy. As a result, additional mechanisms such as
system alarming to report state-consuming status and speed will to be
introduced as well.
10. Acknowledgements
The authors would like to thank Fred Baker, Joel Jaeggli, Erik Kline,
Randy Bush for their comments and feedback.
11. References
Sun, et al. Expires May 1, 2012 [Page 9]
Internet-Draft Contents Transition October 2011
11.1. Normative References
[I-D.wing-behave-http-ip-address-literals]
Wing, D., "Coping with IP Address Literals in HTTP URIs
with IPv6/IPv4 Translators",
draft-wing-behave-http-ip-address-literals-02 (work in
progress), March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[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.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219, May 2011.
11.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
1. Implementation Example
1.1. Practical Deployment
The server-side deployments of NAT64 has been carried out in China
Telecom and Cernet2.
The deployment topology is depicted as follows:
Sun, et al. Expires May 1, 2012 [Page 10]
Internet-Draft Contents Transition October 2011
+----------------+ +---------+
+ Data Center + | Syslog | +--------------+
| +--------+ | +----+----+ | IPv6 |
| | IPv4 +--+--+ | +--+ Internet |
| | Server | | | +----+----+ / +--------------+
| +--------+ | | | NAT64 |/
| | +--+ Gateway |\ +--------------+
| +--------+ | | +----+----+ \ | IPv4 |
| | IPv6 | | | | +--+ Internet |
| | Server +--+--+ +----+----+ +--------------+
| +--------+ | |geograph-|
| | |ication |
+----------------+ +---------+
Figure 2: Deployment topology
See below for some sites that have migrated through the approach
aforementioned, and are IPv6 accessible:
+-------------------------+-------------------------------+
| Content Provider | Categories |
+-------------------------+-------------------------------+
| www.2118.com.cn | News, BBS, E-commerce, Video |
+-------------------------+-------------------------------+
| www.5460.net | BBS, Album |
+-------------------------+-------------------------------+
| www.118326.com | News, Video |
+-------------------------+-------------------------------+
| www.hnradio.com | Video |
+-------------------------+-------------------------------+
| www.voc.com.cn | News, BBS, E-commerce, Video |
+-------------------------+-------------------------------+
| www.chinatelecom.com.cn | News, BBS, Recruitment |
+-------------------------+-------------------------------+
Up to now, there are more than 15 thousands different IPv6 users ever
accessing the above six Content Providers through the NAT64 box
totally, with 6000 to 7000 active users every day. "www.voc.com.cn"
is the most popular one accessed by more than 4000 IPv6 users daily,
and www.chinatelecom.com.cn (the official website of china telecom)
has amounts of access from 1200 IPv6 users on average every day.
The IPv6 users aforementioned are located worldwide. More than 91
percent come from CERNET2, and the rest are from China telecom, USA,
Australia, Finland, etc. The total percentage of 6to4 users accounts
for approximately 3.2%.
Sun, et al. Expires May 1, 2012 [Page 11]
Internet-Draft Contents Transition October 2011
1.2. Test results for TOP 100 Websites in China
We have tested TOP 100 websites in China with stateful NAT64, in
which both dual-stack and IPv6-only access scenarios have been
included. Our major objective is to verify the ALG issues in popular
websites.
Figure 3: Experimental Topology
+----------------+ +--------+ +--------------+
| IPv4 Internet | | DNS64 +------+ IPv6 |
| + +--------+ +--+ Network |
| +--------+ | +---------+ / +--------------+
| | IPv4 | | | NAT64 |/
| | Server +--+-----+ Gateway |\ +--------------+
| +--------+ | +---------+ \ | IPv4 |
| | +--+ Network |
| | +--------------+
+----------------+
The test results have shown that there is no service brokenness in
dual-stack access environment, and IPv6 transmission would be
preferred in non-ALG case. However, for IPv6-only users, we have
found an interesting phenomena: 90 percentage of comprehensive
websites(like sina, 163.com, etc) would not have IPv4 address literal
problem for their video service, while more than 90% of video
websites (like youku, tudou, etc) do have ALG problem which embedding
IPv4 address directly. It is mainly because video websites have
rented CDN servers from third-party CSPs providers, who make use of
address-based scheduling policy as in section 7. It is important to
solve the CDN problem in IPv6 transition.
Authors' Addresses
Qiong Sun
China Telecom
Room 708 No.118, Xizhimenneidajie
Beijing, 100035
P.R.China
Phone: +86 10 5855 2923
Email: sunqiong@ctbri.com.cn
Sun, et al. Expires May 1, 2012 [Page 12]
Internet-Draft Contents Transition October 2011
Chongfeng Xie
China Telecom
Room 708 No.118, Xizhimenneidajie
Beijing, 100035
P.R.China
Phone: +86 10 5855 2116
Email: xiechf@ctbri.com.cn
Qian Liu
China Telecom
No.359 Wuyi Rd.,
Changsha, Hunan 410011
P.R.China
Phone: +86 731 8226 0127
Email: 18973133999@189.cn
Xing Li
Tsinghua University
Room 225, Main Building
Beijing 100084
P.R.China
Phone: +86 10 6278 5983
Email: xing@cernet.edu.cn
Jacni Qin
ZTE
Shanghai,
China
Phone: +86 1391 861 9913
Email: jacniq@gmail.com
Dong Liu
BII Group
Beijing 100028
P.R.China
Phone: +86 138 0103 2487
Email: dliu@biigroup.com
Sun, et al. Expires May 1, 2012 [Page 13]
Internet-Draft Contents Transition October 2011
Qin Zhao
BUPT
Beijing 100876
P.R.China
Phone: +86 138 1127 1524
Email: zhaoqin@bupt.edu.cn
Sun, et al. Expires May 1, 2012 [Page 14]