この文書はRFC3701の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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.

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試験ネッ
   トワークです。これはRFC2471からのIPv6アドレス、3FFE::/16、
   を運用します。IPv6が商用サービスを始めているので、6boneの段
   階的廃止を予期して計画を立てることは適当です。この文書はIETFがこ
   れを決定する適切な場所であるという仮定の上に、6boneとそのアドレ
   ス割り当ての多年にわたる段階的廃止の計画します。

   This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",
   December, 1998.  RFC 2471 will become historic.
   この文書は1998年12月のRFC2471「IPv6テストアドレス割
   当て」を時代遅れにします。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試験台ネットワークは1996年3月に設立され、
   1996年夏に、古い(そして現在は時代遅れの)プロバイダベースのユニ
   キャストアドレスフォーマットのIPv6試験アドレス、5F00::/8[TEST-OLD]、
   で運用を開始しました。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.
   修正されたIPv6アドレス体系下の新しい集約グローバルユニキャストア
   ドレスフォーマットで6boneを運営するために、[TEST-OLD]は、新しい
   3FFE::/16のIPv6試験アドレス割り当てる[TEST-NEW]で置き換えられま
   した。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から割当
   てられた集約グローバルユニキャストアドレスで、[GUIDE]で指定した6bo
   neルーティング実施規則と、後に書き直した[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;
      - 初期の標準開発者と実装者が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アドレスプレフィックスが割り当てられました。これが6bon
   eの段階的廃止を予期して計画を立てることは始まるべきであるという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
   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がIPv6プロト
   コルを開発するのを助けて、そしてIPv6移行を支援するから、一般にI
   ETFの活動と見られます。この文書の終わりの6boneテストを明示す
   るRFC[TEST-NEW]は、6boneテストがIETFのIPng移行作業グ
   ループの6boneテストベッド活動の援助下にあるはずであったことを明
   示しました。しかしながら、2002年にngtrans作業グループは終
   了し、ある程度v6ops作業グループによって置き換えられ、そしてその
   規約に6boneの監督は含まれませんでした。それ故に、6boneの段
   階的廃止の詳細に対する共同体のフィードバックを受取る適切な方法として、
   6bone段階的廃止計画を決定するのにIETF情報RFC手順を使うこ
   とが適当であると想定されます。

   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関係者が、適切な地域イン
   ターネット登記所(RIR)か国内インターネット登記所かローカルインター
   ネット登記所(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月1日までに、IA
   NAによって返還を要求された6boneプレフィックスでの稼働を、すべ
   ての完全にやめることが予想されます。

   This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",
   December, 1998.  RFC 2471 will become historic.
   この文書は1998年12月のRFC2471「IPv6テストアドレス割
   り当て」を時代遅れにします。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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
   NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
   [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(pTLA)として知られている6
   bone最上位レベルアドレスプレフィックスが2004年1月1日まで割
   り当て続けられるかもしれません(MAY)。

   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日以降は、新しい6
   boneの3FFEのpTLAが割り当てられないことが要求されます(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の運用手順とし
   て撤回された割当て以外、2006年6月1日までは正当なままです。

   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月1日の6bone段階的廃止日付の後に、6boneの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.
   このRFCは、6boneプレフィックス保有者が、pTLAの最上位かそ
   れ以下かに関わらず、特定のレベルの商用IPv6アドレスプレフィックス
   を求めるべきことを意味しない、と明示します。固有の必要性に従って、よ
   り高いレベルあるいは低いレベルのIPv6プレフィックスを求めることが、
   6boneプレフィックス保有者にとって合理的であるかもしれません。

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.
   この文書はIPv6テストアドレス割当て[TEST-NEW]の使用の段階的廃止計
   画を定義し、そしてこれは[AGGR]と整合したアドレスを使います。これはイ
   ンターネット基礎セキュリティに直接の影響を持っていません。

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テストアドレス割当て[TEST-NEW]の使用の段階的廃止計
   画を定義します。IANAは2.0章で指定された日付に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.
   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が現在
   のインターネットの中でグローバルにルーティングできるように要請される
   方法でこれらを再配分する前に、この事を念頭におくことが勧められます。

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.
   著作権(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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

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文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

[]Japanese translation by Ishida So