RFC3701 日本語訳
3701 6bone (IPv6 Testing Address Allocation) Phaseout. R. Fink, R.Hinden. March 2004. (Format: TXT=12019 bytes) (Obsoletes RFC2471) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Fink Request for Comments: 3701 R. Hinden Obsoletes: 2471 March 2004 Category: Informational
コメントを求めるワーキンググループR.密告者要求をネットワークでつないでください: 3701R.Hindenは以下を時代遅れにします。 2471 2004年3月のカテゴリ: 情報
6bone (IPv6 Testing Address Allocation) Phaseout
6bone(IPv6テストアドレス配分)段階的撤去
Status of this Memo
この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.
Copyright(C)インターネット協会(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.
6boneは、1996年に様々なIPv6テストを可能にして、IPv6の移行をインターネットに助けるためにIPv6 TestbedネットワークとIETFによって書き立てられました。 それはIPv6アドレス配分3FFEで以下を操作します:RFC2471からの/16。 IPv6が生産展開を始めているとき、6boneの段階的撤去の計画を立てるのは適切です。 このドキュメントは6boneのマルチ年の段階的撤去とIETFがこれを決定する適切な場所であるという前提のそのアドレス配分のためにプランを確立します。
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.
「IPv6はアドレス配分をテストし」て、このドキュメントが1998年12月にRFC2471を時代遅れにします。 RFC2471は歴史的になるでしょう。
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].
6bone IPv6 Testbedネットワークは1996年3月に設立されました、1996年夏の間、5F00のIPv6テストアドレス配分を使用することで操作上になって:、:オリジナルの、そして、(現在時代遅れ)のプロバイダーを使用した/8[TEST-OLD]がユニキャストアドレス形式を基礎づけました。 1998年7月に、新しいIPv6 Addressing Architecture[ARCH]はオリジナルのプロバイダーに基づいているユニキャストアドレス形式を現在標準化された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
6boneが新しいAggregatable Global Unicastアドレス指定形式で改訂されたIPv6アドレス体系の下で作動するのを許容するために、[TEST-OLD]をアドレスをテストする新しいIPv6に取り替えました。
Fink & Hinden Informational [Page 1] RFC 3701 6bone Phaseout Plan March 2004
密告者とHindenの情報[1ページ]のRFC3701 6bone段階的撤去は2004年3月に計画されています。
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.
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からのAggregatable Global Unicast Address接頭語で首尾よく以下を操作し続けていました:/16配分、1セットの6boneルーティング習慣規則を使用するのは[PRACTICE]の背骨ルーティングガイドラインを[ガイド]で指定して、後で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;
- 初期の標準の開発者とimplementersが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年の計画、配分、アドレスがRegionalインターネットRegistry(RIR)共同体に前に置くIPv6生産は進行中でした。 2002の間、トップレベルにおける6boneによって割り当てられるよりさらに多くの生産IPv6アドレス接頭語を割り当てていました。 一般に、これが6bone段階的撤去の計画を立てるのが始まるべきであるという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.
一般に、それでも、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
一般に、見られて、それが展開しているIPv6プロトコルにIETFを助けて、また、IPv6変遷を助けるためにIETF関係者によって設立されたとき、6boneがIETF活動であることはそうです。 これに
Fink & Hinden Informational [Page 2] RFC 3701 6bone Phaseout Plan March 2004
密告者とHindenの情報[2ページ]のRFC3701 6bone段階的撤去は2004年3月に計画されています。
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 Transition(ngtrans)作業部会の6boneテストベッド活動の前兆であることであると指定しました。 しかしながら、2002の間、ngtransワーキンググループをある程度v6opsワーキンググループに終えて、取り替えました。(それは、特許における、6boneの見落としを含んでいませんでした)。 したがって、6bone段階的撤去プランを決定するのにIETF Informational RFCの過程を使用するのが適切であると思われます、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関係者が関連RegionalインターネットRegistry(RIR)、NationalインターネットRegistry、またはLocalインターネットRegistries(ISP)によって割り当てられた生産IPv6アドレス接頭語に変えることができるくらいの時間までに続かれる6boneの継続する操作を考慮するためにマルチ年の段階的撤去スケジュールを指定します。
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.
「IPv6はアドレス配分をテストし」て、このドキュメントが1998年12月にRFC2471を時代遅れにします。 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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. 6bone Phaseout Plan
2. 6bone段階的撤去プラン
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コンセンサスが、それが役に立つと判断するという範囲まで備えるために、疑似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 pTLAsも割り当てないのは、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.
6bone関係者が生産IPv6アドレス接頭語に変えることができるくらいの計画時間に提供するために、締切りの時間によって割り当てられたすべての6bone接頭語が上で指定しました、6bone操作手順の問題として引き下がる配分を除いてSHALLは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接頭語をフィルターにかけるかもしれません。
Fink & Hinden Informational [Page 3] RFC 3701 6bone Phaseout Plan March 2004
密告者とHindenの情報[3ページ]のRFC3701 6bone段階的撤去は2004年3月に計画されています。
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接頭語を求めるのがそれは完全に妥当であるかもしれません。
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.
[アーチ]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR] HindenとR.とデアリングとS.とM.オデル、「Aggregatableのグローバルなユニキャストアドレス形式」、RFC2374、1998年7月。
[RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[TEST-NEW] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[試しに新しい] HindenとR.と密告者とR.とJ.ポステル、「IPv6テストアドレス配分」、RFC2471、1998年12月。
[TEST-OLD] Hinden, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 1897, January 1996
[試しに古い] HindenとR.とJ.ポステル、「IPv6テストアドレス配分」、RFC1897、1996年1月
3.2. Informative References
3.2. 有益な参照
[GUIDE] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[誘導します] RockellとR.とR.密告者、「6Bone背骨ルート設定ガイドライン」、RFC2772、2000年2月。
[PRACTICE] Durand, A. and B. Buclin, "6bone Routing Practice", RFC 2546, March 1999.
[習慣] ジュランドとA.とB.Buclin、「6boneルート設定練習」、RFC2546、1999年3月。
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.
このドキュメントは[AGGR]と一致したアドレスを使用するIPv6 Testing Address Allocation[TEST-NEW]の使用法のための段階的撤去プランを定義します。 それはインターネット基盤セキュリティに少しの直接的な衝撃も持っていません。
6. IANA Considerations
6. IANA問題
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 Testing Address Allocation[TEST-NEW]の使用法のための段階的撤去プランを定義します。 IANA MUSTは3FFEを開墾します:、:日付の/16接頭語はセクション2.0で指定しました。
Fink & Hinden Informational [Page 4] RFC 3701 6bone Phaseout Plan March 2004
密告者とHindenの情報[4ページ]のRFC3701 6bone段階的撤去は2004年3月に計画されています。
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 Testing Address Allocationが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がこれに堪える経験が念頭でお勧めですか?
7. Authors' Addresses
7. 作者のアドレス
Robert L. Fink
ロバートL.密告者
EMail: bob@thefinks.com
メール: bob@thefinks.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートM.Hindenノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2004 EMail: bob.hinden@nokia.com
以下に電話をしてください。 +1 650 625-2004 メールしてください: bob.hinden@nokia.com
Fink & Hinden Informational [Page 5] RFC 3701 6bone Phaseout Plan March 2004
密告者とHindenの情報[5ページ]のRFC3701 6bone段階的撤去は2004年3月に計画されています。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Fink & Hinden Informational [Page 6]
密告者とHinden情報です。[6ページ]
一覧
スポンサーリンク