Network Working Group R. Fink
Request for Comments: 3701 R. Hinden
Obsoletes: 2471 March 2004
Category: Informational
Network Working Group R. Fink
Request for Comments: 3701 R. Hinden
Obsoletes: 2471 March 2004
Category: Informational
6bone (IPv6 Testing Address Allocation) Phaseout
6bone（IPv6测试地址分配）淘汰
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.
版权所有（C）互联网协会（2004年）。版权所有。
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.
IETF于1996年建立了6bone，作为IPv6测试平台网络，以支持各种IPv6测试，并帮助IPv6过渡到Internet。它在RFC 2471的IPv6地址分配3FFE:：/16下运行。由于IPv6正在开始其生产部署，因此有必要计划逐步淘汰6bone。本文件建立了一个多年逐步淘汰6bone及其地址分配的计划，前提是IETF是确定这一点的适当场所。
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.
本文件废除了RFC 2471，“IPv6测试地址分配”，1998年12月。RFC 2471将成为历史。
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].
6bone IPv6试验台网络于1996年3月建立，1996年夏季开始运行，使用了5F00:：/8[TEST-OLD]的IPv6测试地址分配，该分配使用了原始（现在已过时）基于提供商的单播地址格式。1998年7月，一种新的IPv6寻址体系结构[ARCH]将原来基于提供商的单播地址格式替换为现在标准化的可聚合全局单播地址格式[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
为了允许6bone在新的可聚合全局单播寻址格式的修订版IPv6地址体系结构下运行，将[TEST-OLD]替换为新的IPv6测试地址
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.
[TEST-NEW]中3FFE:：/16的分配。1998年秋季，在[AGGR]的预期下，6bone在3FFE:：/16前缀下重新寻址，问题不大。
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].
从1998年秋季开始，直到本说明发布，6bone继续使用3FFE:：/16分配中的可聚合全局单播地址前缀成功运行，使用了[指南]中规定的一组6bone路由实践规则，后来在[实践]中改进为6bone主干路由指南。
During its lifetime the 6bone has provided:
在其使用寿命内，6bone提供了：
- a place for early standard developers and implementers to test out the IPv6 protocols and their implementations;
- 早期标准开发人员和实现人员测试IPv6协议及其实现的场所；
- a place for early experimentation with routing and operational procedures;
- 早期试验路线和操作程序的场所；
- a place to evolve practices useful for production IPv6 prefix allocation;
- 为生产IPv6前缀分配提供了一个发展实践的场所；
- a place to provide bootstrap qualification for production IPv6 address prefix allocation;
- 为生产IPv6地址前缀分配提供引导鉴定的位置；
- a place to develop IPv6 applications;
- 开发IPv6应用程序的地方；
- a place for early users to try using IPv6 in their hosts and networks.
- 早期用户在其主机和网络中尝试使用IPv6的场所。
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.
正如[TEST-NEW]中明确指出的，6bone的地址是临时的，将在将来回收。它进一步指出，这些地址的所有用户（在3FFE:：/16前缀内）将在将来某个时候被要求重新编号。
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.
自1999年以来，区域互联网注册中心（RIR）社区一直在规划和分配IPv6生产地址前缀。在2002年期间，分配的生产IPv6地址前缀比6bone在顶层分配的多。一般认为，这是一个合理的指标，应开始规划6骨淘汰。
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.
一般认为6bone仍有一些剩余需求，至少目前的使用情况需要时间进行评估，并可能在可能的情况下转移到生产IPv6网络。
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
一般认为，6bone是IETF的一项活动，因为它是由IETF参与者建立的，目的是协助IETF制定IPv6协议，并协助IPv6过渡。对此
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.
最后，[TEST-NEW]RFC规定，6bone测试将在IETF IPng过渡（ngtrans）工作组6bone测试台活动的主持下进行。然而，在2002年期间，ngtrans工作组被终止，并在一定程度上被v6ops工作组取代，该工作组在其章程中未包括对6bone的监督。因此，假设使用IETF信息RFC流程来确定6bone淘汰计划是合适的，同时也是获得社区对6bone淘汰细节反馈的合适方式。
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).
本6bone淘汰计划规定了一个多年淘汰时间表，以便有足够的时间继续运行6bone，然后有足够的时间让6bone参与者转换为相关区域互联网注册中心（RIR）、国家互联网注册中心分配的生产IPv6地址前缀，或本地互联网注册处（ISP）。
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.
根据该逐步淘汰计划，预计6bone将于2006年6月6日停止运营，所有6bone前缀将由IANA完全回收。
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.
本文件废除了RFC 2471，“IPv6测试地址分配”，1998年12月。RFC 2471将成为历史。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
为使6bone继续有效运行，在IETF一致认为6bone有用的范围内，6bone顶级地址前缀（称为伪TLA（PTLA））可继续分配到2004年1月1日。
Thus after the pTLA allocation cutoff date January 1, 2004, it is REQUIRED that no new 6bone 3FFE pTLAs be allocated.
因此，在pTLA分配截止日期2004年1月1日之后，不需要分配新的6bone 3FFE pTLA。
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.
为使6bone参与者有足够的计划时间转换为生产IPv6地址前缀，在上述截止时间分配的所有6bone前缀（因6bone操作程序而撤回的分配除外）应保持有效至2006年6月6日。
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.
因此，在2006年6月6日6bone逐步淘汰日期之后，我们的目的是不在互联网上以任何形式使用任何大小/长度的6bone 3FFE前缀。网络运营商可能会过滤其边界上的3FFE前缀，以确保这些前缀不会被误用。
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.
应该注意的是，本RFC并不意味着6bone前缀持有者（无论是pTLA顶级还是更低级别）应在任何特定级别寻求生产IPv6地址前缀。对于6bone前缀持有者来说，根据其特定需求，寻求更高级别或更低级别的IPv6前缀可能是完全合理的。
[ARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ARCH]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR]Hinden，R.，Deering，S.和M.O'Dell，“一种可聚合的全球单播地址格式”，RFC 2374，1998年7月。
[RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于指示需求水平的关键字”，BCP 14，RFC 2119，1997年3月。
[TEST-NEW] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[TEST-NEW]Hinden，R.，Fink，R.和J.Postel，“IPv6测试地址分配”，RFC 24711998年12月。
[TEST-OLD] Hinden, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 1897, January 1996
[TEST-OLD]Hinden，R.和J.Postel，“IPv6测试地址分配”，RFC 1897，1996年1月
[GUIDE] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[指南]Rockell，R.和R.Fink，“6Bone主干路由指南”，RFC 27722000年2月。
[PRACTICE] Durand, A. and B. Buclin, "6bone Routing Practice", RFC 2546, March 1999.
[实践]Durand，A.和B.Buclin，“6骨路由实践”，RFC 25461999年3月。
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.
本文件定义了使用IPv6测试地址分配[TEST-NEW]的淘汰计划，该计划使用与[AGGR]一致的地址。它对互联网基础设施安全没有任何直接影响。
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.
本文件定义了使用IPv6测试地址分配[TEST-NEW]的淘汰计划。IANA必须在第2.0节规定的日期收回3FFE:：/16前缀。
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.
当IANA回收6bone测试地址分配时，预计许多网络运营商将在其边界上对其进行过滤，以确保这些前缀不会被误用。
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.
IPv4世界的经验表明，如果重新分配此地址空间，可能不会立即删除此类筛选器，建议IANA在重新分配地址空间之前牢记这一点，重新分配方式要求在当前互联网中进行全局路由。
Robert L. Fink
罗伯特·L·芬克
EMail: bob@thefinks.com
EMail: bob@thefinks.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
Robert M.Hinden诺基亚313飞兆半导体山景大道，美国加利福尼亚州94043
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。