6bone (IPv6 Testing Address Allocation) Phaseout
Plan to shut down the IPv6 testbed network and reclaim its address space.
Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, DOI 10.17487/RFC3701, March 2004, <https://www.rfc-editor.org/info/rfc3701>.
@misc{rfc3701,
series = {Request for Comments},
number = 3701,
howpublished = {RFC 3701},
publisher = {RFC Editor},
doi = {10.17487/RFC3701},
url = {https://www.rfc-editor.org/info/rfc3701},
author = {R. Fink and R. Hinden},
title = {{6bone (IPv6 Testing Address Allocation) Phaseout}},
pagetotal = 6,
year = 2004,
month = mar,
} RFC text
Contents
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
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
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.
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.
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
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.
AI ELI5
On this page
§1The 6bone Testbed
The 6bone was an experimental network established in March 1996 to test IPv6 protocols before they were deployed on the production Internet. It operated as a separate testbed using a dedicated address allocation: initially 5F00::/8, then 3FFE::/16 starting in 1998.
The 6bone served multiple purposes: it allowed protocol developers and implementers to test their IPv6 code, enabled experimentation with IPv6 routing practices, allowed organizations to test IPv6 applications, and provided early users a safe place to try IPv6 networking. By the time RFC 3701 was written in 2004, production IPv6 deployment was underway, making the testbed less critical.
The 6bone was like a practice track where engineers could test new IPv6 roads before anyone used them for real traffic.
§2Addressing History
The 6bone started in 1996 with the address block 5F00::/8 under the original provider-based unicast address format. In 1998, the IPv6 Addressing Architecture was revised, and the 6bone was re-addressed to use the new Aggregatable Global Unicast Address format under 3FFE::/16. This re-addressing happened smoothly in the fall of 1998.
From 1998 onwards, the 6bone operated using the 3FFE::/16 prefix with a hierarchical allocation system. The RFC explicitly acknowledged that these addresses were temporary and would be reclaimed when the testbed was no longer needed.
The practice track had two versions of road signs. In 1998, they changed to a new style, but kept the same practice track running.
§3Why Phaseout Now
By 2002, production IPv6 address prefixes allocated by Regional Internet Registries (RIRs) had surpassed the total 6bone allocations. This indicated sufficient interest in production IPv6 that the testbed was no longer the primary driver of IPv6 development.
However, the RFC acknowledges that some continuing need existed for the 6bone, as various testbed users still depended on it. The phaseout plan therefore allocates several years to allow users to transition from 6bone addresses to production IPv6 prefixes allocated by their regional registries.
By 2002, the real IPv6 roads had enough addresses handed out that the practice track was no longer the main event. But some people still needed time to move from the practice track to the real roads.
§4The Phaseout Schedule
The plan established two key dates:
January 1, 2004: No new 6bone address allocations (pTLAs, or pseudo Top-Level Aggregators) are permitted. Existing allocations may continue to be used but no new ones are assigned.
June 6, 2006: All 6bone prefixes from the 3FFE::/16 space are reclaimed and cease operation. After this date, network operators are encouraged to filter traffic using 3FFE:: prefixes to ensure they are not misused.
The RFC allows three years between the allocation cutoff and the operational cutoff, giving 6bone users sufficient time to transition their networks to production IPv6 addresses.
Starting January 2004, nobody can get a new pass to the practice track. Everyone has until June 2006 to move their infrastructure to the real roads.
§5Implementation and Transition
The RFC does not specify any particular transition mechanism or requirements for prefix renumbering. Organizations are free to seek production IPv6 addresses at any hierarchical level that matches their needs, whether that is a larger prefix or a smaller one.
The RFC notes lessons from IPv4 history: when IPv4 addresses are reclaimed and potentially reallocated, network operators may be reluctant to remove filters, even long after the addresses are no longer in use. IANA is advised to consider this when deciding whether to reallocate the 3FFE::/16 block in the future.
Organizations can choose what size of production address block works best for them. And when the old practice block gets freed up, people might block it forever by accident, so maybe it is better to just not use it again.