RFC2772 日本語訳
2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT=28565 bytes) (Obsoletes RFC2546) (Updated by RFC3152) (Status: INFORMATIONAL)
RFC一覧
英語原文
Network Working Group R. Rockell
Request for Comments: 2772 Sprint
Obsoletes: 2546 R. Fink
Category: Informational ESnet
February 2000
6Bone Backbone Routing Guidelines
6Bone バックボーンルーティングガイドライン
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.
このメモは、Internet community のための情報を提供する。これは、いか
なる種類の Internet 標準を明細に述べるものではない。このメモの配布は
無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
-----------------------------------------------------------------------
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 testbed である。この
ため、次に述べる 2 つは重要である。1 つ目は IPv6 ネットワークのコア
バックボーンは stability (安定性) を維持することと、もう 1 つは 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
-----------------------------------------------------------------------
1. Introduction
1. 序論
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 testbed である。この
ため、次に述べる 2 つは重要である。1 つ目は IPv6 ネットワークのコア
バックボーンは安定性を維持することと、もう 1 つは 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 として、BGP4+ と共通に参照される、定
義された [RFC 2283] の Multiprotocol Extensions for 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].
この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" と
"OPTIONAL" は、[RFC 2119] で記述されたとして解釈されるべきである。
-----------------------------------------------------------------------
2. Scope of this document
2. この文書の範囲
This document is a best-practices Informational document aimed at
IPv6 entities which operate under the 6Bone IPv6 testbed TLA
allocation.
この文書は、IPv6 testbed TLA 割り当てのもとで運用する IPv6 エンティ
ティを意図した、最善である practices (経験からの実施) の
Informational 文書である。
-----------------------------------------------------------------------
3. Common Rules for the 6bone
3. 6bone の共通ルール
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:
この section は、6Bone のルーティングを管理している共通ルールを詳し
く述べる。それらは、経路広告、特別アドレスの扱いと経路集約に関して言
うと、6Bone で直面した問題から得られる:
1) link local prefixes
リンクローカルプレフィックス
2) site local prefixes
サイトローカルプレフィックス
3) loopback and unspecified prefixes
ループバックと未指定プレフィックス
4) multicast prefixes
マルチキャストプレフィックス
5) IPv4-compatible prefixes
IPv4 互換プレフィックス
6) IPv4-mapped prefixes
IPv4 射影プレフィックス
7) default routes
デフォルト経路
8) yet undefined unicast prefixes (from a different /3 prefix)
未定義ユニキャストプレフィックス (/3 プレフィックスと異なる)
9) inter-site links issues
サイト内リンク問題
10) 6to4 prefixes
6to4 プレフィックス
11) aggregation & advertisement issues
経路集約 & 広告問題
3.1 Link-local prefixes
3.1 リンクローカルプレフィックス
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 を通し
て、決して広告されてはならない (MUST NOT)。このプレフィックスは、
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
リンクローカルプレフィックスを含む、すべての直接接続ネットワーク
プレフィックスを広告しているルータ
- 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 が検出するなら
それらプレフィックスが他の複数 pLTA へ、またはその 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 とエンドサイトの責任である。そしてその
ことは、運用問題を引き起こさない)。
3.2 Site-local prefixes
3.2 サイトローカルプレフィックス
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 により広告されるだろう (MAY)。サイトの明確な定義は、IPng
working group の進行中の作業である。しかし、次に述べる条件の下で運用
している複数ノードのグループを一般的に含むべきである。それは、1 管理
者または複数管理者のグループ、共通目的のために使用される複数ノードの
グループである。
Site-local prefixes MUST NOT be advertised across transit pNLAs,
pTLAs, or leaf-sites.
サイトローカルプレフィックスは、通過 pNLAs, pTLAs またはリーフサイト
を通して決して広告されてはならない (MUST NOT)。
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 上の外向きだけでなく、内向き
もフィルタすべきである (SHOULD)。
3.3 Loopback and unspecified prefixes
3.3 ループバックと未指定プレフィックス
The loopback prefix (::1/128) and the unspecified prefix (::0/128)
MUST NOT be advertised by any routing protocol.
ループバックプレフィックス (::1/128) と未指定プレフィックス
(::0/128) は、どんなルーティングプロトコルによっても決して広告されて
はならない (MUST NOT)。
The same responsibility lies with the party guilty of advertising the
loopback or unspecified prefix as in Section 3.1 and 3.2.
同一の責任は、Section 3.1 と 3.2 と同様に、ループバックと未指定プレ
フィックスを広告する当事者の責任である。
3.4 Multicast prefixes
3.4 マルチキャストプレフィックス
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).
マルチキャストプレフィックスは、どんなユニキャストルーティングプロト
コルによっても決して広告されてはならない (MUST NOT)。マルチキャスト
ルーティングプロトコルは、マルチキャストのセマンティクスに関連するよ
うに設計されており、それゆえマルチキャスト終点アドレス
(範囲 FF00::/8) でパケットを経路づけるように使用されなければならない
(MUST)。
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 上へと関連されなければならな
い (MUST)。グローバルスコープマルチキャストアドレスのみは、通過
pNLAs と pTLAs を通して経路づけられるかもしれない (MAY)。このメモの
執筆時点で、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 を通して経路づけられるかもしれない (MAY)。
Site-local multicasts MUST NOT be routed toward transit pNLAs or
pTLAs.
サイトローカルマルチキャストは、通過 pNLAs または pTLAs へと決して経
路づけてはならない (MUST NOT)。
Link-local multicasts and node-local multicasts MUST NOT be routed at
all.
リンクローカルマルチキャストとノードローカルマルチキャストは、まった
く決して経路づけてはならない (MUST NOT)。
3.5 IPv4 compatible prefixes
3.5 IPv4 互換プレフィックス
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 アドレスのオクテットを表す) の使用を選択するかもしれない。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
::/96 IPv4 互換プレフィックスは、IGPs により広告されるかもしれない
(MAY)。
IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit
pNLAs or pTLAs.
IPv4 互換プレフィックスは、EGPs により通過 pNLAs や pTLAs へと決して
広告されてはならない (MUST NOT)。
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 へと洩れるなら、適切なフィ
ルタを通すか、または他の方法により問題を解決することが、その経路を広
告している当事者の責任である。だが一方、IGP 境界で外向きと内向き両方
をフィルタすることが 6Bone の全関係者の最大利益のままである。
3.6 IPv4-mapped prefixes
3.6 IPv4 射影プレフィックス
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, ここで a.b.c.d は IPv4 アド
レスのオクテットを表す) は、サイト内の IGPs により広告されるかもしれ
ない (MAY)。サイト内の IPv6 のみであるいくつかのノードが、変換デバイ
スを指し示しているそのような経路を持ち、かつ IPv6 の展開を助けるのに
有用であるだろう。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
IPv4 射影プレフィックスは、EGPs により決して広告されてはならない
(MUST NOT)。
3.7 Default routes
3.7 デフォルト経路
6Bone core pTLA routers MUST be default-free.
6Bone コア pTLA ルータは、デフォルトフリーでなければならない
(MUST)。
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 でないサイト) へとデフォルト経路と広
告するかもしれない (MAY)。通過 pNLAs は、その下流 (他の通過 pNLA ま
たはリーフサイト) へとデフォルト経路を広告するかもしれない (MAY)。
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 の責任である。
3.8 Yet undefined unicast prefixes
3.8 未定義ユニキャストプレフィックス
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 内でどんなルーティングプロトコルによっても
決して広告されてはならない (MUST NOT)。特に、RFC 2471 テストアドレス
は、6Bone を通じて決して広告されてはならない (MUST NOT)。
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) の未委任グローバルユニキャストプレ
フィックスのルーティングは、下の section 4, Routing policies で審議
される。
3.9 Inter-site links
3.9 サイト内リンク
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 互換アドレスは、トンネルに決して使用さ
れてはならない (MUST NOT)。
Sites MAY use Other addressing schemes for Inter-site links, but
these addresses MUST NOT be advertised into the IPv6 global routing
table.
サイトは、サイト内リンクに他のアドレス付け方法を使用するかもしれない
(MAY)。しかしそれらアドレスは、IPv6 グローバルルーティングテーブルへ
と決して広告されてはならない (MUST NOT)。
Prefixes for inter-site links MUST NOT be injected in the global
routing tables.
サイト内リンクのプレフィックスは、グローバルルーティングテーブルに決
して注入されてはならない (MUST NOT)。
3.10 6to4 Prefixes
3.10 6to4 プレフィックス
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 により広告されるかもしれない
(MAY)。しかしながら、6to4 実装者がより多くの運用経験を得るにつれて、
何らかの方法でこれを変更する必要があるかもしれない (MAY)。この文書の
執筆時点で、あらゆる pTLA は、6to4 プレフィックスをグローバル EBGP
へと広告するかもしれない (MAY)。しかしながら、この (アドレス) ブロッ
クを広告するために、pTLA は、このプレフィックス広告の元になっている
アクティブな 6to4 ルータを持たなければならない (MUST)。
This section subject to change, and MAY vary, depending on 6to4
progress within the NGTRANS working group.
この section は、NGTRANS working group 内の 6to4 進行に依存して、変
更を受けさせ、変化するかもしれない (MAY)。
3.11 Aggregation & advertisement issues
3.11 経路集約 & 広告問題
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 を話すあらゆる境界ルータ
によりおこなわれなければならない (MUST)。より個別の経路は、IPv6
6Bone バックボーンへと、またはバックボーンを通して決して洩れてはなら
ない (MUST NOT)。
-----------------------------------------------------------------------
4. Routing Policies for the 6bone
4. 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 は、上流プロバイダへと、そのプロバイダにより割
り当てられたプレフィックスを広告するだけでなければならない (MUST)。
別のプロバイダにより割り当てられたプレフィックスをプロバイダへと広告
することは、容認不可能であり、集約モデルを壊す。サイトは、マルチホー
ム問題を中心にした見方として、別のプロバイダからのプレフィックスをプ
ロバイダへ決して広告してはならない (MUST NOT)。しかしながら、有益と
なる新しい解決法のテストのために、影響を受ける全 (ALL) 関係者がこの
テストを知っており、全員がそのテストのサポートに同意さえすれば、その
テストは、このポリシーを打ち壊すかもしれない。これらのポリシー破壊
(変化) は、グローバルに 6bone ルーティングテーブルへと決して影響を与
えてはならない (MUST)。
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 へと広
告するだけでなければならない (MUST)。かつ、そのサイトは、上流プロバ
イダ B から (そのサイトにより ?) 委任されたプレフィックスをプロバイ
ダ B へと広告するだけでなければならない (MUST)。もし下流が pTLA にま
で他のプロバイダの個別委任経路を漏らすなら、経路集約モデルを壊して
ルーティングテーブルへとグローバルに影響を与えるので、違反される状況
は決して存在しない。IPNG working group はマルチホーム問題を通して考
えているので、展開のための新しい戦略をテストするため、わずかにこの
ルールを改める必要があるかもしれない。しかしながら、この執筆時点での
現在の仕様では、個別経路を広告する理由はなく、pTLA は現在の集約モデ
ルを支持しなければならない (MUST)。
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 やリーフサイトのサイト境界ルータは、その上流プロバイダにより割
り当てられたプレフィックスよりも、さらに個別 (より長いプレフィックス
長) のプレフィックスを決して広告してはならない (MUST NOT)。
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 は、与えられ
た pTLA 委任 (現在 /24 または /28) より長いプレフィックスを他の
6bone pTLA へと決して広告してはならない (MUST NOT)。そのような特別な
ピアリング協定がどれか 2 つ以上の 6bone pTLA 間に置かれる時、ピアリ
ング協定に関与しない他の 6bone pTLA へと個別経路を漏らさない注意が払
われなければならない (MUST)。適切な場所にそのような協定を持つ 6bone
pTLA は、下流 6bone pNLA やリーフサイトへと他の 6bone pTLA 個別経路
を決して広告してはならない (MUST NOT)。それは、広告することにより最
適パスルーティング決定を壊すからである。
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 を通してのピアリング協定は本来非営利であり、それゆえもしありの
ままのピアリング協定が設定されるなら、通過トラフィックを許可するかも
しれない (MAY)。しかしながら、pTLA は、他の pTLA からの通過サービス
を与える、または受け取ることは必要とされない (REQUIRED)。
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.
いつかは、Internet レジストリが、6Bone TLA (3FFE::/16) とは異なって
プレフィックスを割り当てるだろう。この文書が 1999 年に執筆された時点
で、Internet レジストリは、2001::/16 TLA から /35 sub-LTA (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 間のピアリングは、起こるかもしれなく (MAY)、そのような通
過 (トラフィック) を詳細に扱い、どの経路がそれぞれのピアにより受信さ
れるかは、このメモで述べられた一般のピアリングルールの範囲外であり、
ピアリングを言明して確立しているそれら TLA と pTLA のメンバにまで任
されるだろう。しかしながら、ここで審議されるルールの大部分は新しい
TLA に等しく適用できる。
-----------------------------------------------------------------------
5. The 6Bone Registry
5. 6Bone レジストリ
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 は、次の場所で
アクセス可能である:
)
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 レジストリの関連エントリを維持しなけれ
ばならない (MUST)。特に、次に述べるオブジェクトは、全 6Bone リーフサ
イト, pNLAs と pTLAs になければならない (MUST):
- IPv6-site: site description
IPv6-site: サイト記述
- Inet6num: prefix delegation (one record MUST exist for each
delegation)
Inet6num: プレフィックス委任 (1 レコードは、個々の委任について存
在しなければならない (MUST))
- 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.)
他のオブジェクトは、routing policy descriptors, person, role オブ
ジェクトのようなサイト記述で維持されるかもしれない (MAY)。Mntner オ
ブジェクトは、role または person オブジェクトを参照しなければならな
い (MUST)。しかし、それらは 6Bone レジストリに必ずしも存在しないかも
しれない (MAY NOT)。それらは、the Internet レジストリデータベース
(ARIN, APNIC, RIPE-NCC 等) のどれかの中に格納される。
-----------------------------------------------------------------------
6. Guidelines for new sites joining the 6Bone
6. 6Bone に参加する新しいサイトのためのガイドライン
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 has various information
and tools to help find candidate 6bone networks.
6Bone に参加する新しいサイトは、その地域内の通過 pNLA または pTLA へ
接続しようと努めるべきである。そして、もしできれば、Internet サービ
スのためのできるだけ近距離の存在している IPv4 物理パスとルーティング
パスへ接続しようと努めるべきである。6Bone web site
は、候補 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 サーバを維持しなければならない (MUST)。参加するサイト
は、section 5 での記述どおりに、そのサイトに関連する 6Bone オブジェ
クトを維持しなければならない (MUST)。
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 に逆アドレス変換ゾーンを委
任しなければならない (MUST)。または、その下流のための primary DNS を
おこなうための協定を適切に持たなければならない (MUST)。プロバイダは
委任されたアドレス空間を反映している 6Bone レジストリ inet6num オブ
ジェクトも生成しなければならない (MUST)。
Up to date informatino about how to join the 6Bone is available on
the 6Bone Web site at .
6Bone にどのように参加するかの最新情報は、6Bone Web site
で利用可能である。
-----------------------------------------------------------------------
7. Guidelines for 6Bone pTLA sites
7. 6Bone サイトのためのガイドライン
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:
pTLA Applicant (応募者) は、6Bone エンドサイトまたは pNLA 通過と
して最小 3 か月間を 6Bone エンドサイトまたは pNLA 通過として経験
の資格を与えさせる。完全な資格を与える期間に、Applicant は、運用
的に次を提供していなければならない:
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.
Applicant が持つ個々のトンネルを含む、ipv6-site, inet6num,
mntner と person オブジェクトについての、十分に維持された最新
の 6Bone Registry エントリ。
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.
十分に維持され、信頼できる 6Bone への Applicant の境界ルータと
適切なコネクションポイント間の BGP4+ ピアリングと接続性。この
ルータは、IPv6 ping が可能でなければならない。この基準は、
Applicant の 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.
Applicant の (複数) ルータと少なくとも 1 つのホストシステムに
ついて、十分に維持された DNS forward (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.
Applicant の IPv6 サービスを記述している、最低でも 1 つ以上の
web ページを提供している、十分に維持され信頼できる 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:
pTLA Applicant は、"production-quality (製品品質)" の 6Bone バッ
クボーンサービスを提供するための能力と意志を持たなければならない
(MUST)。Applicants は、この要求を支持する声明と情報を提供しなけれ
ばならない。これは、次に述べるものを含まなければならない (MUST)。
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.
pTLA applicant の ipv6-site オブジェクトの個々に登録された
person 属性を持つ、最低 2 人、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.
pTLA Applicant について ipv6-site オブジェクト内の 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.
pTLA Applicant は、pTLA になることにより供給される可能な "user
community" を持たなければならない (MUST)。例えば Applicant は、地
域、国または影響力の中心である主要なプロバイダである。Applicant
は、この要求を支持する声明と情報を提供しなければならない。
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.
pTLA Applicant は、その申し込みの時点で現在の運用ルールとポリシー
は存在するので、その運用ルールとポリシーを忠実に守るように約束し
なければならない (MUST)。6Bone バックボーンと user community のコ
ンセンサス (意見の一致) により将来の 6Bone バックボーン運用ルール
とポリシーが徐々に発展されるので、その運用ルールとポリシーを忠実
に守るように同意しなければならない (MUST)。
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.
Applicant が pTLA 割り当ての受け取りを要求する時、上の基準を満たす要
求を支持する Group 情報を提供することにより、6Bone Operations Group
(下の section 8 を参照しなさい) に問い合わせる。
-----------------------------------------------------------------------
8. 6Bone Operations Group
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 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 site で維持される。
-----------------------------------------------------------------------
9. Common rules enforcement for the 6bone
9. 6bone の共通ルール実施
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.
個々の pTLA サイトは、6Bone のルールとポリシーの実行を約束し、管
理制御内のサイトによりそれらが支持されるのを保証しようと試みるべ
きである (SHOULD)。すなわち、それぞれの pTLA プレフィックスの下で
のプレフィックスが委任されていることである (???)。
2. When a site detects an issue, it SHOULD first use the 6Bone
registry to contact the site maintainer and work the issue.
サイトが問題を検出した時、サイト管理者へ連絡して解決するために
6Bone レジストリを最初に使用すべきである (SHOULD)。
3. If nothing happens, or there is disagreement on what the right
solution is, the issue SHOULD be brought to the 6Bone Operations
Group.
もし何も起こらないか、正しい解決法に不一致があるなら、その問題は
6Bone Operations Group へ提起すべきである (SHOULD)。
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.
問題が製品問題と関連する時、(複数) 関係サイトは、製品ベンダとコン
タクトを取ることに責任があるべきであり、その解決に向けて努めるべ
きである (SHOULD)。
5. When an issue causes major operational problems, backbone sites
SHOULD decide to temporarily set filters in order to restore
service.
ある問題が重大な運用問題を引き起こす時、バックボーンサイトは、
サービスを復帰させるために一時的にフィルタの設定を決定すべきであ
る (SHOULD)。
-----------------------------------------------------------------------
10. Security Considerations
10. セキュリティに関する考察
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 上のルーティングは、経路を誤った方向に導いたことに
よる denial of service 攻撃の影響を受けにくくなることが期待される。
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 testbed である。それ
ゆえ、denial of service またはパケット暴露が予期されることになる。し
かしながら、この性質の問題を分離し修正する最大の責任は、攻撃を生成し
た pTLA にある。仮にバグや誤った構成が起こるなら、他の 6Bone サイト
上に最小の影響を与える戦略上安全な場所に新しいテストシステムを置くこ
とにより、そのシステムを 6Bone へと安全に導入することは、あらゆる
6Bone サイトの責任でもある。
-----------------------------------------------------------------------
11. References
11. 参考文献
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
Allocation", RFC 2471, December 1998.
[RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC
2546, March 1999
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 2283, March
1998.
[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.
-----------------------------------------------------------------------
12. Authors' Addresses
12. 著者のアドレス
Rob Rockell
EMail: rrockell@sprint.net
Bob Fink
EMail: fink@es.net
-----------------------------------------------------------------------
13. Full Copyright Statement
13. 著作権表示全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
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 の働きに対する資金援助は、Internet Society により現在提供
される。
一覧
スポンサーリンク
