v6ops Q. Sun
Internet-Draft C. Xie
Intended status: Informational Q. Liu
Expires: January 12, 2012 China Telecom
X. Li
Tsinghua University
J. Qin
ZTE
D. Liu
BII Group
July 11, 2011
Rapid Transition of IPv4 contents to be IPv6-accessible
draft-sunq-v6ops-contents-transition-01
Abstract
This document describes one deployment model of NAT64, aiming at
rapidly increasing the amount of IPv6 accessible contents for users
from IPv6 Internet.
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 January 12, 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
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
Sun, et al. Expires January 12, 2012 [Page 1]
Internet-Draft Contents Transition July 2011
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 January 12, 2012 [Page 2]
Internet-Draft Contents Transition July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transition As A Service . . . . . . . . . . . . . . . . . 5
3. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Implementation . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
4.2. DNS implementations . . . . . . . . . . . . . . . . . . . 8
4.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Logging and Statistics . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Sun, et al. Expires January 12, 2012 [Page 3]
Internet-Draft Contents Transition July 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 one deployment model of the stateful IPv4/
IPv6 translation [RFC6146],[RFC6052],[RFC6144],[RFC6145] , aiming at
rapidly increasing the amount of IPv6-reachable contents with lower
cost at the early stage of transition, for users from IPv6 Internet.
The contents can be still accessible through IPv4. While this would
be very helpful for CP/SPs to achieve rapid transition, the native
transition of contents (by "Dual-Stack") should always be
recommended.
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 [RFC2119].
2. Motivations
There have been statements from several popular content providers
that they have turned on, or planned to turn on IPv6 soon, which do
have a beneficial effect on encouraging end users' transition to
IPv6. While given the operational cost, the risk to the continuity
of service delivery and compared to the number of active IPv6 users
currently, it is difficult to convince much more content providers
(especially the great many ones of small-to-medium size) to
immediately enable IPv6 natively and make their publically-facing
services accessible through IPv6. On the other hand, 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.
Sun, et al. Expires January 12, 2012 [Page 4]
Internet-Draft Contents Transition July 2011
2.1. Transition As A Service
The deployment model of the stateful IPv4/IPv6 translation
[RFC6146],[RFC6052],[RFC6144],[RFC6145] described in this document
can be regarded as a transition service offered by the operators, to
small-to-medium size content providers (e.g. , those who rent servers
from the operators). By this means, they could make the publically-
facing services to be IPv6-accessible shortly with lower cost,
compared to the employment of "Dual-Stack" approach where the
software or codes may have to be upgraded, which requires additional
investment and expertise right away. Moreover, in this deployment
model, we can still make use of current IPv4 security infrastructures
in data centers, e.g. firewalls, IPS, etc.
For larger content providers (e.g. those who manage servers, or even
the Data Centers of their own), this deployment model can also be
attractive at the very early stage of transition (considering risks
to the service continuity, and the costs). If there are load
balancing devices deployed already, the NAT64 functional elements are
likely to be co-located on these boxes naturally.
But it should be noted that the purpose of this deployment model is
to encourage the IPv6 transition with economic justification within
given transition period. The Dual-Stack mode which is the most
straightforward approach should still be recommended to customers
from the very beginning if the costs and risks are acceptable to
them.
3. Deployment Model
The NAT64 gateway is deployed between the IPv6 Internet and the IPv4
servers[RFC6144]. See the following as an example.
+----------------+ +---------+ +--------------+
| Data Center | | NAT64 | | IPv6 |
| | --- | Gateway | --- | Internet |
| +--------+ | +---------+ +--------------+
| | IPv4 | |
| | Server | | +--------------+
| +--------+ | ----------------- | IPv4 |
| | | Internet |
+----------------+ +--------------+
In this deployment model, the Stateful NAT64 is performed to
translate IPv6 packets to IPv4 and vice versa. The guidance in
[RFC6146],[RFC6052],[RFC6144],[RFC6145] should be followed. The
Sun, et al. Expires January 12, 2012 [Page 5]
Internet-Draft Contents Transition July 2011
communications are initiated from the IPv6 side. The IPv6 node will
firstly get A/AAAA addresses of the 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.
(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 become scarce resources , private
blocks, for instance 10.0.0.0/8 may be used for the Stateful NAT64.
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].
(2)DNS
Before initiating a session, generally an IPv6 user will generate a
DNS lookup to get the AAAA records and learn the addresses of the
hosts to access. In this case, the IPv6 addresses learned through
AAAA records are those translated from the IPv4 addresses of the
server.
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.
The workflow of this model is depicted in the following Figure.
Sun, et al. Expires January 12, 2012 [Page 6]
Internet-Draft Contents Transition July 2011
+-----+-----+ --Upstream Packet Workflow Example---
| IPv6 user | |src address| 2001:c68:cc02::2 |
+-----+-----+ |dst address| 2001:c68:cf02::ca00:5 |
| +-----------------------------------+
-----|------
/ | \
| IPv6 Internet |
\ | /
------|------
| 1:1 Mapping Table
+---------|---------+ +------------------------------+
| | | | 10.0.0.1 | 2001:c68:cf02::2 |
| NAT64 GW | +------------------------------+
+---------|---------+ Translated address
| |src address| 10.0.0.1 |
------|------ |dst address| 202.0.0.5 |
/ | \ +-----------------------------
|IPv4 Data Center|
\ | /
-----|------
|
+-----+-----+
|IPv4 Server| server address: 202.0.0.5
+-----------+
4. The Implementation
The deployments of Stateful NAT64 on the server side are different
from those on the client side:
o The traffic accessing servers come from IPv6 Internet, so the
source IPv6 addresses do not belong to prefixes of any special
Service Provider's;
o It is possible to use private IPv4 blocks for the Stateful NAT64;
o The DNS implementation.
4.1. Address Mapping
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 elected for the Stateful
NAT64. By this means, 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).
Sun, et al. Expires January 12, 2012 [Page 7]
Internet-Draft Contents Transition July 2011
However, there may be conflicts if the same private space is used
internally for the interconnection of servers (e.g. multiple servers
for load balancing). In this case, N:1 mode with public blocks can
be used.
Additionally, an IPv6 prefix from the Service Provider's space is
assigned to represent the servers and form the IPv4-translated AAAA
records.
4.2. DNS implementations
To make sure the addresses of servers can be retrieved by IPv6 users
before initiating sessions, the AAAA records which are formed through
IPv4-translated addresses should be added on the domain's
authoritative DNS. The AAAA records under one domain name could be
converted from the corresponding A records.
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.
4.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.
4.4. Examples
See below for some sites that have migrated through the approach
aforementioned, and are IPv6 accessible:
Sun, et al. Expires January 12, 2012 [Page 8]
Internet-Draft Contents Transition July 2011
+-------------------------+-------------------------------+
| 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 |
+-------------------------+-------------------------------+
4.5. Logging and Statistics
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%.
5. Acknowledgements
The authors would like to thank Fred Baker, Erik Kline, Randy Bush
for their comments and feedback.
6. IANA Considerations
This document includes no request to IANA.
7. Security Considerations
The security issues and considerations discussed in [RFC6146] apply
to the deployment model described in this document.
Sun, et al. Expires January 12, 2012 [Page 9]
Internet-Draft Contents Transition July 2011
8. References
8.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.
[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.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
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 January 12, 2012 [Page 10]
Internet-Draft Contents Transition July 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 January 12, 2012 [Page 11]