doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3701.txt b/doc/rfc/rfc3701.txt
new file mode 100644
index 0000000..3c45973
--- /dev/null
+++ b/doc/rfc/rfc3701.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                            R. Fink
+Request for Comments: 3701                                     R. Hinden
+Obsoletes: 2471                                               March 2004
+Category: Informational
+
+
+            6bone (IPv6 Testing Address Allocation) Phaseout
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   The 6bone was established in 1996 by the IETF as an IPv6 Testbed
+   network to enable various IPv6 testing as well as to assist in the
+   transitioning of IPv6 into the Internet.  It operates under the IPv6
+   address allocation 3FFE::/16 from RFC 2471.  As IPv6 is beginning its
+   production deployment it is appropriate to plan for the phaseout of
+   the 6bone.  This document establishes a plan for a multi-year
+   phaseout of the 6bone and its address allocation on the assumption
+   that the IETF is the appropriate place to determine this.
+
+   This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",
+   December, 1998.  RFC 2471 will become historic.
+
+1.  Introduction
+
+   The 6bone IPv6 Testbed network was established in March 1996,
+   becoming operational during the summer of 1996 using an IPv6 testing
+   address allocation of 5F00::/8 [TEST-OLD] that used the original (and
+   now obsolete) provider based unicast address format.  In July 1998, a
+   new IPv6 Addressing Architecture [ARCH] replaced the original
+   provider based unicast address format with the now standardized
+   Aggregatable Global Unicast Address Format [AGGR].
+
+   To allow the 6bone to operate under the revised IPv6 address
+   architecture with the new Aggregatable Global Unicast addressing
+   format, [TEST-OLD] was replaced with a new IPv6 testing address
+
+
+
+
+
+
+Fink & Hinden                Informational                      [Page 1]
+
+RFC 3701                  6bone Phaseout Plan                 March 2004
+
+
+   allocation" of 3FFE::/16 in [TEST-NEW].  During the fall of 1998, in
+   anticipation of [AGGR], the 6bone was re-addressed under the
+   3FFE::/16 prefix with little problems.
+
+   From the fall of 1998, until the issuance of this note, the 6bone has
+   continued to successfully operate with Aggregatable Global Unicast
+   Address prefixes from the 3FFE::/16 allocation, using a set of 6bone
+   routing practice rules specified in [GUIDE], and later refined to
+   6Bone backbone routing guidelines in [PRACTICE].
+
+   During its lifetime the 6bone has provided:
+
+      - a place for early standard developers and implementers to test
+        out the IPv6 protocols and their implementations;
+
+      - a place for early experimentation with routing and operational
+        procedures;
+
+      - a place to evolve practices useful for production IPv6 prefix
+        allocation;
+
+      - a place to provide bootstrap qualification for production IPv6
+        address prefix allocation;
+
+      - a place to develop IPv6 applications;
+
+      - a place for early users to try using IPv6 in their hosts and
+        networks.
+
+   As clearly stated in [TEST-NEW], the addresses for the 6bone are
+   temporary and will be reclaimed in the future.  It further states
+   that all users of these addresses (within the 3FFE::/16 prefix) will
+   be required to renumber at some time in the future.
+
+   Since 1999 planning for, and allocation of, IPv6 production address
+   prefixes by the Regional Internet Registry (RIR) community has been
+   underway.  During 2002 more production IPv6 address prefixes had been
+   allocated than are allocated by the 6bone at the top level.  It is
+   generally assumed that this is one reasonable indicator that planning
+   for a 6bone phaseout should begin.
+
+   It is generally assumed that there is still some remaining need for
+   the 6bone, at least for current usage that will take time to evaluate
+   and possibly move to production IPv6 networks when possible.
+
+   It is generally viewed that the 6bone is an IETF activity as it was
+   established by IETF participants to assist the IETF in developing
+   IPv6 protocols, and also to assist in the IPv6 transition.  To this
+
+
+
+Fink & Hinden                Informational                      [Page 2]
+
+RFC 3701                  6bone Phaseout Plan                 March 2004
+
+
+   end, the [TEST-NEW] RFC specified that the 6bone testing was to be
+   under the auspices of the IETF IPng Transition (ngtrans) Working
+   Group 6bone testbed activity.  However, during 2002 the ngtrans
+   working group was terminated and replaced to a certain degree by the
+   v6ops working group, which did not include oversight of the 6bone in
+   its charter.  Therefore it is assumed that it is appropriate to use
+   the IETF Informational RFC process to determine a 6bone phaseout
+   plan, as well as an appropriate way to get community feedback on the
+   specifics of the 6bone phaseout.
+
+   This plan for a 6bone phaseout specifies a multi-year phaseout
+   timeline to allow sufficient time for continuing operation of the
+   6bone, followed by a sufficient time for 6bone participants to
+   convert to production IPv6 address prefixes allocated by the relevant
+   Regional Internet Registry (RIR), National Internet Registry, or
+   Local Internet Registries (ISPs).
+
+   It is anticipated that under this phaseout plan the 6bone will cease
+   to operate by June 6, 2006, with all 6bone prefixes fully reclaimed
+   by the IANA.
+
+   This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",
+   December, 1998.  RFC 2471 will become historic.
+
+   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 [RFC2119].
+
+2.  6bone Phaseout Plan
+
+   To provide for the continuing useful operation of the 6bone, to the
+   extent that IETF consensus judges it to be useful, 6bone top level
+   address prefixes known as pseudo TLA's (pTLAs) MAY continue to be
+   allocated until January 1, 2004.
+
+   Thus after the pTLA allocation cutoff date January 1, 2004, it is
+   REQUIRED that no new 6bone 3FFE pTLAs be allocated.
+
+   To provide for sufficient planning time for 6bone participants to
+   convert to production IPv6 address prefixes, all 6bone prefixes
+   allocated by the cutoff time specified above, except for allocations
+   withdrawn as a matter of 6bone operating procedures, SHALL remain
+   valid until June 6, 2006.
+
+   Thus after the 6bone phaseout date June 6, 2006, it is the intent
+   that no 6bone 3FFE prefixes, of any size/length, be used on the
+   Internet in any form.  Network operators may filter 3FFE prefixes on
+   their borders to ensure these prefixes are not misused.
+
+
+
+Fink & Hinden                Informational                      [Page 3]
+
+RFC 3701                  6bone Phaseout Plan                 March 2004
+
+
+   It should be noted that this RFC does not intend to imply that a
+   6bone prefix holder, whether at the pTLA top level or lower, should
+   seek a production IPv6 address prefix at any specific level.  It may
+   be entirely reasonable for a 6bone prefix holder to seek a higher
+   level, or a lower level, IPv6 prefix as their specific needs dictate.
+
+3.  References
+
+3.1.  Normative References
+
+   [ARCH]     Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [AGGR]     Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
+              Global Unicast Address Format", RFC 2374, July 1998.
+
+   [RFC2119]  Bradner, S., "Keywords for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [TEST-NEW] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
+              Allocation", RFC 2471, December 1998.
+
+   [TEST-OLD] Hinden, R. and J. Postel, "IPv6 Testing Address
+              Allocation", RFC 1897, January 1996
+
+3.2.  Informative References
+
+   [GUIDE]    Rockell, R. and R. Fink, "6Bone Backbone Routing
+              Guidelines", RFC 2772, February 2000.
+
+   [PRACTICE] Durand, A. and B. Buclin, "6bone Routing Practice", RFC
+              2546, March 1999.
+
+5.  Security Considerations
+
+   This document defines a phaseout plan for the usage of the IPv6
+   Testing Address Allocation [TEST-NEW], which uses addresses
+   consistent with [AGGR].  It does not have any direct impact on
+   Internet infrastructure security.
+
+6.  IANA Considerations
+
+   This document defines a phaseout plan for the usage of the IPv6
+   Testing Address Allocation [TEST-NEW].  The IANA MUST reclaim the
+   3FFE::/16 prefix upon the date specified in section 2.0.
+
+
+
+
+
+
+Fink & Hinden                Informational                      [Page 4]
+
+RFC 3701                  6bone Phaseout Plan                 March 2004
+
+
+   When the 6bone Testing Address Allocation is reclaimed by the IANA,
+   it is expected that many network operators will filter it on their
+   borders to ensure these prefixes are not misused.
+
+   There is experience from the IPv4 world that such filters may not be
+   removed promptly should this address space be reallocated, and it is
+   recommended that the IANA bears this in mind before reallocating it
+   in a manner that would require it to be routed globally within the
+   current Internet.
+
+7.  Authors' Addresses
+
+   Robert L. Fink
+
+   EMail: bob@thefinks.com
+
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   US
+
+   Phone: +1 650 625-2004
+   EMail: bob.hinden@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fink & Hinden                Informational                      [Page 5]
+
+RFC 3701                  6bone Phaseout Plan                 March 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Fink & Hinden                Informational                      [Page 6]
+