[要約] RFC 2546は、6Boneネットワークにおけるルーティングの実践に関するガイドラインです。その目的は、IPv6の実装とデプロイメントにおけるベストプラクティスを提供することです。
Network Working Group A. Durand
Request for Comments: 2546 IMAG
Category: Informational B. Buclin
AT&T Labs Europe
March 1999
6Bone Routing Practice
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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のサイトが動作する場合があります方法についてのガイドラインを示します。これは、（[RFC 2283] BGP4 +など）と外部ゲートウェイプロトコル（例えばRIPngの[RFC 2080]のような）の両方内部ゲートウェイプロトコルの設定のための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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
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のは、擬似トップレベルアグリゲータ（pTLA）サイト、擬似次のレベルアグリゲータ（pNLA）サイトや葉のサイトを持つ階層型ネットワークとして構成されています。 [1]に記載されているように、このトポロジは、IPv6アドレスの集合アーキテクチャをサポートします。 6boneの骨格はメッシュのみ相互接続pTLAsで作られています。 pNLAsは、一つ以上のpTLAsに接続して、葉のサイトのトランジットサービスを提供しています。
pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing protocol for exchanging routing information among them.
pTLAサイトはそれらの間でルーティング情報を交換するための必須のルーティングプロトコルとしてBGP4 + [RFC 2283]を使用しなければなりません。
Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP.
マルチホームサイトやpNLAsもBGP4 +を使用すべきです。定期的なサイトは、ISPに単純なデフォルトルートを使用するかもしれません。
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）集計＆広告問題
The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP.
リンクローカルプレフィックス（FE80 :: / 10）は、IGPまたはEGPのいずれかを介して広告を出してはなりません。
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:
リンクローカルプレフィックスが誤って宣伝することができよく知られている例は次のとおりです。
- a router advertising all directly connected network prefixes including the link-local one.
- リンクローカル1を含むすべての直接接続されたネットワークプレフィックスを広告するルータ。
- Subnetting of the link-local prefix.
- リンクローカルプレフィックスのサブネット。
In such cases, vendors should be urged to correct their code.
このような場合には、ベンダーは、コードを修正するよう要請しなければなりません。
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の範囲内）サイトローカルプレフィックスは、サイト内のIGPかのEGPによって宣伝されるかもしれません。サイトの正確な定義はIPngのワーキンググループで議論進行中の作業です。
Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.
サイトローカルプレフィックスはトランジットpNLAsまたはpTLAsに広告してはなりません。
The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol.
ループバック・プレフィックス（:: 1/128）および不特定のプレフィックス（:: 0/128）は、任意のルーティングプロトコルによってアドバタイズされてはいけません。
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.
もちろん、リンクローカルマルチキャストおよびノードローカルマルチキャストは、すべてのルーティングされてはなりません。
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のに使用することはありません。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
:: / 96 IPv4互換プレフィックスはのIGPによって通知されるかもしれません。
IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.
IPv4互換プレフィックスはトランジットpNLAsまたはpTLAsへのEGPによってアドバタイズしてはなりません。
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）サイト内のIGPによってアドバタイズされるかもしれません。サイト内のいくつかのIPv6ノードのみが翻訳装置を指し、このようなルートを持っていることは有用である可能性があります。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
IPv4マッププレフィックスは、のEGPによってアドバタイズしてはなりません。
6Bone core pTLA routers MUST be default-free.
6boneのコアpTLAルータは、デフォルトフリーでなければなりません。
pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do the same for their leaf sites.
pTLAsは彼らのpNLAsへのデフォルトルートを広告するかもしれません。トランジットpNLAsは、その葉のサイトに対して同じことを行うことができます。
Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone.
まだ2000以外の他のフォーマットプレフィックスから未定義のユニキャストプレフィクス:: / 3は、6boneの内の任意のルーティングプロトコルによってアドバタイズされてはいけません。具体的には、RFC 2471テストアドレスは、6boneので宣伝してはなりません。
Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) is discussed in section 4, Routing policies, below.
6boneの範囲（3FFE :: / 16）の外部グローバルユニキャストプレフィクスのルーティングは、以下に、セクション4、ルーティングポリシーに記載されています。
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.
これらのリンクのための接頭辞は、グローバルルーティングテーブルに注入してはなりません。
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から割り当てられたプレフィックスを通知しなければなりません。
Site border router MUST NOT advertise prefixes more specific than the /48 ones allocated by their ISP.
サイト境界ルータは、そのISPによって割り当てられた/ 48のものよりも、より具体的なプレフィックスを通知してはなりません。
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は、他のpTLAsに24より長いプレフィックスを通知してはなりません。そのような特別なピアリング契約は、任意の2つ以上pTLAsとの間の所定の位置にあるときは、注意がピアリング協定に参加していない他のpTLAsに、より具体的な接頭辞を漏洩しないように注意しなければなりません。
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）他のバック骨部位とピアリングを維持しなければなりません。
The peering agreements across the 6Bone are by nature non-commercial, and therefore SHOULD allow transit traffic through.
6boneの間でピアリング契約は自然非商業的であり、したがって通る通過トラフィックを許可する必要があります。
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.
最終的には、インターネットレジストリが6boneの1以外のTLASを割り当てます（現在は3FFE :: / 16）。これらTLASを保有する組織は、新たなIPv6ネットワーク、6boneのに対して平行を確立します。 6boneのは6boneの全体B UTトランジットは保証されません、この新しいIPv6インターネットと相互接続することがあります。 IPv6インターネットへまたはからのトラフィックを運ぶかどうかを決定するために、それぞれの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のレジストリは、6boneの情報を格納するために使用されるIPv6の拡張と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のいずれかの内に格納することができます。
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の入社新サイトでは、地域内のトランジットpNLAまたはpTLAに接続しようと、インターネットサービスのための彼らの既存のIPv4物理的およびルーティングパスになるべく近いはずです。 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サーバを維持しなければなりません。参加サイトが6boneのレジストリは、そのサイト、特にIPv6-サイトとのmntnerオブジェクトに対するオブジェクト維持しなければなりません。
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はまた、委任アドレス空間（inet6num :)を反映した6boneのレジストリオブジェクトを作成する必要があります。
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のWebサイトで入手可能です。
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.サイトは、少なくとも葉のサイトとして、好ましくは、既存のpTLA下トランジットpNLAとして、6boneの上で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の運用グループにするために適用されます。
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の操作群は、本規則の遵守を監視する担当体であり、ずれを補正するために適切な行動をとるであろう。 6boneの運用グループのメンバーシップは、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の運用グループは、現在の6boneに参加サイトを表し、それらの既存の6boneメーリングリストのメンバー、すなわち、6bone@isi.edu、によって定義されます。そのためには、メーリングリストに参加するために、関連するサイトの連絡先に現職です。リストに参加する方法については、http://www.6bone.netで6boneのWebサイト上で維持されています。
Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules 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の運用グループにすることができます。
- 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.
- 問題は、製品の問題に関連している場合は、関連するサイト（複数可）、接触決議に向けた製品ベンダーと仕事を担当しています。
- When an issue causes major operational problems, backbone sites may decide to temporarily set filters in order to restore service.
- 問題が主要な操作上の問題が発生した場合、バックボーンサイトが一時的にサービスを回復するために、フィルタを設定することもできます。
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.
The 6Bone is a test network. Therefore, denial of service, packet disclosure, are to be expected.
6boneのは、テストネットワークです。そのため、サービス、パケットの開示、拒否が予想されます。
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.
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[1] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[RFC 2471] HindenとR.、フィンク、R.およびJ.ポステル（故人）、 "IPv6のテストアドレス割り当て"、RFC 2471、1998年12月。
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC 2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998.
[RFC 2283]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2283、1998年3月。
[RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[RIPE-181]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、J.、Karrenberg、D.、テルプストラ、M.及びJ.ゆう、ルーティングレジストリにIPルーティングポリシーの表現。テクニカルレポート熟し-181、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France
グルノーブルIMAG BP 53 38041グルノーブルセデックス9、フランスのコンピュータ科学と応用数学のアラン・デュラン研究所
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 Eメール：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.社ルートドゥアエロ31、CP 72 CH-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 Eメール：Bertrand.Buclin@ch.att.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。