RFC2546 日本語訳
2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT=17844 bytes) (Obsoleted by RFC2772) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Durand
Request for Comments: 2546 IMAG
Category: Informational B. Buclin
AT&T Labs Europe
March 1999
コメントを求めるワーキンググループA.ジュランドの要求をネットワークでつないでください: 2546年のIMAGカテゴリ: 1999年の情報のB.Buclin AT&Tの研究室ヨーロッパの行進
6Bone Routing Practice
6Boneルート設定練習
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Introduction
1. 序論
The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6Bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites.
6BoneはIPv6プロトコルと製品がそれを実行している実験を支持する環境です。 ネットワークが成長するのに従って、一般的な操作規定の必要性は現れました。 葉によるにせのルートか背骨サイトさえの頻繁な挿入のために6Bone背骨の操作は特に、挑戦です。
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]).
このメモは6Boneサイトがどう作動するかもしれないかに関するガイドラインを特定します、6Boneが上質の実験環境のままで残ることができて、それが過去に病理学的な状況を避けるために遭遇したように。 それはInteriorゲートウェイプロトコル(RIPng[RFC2080]などの)とExteriorゲートウェイプロトコル(BGP4+[RFC2283]のような)の両方の構成において、6Boneで許容できる'最も良い現在の習慣'を定義します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Basic principles
2. 基本原理
The 6Bone is structured as a hierarchical network with pseudo Top Level Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA) sites and leaf sites. This topology supports the IPv6 address aggregation architecture as described in [1]. The 6Bone backbone is made of a mesh interconnecting pTLAs only. pNLAs connect to one or more pTLAs and provide transit service for leaf sites.
6Boneは階層的なネットワークとして疑似Top Level Aggregator(pTLA)サイト、疑似Next Level Aggregator(pNLA)サイト、および葉のサイトで構造化されます。 このトポロジーは[1]で説明されるようにIPv6アドレス集合構造をサポートします。 6Bone背骨はpTLAsだけとインタコネクトするメッシュで作られています。pNLAsは1pTLAsに接続して、トランジットサービスを葉のサイトに提供します。
Durand & Buclin Informational [Page 1] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[1ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing protocol for exchanging routing information among them.
pTLAサイトは、それらの中でルーティング情報を交換するのに、義務的なルーティング・プロトコルとしてBGP4+[RFC2283]を使用しなければなりません。
Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP.
また、遺跡かpNLAs SHOULDがBGP4+を使用します。マルチ、家へ帰り、通常のサイトは簡単なデフォルトルートをそれらのISPに使用するかもしれません。
3. Common Rules
3. 共通規則
This section details common rules governing the routing on the 6Bone. They are derived from 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 prefix & unspecified prefix
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) aggregation & advertisement issues
10) 集合と広告問題
3.1 Link-local prefix
3.1 リンクローカルの接頭語
The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP.
IGPかEGPのどちらかを通してリンクローカルの接頭語(FE80: : /10)の広告を出してはいけません。
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:
リンクのローカルの接頭語を間違って広告に掲載できたよく知られているケースのは:
Durand & Buclin Informational [Page 2] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[2ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
- 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.
そのような場合、業者が彼らのコードを修正するよう促されるべきです。
3.2 Site-local prefixes
3.2 サイトローカルの接頭語
Site local prefixes (in the FEC0::/10 range) MAY be advertized by IGPs or EGPs within a site. The precise definition of a site is ongoing work discussed in the IPng working group.
サイトのローカルの接頭語(FEC0で: : /10は及ぶ)はサイトの中のIGPsかEGPsによってadvertizedされるかもしれません。 サイトの厳密な定義はIPngワーキンググループで議論した進行中の仕事です。
Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.
トランジットpNLAsかpTLAsにサイトのローカルの接頭語の広告を出してはいけません。
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)の広告を出してはいけません。
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 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.
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に向かってサイト地方のマルチキャストを発送してはいけません。
Obviously, link-local multicasts and node-local multicasts MUST NOT be routed at all.
明らかに、リンク地方のマルチキャストとノード地方のマルチキャストを全く発送してはいけません。
3.5 IPv4-compatible prefixes
3.5 IPv4コンパチブル接頭語
Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. As there is no real rationale today for doing that, these addresses SHOULD
サイトは、内部的に、IPv4コンパチブルアドレス(: : a.b.c.d)を使用するのを選ぶかもしれません。 今日、どんな本当の原理もそれをするためにないとき、これらはSHOULDを記述します。
NOT be used in the 6Bone.
6Boneで使用されないでください。
Durand & Buclin Informational [Page 3] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[3ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
:、:/96IPv4コンパチブル接頭語はIGPsによって広告を出されるかもしれません。
IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.
IPv4コンパチブル接頭語はEGPsによってトランジットpNLAsかpTLAsに広告を出されてはいけません。
3.6 IPv4-mapped prefixes
3.6 IPv4によって写像された接頭語
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is 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.
IPv4によって写像された接頭語(: : FFFF: a.b.c.dがIPv4アドレスであるa.b.c.d)はサイトの中にIGPsによって広告を出されるかもしれません。 それはいくらかのIPv6の役に立つかもしれません。そのようなルートに翻訳装置を示させるサイトの中のノードだけ。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
IPv4によって写像された接頭語はEGPsによって広告を出されてはいけません。
3.7 Default routes
3.7 デフォルトルート
6Bone core pTLA routers MUST be default-free.
6BoneコアpTLAルータはデフォルトなしであるに違いありません。
pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do the same for their leaf sites.
pTLAsは彼らのpNLAsにデフォルトルートの広告を出すかもしれません。 トランジットpNLAsは同じように彼らの葉のサイトにするかもしれません。
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を除いて、形式からのしかし、未定義のユニキャスト接頭語は以下を前に置きます:6Boneのどんなルーティング・プロトコルも/3の広告を出してはいけません。 特に、6BoneにRFC2471テストアドレスの広告を出してはいけません。
Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) is discussed in section 4, Routing policies, below.
グローバルなユニキャストのルート設定は(3FFE: : /16)について議論する6Bone範囲の外にセクション4、以下のルート設定方針を前に置きます。
3.9 Inter-site links
3.9 相互サイトリンク
Global IPv6 addresses MUST be used for the end points of the inter- site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
相互サイトリンクのエンドポイントにグローバルなIPv6アドレスを使用しなければなりません。 特に、トンネルにIPv4コンパチブルアドレスを使用してはいけません。
Prefixes for those links MUST NOT be injected in the global routing tables.
グローバルな経路指定テーブルでそれらのリンクへの接頭語を注入してはいけません。
3.10 Aggregation & advertisement issues
3.10 集合と広告問題
Route aggregation MUST be performed by any border router.
どんな境界ルータでもルート集合を実行しなければなりません。
Sites or pNLAs MUST only advertise to their upstream provider the prefixes assigned by that ISP unless otherwise agreed.
サイトかpNLAsが別の方法で同意されない場合そのISPによって割り当てられた接頭語の彼らの上流のプロバイダーに広告を出すだけでよいです。
Durand & Buclin Informational [Page 4] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[4ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
Site border router MUST NOT advertise prefixes more specific than the /48 ones allocated by their ISP.
サイト境界ルータは48のものがそれらのISPで割り当てた/より特定の接頭語の広告を出してはいけません。
pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless special peering agreements are implemented. When such special peering agreements are in place between any two or more pTLAs, care MUST be taken not to leak the more specific prefixes to other pTLAs not participating in the peering agreement.
特別なじっと見る協定が履行されない場合、pTLAは24より長い間、他のpTLAsに接頭語の広告を出してはいけません。 どんな2pTLAsの間にもそのような特別なじっと見る協定が適所にあるとき、じっと見る協定に参加しない他のpTLAsにより特定の接頭語を漏らさないように注意しなければなりません。
4. Routing policies
4. ルート設定方針
6Bone backbone sites maintain the mesh into the backbone and provide an as reliable as possible service, granted the 6Bone is an experimentation tool. To achieve their mission, 6Bone backbone sites MUST maintain peerings with at least 3 (three) other back bone sites.
6Bone背骨サイトが背骨にメッシュを維持して、提供される、信頼できる、可能なサービス、6Boneを与えているのは、実験ツールです。 彼らの任務を達成するために、6Bone背骨サイトは他の少なくとも3つ(3)の逆骨のサイトがあるpeeringsを維持しなければなりません。
The peering agreements across the 6Bone are by nature non-commercial, and therefore SHOULD allow transit traffic through.
自然で、6Boneの向こう側のじっと見る協定は非営利的です、そして、したがって、SHOULDはトランジット交通の通ることを許します。
Eventually, the Internet registries will assign other TLAs than the 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs will establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT interconnect with this new IPv6 Internet, b ut transit across the 6Bone will not be guaranteed. It will be left to each 6Bone backbone site to decide whether it will carry traffic to or from the IPv6 Internet.
結局、インターネット登録は6Bone1(現在の3FFE: : /16)以外のTLAsを割り当てるでしょう。 それらのTLAsを持っている組織は新しいIPv6ネットワーク、6Boneへの平行線を確立するでしょう。 6Boneの向こう側のb utトランジットは6Bone MIGHTがこの新しいIPv6インターネットで内部連絡するのが保証されないでしょう。 それが、インターネットかIPv6インターネットから交通を運ぶかどうか決めるのがそれぞれの6Bone背骨サイトに残されるでしょう。
5. The 6Bone registry
5. 6Bone登録
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone. Each 6Bone site MUST maintain the relevant entries in the 6Bone registry (whois.6bone.net). In particular, the following objects MUST be present:
6Bone登録はIPv6拡張子が6Boneの情報を格納するのに使用されているRIPE-181データベースです。 それぞれの6Boneサイトは6Bone登録(whois.6bone.net)で関連エントリーを維持しなければなりません。 以下の物は特に、存在していなければなりません:
- IPv6-site: site description
- IPv6-サイト: サイト記述
- Inet6num: prefix delegation
- Inet6num: 接頭語代表団
- Mntner: coordinate of site maintenance staff
- Mntner: サイト整備員の座標
Other objects 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 must not necessarily reside in the 6Bone registry, they can be stored within any of the Internet registry databases (RIPE, InterNIC, APNIC,
他の物はルーティング方針記述子、人または役割の物などのサイトの裁量で維持されるかもしれません。 Mntner物が役割か人の物について言及しなければなりませんが、ものが必ず6Bone登録に住んでいなければならないというわけではなくて、インターネット登録データベースのどれかの中にそれらは格納できる、(RIPE、InterNIC、APNIC
Durand & Buclin Informational [Page 5] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[5ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
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 registry is available to find out candidate ISPs.
6Boneを接合する新しいサイトは望ましくはできるだけインターネットのサービスのためのそれらの既存のIPv4物理的で掘っている経路の近くでそれらの領域の中でpNLAかpTLAをトランジットに接続しようとするべきです。 6Bone登録は、候補ISPを見つけるために利用可能です。
Any site connected to the 6Bone MUST maintain a DNS server for forward name looking and reverse address translation. The joining site MUST maintain the 6Bone registry objects relative to its site, and in particular the IPv6- site and the MNTNER objects.
6Boneにつなげられたどんなサイトも、前進の名前の見るDNSサーバを維持して、アドレス変換を逆にしなければなりません。 接合サイトは特にサイト、IPv6サイト、およびMNTNER物に比例して6Bone登録物を維持しなければなりません。
The upstream ISP MUST delegate the reverse address translation zone in DNS to the joining site. The ISP MUST also create 6Bone registry objects reflecting the delegated address space (inet6num:).
上流のISPはDNSの逆のアドレス変換ゾーンを接合サイトへ代表として派遣しなければなりません。 また、代表として派遣されたアドレス空間を反映して、ISPが6Bone登録物を作成しなければならない、(inet6num:、)
Up to date information about how to join the 6Bone is available on the 6Bone Web site at http://www.6bone.net.
どう接合するかの日付の情報まで、6Boneは http://www.6bone.net の6Boneウェブサイトで利用可能です。
7. Guidelines for 6Bone pTLA sites
7. 6Bone pTLAサイトのためのガイドライン
6Bone pTLA sites are altogether forming the backbone of the 6Bone. In order to ensure the highest level possible of availability and stability for the 6Bone environment, a few constraints are placed onto sites wishing to become or stay a 6Bone pTLA:
6Bone pTLAサイトは6Boneの背骨を全体で形成しています。 6Bone環境に、有用性と安定性で可能な最高水準を確実にするために、いくつかの規制がなりたいか、または6Bone pTLAに滞在したがっているサイトに、置かれます:
1. The site MUST have experience with IPv6 on the 6Bone, at least as
a leaf site and preferably as a transit pNLA under an existing
pTLA.
1. サイトは少なくとも葉のサイトとして6Boneと、望ましくはトランジットpNLAとして既存のpTLAの下にIPv6の経験を持たなければなりません。
2. The site MUST have the ability and intent to provide "production-
like" 6Bone backbone service to provide a robust and operationally
reliable 6Bone backbone.
2. サイトには、能力と強健で操作上信頼できる6Bone背骨を提供するために「生産同様」の6Bone背骨サービスを提供する意図がなければなりません。
3. The site MUST have a potential "user community" that would be
served by becoming a pTLA, e.g., the requester is a major player
in a region, country or focus of interest.
3. サイトには、pTLAになることによって役立たれている潜在的「ユーザーコミュニティ」がなければなりません、例えば、リクエスタは興味がある領域、国または焦点の一流選手です。
4. Must commit to abide by the 6Bone backbone operational rules and
policies as defined in the present document.
4. 現在のドキュメントで定義されるように6Boneの背骨の操作上の規則と方針を守るために公約しなければなりません。
When a candidate site seeks to become a pTLA site, it will apply for it to the 6Bone Operations group (see below) by bringing evidences it meets the above criteria.
候補地がpTLAサイトになろうとするなら、上の評価基準を満たすという証拠をもたらすことによって、それは6Bone Operationsグループ(以下を見る)にそれに申し込むでしょう。
Durand & Buclin Informational [Page 6] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[6ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
8. 6Bone Operations group
8. 6Bone Operationsグループ
The 6Bone Operations group is the body in charge of monitoring the adherence to the present rules, and will take the appropriate actions to correct deviations. Membership in the 6Bone Operations group is mandatory for, and restricted to, any site connected to the 6Bone.
6Bone Operationsグループは、現在の規則に固守をモニターすることを担当したボディーであり、逸脱を修正するために適切な行動を取るでしょう。 6Bone Operationsグループにおける会員資格は義務的であって、部外秘であることで、どんなサイトも6Boneに接続したということです。
The 6Bone Operations group is currently defined by those members of the existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent sites participating on the 6Bone. Therefore it is incumbent on relevant site contacts to join the mailing list. Instructions on how to join the list are maintained on the 6Bone web site at http://www.6bone.net.
6Bone Operationsグループは現在、すなわち、既存の6Boneメーリングリストのそれらのメンバー、6Boneに参加するサイトを表す 6bone@isi.edu によって定義されます。 したがって、関連サイト接触では、メーリングリストを接合するのは現職です。 どうリストを接合するかに関する指示は http://www.6bone.net の6Boneウェブサイトで維持されます。
9. Common rules enforcement
9. 共通規則実施
Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules described in this document, in order to maintain the 6Bone as quality tool for experimenting with the IPv6 protocols and products implementing them.
6Boneへの参加は自発的の、そして、慈善の仕事です。 しかしながら、参加サイトが本書では説明された規則を固く守ると予想されます、それらを実行するIPv6プロトコルと製品を実験するための上質のツールとして6Boneを維持するために。
The following processes are proposed to help enforcing the 6Bone rules:
以下の過程は6Bone規則を実施するのを助けるために提案されます:
- Each pTLA site has committed when requesting their pTLA to
implement the rules, and to ensure they are respected by sites
within their administrative control (i.e. those to who prefixes
have been delegated).
- 規則を実行して、それらが彼らの運営管理コントロール(すなわち、接頭語がだれであるかへ代表として派遣されたもの)の中でサイトによって尊敬されるのを保証するようそれらのpTLAに要求するとき、それぞれのpTLAサイトは公約されました。
- When a site detects an issue, it will first use the 6Bone registry
to contact the site maintainer and work the issue.
- サイトが問題を検出するとき、それは、最初に、サイト維持装置に連絡して、問題を扱うのに6Bone登録を使用するでしょう。
- If nothing happens, or there is disagreement on what the right
solution is, the issue can be brought to the 6Bone Operations
group.
- 何も起こらないか、または正しい解決が何であるかに関して不一致があれば、6Bone Operationsグループに問題をもたらすことができます。
- When the problem is related to a product issue, the site(s)
involved is responsible for contact the product vendor and work
toward its resolution.
- 問題が関係づけられたら製品問題、かかわった(s)は責任があるサイトに、製品業者に連絡してください、そして、解決に向かって取り組んでください。
- When an issue causes major operational problems, backbone sites may
decide to temporarily set filters in order to restore service.
- 問題が主要な運転上の問題を引き起こすと、背骨サイトは、復旧するために一時フィルタを設定すると決めるかもしれません。
Durand & Buclin Informational [Page 7] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[7ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
10. Security Considerations
10. セキュリティ問題
The result of bogus 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
guidelines, routing on the 6Bone will be less sensitive to denial
of service attacks due to misleading routes.
経路指定テーブルのにせのエントリーの結果は通常手の届かないサイトです。 集めるガイドラインか廃棄物ルートを持っていると、経路指定テーブルは掃除するでしょう。 これらのガイドラインを使用して、6Boneの上のルーティングがそれほど紛らわしいルートによるサービス不能攻撃に敏感にならないと予想されます。
The 6Bone is a test network. Therefore, denial of service, packet
disclosure, are to be expected.
6Boneはテストネットワークです。 したがって、サービスの否定、パケット公開は予想されることです。
11. Acknowledgements
11. 承認
This document is the result of shared experience on the 6Bone.
Special thanks go to Bob Fink for the hard work make to date to
direct the 6Bone effort, to David Kessens for the 6Bone registry,
and to Guy Davies for his insightful contributions.
このドキュメントは6Boneにおける共有経験の結果です。 特別な感謝は6Boneの努力までダイレクトにさかのぼりに仕事が作る困難のためのボブFinkに行きます、6Bone登録と、彼の洞察に満ちた貢献のためのガイ・デイヴィースへのデヴィッドKessensに。
12. References
12. 参照
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[1]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6
Testing Address Allocation", RFC 2471, December 1998.
[RFC2471] HindenとR.と密告者とR.とJ.ポステル(死んだ)、「IPv6テストアドレス配分」、RFC2471、1998年12月。
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2080] マルキンとG.とR.Minnear、「IPv6"、RFC2080、1997年1月のためのRIPng。」
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 2283, March
1998.
[RFC2283] ベイツとT.とチャンドラとR.とキャッツとD.とY.Rekhter、「BGP-4インチのためのMultiprotocol拡張子、RFC2283、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.
[熟している181] ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、J.、Karrenberg、D.、テルプストラ、M.、およびJ.ユー(ルート設定登録のIPルート設定方針の表現)。 RIPE、RIPE NCC、アムステルダムオランダ1994年10月の技術的なReport熟している181。
Durand & Buclin Informational [Page 8] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[8ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
13. Authors' Addresses
13. 作者のアドレス
Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France
アランジュランドInstitut d'Informatique et de Mathematiques Appliquees deグルノーブルIMAG BP53 38041グルノーブルCEDEX9フランス
Phone : +33 4 76 63 57 03 Fax : +33 4 76 51 49 64 EMail: Alain.Durand@imag.fr
以下に電話をしてください。 +33 4 76 63 57 03ファックス: +33 4 76 51 49 64はメールされます: Alain.Durand@imag.fr
Bertrand Buclin AT&T International S.A. Route de l'aeroport 31, CP 72 CH-1215 Geneve 15 (Switzerland)
バートランドBuclin AT&TインターナショナルS.A.Route de l'aeroport31、CP72CH-1215ジュネーブ15(スイス)
Phone : +41 22 929 37 40 Fax : +41 22 929 39 84 EMail: Bertrand.Buclin@ch.att.com
以下に電話をしてください。 +41 22 929 37 40ファックス: +41 22 929 39 84はメールされます: Bertrand.Buclin@ch.att.com
Durand & Buclin Informational [Page 9] RFC 2546 6Bone Routing Practice March 1999
ジュランドとBuclinの情報[9ページ]のRFC2546 6Boneルート設定は1999年3月に練習されます。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Durand & Buclin Informational [Page 10]
ジュランドとBuclin情報です。[10ページ]
一覧
スポンサーリンク
