doc: Add RFC documents

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]
+