この文書はRFC3701の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
６ｂｏｎｅは１９９６年にＩＥＴＦによって設立され、様々なＩＰｖ６試験
やＩＰｖ６をインターネットに移行する事を助けるための、ＩＰｖ６試験ネッ
トワークです。これはＲＦＣ２４７１からのＩＰｖ６アドレス、3FFE::/16、
を運用します。ＩＰｖ６が商用サービスを始めているので、６ｂｏｎｅの段
階的廃止を予期して計画を立てることは適当です。この文書はＩＥＴＦがこ
れを決定する適切な場所であるという仮定の上に、６ｂｏｎｅとそのアドレ
ス割り当ての多年にわたる段階的廃止の計画します。
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",
December, 1998. RFC 2471 will become historic.
この文書は１９９８年１２月のＲＦＣ２４７１「ＩＰｖ６テストアドレス割
当て」を時代遅れにします。ＲＦＣ２４７１は歴史的になるでしょう。
1. Introduction
1. はじめに
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].
６ｂｏｎｅ、ＩＰｖ６試験台ネットワークは１９９６年３月に設立され、
１９９６年夏に、古い（そして現在は時代遅れの）プロバイダベースのユニ
キャストアドレスフォーマットのＩＰｖ６試験アドレス、5F00::/8[TEST-OLD]、
で運用を開始しました。１９９８年７月にＩＰｖ６アドレス体系[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.
修正されたＩＰｖ６アドレス体系下の新しい集約グローバルユニキャストア
ドレスフォーマットで６ｂｏｎｅを運営するために、[TEST-OLD]は、新しい
3FFE::/16のＩＰｖ６試験アドレス割り当てる[TEST-NEW]で置き換えられま
した。１９９８年の秋に、[AGGR]の予想どおり、６ｂｏｎｅはほとんど問題
なしで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].
１９９８年の秋からこのノートの発行まで、６ｂｏｎｅは3FFE::/16から割当
てられた集約グローバルユニキャストアドレスで、[GUIDE]で指定した６ｂｏ
ｎｅルーティング実施規則と、後に書き直した[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.
[TEST-NEW]で明示的に述べられるように、６ｂｏｎｅのアドレスは一時的で
あり、将来回収されるでしょう。それはさらにすべてのこれらのアドレス
（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.
１９９９年からＩＰｖ６商用アドレスプレフィックスの計画と割当が、地域
のインターネット登記所（ＲＩＲ）共同体によって、進行しました。
２００２年の間に最上位レベルで６ｂｏｎｅに割り当てられるより多くの商
用ＩＰｖ６アドレスプレフィックスが割り当てられました。これが６ｂｏｎ
ｅの段階的廃止を予期して計画を立てることは始まるべきであるという１つ
の合理的な指標であると一般に想定されます。
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.
６ｂｏｎｅがＩＥＴＦ関係者によって設立され、ＩＥＴＦがＩＰｖ６プロト
コルを開発するのを助けて、そしてＩＰｖ６移行を支援するから、一般にＩ
ＥＴＦの活動と見られます。この文書の終わりの６ｂｏｎｅテストを明示す
るＲＦＣ[TEST-NEW]は、６ｂｏｎｅテストがＩＥＴＦのＩＰｎｇ移行作業グ
ループの６ｂｏｎｅテストベッド活動の援助下にあるはずであったことを明
示しました。しかしながら、２００２年にｎｇｔｒａｎｓ作業グループは終
了し、ある程度ｖ６ｏｐｓ作業グループによって置き換えられ、そしてその
規約に６ｂｏｎｅの監督は含まれませんでした。それ故に、６ｂｏｎｅの段
階的廃止の詳細に対する共同体のフィードバックを受取る適切な方法として、
６ｂｏｎｅ段階的廃止計画を決定するのにＩＥＴＦ情報ＲＦＣ手順を使うこ
とが適当であると想定されます。
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].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈します。
2. 6bone Phaseout Plan
2. ６ｂｏｎｅ段階的廃止計画
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.
６ｂｏｎｅの継続的で有用な稼働に備えるために、ＩＥＴＦ総意が有用であ
ると判定する限りにおいて、疑似ＴＬＡ（ｐＴＬＡ）として知られている６
ｂｏｎｅ最上位レベルアドレスプレフィックスが２００４年１月１日まで割
り当て続けられるかもしれません(MAY)。
Thus after the pTLA allocation cutoff date January 1, 2004, it is
REQUIRED that no new 6bone 3FFE pTLAs be allocated.
それでｐＴＬＡ割り当て打ち切り日の２００４年１月１日以降は、新しい６
ｂｏｎｅの3FFEのｐＴＬＡが割り当てられないことが要求されます(REQUIRED)。
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.
２００６年６月１日の６ｂｏｎｅ段階的廃止日付の後に、６ｂｏｎｅの3FFE
プレフィックスは、大きさ／長さの形式を問わず、インターネット上で使わ
れないことが意図されます(REQUIRED)。ネットワークオペレータがこれらの
プレフィックスが誤用されないことを保証するために境界上で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.
このＲＦＣは、６ｂｏｎｅプレフィックス保有者が、ｐＴＬＡの最上位かそ
れ以下かに関わらず、特定のレベルの商用ＩＰｖ６アドレスプレフィックス
を求めるべきことを意味しない、と明示します。固有の必要性に従って、よ
り高いレベルあるいは低いレベルのＩＰｖ６プレフィックスを求めることが、
６ｂｏｎｅプレフィックス保有者にとって合理的であるかもしれません。
3. References
3. 参考文献
3.1. Normative References
3.1. 参照する参考文献
[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
3.2. 有益な参考文献
[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
5. セキュリティの考察
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.
この文書はＩＰｖ６テストアドレス割当て[TEST-NEW]の使用の段階的廃止計
画を定義し、そしてこれは[AGGR]と整合したアドレスを使います。これはイ
ンターネット基礎セキュリティに直接の影響を持っていません。
6. IANA Considerations
6. ＩＡＮＡの考慮
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.
この文書はＩＰｖ６テストアドレス割当て[TEST-NEW]の使用の段階的廃止計
画を定義します。ＩＡＮＡは２.０章で指定された日付に3FFE::/16プレフィッ
クスの返還を要求しなくてはなりません(MUST)。
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
7. 著者のアドレス
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
8. 著作権表示全文
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。