Network Working Group R. Rockell
Request for Comments: 2772 Sprint
Obsoletes: 2546 R. Fink
Category: Informational ESnet
February 2000
6Bone Backbone Routing Guidelines
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
6boneのは、IPv6の進化と展開を支援するためのIPv6テストベッドです。このため、IPv6ネットワークのコアバックボーンが安定性を維持することが重要であり、すべての事業者がルールとIPv6ルーティング機器を展開することにより、ガイドラインの共通セットを持っています。
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.
すべての6boneルーティング機器のオペレータは、6boneのルーティングシステムの効率的かつ安定的な展開のためのリファレンスとして使用するためにこの文書では、一連のガイドラインを提供します。 6boneの複雑さが大きくなるにつれて、規則の共通のセットへの付着が存在するための効率的でスケーラブルなバックボーンためにますます重要になります。
Table of Contents
目次
1. Introduction.................................................. 2
2. Scope of this document........................................ 3
3. Common Rules for the 6bone.................................... 3
3.1 Link-local prefixes...................................... 3
3.2 Site-local prefixes...................................... 4
3.3 Loopback and unspecified prefixes........................ 5
3.4 Multicast prefixes....................................... 5
3.5 IPv4 compatible prefixes................................. 5
3.6 IPv4-mapped prefixes..................................... 6
3.7 Default routes........................................... 6
3.8 Yet undefined unicast prefixes........................... 6
3.9 Inter-site links......................................... 6
3.10 6to4 Prefixes........................................... 7
3.11 Aggregation & advertisement issues...................... 7
4. Routing Policies for the 6bone................................ 7
5. The 6Bone Registry............................................ 8
6. Guidelines for new sites joining the 6Bone.................... 9
7. Guidelines for 6Bone pTLA sites............................... 9
8. 6Bone Operations group........................................ 11
9. Common rules enforcement for the 6bone........................ 11
10. Security Considerations...................................... 12
11. References................................................... 12
12. Authors' Addresses........................................... 13
13. Full Copyright Statement..................................... 14
The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
6boneのは、IPv6の進化と展開を支援するためのIPv6テストベッドです。このため、IPv6ネットワークのコアバックボーンが安定性を維持することが重要であり、すべての事業者がルールとIPv6ルーティング機器を展開することにより、ガイドラインの共通セットを持っています。
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.
すべての6boneルーティング機器のオペレータは、6boneのルーティングシステムの効率的かつ安定的な展開のためのリファレンスとして使用するためにこの文書では、一連のガイドラインを提供します。 6boneの複雑さが大きくなるにつれて、規則の共通のセットへの付着が存在するための効率的でスケーラブルなバックボーンためにますます重要になります。
This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as defined [RFC 2283], commonly referred to as BGP4+, as the currently accepted EGP.
現在受け入れられてEGPとして、[RFC 2283]、一般BGP4 +と呼ばれる定義されるように、このドキュメントは、BGP4のためのマルチプロトコルの拡張でBGP4を使用します。
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 [RFC 2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
This document is a best-practices Informational document aimed at IPv6 entities which operate under the 6Bone IPv6 testbed TLA allocation.
この文書は、6boneのIPv6のテストベッドTLA配分の下で動作するIPv6の実体を目的としたベストプラクティス情報の文書です。
This section details common rules governing the routing of the 6Bone. They are derived from the issues encountered on the 6Bone, with respect to the routes advertised, handling of special addresses, and aggregation:
このセクションでは、6boneののルーティングを管理する共通のルールを詳しく説明します。彼らは、アドバタイズされたルートに関して、特別なアドレスの取り扱い、および凝集に、6boneの上で遭遇した問題から派生されています。
1) link local prefixes
1）ローカルプレフィックスをリンク
2) site local prefixes
2）サイトローカルプレフィックス
3) loopback and unspecified prefixes
3）ループバックおよび不特定のプレフィックス
4) multicast prefixes
4）マルチキャストプレフィックス
5) IPv4-compatible prefixes
5）IPv4互換プレフィックス
6) IPv4-mapped prefixes
6）IPv4マッププレフィックス
7) default routes
7）デフォルトルート
8) yet undefined unicast prefixes (from a different /3 prefix)
8）はまだ異なる/ 3プレフィックスから未定義のユニキャストプレフィクス（）
9) inter-site links issues
9）サイト間で問題リンク
10) 6to4 prefixes
10）の6to4プレフィックス
11) aggregation & advertisement issues
11）集計＆広告問題
This link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP. Under no circumstance should this prefix be seen in the 6Bone backbone routing table.
このリンクローカルプレフィックス（FE80 :: / 10）は、IGPまたはEGPのいずれかを介して広告を出してはなりません。いかなる状況下では、このプレフィックスは、6boneのバックボーンルーティングテーブルの中で理解すべきです。
By definition, the link-local prefix has a scope limited to a specific link. Since the prefix is the same on all IPv6 links, advertising it in any routing protocol does not make sense and, worse, may introduce nasty error conditions.
定義では、リンクローカルプレフィックスは、特定のリンクに限定されたスコープを持っています。接頭ので意味がないと、悪化し、厄介なエラー条件を導入することができる任意のルーティングプロトコルでそれを宣伝し、すべてのIPv6リンクでも同じです。
Well known cases where link-local prefixes could be advertised by mistake include, but are not limited to:
リンクローカルプレフィックスが誤って宣伝することができよく知られている場合には、これらに限定されません：
- a router advertising all directly connected network prefixes including the link-local one
- ルータはリンクローカル1を含むすべての直接接続されたネットワークプレフィックスを広告します
- subnetting of the link-local prefix
- リンクローカルプレフィックスのサブネット
In such cases, vendors should be urged to correct their code. While vendors should be encouraged to fix the problem, the ultimate responsibility lies on the operator of that IPv6 site to correct the problem through whatever means necessary.
このような場合には、ベンダーは、コードを修正するよう要請しなければなりません。ベンダーはこの問題を解決するために奨励されるべきであるが、最終的な責任は、必要なあらゆる手段を通じて、問題を修正するために、そのIPv6サイトの運営者です。
Should a pTLA discover link-local prefixes coming from another pTLA, it is the responsibility of the pTLA leaking the routes to filter these, and correct the problem in a timely fashion. Should a pTLA discover that a downstream of that pTLA is leaking link-local prefixes, it is the pTLA's responsibility to ensure that these prefixes are not leaked to other pTLA's, or to other downstreams of that pTLA.
pTLAは別のpTLAからのリンクローカルプレフィックスを発見する必要があり、それはこれらをフィルタリングし、かつタイムリーに問題を修正するためにルートを漏洩しpTLAの責任です。 pTLAは、そのpTLAの下流には、リンクローカルプレフィックスをリークしていることを発見する必要があり、これらのプレフィックスは、他のpTLAの、またはそのpTLAの他のダウンストリームにリークされていないことを保証するために、pTLAの責任です。
Failure to filter such routes in a timely fashion may result in the manual shutting down of BGP4+ sessions to that pTLA, from other pTLA's.
タイムリーに、このようなルートをフィルタに失敗すると、他のpTLAのから、そのpTLAへのBGP4 +セッションのダウン手動シャットをもたらすことができます。
(Also, it is each pTLA, pNLA, and end-site's responsibility to not only filter their own BGP4+ sessions appropriately to peers, but to filter routes coming from peers as well, and to only allow those routes that fit the aggregation model, and do not cause operational problems).
（また、各pTLA、pNLAで、のみならず、エンドサイトの責任は、ピアに適切に自分のBGP4 +セッションをフィルタリングするが、同様に、ピアからのルートをフィルタリングするために、そして唯一の集約モデルに適合それらのルートを許可するように、と）操作上の問題を引き起こすことはありません。
Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's or EGP's within a site. The precise definition of a site is ongoing work of the IPng working group, but should generally include a group of nodes that are operating under one administrator or group of administrators, or a group of nodes which are used for a common purpose.
（FEC0 :: / 10の範囲内）サイトローカルプレフィックスは、サイト内のIGPのか、EGPのによってアドバタイズされるかもしれません。サイトの正確な定義はIPngのワーキンググループの継続的な作業であるが、一般的に管理者の一の管理者またはグループの下で動作しているノードのグループ、または共通の目的のために使用されているノードのグループを含める必要があります。
Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or leaf-sites.
サイトローカルプレフィックスはトランジットpNLAs、pTLAs、またはリーフのサイトで広告を出してはなりません。
Again, should site-local prefixes be leaked outside of a given site, it is the responsibility of the site to fix the problem in a timely manner, either through filters, or via other means which remove the operational impact that those prefixes had on the peering sites involved. However, every site SHOULD filter not only outbound on their EGP, but also inbound, in order to ensure proper routing announcements are not only sent, but also received.
ここでも、サイトローカルプレフィックスは、特定のサイトの外に漏れ出しなければならない、それはサイトの責任はフィルターを通して、またはそれらの接頭辞が上であったこと、動作への影響を取り除く他の手段を介してのいずれか、タイムリーに問題を解決することです関連するサイトをピアリング。しかし、すべてのサイトには、適切なルーティングの発表のみ送信するだけでなく、受信されませんを確保するために、だけでなく、インバウンド、そのEGPの発信だけでなく、フィルタリングすべきです。
The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol.
ループバック・プレフィックス（:: 1/128）および不特定のプレフィックス（:: 0/128）は、任意のルーティングプロトコルによってアドバタイズされてはいけません。
The same responsibility lies with the party guilty of advertising the loopback or unspecified prefix as in Section 3.1 and 3.2.
同じ責任は、セクション3.1および3.2のようにループバックまたは不特定のプレフィックスを広告するの有罪党です。
Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast routing protocols are designed to respect the semantics of multicast and MUST therefore be used to route packets with multicast destination addresses (in the range of FF00::/8).
マルチキャストプレフィックスは、任意のユニキャストルーティングプロトコルによってアドバタイズされてはいけません。マルチキャストルーティングプロトコルは、マルチキャストのセマンティクスを尊重するように設計され、したがって、（FF00の範囲内:: / 8）マルチキャスト宛先アドレスを有するパケットをルーティングするために使用されなければなりません。
Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and pTLAs. There is no requirement on a pTLA to route multicast packets at the time of the writing of this memo.
マルチキャストアドレススコープは、6boneの上尊重されなければなりません。唯一のグローバルスコープのマルチキャストアドレスはトランジットpNLAsとpTLAs渡ってルーティングすることができます。このメモの執筆時点でルートマルチキャストパケットにpTLA上の要件はありません。
Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be routed across a pNLA to its leaf sites.
組織ローカルマルチキャストは、（FF08 :: / 16またはFF18 :: / 16の範囲で）その葉サイトにpNLA間でルーティングすることができます。
Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs.
サイトローカルマルチキャストは、トランジットpNLAsまたはpTLAsに向かってルーティングされてはなりません。
Link-local multicasts and node-local multicasts MUST NOT be routed at all.
リンクローカルマルチキャストおよびノードローカルマルチキャストは、すべてのルーティングされてはなりません。
Sites may choose to use IPv4 compatible addresses (::a.b.c.d where a.b.c.d represents the octets of an IPv4 address) internally. As there is no real rationale today for doing so, these address SHOULD NOT be used or routed in the 6Bone.
サイトでは、内部的にはIPv4互換アドレス（A.B.C.Dは、IPv4アドレスのオクテットを表し:: A.B.C.D）を使用することもできます。そうするために、今日は本当の根拠が存在しないように、これらのアドレスが使用されるか、またはの6boneにルーティングされるべきではありません。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
:: / 96 IPv4互換プレフィックスはのIGPによって通知されるかもしれません。
IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.
IPv4互換プレフィックスはトランジットpNLAsまたはpTLAsへのEGPによってアドバタイズしてはなりません。
Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is the responsibility of the party who is advertising the route to fix the problem, either through proper filters, or through other means, while it remains in the best interest of all particiapants of the 6Bone to filter both outbound and inbound at their IGP borders.
それはの最善の利益のまま/ 96 IPv4互換プレフィックスがEGPに漏洩する::べきで、それは、適切なフィルターを通して、または他の手段を介してのいずれかで、問題を解決するためにルートをアドバタイズしている当事者の責任であります6boneのすべてのparticiapantsは彼らのIGP境界でアウトバウンドとインバウンドの両方をフィルタリングします。
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the octets of an IPv4 address) MAY be advertised by IGPs within a site. It may be useful for some IPv6 only nodes within a site to have such a route pointing to a translation device, to aid in deployment of IPv6.
IPv4マッププレフィックス（:: FFFF：A.B.C.Dは、IPv4アドレスのオクテットを表すA.B.C.D）サイト内のIGPによって通知されるかもしれません。これは、IPv6の展開を支援するために、変換デバイスを指し、このようなルートを持っているために、サイト内の一部のIPv6ノードだけのために有用である可能性があります。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
IPv4マッププレフィックスは、のEGPによってアドバタイズしてはなりません。
6Bone core pTLA routers MUST be default-free.
6boneのコアpTLAルータは、デフォルトフリーでなければなりません。
pTLAs MAY advertise a default route to any downstream peer (non-pTLA site). Transit pNLAs MAY advertise a default route to any of their downstreams (other transit pNLA or leaf site).
pTLAsは、任意の下流のピア（非pTLAサイト）へのデフォルトルートを広告するかもしれません。トランジットpNLAsは、そのダウンストリーム（他のトランジットpNLAまたはリーフサイト）のいずれかへのデフォルトルートを広告するかもしれません。
Should a default route be redistributed into an EGP and found on any pTLA EGP sessions, it is the responsibility of the pTLA to fix this problem immediately upon realization of the route's existence, and the responsibility of the guilty pTLA to push the entity from which the default route was originated, should the default route have originated from downstream of a pTLA.
デフォルトルートはEGPに再配布して任意のpTLA EGPセッションで発見されなければならない、それはpTLAの責任は、ルートの存在を実現するとすぐにこの問題を解決することであり、有罪pTLAの責任は実体をプッシュしているから、デフォルトルートが発信された、デフォルトルートがpTLAの下流に由来している必要があります。
Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone.
まだ2000以外の他のフォーマットプレフィックスから未定義のユニキャストプレフィクス:: / 3は、6boneの内の任意のルーティングプロトコルによってアドバタイズされてはいけません。具体的には、RFC 2471テストアドレスは、6boneので宣伝してはなりません。
Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), and routing of global unicast prefixes yet undelegated in the range (3ffe::/16) are discussed in section 4, Routing policies, below.
範囲（3FFE :: / 16）に未だ委任解除グローバルユニキャスト6boneの範囲外のプレフィックス（3FFE :: / 16）、及びグローバルユニキャストプレフィクスのルーティングのルーティングは、以下に、セクション4、ルーティングポリシーに記載されています。
Global IPv6 addresses must be used for the end points of inter-site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
グローバルIPv6アドレスは、サイト間リンクのエンドポイントを使用する必要があります。具体的には、IPv4互換アドレスはトンネルのために使用してはいけません。
Sites MAY use Other addressing schemes for Inter-site links, but these addresses MUST NOT be advertised into the IPv6 global routing table.
サイトは、サイト間リンクのためのその他のアドレス指定方式を使用することができるが、これらのアドレスは、IPv6グローバルルーティングテーブルにアドバタイズしてはなりません。
Prefixes for inter-site links MUST NOT be injected in the global routing tables.
サイト間リンクのための接頭辞は、グローバルルーティングテーブルに注入してはなりません。
The 6to4 prefix, or some portion thereof, MAY be announced by any pTLA which has a current implementation of 6to4 in their IPv6 network. However, as 6to4 implementors gain more operational experience, it MAY be necessary to change this in some way. At the time of the writing of this docuement, any pTLA MAY announce the 6to4 prefix into global EBGP. However, in order to announce this block, the pTLA MUST have a 6to4 router active, sourcing this prefix announcement.
6to4のプレフィックス、またはその一部は、彼らのIPv6ネットワーク内の6to4の現在の実装を持っている任意のpTLAが発表されるかもしれません。 6to4の実装者は、より多くの運用経験を積むようしかし、いくつかの方法でこれを変更する必要があるかもしれません。このdocuementの執筆時点では、任意のpTLAはグローバルEBGPへの6to4プレフィックスを発表するかもしれません。しかし、このブロックを発表するために、pTLAは、このプレフィックスの発表を調達アクティブ6to4ルーターを持っている必要があります。
This section subject to change, and MAY vary, depending on 6to4 progress within the NGTRANS working group.
この変更される部分、及びNGTRANSワーキンググループ内の6to4進捗に応じて、変化してもよいです。
Route aggregation MUST be performed by any border router talking EGP with any other IPv6 sites. More-specifics MUST NOT be leaked into or across the IPv6 6Bone backbone.
ルート集約は、他のIPv6サイトとEGPの話を任意の境界ルータで実行しなければなりません。もっと-詳細は、IPv6の6boneバックボーンに、または全体に漏洩してはなりません。
Leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider. Advertising a prefix assigned by another provider to a provider is not acceptable, and breaks the aggregation model. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem. However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally.
リーフサイトやpNLAsは上流のプロバイダにそのプロバイダから割り当てられたプレフィックスを通知しなければなりません。プロバイダに別のプロバイダから割り当てられたプレフィックスを広告することは受け入れられない、と集約モデルを破ります。サイトには、マルチホーミングの問題を回避する方法として、プロバイダに別のプロバイダからのプレフィックスを通知してはなりません。しかし、新しいソリューションをテストするための利益のために、一つはあまりにも長い間、影響を受けるすべての当事者は、このテストを認識しているとして、このポリシーを破ることができ、すべてがこのテストをサポートすることに同意します。これらのポリシーブレークは、グローバルの6boneルーティングテーブルに影響してはいけません。
To clarify, if one has two upstream pNLA or pTLA providers, (A and B for this example), one MUST only announce the prefix delegated to one by provider A to provider A, and one MUST only announce the prefeix delegated by one from provider B upstream to provider B. There exists no circumstance where this should be violated, as it breaks the aggregation model, and could globally affect routing decisions if downstreams are able to leak other providers' more specific delegations up to a pTLA. As the IPNG working group works through the multi-homing problem, there may be a need to alter this rule slightly, to test new strategies for deployment. However, in the case of current specifications at the time of this writing, there is no reason to advertise more specifics, and pTLA's MUST adhere to the current aggregation model.
一つは（この例のA及びB）は、2つの上流pNLAまたはpTLAプロバイダを有する場合、明確にするために、一つだけプロバイダAにプロバイダAずつに委譲されたプレフィックスを通知しなければならない、一つだけのプロバイダからの1つによって委任prefeixを発表しなければなりませんBは、それが集約モデルを壊すとして、上流プロバイダBに、これに違反しなければならない何の事情が存在しない、とダウンストリームがpTLAまで他のプロバイダーのより具体的な代表団を漏洩することができれば、グローバルルーティングの決定に影響を与える可能性があります。 IPNGワーキンググループは、マルチホーミングの問題を介して動作として、展開のための新たな戦略をテストするために、少しこのルールを変更する必要があるかもしれません。しかし、この記事の執筆時点での現在の仕様の場合には、より多くの詳細を宣伝する理由はない、とpTLAのは、現在の集約モデルに準拠する必要があります。
Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more specific (longer) than the prefix that was allocated by their upstream provider.
pNLAまたはリーフサイトのサイト境界ルータは、その上流プロバイダによって割り当てられたプレフィックスよりも（長く）、より具体的なプレフィックスを通知してはなりません。
All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision.
特別なピアリング手配が実装されていない限り、すべての6boneのpTLAsは、他の6bone pTLAsに（現在は/ 24または/ 28）与えられたpTLA委任より長いプレフィックスを通知してはなりません。このような特殊なピアリングaggreementsは、任意の2つ以上の6bone pTLAs間の所定の位置にあるときに、注意がピアリングaggreementに参加していない他の6boneのpTLAs、より具体的に漏れないように注意しなければなりません。これが最善のパスルーティングの決定を破るだろうような場所では、そのような契約を結んでいるの6bone pTLAsは、下流の6bone pNLAsまたはリーフサイトに他の6bone pTLAより多くの詳細を広告してはなりません。
The peering agreements across the 6Bone may be by nature non-commercial, and therefore MAY allow transit traffic, if peering agreements of this nature are made. However, no pTLA is REQUIRED to give or receive transit service from another pTLA.
6boneの間でピアリング契約は自然非商業的であってもよく、このような性質のピアリング合意がなされた場合ので、トランジットトラフィックを可能にすることができます。しかし、pTLAは与えるか、または別のpTLAからのトランジットサービスを受けるために必要とされません。
Eventually, the Internet registries will assign prefixes under other than the 6Bone TLA (3FFE::/16). As of the time this document was written in 1999, the Internet registries were starting to assign /35 sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly be used in the future.
最終的には、インターネットレジストリは、6boneのTLA（3FFE :: / 16）以外の下にプレフィックスを割り当てます。この文書は、1999年に書かれた時のように、インターネットレジストリ2001 :: / 16 TLAから/ 35サブTLA（sTLA）ブロックを割り当てるために開始しました。その他は確かに将来的に使用されます。
The organizations receiving prefixes under these newer TLAs would be expected to want to establish peering and connectivity relationships with other IPv6 networks, both in the newer TLA space and in the 6bone pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY occur, and details such as transit, and what routes are received by each, are outside of general peering rules as stated in this memo, and are left up to the members of those TLA's and pTLA's that are establishing said peerings. However, it is expected that most of the rules discussed here are equally applicable to new TLAs.
これらの新しいTLAS下プレフィックスを受ける組織は、新しいTLA空間でと6boneのpTLA空間で両方、他のIPv6ネットワークとのピアリングとの接続関係を確立したいことが期待されます。このメモに記載され、それらのTLAのとpTLA者のメンバーに任されているように新しいTLAの及び現在の6bone pTLAの発生してもよく、そのような輸送などの詳細、及びどの経路それぞれによって受信される間にピアリング、外部一般的なピアリングルールでありますそれは言っピアリングを確立しています。しかし、ここで議論のルールのほとんどが新しいTLASにも同様に適用可能であることが期待されています。
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone, and its sites. The 6bone is accessible at:
6boneのレジストリは、IPv6 6boneの情報を格納するために使用される拡張機能、およびそのサイトとRIPE-181データベースです。 6boneのは、アクセスできます。
<http://www.6bone.net/whois.html>)
＜ｈっｔｐ：／／ｗっｗ。６ぼね。ねｔ／うぉいｓ。ｈｔｍｌ＞）
Each 6Bone site MUST maintain the relevant entries in the 6Bone registry. In particular, the following object MUST be present for all 6Bone leaf sites, pNLAs and pTLAs:
各6boneのサイトが6boneのレジストリに関連するエントリを維持しなければなりません。具体的には、以下のオブジェクトは、すべての6boneの葉サイト、pNLAsとpTLAsために存在しなければなりません。
- IPv6-site: site description
- IPv6のサイト：サイトの説明
- Inet6num: prefix delegation (one record MUST exist for each delegation)
- Inet6num：プレフィックス委任（1つのレコードは、各代表団のために存在しなければなりません）
- Mntner: contact info for site maintance/administration staff.
- のmntner：サイトmaintance /管理スタッフのための情報をお問い合わせください。
Other object MAY be maintained at the discretion of the sites such as routing policy descriptors, person, or role objects. The Mntner object MUST make reference to a role or person object, but those MAY NOT necessarily reside in the 6Bone registry. They can be stored within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.)
他のオブジェクトは、ルーティングポリシー記述子、人、またはロールオブジェクトとして現場の裁量で維持することができます。 mntnerオブジェクトは、役割や人物オブジェクトへの参照を作る必要がありますが、それらは必ずしも6boneのレジストリに存在しないかもしれません。彼らは、インターネットレジストリデータベース（ARIN、APNIC、RIPE-NCCなど）のいずれかの内に格納することができます。
New sites joining the 6Bone should seek to connect to a transit pNLA or a pTLA within their region, and preferably as close as possible to their existing IPv4 physical and routing path for Internet service. The 6Bone web site at <http://www.6bone.net> has various information and tools to help find candidate 6bone networks.
6boneの入社新サイトでは、地域内のトランジットpNLAまたはpTLAに接続しようと、インターネットサービスのための彼らの既存のIPv4物理的およびルーティングパスになるべく近いはずです。 <http://www.6bone.net>での6boneのWebサイトでは、候補6boneのネットワークを見つけるのに役立つ様々な情報やツールを持っています。
Any site connected to the 6Bone MUST maintain a DNS server for forward name lookups and reverse address lookups. The joining site MUST maintain the 6Bone objects relative to its site, as describe in section 5.
6boneのに接続されたすべてのサイトには、前方名前検索と逆アドレスルックアップのためのDNSサーバを維持しなければなりません。接合部位は、セクション5で説明したように6boneのは、そのサイトに対してオブジェクトを維持しなければなりません。
The upstream provider MUST delegate the reverse address translation zone in DNS to the joining site, or have an agreement in place to perform primary DNS for that downstream. The provider MUST also create the 6Bone registry inet6num object reflecting the delegated address space.
上流プロバイダが加入サイトにDNSで逆のアドレス変換ゾーンを委任、またはその下流のプライマリDNSを実行するための場所での合意がなければなりません。プロバイダはまた、委任アドレス空間を反映した6boneレジストリinet6numオブジェクトを作成する必要があります。
Up to date informatino about how to join the 6Bone is available on the 6Bone Web site at <http://www.6bone.net>.
参加方法についての最新informatinoまで6boneのは、<http://www.6bone.net>で6boneのWebサイトで入手可能です。
The following rules apply to qualify for a 6Bone pTLA allocation. It should be recognized that holders of 6Bone pTLA allocations are expected to provide production quality backbone network services for the 6Bone.
次の規則が6boneのpTLA割り当ての資格を得るために適用されます。 6boneのpTLA割り当ての保有者は、6boneのための生産品質バックボーンネットワークサービスを提供することが期待されていることを認識すべきです。
1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has.
1. pTLA出願人は、6boneのエンドサイトやpNLAトランジットとしての経験を予選3ヶ月の最小値を持っている必要があります。全体予選期間中、出願人は、運用上、以下を提供する必要があります。完全に最新の状態に維持、出願人は、持っている各トンネルを含め、IPv6のサイトinet6num、のmntner、および人物オブジェクト用の6boneレジストリエントリ、。
b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request.
B。出願人の境界ルータと6boneのに適切な接続ポイントとの間に完全に維持し、かつ信頼性の高い、BGP4 +ピアリングと接続。このルータは、IPv6 ping可能である必要があります。この基準は、出願人のpTLA要求時に6boneの運用グループのメンバーによって判断されます。
c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system.
C。完全に前方（AAAA）DNSを維持し、出願人のルータ（複数可）と、少なくとも1つのホスト・システム用（ip6.int）のエントリを逆転。
d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable.
D。完全に維持され、かつ信頼性の高い、IPv6のアクセス可能なシステムには、最低でも、提供する1つのまたは複数のウェブページ、出願人のIPv6サービスを記述する。このサーバは、IPv6 ping可能である必要があります。
2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following:
2. pTLA出願人は、「生産・品質」の6boneバックボーン・サービスを提供する能力と意思を持たなければなりません。出願人らは、この主張を支持する声明や情報を提供する必要があります。これには、以下を含める必要があります。
a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant.
A。 pTLAの申請のためのIPv6サイトのオブジェクトにそれぞれの登録者の属性と、3が好ましく、最低二人のサポートスタッフ、。
b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant.
B。すべてのサポートスタッフがアクセス権を持ってサポートの連絡先の目的のための一般的なメールボックスは、pTLA申請のためのIPv6サイトオブジェクト内の通知属性とを指摘しました。
3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim.
3. pTLA出願人は、そのがpTLAになることによって提供されるだろう潜在的な「ユーザーコミュニティ」を持たなければならない、例えば、出願人は、関心領域、国、またはフォーカスのインターネットサービスの大手プロバイダーです。出願人は、サポートにこの主張を陳述し、情報を提供する必要があります。
4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community.
4. pTLA出願人は、彼らがその適用の時点で存在として現在の6boneの運用ルールとポリシーを遵守することにコミットし、彼らは6boneのバックボーンのコンセンサスとユーザーコミュニティによって発展し、将来の6boneバックボーン運用ルールとポリシーに従うことに同意しなければなりません。
When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing to the Group information in support of its claims that it meets the criteria above.
出願人はpTLA割り当てを受信しようとする場合、それは上記の基準を満たしていることを主張を支持するグループ情報を提供することにより、（以下のセクション8を参照）6boneの運用グループに適用されます。
The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone.
6boneの運用グループは、現在のルールの遵守を監視し、ポリシングを担当するグループです。 6boneの運用グループのメンバーシップは、6boneのに接続されているサイトには必須、とに制限されています。
The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone mailing list. Instructions on how to join the list are maintained on the 6Bone web site at < http://www.6bone.net>.
6boneの運用グループは、現在の6boneに参加するサイトを表す既存の6boneメーリングリストのメンバーによって定義されます。従って、6boneのメーリングリストに参加するために、関連するサイトの連絡先に現職です。リストに参加する方法については、<http://www.6bone.net>で6boneのWebサイト上で維持されています。
Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules and policies described in this document in order to maintain the 6Bone as a quality tool for the deployment of, and transition to, IPv6 protocols and the products implementing them.
6boneのへの参加は任意と慈悲深い作業です。しかし、参加サイトはの展開、および、IPv6プロトコルとそれらを実装する製品への移行のための品質ツールとして6boneのを維持するために、このドキュメントで説明するルールとポリシーを遵守することが期待されます。
The following is in support of policing adherence to 6Bone rules and policies:
以下は、6boneのルールとポリシーの遵守を取り締まるのサポートにあります。
1. Each pTLA site has committed to implement the 6Bone's rules and policies, and SHOULD try to ensure they are adhered to by sites within their administrative control, i.e. those to who prefixes under their respective pTLA prefix have been delegated.
1.各pTLAサイトが6boneののルールやポリシーを実装するためにコミットしている、と彼らはそれぞれのpTLAの接頭辞の下に接頭辞人にそれらが委任されている彼らの管理制御内のサイト、すなわちにより接着されていることを確認してみてください。
2. When a site detects an issue, it SHOULD first use the 6Bone registry to contact the site maintainer and work the issue.
サイトには、問題を検出した場合2.は、それが最初のサイトのメンテナに連絡して、問題を動作するように6boneのレジストリを使用すべきです。
3. If nothing happens, or there is disagreement on what the right solution is, the issue SHOULD be brought to the 6Bone Operations Group.
3.何も起こらない、または適切なソリューションとは何かについて意見の相違がある場合は、問題が6boneの運用グループにもたらされるべきです。
4. When the problem is related to a product issue, the site(s) involved SHOULD be responsible for contacting the product vendor and work toward its resolution.
問題は、製品の問題に関連しているとき4.関わる部位（単数または複数）は、その解決に向けた製品のベンダーと仕事を接触させるための責任を負わなければなりません。
5. When an issue causes major operational problems, backbone sites SHOULD decide to temporarily set filters in order to restore service.
5.問題が主要な操作上の問題が発生した場合、バックボーンサイトが一時的にサービスを回復するために、フィルタを設定することを決定すべきです。
The result of incorrect entries in routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using these rules and policies, routing on the 6Bone will be less sensitive to denial of service attacks due to misleading routes.
ルーティングテーブルのエントリが不適切な場合の結果は、通常、到達不能のサイトです。ガイドラインはルートを集約または拒否するために持つことは、ルーティングテーブルをクリーンアップします。これらのルールとポリシーを使用して、6boneの上のルーティングが原因誤解を招くようなルートにサービス拒否攻撃に対する感受性が低いことが期待されます。
The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Therefore, denial of service or packet disclosure are to be expected. However, it is the pTLA from where the attack originated who has ultimate responsibility for isolating and fixing problems of this nature. It is also every 6Bone site's responsibility to safely introduce new test systems into the 6Bone, by placing them at a strategically safe places which will have minimal impact on other 6Bone sites, should bugs or misconfigurations occur.
6boneのは、IPv6の進化と展開を支援するためのIPv6テストベッドです。そのため、サービスまたはパケット開示の拒否は予想されています。しかし、それは攻撃が分離し、この種の問題を修正するための最終的な責任を持っている人元の場所からのpTLAです。他の6boneサイトへの影響を最小限に抑える必要があります戦略的に安全な場所でそれらを配置することにより、バグや設定ミスが発生した場合、また、安全の6boneに新しいテスト・システムを導入するためにあらゆるの6boneサイトの責任です。
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC 2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[RFC 2471] HindenとR.、フィンク、R.とJ.ポステル、 "IPv6のテストアドレス割り当て"、RFC 2471、1998年12月。
[RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC 2546, March 1999
[RFC 2546]デュラン、A.およびB. Buclin、 "6boneのルーティング実践"、RFC 2546、1999年3月
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC 2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998.
[RFC 2283]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2283、1998年3月。
[RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[RIPE-181]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、J.、Karrenberg、D.、テルプストラ、M.及びJ.ゆう、ルーティングレジストリにIPルーティングポリシーの表現。テクニカルレポート熟し-181、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
Rob Rockell EMail: rrockell@sprint.net
ロブロッケルEメール：rrockell@sprint.net
Bob Fink EMail: fink@es.net
ボブ・フィンクEメール：fink@es.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。