[要約] RFC 3701は、IPv6のテストアドレス割り当てである6boneの廃止に関するものです。その目的は、6boneの運用を終了し、IPv6の本番環境への移行を促進することです。
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）The Internet Society（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.
6boneは、1996年にIETFによってIPv6テストベッドネットワークとして設立され、さまざまなIPv6テストを有効にし、IPv6のインターネットへの移行を支援しました。RFC 2471からのIPv6アドレスAllocation 3ffe ::/16で動作します。IPv6が生産展開を開始しているため、6boneの段階的アウトを計画することが適切です。このドキュメントは、IETFがこれを決定するのに適切な場所であるという仮定で、6Boneの複数年の段階的段階とそのアドレス割り当ての計画を確立します。
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.
このドキュメントは、RFC 2471、「IPv6テストアドレス割り当て」、1998年12月に廃止されました。RFC2471は歴史的になります。
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 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.
6boneが新しい集計可能なグローバルユニキャストアドレス形式を使用して修正されたIPv6アドレスアーキテクチャの下で動作できるようにするために、[Test-New]の3ffe ::/16の新しいIPv6テストアドレス割り当て "の新しいIPv6テストアドレス割り当てに置き換えられました。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は、[ガイド]で指定された6boneルーティングプラクティスルールのセットを使用して、3FFE ::/16割り当ての集計可能なグローバルユニキャストアドレスプレフィックスで正常に動作し続けています。その後、[実践]の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年以来、IPv6生産アドレスの地域インターネットレジストリ（RIR）コミュニティによるプレフィックスの計画と割り当てが進行中です。2002年には、最上位の6boneによって割り当てられるよりも多くの生産IPv6アドレスプレフィックスが割り当てられていました。一般に、これは6ボーンの段階的アウトの計画が開始されるべきであるという合理的な指標の1つであると想定されています。
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.
少なくとも、可能な場合は評価に時間がかかり、おそらく生産IPv6ネットワークに移動するために時間がかかる現在の使用には、6boneの必要性がまだ残っていると一般に想定されています。
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.
一般に、6boneはIETF参加者によって確立されたIETFアクティビティであり、IETFがIPv6プロトコルの開発を支援し、IPv6遷移を支援することであると見なされています。この目的のために、[テスト-NEW] RFCは、6boneテストがIETF IPNG遷移（NGTRANS）ワーキンググループ6boneテストベッドアクティビティの後援の下にあることを指定しました。ただし、2002年には、NGTRANSワーキンググループが終了し、V6OPSワーキンググループにある程度置き換えられました。したがって、IETF情報情報RFCプロセスを使用して6bone PhaseOutプランを決定することが適切であると想定されており、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).
6ボーンの段階的アウトのこの計画は、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月に廃止されました。RFC2471は歴史的になります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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コンセンサスが有用であると判断する範囲で、Pseudo TLA（PTLAS）として知られる6boneトップレベルのアドレスプレフィックスは、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.
6ボーンの参加者が生産IPv6アドレスのプレフィックスに変換するのに十分な計画時間を提供するために、6ボーンの操作手順の問題として撤回された割り当てを除き、上記のカットオフ時間によって割り当てられたすべての6ボーンプレフィックスは、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 PhaseOutの日付の後、どんなサイズ/長さでも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は、PTLAのトップレベル以下であろうと、6boneプレフィックスホルダーが特定のレベルで生産IPv6アドレスのプレフィックスを探す必要があることを意味するものではないことに注意する必要があります。6boneプレフィックスホルダーが、特定のニーズが指示するように、より高いレベル、またはより低いレベルのIPv6プレフィックスを求めることは完全に合理的かもしれません。
[ARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[Arch] Hinden、R。and 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。and 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。、「要件レベルを示すためにRFCSで使用するためのキーワード」、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 2471、1998年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 2772、2000年2月。
[PRACTICE] Durand, A. and B. Buclin, "6bone Routing Practice", RFC 2546, March 1999.
[実践] Durand、A。およびB. Buclin、「6bone Routing Practice」、RFC 2546、1999年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.
このドキュメントでは、[Aggr]と一致するアドレスを使用するIPv6テストアドレスのアドレス割り当て[Test-New]の使用に関するフェーズアウト計画を定義します。インターネットインフラストラクチャのセキュリティに直接的な影響はありません。
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.
6BONEテストアドレスの割り当てがIANAによって回収されると、多くのネットワークオペレーターが境界でそれをフィルタリングして、これらの接頭辞が誤用されないようにすることが予想されます。
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は、現在の内部でグローバルにルーティングする必要がある方法でそれを再配置する前に、IANAがこれを念頭に置くことをお勧めしますインターネット。
Robert L. Fink
ロバート・L・フィンク
EMail: bob@thefinks.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートM.ヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043米国
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。