From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5211.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc5211.txt (limited to 'doc/rfc/rfc5211.txt') 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, + . + + [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] + -- cgit v1.2.3