6bone (IPv6 Testing Address Allocation) Phaseout

Network Working Group                                            R. Fink
Request for Comments: 3701                                     R. Hinden
Obsoletes: <a href="./rfc2471">2471</a>                                               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 <a href="./rfc2471">RFC 2471</a>.  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 <a href="./rfc2471">RFC 2471</a>, "IPv6 Testing Address Allocation",
   December, 1998.  <a href="./rfc2471">RFC 2471</a> will become historic.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 [<a href="#ref-TEST-OLD" title=""IPv6 Testing Address Allocation"">TEST-OLD</a>] that used the original (and
   now obsolete) provider based unicast address format.  In July 1998, a
   new IPv6 Addressing Architecture [<a href="#ref-ARCH" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">ARCH</a>] replaced the original
   provider based unicast address format with the now standardized
   Aggregatable Global Unicast Address Format [<a href="#ref-AGGR" title=""An Aggregatable Global Unicast Address Format"">AGGR</a>].

   To allow the 6bone to operate under the revised IPv6 address
   architecture with the new Aggregatable Global Unicast addressing
   format, [<a href="#ref-TEST-OLD" title=""IPv6 Testing Address Allocation"">TEST-OLD</a>] was replaced with a new IPv6 testing address






<span class="grey">Fink & Hinden                Informational                      [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc3701">RFC 3701</a>                  6bone Phaseout Plan                 March 2004</span>


   allocation" of 3FFE::/16 in [<a href="#ref-TEST-NEW" title=""IPv6 Testing Address Allocation"">TEST-NEW</a>].  During the fall of 1998, in
   anticipation of [<a href="#ref-AGGR" title=""An Aggregatable Global Unicast Address Format"">AGGR</a>], 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 [<a href="#ref-GUIDE" title=""6Bone Backbone Routing Guidelines"">GUIDE</a>], and later refined to
   6Bone backbone routing guidelines in [<a href="#ref-PRACTICE" title=""6bone Routing Practice"">PRACTICE</a>].

   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 [<a href="#ref-TEST-NEW" title=""IPv6 Testing Address Allocation"">TEST-NEW</a>], 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



<span class="grey">Fink & Hinden                Informational                      [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc3701">RFC 3701</a>                  6bone Phaseout Plan                 March 2004</span>


   end, the [<a href="#ref-TEST-NEW" title=""IPv6 Testing Address Allocation"">TEST-NEW</a>] 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 <a href="./rfc2471">RFC 2471</a>, "IPv6 Testing Address Allocation",
   December, 1998.  <a href="./rfc2471">RFC 2471</a> 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 [<a href="./rfc2119" title=""Keywords for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  6bone Phaseout Plan</span>

   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.



<span class="grey">Fink & Hinden                Informational                      [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc3701">RFC 3701</a>                  6bone Phaseout Plan                 March 2004</span>


   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  References</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Normative References</span>

   [<a id="ref-ARCH">ARCH</a>]     Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.

   [<a id="ref-AGGR">AGGR</a>]     Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
              Global Unicast Address Format", <a href="./rfc2374">RFC 2374</a>, July 1998.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Keywords for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-TEST-NEW">TEST-NEW</a>] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
              Allocation", <a href="./rfc2471">RFC 2471</a>, December 1998.

   [<a id="ref-TEST-OLD">TEST-OLD</a>] Hinden, R. and J. Postel, "IPv6 Testing Address
              Allocation", <a href="./rfc1897">RFC 1897</a>, January 1996

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Informative References</span>

   [<a id="ref-GUIDE">GUIDE</a>]    Rockell, R. and R. Fink, "6Bone Backbone Routing
              Guidelines", <a href="./rfc2772">RFC 2772</a>, February 2000.

   [<a id="ref-PRACTICE">PRACTICE</a>] Durand, A. and B. Buclin, "6bone Routing Practice", <a href="./rfc2546">RFC</a>
              <a href="./rfc2546">2546</a>, March 1999.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   This document defines a phaseout plan for the usage of the IPv6
   Testing Address Allocation [<a href="#ref-TEST-NEW" title=""IPv6 Testing Address Allocation"">TEST-NEW</a>], which uses addresses
   consistent with [<a href="#ref-AGGR" title=""An Aggregatable Global Unicast Address Format"">AGGR</a>].  It does not have any direct impact on
   Internet infrastructure security.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   This document defines a phaseout plan for the usage of the IPv6
   Testing Address Allocation [<a href="#ref-TEST-NEW" title=""IPv6 Testing Address Allocation"">TEST-NEW</a>].  The IANA MUST reclaim the
   3FFE::/16 prefix upon the date specified in <a href="#section-2.0">section 2.0</a>.






<span class="grey">Fink & Hinden                Informational                      [Page 4]</span>

<span id="page-5" ></span>
<span class="grey"><a href="./rfc3701">RFC 3701</a>                  6bone Phaseout Plan                 March 2004</span>


   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Authors' Addresses</span>

   Robert L. Fink

   EMail: [email protected]


   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   US

   Phone: +1 650 625-2004
   EMail: [email protected]


























<span class="grey">Fink & Hinden                Informational                      [Page 5]</span>

<span id="page-6" ></span>
<span class="grey"><a href="./rfc3701">RFC 3701</a>                  6bone Phaseout Plan                 March 2004</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Full Copyright Statement</span>

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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 <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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 [email protected].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Fink & Hinden                Informational                      [Page 6]