[要約] RFC 2650は、RPSL（Routing Policy Specification Language）の実践的な使用方法についてのガイドラインです。このRFCの目的は、RPSLを使用して効果的なルーティングポリシーを定義し、インターネットルーティングの管理を向上させることです。
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
実際にRPSLを使用します
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.
Copyright（c）The Internet Society（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.
このドキュメントは、ルーティングポリシー仕様言語（RPSL）を使用して、インターネットルーティングレジストリ（IRR）のルーティングポリシーを説明するためのチュートリアルです。RPSLを使用してさまざまなルーティングポリシーと構成を指定する方法、IRRでこれらのポリシーを登録する方法、およびベンダー固有のルーター構成を生成するためのルーティングポリシー分析ツールを使用してそれらを分析する方法について説明します。
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のチュートリアルであり、インターネットルーティングを理解しているが、RPSLとIRRに新しいインターネット/ネットワークサービスプロバイダー（ISP/NSP）エンジニアを対象としています。読者は、完全性については、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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、ルーティングポリシーのリポジトリです。現在、IRRリポジトリは、次のサイトで維持されている5つのリポジトリのセットです。カナダのCA*ネットレジストリ、アメリカ合衆国のANS、CW、RADBレジストリ、ヨーロッパのREGISTRISTRE。5つのリポジトリは独立して実行されます。ただし、各サイトは、そのデータを他のサイトと定期的に交換します（少なくとも1日に1回、10分ごとに頻繁に）。CW、CA*ネット、およびANSは、それぞれネットワークのルーティングポリシーとCW、CA*Net、および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つのレジストリをセットとして検査できます。このプラクティスは、データの矛盾にほぼ常に導かれるため、彼/彼女のデータを複数のレジストリに登録することを控える必要があります。データを解釈しようとしているユーザーは、（せいぜい）状況に残されています。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は、Ripe-181 [2、3]に基づいています。これは、IRRでルーティングポリシーと構成を登録するために使用される言語です。Ripe-181の運用上の使用は、実際に使用されているルーティングポリシーを表現することが時々難しい（または不可能な）ことを示しています。RPSLは、これらの欠点に対処し、必要に応じてさらに拡張できる言語を提供するために開発されました。RPSL Obsoletes 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つに登録されている1つ以上のデータベース「オブジェクト」で表されます。各データベースオブジェクトには、いくつかのルーティングポリシー情報と必要な管理データが含まれています。たとえば、ドメイン間メッシュでルーティングされたアドレスプレフィックスは、ルートオブジェクトで指定され、Aut-Numオブジェクトで指定されているASのピアリングポリシーが指定されます。データベースオブジェクトは、参照により互いに関連しています。たとえば、ルートオブジェクトは、発信される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説明：uonet説明：オレゴン大学説明：コンピューティングセンター説明：ユージン、または97403-1212説明：米国起源：AS3582 Mnt-byby：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]は、ルーティングレジストリデータの分析に使用できるツールのスイートです。ルーター（RTCONFIG）を構成するツール、インターネット上のパス（PRPATHおよびPRTRACEROUTE）を分析するツール、RPSLオブジェクト（ROE、AOE、PRCHECK）を比較、検証、登録するツールが含まれます。
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で説明されています。ただし、IRRオブジェクトに関する権威ある情報は、RFC-2622、および一般的なデータベースオブジェクト（人、役割、メンテナー）およびレジストリデータベースのクエリと更新に関する権威ある情報を求める必要があります。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
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の接続性を提供し、Transitに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のみで構成されるパス（^ in <^ as3 $>は、AS3がパスの最初のメンバーであり、AS3がパスで1回以上発生することを意味し、$はパスに存在する他のものがないことを意味します。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：隣接するASES。
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.
上記の例では、インポート属性の「Accept Any」は、AS2がAS1が送信する発表を受け入れ、エクスポート属性の「アナウンス」は、AS2がルーティングテーブルにあるルートがAS3に渡されることを示していることを示しています。。AS1がAS2に「Any」を発表すると仮定すると、AS2はAS1から完全なルーティングを取得しています。
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オブジェクト自体を考えてみましょう。これは、レジストリデータベースの1つに提出できる属性ラベルと値のセットであることに注意してください。この特定のオブジェクトは、熟したレジストリにある（または向かう）として指定されています（図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-by属性の値）で「維持されている」ことも注目に値します。Aut-Numオブジェクトはルーターの構成やその他の運用目的に使用される可能性があるため、読者はその内容の妥当性を期待できるようにする必要があります。したがって、MNTNERをAut-Numおよび他のほとんどのデータベースオブジェクトで指定する必要があります。つまり、ピアリングポリシーを登録する前にMNTNERオブジェクトを作成する必要があります。「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は一般に、顧客のネットワークのルートをTransit 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に同じサービスを提供したいと考えてください。明らかに、AS2（図2）のAut-Numオブジェクトのインポートラインとエクスポートラインを図4に示すものに簡単に変更するのは簡単です。
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
Figure 4: Policy for AS3 and AS4 in the AS2 as-num object
図4：AS2 AS-NumオブジェクトのAS3およびAS4のポリシー
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が選択的である場合、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の「As-Set」オブジェクトを使用することにより、これを大幅に簡素化できます。図5では、AS2の顧客について説明します。このセットを使用すると、図6に示すように、図2のポリシーを書き換えることができます。
as-set: AS2:AS-CUSTOMERS
members: AS3 AS4
changed: orange@ripe.net
source: RIPE
Figure 5: The as-set object
図5：ASセットオブジェクト
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
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*$>
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, and then 0 or more occurrences of any AS2 customer (e.g. any member of the as-set AS2:AS-CUSTOMERS).
AS2の顧客ベースが成長するにつれて、AS1またはAS2のAut-Numオブジェクトに変更を加える必要はありません。新規顧客のAS番号は、AS-SET AS2：AS-カスタマーに単純に追加でき、既存の顧客のようにすべてが機能します。読みやすさ、スケーラビリティ、保守性の観点から明らかに、これは、顧客のポリシーをAut-Numオブジェクトに直接追加する場合と比較すると、はるかに優れたメカニズムです。この特定の例のポリシーは、AS1がAS2からのAS2からのルートアナウンスを受け入れると述べています。パスの最初の要素がAS2であり、その後AS2の発生が増え、その後AS2顧客の0以上の発生（たとえば、ASのメンバーは任意です。-Set 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 }
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
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
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オブジェクトでは何も変更する必要はありません。Aut-Numオブジェクト。追加の複雑さは、2つのルートセット名が異なるためです。そうしないと、2つのインポートステートメントを1つに組み合わせることができました。セット名は階層的に構築されていることに注意してください。最初の数は、これらがセットであることを示し、最後の数字は各ピアのこれらのセットをパラメーター化します。RPSLを使用すると、ピアのAS番号をキーワードPeerasに置き換えることができます。
Hence,
したがって、
import: from AS3 accept AS2:RS-ROUTES:PeerAS
import: from AS4 accept AS2:RS-ROUTES: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.
図6の対応するインポートステートメントと同じ意味があります。これにより、図9に示すように、2つのインポートステートメントを1つに組み合わせることができます。
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
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.
上記の例では、ピアリングはASEの間でのみ与えられました。ただし、ピーリングについては、RPSLによってさらに詳細に説明できます。ここでは、インポートおよびエクスポート属性のIPアドレスを使用して、物理ルーター間でピーリングを指定できます。図10は、AS1とAS2がExchange Point 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+$>
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にはこの例の交換ポイントへの接続が1つしかないため、この仕様は境界ルーターが指定されていないものと違いはありません。ただし、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+$>
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.
ピアリング仕様で特定のペアのルーターを選択することにより、他のペアを拒否できます。ポリシー条項にルーターが含まれていない場合、ポリシーは関連するASEのすべてのピーリングに適用されると想定されています。
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.
ASES間のピーリングの仕様は、ASごとに1つのルーターに限定されません。図10では、AS2のExchange Point IXへの2つの接続のうちの1つが、他の接続が失敗した場合にバックアップとして使用される場合があります。AS1は、通常の操作中にAS2のルーター7.7.7.2への接続を、ルーター7.7.7.3にバックアップとして使用したいと仮定します。ルーターの構成では、これはローカルの好みを設定することで実行できます。RPSLに相当するものは、ピアリング説明の対応するアクション定義です。アクション定義は、Acceptキーワードの直前に挿入されます。
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.
PREFは、より大きな値よりも小さな値が好まれるという点で、ローカル-PREFとは反対です。アクションは、ルーターのIPアドレスを指定せずに定義することもできます。ポリシー条項にルーターが含まれていない場合、関係するASEのすべてのピーリングに対してアクションが実行されると想定されます。
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]を参照してください。薬を使用して負荷分散を達成するために、しばしば「IGPメトリック」に設定します。これはRPSLで次のように指定されています。
aut-num: AS2
export: to AS1 action med=igp_cost; announce <^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を設定し、他のルーターの1つのルーターと他のルートでいくつかのルートを優先させます。
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 "Local_Pref"を構成できるようにすることです。これにより、通常はBGP「local_pref」を下げてバックアップの取り決めを示すことにより、顧客がプロバイダーのルート選択に影響を与えることができます。
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（プロバイダー）がポリシーを指定して、AS1の2人の直接顧客（AS2とAS3）に接続された顧客（AS4）が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+$>
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：1のルートにタグを付けた場合、AS1がBGP「local_pref」を10削減するためにこれに基づいて行動することを説明するためのポリシーを追加するとします。
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のRefineステートメントの理想的な候補です。これにより、ポリシーがより簡潔になり、将来的にはピアリングステートメントが追加されるため、エラーの可能性の一部を回避します。
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：1を含む顧客から受け入れられたルートが、ローカル優先値を10削減することを明確に見ることができます。
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:
まず、AS1のすべての顧客を集めて、SENT AS1：AS-Customersに集めます。AS1で始まる階層セット名を使用して、他のASEとのIRRでの衝突の可能性を回避します。
as-set: AS1:AS-CUSTOMERS members: AS2, AS3, AS5
as-set：as1：as-customersメンバー：AS2、AS3、AS5
We also define one set for each customer which lists the AS numbers of any of their customers.
また、顧客の数をリストする各顧客向けの1つのセットを定義します。
as-set: AS1:AS-CUSTOMERS:AS2
members: AS4
as-set: AS1:AS-CUSTOMERS:AS3
members: AS4
as-set: AS1:AS-CUSTOMERS:AS5
members: # AS5 has no customers yet, so keep blank for now
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：AS-カスタマーでのPeerasの使用は、基本的にAS1：AS-カスタマーのメンバーをループすることと同等であり、PeerasをSet 1：As-Customersのメンバーに置き換えることでポリシーを拡大します。
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 Export：AS2 Action Community.Append（1：1）;AS1エクスポートの発表：AS3にAS1を発表します
Here, AS4 is signalling AS1 to prefer the routes from AS3.
ここで、AS4はAS1から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から1つずつ抽出され、編集してからレジストリロボットに引き渡される場合があります。ただし、Ratoolset [6]は非常に優れたツールを提供し、Aut-Numオブジェクトの作業がはるかに簡単になります：Aut-NumオブジェクトエディターAOE。
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]によって開発されたツールであり、さまざまなIRRSに保持されているポリシーデータからベンダー固有のルーター構成を生成します。RTConfigは現在、Cisco、Gated、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コマンドが含まれます。ソースファイルを作成するには、ルーター構成ファイルのいずれかを選択し、ベンダー固有のポリシー構成コマンドを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」などのコマンドは、RTCONFIGに指示して、AS3582でルーター198.32.162.1でルーター198.32.162.1でベンダー固有のインポートポリシーを生成するように指示します。AS3701のルーター198.32.162.2。他の@RtConfigコマンドは、RTCONFIGに生成する出力で特定の名前と番号を使用するように指示します（追加情報については、RTConfigマニュアル[8]を参照してください）。
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
ルーターBGP 3582ネットワーク128.223.0.0！！アクセスリスト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_NAMAME = "asfig_name .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 AS2914198.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.
この付録では、多くの典型的なインターネットルーティングポリシーを実装するために必要なRPSLオブジェクトを紹介します。RFC-2622およびRIPE-157は、これらのオブジェクトとRPSL構文の権威ある説明を提供しますが、この付録は実際に十分であることがよくあります。
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 オブジェクトを設定する（asset、ルートセット）
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レジストリの1つに登録する必要があります。
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
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
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.
プライベートレジストリのいずれかを使用している場合、サービスプロバイダーは質問に対処できる必要があります。
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に示します。メンテナーはメンテナンスAS3701と呼ばれます。ここの連絡先担当者は、管理者（Admin-C）およびTechnical（Tech-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-byを追加することによって行われます。図14では、メンテナーのメンテナンス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
Figure 14: Maintainer Object
図14：メンテナーオブジェクト
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、Tech-C）をリストし、図14に表示されているメンテナーである（MNT-BY）MEANTING-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.
この例では、AS3582はキーワードを使用してAS3701からすべてのルートをインポートします。AS3582は、AS4222、AS5650、およびAS1798から内部ルートのみを輸入します。AS2914の輸入ポリシーは少し複雑です。AS2914は他のさまざまなASEへのトランジットを提供するため、AS3582はAS2194で始まるASPathのルートを受け入れます。これに続いてAS-WNAのメンバーがASセット（以下のセクションA.4.1を参照）であり、AS2914をトランジットする顧客を説明しています。
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はマルチホームのスタブAS（つまり、輸送を提供しない）であるため、その輸出ポリシーは単に「AS3582の発表」条項で構成されています。つまり、AS3582の内部ルートを発表します。これらのルートは、Origin属性が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
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：EUGENE、OR EUGENE、OR 97403-1212 DESCR：USA MNT-BY：MEANT-AS3582変更：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が新しいルートを発信している場合、Origin 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が新しいルートを発信する場合、Origin AS3701を持つそのルートのルートオブジェクトを作成するだけです。AS3701とAS3582の両方が、Aut-Numオブジェクトを変更せずにこのルートオブジェクトを使用して構成を構築できるようになりました。
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をOrigin属性によって維持します。この参照により、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.
したがって、ルートオブジェクトは、ルーティングポリシーのルールに従ってピアASEに配布されるルートを提供します。したがって、バックボーンルーターのルーティングテーブル内の任意のルートの場合、IRRのレジストリの1つにルートオブジェクトが存在する必要があります。ルートオブジェクトは、ASの外側にあるルートのみでIRRに登録する必要があります。通常、この一連の外部ルートは、AS内に内部的に表示されるルートとは異なります。主な理由の1つは、外部のピアがあなたの内部ルーティングの詳細に関する情報をまったく必要としないことです。したがって、外部ルートは、一般に内部ルートの集約された組み合わせであり、CIDRルールに従って該当する場合は短いIPプレフィックスを備えています。CIDRのチュートリアル紹介については、CIDR FAQ [5]を参照してください。ルートを可能な限り集約し、グローバルルーティングテーブルに注入するルートの数を最小限に抑え、同時に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プログラムを使用して単一ルートオブジェクトを簡単に照会し、メールでオブジェクトをレジストリロボットに送信することができますが、これは大きなセットでは厄介になります。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].
ルートオブジェクトをインタラクティブに処理するためのラットオールセットのはるかに洗練されたツールは、ルートオブジェクトエディターROEです。IRRで登録されているルートオブジェクトを表示および操作するためのグラフィカルユーザーインターフェイスがあります。新しいルートオブジェクトは、テンプレートから生成され、レジストリに送信される場合があります。さらに、データベースからのルートオブジェクトは、実際のルートと比較される場合があります。したがって、ROEは、ルートオブジェクトのIRRのインターフェイスとして強くお勧めします。PevalとRoeの詳細情報は、Ratoolset [6]と一緒に入手できます。
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を設定したオブジェクトに組み合わせることができます。As Setとルートセットの事前定義されたセットオブジェクトには、2つの基本的なタイプがあります。RPSLセットオブジェクトは以下に説明します。
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セット）は、自律システムオブジェクトを名前付きセットにグループ化するために使用されます。AS-Setには、「As-」で始まるRPSL名があります。図17の例では、As-Nero-Partnersと呼ばれるASセットとAS3701、AS4201、AS3582、AS4222、AS1798を含むASセットが定義されています。ASセットは、RIPE-181 AS-MacroのRPSL置換です。Aut-Numオブジェクトの設定名として参照することにより、間接的に設定されたASEを含めるように拡張されています。
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セットは、顧客、プロバイダーなどのグループにポリシーを指定する場合、または輸送用に特に役立ちます。これらのグループのセットを登録することをお勧めします。これは、それらを同様に扱う可能性が高いためです。つまり、独自の自律システムを持っているすべての顧客に非常に類似したルーティングポリシーがあります。これは、あなたが覗き込んでいるプロバイダーにも当てはまることを発見するかもしれません。また、ASEをトランジットを提供する1つのASセットに組み合わせることが最も便利です。たとえば、トランジットプロバイダーが顧客のASセット（つまり、顧客の輸入条項に顧客のASセットが含まれている）を使用して輸入ポリシーを指定した場合、その顧客はそのトランジットプロバイダーが受け入れるASEのセットを変更できます。。繰り返しますが、これは、顧客またはトランジットプロバイダーにAut-Numオブジェクトを変更することを要求することなく実現できます。
as-set: AS3582:AS-PARTNERS members: AS3701, AS4201, AS3582, AS4222, AS1798
AS-SET：AS3582：AS-PARTNERSメンバー：AS3701、AS4201、AS3582、AS4222、AS1798
Figure 17: as-set Object
図17：ASセットオブジェクト
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.
セットのASESは、AS-Setのメンバー属性に続いて、単にコンマ区切りリストにまとめられています。このリストには、他のASセット名も含まれている場合があります。
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.
ルートセットは、ルートのグループに名前を付ける方法です。構文はASセットに似ています。ルートセットには、「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-BARには、セットRS-UOのメンバーとアドレスプレフィックス128.7.0.0/16が含まれています。セットRS-Martiansは、範囲演算子の使用を示しています。0.0.0.0/0732は、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-BARメンバー：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-Martiansの発言：ピアメンバーから受け入れられていないルート：0.0.0.0/0、＃デフォルトルート0.0.0.0/0732、＃ホストルート224.0.0.0.0/3^、＃マルチキャストルート127.0.0.0.0/8^9-32、。。。
Figure 18: route-set Objects
図18：ルートセットオブジェクト
B Output of RtConfig: An Example
b rtconfigの出力：例
In Figure 19, you see the result of running RtConfig on the source file in Figure 11.
図19には、図11のソースファイルでRTCONFIGを実行した結果が表示されます。
router bgp 3582 network 128.223.0.0 ! ! NERO neighbor 198.32.162.2 remote-as 3701
ルーターBGP 3582ネットワーク128.223.0.0！！Nero Neighbor 198.32.162.2 remote-as 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
! router bgp 3582 neighbor 198.32.162.6 route-map AS2914-IMPORT in
！ルーターBGP 3582ネイバー198.32.162.6ルートマップAS2914-IMPORT IN
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.
このドキュメントはRPSLのチュートリアルであり、保護する必要があるプロトコルまたは標準を定義していません。
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.、Meyer、D.、Bates、T.、Karrenberg、D.、M。Terpsstra、「ルーティングポリシー仕様言語（RPSL）」、RFC2622、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] Bates、T.、Jouanigot、J-M.、Karrenberg、D.、Lothberg、P。and M. Terpsstra、「熟したデータベースにおけるIPルーティングポリシーの表現」、テクニカルレポートRipe-81、Ripe、Ripe NCC、Amsterdam、Notherlands、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。ジェリッヒ、J。ジョンチャレー、J-M。Jouanigot、D。Karrenberg、M。Terpsstra、およびJ. Yu。1994年10月、ルーティングレジストリでのIPルーティングポリシーの表現。
[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データベースドキュメント。1997年5月、オランダ、アムステルダム、RIPE NCC、RIPE-157、RIPE-157。
[5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. http://www.ibm.net.il/~hank/cidr.html
[5] ハンク・ヌスバッハー。CIDR FAQ。テルアビブ大学とIBMイスラエル。http://www.ibm.net.il/~hank/cidr.html
[6] The RAToolSet. http://www.ra.net/ra/RAToolSet/
[6] ラットオールセット。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. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1654、1994年7月。
[8] RtConfig as part of the RAToolSet. http://www.ra.net/ra/RAToolSet/RtConfig.html
[8] rtconfig ratolsetの一部として。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] Chen、E。およびT. Bates、「マルチホームルーティングにおけるBGPコミュニティ属性のアプリケーション」、RFC 1998、1996年8月。
Authors' Addresses
著者のアドレス
David Meyer Cisco Systems
David Meyer Cisco Systems
EMail: dmm@cisco.com
Joachim Schmitz America On-Line
ヨアヒム・シュミッツアメリカオンライン
EMail: SchmitzJo@aol.com
Carol Orange RIPE NCC
キャロルオレンジの熟したNCC
EMail: orange@spiritone.com
Mark Prior connect.com.au pty ltd
Mark Prior Connect.com.au Pty Ltd
EMail: mrp@connect.com.au
Cengiz Alaettinoglu USC/Information Sciences Institute
Cengiz Alaettinoglu USC/Information Sciences Institute
EMail: cengiz@isi.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。