summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5211.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5211.txt')
-rw-r--r--doc/rfc/rfc5211.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5211.txt b/doc/rfc/rfc5211.txt
new file mode 100644
index 0000000..add70b0
--- /dev/null
+++ b/doc/rfc/rfc5211.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group J. Curran
+Request for Comments: 5211 July 2008
+Category: Informational
+
+
+ An Internet Transition Plan
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+IESG Note
+
+ This RFC is not a candidate for any level of Internet Standard. The
+ IETF disclaims any knowledge of the fitness of this RFC for any
+ purpose and notes that the decision to publish is not based on IETF
+ review apart from IESG review for conflict with IETF work. RFC
+ Editor has chosen to publish this document at its discretion. See
+ RFC 3932 for more information.
+
+Abstract
+
+ This memo provides one possible plan for transitioning the Internet
+ from a predominantly IPv4-based connectivity model to a predominantly
+ IPv6-based connectivity model.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Requirements Language ......................................2
+ 2. A Phased Transition Model .......................................2
+ 2.1. Preparation Phase - Present to December 2009 ...............3
+ 2.2. Transition Phase - January 2010 to December 2011 ...........4
+ 2.3. Post-Transition Phase - January 2012 to the Future .........4
+ 3. Summary .........................................................5
+ 4. Security Considerations .........................................5
+ 5. IANA Considerations .............................................5
+ 6. Acknowledgments .................................................6
+ 7. References ......................................................6
+ 7.1. Normative References .......................................6
+ 7.2. Informative References .....................................6
+
+
+
+
+
+
+
+
+Curran Informational [Page 1]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+1. Introduction
+
+ This memo provides one possible plan for transitioning the Internet
+ from a predominantly IPv4-based connectivity model to a predominantly
+ IPv6-based connectivity model.
+
+ Other transition plans are possible and this purely informational
+ document does not create an obligation on any party to undertake any
+ of the actions specified herein, and the use of requirements language
+ per RFC 2119 is only for the purpose of clearly describing the
+ proposed transition plan in unambiguous terms.
+
+ The motivation for an Internet-wide transition plan is to facilitate
+ coordination of expectations among innumerable, highly decentralized
+ entities during a period of significant change, thus reducing risk to
+ the defining Internet property of universal connectivity.
+
+ The purpose of specifying this particular transition plan is to allow
+ for overall assessment of the challenges of accomplishing the desired
+ transition and to continue the discussion of Internet-wide transition
+ plans in general.
+
+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].
+ RFC 2119 defines the use of these key words to help make the intent
+ of Standards Track documents as clear as possible. While not a
+ Standards Track document, the same key words are used in this
+ document only for sake of clarity in describing the proposed
+ transition plan.
+
+2. A Phased Transition Model
+
+ It is not reasonable to specify the changes that each and every
+ system connected to the Internet must undergo in order to achieve the
+ desired transition, as the number of connected systems precludes
+ creating one plan that contains such a level of detail. Further,
+ while there are common scenarios that may be specified for
+ transitioning individual networks (refer to [RFC3750] and [RFC4057]
+ for examples), the specific timeline and mechanisms utilized for a
+ given network will be unique. Despite these challenges, it is
+ necessary to coordinate expectations on an overall basis so that
+ Internet-wide connectivity is maintained throughout the transition.
+
+
+
+
+
+
+Curran Informational [Page 2]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+ This document specifies a three-phase transition plan that includes
+ preparation, transition, and post-transition phases, and delineates
+ the necessary activities within each phase based on the role that an
+ organization plays in the provision and use of Internet services.
+
+ An important distinction made in this transition plan is identifying
+ the explicit requirement for existing end-site organizations to add
+ IPv6-based connectivity to their public-facing servers during a
+ transition phase. An accelerated adoption of IPv6 for public-facing
+ servers enables new organizations in the post-transition phase to be
+ connected to the Internet only via IPv6 and still have access to a
+ substantial representative base of publicly available servers.
+
+ For nearly every organization, the task of IPv6-enabling their
+ public-facing servers is far easier than undertaking an
+ organization-wide adoption of IPv6. Still, the requirement for
+ existing Internet-connected organizations to add IPv6 connectivity
+ (even to a small number of systems) will be a significant hurdle and
+ require a level of effort that may not be achievable given the lack
+ of compelling additional benefits to these organizations [RFC1669].
+ This transition plan presumes that "connectivity is its own reward"
+ [RFC1958] and that there still exists a sufficient level of
+ cooperation among Internet participants to make this evolution
+ possible.
+
+ The three proposed phases are: Preparation Phase, Transition Phase,
+ and Post-Transition Phase. The timeline for the phases has been set
+ to allow entry to the Post-Transition Phase prior to the projected
+ IPv4 address pool exhaustion date [IPUSAGE].
+
+2.1. Preparation Phase - Present to December 2009
+
+ In the Preparation Phase, Service Providers pilot test their IPv6
+ network services, and end-site organizations prepare to provide
+ Internet-facing services via IPv6-based connectivity while continuing
+ to provide Internet-facing services via IPv4 connectivity.
+
+ During the Preparation Phase, the following principles apply:
+
+ PREP1: Service Providers SHOULD offer pilot IPv6-based Internet
+ Service to their Internet customers. IPv6-based Internet
+ Service MAY be provided via IPv6 transition mechanisms (such
+ as those described in [RFC4213], for example) or via native
+ IPv6 network service.
+
+
+
+
+
+
+
+Curran Informational [Page 3]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+ PREP2: Organizations SHOULD arrange for IPv6-based Internet
+ connectivity for any Internet-facing servers (e.g., web,
+ email, and domain name servers). Internet-facing IPv6 servers
+ in this phase SHOULD use separate service names per [RFC4472]
+ to avoid impact to production IPv4-based services unless the
+ organization supports production IPv6 connectivity.
+
+ PREP3: Organizations MAY provide IPv6-based Internet connectivity to
+ internal user communities.
+
+2.2. Transition Phase - January 2010 to December 2011
+
+ In the Transition Phase, Service Providers offer production IPv6 and
+ IPv4 services to their Internet customers. End-site organizations
+ provide Internet-facing services in a production manner via IPv6-
+ based connectivity in addition to IPv4-based connectivity.
+
+ During the Transition Phase, the following principles apply:
+
+ TRANS1: Service Providers MUST offer IPv6-based Internet Service to
+ their Internet customers. IPv6-based Internet Service SHOULD
+ be via native IPv6 network service but MAY be via IPv6
+ transition mechanisms if necessary.
+
+ TRANS2: Organizations MUST arrange for IPv6-based Internet
+ connectivity for any Internet-facing servers (e.g., web,
+ email, and domain name servers). Internet-facing IPv6
+ servers SHOULD be treated as production by the organization,
+ and SHOULD be treated as production by other Internet
+ organizations.
+
+ TRANS3: Organizations SHOULD provide IPv6-based Internet connectivity
+ to their internal user communities, and provide IPv6 internal
+ supporting servers (e.g., DNS, DHCP). IPv6-based Internet
+ connectivity MAY be via native IPv6 network service or MAY be
+ via IPv6 transition mechanisms.
+
+2.3. Post-Transition Phase - January 2012 to the Future
+
+ In the Post-Transition Phase, end-site organizations provide all
+ Internet-facing services via IPv6-based connectivity, thus allowing
+ for new Internet customers connected solely by IPv6.
+
+ During the Post-Transition Phase, the following principles apply:
+
+ POST1: Service Providers MUST offer IPv6-based Internet Service to
+ their Internet customers. IPv6-based Internet Service SHOULD
+ be via native IPv6 network service.
+
+
+
+Curran Informational [Page 4]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+ POST2: Organizations MUST arrange for IPv6-based Internet
+ connectivity for any Internet-facing servers (e.g., web,
+ email, and domain name servers). Internet-facing IPv6 servers
+ MUST be treated as production by the organization, and SHOULD
+ be treated as production by other Internet organizations.
+
+ POST3: Organizations SHOULD provide IPv6-based Internet connectivity
+ to internal user communities, and provide IPv6 internal
+ supporting infrastructure (e.g., routers, DNS, DHCP, etc).
+ IPv6-based Internet connectivity SHOULD be via native IPv6
+ network service or MAY be via IPv6 transition mechanisms.
+
+ POST4: Service Providers MAY continue to offer IPv4-based Internet
+ connectivity to their Internet customers. Organizations MAY
+ continue to use IPv4-based Internet connectivity.
+
+3. Summary
+
+ In order to facilitate full Internet-wide connectivity during the
+ transition from IPv4-based connectivity to IPv6-based connectivity, a
+ transition plan which provides clear guidance to organizations
+ regarding expectations is necessary. As the specific expectations
+ change over time, and vary greatly by organization, a phased approach
+ is specified in this document, with the timeline for each phase set
+ with the intention of allowing enough time for the necessary planning
+ and deployment steps which each organization much undertake. This
+ Internet Transition Plan provides for transition to predominantly
+ IPv6-connectivity by January 2012 which, with careful management, may
+ meet the overall requirements of allowing the Internet to scale as
+ specified in "The Recommendation for the IP Next Generation Protocol"
+ [RFC1752].
+
+4. Security Considerations
+
+ This memo describes the transition of the Internet from IPv4-based
+ connectivity to predominantly IPv6-based connectivity. This change
+ inherently has security implications due to the widespread deployment
+ of a new version of the Internet Protocol but these are beyond the
+ scope of this document and are covered in [RFC4942]. This document
+ raises no new security issues itself.
+
+5. IANA Considerations
+
+ While no new name or identifier space is created by this document,
+ the policies for management of Internet Protocol version 4 (IPv4)
+ address space may not provide for IPv4 availability through the
+ Transition Phase as intended by this plan. The IANA should work with
+
+
+
+
+Curran Informational [Page 5]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+ all parties to develop policies per [RFC2050] which allow continued
+ general availability of IPv4 address resources sufficiently long for
+ any transition plan that receives widespread community support.
+
+6. Acknowledgments
+
+ This document would not have been possible without the abundant
+ suggestions made by members of the Internet community at large, but
+ specific thanks go to Fred Baker, Jim Bound, Scott Bradner, Bob
+ Braden, Randy Bush, David Divins, Geoff Huston, Chris Morrow, Jordi
+ Palet, Ken Shores, James Woodyatt, and the members of the IETF V6
+ Operations Working Group for their review and insightful suggestions
+ for improvement.
+
+7. References
+
+7.1. Normative References
+
+ [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.
+
+ [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
+ Considerations and Issues with IPv6 DNS", RFC 4472, April
+ 2006.
+
+ [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP
+ Next Generation Protocol", RFC 1752, January 1995.
+
+7.2. Informative References
+
+ [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
+ Internet", RFC 1958, June 1996.
+
+ [RFC1669] Curran, J., "Market Viability as a IPng Criteria", RFC
+ 1669, August 1994.
+
+ [IPUSAGE] Huston, G., IPv4 Address Report, February 2008,
+ <http://www.potaroo.net/tools/ipv4/index.html>.
+
+ [RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC
+ 4057, June 2005.
+
+ [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der
+ Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC
+ 3750, April 2004.
+
+
+
+Curran Informational [Page 6]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+ [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
+ J. Postel, "Internet Registry IP Allocation Guidelines",
+ BCP 12, RFC 2050, November 1996.
+
+ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
+ Transition/Co-existence Security Considerations", RFC
+ 4942, September 2007.
+
+Author's Address
+
+ John Curran
+ 99 Otis Street
+ Cambridge, MA USA 20190
+
+ EMail: jcurran@istaff.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Curran Informational [Page 7]
+
+RFC 5211 An Internet Transition Plan July 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78 and at http://www.rfc-editor.org/copyright.html,
+ and except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Curran Informational [Page 8]
+