[要約] RFC 2772は、6Boneバックボーンルーティングのガイドラインを提供しています。その目的は、IPv6ネットワークのバックボーンルーティングに関するベストプラクティスを定義し、6Boneネットワークの効率的な運用を支援することです。
Network Working Group R. Rockell
Request for Comments: 2772 Sprint
Obsoletes: 2546 R. Fink
Category: Informational ESnet
February 2000
6Bone Backbone Routing Guidelines
6ボーンバックボーンルーティングガイドライン
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.
Copyright（c）The Internet Society（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]と呼ばれる[RFC 2283]の定義[RFC 2283]として、BGP-4のマルチプロトコル拡張を備えたBGP-4を使用しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
定義上、Link-Local Prefixには特定のリンクに制限されたスコープがあります。プレフィックスはすべての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
- リンクローカルを含むすべての直接接続されたネットワークプレフィックスをすべて広告するルーター
- 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).
（また、独自のBGP4セッションをピアに適切にフィルタリングするだけでなく、同様に同僚から来るルートをフィルタリングし、集約モデルに合ったルートのみを許可するのは、各PTLA、PNLA、およびエンドサイトの責任です。運用上の問題を引き起こさないでください）。
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ワーキンググループの継続的な作業ですが、通常、1つの管理者または管理者のグループの下で動作するノードのグループ、または一般的な目的で使用されるノードのグループを含める必要があります。
Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or leaf-sites.
サイトローカルプレフィックスは、トランジットPNLA、PTLA、またはリーフサイト全体で宣伝してはなりません。
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で尊重する必要があります。トランジットPNLAおよびPTLAを介してルーティングできるグローバルスコープマルチキャストアドレスのみがルーティングできます。PTLAには、このメモの執筆時点でマルチキャストパケットをルーティングするための要件はありません。
Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be routed across a pNLA to its leaf sites.
Organization-Local Multicasts（FF08 ::/16またはFF18 ::/16 Range）は、PNLAを介して葉の部位にルーティングできます。
Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs.
サイトローカルマルチキャストは、通過PNLAまたはPTLAに向かってルーティングしてはなりません。
Link-local multicasts and node-local multicasts MUST NOT be routed at all.
Link-Local MulticastsとNode-Local Multicastsをまったくルーティングしてはなりません。
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を使用することを選択できます。ここで、A.B.C.DはIPv4アドレスのオクテットを内部的に表します。今日の本当の根拠はないため、これらのアドレスを6boneで使用したりルーティングしたりしないでください。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
::/96 IPv4互換のプレフィックスは、IGPSによって宣伝される場合があります。
IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.
IPv4互換性のあるプレフィックスは、EGPによってPNLASまたはPTLAを通過するために宣伝してはなりません。
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のすべての参加者は、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-Mappedプレフィックス（:: FFFF：A.B.C.Dここで、A.B.C.DはIPv4アドレスのオクテットを表します）は、サイト内のIGPSによって宣伝されます。サイト内の一部のIPv6ノードのみが、IPv6の展開を支援するために、このようなルートを翻訳デバイスに指すようなルートを持つことが役立つ場合があります。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
IPv4マップされたプレフィックスは、EGPSによって宣伝されてはなりません。
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).
PTLAは、下流のピア（非PTLAサイト）へのデフォルトルートを宣伝する場合があります。Transit PNLAは、下流のいずれか（他のトランジット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年以外のフォーマットプレフィックスから未定義のユニキャストプレフィックスは、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.
6bone範囲外のグローバルユニキャストプレフィックスのルーティング（3ffe ::/16）、および範囲内ではまだ解除されていないグローバルユニキャストプレフィックスのルーティング（3ffe ::/16）については、以下のルーティングポリシーで説明します。
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の実装者がより多くの運用エクスペリエンスを獲得するにつれて、何らかの方法でこれを変更する必要がある場合があります。このドキュメントの執筆時点で、PTLAは6to4プレフィックスをグローバルEBGPに発表する場合があります。ただし、このブロックを発表するには、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.
リーフサイトまたはPNLAは、そのプロバイダーによって割り当てられたプレフィックスを上流のプロバイダーにのみ広告する必要があります。別のプロバイダーによってプロバイダーに割り当てられたプレフィックスを宣伝することは受け入れられず、集約モデルを破ります。マルチホミングの問題を回避する方法として、サイトは別のプロバイダーからプロバイダーにプレフィックスを宣伝してはなりません。ただし、新しいソリューションをテストするために、すべての影響を受ける当事者がこのテストを認識しており、すべてがこのテストをサポートすることに同意している限り、このポリシーを破ることができます。これらのポリシーブレークは、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.
明確にするために、2つのアップストリームPNLAまたはPTLAプロバイダー（この例ではAとB）がある場合、プロバイダーAにプロバイダーAに委任されたプレフィックスを発表する必要があり、プロバイダーから1つによって委任されたPrefeixを発表する必要があります。bプロバイダー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 PTLAは、特別なピアリングアレンジメントが実装されていない限り、特定のPTLA委任（現在 /24または /28）よりも長く他の6bone PTLAにプレフィックスを宣伝してはなりません。このような特別な覗き見が任意の2つ以上の6bone PTLAの間に配置されている場合、ピアリングアゲージに参加していない他の6bone PTLAにより多くの詳細を漏らしないように注意する必要があります。6Bone PTLAは、そのような契約を締結しているPTLAは、他の6bone PTLAを下流の6bone PNLAまたは葉のサイトに宣伝してはなりません。
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.
これらの新しいTLAに基づいてプレフィックスを受け取る組織は、新しいTLAスペースと6bone PTLAスペースの両方で、他のIPv6ネットワークとのピアリングと接続の関係を確立したいと予想されます。新しいTLAと現在の6bone PTLAの間で覗き込んでいる可能性があり、トランジットなどの詳細、およびそれぞれが受信するルートは、このメモに記載されている一般的なピアリングルールの外側であり、TLAとPTLAのメンバーに任されています。それは上記の査読を確立しています。ただし、ここで説明するルールのほとんどは、新しいTLAに等しく適用できると予想されます。
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レジストリは、6boneおよびそのサイトに関する情報を保存するために使用されるIPv6拡張機能を備えた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リーフサイト、PNLA、およびPTLAに存在する必要があります。
- IPv6-site: site description
- IPv6-Site：サイトの説明
- Inet6num: prefix delegation (one record MUST exist for each delegation)
- inet6num：プレフィックス委任（各代表団に1つのレコードが存在する必要があります）
- Mntner: contact info for site maintance/administration staff.
- MNTNER：サイトメンテナンス/管理スタッフの連絡先情報。
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に接続しようとする必要があります。<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>.
6boneへの参加方法についての最新情報は、6bone Webサイト<http://www.6bone.net>で入手できます。
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-Site INET6NUM、MNTNER、および人物のオブジェクトのIPv6サイトINET6NUM、および個人のオブジェクトの最新の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 pinableでなければなりません。この基準は、申請者のPTLAリクエストの時点で、6bone Operations Groupのメンバーによって審査されます。
c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system.
c. 申請者のルーターと少なくとも1つのホストシステムの完全に維持されたDNSフォワード（AAAA）およびリバース（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アクセス可能なシステムは、適用者のIPv6サービスを説明する1つ以上のWebページで、1つ以上のWebページを提供します。このサーバーはIPv6 pinableでなければなりません。
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サイトオブジェクトのそれぞれに登録された個人属性を持つ最低2人の最低2人のサポートスタッフ。
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サイトオブジェクトのNotify属性を指し示しています。
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申請者は、現在の6ボーンの運用ルールとポリシーを適用時に存在させることを約束し、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の割り当てを受け取ることを求めている場合、上記の基準を満たしているという主張を支持するグループ情報を提供することにより、6Bone Operations Group（以下のセクション8を参照）に適用されます。
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 Operations Groupは、現在のルールの監視と警察の遵守を担当するグループです。6bone Operations Groupのメンバーシップは、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 Operations Groupは現在、6boneに参加しているサイトを代表する既存の6boneメーリングリストのメンバーによって定義されています。したがって、関連するサイトの連絡先が6boneメーリングリストに参加することが義務付けられています。リストに参加する方法の手順は、6bone Webサイト<http://www.6bone.net>に維持されています。
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 Operationsグループにもたらされるべきです。
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. Deering、「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.、Fink、R。、およびJ. Postel、「IPv6テストアドレス割り当て」、RFC 2471、1998年12月。
[RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC 2546, March 1999
[RFC 2546] Durand、A。and B. Buclin、「6bone Routing Practice」、RFC 2546、1999年3月
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC 2080] Malkin、G。およびR. Minnear、「RIPNG for IPv6」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Bates、T.、Chandra、R.、Katz、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] Bates、T.、Gerich、E.、Joncheray、L.、Jouanigot、J.、Karrenberg、D.、Terpsstra、M。and J. Yu、ルーティングレジストリにおけるIPルーティングポリシーの表現。Technical Report Ripe-181、Ripe、Ripe NCC、アムステルダム、オランダ、1994年10月。
Rob Rockell EMail: rrockell@sprint.net
Rob Rockellメール：rrockell@sprint.net
Bob Fink EMail: fink@es.net
Bob Finkメール：fink@es.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。