Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6180 Ericsson
Category: Informational F. Baker
ISSN: 2070-1721 Cisco Systems
May 2011
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
Abstract
The Internet continues to grow beyond the capabilities of IPv4. An
expansion in the address space is clearly required. With its
increase in the number of available prefixes and addresses in a
subnet, and improvements in address management, IPv6 is the only real
option on the table. Yet, IPv6 deployment requires some effort,
resources, and expertise. The availability of many different
deployment models is one reason why expertise is required. This
document discusses the IPv6 deployment models and migration tools,
and it recommends ones that have been found to work well in
operational networks in many common situations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6180.
Arkko & Baker Informational [Page 1]
RFC 6180 IPv6 Transition Guidelines May 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Arkko & Baker Informational [Page 2]
RFC 6180 IPv6 Transition Guidelines May 2011
1. Introduction
The Internet continues to grow beyond the capabilities of IPv4. The
tremendous success of the Internet has strained the IPv4 address
space, which is no longer sufficient to fuel future growth. At the
time of this writing, August 2010, the IANA "free pool" contains only
14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on
past behavior suggest that the Regional Internet Registries (RIRs)
will exhaust their remaining address space by early 2012, apart from
the development of a market in IPv4 address space. An expansion in
the address space is clearly required. With its increase in the
number of available prefixes and addresses in a subnet, and