RFC1786 日本語訳
1786 Representation of IP Routing Policies in a Routing Registry(ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D.Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT=133643 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Bates
Request for Comments: 1786 MCI Telecommunications Corporation
Category: Informational E. Gerich
Merit, Inc.
L. Joncheray
Merit, Inc.
J-M. Jouanigot
CERN
D. Karrenberg
RIPE NCC
M. Terpstra
Bay Networks, Inc.
J. Yu
Merit, Inc.
March 1995
ネットワークワーキンググループT.はコメントを求める要求を和らげます: 1786年のMCIテレコミュニケーション社のカテゴリ: 情報のE.Gerich長所Inc.L.JoncherayはInc.J-Mに値します。 1995年のNCCのM.テルプストラのベイネットワークスのInc.J.ユーの長所Inc.行進のときに熟しているJouanigot CERN D.Karrenberg
Representation of IP Routing Policies
in a Routing Registry
(ripe-81++)
ルート設定登録のIPルート設定方針の表現(熟している81++)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received community wide interest and acknowledgment throughout the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation. It can also be referred to as ripe-81++. This document is an update to the original `ripe-81'[1] proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.[2] and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry.
このドキュメントは、元々、熟している181として知られているRIPEドキュメントとして発行されましたが、また、元の範囲より大きい聴衆に届くようにInformational RFCとして発表されています。 それは、共同体の広い関心と承認をインターネット接続サービス業者共同体に受けて、インターネットルート設定Registriesとルーティング方針表現への今後の活動に基本的な出発点として使用されるでしょう。 また、熟している81++とそれを呼ぶことができます。このドキュメントはルーティングを表して、保存するための[1]提案がRIPEデータベースの中で取り締まるオリジナルの'熟している81'への最新版です。 それは、すべてのインターネット・ルーティング登録によって使用されるためにMerit Inc.[2]によって提案されたいくつかの拡大を取り入れて、一般化されたIPルーティング方針表現の詳細を明らかにします。 それは、ともに家庭教師として機能して、ルーティング登録を使用して、作るデータベースオブジェクトと属性の詳細を明らかにします。
Bates, et al. [Page 1] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [1ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Table of Contents
目次
1. Introduction ................................................ 3
1. 序論… 3
2. Organization of this Document ............................... 3
2. このDocumentの組織… 3
3. General Representation of Policy Information ............... 5
3. 方針情報の一般表現… 5
4. The Routing Registry and the RIPE Database .................. 11
4. ルート設定登録と熟しているデータベース… 11
5. The Route Object ............................................ 16
5. ルートオブジェクト… 16
6. The Autonomous System Object ................................ 26
6. 自律システムオブジェクト… 26
7. AS Macros ................................................... 36
7. マクロとして… 36
8. The Community Object ........................................ 38
8. 共同体は反対します… 38
9. Representation of Routing Policies .......................... 41
9. ルート設定方針の表現… 41
10. Future Extensions .......................................... 50
10. 今後の拡大… 50
11. References ................................................. 51
11. 参照… 51
12. Security Considerations .................................... 52
12. セキュリティ問題… 52
13. Authors' Addresses ......................................... 53
13. 作者のアドレス… 53
Appendix A - Syntax for the "aut-num" object ................... 55
付録A--"aut-num"のための構文は反対します… 55
Appendix B - Syntax for the "community" object ................. 68
付録B--「共同体」への構文は反対します… 68
Appendix C - Syntax for the "as-macro" object .................. 72
付録C--、「マクロ」としてのオブジェクトのための構文… 72
Appendix D - Syntax for the "route" object ..................... 76
付録D--「ルート」への構文は反対します… 76
Appendix E - List of reserved words ............................ 80
付録E--リザーブドワードのリスト… 80
Appendix F - Motivations for RIPE-81++ ......................... 81
付録F(熟している81++に関する動機)… 81
Appendix G - Transition strategy ............................... 83
付録G--変遷戦略… 83
Bates, et al. [Page 2] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [2ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
1. Introduction
1. 序論
This document is a much revised version of the RIPE routing registry document known as ripe-81 [1]. Since its inception in February, 1993 and the establishment of the RIPE routing registry, several additions and clarifications have come to light which can be better presented in a single updated document rather than separate addenda.
このドキュメントは熟している81[1]として知られているRIPEルーティング登録ドキュメントの多くの改訂版です。 以来、1993年2月の始まりとRIPEルーティング登録、いくつかの追加、および明確化の設立は別々の付加物よりむしろただ一つのアップデートされたドキュメントに示すことができるほうがよい光に来ています。
Some of the text remains the same the as the original ripe-81 document keeping its tutorial style mixed with details of the RIPE database objects relating to routing policy representation. However this document does not repeat the background and historical remarks in ripe-81. For these please refer to the original document. It should be noted that whilst this document specifically references the RIPE database and the RIPE routing registry one can easily read "Regional routing registry" in place of RIPE as this representation is certainly general and flexible enough to be used outside of the RIPE community incorporating many ideas and features from other routing registries in this update.
ルーティング方針表現に関連するRIPEデータベースオブジェクトの細部に家庭教師のスタイルを混ぜ続けながら、テキストのいくつかがオリジナルとしての熟している81が記録する同じくらいのままで残っています。 しかしながら、このドキュメントは熟している81におけるバックグラウンドと歴史的な所見を繰り返しません。 これらについて、正本を参照してください。 明確にRIPEデータベースとRIPEルーティング登録1が容易にこの表現としてのRIPEに代わって「地方のルーティング登録」を読み込むことができる参照がこのドキュメントである間外で他のルーティング登録からの多くの考えと特徴をこのアップデートに取り入れるRIPE共同体で使用されているほど確かに、一般的であって、フレキシブルであることに注意されるべきです。
This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received large interest and acknowledgment within the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation. It but can also be referred to as ripe-81++.
このドキュメントは、元々、熟している181として知られているRIPEドキュメントとして発行されましたが、また、元の範囲より大きい聴衆に届くようにInformational RFCとして発表されています。 それは、インターネット接続サービス業者共同体の中で大きい関心と承認を受けて、インターネットルート設定Registriesとルーティング方針表現への今後の活動に基本的な出発点として使用されるでしょう。 しかし、それ、また、熟している81++と呼ぶことができます。
We would like to acknowledge many people for help with this document. Specifically, Peter Lothberg who was a co-author of the original ripe-81 document for his many ideas as well as Gilles Farrache, Harvard Eidnes, Dale Johnson, Kannan Varadhan and Cengiz Alaettinoglu who all provided valuable input. We would also like to thank the RIPE routing working group for their review and comment. Finally, we like to thank Merit Inc. for many constructive comments and ideas and making the routing registry a worldwide Internet service. We would also like to acknowledge the funding provided by the PRIDE project run in conjunction with the RARE Technical Program, RIPE and the RIPE NCC without which this paper would not have been possible.
このドキュメントによる助けのために多くの人々を承認したいと思います。 明確に、オリジナルの熟している81のものの共著者であったピーターLothbergは、ジルFarrache、ハーバードEidnes、デール・ジョンソン、Kannan Varadhan、およびCengiz Alaettinogluと同様に彼の多くの考えのためにだれが貴重な入力をすべて提供したかを記録します。 また、彼らのレビューとコメントについてRIPEルーティングワーキンググループに感謝申し上げます。 最終的に、私たちは、多くの建設的なコメントと、考えとルーティング登録を世界的なインターネットのサービスにして頂いて、Merit Inc.に感謝するのが好きです。 また、PRIDEプロジェクトによって提供された基金がRARE Technical Program、RIPE、およびRIPE NCCとのこの紙が可能でない接続詞に立候補すると認めたいと思います。
2. Organization of this Document
2. このDocumentの組織
This document acts as both a basic tutorial for understanding routing policy and provides details of objects and attributes used within an Internet routing registry to store routing policies. Section 3 describes general issues about IP routing policies and their representation in routing registries. Experienced readers may wish to skip this section. Section 4 provides an overview of the RIPE
このドキュメントは、理解ルーティング方針のために両方として基本的なチュートリアルを機能させて、ルーティング方針を保存するのにインターネット・ルーティング登録の中で使用されたオブジェクトと属性の詳細を明らかにします。 セクション3はルーティング登録でIPルーティング方針と彼らの表現に関する一般答弁について説明します。 経験豊富な読者はこのセクションをスキップしたがっているかもしれません。 セクション4はRIPEの概要を提供します。
Bates, et al. [Page 3] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [3ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
database, its basic concepts, schema and objects which make up the database itself. It highlights the way in which the RIPE database splits routing information from allocation information. Sections 5, 6, 7 and 8 detail all the objects associated with routing policy representation. Section 9 gives a fairly extensive "walk through" of how these objects are used for expressing routing policy and the general principles behind their use. Section 10 provides a list of references used throughout this document. Appendix A, B, C and D document the formal syntax for the database objects and attributes. Appendix F details the main changes from ripe-81 and motivations for these changes. Appendix G tackles the issues of transition from ripe-81 to ripe-81++.
データベース自体を作るデータベース、基本概念、図式、およびオブジェクト。 それはRIPEデータベースが配分情報からルーティング情報を分ける方法を強調します。 セクション5、6、7、および8はルーティング方針表現に関連しているすべてのオブジェクトについて詳述します。 セクション9はこれらのオブジェクトが彼らの使用の後ろでルーティング方針と綱領を急送するのにどう使用されるかに関するかなり大規模な「ウォークスルー」を与えます。 セクション10はこのドキュメント中で使用される参考文献一覧を提供します。 付録A、B、C、およびDはデータベースオブジェクトと属性のために正式な構文を記録します。 付録Fはこれらの変化に関する熟している81と動機から主な変化について詳述します。 付録Gは熟している81〜熟している81++までの変遷の問題に取り組みます。
Bates, et al. [Page 4] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [4ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
3. General Representation of Policy Information
3. 方針情報の一般表現
Networks, Network Operators and Autonomous Systems
ネットワーク、ネットワーク・オペレータ、および自律システム
Throughout this document an effort is made to be consistent with terms so as not to confuse the reader.
このドキュメント中では、取り組みは読者を混乱させないように用語と一致しているのが作られています。
When we talk about "networks" we mean physical networks which have a unique classless IP network number: Layer 3 entities. We do not mean organizations.
「ネットワーク」に関して話すとき、私たちはユニークな階級のないIPネットワーク・ナンバーを持っている物理ネットワークを言っています: 3つの実体を層にしてください。 私たちは組織を言っていません。
We call the organizations operating networks "network operators". For the sake of the examples we divide network operators into two categories: "service providers" and "customers". A "service provider" is a network operator who operates a network to provide Internet services to different organizations, its "customers". The distinction between service providers and customers is not clear cut. A national research networking organization frequently acts as a service provider to Universities and other academic organizations, but in most cases it buys international connectivity from another service provider. A University networking department is a customer of the research networking organization but in turn may regard University departments as its customers.
私たちは、組織を操作ネットワーク「ネットワーク・オペレータ」と呼びます。 例のために、私たちはネットワーク・オペレータを2つのカテゴリに分割します: 「サービスプロバイダー」と「顧客。」 「サービスプロバイダー」は異なった組織、「顧客」にインターネットのサービスを提供するためにネットワークを経営するネットワーク・オペレータです。 サービスプロバイダーと顧客の区別は明確なカットではありません。 国家の研究ネットワーク組織はサービスプロバイダーとして頻繁に大学と他の学術機関に務めますが、多くの場合、それは別のサービスプロバイダーから国際的な接続性を買います。 大学ネットワーク部は、研究ネットワーク組織の顧客ですが、順番に大学部を顧客と見なすかもしれません。
An Autonomous System (AS) is a group of IP networks having a single clearly defined routing policy which is run by one or more network operators. Inside ASes IP packets are routed using one or more Interior Routing Protocols (IGPs). In most cases interior routing decisions are based on metrics derived from technical parameters like topology, link speeds and load. The entity we refer to as an AS is frequently and more generally called a routing domain with the AS just being an implementation vehicle. We have decided to use the term AS exclusively because it relates more directly with the database objects and routing tools. By using only one term we hope to reduce the number of concepts and to avoid confusion. The academically inclined reader may forgive us.
Autonomous System(AS)は1人以上のネットワーク・オペレータによって実行される明確に定義されたただ一つのルーティング方針を持っているIPネットワークのグループです。 内面のASes IPパケットは、1つ以上のInteriorルート設定プロトコル(IGPs)を使用することで発送されます。 多くの場合、内部のルーティング決定は、トポロジーのような技術的パラメータから得られた測定基準に基づいていて、速度をリンクして、ロードされます。 頻繁でより一般に、私たちがASと呼ぶ実体はまさしく実装乗り物であるASで経路ドメインと呼ばれます。 排他的にそれが、より直接データベースオブジェクトとルーティングツールで関係するので、私たちは、ASという用語を使用すると決めました。 ある用語だけを使用することによって、私たちは、概念の数を減少させて、混乱を避けることを望んでいます。 アカデミックに傾向がある読者は私たちを許すかもしれません。
ASes exchange routing information with other ASes using Exterior Routing Protocols (EGPs). Exterior routing decisions are frequently based on policy based rules rather than purely on technical parameters. Tools are needed to configure complex policies and to communicate those policies between ASes while still ensuring proper operation of the Internet as a whole. Some EGPs like BGP-3 [8] and BGP-4 [9] provide tools to filter routing information according to policy rules and more. None of them provides a mechanism to publish or communicate the policies themselves. Yet this is critical for operational coordination and fault isolation among network operators and thus for the operation of the global Internet as a whole. This
ASesは、Exteriorルート設定プロトコル(EGPs)を使用することで他のASesとルーティング情報を交換します。 外のルーティング決定は頻繁に純粋な技術的パラメータに関してというよりむしろ方針に基づいている規則に基づいています。 ツールが、複雑な方針を構成して、まだ全体でインターネットの適切な操作を確実にしている間、ASesの間のそれらの方針を伝えるのに必要です。 BGP-3[8]とBGP-4[9]のようないくつかのEGPsが、政策ルールとその他に従ってルーティング情報をフィルターにかけるためにツールを提供します。 それらのいずれも、方針自体を発行するか、または伝えるためにメカニズムを提供しません。 しかし、ネットワーク・オペレータの中の業務調整と欠点分離とその結果、全体で世界的なインターネットの操作に、これは重要です。 これ
Bates, et al. [Page 5] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [5ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
document describes a "Routing Registry" providing this functionality.
ドキュメントは、この機能性を提供しながら、「ルート設定登録」について説明します。
Routing Policies
ルート設定方針
The exchange of routing information between ASes is subject to routing policies. Consider the case of two ASes, X and Y exchanging routing information:
ASesの間のルーティング情報の交換はルーティング方針を受けることがあります。 ルーティング情報を交換して、2ASes、X、およびYに関するケースを考えてください:
NET1 ...... ASX <---> ASY ....... NET2
NET1… ASX<。--->ASY… NET2
ASX knows how to reach a network called NET1. It does not matter whether NET1 is belonging to ASX or some other AS which exchanges routing information with ASX either directly or indirectly; we just assume that ASX knows how to direct packets towards NET1. Likewise ASY knows how to reach NET2.
ASXはNET1と呼ばれるネットワークに達する方法を知っています。 NET1が直接か間接的にルーティング情報をASXと交換するASXかある他のASに属しているかどうかは重要ではありません。 私たちは、ASXがNET1にパケットを向ける方法を知っているとただ思います。 同様にASYはNET2に達する方法を知っています。
In order for traffic from NET2 to NET1 to flow between ASX and ASY, ASX has to announce NET1 to ASY using an external routing protocol. This states that ASX is willing to accept traffic directed to NET1 from ASY. Policy thus comes into play first in the decision of ASX to announce NET1 to ASY.
NET2からNET1までのトラフィックがASXとASYの間を流れるように、ASXは外部のルーティング・プロトコルを使用することでNET1をASYに発表しなければなりません。 これは、ASXが、ASYからNET1に向けられたトラフィックを受け入れても構わないと思っていると述べます。 その結果、方針はASXがNET1をASYに発表するという決定における1番目を活動し始めます。
In addition ASY has to accept this routing information and use it. It is ASY's privilege to either use or disregard the information that ASX is willing to accept traffic for NET1. ASY might decide not to use this information if it does not want to send traffic to NET1 at all or if it considers another route more appropriate to reach NET1.
さらに、ASYはこのルーティング情報を受け入れて、それを使用しなければなりません。 ASXが、NET1のためにトラフィックを受け入れても構わないと思っているという情報を使用するか、または無視するのが、ASYの特権です。 ASYは、全くNET1にトラフィックを送りたがっていないか、または別のルートがNET1に達するのが、より適切であると考えるならこの情報を使用しないと決めるかもしれません。
So in order for traffic in the direction of NET1 to flow between ASX and ASY, ASX must announce it to ASY and ASY must accept it from ASX:
それで、ASXはNET1の向きにトラフィックがASXとASYの間を流れるようにそれをASYに発表しなければなりません、そして、ASYはASXからそれを受け入れなければなりません:
Bates, et al. [Page 6] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [6ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
resulting packet flow towards NET1
<<===================================
|
|
announce NET1 | accept NET1
--------------> + ------------->
|
AS X | AS Y
|
<------------- + <--------------
accept NET2 | announce NET2
|
|
resulting packet flow towards NET2
===================================>>
NET1<<に向かった結果として起こるパケット流動=================================== | | NET1を発表してください。| NET1を受け入れてください。-------------->+------------->| Xとして| Yとして| <、-、-、-、-、-、-、-、-、-、-、-、-- + <。-------------- NET2を受け入れてください。| NET2を発表してください。| | NET2に向かった結果として起こるパケット流動===================================>>。
Ideally, and seldom practically, the announcement and acceptance policies of ASX and ASY are identical.
理想的で、めったに、実際に、ASXとASYの発表と承認方針は同じではありません。
In order for traffic towards NET2 to flow, announcement and acceptance of NET2 must be in place the other way round. For almost all applications connectivity in just one direction is not useful at all.
NET2に向かったトラフィックが流れるように、NET2の発表と承認は適所にもう片方の方法でぐるりとあるに違いありません。 ほとんどすべてのアプリケーションには、まさしく一方向への接続性は全く役に立ちません。
Usually policies are not configured for each network separately but for groups of networks. In practise these groups are almost always defined by the networks forming one or more ASes.
ネットワークのグループがなければ、通常、方針は各ネットワークのために別々に構成されません。 これらのグループは中で練習します。1ASesを形成しながら、ほとんどいつもネットワークによって定義されます。
Routing Policy limitations
ルート設定Policy制限
It is important to realize that with current destination based forwarding technology routing policies must eventually be expressed in these terms. It is relatively easy to formulate reasonable policies in very general terms which CANNOT be expressed in terms of announcing and accepting networks. With current technology such policies are almost always impossible to implement.
結局これらの用語でルーティング方針を技術に送りながら基づく現在の目的地があるそれを言い表さなければならないとわかるのは重要です。ネットワークを発表して、受け入れることに関して表されない非常に一般的な用語で合理的な方針を定式化するのは比較的簡単です。 現在の技術で、そのような方針は実装するのがほとんどいつも不可能です。
The generic example of a reasonable but un-implementable routing is a split of already joined packet streams based on something other than destination address. Once traffic for the same destination network passes the same router, or the same AS at our level of abstraction, it will take exactly the same route to the destination (disregarding special cases like "type of service" routing, load sharing and
妥当な、しかし、不-実装可能なルーティングの一般例は送付先アドレス以外の何かに基づく既に接合されたパケットストリームの分裂です。 同じ送信先ネットワークのためのトラフィックが私たちのレベルの抽象化でいったん同じルータ、または同じASを渡すと、まさに同じルートはそれによって目的地に持って行かれるでしょう。そして(特別番組を無視するとルーティングが「サービスのタイプ」のようにケースに入れられる、負荷分割法。
Bates, et al. [Page 7] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [7ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
routing instabilities).
ルーティングの不安定性)
In a concrete example AS Z might be connected to the outside world by two links. AS Z wishes to reserve these links for different kinds of traffic, let's call them black and white traffic. For this purpose the management of AS Z keeps two lists of ASes, the black and the white list. Together these lists comprise all ASes in the world reachable from AS Z.
具体的な実例では、AS Zは2個のリンクによって外の世界に接続されるかもしれません。 AS Zは異種のトラフィックのためにこれらのリンクを予約して、それらが黒いと言って、トラフィックを空白にしたがっていましょう。 このためにAS Zの経営者側は黒いリスト、ASesの2つのリスト、および白いリストを保ちます。 これらのリストはAS Zから届いている世界のすべてのASesを一緒に、包括します。
"W"
<--->
... AS Z .... NET 3
<--->
"B"
「W」<。--->… Zとして… ネット3<。--->「B」
It is quite possible to implement the policy for traffic originating in AS Z: AS Z will only accept announcements for networks in white ASes on the white link and will only accept announcements for networks in black ASes on the black link. This causes traffic from networks within AS Z towards white ASes to use the white link and likewise traffic for black ASes to use the black link.
AS Zで起こるトラフィックのために政策を実施するのはかなり可能です: AS Zは白いASesのネットワークのために白いリンクの上に発表を受け入れるだけであり、黒いASesのネットワークのために黒いリンクの上に発表を受け入れるだけでしょう。 これで、白いASesに向かったAS Zの中のネットワークからのトラフィックは白いリンクと黒いASesが黒いリンクを使用する同様にトラフィックを使用します。
Note that this way of implementing things makes it necessary to decide on the colour of each new AS which appears before traffic can be sent to it from AS Z. A way around this would be to accept only white announcements via the white link and to accept all but white announcements on the black link. That way traffic from new ASes would automatically be sent down the black link and AS Z management would only need to keep the list of white ASes rather than two lists.
ものを実装するこの方法でそれぞれの新しいASの色でこれのずっと周りでトラフィックをAS Z.Aからそれに送ることができる前にどれが現れるかが、白いリンクを通して白い発表だけを受け入れて、黒いリンクの上にほとんど白い発表を受け入れることになっていると決めるのが必要になることに注意してください。 そのように、自動的に新しいASesからのトラフィックを黒いリンクの下側に送るでしょう、そして、AS Z経営者側は2つのリストよりむしろ白いASesのリストを保つ必要があるだけでしょう。
Now for the unimplementable part of the policy. This concerns traffic towards AS Z. Consider the following topology:
現在、方針の非実装可能部分に。 この関心はAS Z.Considerに向かって以下のトポロジーを取引します:
B AS ---) "W"
W AS ---) --->
B AS ---)>> AS A ---> ... AS Z .... NET 3
B AS ---) --->
W AS ---) "B"
B---) 「W」W---) --->B---)Aとしての>>。--->… Zとして… ネット3B---) --->W---) 「B」
As seen from AS Z there are both black and white ASes "behind" AS A. Since ASes can make routing decisions based on destination only, AS A and all ASes between AS A and the two links connecting AS Z can only make the same decision for traffic directed at a network in AS Z, say NET 3. This means that traffic from both black and white ASes towards NET 3 will follow the same route once it passes through AS A. This will either be the black or the white route depending on the routing policies of AS A and all ASes between it and AS Z.
そこでAS Zから見られているのが、A.Since ASesがAS Aの間で目的地だけに基づくルーティング決定、AS A、およびすべてのASesをすることができるASes “behind" ASであり、黒くて白の両方のAS Zを接続する2個のリンクがAS Zでネットワークに向けられたトラフィックのための同じ決定をすることができるだけであるので、NET3を言ってください。 いったんAS A.Thisを通り抜けると、黒とNET3に向かったASesが同じように続く白の両方からのトラフィックが発送するこの手段は、黒いルートであるか白いルートのどちらかにそれとAS Zの間のAS AとすべてのASesのルーティング方針によるなるでしょう。
Bates, et al. [Page 8] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [8ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
The important thing to note is that unless routing and forwarding decisions can be made based on both source and destination addresses, policies like the "black and white" example cannot be implemented in general because "once joined means joined forever".
注意する重要なことはソースと送付先アドレスの両方に基づいてルーティングと決定を進めるのを作ることができないなら、一般に、「一度接合された手段はいつまでも、接合した」ので「白黒」の例のような政策を実施されることができないということです。
Access Policies
アクセス方針
Access policies contrary to routing policies are not necessarily defined in terms of ASes. The very simplest type of access policy is to block packets from a specific network S from being forwarded to another network D. A common example is when some inappropriate use of resources on network D has been made from network S and the problem has not been resolved yet. Other examples of access policies might be resources only accessible to networks belonging to a particular disciplinary group or community of interest. While most of these policies are better implemented at the host or application level, network level access policies do exist and are a source of connectivity problems which are sometimes hard to diagnose. Therefore they should also be documented in the routing registry according to similar requirements as outlined above.
ルーティング方針とは逆のアクセス方針は必ずASesに関して定義されるというわけではありません。 非常に最も純真なタイプのアクセス方針は特定のネットワークSからのパケットが別のネットワークD.に送られるのを妨げることです。A一般的な例はネットワークSからネットワークDにおけるリソースの何らかの誤用をして、まだ問題を解決していない時です。 アクセス方針に関する他の例は特定の訓練上のグループか利益共同体のものネットワークへのアクセス可能なだけのリソースであるかもしれません。 これらの方針の大部分は実装されるほうがよいのですが、ホストかアプリケーションレベル、ネットワークレベルでは、アクセス方針は、存在していて、時々診断しにくい接続性問題の源です。 したがって、また、同様の要件に従って、それらは上に概説されているようにルーティング登録に記録されるべきです。
Routing vs. Allocation information
ルート設定対Allocation情報
The RIPE database contains both routing registry and address space allocation registry information. In the past the database schema combined this information. Because RIPE was tasked with running both an allocation and routing registry it seemed natural to initially combine these functions. However, experience has shown that a clear separation of routing information from allocation is desirable. Often the maintainer of the routing information is not the same as the maintainer of the allocation information. Moreover, in other parts of the world there are different registries for each kind of information.
RIPEデータベースはルーティング登録とアドレス空間配分登録情報の両方を含んでいます。 過去に、データベース・スキーマはこの情報を結合しました。 RIPEが稼働で仕事を課されたので、配分とそれが思えたルーティング登録の初めは当然の両方がこれらの機能を結合します。 しかしながら、経験は、配分からのルーティング情報の明確な分離が望ましいのを示しました。 しばしば、ルーティング情報の維持装置は配分情報の維持装置と同じであるというわけではありません。 そのうえ、世界のほかの地域に、各種類の情報のための異なった登録があります。
Whilst the actual routing policy objects will be introduced in the next section it is worthy of note that a transition from the current objects will be required. Appendix G details the basic steps of such a transition.
次のセクションで実際のルーティング政策目的を導入するでしょうが、それは現在のオブジェクトからの変遷が必要であるというメモにふさわしいです。 付録Gはそのような変遷の基本的なステップを詳しく述べます。
This split in information represents a significant change in the representational model of the RIPE database. Appendix F expands on the reasons for this a little more.
情報におけるこの分裂はRIPEデータベースの具象主義のモデルにおける著しい変化を表します。 付録Fはこのもう少しの理由について詳述します。
Bates, et al. [Page 9] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [9ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Tools
ツール
The network operators will need a series of tools for policy routing. Some tools are already available to perform some of the tasks. Most notably, the PRIDE tools [3] from the PRIDE project started in September 1993 as well as others produced by Merit Inc [4] and CERN [5].
ネットワーク・オペレータは方針ルーティングに一連のツールを必要とするでしょう。 いくつかのツールが、タスクのいくつかを実行するために既に利用可能です。 最も著しく、PRIDEプロジェクトからのPRIDEツール[3]はMerit Inc[4]とCERN[5]によって生産された他のものと同様に1993年9月に始まりました。
These tools will enable them to use the routing policy stored in the RIPE routing registry to perform such tasks as check actual routing against policies defined, ensure consistency of policies set by different operators, and simulate the effects of policy changes.
これらのツールは、定義された方針に対して実際のルーティングをチェックして、方針の一貫性が異なったオペレータでセットしたのを確実にして、政策変更の効果をシミュレートするようなタスクを実行するためにRIPEルーティング登録に保存されたルーティング方針を使用するのを可能にするでしょう。
Work continues on producing more useful tools to service the Internet community.
より役に立つツールを生産するとき、仕事は、インターネットコミュニティを修理し続けています。
Bates, et al. [Page 10] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [10ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
4. The Routing Registry and the RIPE Database
4. ルート設定登録と熟しているデータベース
One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons along with various other kinds of network management information. The database content is public and can be queried using the whois protocol as well as retrieved as a whole. This supports NICs/NOCs all over Europe and beyond to perform their respective tasks.
RIPEの活動の1つは他の様々な種類のネットワークマネージメント情報と共に、ヨーロッパのIPに関するデータベースがネットワークと、DNSドメインと彼らの連絡窓口であることを支持することです。 データベース内容について、公共であり、whoisプロトコルを使用することで質問して、全体で検索できます。 これは、彼らのそれぞれのタスクを実行するためにヨーロッパ全体にわたる向こうのNICs/NOCsをサポートします。
The RIPE database combines both allocation registry and routing registry functions. The RIPE allocation registry contains data about address space allocated to specific enterprises and/or delegated to local registries as well as data about the domain name space. The allocation registry is described in separate documents [6,7] and outside the scope of this document.
RIPEデータベースは配分登録とルーティング登録機能の両方を結合します。 RIPE配分登録は、特定の企業に割り当てられたアドレス空間に関してデータを含んでいる、そして/または、ドメイン名スペースに関するデータと同様に地方の登録に委任しました。 配分登録は別々のドキュメント[6、7]とこのドキュメントの範囲の外で説明されます。
Database Objects
データベースオブジェクト
Each object in the database describes a single entity in the real world. This basic principle means that information about that entity should only be represented in the corresponding database object and not be repeated in other objects. The whois service can automatically display referenced objects where appropriate.
データベースの各オブジェクトは本当の世界で単一体について説明します。 この基本原理は、その実体の情報が対応するデータベースオブジェクトに表されるだけであるべきであり、他のオブジェクトで繰り返されないことを意味します。 whoisサービスは自動的に適切であるところに参照をつけられたオブジェクトを表示できます。
The types of objects stored in the RIPE database are summarized in the table below:
RIPEデータベースに保存されたオブジェクトのタイプは以下のテーブルにまとめられます:
R Object Describes References ____________________________________________________________________
Rオブジェクトは参照について説明します。____________________________________________________________________
B person contact persons
B人の連絡窓口
A inetnum IP address space person A domain DNS domain person
inetnum IPアドレス空間人のAドメインDNSドメイン人
R aut-num autonomous system person
(aut-num,community)
R as-macro a group of autonomous systems person, aut-num
R community community person
R route a route being announced aut-num, community
マクロとしての自律システム人のR aut-num自律システム人(aut-num、共同体)のR aグループ、発表されたaut-num、共同体であるaut-num R共同体共同体人のRルートaルート
R clns CLNS address space and routing person
R clns CLNSアドレス空間とルーティング人
The first column indicates whether the object is part of the allocation registry (A), the routing registry (R) or both (B). The
最初のコラムは、オブジェクトが配分登録(A)、ルーティング登録(R)の一部ですかそれとも両方が(B)であるかを示します。 The
Bates, et al. [Page 11] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [11ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
last column indicates the types of objects referenced by the particular type of object. It can be seen that almost all objects reference contact persons.
最後のコラムは特定のタイプのオブジェクトによって参照をつけられるオブジェクトのタイプを示します。 ほとんどすべてのオブジェクト参照が人々に連絡するのを見ることができます。
Objects are described by attributes value pairs, one per line. Objects are separated by empty lines. An attribute that consists of multiple lines should have the attribute name repeated on consecutive lines. The information stored about network 192.87.45.0 consists of three objects, one inetnum object and two person objects and looks like this:
オブジェクトは属性によって1系列あたりの1つ歳の値の組に説明されます。 オブジェクトは空の系列によって分離されます。 複数の系列から成る属性で、連続した系列で属性名を繰り返すべきです。 情報がネットワークに関して保存した、192.87、.45、.0、3個のオブジェクト、1個のinetnumオブジェクト、および2個の人のオブジェクトから成って、このように以下を見ます。
Bates, et al. [Page 12] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [12ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: tony@ripe.net 940110 source: RIPE
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: アムステルダム(オランダ)国: NLアドミンc: ダニエルのKarrenbergの科学技術のc: テンのテルプストラ回転-srv: ns.ripe.net回転-srv: ns.eu.netに通知します: ops@ripe.net は変化しました: tony@ripe.net 940110ソース: 熟す
person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk@ripe.net nic-hdl: DK58 changed: ripe-dbm@ripe.net 920826 source: RIPE
人: ダニエルKarrenbergアドレス: RIPE Network Coordination Centre(NCC)アドレス: Kruislaan409アドレス: NL-1098 SJアムステルダムアドレス: オランダ電話: +31 20 592 5065年のファックスノー: +31 20 592 5090はメールされます: dfk@ripe.net nic-hdl: DK58は変化しました: ripe-dbm@ripe.net 920826ソース: 熟す
person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra@ripe.net nic-hdl: MT2 notify: marten@ripe.net changed: marten@ripe.net 931230 source: RIPE
人: テンのテルプストラアドレス: RIPE Network Coordination Centre(NCC)アドレス: PRIDE Projectアドレス: Kruislaan409アドレス: NL-1098 SJアムステルダムアドレス: オランダ電話: +31 20 592 5064年のファックスノー: +31 20 592 5090はメールされます: Marten.Terpstra@ripe.net nic-hdl: MT2は通知します: marten@ripe.net は変化しました: marten@ripe.net 931230ソース: 熟す
Objects are stored and retrieved in this tag/value format. The RIPE NCC does not provide differently formatted reports because any desired format can easily be produced from this generic one.
オブジェクトは、このタグ/値の形式で保存されて、検索されます。 どんな必要な形式もこのジェネリック1から容易に発生できるので、RIPE NCCは異なってフォーマットされたレポートを提供しません。
Bates, et al. [Page 13] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [13ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Routing Registry Objects
ルート設定登録オブジェクト
The main objects comprising the routing registry are "aut-num" and "route", describing an autonomous system and a route respectively. It should be noted that routes not described in the routing registry should never be routed in the Internet itself.
それぞれ自律システムとルートを説明して、ルーティング登録を含む主なオブジェクトは、"aut-num"と「ルート」です。 ルーティング登録で説明されなかったルートがインターネット自体で決して発送されるべきでないことに注意されるべきです。
The autonomous system (aut-num) object provides contact information for the AS and describes the routing policy of that AS. The routing policy is described by enumerating all neighboring ASes with which routing information is exchanged. For each neighbor the routing policy is described in terms of exactly what is being sent (announced) and allowed in (accepted). It is important to note that this is exactly the part of the global policy over which an AS has direct control. Thus each aut-num object describes what can indeed be implemented and enforced locally by the AS concerned. Combined together all the aut-num objects provide the global routing graph and permit to deduce the exact routing policy between any two ASes.
自律システム(aut-num)オブジェクトは、ASのための問い合わせ先を提供して、そのASのルーティング方針を説明します。 ルーティング方針は、ルーティング情報が交換されるすべての隣接しているASesを数え上げることによって、説明されます。 各隣人に関しては、ルーティング方針は、まさに送られる(発表されます)もので説明されて、(受け入れられる)に許容されています。 これがちょうどASが直轄を持っているグローバルな方針の部分であることに注意するのは重要です。 したがって、それぞれのaut-numオブジェクトは、本当に、関するASが局所的に何を実装して、励行できるかを説明します。 一緒に結合されて、すべてのaut-numオブジェクトが、グローバルなルーティンググラフを提供して、どんな2ASesの間の正確なルーティング方針を推論するのを可能にします。
While the aut-num objects describe how routing information is propagated, the route object describes a single route injected into the external routing mesh. The route object references the AS injecting (originating) the route and thereby indirectly provides contact information for the originating AS. This reference also provides the primary way of grouping routes into larger collections. This is necessary because describing routing policy on the level of single routes would be awkward to impractical given the number of routes in the Internet which is about 20,000 at the time of this writing. Thus routing policy is most often defined for groups of routes by originating AS. This method of grouping is well supported by current exterior routing protocols. The route object also references community objects described below to provide another method of grouping routes. Modification of aut-num object itself and the referencing by route objects is strictly protected to provide network operators control over the routing policy description and the routes originated by their ASes.
aut-numオブジェクトはルーティング情報がどう伝播されるかを説明しますが、ルートオブジェクトは外部のルーティングメッシュに注がれたただ一つのルートを説明します。 ルートオブジェクトは、ルートを注入しながら(溯源します)ASに参照をつけて、その結果、間接的に起因しているASに問い合わせ先を供給します。 また、この参照はルートをより大きい収集に分類するプライマリ方法を提供します。 この書くこと時点でおよそ2万であるインターネットのルートの数を考えて、ただ一つのルートのレベルに関する方針を発送すると説明するのは非実用的に無器用でしょう、したがって、これが必要です。 したがって、ルーティング方針は、ルートのグループのためにASを溯源することによって、たいてい定義されます。 組分けのこのメソッドは現在の外のルーティング・プロトコルによってよくサポートされます。 ルートは反対します、また、参照共同体が、ルートを分類する別のメソッドを提供するために以下で説明されていた状態で反対します。 aut-numオブジェクト自体と参照箇所の変更は、ルーティング方針記述のネットワーク・オペレータコントロールとそれらのASesによって溯源されたルートを提供するためにルートオブジェクトによって厳密に保護されます。
Sometimes even keeping track of groups of routes at the AS level is cumbersome. Consider the case of policies described at the transit provider level which apply transitively to all customers of the transit provider. Therefore another level of grouping is provided by the as-macro object which provides groups of ASes which can be referenced in routing policies just like single ASes. Membership of as-macro groups is also strictly controlled.
ASレベルでルートのグループの時々動向をおさえさえする厄介です。 方針に関するケースが、トランジットプロバイダーレベルでどれがトランジットプロバイダーのすべての顧客に移行的に適用されるかを説明したと考えてください。 したがって、マクロとしてのまさしく独身のASesのようなルーティング方針で参照をつけることができるASesのグループを提供するオブジェクトは別のレベルの組分けを提供します。 また、マクロとしてのグループの会員資格は厳密に制御されます。
Sometimes there is a need to group routes on different criteria than ASes for purposes like statistics or local access policies. This is provided by the community object. A community object is much like an
ルートを分類する必要が統計のような目的のためのASesかローカルのアクセス方針と異なった評価基準に時々あります。 共同体オブジェクトはこれを提供します。 共同体オブジェクトがあります。
Bates, et al. [Page 14] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [14ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
AS but without a routing policy. It just describes a group of routes. This is not supported at all by exterior routing protocols and depending on aggregation of routes may not be generally usable to define routing policies. It is suitable for local policies and non- routing related purposes.
ASにもかかわらず、ルーティング方針なしで。 それはただルートのグループについて説明します。 これは外のルーティング・プロトコルによって全くサポートされません、そして、一般に、ルートの集合に依存するのはルーティング方針を定義するのにおいて使用可能でないかもしれません。 それはローカルの方針に適しています、そして、非ルーティングは目的を関係づけました。
These routing related objects will be described in detail in the sections below.
関連するオブジェクトを発送するこれらが下のセクションで詳細に説明されるでしょう。
Bates, et al. [Page 15] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [15ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
5. The Route Object
5. ルートオブジェクト
As stated in the previous chapter routing and address space allocation information are now clearly separated. This is performed with the introduction of the route object. The route object will contain all the information regarding a routing announcement.
前の章に述べられているように、ルーティングとアドレス空間配分情報は現在、明確に切り離されます。 これはルートオブジェクトの挿入で実行されます。 ルートオブジェクトはルーティング発表のすべての情報を含むでしょう。
All routing related attributes are removed from the inetnum object. Some old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf- in, nsf-out, gateway). The currently useful routing attributes are moved to the route object: aut-sys becomes origin, ias-int will be encoded as part of the inet-rtr [15] object and comm-list simply moves. See [6] for detail of the "inetnum" object definition.
inetnumオブジェクトからすべてのルーティングの関連する属性を取り除きます。 いくつかの古い属性が時代遅れにされます: 接続してください、routpr-l、bdryg-lがコネ、外のnsf、ゲートウェイをnsfする、) 現在役に立つルーティング属性はルートオブジェクトに動かされます: aut-sysは発生源になって、inet-rtr[15]オブジェクトとcomm-リストの一部が単に移行するとき、ias-intはコード化されるでしょう。 "inetnum"オブジェクト定義の詳細のための[6]を見てください。
The information in the old inetnum object
古いinetnumオブジェクトの情報
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS3333 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: tony@ripe.net 940110 source: RIPE
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: アムステルダム(オランダ)国: NLアドミンc: ダニエルのKarrenbergの科学技術のc: Martenテルプストラは接続します: RIPE NSF WCW aut-sys: AS3333 comm-リスト: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600回転-srv: ns.ripe.net回転-srv: ns.eu.netに通知します: ops@ripe.net は変化しました: tony@ripe.net 940110ソース: 熟す
will be distributed over two objects:
2個の物の上に分配されるでしょう:
Bates, et al. [Page 16] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [16ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: tony@ripe.net 940110 source: RIPE
inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: アムステルダム(オランダ)国: NLアドミンc: ダニエルのKarrenbergの科学技術のc: テンのテルプストラ回転-srv: ns.ripe.net回転-srv: ns.eu.netに通知します: ops@ripe.net は変化しました: tony@ripe.net 940110ソース: 熟す
route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET changed: dfk@ripe.net 940427 source: RIPE
以下を発送してください。 192.87.45.0/24descr: RIPE Network Coordination Centreの起源: AS3333 comm-リスト: SURFNETは変化しました: dfk@ripe.net 940427ソース: 熟す
The route object is used to represent a single route originated into the Internet routing mesh. The actual syntax is given in Appendix D. However, there are several important aspects of the attributes worthy of note.
ルート物は、インターネット・ルーティングメッシュに溯源されたただ一つのルートを表すのに使用されます。 Appendix D.Howeverで実際の構文を与えて、注意にふさわしい属性のいくつかの重要な一面があります。
The value of the route attribute will be a classless address. It represents the exact route being injected into the routing mesh. The representation of classless addresses is described in [10].
ルート属性の値は階級のないアドレスになるでしょう。 それはルーティングメッシュに注がれる正確なルートを表します。 階級のないアドレスの表現は[10]で説明されます。
The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. The "aut-num" object (see below) thus referenced provides all the contact information for this route.
起源属性の値はaut-num物を示すフォームAS1234のAS参照になるでしょう。 それはルーティングメッシュにこのルートを注ぐASを表します。 このようにして参照をつけられる"aut-num"物(以下を見る)はこのルートのためのすべての問い合わせ先を提供します。
Special cases: There can only be a single originating AS in each route object. However in todays Internet sometimes a route is injected by more than one AS. This situation is potentially dangerous as it can create conflicting routing policies for that route and requires coordination between the originating ASes. In the routing registry this is represented by multiple route objects.
特別なケース: 独身の由来しているASがそれぞれのルート物にあることができるだけです。 しかしながら、今日のインターネットでは、時々、ルートは1ASによって注入されます。 そのルートに方針を発送しながら闘争を作成できて、由来しているASesの間のコーディネートを必要とするとき、この状況は潜在的に危険です。 ルーティング登録では、これは複数のルート物によって表されます。
Bates, et al. [Page 17] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [17ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
This is a departure from the one route (net), one AS principle of the ripe-81 routing registry. The consequences for the different tools based in the routing registry will need to be evaluated and possibly additional consistency checking of the database is needed.
これは1つのルート(ネットの)からの出発、熟している81ルーティング登録の1つのAS原則です。 ルーティング登録に拠点を置く異なったツールのための結果は、評価される必要があるでしょう、そして、データベースのことによると追加している一貫性の照合が必要です。
The examples below will illustrate the usage of the route object further. Suppose three chunks of address space of 2 different enterprises represented by the following inetnum objects:
以下の例はさらにルート物の使用法を例証するでしょう。 以下のinetnum物によって代表された2つの異なった企業のアドレス空間の3つの塊を仮定してください:
Examples
例
inetnum: 193.0.1.0
netname: ENT-1
descr: Enterprise 1
...
inetnum: 193.0.1.0 netname: ENT-1 descr: エンタープライズ1…
inetnum: 193.0.8.0
netname: ENT-2
descr: Enterprise 2
...
inetnum: 193.0.8.0 netname: ENT-2 descr: エンタープライズ2…
inetnum: 193.0.9.0
netname: ENT-2-SPEC
descr: Enterprise 2
...
inetnum: 193.0.9.0 netname: ENT-2-SPEC descr: エンタープライズ2…
Supposing that the Enterprises have their own AS numbers straight application of routing without aggregation would yield:
エンタープライズでそれら自身のAS番号がまっすぐになると思って、集合のないルーティングの適用はもたらされるでしょう:
route: 193.0.1.0/24
descr: Enterprise 1
origin: AS1
...
以下を発送してください。 193.0.1.0/24descr: エンタープライズ1の起源: AS1…
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
...
以下を発送してください。 193.0.8.0/24descr: エンタープライズ2の起源: AS2…
route: 193.0.9.0/24
descr: Enterprise 2
origin: AS2
...
以下を発送してください。 193.0.9.0/24descr: エンタープライズ2の起源: AS2…
Bates, et al. [Page 18] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [18ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
NB: This representation can be achieved by straight translation from the ripe-81 representation. See Appendix G for more details.
ネブラスカ: 熟している81表現からまっすぐな翻訳でこの表現を達成できます。 その他の詳細に関してAppendix Gを見てください。
Homogeneous Aggregation
均質の集合
The two chunks of address space of Enterprise 2 can be represented by one aggregate route turning two route objects into one and potentially saving routing table space for one route.
2個のルート物を1つに変えて、潜在的に経路指定テーブルにスペースを節約すると個人的には発送される1つの集合ルートでエンタープライズ2のアドレス空間の2つの塊を表すことができます。
route: 193.0.8.0/23
descr: Enterprise 2
origin: AS2
...
以下を発送してください。 193.0.8.0/23descr: エンタープライズ2の起源: AS2…
Note that AS2 can also decide to originate all routes mentioned so far, two 24-bit prefixes and one 23-bit prefix. This case would be represented by storing all three route objects in the database. In this particular example the additional routes will not add any functionality however and only increase the amount of routes announced unnecessarily.
また、AS2が、今までのところ言及されているすべてのルート、2つの24ビットの接頭語、および1つの23ビットの接頭語を溯源すると決めることができることに注意してください。 本件は、データベースにすべての3個のルート物を格納することによって、表されるでしょう。 この特定の例では、追加ルートは、しかしながら、どんな機能性も加えて、不必要に発表されたルートの量を増加させるだけではないでしょう。
Heterogeneous Aggregation
異種の集合
Consider the following case however:
しかしながら、以下のケースを考えてください:
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
...
以下を発送してください。 193.0.8.0/24descr: エンタープライズ2の起源: AS2…
route: 193.0.9.0/24
descr: Enterprise 2 / Special
origin: AS2
comm-list: SPECIAL
...
以下を発送してください。 193.0.9.0/24descr: エンタープライズ2/特別番組の起源: AS2 comm-リスト: 特別番組…
Now the prefix 193.0.9.0/24 belongs to community SPECIAL (this community may well not be relevant to routing) and the other prefix originated by AS2 does not. If AS2 aggregates these prefixes into the 193.0.8.0/23 prefix, routing policies based on the community value SPECIAL cannot be implemented in general, because there is no way to distinguish between the special and the not-so-special parts of AS2.
193.0を前に置いてください。現在、.9 .0/24は共同体SPECIALに属して(この共同体はたぶんルーティングに関連していないでしょう)、AS2によって溯源されたもう片方の接頭語は属しません。 AS2が193.0.8.0/23接頭語へのこれらの接頭語に集めるなら、一般に、共同体価値のSPECIALに基づくルーティング政策は実施されることができません、AS2の特別な部分としたがって、特別でない部分を見分ける方法が全くないので。
Bates, et al. [Page 19] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [19ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
If another AS has the policy to accept only routes to members of community SPECIAL it cannot implement it, because accepting the route to 193.0.8.0/23 would also route to 193.0.8.0/24 and not accepting this route would lose connectivity to the special part 193.0.9.0/24. We call aggregate routes consisting of components belonging to different communities or even different ASes "heterogeneous aggregates".
別のASに共同体SPECIALのメンバーにルートだけを受け入れる方針があるなら、それを実行できないで、ルートを193.0に受け入れて、また23がそうする.8.0/が.8を193.0に発送するので、このルートがそうする受諾ではなく、.0/24が.0/24に特別なパート193.0.9に接続性を失います。 私たちは、集合ルートを異なった共同体のものコンポーネントか異なったASes「異種の集合」からさえ成ると呼びます。
The major problem introduced with heterogeneous aggregates is that once the homogeneous more specific routes are withdrawn one cannot tell if a more specific part of the heterogeneous route has a different policy. However, it can be counter argued that knowing this policy is of little use since a routing policy based on the less specific heterogeneous aggregate only cannot be implemented. In fact, this displays a facet of CIDR itself in that one may actually trade off implementing slight policy variations over announcing a larger (albeit heterogeneous in terms of policy) aggregate to save routing table space.
異種の集合で紹介された大した問題は均質の、より特定のルートがいったんよそよそしくなると人が、異種のルートの、より特定の部分で異なった方針があるかどうかわからないということです。 しかしながら、それほど特定でない異種の集合だけに基づくルーティング政策は実施されることができないのでこの方針がほとんど役に立たないのを知るのは、論争されたカウンタであるかもしれません。 事実上、経路指定テーブルスペースを節約するために、より大きい(方針で異種ですが)集合を発表する上で実際にわずかな方針変化を実行するところで取り引きされるかもしれないので、これはCIDR自身の一面を表示します。
However, it is still useful to be able to document these variations in policy especially when this homogeneous more specific route is just being withdrawn. For this one can use the "withdrawn" attribute. The withdrawn attribute can serve to both indicate that a less specific aggregate is in fact heterogeneous and also allow the general documenting of route withdrawal.
しかしながら、特にこの均質の、より特定のルートがただ引っ込められているとき方針のこれらの変化を記録できるのはまだ役に立っています。 これが「よそよそしい」属性を使用できるので。 よそよそしい属性は事実上、それほど特定でない集合が異種であることを示して、また、ルート退出の一般的なドキュメントを許容するのに役立つことができます。
So there has to be a way for AS2 to document this even if it does not originate the route to 193.0.9.0/24 any more. This can be done with the "withdrawn" attribute of the route object. The aggregate route to 193.0.8.0/23 is now be registered as:
したがって、193.0にルートを溯源しないでもAS2がこれを記録する方法がなければなりません。.9 それ以上.0/24。 ルート物の「よそよそしい」属性でこれができます。 集合は.8を193.0に発送します。登録されていて、.0/23は以下として現在です。
route: 193.0.8.0/23
descr: Enterprise 2
origin: AS2
...
以下を発送してください。 193.0.8.0/23descr: エンタープライズ2の起源: AS2…
With the two homogeneous routes marked as withdrawn from the Internet routing mesh but still preserving their original routing information.
2つの均質のルートがインターネット・ルーティングメッシュから引き下がりますが、まだそれらのオリジナルのルーティング情報を保存しているとしてマークされている状態で。
Bates, et al. [Page 20] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [20ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
withdrawn: 940701
...
以下を発送してください。 193.0.8.0/24descr: エンタープライズ2の起源: AS2よそよそしい: 940701 ...
route: 193.0.9.0/24
descr: Enterprise 2 / Special
origin: AS2
comm-list: SPECIAL
withdrawn: 940701
...
以下を発送してください。 193.0.9.0/24descr: エンタープライズ2/特別番組の起源: AS2 comm-リスト: SPECIALよそよそしい: 940701 ...
It should be noted that the date value used in the withdrawn attribute can only be in the past.
よそよそしい属性に使用される日付の値が過去にあることができるだけであることに注意されるべきです。
Proxy Aggregation
プロキシ集合
The next step of aggregation are aggregates consisting of more than one AS. This generally means one AS is aggregating on behalf of another. It is called proxy aggregation. Proxy aggregation should be done with great care and always be coordinated with other providers announcing the same route.
集合の次のステップは1ASから成る集合です。 一般に、これは、1ASが別のものを代表して集めていることを意味します。 それはプロキシ集合と呼ばれます。 プロキシ集合を細心の注意を払ってして、他のプロバイダーが同じルートを発表している状態で、いつも調整するべきです。
Consider the following:
以下を考えてください:
route: 193.0.0.0/20
descr: All routes known by AS1 in a single package
origin: AS1
...
以下を発送してください。 193.0.0.0/20descr: ただ一つのパッケージの起源でAS1によって知られていたすべてのルート: AS1…
route: 193.0.1.0/24
descr: Foo
origin: AS1
withdrawn: 940310
...
以下を発送してください。 193.0.1.0/24descr: Fooの起源: AS1よそよそしい: 940310 ...
Bates, et al. [Page 21] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [21ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
route: 193.0.8.0/24
descr: Bar
origin: AS2
withdrawn: 940310
...
以下を発送してください。 193.0.8.0/24descr: 起源を禁じてください: AS2よそよそしい: 940310 ...
route: 193.0.9.0/24
descr: Bar-2
origin: AS2
withdrawn: 940310
comm-list: SPECIAL
...
以下を発送してください。 193.0.9.0/24descr: バー-2の起源: AS2よそよそしい: 940310comm-リスト: 特別番組…
If AS1 announced no other routes to a single homed neighboring AS, that neighbor can in general either take that route or leave it but not differentiate between AS1 and AS2.
AS1が、シングルへの他のルートが全くASを近所付き合いさせながら家へ帰らなかったと発表したなら、一般に、その隣人は、そのルートを取ることができませんし、それを残しますが、AS1とAS2を区別できません。
Note: If the neighbor was previously configured to accept routes originating in AS2 but not in AS1 they lose connectivity to AS2 as well. This means that proxy aggregation has to be done carefully and in a well coordinated fashion. The information in the withdrawn route object can help to achieve that.
以下に注意してください。 隣人が以前に、AS2で起こるルートを受け入れるために構成されましたが、AS1で構成されたというわけではないなら、それらはまた、AS2に接続性を失います。 これは、慎重とよく調整されたファッションでプロキシ集合をしなければならないことを意味します。 よそよそしいルート物の情報は、それを達成するのを助けることができます。
Aggregates with Holes
穴がある集合
If we assume that the world of our example still consists of only three chunks of address space the aggregate above contains what are called holes, parts of an aggregate that are not reachable via the originator of the route. From the routing information itself one cannot tell whether these are holes and what part of the route falls inside one. The only way to tell is to send a packet there and see whether it gets to the destination, or an ICMP message is received back, or there is silence. On the other hand announcing aggregates with holes is quite legitimate. Consider a 16-bit aggregate with only one 24-bit prefix unreachable. The savings in routing table size by far outweigh the hole problem.
私たちが、私たちの例の世界がアドレス空間の3つの塊だけからまだ成っていると思うなら、上の集合は穴と呼ばれるものを含んでいます、集合のルートの創始者を通して届いていない部分。 ルーティング情報自体から、人はこれらが穴であるかどうかと、ルートのどんな部分が1に落ちるかわかりません。 言う唯一の方法がパケットをそこに送って、それが目的地に着くかどうかを見ることである、ICMPメッセージを受け取り返すか、または沈黙があります。 他方では、穴で集合を発表するのはかなり正統です。 1つの24ビットの接頭語だけが手が届かない状態で16ビットの集合を考えてください。 経路指定テーブルサイズにおける貯蓄は穴の問題より断然重いです。
For operational reasons however it is very useful to register these holes in the routing registry. Consider the case where a remote network operator experiences connectivity problems to addresses
しかしながら、操作上の理由に、ルーティング登録のこれらの穴を登録するのは非常に役に立ちます。 リモートネットワーク・オペレータが接続性問題をアドレスに経験するケースを考えてください。
Bates, et al. [Page 22] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [22ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
inside an aggregate route. If the packets are getting to the AS announcing the aggregate and there are no more specific routes, the normal cause of action is to get in touch with the originating AS of the aggregate route and ask them to fix the problem. If the address falls into a hole this is futile. Therefore problem diagnosis can be sped up and unnecessary calls prevented by registering the holes in the routing registry. We do this by using the "hole" attribute. In our example the representation would be:
集合ルートの中で。 パケットが集合を発表するASを始めていて、それ以上の特定のルートがなければ、正常な訴因は、集合ルートの由来しているASに連絡を取って、問題を修正するように彼らに頼むことです。 アドレスが穴に落ちるなら、これは空しいです。 したがって、診断があることができることにおける問題は加速しました、そして、不要な呼び出しはルーティング登録の登録するのによる穴を防ぎました。 私たちは、「穴」属性を使用することによって、これをします。 私たちの例では、表現は以下の通りでしょう。
route: 193.0.0.0/20
descr: All routes known by AS1
origin: AS1
hole: 193.0.0.0/24
hole: 193.0.2.0/23
hole: 193.0.4.0/22
hole: 193.0.10.0/23
hole: 193.0.12.0/22
...
以下を発送してください。 193.0.0.0/20descr: AS1の起源によって知られていたすべてのルート: AS1は掘ります: 193.0.0.0/24穴: 193.0.2.0/23穴: 193.0.4.0/22穴: 193.0.10.0/23穴: 193.0.12.0/22 ...
Note: there would also be two routes with the withdrawn attribute as displayed above (i.e. 193.0.8.0/24 and 193.0.9.0/24). It is not mandatory to document all holes. It is recommended all holes routed by another service provider are documented.
以下に注意してください。 また、よそよそしい属性がある2つのルートが上に表示するようにあるだろう、(すなわち、193.0.8 24と.0/193.0.9.0/、24)。 すべての穴を記録するのは義務的ではありません。 別のサービスプロバイダーによって発送されたすべての穴が記録されるのが推薦されます。
Multiple Proxy Aggregation
複数のプロキシ集合
Finally suppose that AS2 decides to announce the same aggregate, as in the previous example, they would add the following route object to the registry:
AS2が、同じ集合を発表すると決めると最終的に仮定してください、彼らが前の例で以下のルート物を登録に加えるだろうというとき:
route: 193.0.0.0/20
descr: All routes known by AS2
origin: AS2
hole: 193.0.0.0/24
hole: 193.0.2.0/23
hole: 193.0.4.0/22
hole: 193.0.10.0/23
hole: 193.0.12.0/22
...
以下を発送してください。 193.0.0.0/20descr: AS2の起源によって知られていたすべてのルート: AS2は掘ります: 193.0.0.0/24穴: 193.0.2.0/23穴: 193.0.4.0/22穴: 193.0.10.0/23穴: 193.0.12.0/22 ...
Both AS1 and AS2 will be notified that there already is a route to the same prefix in the registry.
AS1とAS2の両方が同じ接頭語へのルートが登録に既にあるように通知されるでしょう。
Bates, et al. [Page 23] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [23ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
This multiple proxy aggregation is very dangerous to do if the sub- aggregates of the route are not the same. It is still dangerous when the sub-aggregates are consistent but connectivity to the sub- aggregates varies widely between the originators.
ルートのサブ集合が同じでないなら、この複数のプロキシ集合はするのが非常に危険です。 サブ集合が一貫しているとき、それはまだ危険ですが、サブ集合への接続性は創始者の間でばらつきが大きいです。
Route object update procedures
ルート物のアップデート手順
Adding a route object will have to be authorised by the maintainer of the originating AS. The actual implementation of this is outside the scope of this document. This guarantees that an AS guardian has full control over the registration of the routes it announces [11].
ルート物を加えるのは由来しているASの維持装置によって認可されなければならないでしょう。 このドキュメントの範囲の外にこの実際の実現はあります。 保護者が完全にするASがルートの登録の上でそれを制御するというこの保証は[11]を示します。
What is an Inter-AS network ?
Inter-ASネットワークは何ですか?
An inter-AS network (Inter-AS IP networks are those networks are currently called FIXes, IXFs, DMZs, NAPs, GIX and many other acronyms) exists for the purpose of passing traffic and routing information between different autonomous systems. The most simple example of an inter-AS network is a point-to-point link, connecting exactly two ASes. Each end of such a link is connected to an interface of router belonging to each of the autonomous systems. More complex examples are broadcast type networks with multiple interfaces connecting multiple ASes with the possibility of more than one connection per AS. Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS networks X and Y:
相互ASネットワーク(相互AS IPネットワークはそれらのネットワークが現在FIXes、IXFs、DMZs、NAPs、GIX、および他の多くの頭文字語と呼ばれるということである)は交通とルーティング情報の目的のために異なった自律システムの間に存在しています。相互ASネットワークの最も簡単な例はポイントツーポイント接続です、ちょうど2ASesを接続して。 そのようなリンクの各端はそれぞれの自律システムへのルータ属のインタフェースに接続されます。より複雑な例は複数のインタフェースが1ASあたり1つ以上の接続の可能性に複数のASesを接続する放送タイプネットワークです。 インタフェースaからfが2つの相互ASネットワークXとYによって接続される状態で、3つのルータ1、2、および3に関する以下の例を考えてください:
X Y
a1b --- c2d --- e3f
X Y a1b--- c2d--- e3f
Suppose that network X is registered in the routing registry as part of AS1 and net Y as part of AS3. If traffic passes from left to right prtraceroute will report the following sequence of interfaces and ASes:
ネットワークXがAS3の一部としてのAS1とネットYの一部としてルーティング登録に登録されると仮定してください。 交通が左から右まで通り過ぎると、prtracerouteはインタフェースとASesの以下の系列を報告するでしょう:
a in AS1
c in AS1
e in AS3
AS3のAS1eのAS1cのa
The traceroute algorithm enumerates only the receiving interfaces on the way to the destination. In the example this leads to the passage
トレースルートアルゴリズムは受信インタフェースだけを目的地への途中に列挙します。 例では、これは通路に通じます。
Bates, et al. [Page 24] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [24ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
of AS2 going unnoticed. This is confusing to the user and will also generate exceptions when the path found is checked against the routing registry.
AS2が見つからずに済むのについて。 見つけられた経路がルーティング登録に対してチェックされるとき、これは、ユーザに混乱させていて、また、例外を発生させるでしょう。
For operational monitoring tools such as prtraceroute it is necessary to know which interface on an inter-AS network belongs to which AS. If AS information is not known about interfaces on an inter-AS network, tools like prtraceroute cannot determine correctly which ASes are being traversed.
prtracerouteなどの操作上のモニターしているツールに、相互ASネットワークのどのインタフェースがどのASに属すかを知るのが必要です。 AS情報が相互ASネットワークでインタフェースに関して知られていないなら、prtracerouteのようなツールは、どのASesが横断されているかを正しく決定できません。
All interfaces on inter-AS networks will are described in a separate object know as the `inet-rtr' object [15].
ネットワークが望んでいる相互ASの上のすべてのインタフェースが別々の目的が'inet-rtr'物[15]として知っている説明されたコネです。
Bates, et al. [Page 25] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [25ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
6. The Autonomous System Object
6. 自律システム物
Autonomous Systems
自律システム
An Autonomous System (AS) is a group of IP networks operated by one or more network operators which has a single and clearly defined external routing policy.
Autonomous System(AS)は1人以上のネットワーク・オペレータによって経営されたIPネットワークのグループです(単一の、そして、明確に定義された外部のルーティング方針があります)。
An AS has a unique number associated with it which is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as BGP and EGP are used to exchange routing information between ASes.
ASには、それに関連しているユニークな数があります(外のルーティング情報の交換とAS自身に関する識別子として使用されます)。 BGPやEGPなどの外のルーティング・プロトコルは、ASesの間でルーティング情報を交換するのに使用されます。
In routing terms an AS will normally use one or more interior gateway protocols (IGPs) in conjunction with some sort of common agreed metrics when exchanging network information within its own AS.
それ自身のASの中でネットワーク情報を交換するとき、ルーティング用語で、通常、ASはある種の一般的な同意された測定基準に関連して1つ以上の内部のゲートウェイプロトコル(IGPs)を使用するでしょう。
The term AS is often confused or even misused as a convenient way of grouping together a set of networks which belong under the same administrative umbrella even if within that group of networks there are various different routing policies. We provide the "community" concept for such use. ASes can strictly have only one single external routing policy.
ネットワークのそのグループの中に様々な異なったルーティング方針があっても、ASという用語は、しばしば混乱するか、または同じ管理かさに属すネットワークのセットを一緒に分類する便利な方法として誤用さえされます。 私たちはそのような使用のための「共同体」概念を提供します。 ASesは厳密に1つのただ一つの外部のルーティング方針しか持つことができません。
The creation of an AS should be done in a conscious and well coordinated manner to avoid creating ASes for the sake of it, perhaps resulting in the worst case scenario of one AS per routing announcement. It should be noted that there is a limited number of AS numbers available. Also creating an AS may well increase the number of AS paths modern EGPs will have to keep track of. This aggravates what is known as "the routing table growth problem". This may mean that by applying the general rules for the creation and allocation of an AS below, some re-engineering may well be needed. However, this may be the only way to actually implement the desired routing policy anyway. The creation and allocation of an AS should be done with the following recommendations in mind:
それのためにASesを作成するのを避けるために意識していてよく調整された方法でASの創造をするべきです、恐らくルーティング発表あたり1ASの最悪の場合をもたらして。 有効なAS番号の限られた数があることに注意されるべきです。 また、ASを作成すると、近代的なEGPsが動向をおさえなければならないAS経路の数はたぶん増加するでしょう。 これは「経路指定テーブル成長問題」として知られていることをいらいらさせます。 これは、以下でのASの創造と配分のために総則を適用することによって、何らかのリエンジニアリングがたぶん必要であるだろうことを意味するかもしれません。 しかしながら、これは実際にとにかく必要なルーティング政策を実施する唯一の方法であるかもしれません。 念頭で以下の推薦でASの創造と配分をするべきです:
+ Creation of an AS is only required when exchanging routing
information with other ASes. Some router implementations make
use of an AS number as a form of tagging to identify the routing
process. However, it should be noted that this tag does not
need to be unique unless routing information is indeed exchanged
with other ASes.
他のASesとルーティング情報を交換するときだけ、+ ASの創造が必要です。 いくつかのルータ実現が、ルーティングの過程を特定するのにタグ付けのフォームとしてAS番号を利用します。 しかしながら、ルーティング情報が本当に他のASesと共に交換されない場合このタグが特有である必要はないことに注意されるべきです。
Bates, et al. [Page 26] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [26ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
+ For a simple case of customer networks connected to a single
service provider, the IP network should normally be a member of
the service providers AS. In terms of routing policy the IP
network has exactly the same policy as the service provider and
there is no need to make any distinction in routing information.
This idea may at first seem slightly alien to some, but it
highlights the clear distinction in the use of the AS number as
a representation of routing policy as opposed to some form of
administrative use.
ただ一つのサービスプロバイダーに接続された顧客ネットワークの簡単なケースのための+、通常、IPネットワークはサービスプロバイダーASのメンバーであるはずです。 IPネットワークには、ルーティング方針で、まさにサービスプロバイダーと同じ方針があります、そして、ルーティングにおけるどんな区別も情報にする必要は全くありません。 この考えは初めに、いくつかにわずかに異質に見えるかもしれませんが、それは何らかの形式の管理使用と対照的にルーティング方針の表現としてAS番号の使用における明らかな区別を強調します。
+ If a network operator connects to more than one AS with
different routing policies then they need to create their own
AS. In the case of multi-homed customer networks connected to
two service providers there are at least two different routing
policies to a given customer network. At this point the
customer networks will be part of a single AS and this AS would
be distinct from either of the service providers ASes. This
allows the customer the ability of having a different
representation of policy and preference to the different service
providers. This is the ONLY case where a network operator
should create its own AS number.
+はネットワーク・オペレータであるなら異なったルーティング方針で1ASに接続して、次に、それらは、それら自身のASを作成する必要があります。 ケース、マルチ、家へ帰り、顧客ネットワークは与えられた顧客ネットワークへの少なくとも2つの異なったルーティング方針をある2つのサービスプロバイダーに関連づけました。 ここに、顧客ネットワークは独身のASの一部になるでしょう、そして、このASはサービスプロバイダーASesのどちらかと異なっているでしょう。 これは方針と好みの異なった表現を異なったサービスプロバイダーに持つ能力を顧客に許容します。 これはネットワーク・オペレータがそれ自身のAS番号を作成するべきである唯一のそうです。
+ As a general rule one should always try to populate the AS with
as many routes as possible, providing all routes conform to the
same routing policy.
同じくらい多くのルートが可能な状態で+概していつもASに居住しようとするべきです、すべてのルートが同じルーティング方針に一致しているなら。
Each AS is represented in the RIPE database by both an aut-num object and the route objects representing the routes originated by the AS. The aut-num object stores descriptive, administrative and contact information about the AS as well as the routing policies of the AS in relation to all neighboring ASes.
各ASは、ASによって溯源されたルートを表しながら、RIPEデータベースにaut-num物とルート物の両方によって表されます。 aut-num物が格納する、描写的であるのと、管理、そして、すべての隣接しているASesと関連したASのルーティング方針と同様にASに関する問い合わせ先。
The origin attributes of the route objects define the set of routes originated by the AS. Each route object can have exactly one origin attribute. Route objects can only be created and updated by the maintainer of the AS and not by those immediately responsible for the particular routes referenced therein. This ensures that operators, especially service providers, remain in control of AS routing announcements.
ルート物の起源属性はASによって溯源されたルートのセットを定義します。 それぞれのルート物はまさに1つの起源属性を持つことができます。 ASの維持装置はルート物を作成して、すぐにそこに参照をつけられた特定のルートに責任があるそれらでアップデートするのではなく、アップデートできるだけです。 これは、オペレータ(特にサービスプロバイダー)がASルーティング発表のコントロールに残っているのを確実にします。
The AS object itself is used to represent a description of administrative details and the routing policies of the AS itself. The AS object definition is depicted as follows.
AS物自体は、AS自身の管理詳細とルーティング方針の記述を表すのに使用されます。 ASオブジェクト定義は以下の通り表現されます。
Bates, et al. [Page 27] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [27ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example:
例:
aut-num: AS1104 descr: NIKHEF-H Autonomous system as-in: from AS1213 100 accept AS1213 as-in: from AS1913 100 accept AS1913 as-in: from AS1755 150 accept ANY as-out: to AS1213 announce ANY as-out: to AS1913 announce ANY as-out: to AS1755 announce AS1104 AS1913 AS1213 tech-c: Rob Blokzijl admin-c: Eric Wassenaar guardian: as-guardian@nikhef.nl changed: ripe-dbm@ripe.net 920910 source: RIPE
aut-num: AS1104 descr: NIKHEF-H Autonomousシステム、コネとして: AS1213 100から、コネとしてAS1213を認めてください: AS1913 100から、コネとしてAS1913を認めてください: AS1755 150から、アウトとして何でも受け入れてください: AS1213に、アウトとして何でも発表してください: AS1913に、アウトとして何でも発表してください: AS1755に、AS1104 AS1913 AS1213の科学技術のcを発表してください: Blokzijlアドミンcから、略奪してください: エリックワッセナー保護者: as-guardian@nikhef.nl は変化しました: ripe-dbm@ripe.net 920910ソース: 熟す
See Appendix A for a complete syntax definition of the "aut-num" object.
"aut-num"物の完全な構文定義に関してAppendix Aを見てください。
It should be noted that this representation provides two things:
この表現が2つのものを提供することに注意されるべきです:
+ a set of routes.
+ 1セットのルート。
+ a description of administrative details and routing policies.
+ 管理詳細とルーティング方針の記述。
The set of routes can be used to generate network list based configuration information as well as configuration information for exterior routing protocols knowing about ASes. This means an AS can be defined and is useful even if it does not use routing protocols which know about the AS concept.
ASesに関して知りながら外のルーティング・プロトコルのための設定情報と同様にネットワークリストに基づいている設定情報を発生させるのにルートのセットを使用できます。 これはAS概念に関して知っているルーティング・プロトコルを使用しないでも、ASが定義できて、役に立つことを意味します。
Bates, et al. [Page 28] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [28ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Description of routing policies between ASs with multiple connections - "interas-in/interas-out"
複数の接続によるASsの間のルーティング方針の記述--「外の中のinteras/interas」
The following section is only relevant for ASes which use different policies on multiple links to the same neighboring AS. Readers not doing this may want to skip this section.
同じ隣接しているASへの複数のリンクに関する異なった方針を使用するASesだけにおいて、以下のセクションは関連しています。 これをしていない読者はこのセクションをスキップしたがっているかもしれません。
Description of multiple connections between ASs defines how two ASs have chosen to set different policies for the use of each or some of the connections between the ASs. This description is necessary only if the ASs are connected in more than one way and the routing policy and differs at these two connections.
2ASsが、それぞれの使用かASsの間の何人かの接続のための異なった方針を設定するのをどう選んだかをASsの間の複数の接続の記述は定義します。 ASsが1つ以上の方法とルーティング方針で接続されて、これらの2つの接続のときに異なる場合にだけ、この記述が必要です。
Example:
例:
LINK1
193.0.1.1 +----------+ 193.0.1.2
| |
AS1------AS2== ==AS3-----AS4
| |
193.0.1.5 +----------+ 193.0.1.6
LINK2
LINK1 193.0.1.1+----------+ 193.0.1.2 | | AS1------AS2== ==AS3-----AS4| | 193.0.1.5 +----------+ 193.0 .1、.6LINK2
Note: LINK here denotes the peer connection points between
ASs. It is not necessarily just a serial link. It could
be ethernet or any other type of connection as well. It
can also be a peer session where the address is the same at
one end and different at the other end.
以下に注意してください。 ここのLINKはASsの間の同輩接続拠点を指示します。 それは必ず連続の単なるリンクであるというわけではありません。 それはまた、イーサネットかいかなる他のタイプの接続であるかもしれません。 また、アドレスがどこで片端で同じであって、もう一方の端のときに異なっているかは、同輩セッションであるかもしれません。
It may be that AS2 wants to use LINK2 only for traffic towards AS4. LINK1 is used for traffic to AS3 and as backup to AS4, should LINK2 fail. To implement this policy, one would use the attribute "interas-in" and "interas-out." This attribute permits ASs to describe their local decisions based on its preference such as multi-exit-discriminators (MEDs) as used in some inter-domain routing protocols (BGP4, IDRP) and to communicate those routing decisions. This information would be useful in resolving problems when some traffic paths changed from traversing AS3's gateway in Timbuktu rather than the gateway in Mogadishu. The exact syntax is given in Appendix A. However, if we follow this example through in terms of AS2 we would represent this policy as follows:
多分、AS2は交通にだけAS4に向かってLINK2を使用したがっています。 LINK2が失敗するなら、LINK1はAS3とバックアップとした交通にAS4に使用されます。 この政策を実施するために、1つは属性「中のinteras」と「外のinteras」を使用するでしょう。 この属性は、ASsがいくつかの相互ドメインルーティング・プロトコル(BGP4、IDRP)に使用されるようにマルチ出口の弁別器(MEDs)などの好みに基づく地元の決定について説明して、それらのルーティング決定を伝えることを許可します。 いくつかの交通経路がモガディシュのゲートウェイよりむしろティンブクトゥのAS3のゲートウェイを横断するのでいつ変化したかというこの情報は問題を解決する際に役に立つでしょう。 私たちは、Appendix A.Howeverで正確な構文を与えて、AS2で終えたこの例に倣うなら、以下のこの方針を表すでしょう:
Bates, et al. [Page 29] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [29ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example:
例:
aut-num: AS2
as-in: from AS3 10 accept AS3 AS4
as-out: to AS3 announce AS1 AS2
interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=5) accept AS3
interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=9) accept AS4
interas-in:from AS3 193.0.1.5/32 193.0.1.6/32 (pref=7) accept AS4
...
aut-num: AS2、コネとして: AS3 10から、アウトとしてAS3 AS4を認めてください: AS3に、中のAS1 AS2 interasを発表してください: AS3 193.0.1.1/32 193.0.1.2/32(pref=5)から、中のAS3 interasを受け入れてください: AS3 193.0.1.1/32 193.0.1.2/32(pref=9)から、中のAS4 interasを受け入れてください: AS3 193.0.1.5/32 193.0.1.6/32(pref=7)から、AS4を受け入れてください…
Here we see additional policy information between two ASs in terms of the IP addresses of the connection. The parentheses and keyword are syntactic placeholders to add the readability of the attributes. If pref=MED is specified the preference indicated by the remote AS via the multi-exit- discriminator metric such as BGP is used. Of course this type on inter-AS policy should always be bilaterally agreed upon to avoid asymmetry and in practice there may need to be corresponding interas-out attributes in the policy representation of AS3.
ここで、私たちは接続のIPアドレスで2ASsの間の追加方針情報を見ます。 括弧とキーワードは属性の読み易さを加える構文のプレースホルダです。 pref=MEDが指定されるなら、BGPなどのようなメートル法のマルチ出口の弁別器を通してリモートASによって示された好みは使用されています。 もちろん、相互AS方針のこのタイプは非対称を避けるために相互的にいつも同意されるべきです、そして、実際には、AS3の方針表現における対応する外のinteras属性は必要とするかもしれないでしょう。
The interas-out attribute is similar to interas-in as as-out is to as-in. The one major difference being that interas-out allows you to associate an outgoing metric with each route. It is important to note that this metric is just passed to the peer AS and it is at the peer AS's discretion to use or ignore it. A special value of IGP specifies that the metric passed to the receiving AS will be derived from the IGP of the sending AS. In this way the peer AS can choose the optimal link for its traffic as determined by the sending AS.
外のinteras属性がアウトのように中のinterasと同様である、コネとして、あります。 あなたが外のそのinterasである1つの主要な違いで交際できる、外向的である、各ルートで、メートル法です。 これほどメートル法でそれに注意するのがただ同輩ASに通られて、それを使用するか、または無視するために同輩ASの裁量にはそれがあるのは、重要です。 IGPの特別な値は、受信ASに通過されたメートル法が発信しているASのIGPから得られると指定します。 このように、発信しているASによって決定されるように同輩ASは交通への最適のリンクを選ぶことができます。
If we look at the corresponding interas-out for AS3 we would see the following:
AS3のために外の対応するinterasを見るなら、私たちは以下を見るでしょう:
Example:
例:
aut-num: AS3 as-in: from AS2 10 accept AS1 A2 as-out: to AS2 announce AS3 AS4 interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3 interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=9) announce AS4 interas-out:to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=7) announce AS4 ...
aut-num: AS3、コネとして: AS2 10から、アウトとしてAS1 A2を認めてください: AS2に、外のAS3 AS4 interasを発表してください: AS2 193.0.1に、.2/32 193.0.1.1/32(メートル法的に出かけている=5)は外のAS3 interasを発表します: AS2 193.0.1に、.2/32 193.0.1.1/32(メートル法的に出かけている=9)は外のAS4 interasを発表します: AS2 193.0.1に、.6/32 193.0.1.5/32(メートル法的に出かけている=7)はAS4を発表します…
Bates, et al. [Page 30] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [30ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Descriptions of interas policies do not replace the global policy described in as-in, as-out and other policy attributes which should be specified too. If the global policy mentions more routes than the combined local policies then local preferences for these routes are assumed to be equal for all links.
interas方針の記述は中でコネ、アウトと説明されたグローバルな方針と指定されるべきである他の方針属性にも取って代わりません。 グローバルな方針が結合したローカルの方針より多くのルートに言及するなら、これらのルートのための地方の好みがすべてのリンクに等しいと思われます。
Any route specified in interas-in/out and not specified in as-in/out is assumed not accepted/announced between the ASes concerned. Diagnostic tools should flag this inconsistency as an error. It should be noted that if an interas-in or interas-out policy is specified then it is mandatory to specify the corresponding global policy in the as-in or as-out line. Please note there is no relevance in the cost associated with as-in and the preferences used in interas-in.
どんなルートも、当該のASesの間で受け入れたか、または発表しませんでした中のinteras/出ていて外でコネとしての/で指定されなかった指定されたコネが思われる。 診断用道具は誤りとしてこの矛盾に旗を揚げさせるはずです。 中のinterasか外のinteras方針が指定されるならコネとした、または、アウトとした線で対応するグローバルな方針を指定するのが義務的であることに注意されるべきです。 コネとして交際された費用と中のinterasで使用される好みにおける関連性が全くありません。
The interaction of interas-in/interas-out with as-in/as-out
コネとしての/でinterasアウトとして中のinteras/出かけることの相互作用
Although formally defined above, the rules associated with policy described in terms of interas-in and interas-out with respect to as- in and as-out are worthy of clarification for implementation.
正式に上、中のinterasに関して説明される方針に関連している規則、および外のinterasを定義する、-、アウトとアウトとして、実現のための明確化の立派な人物はそうです。
When using interas-in or interas-out policy descriptions, one must always make sure the set of policies described between two ASes is always equal to or a sub-set of the policy described in the global as-in or as-out policy. When a sub-set is described remember the remaining routes are implicitly shared across all connections. It is an error for the interas policies to describe a superset of the global policies, i.e. to announce or accept more routes than the global policies.
中のinterasか外のinteras方針記述を使用して、いつまで2ASesの間で説明された方針のセットが確実にいつも等しくなるようにいつもしなければならないか、さもなければ、方針の部分集合は中でコネとした、または、アウトとしたグローバルな方針を説明しました。 部分集合が説明されたら、残っているルートがすべての接続の向こう側にそれとなく共有されたのを覚えていてください。 それはすなわち、グローバルな方針より多くのルートをinteras方針がグローバルな方針のスーパーセットについて説明して、発表するか、または受け入れる誤りです。
When defining complex interas based policies it is advisable to ensure that any possible ambiguities are not present by explicitly defining your policy with respect to the global as-in and as-out policy.
複雑なinterasベースの方針を定義するとき、どんな可能なあいまいさもコネとしたアウトとしたグローバルな方針に関して明らかにあなたの方針を定義することによって存在していないのを保証するのは賢明です。
If we look at a simple example, taking just in-bound announcements to simplify things. If we have the following global policy:
ものを簡素化するためにまさしく行きでの発表を取って、私たちが簡単な例を見るなら。 私たちに以下のグローバルな方針があるなら:
aut-num: AS1
as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
aut-num: AS1、コネとして: AS2 10から、AS100 ORを受け入れてください。{10.0.0.0/8}
Suppose there are three peerings between AS1 and AS2, known as L1-R1, L2-R2 and L3-R3 respectively. The actual policy of these connections is to accept AS100 equally on these three links and just route 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to just specify an interas policy for L3-R3:
L1-R1、L2-R2、およびL3-R3としてそれぞれ知られているAS1とAS2の間には、3peeringsがあると仮定してください。 これらの接続の実際の方針がこれらの3個のリンクの上に等しくAS100を受け入れることであり、まさしくルート10.0.0.0/はL3-R3の上の8です。 この例外について言及する簡単な方法はただinteras方針をL3-R3に指定することです:
Bates, et al. [Page 31] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [31ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}
中のinteras: AS2 L3 R3(pref=100)から、受け入れてください。{10.0.0.0/8}
The implicit rule that all routes not mentioned in interas policies are accepted on all links with equal preference ensures the desired result.
等しい好みとのすべてのリンクの上にinteras方針で言及されなかったすべてのルートを受け入れるという暗黙の規則は必要な結果を確実にします。
The same policy can be written explicitly as:
以下として明らかに同じ方針を書くことができます。
interas-in: from AS2 L1 R1 (pref=100) accept AS100
interas-in: from AS2 L2 R2 (pref=100) accept AS100
interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}
中のinteras: AS2 L1 R1(pref=100)から、中のAS100 interasを受け入れてください: AS2 L2 R2(pref=100)から、中のAS100 interasを受け入れてください: AS2 L3 R3(pref=100)から、AS100 ORを受け入れてください。{10.0.0.0/8}
Whilst this may at first sight seem obvious, the problem arises when not all connections are mentioned. For example, if we specified only an interas-in line for L3-R3 as below:
これは一目で明白に見えるかもしれませんが、すべての接続が言及されるというわけではないとき、問題は起こります。 例えば、私たちが中のinterasだけを指定したなら、以下の同じくらいL3-R3には、立ち並んでください:
aut-num: AS1
as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}
aut-num: AS1、コネとして: AS2 10から、AS100 ORを受け入れてください、10.0、.0、.0/8、中のinteras: AS2 L3 R3(pref=100)から、AS100 ORを受け入れてください。{10.0.0.0/8}
then the policy for the other links according to the rules above
would mean they were equal to the global policy minus the sum of the
local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR
{10.0.0.0/0})) = empty) which in this case would mean nothing is
accepted on connections L1-R1 and L2-R2 which is incorrect.
すなわち、次に、上の規則に従った他のリンクへの方針が、それらがローカルの方針の合計を引いてグローバルな方針と等しかったことを意味するだろう、((AS100 OR、10.0、.0、.0/0、)、/、(AS100 OR、10.0、.0、.0/0、)、=は空になります(この場合何も接続のL1-R1とL2-R2のときに受け入れられないことを意味するでしょう)(不正確です)。
Another example: If we only registered the policy for link L2- R2:
別の例: 私たちがリンクL2R2に方針を登録しただけであるなら:
interas-in: from AS2 L2 R2 (pref=100) accept AS100
中のinteras: AS2 L2 R2(pref=100)から、AS100を受け入れてください。
The implicit policy for both L1-R1 and L3-R3 would be as follows:
L1-R1とL3-R3の両方のための暗黙の方針は以下の通りでしょう:
interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8}
interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}
中のinteras: AS2 L1 R1(pref=100)から、受け入れてください、10.0、.0、.0/8、中のinteras: AS2 L3 R3(pref=100)から、受け入れてください。{10.0.0.0/8}
This is derived as the set of global policies minus the set of interas-in policies (in this case just accept AS100 as it was the L2-R2 interas-in policy we registered) with equal cost for the remaining connection. This again is clearly not what was intended.
これは残っている接続のためにグローバルな方針のセットとして等しい費用で中のinteras方針のセットを引いて引き出されます(それが私たちが登録した中のL2-R2 interas方針であったので、この場合ただAS100を受け入れます)。 これは再び明確に意図したことではありません。
Bates, et al. [Page 32] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [32ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
We strongly recommend that you always mention all policies for all interas connections explicitly, to avoid these possible errors. One should always ensure the set of the interas policies is equal to the global policy. Clearly if interas policies differ in complex ways it is worth considering splitting the AS in question into separate ASes. However, this is beyond the direct scope of this document.
私たちは、あなたがこれらの可能な誤りを避けるためにいつも明らかにすべてのinteras接続のためのすべての方針に言及することを強く勧めます。 いつもinteras方針のセットが確実にグローバルな方針と等しくなるようにするべきです。 明確に、interas方針が複雑な道において異なるなら、問題のASを別々のASesに分割すると考える価値があります。 しかしながら、これはこのドキュメントのダイレクト範囲を超えています。
It should also be noted there is no direct relationship between the cost used in as-in and the preference used in interas-in.
また、コネとして中で使用された費用と中のinterasで使用される好みとの直接の因果関係が全くないことに注意されるべきです。
Bates, et al. [Page 33] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [33ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
How to describe the exclusion policy of a certain AS - "as-exclude"
どうあるASの除外方針を説明するか--、「-、除外、」
Some ASes have a routing policy based on the exclusion of certain routes if for whatever reason a certain AS is used as transit. Whilst, this is in general not good practice as it makes implicit assumptions on topology with asymmetry a possible outcome if not coordinated, this case needs to be accommodated within the routing policy representation.
あるASがトランジットとして使用されるいかなる理由でもいくつかのASesがルーティング方針をある一定のルートの除外に基づかせています。 これによるそうでなければ、非対称があるトポロジーにおける暗黙の仮定を可能な結果にするので、一般に、どんな良い習慣も調整されませんでした、ルーティング方針表現の中に収容されるべき本件の必要性ということですが。
The way this is achieved is by making use of the "as-exclude" attribute. The precise syntax of this attribute can be found in Appendix A along with the rest of the defined syntax for the "aut- num" object. However, some explanation of the use of this attribute is useful. If we have the following example topology.
これが達成される方法が使用をすることである、「-、除外、」 結果と考えます。 "aut- num"物のために定義された構文の残りに伴うAppendix Aでこの属性の正確な構文を見つけることができます。 しかしながら、この属性の使用の何らかの説明が役に立ちます。 私たちに以下の例のトポロジーがあるなら。
Example:
例:
AS4--------AS3
| | |
| | |
AS1--------AS2--------AS5
AS4--------AS3| | | | | | AS1--------AS2--------AS5
With a simple corresponding policy like so:
そうのような簡単な対応する方針で:
Example:
例:
aut-num: AS1
as-in: from AS2 100 accept ANY
as-out: to AS2 announce AS1
as-exclude: exclude AS4 to ANY
....
aut-num: AS1、コネとして: AS2 100から、アウトとして何でも受け入れてください: AS2に、AS1を発表してください、-、除外、: いずれまでもAS4を除いてください…
We see an interesting policy. What this says in simple terms is AS1 doesn't want to reach anything if it transits AS4. This can be a perfectly valid policy. However, it should be realized that if for whatever reason AS2 decides to route to AS3 via AS4 then immediately AS1 has no connectivity to AS3 or if AS1 is running default to AS2 packets from AS1 will still flow via AS4. The important point about this is that whilst AS1 can advise its neighbors of its policy it has no direct control on how it can enforce this policy to neighbors upstream.
私たちはおもしろい方針を見ます。 AS4を通過するなら、これが簡単に言えばAS1であると言うことは何にも達したがっていません。 これは完全に有効な方針であるかもしれません。 しかしながら、それでも、AS1がAS2が次に、すぐにAS4を通してAS3に発送すると決めるどんな理由でも接続性を全くAS3に持っていないか、またはAS1がデフォルトをAS2へ走らせているとAS1からのパケットがAS4を通して流れると実感されるべきです。 これに関する重要なポイントはAS1が方針を隣人に知らせることができますが、それがどうこの方針を隣人に実施できるかにおける直轄を全く上流にしないということです。
Bates, et al. [Page 34] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [34ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Another interesting scenario to highlight the unexpected result of using such an "as-exclude" policy. If we assume in the above example AS2 preferred AS4 to reach AS3 and AS1 did not use default routing then as stated AS1 would have no connectivity to AS3. Now lets suppose that for example the link between AS2 and AS4 went down for some reason. Like so:
そのようなものを使用する予期しなかった結果を強調する別のおもしろいシナリオ、「-、除外、」 方針 私たちが、上記の例でAS2が、AS4がAS3に達するのを好んで、AS1がその時述べられるとしてデフォルトルーティングを使用しなかったと思うなら、AS1は接続性を全くAS3に持っていないでしょう。 現在、例えばAS2とAS4とのリンクがある理由で落ちたと思わせます。 そうのように:
Example:
例:
AS4--------AS3
|
|
AS1--------AS2--------AS5
AS4--------AS3| | AS1--------AS2--------AS5
Suddenly AS1 now has connectivity to AS3. This unexpected behavior should be considered when created policies based on the "as-exclude" attribute.
突然、AS1は現在、AS3に接続性を持っています。 ベースの作成された方針であるときに、この予期していなかった振舞いが考えられるべきである、オンである、「-、除外、」 属性
The second problem with this type of policy is the potential of asymmetry. In the original example we saw the correct policy from AS1's point of view but if ASes with connectivity through AS4 do not use a similar policy you have asymmetric traffic and policy. If an AS uses such a policy they must be aware of the consequences of its use. Namely that the specified routes which transit the AS (i.e. routing announcements with this AS in the AS path information) in question will be excluded. If not coordinated this can easily cause asymmetry or even worse loss of connectivity to unknown ASes behind (or in front for that matter) the transit AS in question. With this in mind this attribute can only be viewed as a form of advisory to other service providers. However, this does not preclude its use with policy based tools if the attribute exists.
このタイプの方針に関する2番目の問題は非対称の可能性です。 オリジナルの例では、私たちはAS1の観点から正しい方針を見ましたが、AS4を通して接続性があるASesが同様の方針を使用しないなら、あなたには、非対称の交通と方針があります。 ASがそのような方針を使用するなら、彼らは使用の結果を知っているに違いありません。 すなわち、問題のAS(すなわち、このASがAS経路情報にあるルーティング発表)がそれのトランジットがそうする指定されたルートは除かれます。 調整されないなら、これは容易に後ろ(またはさらに言えば、前部で)の未知のASesへの接続性の非対称かさらに悪い損失に問題のトランジットASを引き起こす場合があります。 これが念頭にある場合、他のサービスプロバイダーへの状況報告のフォームとしてこの属性を見なすことができるだけです。 しかしながら、属性が存在しているなら、これは方針に基づいているツールによる使用を排除しません。
By having the ability to specify a route keyword based on any of the four notations given in the syntax it allows the receiving AS to specify what routes it wishes to exclude through a given transit AS to a network granularity.
構文で与えられた4つの記法のいずれにも基づくルートキーワードを指定する能力を持っていることによって、受信ASは、それでそれが与えられたトランジットでネットワーク粒状までどんなルートを除きたがっているかをASを指定できます。
Bates, et al. [Page 35] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [35ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
7. AS Macros
7. マクロとして
It may be difficult to keep track of each and every new AS that is represented in the routing registry. A convenient way around this is to define an `AS Macro' which essentially is a convenient way to group ASes. This is done so that each and every AS guardian does not have to add a new AS to it's routing policy as described by the as-in and as-out attributes of it's AS object.
ルーティング登録に表されるありとあらゆる新しいASの動向をおさえるのは難しいかもしれません。 これの周りの便利な道は本質的にはASesを分類する便利な方法である'AS Macro'を定義することです。 これが完了しているので、ありとあらゆるAS保護者が、コネとしたアウトとしたそれの属性によって説明されるようにそれへの新しいASが方針を発送していると言い足す必要はないのは、AS物です。
However, it should be noted that this creates an implicit trust on the guardian of the AS-Macro.
しかしながら、これがAS-マクロの保護者に暗黙の信用を作成することに注意されるべきです。
An AS-Macro can be used in <routing policy expressions> for the "as- in" and "as-out" attributes in the aut-num object. The AS-Macro object is then used to derive the list or group of ASes.
<ルーティング方針表現>でAS-マクロを使用できる、「-、」 aut-numの「アウト」としての属性では、反対してください。 そして、AS-マクロ物は、ASesのリストかグループを引き出すのに使用されます。
A simple example would be something like:
簡単な例は以下に似ているでしょう。
Example:
例:
aut-num: AS786
as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
as-out to AS1755 announce AS786
.....
aut-num: AS786、コネとして: AS1755 100から、アウトとしてAS1755にAS-EBONE AND NOT AS1104を認めてください。AS786を発表してください…
Where the as-macro object for AS-EBONE is as follows:
AS-EBONEのためのマクロとしての物は以下の通りであるところ:
as-macro: AS-EBONE
descr: ASes routed by EBONE
as-list: AS2121 AS1104 AS2600 AS2122
as-list: AS1103 AS1755 AS2043
guardian: guardian@ebone.net
......
マクロとして: AS-EBONE descr: ASesはリストとしてEBONEで掘りました: AS2121 AS1104 AS2600 AS2122、リストとして: AS1103 AS1755 AS2043保護者: guardian@ebone.net …
So the policy would be evaluated to:
それで、方針は以下のことのために評価されるでしょう。
aut-num: AS786
as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
as-in: from AS1755 100 accept AS1103 OR AS1755 OR
as-in: from AS1755 100 accept AS2043) AND NOT AS1104
......
aut-num: AS786、コネとして: AS1755 100から、受け入れてください、(AS2121 OR AS1104 OR AS2600 OR AS2122、コネとして: AS1755 100から、コネとしてAS1103 OR AS1755 ORを認めてください: AS1755 100から、AS2043) AND NOT AS1104を受け入れてください…
Bates, et al. [Page 36] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [36ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
It should be noted that the above examples incorporates the rule for line wrapping as defined in Appendix A for policy lines. See Appendix C for a definition on the AS-Macro syntax.
上記の例が線ラッピングのためにAppendix Aで施政方針と定義されるように規則を取り入れることに注意されるべきです。 AS-マクロ構文で定義に関してAppendix Cを見てください。
Bates, et al. [Page 37] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [37ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
8. The Community Object
8. 共同体物
A community is a group of routes that cannot be represented by an AS or a group of ASes. It is in some circumstances useful to define a group of routes that have something in common. This could be a special access policy to a supercomputer centre, a group of routes used for a specific mission, or a disciplinary group that is scattered among several autonomous systems. Also these communities could be useful to group routes for the purpose of network statistics.
共同体は、ASが表すことができないルートのグループかASesのグループです。 ルートのグループを定義するために役に立ついくつかの事情では、一脈相通じるものがあってください。 これは、スーパーコンピュータセンターへの特別なアクセス方針、特定の任務に使用される、ルートのグループ、またはいくつかの自律システムの中に点在する訓練上のグループであるかもしれません。また、これらの共同体も、ネットワーク統計の目的のためにルートを分類するために役に立つかもしれません。
Communities do not exchange routing information, since they do not represent an autonomous system. More specifically, communities do not define routing policies, but access or usage policies. However, they can be used as in conjunction with an ASes routing policy to define a set of routes the AS sets routing policy for.
彼らが自律システムを表さないので、共同体はルーティング情報を交換しません。 より明確に、共同体はルーティング方針ではなく、アクセスか用法方針を定義します。 しかしながら、ASがルーティング方針を設定する1セットのルートを定義するASesルーティング方針に関連してそれらを使用できます。
Communities should be defined in a strict manner, to avoid creating as many communities as there are routes, or even worse. Communities should be defined following the two rules below;
共同体は、ルート、さらに悪いのがあるのと同じくらい多くの共同体を創設するのを避けるために厳しい方法で定義されるべきです。 以下の2つの規則に従って、共同体は定義されるべきです。
+ Communities must have a global meaning. Communities that have
no global meaning, are used only in a local environment and
should be avoided.
+ 共同体には、グローバルな意味がなければなりません。 いいえをグローバルにする共同体は、意味して、地方の環境だけで使用されて、避けられるべきです。
+ Communities must not be defined to express non-local policies.
It should be avoided that a community is created because some
other organization forces a policy upon your organization.
Communities must only be defined to express a policy defined by
your organization.
非ローカルの方針を言い表すために+ 共同体を定義してはいけません。 避けられて、ある他の組織があなたの組織に方針を押しつけるのでそのa共同体が創設されるということであるべきです。 あなたの組織によって定義された方針を言い表すためには共同体を定義するだけでよいです。
Community examples
共同体の例
There are some clear examples of communities:
共同体のいくつかの明確な例があります:
BACKBONE -
all customers of a given backbone service provider even though
they can have various different routing policies and hence
belong to different ASes. This would be extremely useful for
statistics collection.
BACKBONE--与えられた背骨サービスプロバイダーのすべての顧客が、彼らですが、様々な異なったルーティング方針を持って、したがって、異なったASesに属すことができます。 これは非常に統計収集の役に立つでしょう。
Bates, et al. [Page 38] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [38ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
HEPNET -
the High Energy Physics community partly shares infrastructure
with other organizations, and the institutes it consists of are
scattered all over Europe, often being part of a non HEPNET
autonomous system. To allow statistics, access or part of a
routing policy , a community HEPNET, consisting of all routes
that are part of HEPNET, conveniently groups all these routes.
HEPNET--High Energy Physics共同体は他の組織とインフラストラクチャを一部共有します、そして、それが成る研究所はヨーロッパ全体にわたって点在します、しばしば非HEPNET自律システムの一部であり。 ルーティング方針、共同体の統計、アクセスまたは一部を許容するために、HEPNETの一部であるすべてのルートから成って、HEPNETは便利にこれらのすべてのルートを分類します。
NSFNET -
the National Science Foundation Network imposes an acceptable
use policy on routes that wish to make use of it. A community
NSFNET could imply the set of routes that comply with this
policy.
国立科学財団Networkは許容できる使用を課します。NSFNET--、それを利用したがっているルートに関する方針。 共同体NSFNETはこの方針に従うルートのセットを含意できました。
MULTI -
a large multinational corporation that does not have its own
internal infrastructure, but connects to the various parts of
its organizations by using local service providers that connect
them all together, may decide to define a community to restrict
access to their networks, only by networks that are part of this
community. This way a corporate network could be defined on
shared infrastructure. Also, this community could be used by any
of the service providers to do statistics for the whole of the
corporation, for instance to do topology or bandwidth planning.
MULTI--それ自身の内部のインフラストラクチャを持っていませんが、一斉にそれらを接続するローカル・サービスプロバイダーを使用することによって組織の様々な部分に接続する大きい多国籍企業は、アクセスをそれらのネットワークに制限するために共同体を定義すると決めるかもしれません、この共同体の一部である唯一のネットワークで。 この道と、共有されたインフラストラクチャで企業ネットワークを定義できました。 また、この共同体はトポロジーか帯域幅計画をするのにいずれによってもサービスプロバイダーに使用されて、例えば、会社の全体のために統計できました。
Similar to Autonomous systems, each community is represented in the RIPE database by both a community object and community tags on the route objects representing the routes belonging to the community. The community object stores descriptive, administrative and contact information about the community.
Autonomousシステムと同様です、各共同体は、共同体のものルートを表しながら、ルート物の上にRIPEデータベースで共同体物と共同体タグの両方によって代表されます。 共同体物が格納する、描写的であるのと、管理、そして、共同体に関する問い合わせ先。
The community tags on the route objects define the set of routes belonging to a community. A route can have multiple community tags. The community tags can only be created and updated by the "guardian" of the community and not by those directly responsible for the particular network. This ensures that community guardians remain in control of community membership.
ルート物の上の共同体タグは共同体のものルートのセットを定義します。 ルートは複数の共同体タグを持つことができます。 直接特定のネットワークに責任があるそれらではなく、共同体の「保護者」が、共同体タグを作成して、アップデートできるだけです。 これは、共同体の保護者が共同体会員資格のコントロールに残っているのを確実にします。
Here's an example of how this might be represented in terms of the community tags within the network object. We have an example where the route 192.16.199.0/24 has a single routing policy (i.e. that of AS 1104), but is part of several different communities of interest. We use the tag "comm-list" to represent the list of communities associated with this route. NIKHEF-H uses the service provider SURFNET (a service provider with customers with more than one routing
ここに、これがネットワーク物の中に共同体タグに関してどう表されるかもしれないかに関する例があります。 私たちは.0/24がaに選抜させるしかし方針(すなわち、AS1104のもの)を発送するルート192.16.199がそうである例に興味があるいくつかの異なった共同体を離れさせます。 私たちは、このルートに関連している共同体のリストを表すのにタグ「comm-リスト」を使用します。 NIKHEF-HがサービスプロバイダーSURFNETを使用する、(1以上をもっている顧客が掘っているサービスプロバイダー
Bates, et al. [Page 39] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [39ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
policy), is also part of the High Energy Physics community as well as having the ability to access the Supercomputer at CERN (the community `CERN-SUPER', is somewhat national, but is intended as an example of a possible use of an access policy constraint).
方針)、CERN(共同体'CERN-SUPER'は、いくらか国家ですが、アクセス方針規制の活用可能性に関する例として意図する)でSupercomputerにアクセスする能力を持っていることと同様にHigh Energy Physics共同体の一部もそうです。
Example:
例:
route: 192.16.199.0/24 descr: Local Ethernet descr: NIKHEF section H origin: AS1104 comm-list: HEPNET CERN-SUPER SURFNET changed: ripe-dbm@ripe.net 920604 source: RIPE
以下を発送してください。 192.16.199.0/24descr: 地方のイーサネットdescr: NIKHEFセクションHの起源: AS1104 comm-リスト: HEPNET CERN-SUPER SURFNETは変化しました: ripe-dbm@ripe.net 920604ソース: 熟す
In the above examples some communities have been defined. The community object itself will take the following format:
上記の例には、定義された共同体もありました。 共同体物自体は以下の形式を取るでしょう:
Example:
例:
community: SURFNET descr: Dutch academic research network authority: SURFnet B.V. guardian: comm-guardian@surfnet.nl admin-c: Erik-Jan Bos tech-c: Erik-Jan Bos changed: ripe-dbm@ripe.net 920604 source: RIPE
共同体: SURFNET descr: オランダの学問研究ネットワーク権威: SURFnet B.V.保護者: comm-guardian@surfnet.nl アドミンc: エリック-1月のボスの科学技術のc: エリック-ジャン・ボスは変化しました: ripe-dbm@ripe.net 920604ソース: 熟す
For a complete explanation of the syntax please refer to Appendix B.
構文に関する完璧な説明について、Appendix Bを参照してください。
Bates, et al. [Page 40] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [40ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
9. Representation of Routing Policies
9. ルート設定方針の表現
Routing policies of an AS are represented in the autonomous system object. Initially we show some examples, so the reader is familiar with the concept of how routing information is represented, used and derived. Refer to Appendix A, for the full syntax of the "aut-num" object.
ASのルート設定方針は自律システム物に表されます。 初めは私たちがいくつかの例を示しているので、読者はルーティング情報がどう表されて、使用されて、引き出されるかに関する概念に詳しいです。 "aut-num"物の完全な構文についてAppendix Aを参照してください。
The topology of routing exchanges is represented by listing how routing information is exchanged with each neighboring AS. This is done separately for both incoming and outgoing routing information. In order to provide backup and back door paths a relative cost is associated with incoming routing information.
ルーティング交換のトポロジーは、それぞれの隣接しているASと共にルーティング情報をどう交換するかを記載することによって、表されます。 ともに送受信のルーティング情報のために別々にこれをします。 バックアップと裏口経路に親類を供給するために、費用は入って来るルーティング情報に関連しています。
Example 1:
例1:
AS1------AS2
AS1------AS2
This specifies a simple routing exchange of two presumably isolated ASes. Even if either of them has routing information about routes in ASes other than AS1 and AS2, none of that will be announced to the other.
これは2おそらく孤立しているASesの簡単なルーティング交換を指定します。 いずれか一方にAS1とAS2以外のASesのルートのルーティング情報があっても、そのいずれももう片方に発表されないでしょう。
aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2
aut-num: AS1、アウトとして: AS2に、コネとしてAS1を発表してください: AS2 100から、AS2を受け入れてください。
aut-num: AS2 as-out: to AS1 announce AS2 as-in: from AS1 100 accept AS1
aut-num: AS2、アウトとして: AS1に、コネとしてAS2を発表してください: AS1 100から、AS1を受け入れてください。
The number 100 in the in-bound specifications is a relative cost, which is used for backup and back door routes. The absolute value is of no significance. The relation between different values within the same AS object is. A lower value means a lower cost. This is consciously similar to the cost based preference scheme used with DNS MX RRs.
行きの仕様によるNo.100は相対コストです。(その相対コストはバックアップと裏口ルートに使用されます)。 絶対値は意味の全くものではありません。 同じAS物の中の異価の関係はそうです。 下側の値は低い費用を意味します。 これは意識してベースの好みの計画がDNS MX RRsと共に使用した費用と同様です。
Example 2:
例2:
Now suppose that AS2 is connected to one more AS, besides AS1, and let's call that AS3:
今度は、AS2がAS1以外にもうひとつのASに接続されると仮定してください、そして、それをAS3と呼びましょう:
Bates, et al. [Page 41] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [41ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
AS1------AS2------AS3
AS1------AS2------AS3
In this case there are two reasonable routing policies:
この場合、2つの合理的なルーティング方針があります:
a) AS2 just wants to exchange traffic with both AS1 and AS3 itself
without passing traffic between AS1 and AS3.
a) AS2はAS1とAS3の間の交通なしでAS1とAS3自身の両方と交通をただ交換したがっています。
b) AS2 is willing to pass traffic between AS3 and AS1, thus acting
as a transit AS
b) AS2は、AS3とAS1の間の交通を通り過ぎても構わないと思っていて、その結果、トランジットASとして機能します。
Example 2a:
例の2a:
In the first case AS1's representation in the routing registry will remain unchanged as will be the part of AS2's representation describing the routing exchange with AS1. A description of the additional routing exchange with AS3 will be added to AS2's representation:
ルーティング登録の前者の場合AS1の表現はルーティングについて説明するAS2の表現の部分がAS1との交換であるつもりであったなら変わりがないままで残るでしょう。 AS3との追加ルーティング交換の記述はAS2の表現に追加されるでしょう:
aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2
aut-num: AS1、アウトとして: AS2に、コネとしてAS1を発表してください: AS2 100から、AS2を受け入れてください。
aut-num: AS2 as-out: to AS1 announce AS2 as-in: from AS1 100 accept AS1 as-out: to AS3 announce AS2 as-in: from AS3 100 accept AS3
aut-num: AS2、アウトとして: AS1に、コネとしてAS2を発表してください: AS1 100から、アウトとしてAS1を認めてください: AS3に、コネとしてAS2を発表してください: AS3 100から、AS3を受け入れてください。
aut-num: AS3 as-out: to AS2 announce AS3 as-in: from AS2 100 accept AS2
aut-num: AS3、アウトとして: AS2に、コネとしてAS3を発表してください: AS2 100から、AS2を受け入れてください。
Note that in this example, AS2 keeps full control over its resources. Even if AS3 and AS1 were to allow each others routes in from AS2, the routing information would not flow because AS2 is not announcing it. Of course AS1 and AS3 could just send traffic to each other to AS2 even without AS2 announcing the routes, hoping that AS2 will forward it correctly. Such questionable practices however are beyond the scope of this document.
この例では、AS2がリソースの完全なコントロールを保つことに注意してください。 AS3とAS1がそれぞれを許容したとしてもさえ、AS2からの中の他のものルートであり、AS2がそれを発表していないので、ルーティング情報は流れないでしょうに。 もちろん、AS2がルートを発表さえしないで、AS1とAS3はただ互いに交通をAS2に送ることができました、AS2が正しくそれを進めることを望んでいて。 しかしながら、そのような疑わしい習慣はこのドキュメントの範囲を超えています。
Bates, et al. [Page 42] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [42ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 2b:
例の2b:
If contrary to the previous case, AS1 and AS3 are supposed to have connectivity to each other via AS2, all AS objects have to change:
AS1とAS3が先の事件とは逆にAS2を通して互いに接続性を持つべきであるなら、すべてのAS物が変化しなければなりません:
aut-num: AS1 as-out: to AS2 announce AS1 as-in: from AS2 100 accept AS2 AS3
aut-num: AS1、アウトとして: AS2に、コネとしてAS1を発表してください: AS2 100から、AS2 AS3を受け入れてください。
aut-num: AS2 as-out: to AS1 announce AS2 AS3 as-in: from AS1 100 accept AS1 as-out: to AS3 announce AS2 AS1 as-in: from AS3 100 accept AS3
aut-num: AS2、アウトとして: AS1に、コネとしてAS2 AS3を発表してください: AS1 100から、アウトとしてAS1を認めてください: AS3に、コネとしてAS2 AS1を発表してください: AS3 100から、AS3を受け入れてください。
aut-num: AS3 as-out: to AS2 announce AS3 as-in: from AS2 100 accept AS1 AS2
aut-num: AS3、アウトとして: AS2に、コネとしてAS3を発表してください: AS2 100から、AS1 AS2を受け入れてください。
Note that the amount of routing information exchanged with a neighbor AS is defined in terms of routes belonging to ASes. In BGP terms this is the AS where the routing information originates and the originating AS information carried in BGP could be used to implement the desired policy. However, using BGP or the BGP AS-path information is not required to implement the policies thus specified. Configurations based on route lists can easily be generated from the database. The AS path information, provided by BGP can then be used as an additional checking tool as desired.
隣人ASと共に交換されたルーティング情報の量がASesに属すルートで定義されることに注意してください。 BGP用語で、これはルーティング情報が由来するASです、そして、必要な政策を実施するのにBGPで運ばれた由来しているAS情報は使用できました。 しかしながら、BGPかBGP AS-経路情報を使用するのは、このようにして指定された政策を実施するのに必要ではありません。 ルートリストに基づく構成はデータベースから容易に発生できます。 そして、必要な追加照合同じくらいツールとしてBGPによってAS経路情報であって、提供を使用できます。
The specification understands one special expression and this can be expressed as a boolean expression:
仕様は1つの特別な表現を理解しています、そして、論理演算子表現としてこれは言い表すことができます:
ANY - means any routing information known. For output this means that
all routes an AS knows about are announced. For input it means
that anything is accepted from the neighbor AS.
いずれ--知られているどんなルーティング情報も意味します。 出力のために、これは、ASが知っているすべてのルートが発表されることを意味します。 入力のために、それは、何でも隣人ASから受け入れられることを意味します。
Bates, et al. [Page 43] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [43ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 3:
例3:
AS4 is a stub customer AS, which only talks to service provider AS123.
AS4はスタッブ顧客ASです。(そのASはサービスプロバイダーAS123と話すだけです)。
|
|
-----AS123------AS4
|
|
| | -----AS123------AS4| |
aut-num: AS4 as-out: to AS123 announce AS4 as-in: from AS123 100 accept ANY
aut-num: AS4、アウトとして: AS123に、コネとしてAS4を発表してください: AS123 100から、何でも受け入れてください。
aut-num: AS123 as-in: from AS4 100 accept AS4 as-out: to AS4 announce ANY <further neighbors>
aut-num: AS123、コネとして: AS4 100から、アウトとしてAS4を認めてください: AS4に、あらゆる<の、より遠い隣人>を発表してください。
Since AS4 has no other way to reach the outside world than AS123 it is not strictly necessary for AS123 to send routing information to AS4. AS4 can simply send all traffic for which it has no explicit routing information to AS123 by default. This strategy is called default routing. It is expressed in the routing registry by adding one or more default tags to the autonomous system which uses this strategy. In the example above this would look like:
AS4にはAS123以外の外の世界に達する方法が全くないので、AS123がルーティング情報をAS4に送るのは厳密に必要ではありません。 AS4は単に、それがデフォルトでどんな明白なルーティング情報もAS123に持っていないすべての交通を送ることができます。 この戦略はデフォルトルーティングと呼ばれます。 ルーティング登録では、1個以上のデフォルトタグを自律システムに加えることによって、どれがこの戦略を使用するかは言い表されます。 例では、上では、これに似ているでしょう:
aut-num: AS4 as-out: to AS123 announce AS4 default: AS123 100
aut-num: AS4、アウトとして: AS123に、AS4デフォルトを発表してください: AS123 100
aut-num: AS123 as-in: from AS4 100 accept AS4 <further neighbors>
aut-num: AS123、コネとして: AS4 100から、AS4の<の、より遠い隣人>を受け入れてください。
Bates, et al. [Page 44] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [44ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 4:
例4:
AS4 now connects to a different operator, AS5. AS5 uses AS123 for outside connectivity but has itself no direct connection to AS123. AS5 traffic to and from AS123 thus has to pass AS4. AS4 agrees to act as a transit AS for this traffic.
AS4は現在、異なったオペレータ、AS5に接続します。 AS5自身は外の接続性にAS123を使用しますが、AS123にはどんなダイレクト接続もいません。 その結果、AS123とAS123からのAS5交通はAS4を渡さなければなりません。 AS4は、この交通へのトランジットASとして機能するのに同意します。
|
|
-----AS123------AS4-------AS5
|
|
| | -----AS123------AS4-------AS5| |
aut-num: AS4 as-out: to AS123 announce AS4 AS5 as-in: from AS123 100 accept ANY as-out: to AS5 announce ANY as-in: from AS5 50 accept AS5
aut-num: AS4、アウトとして: AS123に、コネとしてAS4 AS5を発表してください: AS123 100から、アウトとして何でも受け入れてください: AS5に、コネとして何でも発表してください: AS5 50から、AS5を受け入れてください。
aut-num: AS5 as-in: from AS4 100 accept ANY as-out: to AS4 announce AS5
aut-num: AS5、コネとして: AS4 100から、アウトとして何でも受け入れてください: AS4に、AS5を発表してください。
aut-num: AS123 as-in: from AS4 100 accept AS4 AS5 as-out: to AS4 announce ANY <further neighbors>
aut-num: AS123、コネとして: AS4 100から、アウトとしてAS4 AS5を認めてください: AS4に、あらゆる<の、より遠い隣人>を発表してください。
Now AS4 has two sources of external routing information. AS5 which provides only information about its own routes and AS123 which provides information about the external world. Note that AS4 accepts information about AS5 from both AS123 and AS5 although AS5 information cannot come from AS123 since AS5 is connected only via AS4 itself. The lower cost of 50 for the announcement from AS5 itself compared to 100 from AS123 ensures that AS5 is still believed even in case AS123 will unexpectedly announce AS5.
今、AS4には、外部のルーティング情報の2つの源があります。 それ自身のルートの情報だけを提供するAS5と外界の情報を提供するAS123。 AS5がAS4自身を通してだけ接続されるのでAS5情報がAS123から来ることができませんが、AS4がAS123とAS5の両方からAS5の情報を受け入れることに注意してください。 AS5自身からの発表がAS123から100と比較されたので、50の低い費用は、AS123が不意にAS5を発表さえするといけなくて、AS5がまだ信じられているのを確実にします。
In this example too, default routing can be used by AS5 much like in the previous example. AS4 can also use default routing towards AS123:
この例でも、前の例などのようなAS5はデフォルトルーティングを使用できます。 また、AS4はAS123に向かってデフォルトルーティングを使用できます:
Bates, et al. [Page 45] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [45ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
aut-num: AS4 as-out: to AS123 announce AS4 AS5 default: AS123 11 as-in: from AS5 50 accept AS5
aut-num: AS4、アウトとして: AS123に、AS4 AS5デフォルトを発表してください: AS123、11 コネとして: AS5 50から、AS5を受け入れてください。
Note no announcements to AS5, they default to us.
発表に全くAS5に注意しないでください、そして、それらは私たちをデフォルトとします。
aut-num: AS5 as-out: to AS4 announce AS5 default: AS4 100
aut-num: AS5、アウトとして: AS4に、AS5デフォルトを発表してください: AS4 100
aut-num: AS123 as-in: from AS4 100 announce AS4 AS5 <further neighbors>
aut-num: AS123、コネとして: AS4 100から、AS4 AS5の<の、より遠い隣人>を発表してください。
Note that the relative cost associated with default routing is totally separate from the relative cost associated with in-bound announcements. The default route will never be taken if an explicit route is known to the destination. Thus an explicit route can never have a higher cost than the default route. The relative cost associated with the default route is only useful in those cases where one wants to configure multiple default routes for redundancy.
デフォルトルーティングに関連している相対コストが行きでの発表に関連している相対コストから完全に別々であることに注意してください。 明白なルートを目的地に知っていると、デフォルトルートを決して取らないでしょう。 したがって、明白なルートはデフォルトルートより高い費用を決して持つことができません。 デフォルトルートに関連している相対コストは1つが冗長のために複数のデフォルトルートを構成したがっているそれらの場合だけで役に立ちます。
Note also that in this example the configuration using default routes has a subtly different behavior than the one with explicit routes: In case the AS4-AS5 link fails AS4 will send traffic to AS5 to AS123 when using the default configuration. Normally this makes not much difference as there will be no answer and thus little traffic. With certain datagram applications which do not require acknowledgments however, significant amounts of traffic may be uselessly directed at AS123. Similarly default routing should not be used if there are stringent security policies which prescribe any traffic intended for AS5 to ever touch AS123.
また、この例では、デフォルトルートを使用する構成がかすかに明白なルートがあるものと異なった振舞いを持っていることに注意してください: AS4-AS5リンクが失敗するといけないので、デフォルト設定を使用するとき、AS4はAS123へのAS5に交通を送るでしょう。 通常、交通が答えがではなくその結果、少ししかないので、これにそれほど多くなく効果があります。 しかしながら、承認を必要としないあるデータグラムアプリケーションで、AS123は無益にかなりの量の交通に向けられるかもしれません。 同様に、AS5がAS123に触れることを意図するどんな交通も定める厳しい安全保障政策があれば、デフォルトルーティングを使用するべきではありません。
Once the situation gets more complex using default routes can lead to unexpected results or even defeat the routing policies established when links fail. As an example consider how Example 5a) below could be implemented using default routing. Therefore, generally it can be said that default routing should only be used in very simple topologies.
状況がデフォルトを使用することでいったんより複雑になると、ルートは予期しなかった結果かリンクが失敗するときルーティング方針が確立した敗北にさえつながることができます。 例として、デフォルトルーティングを使用することでどうしたら以下のExample 5a)を実行できるだろうか考えてください。 したがって、一般に言われていて、そのデフォルトルーティングが非常に簡単なtopologiesで使用されるだけであるべきであるということであるかもしれません。
Bates, et al. [Page 46] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [46ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 5:
例5:
In a different example AS4 has a private connection to AS6 which in turn is connected to the service provider AS123:
異なった例に、順番にサービスプロバイダーAS123に接続されるAS6にはAS4が個人的な接続がいます:
|
|
-----AS123------AS4
| |
| |
| |
AS6 ---------+
| | -----AS123------AS4| | | | | | AS6---------+
There are a number of policies worth examining in this case:
この場合調べる価値がある多くの方針があります:
a) AS4 and AS6 wish to exchange traffic between themselves
exclusively via the private link between themselves; such
traffic should never pass through the backbone (AS123). The
link should never be used for transit traffic, i.e. traffic not
both originating in and destined for AS4 and AS6.
a) AS4とAS6は排他的に自分たちの間の個人的なリンクを通して自分たちの間の交通を交換したがっています。 そのような交通は背骨(AS123)を決して、通り抜けるべきではありません。 リンクはトランジット交通(すなわち、AS4とAS6のために由来して、運命づけられない交通)に決して使用されるべきではありません。
b) AS4 and AS6 wish to exchange traffic between themselves via the
private link between themselves. Should the link fail, traffic
between AS4 and AS6 should be routed via AS123. The link should
never be used for transit traffic.
b) AS4とAS6は自分たちの間の個人的なリンクを通して自分たちの間の交通を交換したがっています。 リンクが失敗するはずであるなら、AS4とAS6の間の交通はAS123を通して発送されるべきです。 リンクはトランジット交通に決して使用されるべきではありません。
c) AS4 and AS6 wish to exchange traffic between themselves via the
private link between themselves. Should the link fail, traffic
between AS4 and AS6 should be routed via AS123. Should the
connection between AS4 and AS123 fail, traffic from AS4 to
destinations behind AS123 can pass through the private link and
AS6's connection to AS123.
c) AS4とAS6は自分たちの間の個人的なリンクを通して自分たちの間の交通を交換したがっています。 リンクが失敗するはずであるなら、AS4とAS6の間の交通はAS123を通して発送されるべきです。 AS4とAS123との接続が失敗するなら、AS123の後ろのAS4から目的地までの交通は個人的なリンクとAS6の接続をAS123に通り抜けることができます。
d) AS4 and AS6 wish to exchange traffic between themselves via the
private link between themselves. Should the link fail, traffic
between AS4 and AS6 should be routed via AS123. Should the
backbone connection of either AS4 or AS6 fail, the traffic of
the disconnected AS should flow via the other AS's backbone
connection.
d) AS4とAS6は自分たちの間の個人的なリンクを通して自分たちの間の交通を交換したがっています。 リンクが失敗するはずであるなら、AS4とAS6の間の交通はAS123を通して発送されるべきです。 AS4かAS6のどちらかの背骨接続が失敗するなら、外されたASの交通はもう片方のASの背骨接続で流れるべきです。
Bates, et al. [Page 47] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [47ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 5a:
例の5a:
aut-num: AS4 as-in: from AS123 100 accept NOT AS6 as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-out: to AS6 announce AS4
aut-num: AS4、コネとして: AS123 100から、アウトとしてNOT AS6を認めてください: AS123に、コネとしてAS4を発表してください: AS6 50から、アウトとしてAS6を認めてください: AS6に、AS4を発表してください。
aut-num: AS123 as-in: from AS4 100 accept AS4 as-out: to AS4 announce ANY as-in: from AS6 100 accept AS6 as-out: to AS6 announce ANY <further neighbors>
aut-num: AS123、コネとして: AS4 100から、アウトとしてAS4を認めてください: AS4に、コネとして何でも発表してください: AS6 100から、アウトとしてAS6を認めてください: AS6に、あらゆる<の、より遠い隣人>を発表してください。
aut-num: AS6 as-in: from AS123 100 accept NOT AS4 as-out: to AS123 announce AS6 as-in: from AS4 50 accept AS4 as-out: to AS4 announce AS6
aut-num: AS6、コネとして: AS123 100から、アウトとしてNOT AS4を認めてください: AS123に、コネとしてAS6を発表してください: AS4 50から、アウトとしてAS4を認めてください: AS4に、AS6を発表してください。
Note that here the configuration is slightly inconsistent. AS123 will announce AS6 to AS4 and AS4 to AS6. These announcements will be filtered out on the receiving end. This will implement the desired policy. Consistency checking tools might flag these cases however.
ここで、構成がわずかに矛盾していることに注意してください。 AS123はAS4へのAS6とAS6へのAS4を発表するでしょう。 これらの発表は受ける側になって無視されるでしょう。 これは必要な政策を実施するでしょう。 しかしながら、ツールをチェックする一貫性はこれらのケースに旗を揚げさせるかもしれません。
Bates, et al. [Page 48] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [48ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 5b:
例の5b:
aut-num: AS4 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-out: AS6 AS4
aut-num: AS4、コネとして: AS123 100から、アウトとして何でも受け入れてください: AS123に、コネとしてAS4を発表してください: AS6 50から、アウトとしてAS6を認めてください: AS6 AS4
aut-num: AS123 as-in: AS4 100 AS4 as-out: AS4 ANY as-in: AS6 100 AS6 as-out: AS6 ANY <further neighbors>
aut-num: AS123、コネとして: AS4 100AS4、アウトとして: AS4 ANY、コネとして: AS6 100AS6、アウトとして: AS6 ANYの<の、より遠い隣人>。
aut-num: AS6 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS6 as-in: from AS4 50 accept AS4 as-out: to AS4 announce AS6
aut-num: AS6、コネとして: AS123 100から、アウトとして何でも受け入れてください: AS123に、コネとしてAS6を発表してください: AS4 50から、アウトとしてAS4を認めてください: AS4に、AS6を発表してください。
The thing to note here is that in the ideal operational case, `all links working' AS4 will receive announcements for AS6 from both AS123 and AS6 itself. In this case the announcement from AS6 will be preferred because of its lower cost and thus the private link will be used as desired. AS6 is configured as a mirror image.
ここで注意することは'理想的な操作上の場合では、'AS4を扱うすべてのリンクがAS6のためにAS123とAS6自身の両方から発表を受けるということです。 この場合AS6からの発表は低い費用のために好まれるでしょう、そして、その結果、個人的なリンクは望まれているように使用されるでしょう。 AS6は鏡像として構成されます。
Bates, et al. [Page 49] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [49ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example 5c:
例の5c:
The new feature here is that should the connection between AS4 and AS123 fail, traffic from AS4 to destinations behind AS123 can pass through the private link and AS6's connection to AS123.
ここの新機能はAS4とAS123との接続が失敗するなら、AS123の後ろのAS4から目的地までの交通が個人的なリンクとAS6の接続をAS123に通り抜けることができるということです。
aut-num: AS4 as-in: from AS123 100 accept ANY as-out: to AS123 announce AS4 as-in: from AS6 50 accept AS6 as-in: from AS6 110 accept ANY as-out: to AS6 AS4
aut-num: AS4、コネとして: AS123 100から、アウトとして何でも受け入れてください: AS123に、コネとしてAS4を発表してください: AS6 50から、コネとしてAS6を認めてください: AS6 110から、アウトとして何でも受け入れてください: AS6 AS4に
aut-num: AS123 as-in: from AS4 1 accept AS4 as-out: to AS4 announce ANY as-in: from AS6 1 accept AS6 as-in: from AS6 2 accept AS4 as-out: to AS6 announce ANY <further neighbors>
aut-num: AS123、コネとして: AS4 1から、アウトとしてAS4を認めてください: AS4に、コネとして何でも発表してください: AS6 1から、コネとしてAS6を認めてください: AS6 2から、アウトとしてAS4を認めてください: AS6に、あらゆる<の、より遠い隣人>を発表してください。
aut-num: AS6 as-in: from AS123 100 accept ANY as-out: to AS123 AS6 announce AS4 as-in: from AS4 50 accept AS4 as-out: to AS4 announce ANY
aut-num: AS6、コネとして: AS123 100から、アウトとして何でも受け入れてください: AS123 AS6に、コネとしてAS4を発表してください: AS4 50から、アウトとしてAS4を認めてください: AS4に、何でも発表してください。
Note that it is important to make sure to propagate routing information for both directions in backup situations like this. Connectivity in just one direction is not useful at all for almost all applications.
このようなバックアップ状況の両方の指示のためのルーティング情報を伝播するのを確実にするのが重要であることに注意してください。 まさしく一方向への接続性は全くほとんどすべてのアプリケーションの役に立ちません。
Note also that in case the AS6-AS123 connection breaks, AS6 will only be able to talk to AS4. The symmetrical case (5d) is left as an exercise to the reader.
また、AS6-AS123接続が中断しているといけないのでAS6がAS4と話すことができるだけであることに注意してください。 対称のケース(5d)は運動として読者に任せます。
10. Future Extensions
10. 今後の拡大
We envision that over time the requirements for describing routing policy will evolve. The routing protocols will evolve to support the requirements and the routing policy description syntax will need to evolve as well. For that purpose, a separate document will describe experimental syntax definitions for policy description. This document [14] will be updated when new objects or attributes are proposed or modified.
私たちは方針を発送すると説明するための要件が発展する時、それを思い描きます。 ルーティング・プロトコルは要件を支持するために発展するでしょう、そして、ルーティング方針記述構文はまた、発展する必要があるでしょう。 そのために、別々のドキュメントは方針記述のための実験的な構文定義について説明するでしょう。 新しい物か属性を提案するか、または変更するとき、このドキュメント[14]をアップデートするでしょう。
Bates, et al. [Page 50] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [50ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
11. References
11. 参照
[1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P.,
Terpstra, M., "Representation of IP Routing Policies in the RIPE
Database", RIPE-81, February 1993.
[1] ベイツ、T.、Jouanigot、J-M.、Karrenberg、D.、Lothberg、P.、テルプストラ、M.、「熟しているデータベースにおける、IPルート設定方針の表現」、熟している81、1993年2月。
[2] Merit Network Inc.,"Representation of Complex Routing Policies
of an Autonomous System", Work in Progress, March 1994.
[2] 長所ネットワーク株式会社、「自律システムの複雑なルート設定方針の表現」は進歩、1994年3月に働いています。
[3] PRIDE Tools Release 1.
See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z.
[3] プライドツールは1をリリースします。 ftp.ripe.netを見てください: プライドツールプライド/ツール/1.tar.Z。
[4] Merit Inc. RRDB Tools.
See rrdb.merit.edu:pub/meritrr/*
[4] 株式会社RRDBツールに値してください。 rrdb.merit.eduを見てください: pub/meritrr/*
[5] The Network List Compiler.
See dxcoms.cern.ch:pub/ripe-routing-wg/nlc-2.2d.tar
[5] ネットワークリストコンパイラ。 dxcoms.cern.ch: 熟しているルーティングwg/nlc-2.2d.パブ/タールを見てください。
[6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and
Persons", RIPE-119, October 1994.
[6] 主、A.、テルプストラ、M.、「ネットワークと人々のための熟しているデータベーステンプレート」、熟している-119、1994年10月。
[7] Karrenberg, D., "RIPE Database Template for Domains", RIPE-49,
April 1992.
[7]Karrenberg、D.、「ドメインへの熟しているデータベーステンプレート」、熟している-49、1992年4月。
[8] Lougheed, K., Rekhter, Y., "A Border Gateway Protocol 3 (BGP-
3)", RFC1267, October 1991.
1991年10月の[8] ロッキード、K.、Rekhter、Y.、「ボーダ・ゲイトウェイ・プロトコル3(BGP3)」RFC1267。
[9] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC-1654, May 1994.
[9] Rekhter(Y.、李、T.、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」RFC-1654)は1994がそうするかもしれません。
[10] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless
Internet Addresses in the RIPE Database", RIPE-121, October
1994.
[10] ベイツ、T.、Karrenberg、D.、テルプストラ、M.、「熟しているデータベースの階級のないインターネットアドレスのサポート」、熟している121、1994年10月。
[11] Karrenberg, D., "Authorisation and Notification of Changes in
the RIPE Database", RIPE-120, October 1994.
[11]Karrenbergと、D.と、熟している120の「熟しているデータベースにおける変化の認可と通知」、10月1994日
[12] Bates, T., "Support of Guarded fields within the RIPE Database",
ripe-117, July 1994.
[12] ベイツ、T.、「RIPE Databaseの中のGuarded分野のサポート」、熟している117、1994年7月。
[13] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., Zappala, D.,
"Source Demand Routing: Packet Format and Forwarding
Specification (Version 1)", Work in Progress, March 1994.
[13]Estrin、D.、李、T.、Rekhter、Y.、Varadhan、K.、Zappala、D.、「以下を掘るソース要求」 「パケット・フォーマットと推進仕様(バージョン1)」は進歩、1994年3月に働いています。
[14] Joncheray, L., "Experimental Objects and attributes for the
Routing Registry", RIPE-182, October1994.
[14]Joncherayと、L.と、「ルート設定Registryのための実験的なObjectsと属性」、RIPE-182、October1994。
[15] Bates, T., "Specifying an `Internet Router' in the Routing
[15] ベイツ、「ルート設定における'インターネットルータ'を指定する」T.
Bates, et al. [Page 51] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [51ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Registry", RIPE-122, October 1994.
「登録」、熟している122、1994年10月。
[16] Bates, T., Karrenberg, D., Terpstra, M., "RIPE Database
Transition Plan", RIPE-123, October 1994.
[16] ベイツ、T.、Karrenberg、D.、テルプストラ、M.、「熟しているデータベース変遷プラン」、熟している-123、1994年10月。
12. Security Considerations
12. セキュリティ問題
Security issues are beyond the scope of this memo.
安全保障問題はこのメモの範囲を超えています。
Bates, et al. [Page 52] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [52ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
13. Authors' Addresses
13. 作者のアドレス
Tony Bates MCI Telecommunications Corporation 2100 Reston Parkway Reston, VA 22094 USA +1 703 715 7521 Tony.Bates@mci.net
トニーベイツMCIテレコミュニケーション社2100のレストンParkwayヴァージニア22094レストン(米国)+1 703 715 7521 Tony.Bates@mci.net
Elise Gerich The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2120 epg@merit.edu
エリーズGerichミシガン大学長所コンピュータネットワーク1075ビール・Avenue MI48109アナーバー(米国)+1 313 936 2120 epg@merit.edu
Laurent Joncheray The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2065 lpj@merit.edu
ローランJoncherayミシガン大学長所コンピュータネットワーク1075ビール・Avenue MI48109アナーバー(米国)+1 313 936 2065 lpj@merit.edu
Jean-Michel Jouanigot CERN, European Laboratory for Particle Physics CH-1211 Geneva 23 Switzerland +41 22 767 4417 Jean-Michel.Jouanigot@cern.ch
ジャンミッシェルJouanigot CERN、欧州原子核共同研究機構CH-1211ジュネーブ23スイス+41 22、767、4417 Jean-Michel.Jouanigot@cern.ch
Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 NL-1098 SJ Amsterdam The Netherlands +31 20 592 5065 D.Karrenberg@ripe.net
ダニエル・Karrenbergの熟しているネットワークコーディネートセンターKruislaan409NL-1098 SJアムステルダムオランダ+31、20、592、5065 D.Karrenberg@ripe.net
Bates, et al. [Page 53] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [53ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Marten Terpstra Bay Networks, Inc. 2 Federal St Billerica, MA 01821 USA +1 508 436 8036 marten@BayNetworks.com
テンテルプストラベイネットワークスInc.2の連邦政府のSt MA01821ビルリカ(米国)+1 508 436の8036 marten@BayNetworks.com
Jessica Yu The University of Michigan Merit Computer Network 1075 Beal Avenue Ann Arbor, MI 48109 USA +1 313 936 2655 jyy@merit.edu
ミシガン長所コンピュータネットワーク1075ビール・Avenue MI48109アナーバー(米国)+1 313 936 2655 jyy@merit.edu のジェシカ・ユー大学
Bates, et al. [Page 54] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [54ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix A - Syntax for the aut-num object.
付録A--aut-num物のための構文。
Here is a summary of the tags associated with aut-num object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the aut-num object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute.
ここに、aut-num物自体とそれらの状態に関連しているタグの概要があります。 この属性がaut-num物で義務的であるか否かに関係なく、最初のコラムが属性、第2コラムを指定して、この詳細が缶を結果と考えるか否かに関係なく、第3コラムは一度[複数の]より物[シングル]に一度だけ現れます。 複数の1属性あたりの線を指定するとき、属性名を繰り返さなければなりません。 [6] descrのための例を見てください: 結果と考えます。
aut-num: [mandatory] [single] as-name: [optional] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] guardian: [mandatory] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single]
aut-num: [義務的な] [単一の] 名前として: [任意][単一の]のdescr: [義務的な] [複数の] コネとして: [任意の] [複数の] アウトとして: 中の[任意][複数の]のinteras: 外の[任意][複数の]のinteras: [任意]の[倍数]、-、除外、: [任意の] [複数]のデフォルト: [任意の] [複数の] 科学技術のc: [義務的な] [複数]のアドミンc: [義務的な] [複数]の保護者: [義務的][単一の]の所見: [任意の] [複数の] 通知します: 近く[任意][複数の]のmnt: [任意]の[倍数]は変化しました: [義務的な] [複数]のソース: [義務的]です。[単一]です。
Each attribute has the following syntax:
各属性に、以下の構文があります:
aut-num:
The autonomous system number. This must be a uniquely allocated
autonomous system number from an AS registry (i.e. the RIPE NCC,
the Inter-NIC, etc).
aut-num: 自律システム番号。 これはAS登録(すなわち、RIPE NCC、Inter-NICなど)からの唯一割り当てられた自律システム番号であるに違いありません。
Format:
AS<positive integer between 1 and 65535>
形式: 1〜65535のAS<正の整数>。
Example:
例:
aut-num: AS1104
aut-num: AS1104
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 55] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [55ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
as-name:
The name associated with this AS. This should as short but as
informative as possible.
名前として: このASに関連している名前。 これは短いのですが、できるだけ有益であるとしてそうするべきです。
Format:
Text consisting of capitals, dashes ("-") and digits, but must
start with a capital.
形式: 首都から始まらなければならないのを除いた首都、ダッシュ(「-」)、およびケタから成るテキスト。
Example:
例:
as-name: NIKHEF-H
名前として: NIKHEF-H
Status: single, only one line allowed
状態: シングル、許容された1つの線だけ
descr:
A short description of the Autonomous System.
descr: Autonomous Systemの短い記述。
Format:
free text
形式: 無料のテキスト
Example:
例:
descr: NIKHEF section H
descr: Science Park Watergraafsmeer
descr: Amsterdam
descr: NIKHEF部Hのdescr: サイエンスパークWatergraafsmeer descr: アムステルダム
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
as-in:
A description of accepted routing information between AS peers.
コネとして: ASの間の受け入れられたルーティング情報の記述はじっと見ます。
Format:
from <aut-num> <cost> accept <routing policy expression>
形式: <aut-num><費用>から、<ルーティング方針表現>を受け入れてください。
The keywords from and accept are optional and can be omitted.
受け入れてください。そして、キーワード、任意であり、省略できます。
<aut-num> refers to your AS neighbor.
<aut-num>はあなたのAS隣人について言及します。
<cost> is a positive integer used to express a relative cost
of routes learned. The lower the cost the more preferred the
route.
<費用>は学習されたルートの相対コストを言い表すのに使用される正の整数です。 低い..費用..以上..都合のよい..ルート
<routing policy expression> can take the following formats.
<ルーティング方針表現>は以下の形式を取ることができます。
1. A list of one or more ASes, AS Macros, Communities or
Route Lists.
1. 1ASes、AS Macros、CommunitiesまたはRoute Listsのリスト。
A Route List is a list of routes in prefix length format,
Route Listは接頭語長さの形式におけるルートのリストです。
Bates, et al. [Page 56] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [56ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
separated by commas, and surrounded by curly brackets
(braces, i.e. `{' and '}').
コンマによって切り離されて、ブレースによって囲まれる、(すなわち、用意する、'、''}'、)
Examples:
例:
as-in: from AS1103 100 accept AS1103
as-in: from AS786 105 accept AS1103
as-in: from AS786 10 accept AS786 HEPNET
as-in: from AS1755 110 accept AS1103 AS786
as-in: from AS3333 100 accept {192.87.45.0/16}
コネとして: AS1103 100から、コネとしてAS1103を認めてください: AS786 105から、コネとしてAS1103を認めてください: AS786 10から、コネとしてAS786 HEPNETを認めてください: AS1755 110から、コネとしてAS1103 AS786を認めてください: AS3333 100から、受け入れてください。{192.87.45.0/16}
2. A set of KEYWORDS. The following KEYWORD is currently
defined:
2. KEYWORDSの1セット。 以下のKEYWORDは現在、定義されます:
ANY this means anything the neighbor AS knows.
少しも、これは隣人ASが知ることを意味します。
3. A logical expression of either 1 or 2 above The current
logical operators are defined as:
3. 1か現在の論理演算子より高い2が定義されるどちらかの論理式:
AND
OR
NOT
AND OR NOT
This operators are defined as true BOOLEAN operators even
if the operands themselves do not appear to be BOOLEAN.
Their operations are defined as follows:
オペランド自体がブールであるように見えないでも、このオペレータは本当の論理演算子と定義されます。 彼らの操作は以下の通り定義されます:
Operator Operation Example
オペレータ操作の例
OR UNION AS1 OR AS2
|
+-> all routes in AS1
or AS2.
または、組合AS1かAS2| すべてがAS1かAS2で発送する+->。
AND INTERSECTION AS1 AND HEPNET
|
+-> a route in AS1 and
belonging to
community HEPNET.
ANDの交差点AS1とHEPNET| +->aは、共同体HEPNETにAS1で発送して、属します。
NOT COMPLEMENT NOT AS3
|
+-> any route except
AS3 routes.
補数AS3| AS3ルートを除いて、いずれも発送する+->。
Bates, et al. [Page 57] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [57ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Rules are grouped together using parenthesis i.e "(" and
")".
そして、規則が挿入句i.eを使用することで一緒に分類される、「(「」、)、」
The ordering of evaluation of operators and there
association is as follows:
そこでオペレータの評価を注文して、協会は以下の通りです:
Operator Associativity
オペレータ会合性
() left to right
NOT right to left
AND left to right
OR left to right
()は権利ではなく、右まで残っている正しいORまで残っている左のANDへの右まで残っています。
NOTE: if no logical operator is given between ASes, AS-
macros, Communities, Route Lists and KEYWORDS it is
implicitly evaluated as an `OR' operation. The OR can be
left out for conciseness. However, please note the
operators are still evaluated as below so make sure you
include parentheses whenever needed. To highlight this
here is a simple example. If we denoted a policy of for
example; from AS1755 I accept all routes except routes
from AS1, A2 and AS3 and you enter the following as-in
line.
以下に注意してください。 ASesと、ASマクロと、Communitiesと、Route ListsとKEYWORDSの間に論理演算子を全く与えないなら、'OR'操作としてそれとなくそれを評価します。 簡潔ためにORを省くことができます。 しかしながら、オペレータが以下でまだ評価されている注意で、したがって、必要であるときに、括弧を入れてくれますか? ここでこれを強調するのは、簡単な例です。 例えば、私たちが方針を指示した、。 AS1755から、私はAS1、A2、およびAS3からのルート以外のすべてのルートを受け入れます、そして、あなたはコネとしての以下の線に入れます。
as-in: from AS1755 100 accept NOT AS1 AS2 AS3
コネとして: AS1755 100から、NOT AS1 AS2 AS3を受け入れてください。
This will be evaluated as:
これは以下として評価されるでしょう。
as-in: from AS1755 100 accept NOT AS1 OR AS2 OR AS3
コネとして: AS1755 100から、NOT AS1 OR AS2 OR AS3を受け入れてください。
Which in turn would be evaluated like this:
どれが順番に評価されるだろうかがこれは好きです:
(NOT AS1) OR AS2 OR AS3
-> ((ANY except AS1) union AS2) union AS3)
--> (ANY except AS1)
(NOT AS1)OR AS2 OR AS3->((AS1) 組合AS2を除いたいずれ)組合AS3) -->。(AS1を除いたいずれも)
This is clearly incorrect and not the desired result. The
correct syntax should be:
これが明確に不正確ですが、必要な結果は不正確ではありません。 正しい構文は以下の通りであるべきです。
as-in: from AS1755 100 accept NOT (AS1 AS2 AS3)
コネとして: AS1755 100から、NOTを受け入れてください。(AS1 AS2 AS3)
Bates, et al. [Page 58] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [58ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Producing the following evaluation:
以下の評価を作成します:
NOT (AS1 OR AS2 OR AS3)
-> (ANY) except (union of AS1, AS2, AS3)
NOT(AS1、AS2またはAS3)->は(少しも)除かれます。(AS1、AS2、AS3の組合)
Which depicts the desired routing policy.
Note that can also be written as below which is perhaps
somewhat clearer:
必要なルーティング方針を表現します。 また、どちらが恐らくいくらか明確であるかのでそれを書くことができることに注意してください:
as-in: from AS1755 100 accept ANY AND NOT
as-in: from AS1755 100 accept (AS1 OR AS2 OR AS3)
コネとして: AS1755 100から、コネに受け入れるのではなく、何でも受け入れてください: AS1755 100から、受け入れてください。(AS1、AS2またはAS3)
Examples:
例:
as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513)
as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8}
コネとして: AS1755 100から、コネとしてあらゆるAND NOT(AS1234 OR AS513)を認めてください: AS1755 150から、AS1234 ORを受け入れてください。{35.0.0.0/8}
A rule can be wrapped over lines providing the associated
<aut-num>, <cost> values and from and accept keywords are
repeated and occur on consecutive lines.
受け入れてください。そして、そして、関連<aut-num>を提供する線で規則を包装できます、<費用>値、キーワードは、繰り返されて、連続した線の上に現れます。
Example:
例:
as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513)
コネとして: AS1755 100から、あらゆるAND NOTを受け入れてください。(AS1234 AS513)
and
そして
as-in: from AS1755 100 accept ANY AND NOT (
as-in: from AS1755 100 accept AS1234 AS513)
コネとして: AS1755 100から、あらゆるAND NOTを受け入れてください。(コネとして: AS1755 100から、AS1234 AS513を受け入れてください)
are evaluated to the same result. Please note that the
ordering of these continuing lines is significant.
同じ結果に評価されます。 これらの継続する線の注文は重要です。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
Bates, et al. [Page 59] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [59ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
as-out:
A description of generated routing information sent to other AS
peers.
アウトとして: 発生しているルーティング情報の記述は他のAS同輩に発信しました。
Format:
to <aut-num> announce <routing policy expression
形式: <ルーティング方針表現を<aut-num>に発表してください。
The to and announce keywords are optional and can be omitted.
そして、キーワードは任意であり、省略できると発表してください。
<aut-num> refers to your AS neighbor.
<aut-num>はあなたのAS隣人について言及します。
<routing policy expression> is explained in the as-in
attribute definition above.
<ルーティング方針表現>はコネとしての属性定義上で説明されます。
Example:
例:
as-out: to AS1104 announce AS978
as-out: to AS1755 announce ANY
as-out: to AS786 announce ANY AND NOT (AS978)
アウトとして: AS1104に、アウトとしてAS978を発表してください: AS1755に、アウトとして何でも発表してください: AS786に、あらゆるAND NOTを発表してください。(AS978)
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
interas-in:
Describes incoming local preferences on an inter AS connection.
中のinteras: 間のAS接続における入って来る地方の好みについて説明します。
Format:
from <aut-num> <local-rid> <neighbor-rid> <preference> accept
<routing policy expression>
形式: <の>の<の地方に排除している><aut-num隣人が排除している><好みの>から、<ルーティング方針表現>を受け入れてください。
The keywords from and accept are optional and can be omitted.
受け入れてください。そして、キーワード、任意であり、省略できます。
<aut-num> is an autonomous system as defined in as-in.
<aut-num>は中でコネと定義されるように自律システムです。
<local-rid> contains the IP address of the border router in
the AS describing the policy. IP address must be in prefix
length format.
<の地方に排除している>は方針を説明するASに境界ルータのIPアドレスを含んでいます。 接頭語長さの形式にはIPアドレスがあるに違いありません。
<neighbor-rid> contains the IP address of neighbor AS's border
router from which this AS accept routes defined in the
<routing policy expression>. IP addresses must be in prefix
length format.
<隣人排除している>はこのASが<ルーティング方針表現>で定義されたルートを受け入れる隣人ASの境界ルータのIPアドレスを含んでいます。 接頭語長さの形式にはIPアドレスがあるに違いありません。
<preference> is defined as follows:
<好みの>は以下の通り定義されます:
(<pref-type>=<value>)
(<値の<pref-タイプ>=>)
It should be noted the parenthesis "(" and ")" and the
"<pref-type>" keyword must be present for this preference to
そして、それが注意されるべきである、挿入句、「(「」、)、」 「<pref-タイプ>」キーワードはこの好みのために現在でなければなりません。
Bates, et al. [Page 60] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [60ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
be valid.
有効であってください。
<pref-type> currently only supports "pref". It could be
expanded to other type of preference such as TOS/QOS as
routing technology matures.
<pref-タイプ>は現在、"pref"を支持するだけです。 ルーティング技術が熟すのに従って、他のタイプのTOS/QOSなどの好みにそれを広げることができました。
<value> can take one of the following values:
<値の>は以下の値の1つを取ることができます:
<cost>
<cost> is a positive integer used to express a relative
cost of routes learned. The lower the cost the more
preferred the route. This <cost> value is only comparable
to other interas-in attributes, not to as-in attributes.
<費用><費用>は学習されたルートの相対コストを言い表すのに使用される正の整数です。 低い..費用..以上..都合のよい..ルート この<費用>価値は単にコネとしての属性ではなく、他の中のinteras属性に匹敵しています。
MED
This indicates the AS will use the
MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented in
BGP4 and IDRP, sent from its neighbor AS.
MED Thisは、ASが隣人ASからのBGP4とIDRPで実行されて、送られるとしてのメートル法のMUTLI_EXIT_DISCRIMINATOR(MED)を使用するのを示します。
NOTE: Combinations of MED and <cost> should be avoided
for the same destinations.
以下に注意してください。 MEDと<費用>の組み合わせは同じ目的地として避けられるべきです。
CAVEAT: The pref-type values may well be enhanced in the
future as more inter-ASs routing protocols introduce
other metrics.
警告: より多くの相互ASsルーティング・プロトコルが他の測定基準を紹介するのに応じて、pref-タイプ値は将来、たぶん高められるでしょう。
Any route specified in interas-in and not specified in
as-in is assumed not accepted between the ASes concerned.
Diagnostic tools should flag this inconsistency as an
error. It should be noted that if an interas-in policy
is specified then it is mandatory to specify the
corresponding global policy in the as-in line. Please
note there is no relevance in the cost associated with
as-in and the preferences used in interas-in.
<routing policy expression> is an expression as defined in
as-in above.
中のinterasで指定されて、コネとして中で指定されなかったどんなルートも当該のASesの間に受け入れられないと思われます。 診断用道具は誤りとしてこの矛盾に旗を揚げさせるはずです。 中のinteras方針が指定されるならコネとしての線で対応するグローバルな方針を指定するのが義務的であることに注意されるべきです。 コネとして交際された費用と中のinterasで使用される好みにおける関連性が全くありません。 <ルーティング方針表現>はコネとしての上で定義されるように表現です。
Examples:
例:
NB: This line is wrapped for readability.
interas-in: from AS1104 192.(pref=10)/accept.AS786.AS987
interas-in: from AS1104 192.87.45.(pref=20)2accept.AS987
interas-in: from AS1103 192.87.45.2(pref=MED)8accept2ANY
ネブラスカ: この線は読み易さ中のinterasのために包装されます: 中のAS1104 192(pref=10)/accept.AS786.AS987 interasから: 中のAS1104 192.87.45(pref=20)2accept.AS987 interasから: AS1103 192.87.45.2の(pref=医学)の8accept2ANYから
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
Bates, et al. [Page 61] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [61ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
interas-out:
外のinteras:
Format:
to <aut-num> <local-rid> <neighbor-rid> [<metric>] announce
<routing policy expression>
形式: <の>の<の地方に排除している><aut-num隣人排除している>[<のメートル法の>]に、<ルーティング方針式>を発表してください。
The keywords to and announce are optional and can be omitted.
発表してください。そして、キーワード、任意であり、省略できます。
The definitions of <aut-num>, <local-rid> <neighbor-rid>, and
<routing policy expression> are identical to those defined in
interas-in.
<aut-num>、<の地方に排除している><隣人排除している>、および<ルーティング方針式>の定義は中のinterasで定義されたものと同じです。
<metric> is optional and is defined as follows:
<のメートル法の>は任意であり、以下の通り定義されます:
(<metric-type>=<value>)
(<値の<のメートル法のタイプ>=>)
It should be noted the parenthesis "(" and ")" and the
keywords of "<metric-type>" must be present for this metric to
be valid.
そして、それが注意されるべきである、挿入句、「(「」、)、」 「<のメートル法のタイプ>」のキーワードはこれのために有効になるようにメートル法であることで存在していなければなりません。
<metric-type> currently only supports "metric-out". It could
be expanded to other type of preference such as TOS/QOS as
routing technology matures.
<value> can take one of the following values:
<のメートル法のタイプ>は現在、「メートル法のアウト」をサポートするだけです。 ルーティング技術が熟すのに従って、他のタイプのTOS/QOSなどの好みにそれを広げることができました。 <値の>は以下の値の1つを取ることができます:
<num-metric>
<num-metric> is a pre-configured metric for out-bound
routes. The lower the cost the more preferred the route.
This <num-metric> value is literally passed by the
routing protocol to the neighbor. It is expected that it
is used there which is indicated by pref=MED on the
corresponding interas-in attribute. It should be noted
that whether to accept the outgoing metric or not is
totally within the discretion of the neighbor AS.
<numメートル法の><numメートル法の>は出かける行きのルートにおいてメートル法であることであらかじめ設定されたaです。 低い..費用..以上..都合のよい..ルート この<numメートル法の>値はルーティング・プロトコルによって文字通り隣人に渡されます。 それがそこで使用されると予想されます(対応する中のinteras属性でpref=MEDによって示されます)。 隣人ASの思慮深さの完全に中に外向的がメートル法であると受け入れるかどうかあることに注意されるべきです。
IGP
This indicates that the metric reflects the ASs internal
topology cost. The topology is reflected here by using
MED which is derived from the AS's IGP metric.
IGP Thisは、メートル法がASsの内部のトポロジー費用を反映するのを示します。 トポロジーは、ASのIGPからメートル法で得られるMEDを使用することによって、ここに反映されます。
NOTE: Combinations of IGP and <num-metric> should be
avoided for the same destinations.
以下に注意してください。 IGPと<numメートル法の>の組み合わせは同じ目的地として避けられるべきです。
CAVEAT: The metric-out values may well be enhanced in the
future as more interas protocols make use of metrics.
警告: より多くのinterasプロトコルが測定基準を利用するとき、メートル法的に出ている値は将来、たぶん高められるでしょう。
Any route specified in interas-out and not specified in
as-out is assumed not announced between the ASes
外のinterasで指定されて、アウトとして中で指定されなかったどんなルートもASesの間で発表されていないと思われます。
Bates, et al. [Page 62] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [62ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
concerned. Diagnostic tools should flag this
inconsistency as an error. It should be noted that if an
interas-out policy is specified then it is mandatory to
specify the corresponding global policy in the as-out
line.
関係がある。 診断用道具は誤りとしてこの矛盾に旗を揚げさせるはずです。 外のinteras方針が指定されるならアウトとしての系列における対応するグローバルな方針を指定するのが義務的であることに注意されるべきです。
Examples:
例:
interas-out:ntoiAS1104p192.87.45.254/32t192.87.45.80/32
interas-out: to AS1104m192.87.45.254/32n192.87.45.80/32
interas-out: to AS1103 192.87.45.254/325192.87.45.80/32
(metric-out=IGP) announce ANY
外のinteras: 外のntoiAS1104p192.87.45 32t192.87.45.80/32.254/interas: 外のAS1104m192.87.45.254/32n192.87.45.80/32interasに: .80/32(メートル法的に出ている=IGP)が少しも発表するAS1103 192.87.45.254/325192.87.45に
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
as-exclude:
A list of transit ASes to ignore all routes from.
-、除外、: AはトランジットASesについて記載します。すべてのルートを無視するために。
Format:
exclude <aut-num> to <exclude-route-keyword>
形式: ルートキーワードを除いている<>まで<aut-num>を除いてください。
Keywords exclude and to are optional and can again be omitted.
そして、キーワードが除く、任意であり、再び省略できます。
<aut-num> refers to the transit AS in question.
<aut-num>は問題のトランジットASについて言及します。
an <exclude-route-keyword> can be ONE of the following.
ルートキーワードを除いている<>は以下のONEであるかもしれません。
1. <aut-num>
1. <aut-num>。
2. AS macro
2. ASマクロ
3. Community
3. 共同体
4. ANY
4. 少しも
Examples:
例:
as-exclude: exclude AS690 to HEPNET
-、除外、: HEPNETまでAS690を除いてください。
This means exclude any HEPNET routes which have a route via
AS690.
これは、AS690を通してルートを持っているどんなHEPNETルートも除くことを意味します。
as-exclude: exclude AS1800 to AS-EUNET
-、除外、: AS-EUNETまでAS1800を除いてください。
This means exclude any AS-EUNET routes which have a route via
AS1800.
これは、AS1800を通してルートを持っているどんなAS-EUNETルートも除くことを意味します。
as-exclude: exclude AS1755 to AS1104
-、除外、: AS1104までAS1755を除いてください。
Bates, et al. [Page 63] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [63ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
This means exclude any AS1104 route which have a route via
AS1755.
これは、どんなAS1104ルートも除くことを意味します(AS1755を通してルートを持っています)。
as-exclude: exclude AS1104 to ANY
-、除外、: いずれまでもAS1104を除いてください。
This means exclude all routes which have a route via AS1104.
これは、AS1104を通してルートを持っているすべてのルートを除くことを意味します。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
default:
An indication of how default routing is done.
デフォルト: デフォルトルーティングがどう完了しているかしるし。
Format:
<aut-num> <relative cost> <default-expression>
形式: <aut-num><相対コスト><デフォルト式>。
where <aut-num> is the AS peer you will default route to,
<aut-num>がAS同輩であるところでは、あなたは、デフォルトルートがそうすることを望んでいます。
and <relative cost> is the relative cost is a positive integer
used to express a preference for default. There is no
relationship to the cost used in the as-in tag. The AS peer
with the lowest cost is used for default over ones with higher
costs.
そして、<相対コスト>は相対コストがデフォルトのための優先を言い表すのに使用される正の整数であるということです。 コネとしてのタグで使用される費用との関係が全くありません。 最も低い費用をもっているAS同輩はデフォルトにものの上で、より高いコストで使用されます。
<default-expression> is optional and provides information on
how a default route is selected. It can take the following
formats:
<デフォルト式>は任意であり、デフォルトルートがどう選択されるかの情報を提供します。 それは以下の形式を取ることができます:
1. static. This indicates that a default is statically
configured to this AS peer.
1. 静的です。 これは、デフォルトが静的にこのAS同輩に構成されるのを示します。
2. A route list with the syntax as described in the as-in
attribute. This indicates that this list of routes is
used to generate a default route. A special but valid
value in this is the special route used by some routing
protocols to indicate default: 0.0.0.0/0
2. コネとしての属性で説明される構文があるルートリスト。 これは、ルートのこのリストがデフォルトルートを生成するのに使用されるのを示します。 これの特別な、しかし、有効な値はいくつかのルーティング・プロトコルによって使用される、デフォルトを示す特別なルートです: 0.0.0.0/0
3. default. This is the same as {0.0.0.0/0}. This means that
the routing protocol between these two peers generates a
true default.
3. デフォルトとしてください。 これが同じである、0.0、.0、.0/0 これは、これらの2人の同輩の間のルーティング・プロトコルが本当のデフォルトを生成することを意味します。
Examples:
例:
default: AS1755 10
default: AS786 5 {140.222.0.0/16, 192.87.45.0/24}
default: AS2043 15 default
デフォルト: AS1755 10はデフォルトとします: AS786 5、140.222.0 16、.0/192.87.45.0/、24、デフォルト: AS2043 15デフォルト
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
Bates, et al. [Page 64] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [64ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
tech-c:
Full name or uniquely assigned NIC-handle of a technical contact
person. This is someone to be contacted for technical problems such
as misconfiguration.
科学技術のc: 技術連絡担当者の人のフルネームか唯一割り当てられたNIC-ハンドル。 これはmisconfigurationなどの技術的問題によって連絡されるべきだれかです。
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Example:
例:
tech-c: John E Doe
tech-c: JED31
科学技術のc: ジョンEドウ技術者c: JED31
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person. In many cases this would be the name of the
guardian.
アドミンc: ドメイン管理者の人のフルネームか唯一割り当てられたNIC-ハンドル。 多くの場合、これは保護者の名前でしょう。
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Example:
例:
admin-c: Joe T Bloggs
admin-c: JTB1
アドミンc: ジョーT Bloggsアドミンc: JTB1
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
guardian:
Mailbox of the guardian of the Autonomous system.
保護者: Autonomousシステムの保護者のメールボックス。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain format wherever
possible.
RFC822ドメイン形式には<Eメールアドレス>がどこでも、可能であるところにあるはずです。
Example:
例:
guardian: as1104-guardian@nikhef.nl
保護者: as1104-guardian@nikhef.nl
Status: mandatory, only one line and e-mail address allowed
状態: 義務的である、許容された1つの系列とEメールアドレスだけ
Bates, et al. [Page 65] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [65ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
remarks:
Remarks/comments, to be used only for clarification.
所見: 明確化にだけ使用されるために述べるか、またはコメントします。
Format:
free text
形式: 無料のテキスト
Example:
例:
remarks: Multihomed AS talking to AS1755 and AS786
remarks: Will soon connect to AS1104 also.
所見: AS1755と話すMultihomed ASとAS786所見: すぐ、AS1104にも接続するでしょう。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be sent. See also
[11].
通知します: 属性に通知してください。このオブジェクトへの変化の通知が送られるべきであるEメールアドレスを含んでいます。 また、[11]を見てください。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain syntax wherever
possible.
<Eメールアドレス>がどこでも、可能であるところにRFC822ドメイン構文であるはずです。
Example:
例:
notify: Marten.Terpstra@ripe.net
通知します: Marten.Terpstra@ripe.net
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
近くmnt: 近くmnt属性は登録された維持装置名を含んでいます。 また、[11]を見てください。
Format:
<registered maintainer name>
形式: <は維持装置名の>を登録しました。
Example:
例:
mnt-by: RIPE-DBM
近くmnt: 熟しているDBM
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
changed:
Who changed this object last, and when was this change made.
変えられる: このオブジェクト最終といつが行われたこの変更であるかを変えました。
Format:
<email-address> YYMMDD
形式: <Eメールアドレス>YYMMDD
Bates, et al. [Page 66] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [66ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
<email-address> should be the address of the person who made
the last change. YYMMDD denotes the date this change was made.
<Eメールアドレス>は最後の変更を行った人のアドレスであるべきです。 YYMMDDはこの変更が行われた日付を指示します。
Example:
例:
changed: johndoe@terabit-labs.nn 900401
変えられる: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
source:
Source of the information.
ソース: 情報の源。
This is used to separate information from different sources kept by
the same database software. For RIPE database entries the value is
fixed to RIPE.
これは、同じデータベースソフトによって保管されたさまざまな原因と情報を切り離すのに使用されます。 RIPEデータベースエントリーにおいて、値はRIPEに固定されています。
Format:
RIPE
Status: mandatory, only one line allowed
形式: 熟している状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 67] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [67ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix B - Syntax details for the community object.
付録B--共同体オブジェクトのための構文の詳細。
Here is a summary of the tags associated with community object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the community object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute.
ここに、共同体オブジェクト自体とそれらの状態に関連しているタグの概要があります。 この属性が共同体オブジェクトで義務的であるか否かに関係なく、最初のコラムが属性、第2コラムを指定して、この詳細が缶を結果と考えるか否かに関係なく、第3コラムは一度[複数の]よりオブジェクト[シングル]に一度だけ現れます。 複数の1属性あたりの系列を指定するとき、属性名を繰り返さなければなりません。 [6] descrのための例を見てください: 結果と考えます。
community: [mandatory] [single] descr: [mandatory] [multiple] authority: [mandatory] [single] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single]
共同体: [義務的][単一の]のdescr: [義務的][複数の]の権威: [義務的な] [単一]の保護者: [義務的な] [単一の] 科学技術のc: [義務的な] [複数]のアドミンc: [義務的な] [複数]の所見: [任意の] [複数の] 通知します: 近く[任意][複数の]のmnt: [任意]の[倍数]は変化しました: [義務的な] [複数]のソース: [義務的]です。[単一]です。
Each attribute has the following syntax:
各属性に、以下の構文があります:
community:
Name of the community. The name of the community should be
descriptive of the community it describes.
共同体: 共同体の名前。 共同体の名前はそれが説明する共同体で描写的であるべきです。
Format:
Upper case text string which cannot start with "AS" or any
of the <routing policy expression> KEYWORDS. See Appendix
A.
形式: “AS"から始まることができない大文字テキスト文字列か<ルーティング方針式>キーワードのいずれも。 付録Aを見てください。
Example:
例:
community: WCW
共同体: WCW
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 68] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [68ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
descr:
A short description of the community represented.
descr: 代表された共同体の短い記述。
Format:
free text
形式: 無料のテキスト
Example:
例:
descr: Science Park Watergraafsmeer
descr: Amsterdam
descr: サイエンスパークWatergraafsmeer descr: アムステルダム
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
authority:
The formal authority for this community. This could be an
organisation, institute, committee, etc.
権威: この共同体への形式的権限。 これは機構、研究所、委員会であるかもしれませんなど。
Format:
free text
形式: 無料のテキスト
Example:
例:
authority: WCW LAN Committee
権威: WCW LAN委員会
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
guardian:
Mailbox of the guardian of the community.
保護者: 共同体の保護者のメールボックス。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain format
wherever possible.
RFC822ドメイン形式には<Eメールアドレス>がどこでも、可能であるところにあるはずです。
Example:
例:
guardian: wcw-guardian@nikhef.nl
保護者: wcw-guardian@nikhef.nl
Status: mandatory, only one line and email address allowed
状態: 義務的である、許容された1つの系列とEメールアドレスだけ
tech-c:
Full name or uniquely assigned NIC-handle of an technical
contact person for this community.
科学技術のc: この共同体への技術連絡担当者の人のフルネームか唯一割り当てられたNIC-ハンドル。
Bates, et al. [Page 69] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [69ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Example:
例:
tech-c: John E Doe
tech-c: JED31
科学技術のc: ジョンEドウ技術者c: JED31
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person. In many cases this would be the name of the
guardian.
アドミンc: ドメイン管理者の人のフルネームか唯一割り当てられたNIC-ハンドル。 多くの場合、これは保護者の名前でしょう。
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Example:
例:
admin-c: Joe T Bloggs
admin-c: JTB1
アドミンc: ジョーT Bloggsアドミンc: JTB1
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
remarks:
Remarks/comments, to be used only for clarification.
所見: 明確化にだけ使用されるために述べるか、またはコメントします。
Format:
free text
形式: 無料のテキスト
Example:
例:
remarks: Temporary community
remarks: Will be removed after split into ASes
所見: 一時的な共同体所見: ASesに分かれた後に取り除くでしょう。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
通知します: 属性に通知してください。このオブジェクトへの変化の通知が発信することであるべきであるEメールアドレスを含んでいます。 また、[11]を見てください。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain syntax
wherever possible.
<Eメールアドレス>がどこでも、可能であるところにRFC822ドメイン構文であるはずです。
Bates, et al. [Page 70] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [70ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example:
例:
notify: Marten.Terpstra@ripe.net
通知します: Marten.Terpstra@ripe.net
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
近くmnt: 近くmnt属性は登録された維持装置名を含んでいます。 また、[11]を見てください。
Format:
<registered maintainer name>
形式: <は維持装置名の>を登録しました。
Example:
例:
mnt-by: RIPE-DBM
近くmnt: 熟しているDBM
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
changed:
Who changed this object last, and when was this change made.
変えられる: このオブジェクト最終といつが行われたこの変更であるかを変えました。
Format:
<email-address> YYMMDD
形式: <Eメールアドレス>YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
<Eメールアドレス>は最後の変更を行った人のアドレスであるべきです。 YYMMDDはこの変更が行われた日付を指示します。
Example:
例:
changed: johndoe@terabit-labs.nn 900401
変えられる: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
source:
Source of the information.
ソース: 情報の源。
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
これは、同じデータベースソフトによって保管されたさまざまな原因と情報を切り離すのに使用されます。 RIPEデータベースエントリーにおいて、値はRIPEに固定されています。
Format:
RIPE
Status: mandatory, only one line allowed
形式: 熟している状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 71] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [71ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix C - AS Macros syntax definition.
付録C--AS Macros構文定義。
Here is a summary of the tags associated with as-macro object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the as-macro object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute.
ここに、マクロとしてのオブジェクト自体に関連しているタグの概要とそれらの状態がいます。 この属性がマクロとしてのオブジェクトで義務的であるか否かに関係なく、最初のコラムが属性、第2コラムを指定して、この詳細が缶を結果と考えるか否かに関係なく、第3コラムは一度[複数の]よりオブジェクト[シングル]に一度だけ現れます。 複数の1属性あたりの系列を指定するとき、属性名を繰り返さなければなりません。 [6] descrのための例を見てください: 結果と考えます。
as-macro: [mandatory] [single] descr: [mandatory] [multiple] as-list: [mandatory] [multiple] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single]
マクロとして: [義務的][単一の]のdescr: [義務的な] [複数の] リストとして: [義務的な] [複数]の保護者: [義務的な] [単一の] 科学技術のc: [義務的な] [複数]のアドミンc: [義務的な] [複数]の所見: [任意の] [複数の] 通知します: 近く[任意][複数の]のmnt: [任意]の[倍数]は変化しました: [義務的な] [複数]のソース: [義務的]です。[単一]です。
Each attribute has the following syntax:
各属性に、以下の構文があります:
as-macro:
The name of a macro containing at least two Autonomous Systems
grouped together for ease of administration.
マクロとして: 少なくとも2Autonomous Systemsを含むマクロの名前は管理の容易さのために一緒に分類されました。
Format:
AS-<string>
形式: <として、>を結んでください。
The <string> should be in upper case and not contain any
special characters.
<ストリング>は大文字の中にあって、どんな特殊文字も含むはずがありません。
Example:
例:
as-macro: AS-EBONE
マクロとして: EBONE
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
descr:
A short description of the Autonomous System Macro.
descr: Autonomous System Macroの短い記述。
Format:
free text
形式: 無料のテキスト
Bates, et al. [Page 72] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [72ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example:
例:
descr: Macro for EBONE connected ASes
descr: EBONEのためのマクロはASesを接続しました。
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
as-list:
The list of ASes or other AS macros that make up this macro. It
should be noted that recursive use of AS macros is to be
encouraged.
リストとして: ASesかこのマクロを作る他のASマクロのリスト。 ASマクロの再帰的な使用が奨励されることであることに注意されるべきです。
Format:
<aut-num> <as-macro> ...
形式: マクロ>としての<aut-num><…
See Appendix A for <aut-num> definition.
<aut-num>定義に関してAppendix Aを見てください。
Example:
例:
as-list: AS786 AS513 AS1104
as-list: AS99 AS-NORDUNET
リストとして: AS786 AS513 AS1104、リストとして: AS99、NORDUNET
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
guardian:
Mailbox of the guardian of this AS macro.
保護者: このASマクロの保護者のメールボックス。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain format
wherever possible.
RFC822ドメイン形式には<Eメールアドレス>がどこでも、可能であるところにあるはずです。
Example:
例:
guardian: as-ebone-guardian@ebone.net
保護者: as-ebone-guardian@ebone.net
Status: mandatory, only one line and e-mail address allowed
状態: 義務的である、許容された1つの系列とEメールアドレスだけ
tech-c:
Full name or uniquely assigned NIC-handle of a technical contact
person for this macro. This is someone to be contacted for
technical problems such as misconfiguration.
科学技術のc: このマクロのための技術連絡担当者の人のフルネームか唯一割り当てられたNIC-ハンドル。 これはmisconfigurationなどの技術的問題によって連絡されるべきだれかです。
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Bates, et al. [Page 73] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [73ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Examples:
例:
tech-c: John E Doe
tech-c: JED31
科学技術のc: ジョンEドウ技術者c: JED31
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person. In many cases this would be the name of the
guardian.
アドミンc: ドメイン管理者の人のフルネームか唯一割り当てられたNIC-ハンドル。 多くの場合、これは保護者の名前でしょう。
Format:
<firstname> <initials> <lastname> or <nic-handle>
形式: <firstname><イニシャルの><lastname>か<nic-ハンドル>。
Examples:
例:
admin-c: Joe T Bloggs
admin-c: JTB1
アドミンc: ジョーT Bloggsアドミンc: JTB1
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
remarks:
Remarks/comments, to be used only for clarification.
所見: 明確化にだけ使用されるために述べるか、またはコメントします。
Format:
free text
形式: 無料のテキスト
Example:
例:
remarks: AS321 will be removed from this Macro shortly
所見: AS321はまもなく、このMacroから取り外されるでしょう。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
通知します: 属性に通知してください。このオブジェクトへの変化の通知が発信することであるべきであるEメールアドレスを含んでいます。 また、[11]を見てください。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain syntax
wherever possible.
<Eメールアドレス>がどこでも、可能であるところにRFC822ドメイン構文であるはずです。
Example:
例:
notify: Marten.Terpstra@ripe.net
通知します: Marten.Terpstra@ripe.net
Bates, et al. [Page 74] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [74ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
近くmnt: 近くmnt属性は登録された維持装置名を含んでいます。 また、[11]を見てください。
Format:
<registered maintainer name>
形式: <は維持装置名の>を登録しました。
Example:
例:
mnt-by: RIPE-DBM
近くmnt: 熟しているDBM
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
changed:
Who changed this object last, and when was this change made.
変えられる: このオブジェクト最終といつが行われたこの変更であるかを変えました。
Format:
<email-address> YYMMDD
形式: <Eメールアドレス>YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
<Eメールアドレス>は最後の変更を行った人のアドレスであるべきです。 YYMMDDはこの変更が行われた日付を指示します。
Example:
例:
changed: johndoe@terabit-labs.nn 900401
変えられる: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
source:
Source of the information.
ソース: 情報の源。
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
これは、同じデータベースソフトによって保管されたさまざまな原因と情報を切り離すのに使用されます。 RIPEデータベースエントリーにおいて、値はRIPEに固定されています。
Format:
RIPE
Status: mandatory, only one line allowed
形式: 熟している状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 75] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [75ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix D - Syntax for the "route" object.
付録D--「ルート」オブジェクトのための構文。
There is a summary of the tags associated with route object itself and their status. The first column specifies the attribute, the second column whether this attribute is mandatory in the community object, and the third column whether this specific attribute can occur only once per object [single], or more than once [multiple]. When specifying multiple lines per attribute, the attribute name must be repeated. See [6] the example for the descr: attribute.
ルートオブジェクト自体とそれらの状態に関連しているタグの概要があります。 この属性が共同体オブジェクトで義務的であるか否かに関係なく、最初のコラムが属性、第2コラムを指定して、この詳細が缶を結果と考えるか否かに関係なく、第3コラムは一度[複数の]よりオブジェクト[シングル]に一度だけ現れます。 複数の1属性あたりの系列を指定するとき、属性名を繰り返さなければなりません。 [6] descrのための例を見てください: 結果と考えます。
route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] comm-list: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single]
以下を発送してください。 [義務的][単一の]のdescr: [義務的な] [複数]の発生源: [義務的な] [単一の] 以下を掘ってください。 [任意の] [複数の] よそよそしい: [任意][単一の]のcomm-リスト: [任意の] [複数]の所見: [任意の] [複数の] 通知します: 近く[任意][複数の]のmnt: [任意]の[倍数]は変化しました: [義務的な] [複数]のソース: [義務的]です。[単一]です。
Each attribute has the following syntax:
各属性に、以下の構文があります:
route:
Route being announced.
以下を発送してください。 発表されていた状態で存在を発送してください。
Format:
Classless representation of a route with the RIPE database
known as the "prefix length" representation. See [10] for
more details on classless representations.
形式: RIPEデータベースが「接頭語の長さ」表現として知られているルートの階級のない表現。 階級のない表現に関するその他の詳細のための[10]を見てください。
Examples:
例:
route: 192.87.45.0/24
以下を発送してください。 192.87.45.0/24
This represents addressable bits 192.87.45.0 to
192.87.45.255.
これは.0〜192.87にアドレス可能なビット192.87.45を表します。.45 .255。
route: 192.1.128.0/17
以下を発送してください。 192.1.128.0/17
This represents addressable bits 192.1.128.0 to
192.1.255.255.
これは.0〜192.1にアドレス可能なビット192.1.128を表します。.255 .255。
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 76] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [76ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
origin:
The autonomous system announcing this route.
発生源: このルートを発表する自律システム。
Format:
<aut-num>
形式: <aut-num>。
See Appendix A for <aut-num> syntax.
<aut-num>構文に関してAppendix Aを見てください。
Example:
例:
origin: AS1104
発生源: AS1104
Status: mandatory, only one line allowed
状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
hole:
Denote the parts of the address space covered this route object
to which the originator does not provide connectivity. These
holes may include routes that are being currently routed by
another provider (e.g., a customer using that space has moved to
a different service provider). They may also include space that
has not yet been assigned to any customer.
以下を掘ってください。 カバーされて、アドレス空間の部品を指示してください。創始者が接続性を供給しないこのルートオブジェクト。 これらの穴は現在別のプロバイダーによって発送されているルートを含むかもしれません(例えば、そのスペースを使用している顧客は異なったサービスプロバイダーに移行しました)。 また、彼らはまだどんな顧客にも割り当てられていないスペースを含むかもしれません。
Format:
Classless representation of a route with the RIPE database
known as the "prefix length" representation. See [10] for
more details on classless representations. It should be
noted that this sub-aggregate must be a component of that
registered in the route object.
形式: RIPEデータベースが「接頭語の長さ」表現として知られているルートの階級のない表現。 階級のない表現に関するその他の詳細のための[10]を見てください。 このサブ集合がルートオブジェクトに登録されたそのコンポーネントであるに違いないことに注意されるべきです。
Example:
例:
hole: 193.0.4.0/24
以下を掘ってください。 193.0.4.0/24
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
withdrawn:
Used to denote the day this route has been withdrawn from the
Internet routing mesh. This will be usually be used when a less
specific aggregate route is now routed the more specific (i.e.
this route) is not need anymore.
よそよそしい: このルートがインターネット・ルーティングメッシュから引っ込められた日に指示するのにおいて、使用されています。 これはそれほど特定でない集合ルートが現在発送されるとき、使用されて、それ以上より特定であるのが(すなわち、このルート)、必要性でないという通常ことであるためにことになるでしょう。
Format:
YYMMDD
形式: YYMMDD
YYMMDD denotes the date this route was withdrawn.
YYMMDDはこのルートが引っ込められた日付を指示します。
Bates, et al. [Page 77] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [77ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Example:
例:
withdrawn: 940711
よそよそしい: 940711
Status: optional, one line allowed.
状態: 任意であることで、1つは許容されていた状態で立ち並んでいます。
comm-list:
List of one or more communities this route is part of.
comm-リスト: これが発送する1つ以上の共同体のリストは部分です。
Format:
<community> <community> ...
形式: <共同体><共同体>…
See Appendix B for <community> definition.
<共同体>定義に関してAppendix Bを見てください。
Example:
例:
comm-list: HEP LEP
comm-リスト: 事情通のLEP
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
remarks:
Remarks/comments, to be used only for clarification.
所見: 明確化にだけ使用されるために述べるか、またはコメントします。
Format:
free text
形式: 無料のテキスト
Example:
例:
remarks: Multihomed AS talking to AS1755 and AS786
remarks: Will soon connect to AS1104 also.
所見: AS1755と話すMultihomed ASとAS786所見: すぐ、AS1104にも接続するでしょう。
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
通知します: 属性に通知してください。このオブジェクトへの変化の通知が発信することであるべきであるEメールアドレスを含んでいます。 また、[11]を見てください。
Format:
<email-address>
形式: <Eメールアドレス>。
The <email-address> should be in RFC822 domain syntax
wherever possible.
<Eメールアドレス>がどこでも、可能であるところにRFC822ドメイン構文であるはずです。
Example:
例:
notify: Marten.Terpstra@ripe.net
通知します: Marten.Terpstra@ripe.net
Bates, et al. [Page 78] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [78ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
近くmnt: 近くmnt属性は登録された維持装置名を含んでいます。 また、[11]を見てください。
Format:
<registered maintainer name>
形式: <は維持装置名の>を登録しました。
Example:
例:
mnt-by: RIPE-DBM
近くmnt: 熟しているDBM
Status: optional, multiple lines allowed
状態: 任意であることで、倍数は許容されていた状態で立ち並んでいます。
changed:
Who changed this object last, and when was this change made.
変えられる: このオブジェクト最終といつが行われたこの変更であるかを変えました。
Format:
<email-address> YYMMDD
形式: <Eメールアドレス>YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
<Eメールアドレス>は最後の変更を行った人のアドレスであるべきです。 YYMMDDはこの変更が行われた日付を指示します。
Example:
例:
changed: johndoe@terabit-labs.nn 900401
変えられる: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
状態: 義務的であることで、倍数は許容されていた状態で立ち並んでいます。
source:
Source of the information.
ソース: 情報の源。
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
これは、同じデータベースソフトによって保管されたさまざまな原因と情報を切り離すのに使用されます。 RIPEデータベースエントリーにおいて、値はRIPEに固定されています。
Format:
RIPE
Status: mandatory, only one line allowed
形式: 熟している状態: 義務的であることで、1つだけが許容されていた状態で立ち並んでいます。
Bates, et al. [Page 79] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [79ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix E - List of reserved words
付録E--リザーブドワードのリスト
The following list of words are reserved for use within the attributes of the AS object. The use of these words is solely for the purpose of clarity. All keywords must be lower case.
単語の以下のリストは使用のためにASオブジェクトの属性の中で予約されます。 これらの単語の使用は唯一明快の目的のためのものです。 すべてのキーワードが小文字であるに違いありません。
accept
announce
exclude
from
to
transit
受諾、発表、除外、トランジット
Examples of the usage of the reserved words are:
リザーブドワードの用法に関する例は以下の通りです。
as-in: from <neighborAS> accept <route>
コネとして: <neighborAS>から、<ルート>を受け入れてください。
as-out: to <neighborAS> announce <route>
アウトとして: <ルート>を<neighborAS>に発表してください。
as-exclude: exclude <ASpath> to <destination>
-、除外、: <の目的地>まで<ASpath>を除いてください。
as-transit: transit <ASpath> to <destination>
トランジットとして: <の目的地>へのトランジット<ASpath>。
default: from <neighborAS> accept <route>
デフォルト: <neighborAS>から、<ルート>を受け入れてください。
default: to <neighborAS> announce <route>
デフォルト: <ルート>を<neighborAS>に発表してください。
Note: that as-transit is an experimental attribute. See section 10.
以下に注意してください。 トランジットとしての実験属性です。 セクション10を見てください。
Bates, et al. [Page 80] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [80ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix F - Motivations for RIPE-81++
付録F--熟している81++に関する動機
This appendix gives motivations for the major changes in this proposal from ripe-81.
この付録は熟している81からこの提案における大きな変化に関する動機を与えます。
The main goals of the routing registry rework are:
ルーティング登録の目標が作りなおすメインは以下の通りです。
SPLIT
Separate the allocation and routing registry functions into
different database objects. This will facilitate data management
if the Internet registry and routing registry functions are
separated (like in other parts of the world). It will also make
more clear what is part of the routing registry and who has
authority to change allocation vs. routing data.
SPLIT Separate、異なったデータベースオブジェクトへの配分とルーティング登録機能。 インターネット登録とルーティング登録機能が切り離されると(世界のほかの地域では、好きです)、これはデータ管理を容易にするでしょう。 また、それで、以上はルーティングデータに対して配分を変えるために何がルーティング登録の一部であるか、そして、だれが権限があるかが明確になるでしょう。
CIDR
Add the possibility to specify classless routes in the routing
registry. Classless routes are being used in Internet
production now. Aggregation information in the routing registry
is necessary for network layer troubleshooting. It is also
necessary because aggregation influences routing policies
directly.
CIDR Add、ルーティング登録で階級のないルートを指定する可能性。 階級のないルートは現在、インターネット生産に使用されています。 ルーティング登録の集合情報がネットワーク層トラブルシューティングに必要です。 また、集合が直接ルーティング方針に影響を及ぼすので、それも必要です。
CALLOC
Add the possibility to allocate address space on classless
boundaries in the allocation registry. This is a way to preserve
address space.
CALLOC Add、配分登録の階級のない境界のアドレス空間を割り当てる可能性。 これはアドレス空間を保存する方法です。
CLEAN
To clean up some of the obsolete and unused parts of the routing
registry.
CLEAN Toはルーティング登録の時代遅れの、そして、未使用の地域のいくつかをきれいにします。
The major changes are now discussed in turn:
現在、順番に大きな変化について議論します:
Introduce Classless Addresses
階級のないアドレスを紹介してください。
CIDR, CALLOC
CIDR、CALLOC
Introduce route object.
ルートオブジェクトを導入してください。
SPLIT, CIDR and CALLOC.
CIDRとCALLOC、分かれてください。
Bates, et al. [Page 81] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [81ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Delete obsolete attributes from inetnum.
inetnumから時代遅れの属性を削除してください。
CLEAN.
掃除してください。
Delete RIPE-DB and LOCAL from routing policy expressions.
ルーティング方針式からRIPE-dBとLOCALを削除してください。
CLEAN
掃除してください。
Allow multiple ASes to originate the same route
複数のASesに同じルートを溯源させてください。
Because it is being done. CIDR. Made possible by SPLIT.
完了しているので。 CIDR SPLITによって可能にされます。
Bates, et al. [Page 82] RFC 1786 Representing IP Routing Policies in a RR March 1995
ベイツ、他 [82ページ] 1995年3月にRRのIPルート設定方針を表すRFC1786
Appendix G - Transition strategy from RIPE-81 to RIPE-81++
付録G--RIPE-81からRIPE-81++までの変遷戦略
Transition from the routing registry described by ripe-81 to the routing registry described in this document is a straightforward process once the new registry functions have been implemented in the database software and are understood by the most commonly used registry tools. The routing related attributes in the classful inetnum objects of ripe- 81 can be directly translated into new routing objects. Then these attributes can be deleted from the inetnum object making that object if conform to the new schema.
新しい登録機能がいったんデータベースソフトで実装されて、最も一般的に使用された登録ツールに解釈されると、81熟している歳までに説明されたルーティング登録から本書では説明されたルーティング登録までの変遷は簡単なプロセスです。 ルーティングは直接翻訳された新しいルーティングがオブジェクトであったかもしれないなら熟している81のclassful inetnumオブジェクトで属性を関係づけました。 次に、そのオブジェクトを作るinetnumオブジェクトからこれらの属性を削除できる、新しい図式に従ってください。
Proposed transition steps:
提案された変遷は踏まれます:
1) Implement classless addresses and new object definition in the
database software.
1) データベースソフトへの階級のないアドレスと新しいオブジェクト定義を実装してください。
2) Make common tools understand the new schema and prefer it if both
old and new are present.
2) 一般的なツールが新しい図式を理解して、ともに古いならそれを好むのを作ってください、そして、新しいのは、プレゼントです。
3) Invite everyone to convert their data to the new format. This can
be encouraged by doing conversions automatically and proposing them
to maintainers.
3) 皆がそれらのデータを新しい形式に変換するよう誘ってください。 自動的に変換して、維持装置にそれらを提案することによって、これを奨励できます。
4) At a flag day remove all remaining routing information from the
inetnum objects. Before the flag day all usage of obsoleted
inetnum attributes has to cease and all other routing registry
functions have to be taken over by the new objects and attributes.
4) 旗の日に、inetnumオブジェクトからすべての残っているルーティング情報を取り除いてください。 以前、時代遅れにされたinetnum属性のすべての用法がやめなければならない旗の日、他のすべてのルーティング登録機能が新しいオブジェクトと属性によって引き継がれなければなりません。
Bates, et al. [Page 83]
ベイツ、他 [83ページ]
一覧
スポンサーリンク
