Network Working Group D. Meyer
Request for Comments: 2650 Cisco Systems
Category: Informational J. Schmitz
America On-Line
C. Orange
RIPE NCC
M. Prior
Connect
C. Alaettinoglu
USC/ISI
August 1999
Using RPSL in Practice
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in the IRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations.
この文書は、インターネットルーティングレジストリ（IRR）にルーティングポリシーを記述するためにルーティングポリシー仕様言語（RPSL）を使用して、上のチュートリアルです。私たちは、IRRでこれらのポリシーを登録する方法、およびベンダー固有のルータ設定を生成するために、例えば、ルーティングポリシー分析ツールを使用してそれらを分析する方法、RPSLを使用して、さまざまなルーティング方針と構成を指定する方法を説明します。
1 Introduction
1はじめに
This document is a tutorial on RPSL and is targeted towards an Internet/Network Service Provider (ISP/NSP) engineer who understands Internet routing, but is new to RPSL and to the IRR. Readers are referred to the RPSL reference document (RFC 2622) [1] for completeness. It is also good to have that document at hand while working through this tutorial.
この文書は、RPSLのチュートリアルで、インターネットルーティングを理解し、インターネット/ネットワークサービスプロバイダー（ISP / NSP）エンジニアを対象としてますが、RPSLへとIRRに新しいです。読者は、完全性のためにRPSL参照文書（RFC 2622）[1]と呼ばれます。このチュートリアルを作業中の手でその文書を持っても良いです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
The IRR is a repository of routing policies. Currently, the IRR repository is a set of five repositories maintained at the following sites: the CA*Net registry in Canada, the ANS, CW and RADB registries in the United States of America, and the RIPE registry in Europe. The five repositories are run independently. However, each site exchanges its data with the others regularly (at least once a day and as often as every ten minutes). CW, CA*Net and ANS are private registries which contain the routing policies of the networks and the customer networks of CW, CA*Net, and ANS respectively. RADB and RIPE are both public registries, and any ISP can publish their policies in these registries.
IRRは、ルーティングポリシーのリポジトリです。カナダのCA *ネットレジストリ、米国のANS、CWおよびRADBレジストリ、および欧州におけるRIPEレジストリ：現在、IRRリポジトリは、以下のサイトで維持5つのリポジトリのセットです。 5つのリポジトリは独立して実行されます。ただし、各サイトは、定期的に（少なくとも1日1回のように頻繁に10分ごとなど）他の人とそのデータをやりとりします。 CW、CA * NetとANSは、それぞれのネットワークのルーティングポリシーとCW、CA *ネット、およびANSの顧客ネットワークを含んでプライベートレジストリです。 RADBとRIPEは両方の公共のレジストリであり、任意のISPは、これらのレジストリにその方針を公開することができます。
The registries all maintain up-to-date copies of one another's data. At any of the sites, the five registries can be inspected as a set. One should refrain from registering his/her data in more than one of the registries, as this practice leads almost invariably to inconsistencies in the data. The user trying to interpret the data is left in a confusing (at best) situation. CW, ANS and CA*Net customers are generally required to register their policies in their provider's registry. Others may register policies either at the RIPE or RADB registry, as preferred.
レジストリのすべては、互いのデータの最新のコピーを維持します。いずれのサイトでも、5つのレジストリはセットとして検査することができます。このような行為は、データに不整合にほとんど常につながるように、1つは、レジストリの複数で彼/彼女のデータを登録控えるべきです。データを解釈しようとするユーザーが混乱（せいぜい）状況に残されています。 CW、ANSとCA *ネットの顧客は、一般に、そのプロバイダのレジストリに自分の政策を登録する必要があります。好ましいものとして他には、RIPEやRADBレジストリのポリシーのいずれかを登録することもできます。
RPSL is based on RIPE-181 [2, 3], a language used to register routing policies and configurations in the IRR. Operational use of RIPE-181 has shown that it is sometimes difficult (or impossible) to express a routing policy which is used in practice. RPSL has been developed to address these shortcomings and to provide a language which can be further extended as the need arises. RPSL obsoletes RIPE-181.
RPSLはIRRにルーティングポリシーおよび構成を登録するために使用される言語は、[3,2] RIPE-181に基づくものです。 RIPE-181の操作上の使用は、実際に使用されるルーティングポリシーを発現することが時々困難（または不可能）であることが示されています。 RPSLは、これらの欠点に対処するために、必要に応じてさらに拡張することができます言語を提供するために開発されてきました。 RPSLは、RIPE-181を廃止します。
RPSL constructs are expressed in one or more database "objects" which are registered in one of the registries described above. Each database object contains some routing policy information and some necessary administrative data. For example, an address prefix routed in the inter-domain mesh is specified in a route object, and the peering policies of an AS are specified in an aut-num object. The database objects are related to each other by reference. For example, a route object must refer to the aut-num object for the AS in which it is originated. Implicitly, these relationships define sets of objects, which can be used to specify policies effecting all members. For example, we can specify a policy for all routes of an ISP, by referring to the AS number in which the routes are registered to be originated.
RPSL構築物は、上記のレジストリのいずれかに登録されている1つ以上のデータベース「オブジェクト」で表現されます。各データベース・オブジェクトには、いくつかのルーティングポリシー情報といくつかの必要な管理データが含まれています。たとえば、ドメイン間のメッシュにルーティングされたアドレスのプレフィックスは、ルートオブジェクトに指定され、ASのピアリングポリシーはAUT-NUMオブジェクトで指定されています。データベースオブジェクトは、参照することにより、相互に関連しています。例えば、ルートオブジェクトは、それが発信されたASのためのAUT-NUMオブジェクトを参照しなければなりません。暗黙のうちに、これらの関係は、すべてのメンバーに影響を与えるポリシーを指定するために使用できるオブジェクトのセットを定義します。例えば、我々は、ルートが発信されるように登録されたAS番号を参照することにより、ISPのすべてのルートのためのポリシーを指定することができます。
When objects are registered in the IRR, they become available for others to query using a whois service. Figure 1 illustrates the use of the whois command to obtain the route object for 128.223.0.0/16. The output of the whois command is the ASCII representation of the route object. The syntax and semantics of the route object are described in Appendix A.3. Registered policies can also be compared with others for consistency and they can be used to diagnose operational routing problems in the Internet.
オブジェクトはIRRに登録されている場合、彼らはWHOISサービスを使用してクエリを実行するために他の人のために利用可能になります。図1は128.223.0.0/16のルートオブジェクトを取得するためのwhoisコマンドの使用を示します。 whoisのコマンドの出力は、ルートオブジェクトのASCII表現です。ルートオブジェクトの構文と意味は、付録A.3で説明されています。登録されたポリシーはまた、一貫性のために他の人と比較することができ、それらは、インターネットでの運用ルーティングの問題を診断するために使用することができます。
% whois -h whois.ra.net 128.223.0.0/16 route: 128.223.0.0/16 descr: UONet descr: University of Oregon descr: Computing Center descr: Eugene, OR 97403-1212 descr: USA origin: AS3582 mnt-by: MAINT-AS3582 changed: meyer@ns.uoregon.edu 19960222 source: RADB
％のwhois -h whois.ra.net 128.223.0.0/16ルート：128.223.0.0/16 DESCR：UONet DESCR：オレゴンDESCRの大学：コンピューティングセンターのDESCR：オレゴン州ユージーン97403から1212 DESCR：USA起源：AS3582のMNT-により、 ：MAINT-AS3582は変更：meyer@ns.uoregon.edu 19960222ソース：RADB
Figure 1: whois command and a route object.
図1：WHOISコマンドとルートオブジェクト。
The RAToolSet [6] is a suite of tools which can be used to analyze the routing registry data. It includes tools to configure routers (RtConfig), tools to analyze paths on the Internet (prpath and prtraceroute), and tools to compare, validate and register RPSL objects (roe, aoe and prcheck).
RAToolSet [6]ルーティングレジストリデータを分析するために使用できる一連のツールです。これはRPSLオブジェクト（ROE、AOEとprcheck）を、比較検証し、登録するようにルータを設定するためのツール（RtConfig）、インターネット（prpathとprtraceroute）上の経路を分析するためのツール、およびツールを含みます。
In the following section, we will describe how common routing policies can be expressed in RPSL. The objects themselves are described in Appendix A. Authoritative information on the IRR objects, however, should be sought in RFC-2622, and authoritative information on general database objects (person, role, and maintainers) and on querying and updating the registry databases, should be sought in RIPE-157 [4]. Section 3.2 describes the use of RtConfig to generate vendor specific router configurations.
次のセクションでは、我々はRPSLで表現することができる方法を共通のルーティングポリシーについて説明します。オブジェクト自体は、付録A.しかし、RFC-2622に求められるべきであるIRRオブジェクトに関する正式な情報、および一般的なデータベースオブジェクト（人、役割、およびメンテナ）上とレジストリデータベースを照会し、更新に関する正式な情報に記述されていますRIPE-157で求められるべきである[4]。 3.2節では、ベンダー固有のルータ設定を生成するためにRtConfigの使用を記載しています。
2 Specifying Policy in RPSL
2 RPSLにポリシーを指定します
The key purpose of RPSL is to allow you to specify your routing configuration in the public Internet Routing Registry (IRR), so that you and others can check your policies and announcements for consistency. Moreover, in the process of setting policies and configuring routers, you take the policies and configurations of others into account.
RPSLの主要な目的は、あなたや他の人が一貫性を保つためにあなたのポリシーと告知を確認することができるようにあなたは、公共のインターネットルーティングレジストリ（IRR）であなたのルーティング設定を指定できるようにすることです。また、ポリシーを設定し、ルータを設定するプロセスでは、あなたのアカウントに他人の方針と構成を取ります。
In this section, we begin by showing how some simple peering policies can be expressed in RPSL. We will build on that to introduce various database objects that will be needed in order to register policies in the IRR, and to show how more complex policies can be expressed.
このセクションでは、我々はいくつかの簡単なピアリングポリシーはRPSLで表現することができるかを示すことから始めます。私たちは、IRRにポリシーを登録すると、より複雑なポリシーを表現することができる方法を示すために必要となるさまざまなデータベース・オブジェクトを導入することで構築されます。
The peering policies of an AS are registered in an aut-num object which looks something like that in Figure 2. We will focus on the semantics of the import and export attributes in which peering policies are expressed. We will also describe some of the other key attributes in the aut-num object, but the reader should refer to RFC-2622 or to RIPE-157 for the definitive descriptions.
ASのピアリングポリシーは、当社がピアリングポリシーが表現されているインポートおよびエクスポート属性のセマンティクスに焦点を当てる図2のようなものに見えるAUT-NUMオブジェクトに登録されています。また、AUT-NUMオブジェクト内の他のキー属性のいくつかを説明しますが、読者は決定的な説明については、RFC-2622やRIPE-157を参照してください。
aut-num: AS2 as-name: CAT-NET descr: Catatonic State University import: from AS1 accept ANY import: from AS3 accept <^AS3+$> export: to AS3 announce ANY export: to AS1 announce AS2 AS3 admin-c: AO36-RIPE tech-c: CO19-RIPE mnt-by: OPS4-RIPE changed: orange@ripe.net source: RIPE
AUT-NUM：として名AS2：CAT-NET DESCR：緊張州立大学のインポート：AS1から任意のインポートを受け入れる：AS3から<^ AS3 + $>輸出を受け入れる：AS3するために、任意の輸出を発表：AS1にAS2 AS3管理-Cを発表： AO36-RIPEハイテク-C：CO19-RIPE MNT-によって：OPS4-RIPEが変更：orange@ripe.netソース：RIPE
Figure 2: Autonomous System Object
図2：自律システムオブジェクト
Now consider Figure 3 (AS4 and AS5 in the figure will be discussed later). The peering policies expressed in the AS2 aut-num object in Figure 2 are typical for a small service provider providing connectivity for a customer AS3 and using AS1 for transit. That is, AS2 only accepts announcements from AS3 which:
今、図3（図中AS4とAS5は後述する）を検討してください。図2のAS2 AUT-NUMオブジェクトで表現さピアリングポリシーは、小さなサービスプロバイダは、顧客AS3の接続を提供し、輸送のためにAS1を使用するための典型的なものです。それは、AS2はAS3どのからのお知らせを受け入れ、次のとおりです。
o are originated in AS3; and
O AS3に由来しています。そして
o have paths composed of only AS3's (^ in <^AS3+$> means that AS3 is the first member of the path, + means that AS3 occurs one or more times in the path, and $ means that no other AS can be present in the path after AS3) (1).
O <^ AS3 + $>は、AS3は、パスの最初のメンバーであるという意味で、+は、AS3がパスに一回以上発生し、$は、他のASがで存在することができないことを意味することを意味するのみAS3の（^からなる経路を有しますAS3後のパス）（1）。
To AS1, AS2 announces only those routes which originate in their AS or in their customer's AS.
AS1に、AS2は、そのASや顧客のASに由来するものだけのルートを発表しました。
AS1--------AS2--------AS3
| |
| |
AS4--------AS5
Figure 3: Some Neighboring ASes.
図3：一部の近隣のAS。
In the example above, "accept ANY" in the import attribute indicates that AS2 will accept any announcements that AS1 sends, and "announce ANY" in the export attribute indicates that any route that AS2 has in its routing table will be passed on to AS3. Assuming that AS1 announces "ANY" to AS2, AS2 is taking full routing from AS1.
上記の例では、import属性にAS2がAS1を送信するすべてのアナウンスを受け入れ、およびエクスポート属性でAS2は、そのルーティングテーブルに持っている任意の経路がAS3に渡されることを示している「ANYが発表」になることを示している「ANYが受け入れます」 。 AS2がAS1から完全なルーティングを取って、AS1はAS2に「ANY」を発表すると仮定すると。
Note that with this peering arrangement, if AS1 adds or deletes route objects, there is no need to update any of the aut-num objects to continue the full routing policy. Added (or deleted) route objects will implicitly update AS1's and AS2's policies.
AS1は、ルートオブジェクトを追加または削除した場合、このピアリング構成で、完全なルーティングポリシーを継続するAUT-NUMオブジェクトのいずれかを更新する必要がないことに留意されたいです。追加されました（または削除）ルートオブジェクトは、暗黙的にAS1のとAS2のポリシーを更新します。
While the peering policy specified in Figure 2 for AS2 is common, in practice many peering agreements are more complex. Before we consider more examples, however, let's first consider the aut-num object itself. Note that it is just a set of attribute labels and values which can be submitted to one of the registry databases. This particular object is specified as being in (or headed for) the RIPE registry (see the last line in Figure 2). The source should be specified as one of ANS, CANET, CW, RADB, or RIPE depending on the registry in which the object is maintained. The source attribute must be specified in every database object.
AS2のために、図2に指定されたピアリングポリシーは一般的であるが、実際には多くのピアリング協定は、より複雑です。我々はより多くの例を検討する前に、しかし、のは、最初のAUT-NUMオブジェクト自体を考えてみましょう。それは、レジストリデータベースのいずれかに提出することができ、属性のラベルと値のセットだけであることに注意してください。この特定のオブジェクトは、RIPEレジストリ（図2の最後の行を参照）にある（またはに向かっ）として指定されています。ソースオブジェクトが維持されるレジストリに応じANS、CANET、CW、RADB、またはRIPEの一つとして指定されなければなりません。ソース属性は、すべてのデータベース・オブジェクトに指定する必要があります。
It is also worth noting that this object is "maintained by" OPS4-RIPE (the value of the mnt-by attribute), which references a "mntner" object. Because the aut-num object may be used for router configuration and other operational purposes, the readers need to be able to count on the validity of its contents. It is therefore required that a mntner be specified in the aut-num and in most other database objects, which means you must create a mntner object before you can register your peering policies. For brief information on the "mntner" object and object writeability, see Appendix A of this document. For more extensive information on how to set up and use a mntner to protect your database objects, see Section 2.3 of RIPE-157.
このオブジェクトが「のmntner」オブジェクトを参照OPS4-RIPE（MNT-による属性の値）、「によって維持される」ことも注目に値します。 AUT-NUMオブジェクトは、ルータの設定およびその他の業務の目的に使用することができるので、読者はその内容の妥当性を頼りにすることができるようにする必要があります。それゆえのmntnerがあなたのピアリングポリシーを登録することができます前に、あなたがのmntnerオブジェクトを作成する必要がありますを意味し、AUT-NUMにし、他のほとんどのデータベースオブジェクトで指定する必要があります。 「のmntner」オブジェクトとオブジェクトの書き込み可能性に関する簡単な情報については、このドキュメントの付録Aを参照してください。セットアップおよびデータベース・オブジェクトを保護するためのmntnerの使用方法についてのより広範な情報については、RIPE-157のセクション2.3を参照してください。
It is not uncommon for an ISP to acquire connectivity from a transit provider which announces all routes to it, which it in turn passes on to its customers to allow them to access hosts on the global Internet. Meanwhile, the ISP will generally announce the routes of its customers networks to the transit ISP, making them accessible on the global Internet. This is the service that is specified in Figure 2 for AS3.
ISPは彼らがグローバルなインターネット上のホストにアクセスできるようにするために、顧客へ渡す順番にそれそれへのすべてのルートを、発表しましたトランジットプロバイダから接続を取得することは珍しくありません。一方、ISPは、一般的にグローバルなインターネット上の彼らがアクセスしやすく、トランジットISPに顧客のネットワークのルートを発表します。これは、AS3のために、図2に指定されているサービスです。
Consider again Figure 3. Suppose now that AS2 wants to provide the same service to AS4. Clearly, it would be easy to modify the import and export lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4.
図3. AS2がAS4に同じサービスを提供したいということになりましたと改めて考えてみましょう。明らかに、図4に示したものとAS2（図2）のためのAUT-NUMオブジェクト内のインポートおよびエクスポートの行を変更することは容易であろう。
import: from AS1 accept ANY import: from AS3 accept <^AS3+$> import: from AS4 accept <^AS4+$> export: to AS3 announce ANY export: to AS4 announce ANY export: to AS1 announce AS2 AS3 AS4
インポート：AS1から任意のインポートを受け入れる：AS3から<^ AS3 + $>インポートを受け入れる：AS4から<^ AS4 + $>輸出を受け入れる：AS3するために、任意の輸出を発表：AS4するために、任意の輸出を発表：AS1へのAS2 AS3のAS4を発表
Figure 4: Policy for AS3 and AS4 in the AS2 as-num object
図4：AS2にAS3とAS4のポリシーとして、NUMオブジェクト
These changes are trivial to make of course, but clearly as the number of AS2 customers grows, it becomes more difficult to keep track of, and to prevent errors. Note also that if AS1 is selective about only accepting routes from the customers of AS2 from AS2, the aut-num object for AS1 would have to be adjusted to accommodate AS2's new customer.
これらの変更はもちろん、作りするのは簡単ですが、はっきりとAS2の顧客の数が大きくなるにつれて、それはを追跡するため、およびエラーを防ぐために、より困難になります。注また、AS1のみAS2からAS2の顧客からのルートを受け入れることについて選択的である場合、AS1のためのAUT-NUMオブジェクトはAS2の新規顧客に対応するように調整されなければならないことを。
By using the RPSL "as-set" object, we can simplify this significantly. In Figure 5, we describe the customers of AS2. Having this set to work with, we can now rewrite the policies in Figure 2 as shown in Figure 6.
「としてセット」オブジェクトをRPSLを使用することにより、我々は非常にこれを簡素化することができます。図5では、我々は、AS2の顧客を記述する。図6に示すように動作するように、このセットを持って、我々は今、図2のポリシーを書き換えることができます。
as-set: AS2:AS-CUSTOMERS members: AS3 AS4 changed: orange@ripe.net source: RIPE
以下のように設定：AS2：AS-顧客メンバー：AS3のAS4を変更：orange@ripe.netソース：RIPE
Figure 5: The as-set object
図5のように、設定されたオブジェクト
import: from AS1 accept ANY import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS+$> export: to AS2:AS-CUSTOMERS announce ANY export: to AS1 announce AS2 AS2:AS-CUSTOMERS
インポート：AS2から：AS-顧客は<^ AS2：AS-CUSTOMERS + $>受け入れ、顧客がAS-ANY輸出を発表：AS1へのAS2 AS2を発表：輸出：AS2へのAS-CUSTOMERS AS1から任意のインポートを受け入れます
Figure 6: Policy in the AS2 aut-num object for all AS2 customers
図6：すべてのAS2の顧客のためのAS2 AUT-NUMオブジェクト内のポリシー
Note that if the aut-num object for AS1 contains the line:
AS1のためのAUT-NUMオブジェクトは行が含まれている場合があります：
import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$>
インポート：AS2から受け入れる<^ AS2 + AS2：AS-CUSTOMERS * $>
then no changes will need to be made to the aut-num objects for AS1 or AS2 as the AS2 customer base grows. The AS numbers for new customers can simply be added to the as-set AS2:AS-CUSTOMERS, and everything will work as for the existing customers. Clearly in terms of readability, scalability and maintainability, this is a far better mechanism when compared to adding policy for the customer AS's to the aut-num objects directly. The policy in this particular example states that AS1 will accept route announcements from AS2 in which the first element of the path is AS2, followed by more occurrences of
AS2の顧客基盤の成長に合わせて、その後は変化がAS1またはAS2のためのAUT-NUMオブジェクトに行われる必要がありません。新規顧客のためのAS番号は、単に設定AS2に追加することができます：AS-顧客、およびすべてのものは、既存の顧客のためのように動作します。明らかに読みやすさ、拡張性と保守性の観点から、これは直接AUT-NUMオブジェクトにあります、顧客のためのポリシーを追加することに比べてはるかに優れたメカニズムです。この特定の例では、ポリシーの複数の出現に続いて、AS1は、パスの最初の要素は、AS2であるAS2からルートアナウンスを受け入れると述べ
AS2, and then 0 or more occurrences of any AS2 customer (e.g. any member of the as-set AS2:AS-CUSTOMERS).
AS2、および任意AS2顧客の後、0以上の出現（例えばとして設定AS2の任意のメンバー：AS-CUSTOMERS）。
Alternatively, one may wish to limit the routes one accepts from a peer, especially if the peer is a customer. This is recommended for several reasons, such as preventing the improper use of unassigned address space, and of course malicious use of another organization's address space.
あるいは、ピアが顧客である場合は特に、一方がピアから受け入れるルートを制限することを望むかもしれません。これは、未割り当てアドレス空間の不適切な使用を防止し、もちろん他の組織のアドレス空間の悪意の使用など、いくつかの理由のために推奨されます。
Such filtering can be expressed in various ways in RPSL. Suppose the address space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment to its customers. AS3 may want to announce part or all of this block on the global Internet. Suppose AS2 wants to be certain that it only accepts announcements from AS3 for address space that has been properly allocated to AS3. AS2 might then modify the AS3 import line in Figure 2 to read:
そのようなフィルタリングは、RPSL様々な方法で表現することができます。アドレス空間7.7.0.0/16は、顧客への割り当てのためにISPの管理AS3に割り当てられていると仮定します。 AS3は、グローバルなインターネット上でこのブロックの一部または全部を発表することができます。 AS2は、それだけで正常にAS3に割り当てられたアドレス空間に対するAS3からのお知らせを受け入れることは確かであることを望んでいるとします。 AS2は、読むために、図2にAS3のインポート行を変更する可能性：
import: from AS3 accept { 7.7.0.0/16^16-19 }
インポート：AS3から{7.7.0.0/16^16-19}を受け入れます
which states that route announcements for this address block will be accepted from AS3 if they are of length upto /19. This of course will have to be modified if and when AS3 gets more address space. Moreover, it is again clear that for an ISP with a growing or changing customer base, this mechanism will not scale well.
それらが/ 19点で最大長である場合、このアドレスブロックのルートアナウンスがAS3から受け入れられると述べています。もちろん、これはとAS3は、より多くのアドレス空間を取得するときにあれば修正する必要があります。また、成長や変化する顧客ベースを持つISPのために、このメカニズムがうまくスケールしないことを再度明らかです。
route-set: AS2:RS-ROUTES:AS3 members: 7.7.0.0/16^16-19 changed: orange@ripe.net source: RIPE
ルート設定：AS2：RS-ROUTES：AS3のメンバー：7.7.0.0/16^16-19を変更：orange@ripe.netソース：RIPE
Figure 7: The route-set object
図7：ルートセットオブジェクト
Luckily RPSL supports the notion of a "route-set" which, as shown in Figure 7, can be used to specify the set of routes that will be accepted from a given customer. Given this set (and a similar one for AS4), the manager of AS2 can now filter on the address space that will be accepted from their customers by modifying the import lines in the AS2 aut-num object as shown in Figure 8.
幸いにもRPSLは、図7に示すように、「ルート・セット」の概念をサポートし、特定の顧客から受け入れられるルートのセットを指定するために使用することができます。このセット（およびAS4のための同様のもの）を与えられ、AS2の管理者は、今、図8に示すようにAS2 AUT-NUMオブジェクトにインポートラインを変更することにより、顧客から受け付けされるアドレス空間をフィルタリングすることができます。
import: from AS1 accept ANY import: from AS3 accept AS2:RS-ROUTES:AS3 import: from AS4 accept AS2:RS-ROUTES:AS4 export: to AS2:AS-CUSTOMERS announce ANY export: to AS1 announce AS2 AS2:AS-CUSTOMERS
インポート：AS1から任意のインポートを受け入れる：RS-ROUTES：AS3からAS2を受け入れるAS3のインポート：RS-ROUTES：AS4からAS2を受け入れるAS4エクスポート：AS2へ：顧客はAS-ANY輸出を発表：AS1へのAS2 AS2を発表：AS-顧客
Figure 8: Policy in the AS2 aut-num object for address based filtering on AS2 customers
図8：AS2の顧客のアドレスベースのフィルタリングのためのAS2のAUT-NUMオブジェクト内のポリシー
Note that this is now only slightly more complex than the example in Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object due to address space changes for a customer, and this filtering can be supported without any changes to the AS1 aut-num object. The additional complexity is due to the two route set names being different, otherwise we could have combined the two import statements into one. Please note that the set names are constructed hierarchically. The first AS number denotes whose sets these are, and the last AS number parameterize these sets for each peer. RPSL allows the peer's AS number to be replaced by the keyword PeerAS.
これはさらに、図6に、今だけ、もう少し複雑な例を以下であることに注意してください、何が原因顧客のアドレス空間の変化にAS2のAUT-NUMオブジェクトに変更する必要がなく、このフィルタリングはAS1を変更することなく、サポートすることができますAUT-NUMオブジェクト。追加の複雑さは、それ以外の場合は、我々は一つに2つのimport文を組み合わせることができた、2人のルートセット名が異なることによるものです。セット名を階層的に構築されていることに注意してください。 AS番号最初は、そのセットこれらはであり、最後のAS番号は、各ピアのこれらのセットをパラメータ化。 RPSLは、ピアのAS番号がキーワードPeerASで交換することができます。
Hence,
したがって、
import: from AS3 accept AS2:RS-ROUTES:PeerAS import: from AS4 accept AS2:RS-ROUTES:PeerAS
インポート：RS-ROUTES：AS3からAS2を受け入れるPeerASインポート：RS-ROUTES：AS4からAS2を受け入れるPeerAS
has the same meaning as the corresponding import statements in Figure 6. This lets us combine the two import statements into one as shown in Figure 9.
これは、図9に示すように、私たちは一つに2つのimport文をまとめることができます。図6に対応するimport文と同じ意味を持ちます。
import: from AS1 accept ANY import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS export: to AS2:AS-CUSTOMERS announce ANY export: to AS1 announce AS2 AS2:AS-CUSTOMERS
インポート：AS1からはANYインポートを受け入れる：AS2から：RS-ROUTES：顧客はAS-AS2を受け入れるPeerASエクスポート：AS2へ：AS-お客様はいかなる輸出を発表：AS1へのAS2 AS2を発表：AS-顧客を
Figure 9: Policy in the AS2 aut-num object using PeerAS
図9：PeerASを使用してAS2 AUT-NUMオブジェクト内のポリシー
In the above examples peerings were only given among ASes. However, the peerings may be described in much more detail by RPSL, where peerings can be specified between physical routers using IP addresses in the import and export attributes. Figure 10 shows a simple example in which AS1 and AS2 are connected to an exchange point IX. While AS1 has only one connection to the exchange point via a router interface with IP address 7.7.7.1, AS2 has two different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS may then define its routing policy in more detail by specifying its boundary router.
上記の例でピアリングのみのAS間で与えられました。しかし、ピアリングは、ピアリングは、インポートおよびエクスポート属性にIPアドレスを使用して、物理ルータ間で指定することができますRPSL、によってはるかに詳細に説明することができます。図10は、AS1とAS2は、交換点IXに接続された単純な例を示しています。 AS1は、IPアドレス7.7.7.1を持つルータのインタフェースを介して交換ポイントへの接続を1つだけ持っていますが、AS2は、IPアドレス7.7.7.2と7.7.7.3を持つ2つの異なる接続されています。最初のASは、その境界ルータを指定することにより、より詳細にそのルーティングポリシーを定義することができます。
+--------------------+ +--------------------+
| 7.7.7.1 |-----+ +-----| 7.7.7.2 |
| | | | | |
| AS1 | ======== | AS2 |
| | IX | | |
| | +-----| 7.7.7.3 |
+--------------------+ +--------------------+
Figure 10: Including interfaces in peerings definitions aut-num: AS1 import: from AS2 at 7.7.7.1 accept <^AS2+$>
図10：AS1インポート：AS2から7.7.7.1には<^ AS2 + $>受け入れるAUT-NUMピアリング定義のインタフェースを含みます
Because AS1 has only one connection to the exchange point in this example, this specification does not differ from that in which no boundary router is specified. However, AS1 might want to choose to accept only those announcements from AS2 which come from the router with IP address 7.7.7.2 and disregard those announcements from router 7.7.7.3. AS1 can specify this routing policy as follows:
AS1は、この例では交換ポイントにのみつの接続を有しているので、本明細書には、境界ルータが指定されていたものと変わりません。しかし、AS1は、IPアドレス7.7.7.2とルータから来るAS2からのみアナウンスを受け入れ、ルータ7.7.7.3からそれらのアナウンスを無視するように選択することもできます。次のようにAS1は、このルーティングポリシーを指定することができます。
aut-num: AS1 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2+$>
AUT-NUM：AS1のインポート：AS2 7.7.7.2から7.7.7.1には、<^ AS2 + $>受け入れ
By selecting certain pairs of routers in a peering specification, others can be denied. If no routers are included in a policy clause then it is assumed that the policy applies to all peerings among the ASes involved.
ピアリング仕様にルータの特定のペアを選択することで、他の人が拒否することができます。何のルーターがポリシー句に含まれていない場合、政策が関与のASの中のすべてのピアリングに適用されることが想定されます。
The specification of peerings among ASes is not limited to one router for each AS. In figure 10 one of the two connections of AS2 to the exchange point IX might be used as backup in case the other connection fails. Let us assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during regular operations, and router 7.7.7.3 as backup. In a router configuration this may be done by setting a local preference. The equivalent in RPSL is a corresponding action definition in the peering description. The action definitions are inserted directly before the accept keyword.
AS間のピアリングの仕様は、各ASに1つのルータに限定されるものではありません。図に交換ポイントIXにAS2の2つの接続の10一つは、他の接続が失敗した場合のバックアップとして使用されるかもしれません。私たちは、AS1は、バックアップとして、通常の操作中にルータAS2の7.7.7.2への接続、およびルータ7.7.7.3を使用したいと仮定しましょう。ルータコンフィギュレーションでは、これはローカルプリファレンスを設定することによって行うことができます。 RPSLの等価は、ピアリングの説明で対応するアクションの定義です。アクション定義を受け入れるキーワードの前に直接挿入されています。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10;
from AS2 7.7.7.3 at 7.7.7.1 action pref=20;
accept <^AS2+$>
pref is opposite to local-pref in that the smaller values are preferred over larger values. Actions may also be defined without specifying IP addresses of routers. If no routers are included in the policy clause then it is assumed that the actions are carried out for all peerings among the ASes involved.
県は、より小さい値が大きい値よりも優先されることをローカル・県と反対です。アクションはまた、ルータのIPアドレスを指定せずに定義されてもよいです。何のルーターがポリシー句に含まれていない場合、アクションが関与のAS間のすべてのピアリングのために行われているものとします。
In the previous example AS1 controls where it sends its traffic and which connection is used as backup. However, AS2 may also define a backup connection in an export clause:
それは、そのトラフィックを送信し、バックアップとして使用されている接続先の例のAS1を制御します。しかし、AS2も輸出句のバックアップ接続を定義することができます。
aut-num: AS2
export: to AS1 7.7.7.1 at 7.7.7.2 action med=10;
to AS1 7.7.7.1 at 7.7.7.3 action med=20;
announce <^AS2+$>
The definition given here for AS2 is the symmetric counterpart to the routing policy of AS1. The selection of routing information is done by setting the multi exit discriminator metric med. Actually, med metrics will not be used in practice like this; they are more suitable for load balancing including backups. For more details on med metrics refer to the BGP-4 RFC [7]. To use the med to achieve load balancing, one often sets it to the "IGP metric". This is specified in RPSL as:
AS2のためにここに与えられた定義は、AS1のルーティングポリシーに左右対称の対応です。ルーティング情報の選択は、マルチ出口弁別メトリックMEDを設定することによって行われます。実際には、MEDメトリックは次のように実際には使用されません。彼らは、バックアップを含む負荷分散のために、より適しています。 MEDメトリックの詳細については、BGP-4 RFC [7]を参照。ロードバランシングを実現するために、MEDを使用するためには、多くの場合、「メトリックIGP」に設定します。これは次のようにRPSLで指定されています。
aut-num: AS2 export: to AS1 action med=igp_cost; announce <^AS2+$>
AUT-NUM：AS2エクスポート：AS1アクションにMED = igp_cost。 <^ AS2 + $>を発表
Hence, both routers will set the med to the IGP metric at that router, causing some routes to be preferred at one of the routers and other routes at the other router.
したがって、両方のルータは、いくつかのルートが他のルータのルータと他の経路の一方に好ましいことが原因と、そのルータにIGPメトリックにmedが設定されます。
RFC 1998 [9] describes the use of the BGP community attribute to provide support for load balancing and backup connections of multi-homed autonomous systems. In this section, we use stepwise refinement of an example to illustrate how those policies might be specified using RPSL.
RFC 1998 [9]ロード・バランシングおよびマルチホーム自律システムのバックアップ接続のためのサポートを提供するために、BGPコミュニティ属性の使用を記載しています。このセクションでは、これらのポリシーは、RPSLを使用して指定されるかもしれない方法を説明するために例の段階的詳細化を使用します。
The basic premise of RFC 1998 is to use the BGP community attribute to allow a customer to configure the BGP "LOCAL_PREF" on a provider's routers. This will allow the customer to influence the provider's route selection, normally by lowering the BGP "LOCAL_PREF" to indicate backup arrangements.
RFC 1998の基本的な前提は、顧客がプロバイダのルータでBGP「ローカル優先」を設定できるようにするためにBGPコミュニティ属性を使用することです。これは、顧客が正常にバックアップアレンジを示すために、BGP「ローカル優先」を低下させることで、プロバイダのルート選択に影響を与えることができるようになります。
In this example, we illustrate how AS1 (the provider) might specify their policy so that a customer (AS4) connected to two of AS1's direct customers (AS2 and AS3) might signal to AS1 which connection is to be preferred.
この例では、我々は顧客AS1の直接顧客（AS2とAS3）のうちの2つに接続されている（AS4）は、接続が優先されるAS1に合図なるようAS1（プロバイダ）が彼らのポリシーを指定する方法を示しています。
AS1's base policy is to only accept routes from customers that are originated by the customer, or by the customer's customers. This leads to a policy such as:
AS1の基本方針は、顧客によって発信されている顧客から、または顧客の顧客によってルートを受け入れることです。これは、このような政策につながります：
aut-num: AS1 import: from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$> import: from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$> import: from AS5 accept AS5 AND <^AS5+$>
AUT-NUM：AS1のインポート：AS2から（AS2 OR AS4）を受け入れ、<^ AS2 + AS4 *の$>輸入：AS3から（AS3 OR AS4）を受け入れ、<^ AS3 + AS4 *の$>輸入：AS5からAS5を受け入れて、<^ AS5 + $>
Note that AS4 is a customer of AS2 and AS3, and AS5 does not have its own customers.
AS4は、AS2とAS3の顧客であることに注意してください、とAS5は独自の顧客を持っていません。
Now suppose we want to add some policy to describe that if a customer tags a route with community 1:1 then AS1 will act on this to reduce the BGP "LOCAL_PREF" by 10.
1その後、AS1は10でBGP「ローカル優先」を減らすために、この上で動作します：今、私たちは、顧客がコミュニティ1のルートをタグ付けした場合、その記述するためのいくつかのポリシーを追加するとします。
aut-num: AS1
import: from AS2
action pref=10;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
AND community.contains(1:1)
import: from AS2
action pref=0;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS3
action pref=10;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
AND community.contains(1:1)
import: from AS3
action pref=0;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS5
action pref=10;
accept AS5 AND <^AS5+$> AND community.contains(1:1)
import: from AS5
action pref=0;
accept AS5 AND <^AS5+$>
We can see here that basically we are adding identical statements for each peering to the policy. This is the ideal candidate for RPSL's refine statement. This will make the policy more concise and avoid some of the potential for errors as more peering statements are added in the future:
私たちは、基本的に、我々は各ポリシーにピアリングのために、同一のステートメントを追加していることをここで見ることができます。これは、RPSLの絞り込み声明のための理想的な候補です。これは、ポリシーをより簡潔にし、将来的に追加され、よりピアリングステートメントとしてエラーの可能性のいくつかを避けることができます：
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>;
from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>;
from AS5 accept AS5 AND <^AS5+$>;
}
Now, we can clearly see that any route that has been accepted from a customer that contains the community 1:1 will have it's local preference value reduced by 10.
1それは10に減少ローカルプリファレンス値ですがあります：今、我々は明らかにコミュニティ1が含まれている顧客から受け入れられた任意の経路があることがわかります。
The refinement has cleaned up some of the policy but we still have a large number of individual policies representing the same basic provider policy "from the customer, accept customer routes". These can be simplified by using AS sets.
洗練は、ポリシーの一部をクリーンアップしているが、我々はまだ同じ基本的なプロバイダポリシー表す個々の政策の多くの「顧客からの、顧客のルートを受け入れる」を持っています。これらは、セットとして使用することによって単純化することができます。
First, we will collect together all of AS1's customers into a single AS set, AS1:AS-CUSTOMERS. We use a hierarchical set name that start with AS1 to avoid possible set name clashes in IRR with other ASes:
AS-CUSTOMERS：まず、セット、AS1のような単一の中に一緒にAS1の顧客のすべてを収集します。私たちは、他のASとのIRRで可能なセット名前の衝突を避けるために、AS1で始まる階層的なセット名を使用します。
as-set: AS1:AS-CUSTOMERS members: AS2, AS3, AS5
セット：AS1：AS-CUSTOMERSメンバー：AS2、AS3、AS5
We also define one set for each customer which lists the AS numbers of any of their customers.
我々はまた、顧客のいずれかのAS番号を示している顧客ごとに1つのセットを定義します。
as-set: AS1:AS-CUSTOMERS:AS2 members: AS4
以下のように設定：AS1：AS-CUSTOMERS：AS2のメンバー：AS4
as-set: AS1:AS-CUSTOMERS:AS3 members: AS4
以下のように設定：AS1：AS-CUSTOMERS：AS3のメンバー：AS4
as-set: AS1:AS-CUSTOMERS:AS5 members: # AS5 has no customers yet, so keep blank for now
セット：AS1：AS-CUSTOMERS：AS5のメンバーます。＃AS5はまだ顧客を持っていないので、今のところは空白に保ちます
We can now use the keyword PeerAS with these AS sets to simplify the policy further:
私たちは今、さらにポリシーを簡単にするためにセットとしてこれらとキーワードPeerASを使用することができます。
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS1:AS-CUSTOMERS
accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS)
AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$>
}
The use of PeerAS with AS1:AS-CUSTOMERS is basically equivalent to looping over the members of AS1:AS-CUSTOMERS, expanding the policy by replacing PeerAS with a member from the set AS1:AS-CUSTOMERS.
AS1とPeerASの使用：AS-顧客はAS1のメンバーをループと基本的に等価である：セットAS1から部材とPeerASを置換することによって、ポリシーを拡大、 - 顧客など：・顧客など。
To illustrate how this policy might be utilised by AS4, we present the following policy fragment:
このポリシーはAS4で利用することができる方法を説明するために、我々は次のポリシーの断片を提示します：
aut-num: AS4 export: to AS2 action community.append(1:1); announce AS1 export: to AS3 announce AS1
AUT-NUM：AS4エクスポート：AS2にアクションcommunity.append（1：1）。 AS1の輸出を発表：AS3にAS1を発表
Here, AS4 is signalling AS1 to prefer the routes from AS3.
ここで、AS4は、AS3からのルートを好むAS1シグナリングされます。
3 Tools
3つのツール
In this section, we briefly introduce a number of tools which can be used to inspect data in the database, to determine optimal routing policies, and enter new data.
このセクションでは、我々は簡単に、データベース内のデータを検査するために最適なルーティングポリシーを決定するために、新しいデータを入力に使用できるツールの数を紹介します。
All the examples shown in the previous sections may well be edited by hand. They may be extracted one by one from the IRR using the whois program, edited, and then handed back to the registry robots. However, again the RAToolSet [6] provides a very nice tool which makes working with aut-num objects much easier: the aut-num object editor aoe.
前のセクションで示したすべての実施例は、十分に手で編集することができます。彼らは、WHOISプログラムを使用して、IRRから一つずつ抽出編集し、レジストリロボットに戻って渡されてもよいです。 AUT-NUMオブジェクトエディタAOE：しかし、再びRAToolSet [6]ははるかに簡単AUT-NUMオブジェクトでの作業になり非常に便利なツールを提供します。
The aut-num object editor has a graphical user interface to view and manipulate aut-num objects registered at any IRR. New aut-num objects may be generated using templates and submitted to the registries.
AUT-NUMオブジェクトエディタは、任意のIRRに登録AUT-NUMオブジェクトを表示および操作するためのグラフィカル・ユーザ・インターフェースを有します。新AUT-NUMオブジェクトは、テンプレートを使用して生成され、レジストリに提出することができます。
Moreover, the routing policy from the databases may be compared to real life peerings. Therefore, aoe is highly recommended as an interface to the IRR for aut-num objects. Further information on aoe is available together with the RAToolSet [6].
また、データベースからのルーティングポリシーは、実生活ピアリングと比較することができます。したがって、AOEは高度AUT-NUMオブジェクトのIRRへのインタフェースとして推奨されます。 AOEに関するさらなる情報は、RAToolSetと一緒に利用可能である[6]。
RtConfig is a tool developed by the Routing Arbiter project [8] to generate vendor specific router configurations from the policy data held in the various IRRs. RtConfig currently supports Cisco, gated and RSd configuration formats. It has been publicly available since late 1994, and is currently being used by many sites for router configuration. The next section describes a methodology for generating vendor specific router configurations using RtConfig (2).
RtConfig [8]種々のIRRに保持されているポリシーデータからベンダー固有のルータ設定を生成するために、ルーティングアービタプロジェクトによって開発されたツールです。 RtConfigは現在、シスコ、ゲーティングおよびRSDの構成形式をサポートしています。これは、1994年後半以来、一般に公開されており、現在、ルータ設定のための多くのサイトで使用されています。次のセクションでは、RtConfig（2）を使用して、ベンダー固有のルータ設定を生成するための方法を記載しています。
The general paradigm for using RtConfig involves registering policy in an IRR, building a RtConfig source file, then running running RtConfig against the source file and the IRR database to create vendor specific router configuration for the specified policy. The source file will contain vendor specific commands as well as RtConfig commands. To make a source file, pick up one of your router configuration files and replace the vendor specific policy configuration commands with the RtConfig commands.
RtConfigを使用するための一般的なパラダイムは、IRRにポリシーを登録RtConfigソースファイルをビルドし、ソースファイルと指定したポリシーのためのベンダ固有のルータの設定を作成するには、IRRデータベースに対してRtConfigを実行している実行しているが含まれます。ソースファイルは、ベンダー固有のコマンドと同様にRtConfigコマンドが含まれています。 、ソースファイルを作成し、ルーターの構成ファイルの1つをピックアップし、RtConfigコマンドでベンダー固有のポリシー設定コマンドを交換します。
Commands beginning with @RtConfig instruct RtConfig to perform special operations. An example source file is shown in Figure 11. In this example, commands such as "@RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2" instruct RtConfig to generate vendor specific import policies where the router 198.32.162.1 in AS3582 is importing routes from router 198.32.162.2 in AS3701. The other @RtConfig commands instruct the RtConfig to use certain names and numbers in the output that it generates (please refer to RtConfig manual [8] for additional information).
@RtConfigで始まるコマンドは、特別な操作を実行するためにRtConfigを指示します。例えば、ソースファイルは、この例では、図11に示されている、そのような「@RtConfigインポートAS3582 198.32.162.1 AS3701 198.32.162.2」AS3582のルータ198.32.162.1からルートをインポートしているベンダー固有のインポート・ポリシーを生成するRtConfigを指示するように命令しますAS3701のルータ198.32.162.2。他の@RtConfigコマンドはRtConfigは（詳細については、[8]マニュアルRtConfigを参照）、それが生成する出力の特定の名前と番号を使用するように指示します。
Once a source file is created, the file is processed by RtConfig (the default IRR is the RADB, and the default vendor is Cisco; however, command line options can be used to override these values). The result of running RtConfig on the source file in Figure 11 is shown in Figure 19 in Appendix B.
ソースファイルが作成されると、ファイルがRtConfig（;ただし、コマンドラインオプションは、これらの値を上書きするために使用することができ、デフォルトのIRRはRADBで、デフォルトのベンダーはCiscoです）によって処理されます。図11のソースファイルにRtConfigを実行した結果は、付録Bに、図19に示されています
router bgp 3582 network 128.223.0.0 ! ! Start with access-list 100 ! @RtConfig set cisco_access_list_no = 100 ! ! NERO neighbor 198.32.162.2 remote-as 3701 @RtConfig set cisco_map_name = "AS3701-EXPORT" @RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2 @RtConfig set cisco_map_name = "AS3701-IMPORT" @RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2 ! ! WNA/VERIO neighbor 198.32.162.6 remote-as 2914 @RtConfig set cisco_map_name = "AS2914-EXPORT" @RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6 @RtConfig set cisco_map_name = "AS2914-IMPORT" @RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6
3582ネットワーク128.223.0.0 BGPルータ！ ！アクセスリスト100で開始！ @RtConfigはcisco_access_list_no = 100を設定しました！ ！ NEROの隣人198.32.162.2リモート-として3701 @RtConfigはcisco_map_name = "AS3701-EXPORT" @RtConfig輸出AS3582 AS3701 198.32.162.1 198.32.162.2 @RtConfig設定cisco_map_name = "AS3701-IMPORT" @RtConfig輸入AS3582に198.32.162.1 AS3701 198.32を設定します。 162.2！ ！ WNA / VERIO隣接198.32.162.6リモート-として2914 @RtConfig設定cisco_map_name = "AS2914-EXPORT" @RtConfig輸出AS3582 198.32.162.6 @RtConfigがcisco_map_name = "AS2914-IMPORT" @RtConfigインポートAS3582 AS2914 198.32.162.1設定198.32.162.1 AS2914 198.32.162.6
Figure 11: RtConfig Template File
図11：RtConfigテンプレートファイル
A RPSL Database Objects
RPSLのデータベース・オブジェクト
In this appendix, we introduce the RPSL objects required to implement many
typical Internet routing policies. RFC-2622 and RIPE-157 provide the
authoritative description for these objects and for the RPSL syntax, but
this appendix will often be sufficient in practice.
The frequently needed objects are:
頻繁に必要とされるオブジェクトは、次のとおりです。
o maintainer objects (mntner)
Oの保守オブジェクト（のmntner）
o autonomous system number objects (aut-num)
O自律システム番号オブジェクト（AUT-NUM）
o route objects (route)
Oルートオブジェクト（ルート）
o set objects (as-set, route-set)
Oオブジェクトを設定する（設定されたままの、ルートセット）
and they are described in the following sections. To make your routing policies and configuration public, these objects should be registered in exactly one of the IRR registries.
そして彼らは、次のセクションで説明されています。あなたのルーティングポリシーと設定を公開するには、これらのオブジェクトは、IRRレジストリの正確に一つに登録する必要があります。
In general, you can register your information by sending the appropriate objects to an email address for the registry you use. The email should consist of the objects you want to have registered or modified, separated by empty lines, and preceded by some kind of authentication details (see below). The registry robot processes your mail and enters new objects into the database, deletes old ones (upon request), or makes the requested modifications.
一般的には、あなたが使用して、レジストリのための電子メールアドレスに適切なオブジェクトを送信することによって、あなたの情報を登録することができます。電子メールは、あなたが登録したり、空行で区切られ、修正、および認証の詳細（下記参照）のいくつかの種類が先行しているしたいオブジェクトで構成する必要があります。レジストリロボットがあなたのメールを処理し、データベースに新しいオブジェクトを入力し、（要求に応じて）古いものを削除、または要求された変更を行います。
You will receive a response indicating the status of your submission. As the emails are handled automatically, the response is generally very fast. However, it should be remembered that a significant number of updates are also sometimes submitted to the database (by other robots), so the response time cannot be guaranteed. The email addresses for submitting objects to the existing registries are listed in Figure 12.
あなたの提出の状態を示す応答を受信します。電子メールが自動的に処理されると、応答は一般的に非常に高速です。しかし、更新のかなりの数も時々（他のロボットによって）データベースに送信されるので、応答時間が保証できないことに留意すべきです。既存のレジストリにオブジェクトを提出するための電子メールアドレスは、図12に記載されています。
ANS auto-dbm@ans.net
CANET auto-dbm@canet.net
CW auto-rr@cw.net
RADB auto-dbm@ra.net
RIPE auto-dbm@ripe.net
Figure 12: Email addresses to register policy objects in IRR.
図12：IRRでポリシーオブジェクトを登録するための電子メールアドレス。
Because it is required that a maintainer be specified in many of the database objects, a mntner is usually the first to be created. To have it properly authenticated, a mntner object is added manually by registry staff. Thereafter, all database submissions, deletions and modifications should be done through the registry robot.
それはメンテナがデータベースオブジェクトの多くに指定しておく必要があるので、のmntnerを作成するために最初は普通です。それが正しく認証されているために、のmntnerオブジェクトは、レジストリのスタッフが手動で追加されます。その後、すべてのデータベースの投稿、削除や修正がレジストリロボットを介して行われるべきです。
Each of the registries can provide additional information and support for users. For the public registries this support is available from the email addresses listed in Figure 13.
レジストリのそれぞれには、ユーザーのための追加情報やサポートを提供することができます。公共の登録簿のために、このサポートは、図13に記載されている電子メールアドレスから入手可能です。
RADB db-admin@ra.net
RIPE ripe-dbm@ripe.net
Figure 13: Support email addresses.
図13：電子メールアドレスをサポートしています。
If you are using one of the private registries, your service provider should be able to address your questions.
あなたはプライベートレジストリのいずれかを使用している場合は、サービスプロバイダは、あなたの質問に対処することができるはずです。
A.1 The Maintainer Object
メンテナオブジェクトA.1
The maintainer object is used to introduce some kind of authorization for registrations. It lists various contact persons and describes security mechanisms that will be applied when updating objects in the IRR. Registering a mntner object is the first step in creating policies for an AS. An example is shown in Figure 14. The maintainer is called MAINT-AS3701. The contact person here is the same for administrative (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle DMM65. NIC-handles are unique identifiers for persons in registries. Refer to registry documentation for further details on person objects and usage of NIC-handles.
メンテナオブジェクトは、登録のための認可のいくつかの種類を導入するために使用されます。これは、様々な接触者をリストし、IRR内のオブジェクトを更新する際に適用されるセキュリティメカニズムを説明しています。 mntnerオブジェクトを登録すると、ASのポリシーを作成するための最初のステップです。例が図14に示されている保守者はMAINT-AS3701と呼ばれます。ここでの接触者は、管理者（admin-C）と技術（ハイテクc）の問題についても同様であるとNIC-ハンドルDMM65によって参照されます。 NIC-ハンドルはレジストリにいる人のためのユニークな識別子です。人物オブジェクトとNIC-ハンドルの使用方法の詳細については、ドキュメントをレジストリを参照してください。
The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. CRYPT-PW takes as its argument a password that is encrypted with Unix crypt (3) routine. When sending updates, the maintainer adds the field password: <cleartext password> to the beginning of any requests that are to be authenticated. MAIL-FROM takes an argument that is a regular expression which covers a set of mail addresses. Only users with any of these mail addresses are authorized to work with objects secured by the corresponding maintainer (3).
CRYPT-PWおよびMAIL-FROM：例では、2つの認証メカニズムを示します。 CRYPT-PWは、引数としてのUnixのcrypt（3）ルーチンで暗号化されたパスワードを取ります。 <クリアテキストのパスワード>認証されるすべての要求の先頭に：アップデートを送信すると、メンテナは、フィールドのパスワードを追加します。 MAIL FROM-は、メールアドレスのセットをカバーする正規表現である引数を取ります。これらのメールアドレスのいずれかを持つユーザーのみが該当するメンテナ（3）で固定オブジェクトを操作することが許可されています。
The security mechanisms of the mntner object will only be applied on those objects referencing a specific mntner object. The reference is done by adding the attribute mnt-by to an object using the name of the mntner object as its value. In Figure 14, the maintainer MAINT-AS3701 is maintained by itself.
mntnerオブジェクトのセキュリティメカニズムは、特定のmntnerオブジェクトを参照するそれらのオブジェクトに適用されます。参照は、その値としてのmntnerオブジェクトの名前を使用して、オブジェクトに属性MNTごとを添加することによって行われます。図14においては、保守のMAINT-AS3701は、それ自体によって維持されます。
mntner: MAINT-AS3701 descr: Network for Research and Engineering in Oregon remark: Internal Backbone admin-c: DMM65 tech-c: DMM65 upd-to: noc@nero.net auth: CRYPT-PW 949WK1mirBy6c auth: MAIL-FROM .*@nero.net notify: noc@nero.net mnt-by: MAINT-AS3701 changed: meyer@antc.uoregon.edu 970318 source: RADB
mntner：MAINT-AS3701のDESCR：オレゴン州の発言の研究や工学ネットワーク：内部バックボーン管理者-C：DMM65ハイテク-C：DMM65 UPD-へ：noc@nero.net AUTH：CRYPT-PW 949WK1mirBy6c払い：MAIL-FROM * @ nero.netは通知：noc@nero.net MNTバイ：MAINT-AS3701は、変更された：RADB：970318ソースをmeyer@antc.uoregon.edu
Figure 14: Maintainer Object
図14：メンテナオブジェクト
A.2 The Autonomous System Object
自律システムオブジェクトA.2
The autonomous system object describes the import and export policies of an AS. Each organization registers an autonomous system object (aut-num) in the IRR for its AS. Figure 15 shows the aut-num for AS3582 (UONET).
自律システムオブジェクトは、ASのポリシーのインポートおよびエクスポートについて説明します。各組織は、そのASのためのIRRで自律システムオブジェクト（AUT-NUM）を登録します。図15は、AS3582（UONET）用AUT-NUMを示します。
The autonomous system object lists contacts (admin-c, tech-c) and is maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in Figure 14.
自律システム・オブジェクトは、コンタクト（ADMIN-C、技術-c）をリストし、図14に表示される保守ある（MNT-によって）MAINT-AS3701によって維持されます。
The most important attributes of the aut-num object are import and export. The import clause of an aut-num specifies import policies, while the export clause specifies export policies. The corresponding clauses allow a very detailed description of the routing policy of the AS specified. The details are given in section 2.
AUT-NUMオブジェクトの最も重要な属性は、インポートおよびエクスポートされています。輸出句は、エクスポートポリシーを指定しながら、AUT-NUMの輸入節は、インポートポリシーを指定します。対応する句はとして指定のルーティングポリシーの非常に詳細な記述を可能にします。詳細はセクション2に記載されています。
With these clauses, an aut-num object shows its relationship to other autonomous systems by describing its peerings. In addition, it also defines a routing entity comprising a group of IP networks which are handled according to the rules defined in the aut-num object. Therefore, it is closely linked to route objects.
これらの句と、AUT-NUMオブジェクトは、ピアリングを記述することにより、他の自律システムとの関係を示しています。加えて、それはまた、AUT-NUMオブジェクト内に定義された規則に従って処理されるIPネットワークのグループを含むルーティング・エンティティを定義します。したがって、それは密接にルートオブジェクトにリンクされています。
In this example, AS3582 imports all routes from AS3701 by using the keyword ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. The import policy for for AS2914 is slightly more complex. Since AS2914 provides transit to various other ASes, AS3582 accepts routes with ASPATHs that begin with AS2194 followed by members of AS-WNA, which is an as set (see section A.4.1 below) describing those customers that transit AS2914.
この例では、ANYキーワードを使用して、AS3701からAS3582の輸入のすべてのルート。 AS3582輸入AS4222、AS5650、およびAS1798からのみ内部ルート。 AS2914のための輸入政策は少し複雑です。 AS2914は、様々な他のASへのトランジットを提供するため、AS3582は、トランジットAS2914もの顧客を記述する集合としてであるAS-WNAのメンバー（以下、セクションA.4.1を参照）、続いAS2194で始まるASPATHs持つルートを受け付けます。
Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), its export policy consists simply of "announce AS3582" clauses; that is, announce internal routes of AS3582. These routes are those in route objects where the origin attribute is AS3582.
AS3582（すなわち、それはトランジットを提供していない）のようなマルチホームスタブがあるため、その輸出政策は、単に句「AS3582を発表」から成ります。つまり、AS3582の内部ルートを発表。これらのルートは、元の属性がAS3582であるルートオブジェクトのものです。
aut-num: AS3582 as-name: UONET descr: University of Oregon, Eugene OR import: from AS3701 accept ANY import: from AS4222 accept <^AS4222+$> import: from AS5650 accept <^AS5650+$> import: from AS2914 accept <^AS2914+ (AS-WNA)*$> import: from AS1798 accept <^AS1798+$> export: to AS3701 announce AS3582 export: to AS4222 announce AS3582 export: to AS5650 announce AS3582 export: to AS2914 announce AS3582 export: to AS1798 announce AS3582 admin-c: DMM65 tech-c: DMM65 notify: nethelp@ns.uoregon.edu mnt-by: MAINT-AS3582 changed: meyer@antc.uoregon.edu 970316 source: RADB
AUT-NUM：として名AS3582：UONETのDESCR：オレゴン大学、オレゴン州ユージーンインポート：AS3701から任意のインポートを受け入れる：AS4222から<^ AS4222 + $>インポートを受け入れる：AS5650から<^ AS5650 + $>インポートを受け入れる：AS2914から受け入れます< ^ AS2914 + * $>インポート（ - WNA AS）：AS1798から<^ AS1798 + $>輸出を受け入れる：AS3701 AS3582輸出を発表する：AS4222 AS3582輸出を発表する：AS5650 AS3582輸出を発表する：AS2914 AS3582輸出を発表する：AS1798は、AS3582を発表します管理者-C：DMM65ハイテク-C：DMM65が通知：nethelp@ns.uoregon.edu MNT-によって：MAINT-AS3582を変更：RADB：970316ソースをmeyer@antc.uoregon.edu
Figure 15: Autonomous System Object
図15：自律システムオブジェクト
The aut-num object forms the basis of a scalable and maintainable router
AUT-NUMオブジェクトは、拡張性と保守性ルータの基本となります
route: 128.223.0.0/16 origin: AS3582 descr: UONet descr: University of Oregon descr: Computing Center descr: Eugene, OR 97403-1212 descr: USA mnt-by: MAINT-AS3582 changed: meyer@ns.uoregon.edu 960222 source: RADB
ルート：128.223.0.0/16原産地：AS3582のDESCR：UONet DESCR：オレゴンDESCRの大学：コンピューティングセンターのDESCR：オレゴン州ユージーン97403から1212 DESCR：USA MNT-によって：MAINT-AS3582は変更：960222をmeyer@ns.uoregon.eduソース：RADB
Figure 16: Example of a route object
図16：ルート・オブジェクトの例
configuration system. For example, if AS3582 originates a new route, it need only create a route object for that route with origin AS3582. AS3582 can now build configuration using this route object without changing its aut-num object.
コンフィギュレーションシステム。 AS3582は、新しいルートを発信した場合、それが唯一の原点AS3582とそのルートのルートオブジェクトを作成する必要があります。 AS3582は現在、AUT-NUMオブジェクトを変更することなく、このルートオブジェクトを使用して構成を構築することができます。
Similarly, if for example, AS3701 originates a new route, it need only create a route object for that route with origin AS3701. Both AS3701 and AS3582 can now build configuration using this route object without modifying its aut-num object.
例えば、AS3701は、新しいルートを発信する場合も同様に、それが唯一の原点AS3701とそのルートのためのルートオブジェクトを作成する必要があります。どちらのAS3701とAS3582は現在、AUT-NUMオブジェクトを変更することなく、このルートオブジェクトを使用して構成を構築することができます。
A.3 The Route Object
ルートオブジェクトA.3
In contrast to aut-num objects which describe propagation of routing information for an autonomous system as a whole, route objects define single routes from an AS. An example is given in Figure 16.
AUT-NUMする全体としての自律システムのためのルーティング情報の伝搬を記述するオブジェクトがこれとは対照的に、ルートオブジェクトはASから単一のルートを定義します。例えば、図16に示されています。
This route object is maintained by MAINT-AS3582 and references AS3582 by the origin attribute. By this reference it is grouped together with other routes of the same origin AS, becoming member of the routing entity denoted by AS3582. The routing policies can then be defined in the aut-num objects for this group of routes.
このルートオブジェクトはMAINT-AS3582と原点属性によってAS3582参照によって維持されています。この参照によりそのAS3582によって示さルーティングエンティティのメンバーになると同じ起源の他のルートと一緒にグループ化されます。ルーティングポリシーは、次いで、ルートのこのグループのAUT-NUMオブジェクトに定義することができます。
Consequently, the route objects give the routes from this AS which are distributed to peer ASes according to the rules of the routing policy. Therefore, for any route in the routing tables of the backbone routers a route object must exist in one of the registries in IRR. route objects must be registered in the IRR only for the routes seen outside your AS. Normally, this set of external routes is different from the routes internally visible within your AS. One of the major reasons is that external peers need no information at all about your internal routing specifics. Therefore, external routes are in general aggregated combinations of internal routes, having shorter IP prefixes where applicable according to the CIDR rules. Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is strongly recommended that you aggregate your routes as much as possible, thereby minimizing the number of routes you inject into the global routing table and at the same time reducing the corresponding number of route objects in the IRR.
したがって、ルートオブジェクトはルーティングポリシーの規則に従ってのASをピアに配布され、このASからのルートを与えます。したがって、バックボーンルータのルーティングテーブル内のすべてのルートのルートオブジェクトは、IRRにレジストリのいずれかに存在しなければなりません。ルートオブジェクトは、あなたのAS外に見えるルートのIRRに登録する必要があります。通常、外部ルートのこのセットは、あなたのAS内で内部的に見えるのルートは異なっています。主な理由の1つは、外部ピアがすべてであなたの内部ルーティング仕様に関する情報を必要としないということです。したがって、外部経路は、CIDR規則に従って該当する短いIPプレフィックスを有する、内部ルートの一般的な集約の組み合わせです。 CIDRのチュートリアルの導入のための[5] CIDR FAQを参照してください。強くあなたは、それによってあなたはIRRでグローバルルーティングテーブルに注入すると同時に、ルートオブジェクトの対応する数を減らすルートの数を最小限に抑え、可能な限り、あなたのルートを集約することをお勧めします。
While you may easily query single route objects using the whois program, and submit objects via mail to the registry robots, this becomes kind of awkward for larger sets. The RAToolSet [6] offers several tools to make handling of route objects easier. If you want to read policy data from the IRR and process it by other programs, you might be interested in using peval which is a low level policy evaluation tool. As an example, the command
あなたは簡単にWHOISプログラムを使用して、1つのルートオブジェクトを照会し、レジストリロボットにメールでオブジェクトを提出することができるが、これは一種の厄介な大きなセットのためになります。 RAToolSetは、[6]ルートオブジェクトの取り扱いを簡単にするためにいくつかのツールを提供しています。あなたはIRRからポリシーデータを読み込み、他のプログラムでそれを処理したい場合は、低レベルの政策評価ツールですpevalを使用することに興味があるかもしれません。一例として、コマンド
peval -h whois.ra.net AS3582
peval -h whois.ra.net AS3582
will give you all route objects from AS3582 registered with RADB.
あなたのRADBに登録AS3582からのすべてのルートオブジェクトを提供します。
A much more sophisticated tool from the RAToolSet to handle route objects interactively is the route object editor roe. It has a graphical user interface to view and manipulate route objects registered at any IRR. New route objects may be generated from templates and submitted to the registries. Moreover, the route objects from the databases may be compared to real life routes. Therefore, roe is highly recommended as an interface to the IRR for route objects. Further information on peval and roe is available together with the RAToolSet [6].
対話的にルート・オブジェクトを処理するためにRAToolSetからはるかに洗練されたツールは、ルートオブジェクトエディタ卵です。これは、任意のIRRに登録ルートオブジェクトを表示および操作するためのグラフィカル・ユーザ・インターフェースを有します。新しいルートオブジェクトは、テンプレートから生成され、レジストリに提出することができます。また、データベースからのルートオブジェクトは、実際のルートと比較することができます。したがって、卵は非常にルートオブジェクトのIRRへのインタフェースとして推奨されます。 pevalおよび卵についてのさらなる情報は、RAToolSetと一緒に利用可能である[6]。
A.4 Set Objects
A.4セットオブジェクト
With routing policies it is often necessary to reference groups of autonomous systems or routes which have identical properties regarding a specific policy. To make working with such groups easier RPSL allows to combine them in set objects. There are two basic types of predefined set objects, as-set, and route-set. The RPSL set objects are described below.
ルーティングポリシーでは、特定のポリシーについては、同一の特性を有する自律システムまたは経路のグループを参照することがしばしば必要です。そのようなグループが容易RPSLで操作できるようにするには、設定されたオブジェクトでそれらを組み合わせることができます。事前に定義されたように、設定された設定オブジェクト、およびルートセットの2つの基本タイプがあります。 RPSL設定オブジェクトは、以下に記載されています。
A.4.1 AS-SET Object
A.4.1 AS-SETオブジェクト
Autonomous system set objects (as-set) are used to group autonomous system objects into named sets. An as-set has an RPSL name that starts with "AS-". In the example in Figure 17, an as-set called AS-NERO-PARTNERS and containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set is the RPSL replacement for the RIPE-181 as-macro. It has been extended to include ASes in the set indirectly by referencing as set names in the aut-num objects.
自律システムセットオブジェクトは、（設定されたままの）自律システムは、名前付きセットにオブジェクトをグループ化するために使用されます。セット「AS-」で始まるRPSL名を持っています。図17の例では、AS-セットAS-NERO-PARTNERS及びAS3701、AS4201、AS3582、AS4222を含有呼ば、AS1798が定義されます。セットとしてマクロRIPE-181のためのRPSL置換です。 AUT-NUMオブジェクトでセット名として参照することにより、間接的に設定してのASを含むように拡張されました。
AS-SETs are particularly useful when specifying policies for groups such as customers, providers, or for transit. You are encouraged to register sets for these groups because it is most likely that you will treat them alike, i.e. you will have a very similar routing policy for all your customers which have an autonomous system of their own. You may as well discover that this is also true for the providers you are peering with, and it is most convenient to have the ASes combined in one as-set for which you offer transit. For example, if a transit provider specifies its import policy using its customer's as-set (i.e., its import clause for the customer contains the customer's as-set), then that customer can modify the set of ASes that its transit provider accepts from it. Again, this can be accomplished without requiring the customer or the transit provider to modify its aut-num object.
こうした顧客、プロバイダなどのグループのために、またはトランジットのためのポリシーを指定するときにAS-セットは特に有用です。あなたが同様にそれらを扱う可能性が最も高いので、あなたは、これらのグループのためのセットを登録することが奨励されている、すなわち、あなたは自分自身の自律システムを持っているすべての顧客のために非常に類似したルーティングポリシーを持っています。あなたにも、これはまた、あなたとピアリングしているプロバイダにとって真実であることを発見することができ、あなたがトランジットを提供しているために設定として-1で結合のASを持つことが最も便利です。トランジットプロバイダーは（すなわち、顧客のためにその輸入句は、顧客のように、セットが含まれています）その顧客のAS-セットを使用して、その輸入ポリシーを指定した場合、その顧客はそのトランジットプロバイダはそれから受け入れることのASのセットを変更することができます。再び、これは、AUT-NUMオブジェクトを変更するために、顧客またはトランジット・プロバイダを必要とせずに達成することができます。
as-set: AS3582:AS-PARTNERS members: AS3701, AS4201, AS3582, AS4222, AS1798
セット：AS3582：AS-PARTNERSメンバー：AS3701、AS4201、AS3582、AS4222、AS1798
Figure 17: as-set Object
図17：オブジェクトを設定するように、
The ASes of the set are simply compiled in a comma delimited list following the members attribute of the as-set. This list may also contain other AS-SET names.
セットののASは、単にメンバーがAS-セットの属性で、次のカンマ区切りのリストにまとめられています。このリストには、他のAS-SETの名前が含まれていてもよいです。
A.4.2 ROUTE-SET Object
A.4.2 ROUTE-SETオブジェクト
A route-set is a way to name a group of routes. The syntax is similar to the as-set. A route-set has an RPSL name that starts with "RS-". The members attribute lists the members of the set. The value of a members attribute is a list of address prefixes, or route-set names. The members of the route-set are the address prefixes or the names of other route sets specified.
ルートセットは、ルートのグループに名前を付ける方法です。構文は次のとおりとして、セットに似ています。ルートセットは、「RS-」で始まるRPSL名を持っています。メンバーはリストにセットのメンバーを属性。属性メンバーの値は、アドレスプレフィックス、またはルート・セット名のリストです。ルートセットのメンバーは、アドレスプレフィックスまたは指定された他のルートセットの名前です。
Figure 18 presents some example route-set objects. The set rs-uo contains two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The set rs-bar contains the members of the set rs-uo and the address prefix 128.7.0.0/16. The set rs-martians illustrate the use of range operators. 0.0.0.0/0^32 are the length 32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+ are the more specifics of 224.0.0.0/3, i.e. the routes falling into the multicast address space. For more complete list of range operators please refer to RFC-2622.
図18は、いくつかの例示的ルートセットオブジェクトを提示します。セットrs-UOは、2つのアドレスのプレフィックス、すなわち128.223.0.0/16と198.32.162.0/24が含まれています。セットrs-バーがセットrs-UOとアドレスプレフィックス128.7.0.0/16のメンバーが含まれています。セットRS-火星は、範囲演算子の使用を示します。 0.0.0.0/0^32は0.0.0.0/0の長さ32のより仕様、すなわちホストルートです。 224.0.0.0/3のより具体的、マルチキャストアドレス空間に落下すなわちルートは224.0.0.0/3^+あります。範囲演算子のより完全なリストについては、RFC-2622を参照してください。
route-set: rs-uo members: 128.223.0.0/16, 198.32.162.0/24
ルート設定：RS-UOメンバー：128.223.0.0/16、198.32.162.0/24
route-set: rs-bar members: 128.7.0.0/16, rs-uo
ルート設定：RS-バー部材：128.7.0.0/16、RS-UO
route-set: rs-martians remarks: routes not accepted from any peer members: 0.0.0.0/0, # default route 0.0.0.0/0^32, # host routes 224.0.0.0/3^+, # multicast routes 127.0.0.0/8^9-32, . . .
ルート設定：RS-火星人の発言：どのピアメンバーから受け入れられない路線：0.0.0.0/0、＃デフォルトルート0.0.0.0/0^32、＃ホストルート224.0.0.0/3^+、＃マルチキャストルーティング127.0。 0.0 / 8 ^ 9-32、。 。 。
Figure 18: route-set Objects
図18：ルートセットオブジェクト
B Output of RtConfig: An Example
RtConfigのB出力：例
In Figure 19, you see the result of running RtConfig on the source
file in Figure 11.
router bgp 3582 network 128.223.0.0 ! ! NERO neighbor 198.32.162.2 remote-as 3701
3582ネットワーク128.223.0.0 BGPルータ！ ！ NEROの隣人198.32.162.2リモートとして3701
no access-list 100 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! no route-map AS3701-EXPORT route-map AS3701-EXPORT permit 1 match ip address 100 ! router bgp 3582 neighbor 198.32.162.2 route-map AS3701-EXPORT out ! no route-map AS3701-IMPORT route-map AS3701-IMPORT permit 1 set local-preference 1000 ! router bgp 3582 neighbor 198.32.162.2 route-map AS3701-IMPORT in ! ! WNA/VERIO neighbor 198.32.162.6 remote-as 2914 ! no route-map AS2914-EXPORT route-map AS2914-EXPORT permit 1 match ip address 100 ! router bgp 3582 neighbor 198.32.162.6 route-map AS2914-EXPORT out no ip as-path access-list 100 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ |6188|6971|7790|7951|8028))?$ ! no route-map AS2914-IMPORT route-map AS2914-IMPORT permit 1 match as-path 100 set local-preference 998
何のアクセスリスト100のアクセスリスト100許可のIP 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0アクセスリストない100 IP 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255を拒否！何のルートマップAS3701-EXPORTルートマップAS3701-輸出許可1試合のIPアドレスがありません100！ルータBGP 3582隣人198.32.162.2ルートマップAS3701-EXPORTアウト！何のルートマップAS3701-IMPORTルートマップAS3701-IMPORT許可証1セットのローカル好みません1000年！ルータBGP 3582隣人198.32.162.2ルートマップAS3701-IMPORT中！ ！ WNA / VERIO隣接リモート-として2914 198.32.162.6！何のルートマップAS2914-EXPORTルートマップAS2914-輸出許可1試合のIPアドレスがありません100！ルータのBGP 3582隣人198.32.162.6ルートマップAS2914-EXPORTアウトは、no ip ASパスアクセスリスト100 IPなどのパスアクセスリスト100許可^ _2914（（（_ [0-9] +））* _ \（ 13 | 22 | 97 | 132 | 175 | 668 | 1914 | 2905 | 2914 | 3361 | 3381 | 3791 | 3937 | 4178 \ | 4354 | 4571 | 4674 | 4683 | 5091 | 5303 | 5798 | 5855 | 5856 | 5881 | 6083 \ | 6188 | 6971 | 7790 | 7951 | 8028））$？！ NOルートマップAS2914インポートルートマップAS2914-IMPORT許可1つのマッチしないとして、パス100を設定ローカルプリファレンス998
! router bgp 3582 neighbor 198.32.162.6 route-map AS2914-IMPORT in
！ルータBGP 3582隣人198.32.162.6ルートマップAS2914-IMPORTで
Figure 19: Output of RtConfig
図19：RtConfigの出力
Security Considerations
セキュリティの考慮事項
This document is a tutorial to RPSL, it does not define protocols or
standards that need to be secured.
Endnotes
文末
(1) AS-PATH regular expressions are POSIX compliant regular expressions.
（1）AS-PATHの正規表現は、POSIX準拠の正規表現です。
(2) Discussion of RtConfig internals is beyond the scope of this document.
（2）RtConfigの内部の説明は、この文書の範囲外です。
(3) Clearly, neither of these mechanisms is sufficient to provide strong authentication or authorization. Other public key (e.g., PGP) authentication mechanisms are available from some of the IRRs.
（3）明らかに、これらのメカニズムのいずれも強力な認証または認可を提供するのに十分です。他の公開鍵（例えば、PGP）認証メカニズムは、のIRRの一部から入手可能です。
References
リファレンス
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[1] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、マイヤー、D.、ベイツ、T.、Karrenberg、D.およびM.テルプストラ、「ルーティングポリシー仕様言語（RPSL） 」、RFC 2622、1999年6月。
[2] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P. and M. Terpstra, "Representation of IP Routing Policies in the RIPE database", Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.
[2]ベイツ、T.、Jouanigot、JM。、Karrenberg、D.、Lothberg、P.及びM.テルプストラ、 "RIPEデータベース内のIPルーティングポリシーの表現"、技術報告熟し-81、RIPE、RIPE NCC、アムステルダム、オランダ、1993年2月。
[3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[3] T.ベイツ、E. Gerich、J. Joncharay、J-M。 Jouanigot、D. Karrenberg、M.テルプストラ、及びJ.ゆいます。熟した-181ルーティングレジストリ、テクニカルレポートでIPルーティングポリシー、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月の表現。
[4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997.
[4] A. M. R.マギー。 RIPE NCCデータベースのドキュメント。テクニカルレポートRIPE-157、RIPE NCC、アムステルダム、オランダ、1997年5月。
[5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. http://www.ibm.net.il/~hank/cidr.html
[5]ハンクNussbacher。 CIDRよくある質問。テルアビブ大学とIBMイスラエル。 http://www.ibm.net.il/~hank/cidr.html
[6] The RAToolSet. http://www.ra.net/ra/RAToolSet/
[6] RAToolSetを。 http://www.ra.net/ra/RAToolSet/
[7] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994.
[7] Rekhter Y.とT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1654、1994年7月。
[8] RtConfig as part of the RAToolSet. http://www.ra.net/ra/RAToolSet/RtConfig.html
[8] RtConfig RAToolSetの一部として。 http://www.ra.net/ra/RAToolSet/RtConfig.html
[9] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-Home Routing", RFC 1998, August 1996.
[9]チェン、E.とT.ベイツ、「マルチホームルーティングでのBGPコミュニティ属性の応用」、RFC 1998、1996年8月。
Authors' Addresses
著者のアドレス
David Meyer Cisco Systems
デビッド・マイヤーシスコシステムズ
EMail: dmm@cisco.com
メールアドレス：dmm@cisco.com
Joachim Schmitz America On-Line
ヨアヒム・シュミッツアメリカ・オンライン
EMail: SchmitzJo@aol.com
メールアドレス：SchmitzJo@aol.com
Carol Orange RIPE NCC
キャロルオレンジRIPE NCC
EMail: orange@spiritone.com
メールアドレス：orange@spiritone.com
Mark Prior connect.com.au pty ltd
マーク・プライアーconnect.com.au Pty Ltdの
EMail: mrp@connect.com.au
メールアドレス：mrp@connect.com.au
Cengiz Alaettinoglu USC/Information Sciences Institute
チンギスAlaettinogl USC /情報科学研究所
EMail: cengiz@isi.edu
メールアドレス：cengiz@isi.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。