v6ops J. Qin
Internet-Draft ZTE
Intended status: Informational G. Liu
Expires: April 22, 2010 China Telecom
October 19, 2009
Recommendations for the ISPs' provision of IPv6 transition services to
the ICPs
draft-qin-v6ops-icp-transition-00
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 April 22, 2010.
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.
Abstract
The exhaustion of IPv4 addresses is coming, while due to many
Qin & Liu Expires April 22, 2010 [Page 1]
Internet-Draft ICP Transition October 2009
reasons, no significant IPv6 deployment has occured. The transition
of users, networks and services from IPv4 to IPv6 is not so smoothly
and expeditiously as expected. The solutions now available are not
sufficient for all the scenarios, so the IPv6 deployment models are
revisited, and some new methods used for transition have been
developed to complement the existing ones. This document discusses
the transition of services and the use of these new mechanisms from
the ISP's point of view to provide approaches to the transition for
ICPs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Dual Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 5
2.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 5
3. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 7
3.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 7
4. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Operational Issues . . . . . . . . . . . . . . . . . . . . 8
4.2. Requests to ICPs . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Qin & Liu Expires April 22, 2010 [Page 2]
Internet-Draft ICP Transition October 2009
1. Introduction
The exhaustion of IPv4 addresses is coming, while due to many
reasons, no significant IPv6 deployment has occured. The transition
of users, networks and services from IPv4 to IPv6 is not so smoothly
and expeditiously as expected. The solutions now available are not
sufficient for all the scenarios, so the IPv6 deployment models are
revisited, and some new methods used for transition have been
developed to complement the existing ones. This document discusses
the transition of services and the use of these new mechanisms from
the ISP's point of view to provide approaches to the transition for
ICPs.
The transition of services to IPv6 will get started in succession
from now or sooner in the future. As we all know, the IPv4 users or
various Requests to IPv4 services dominate in current networks, and
even in the future the co-existence of IPv4 and IPv6 will persist for
a long time. so how to preserve the continuity and availability of
legacy services while migrating to IPv6 concerns ICPs deeply. Since
ICPs have different requirements of service level agreement, some
care mostly about the stability and User Experience, and some care
about the cost of migration mostly, the ISP should choose different
migration solutions for ICPs to meet their needs and help them
migrating to IPv6 rapidly. Some recommendations on how to do it are
given in this document.
Approaches
Dual Stack
In order to provide full functional services for both IPv4 and IPv6,
Dual stack may be a good choice. It has less limitations and is
suitable for ICPs that require high availability. While it may be
not cost efficient compared to the utilization of the IPv6 stack
especially at the early stage of transition, so may be not acceptable
to all.
NAT64
There must be some conservative ICPs that are sensitive to the cost
and possible interruption caused by the migration. They want to make
experimental provision of IPv6 services firstly based on current
infrastructures with no change or the system platforms that are not
upgradable. In this case, one could use some translation mechanism
for the communication initiated from IPv6 Internet.
IVI
Qin & Liu Expires April 22, 2010 [Page 3]
Internet-Draft ICP Transition October 2009
On the other hand, there are some radical ICPs relatively that wish
to migrate to IPv6 purely without IPv4 stack enabled, or maybe at
later stage more IPv6-only servers are put in the network, while
under the pressure of large quantity of IPv4 users, the reachability
for them needs to be preserved. IVI is fit for this case.
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. Dual Stack
As specified in RFC4213, Dual Stack is the most well understood and
recommended approach today providing complete implementations for
both IPv4 and IPv6. Through Dual Stack routing infrastructure, the
Dual Stack servers could interoperate with IPv4 and IPv6 user devices
respectively using IPv4 and IPv6. Of course, both stack and
application capabilities of IPv4 and IPv6 must be enabled on the
"Dual Stack servers". For the application aspects of transition,
please refer to RFC4038.
Qin & Liu Expires April 22, 2010 [Page 4]
Internet-Draft ICP Transition October 2009
+------------------------+
| IDC +------------+ |
| | Dual-Stack | |
| | servers | |
| +------+-----+ |
| IPv6 address |& IPv4 address
| | |
| +------+-----+ |
| | Dual-Stack | |
| | router | |
| +--+------+--+ |
+-----------|------|-----+
| | | |
IPv6 prefix | | | | IPv4 prefix
announced | | | | announced
Y | | Y
+----------------------|-+ +-|----------------------+
| +--------+ | | +--------+ |
| | V6 DNS | | | | V4 DNS | |
| | server | | | | server | |
| +--------+ | | +--------+ |
| | | |
| IPv6 Network | | IPv4 Network |
| | | |
| | | |
+------------------------+ +------------------------+
2.1. Operational Issues
For Dual stack mechanism, more issues may come from the business
aspect rather than techniques, which are about how to better align
the costs and benefits of the migration. We only discuss the
technical issues of all these approaches here.
The migration can not be done in one day, the issues of adding DNS
records should be considered in cases where some services are more
IPv6-ready than others.
MORE, TBD..
2.2. Requests to ICPs
The system software of the servers should be upgradable, and the
hardware may need to be upgraded to support both IPv4 and IPv6
capabilities, as more resources like memery are needed to run two
sets of stacks and applications concurrently.
Further more, based on new API, some service applications may need to
Qin & Liu Expires April 22, 2010 [Page 5]
Internet-Draft ICP Transition October 2009
be redeveloped, see RFC3493 and RFC3542 about the API for IPv6.
3. NAT64
NAT64 defines a stateful translation mechanism used for communication
between IPv4 and IPv6 nodes, the suitable scenarios include "an IPv6
network to the IPv4 Internet" and "the IPv6 Internet to an IPv4
network", implying that the communication should be iniciated from
the IPv6 side. The latter scenario applies to the case here.
+------------------------+
| IDC +------------+ |
Stateful | | IPv4 | |
Translation: | | servers | |
| +------+-----+ |
| IPv4|address |
| | |
+-------------+ +------+-----+ |
| v4 pool for | | Dual-Stack | |
| v6 network | | router | |
+-------------+ | with NAT64 | |
| +--+------+--+ |
+-----------|------|-----+
| | | |
IPv6 prefix announced | | | | IPv4 prefix
-of servers in IDC | | | | announced
Y | | Y
+----------------------|-+ +-|----------------------+
| +--------+ | | +--------+ |
| | V6 DNS | | | | V4 DNS | |
| | server | | | | server | |
| +--------+ | | +--------+ |
| | | |
| IPv6 Network | | IPv4 Network |
| | | |
| | | |
+--------------------\---+ +---/--------------------+
\ /
\ /
+--------+
| DNS64 |
| server |
+--------+
Qin & Liu Expires April 22, 2010 [Page 6]
Internet-Draft ICP Transition October 2009
3.1. Operational Issues
At least on IPv4 address pool used for translation should be
configured on the GW and the capacity is limited by the size of the
pool which is for the whole IPv6 Internet. Then one has to determine
where and how to deploy the DNS64 server which is used for
synthesizing AAAA records from A records using special IPv6 prefix.
Moreover, all the limitations of translators apply here.
MORE, TBD..
3.2. Requests to ICPs
Nearly no changes are required in the servers, while there will be
information lost during the translation, so necessary functional
tests may be needed before the migration and deployment of some
services in this way.
4. IVI
IVI is a stateless translation mechanism, the nodes are configured
with IVI format IPv6 addresses which are formed by embedding IPv4
addresses in IPv6 prefixes. They appear as normal IPv6 nodes in the
IPv6 network. Meantime, the IVI nodes are connected to the legacy
IPv4 Internet by IVI boxes which appear as normal IPv4 routers or
gateways. So the communications with IPv6 nodes could be achieved
directly, and the communications with IPv4 Internet could be achieved
via the stateless translator, IVI.
| n | 32 | 96-n |
+------------+--------------+--------+
|IPv6 prefix | IPv4 address | suffix |
+------------+--------------+--------+
/
/
original address
Qin & Liu Expires April 22, 2010 [Page 7]
Internet-Draft ICP Transition October 2009
+------------------------+
| IDC +------------+ |
| | IPv6 | |
| | servers | |
| +------+-----+ |
| IPv6|address (IVI format)
| | |
| +------+-----+ |
| | Dual-Stack | | Stateless
| | router | | Translation:
| | with IVI | |
| +--+------+--+ |
+-----------|------|-----+
| | | |
IPv6 prefix | | | | IPv4 prefix announced
announced | | | | -based on original addresses
Y | | Y
+----------------------|-+ +-|----------------------+
| +--------+ | | +--------+ |
| | V6 DNS | | | | V4 DNS | |
| | server | | | | server | |
| +--------+ | | +--------+ |
| | | |
| IPv6 Network | | IPv4 Network |
| | | |
| | | |
+------------------------+ +------------------------+
4.1. Operational Issues
One should better use the servers' original IPv4 addresses to form
the IVI format IPv6 addresses, that will maintain the stability of
the legacy IPv4 routing infrastructure. The part of network where
the IVI nodes are located should be designed accordingly.
4.2. Requests to ICPs
TBD.
5. IANA Considerations
This document includes no request to IANA.
6. Security Considerations
WILL BE ADDED IN THE NEXT VERSION..
Qin & Liu Expires April 22, 2010 [Page 8]
Internet-Draft ICP Transition October 2009
7. References
7.1. Normative References
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-00 (work in progress),
August 2009.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-00 (work in progress), July 2009.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-01 (work in progress),
September 2009.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in
progress), September 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work
in progress), October 2009.
[I-D.xli-behave-ivi]
Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 Coexistence and Transition", draft-xli-behave-ivi-02
(work in progress), June 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
Qin & Liu Expires April 22, 2010 [Page 9]
Internet-Draft ICP Transition October 2009
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
7.2. Informative References
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
July 2008.
Authors' Addresses
Jacni Qin
ZTE
Shanghai,
P.R.China
Phone: +86 1391 861 9913
Email: jacniq@gmail.com
Qin & Liu Expires April 22, 2010 [Page 10]
Internet-Draft ICP Transition October 2009
Guangyi Liu
China Telecom
Guangzhou,
P.R.China
Phone: +86 20 3863 9762
Email: liugy@gsta.com
Qin & Liu Expires April 22, 2010 [Page 11]