[要約] RFC 2519は、異なるドメイン間のルート集約のためのフレームワークを提供しています。その目的は、インターネットのルーティングテーブルのサイズを削減し、ネットワークの効率性を向上させることです。
Network Working Group E. Chen
Request for Comments: 2519 Cisco
Category: Informational J. Stewart
Juniper
February 1999
A Framework for Inter-Domain Route Aggregation
ドメイン間ルート集約のフレームワーク
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 presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing.
このドキュメントは、ドメイン間ルート集約のフレームワークを提示し、このフレームワークを「実装」するルーター構成の例を示しています。このフレームワークは、ルーティングドメイン内および上流のプロバイダーの両方に向けて、ソースによる集約の哲学を強調しているため、柔軟でスケールであり、また、プロバイダーのバランスをとるために「登録なし」BGPコミュニティの使用を強く奨励しています。スケーラブルなドメイン間ルーティングがインターネットの必要性を備えた、より詳細なルーティング情報が必要です。
The need for route aggregation has long been recognized. Route aggregation is good as it reduces the size, and slows the growth, of the Internet routing table. Thus, the amount of resources (e.g., CPU and memory) required to process routing information is reduced and route calculation is sped up. Another benefit of route aggregation is that route flaps are limited in number, frequency and scope, which saves resources and makes the global Internet routing system more stable.
ルート集約の必要性は長い間認識されてきました。ルート集約は、インターネットルーティングテーブルのサイズを縮小し、成長を遅らせるため、良好です。したがって、ルーティング情報の処理に必要なリソースの量（CPUやメモリなど）が削減され、ルートの計算が拡大されます。ルート集約のもう1つの利点は、ルートフラップの数、頻度、範囲が制限されており、リソースを節約し、グローバルなインターネットルーティングシステムをより安定させることです。
Since CIDR (Classless Inter-Domain Routing) [2] was introduced, significant progress has been made on route aggregation, particularly in the following two areas:
CIDR（クラスレスインタードメインルーティング）[2]が導入されて以来、特に次の2つの領域で、ルート集約について大きな進歩が遂げられています。
- Formulation and implementation of IP address allocation policies by the top registries that conform to the CIDR principles [1].
- CIDR原則に準拠した上位レジストリによるIPアドレス割り当てポリシーの定式化と実装[1]。
This policy work is the cornerstone which makes efficient route aggregation technically possible.
このポリシー作業は、技術的に効率的なルート集約を可能にする礎石です。
- Route aggregation by large (especially "Tier 1") providers. To date, the largest reductions in the size of the routing table have resulted from efficient aggregation by large providers.
- 大規模な（特に「ティア1」）プロバイダーによるルート集約。これまで、ルーティングテーブルのサイズの最大の削減は、大規模なプロバイダーによる効率的な集約から生じています。
However, the ability of various levels of the global routing system to implement efficient aggregation schemes varies widely. As a result, the size and growth rate of the Internet routing table, as well as the associated route computation required, remain major issues today. To support Internet growth, it is important to maximize the efficiency of aggregation at all levels in the routing system.
ただし、効率的な集計スキームを実装するグローバルルーティングシステムのさまざまなレベルの能力は大きく異なります。その結果、インターネットルーティングテーブルのサイズと成長率、および必要な関連ルート計算は、今日も大きな問題のままです。インターネットの成長をサポートするには、ルーティングシステムのすべてのレベルでの集約の効率を最大化することが重要です。
Because of the current size of the routing system and its dynamic nature, the first step towards this goal is to establish a clearly defined framework in which scaleable inter-domain route aggregation can be realized. The framework described in this document is based on the predominant and current experience in the Internet. It emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers. The framework also strongly encourages the use of the "no-export" BGP community to balance the providersubscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. The advantages of this framework include the following:
ルーティングシステムの現在のサイズとその動的な性質のため、この目標に向けた最初のステップは、スケーラブルなドメイン間ルート集約を実現できる明確に定義されたフレームワークを確立することです。このドキュメントで説明されているフレームワークは、インターネットでの主要な現在の経験に基づいています。ルーティングドメイン内と上流のプロバイダーの両方に加えて、ソースによる集約の哲学を強調しています。また、このフレームワークは、「エクスポートなし」BGPコミュニティを使用して、より詳細なドメイン間ルーティングの必要性と、より詳細なルーティング情報のより多くの詳細なルーティング情報のバランスをとることを強く奨励しています。このフレームワークの利点には、以下が含まれます。
- Route aggregation is done in a distributed fashion, with emphasis on aggregation by the party or parties injecting the aggregatable routing information into the global mesh.
- ルート集約は分散型ファッションで行われ、当事者または当事者による集約が集計可能なルーティング情報をグローバルメッシュに注入することに重点を置いています。
- The flexibility of a routing domain to be able to inject more granular routing information to an adjacent domain to control the resulting traffic patterns, without having an impact on the global routing system.
- ルーティングドメインの柔軟性は、グローバルルーティングシステムに影響を与えることなく、結果として生じるトラフィックパターンを制御するために、より詳細なルーティング情報を隣接するドメインに注入できるようにします。
In addition to describing the philosophy, we illustrate it by presenting sample configurations. IPv4 prefixes, BGP4 and ASs are used in examples, though the principles are applicable to inter-domain route aggregation in general.
哲学の説明に加えて、サンプル構成を提示することで説明します。IPv4プレフィックス、BGP4、およびASSは例で使用されていますが、原則は一般的にドメイン間凝集に適用できます。
Address allocation policies and technologies to renumber entire networks, while very relevant to the realization of successful and sustained inter-domain routing, are not the focus of this document. The references section contains pointers to relevant documents [8, 9, 11, 12].
ネットワーク全体を買い戻すための配分ポリシーとテクノロジーに住所は、成功および持続的なドメイン間ルーティングの実現に非常に関連していますが、このドキュメントの焦点ではありません。参照セクションには、関連文書[8、9、11、12]へのポインターが含まれています。
The framework of inter-domain route aggregation we are proposing can be summarized as follows:
私たちが提案しているドメイン間ルート集約のフレームワークは、次のように要約できます。
- Aggregation from the originating AS
- 起源のASからの集約
That is, in its outbound route announcements, each AS aggregates the BGP routes originated by itself, by dedicated AS and by private-ASs [10]. ("Routes originated by an AS" refers to routes which have that AS first in the AS path attribute. For example, routes statically configured and injected into BGP fall into this category.)
つまり、そのアウトバウンドルートの発表では、それぞれがそれ自体によって発生するBGPルートを集計し、個人的に献身的に献身的であることです[10]。（ "asから生まれたルートは、as Asの属性で最初にそれを持つルートを指します。たとえば、静的に構成され、BGPに注入されたルートはこのカテゴリに分類されます。）
This framework does not depend on "proxy aggregation" which refers to route aggregation done by an AS other than the originating AS. This preserves the capability of a multi-homed site to control the granularity of routing information injected into the global routing system. Since proxy aggregation involves coordination among multiple organizations, the complexity of doing proxy aggregation increases with the number of parties involved in the coordination. The complexity, in turn, impacts the practicality of proxy aggregation.
このフレームワークは、as以外のas以外のasによって行われたルーティング集約を指す「プロキシ集約」に依存するものではありません。これにより、グローバルルーティングシステムに注入されたルーティング情報の粒度を制御するためのマルチホームサイトの機能が保持されます。プロキシの集約には複数の組織間の調整が含まれるため、配位に関与する当事者の数とともに、プロキシ集約を行う複雑さが増加します。複雑さは、プロキシ集約の実用性に影響を与えます。
An AS shall always originate via a stable mechanism (e.g., static route configuration) the BGP routes for the large aggregates from which it allocates addresses to customers. This ensures that it is safe for its customers to use BGP "no-export".
Aは常に安定したメカニズム（例えば、静的ルート構成）を介して発生します。これにより、顧客がBGP「no-export」を使用することが安全であることが保証されます。
- Using BGP community "no-export" toward upstream providers
- 上流のプロバイダーにBGPコミュニティの「ノーエクスポート」を使用します
That is, in its route announcements toward its upstream provider, an AS tags the BGP community "no-export" to routes it originates that do not need to be propagated beyond its upstream provider (e.g., prefixes allocated by the upstream provider).
つまり、上流のプロバイダーへのルートアナウンスでは、AS AS AS TAGS TAGS BGP Communityに、上流のプロバイダーを超えて伝播する必要はないルートを導きます（例えば、アップストリームプロバイダーによって割り当てられた接頭辞）。
This framework is illustrated in Figure 1. A "Tier 1" provider does not use "no-export" in its announcement as it does not have an upstream provider. However, it shall aggregate the routes it originates in its outbound announcements towards both peer providers and customers. An AS with an upstream provider shall aggregate the routes it originates and use "no-export" toward its upstream provider for routes that do not need to be propagated beyond its provider's AS. This recursion shall apply to all levels of the routing hierarchy.
このフレームワークを図1に示します。「Tier 1」プロバイダーは、上流のプロバイダーを持っていないため、発表で「輸出なし」を使用しません。ただし、ピアプロバイダーと顧客の両方に対するアウトバウンドアナウンスに由来するルートを集約するものとします。上流のプロバイダーと同様に、それが発生するルートを集約し、プロバイダーのASを超えて伝播する必要のないルートの上流プロバイダーに「no-export」を使用するものとします。この再帰は、ルーティング階層のすべてのレベルに適用されます。
Tier 1
+-- Provider <--+
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| ^ o uses "no-export" if appropriate
|
+---> Tier 2 <--+
Provider |
V |
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| | o uses "no-export" if appropriate
| |
| ^
-> Customer AS
Figure 1
図1
This framework scales well as aggregation is done at all levels of the routing system. It is flexible because the originating AS controls whether routes of finer granularity are injected to, and/or propagated by, its upstream provider. It facilitates multi-homing without compromising route aggregation.
このフレームワークは、集約としてうまくスケールします。ルーティングシステムのすべてのレベルで行われます。より細かい粒度のルートがそのアップストリームプロバイダーに注入され、および/または伝播されるかどうかを制御するため、柔軟性があります。ルートの集約を妥協することなく、マルチホーミングを促進します。
This framework is detailed in the following sections.
このフレームワークについては、次のセクションで詳しく説明しています。
It has been well recognized that address allocation and address renumbering are keys to containing the growth of the Internet routing table [1, 2, 8, 9, 11, 12].
アドレスの割り当てと住所の変更は、インターネットルーティングテーブルの成長を含む鍵であることがよく認識されています[1、2、8、9、11、12]。
Although the strategies discussed in this document do not assume a perfect address allocation, it is strongly urged that an AS receive allocation from its upstream service providers' address block.
このドキュメントで説明されている戦略は、完全なアドレスの割り当てを想定していませんが、AS AS As Appreamのサービスプロバイダーのアドレスブロックから割り当てを受信することが強く促されています。
To reduce the number of routes that need to be injected into an AS, there are a couple of principles that shall be followed:
ASに注入する必要があるルートの数を減らすために、従うべきいくつかの原則があります。
- Carry in its BGP table the large route block allocated from its upstream provider or an address registry (e.g., InterNIC, RIPE, APNIC). This can be done by either static configuration of the large block or by aggregating more specific BGP routes. The former is recommended as it does not depend on other routes.
- BGPテーブルで、上流のプロバイダーまたはアドレスレジストリ（例：内部、熟した、apnic）から割り当てられた大きなルートブロックを持ち運びます。これは、大きなブロックの静的な構成、またはより特定のBGPルートを集約することで実行できます。前者は他のルートに依存しないため推奨されます。
- Allocate sub-blocks to the access routers where further allocation is done. That is, the address allocation shall be done such that only a few, less specific routes (instead of many more, specific ones) need to be known to the other routers within the AS.
- サブブロックをアクセスルーターに割り当て、さらに割り当てが行われます。つまり、アドレス割り当ては、AS内の他のルーターに（さらに多くの具体的なルートの代わりに）わずかな特定のルートのみを知らせる必要があるように行われます。
For example, a prefix of /17 can be further allocated to different access routers as /20s which can then be allocated to customers connected to different interfaces on that router (as shown in Figure 2). Then in general only the /20 needs to be injected into the whole AS. Exceptions need to be made for multi-homed static routes.
たとえば、 /17の接頭辞は、 /20の別のアクセスルーターにさらに割り当てることができ、その後、そのルーターの異なるインターフェイスに接続された顧客に割り当てることができます（図2を参照）。一般に、 /20のみをAS全体に注入する必要があります。マルチホームの静的ルートの例外を作成する必要があります。
access router
+------------+
| x.x.x.x/20 |
+------------+
| | |
| | |
/24 /22 /25
Figure 2
図2
It is noted that rehoming of customers without renumbering even within the same AS may lead to injection of more specific routes. However, in general the more-specifics do not need to be advertised outside of that AS. Such routes can either be tagged with the BGP community "no-export" or filtered out by a prefix-based filter to prevent them from being advertised out.
より具体的なルートの注入につながる可能性があるのと同じ内側でさえも、顧客の再保険委員会を再保持することに注意してください。ただし、一般に、より種は、それ以外で宣伝する必要はありません。このようなルートは、BGPコミュニティの「no-export」でタグ付けするか、プレフィックスベースのフィルターによって除外されて、宣伝されないようにすることができます。
There are at least two types of routes that need to be advertised by an AS: routes originated by the AS and routes originated by its BGP customers. An AS may need to advertise full routes to certain BGP customers, in which case the routing announcements include routes originated by non-customer ASs. Clearly an AS can, and should, safely aggregate the routes originated by itself and by its BGP customers multi-homed only to it (using, e.g., the dedicated-AS and
ASによって宣伝する必要があるルートには、少なくとも2種類のルートがあります。BGPの顧客から生まれたASおよびルートから生まれたルート。ASは、特定のBGPの顧客にフルルートを宣伝する必要がある場合があります。この場合、ルーティングアナウンスには、非カスタマーのお尻から生まれたルートが含まれます。明らかに、可能な限り、それ自体が起源とするルートを安全に集約し、そのBGPの顧客はそれにのみマルチホームしました（例えば、専用のasを使用します。
by the private-AS mechanism [10]) in its outbound announcement. But it is far more dangerous to aggregate routes originated by customer ASs due to multi-homing.
そのアウトバウンドの発表におけるプライベートとしてのメカニズム[10]）によって。しかし、マルチホミングのために顧客のお尻から生まれたルートを集約する方がはるかに危険です。
However, there are several cases in which a route originated by a BGP customer (other than using the dedicated AS or private AS) does not need to be advertised out by its upstream providers. For example,
ただし、BGPの顧客から発信されるルート（専用のASまたはプライベートASを使用する以外）が上流のプロバイダーによって宣伝する必要はない場合があります。例えば、
- The route is a more-specific of the upstream provider's block. However, the customer is either singly homed; or its connection to this particular upstream provider is used for backup only.
- このルートは、アップストリームプロバイダーのブロックのより特有のものです。ただし、顧客は単独で家に帰っています。または、この特定のアップストリームプロバイダーへの接続は、バックアップにのみ使用されます。
- The more-specifics of a larger block are announced by the customer in order to balance traffic over the multiple links to the upstream provider.
- 上流のプロバイダーへの複数のリンク上のトラフィックのバランスをとるために、より大きなブロックのより重要なブロックの固有が顧客によって発表されます。
Our approach to suppress such routes is to give control to the ASs that originate the more-specifics (as seen by its upstream providers) and let them tag the BGP community "no-export" to the appropriate routes.
このようなルートを抑制するアプローチは、より特定のプロバイダーで見られるように）を制御することであり、BGPコミュニティに「Export No-Export」に適切なルートにタグを付けることです。
The BGP community "no-export" is a well known BGP community [6, 7]. A route with this attribute is not propagated beyond an AS boundary. So, if a route is tagged with this community in its announcement to an upstream provider and is accepted by the upstream provider, the route will not be announced beyond the upstream provider's AS. This achieves the goal of suppressing the more-specifics in the upstream provider's outbound announcement.
BGPコミュニティ「No-Export」は、よく知られているBGPコミュニティです[6、7]。この属性を持つルートは、境界を超えて伝播されません。したがって、上流のプロバイダーへの発表でこのコミュニティにルートがタグ付けされ、アップストリームプロバイダーに受け入れられている場合、ルートはアップストリームプロバイダーのASを超えて発表されません。これにより、アップストリームプロバイダーのアウトバウンドアナウンスのより重要なものを抑制するという目標が達成されます。
In this framework, the BGP community "no-export" shall be tagged to routes that are to be advertized to, but not propagated by, its upstream provider. They may include routes allocated out of its upstream provider's block or the more specific routes announced to its upstream provider for the purpose of load balancing. This aggregation strategy can be implemented via prefix-based filtering as shown in the example of Section 5.
このフレームワークでは、BGPコミュニティ「No-Export」は、そのアップストリームプロバイダーに宣伝されるが伝播されないルートにタグ付けされます。上流のプロバイダーのブロックから割り当てられたルート、またはロードバランスを目的として上流のプロバイダーに発表されたより具体的なルートが含まれる場合があります。この集約戦略は、セクション5の例に示すように、プレフィックスベースのフィルタリングを介して実装できます。
For its own protection, a downstream AS shall announce only its own routes and its customer routes to its upstream providers. Thus, the outbound routing announcement and aggregation policy can be expressed as follows:
それ自体の保護のために、ダウンストリームは、独自のルートとその顧客ルートのみを上流のプロバイダーに発表するものとします。したがって、アウトバウンドルーティングの発表と集約ポリシーは、次のように表現できます。
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
それ自体が生まれたルートの場合/献身的な/プライベートAs：必要に応じて「exportなし」のタグを付け、大きなブロックを宣伝してより種を抑制します
For routes originated by customer ASs: advertise to upstream ASs
顧客のお尻から生まれたルートの場合：上流のお尻に宣伝する
For any other routes: do not advertise to upstream ASs
他のルートの場合：上流のお尻に宣伝しないでください
This approach is flexible and scales well as it gives control to the party with the special needs, distributes the workload and avoids the coordination overhead required by proxy aggregation.
このアプローチは、特別なニーズでパーティーを制御し、ワークロードを配布し、プロキシ集約に必要な調整オーバーヘッドを回避するため、柔軟でスケールです。
A provider shall aggregate all the routes it originates, as documented in Section 3. The only difference is that the provider may be providing full routes to certain BGP customers where no outbound filtering is presently in place. Experience has shown that inconsistent route announcement (e.g., aggregate at the interconnects but not toward certain customers) can cause serious routing problems for the Internet as a whole because of longest-match routing. In certain cases announcing the more-specifics to customers might provide for more accurate IGP metrics and could be useful for better load-balancing. However, the potential risk seems to outweigh the benefit, especially given the increasing complexity of connectivity that a customer may have. As a result, every effort shall be made to ensure consistent route aggregation for all BGP peers. This means deploying filters for the BGP peers which receive full routes.
プロバイダーは、セクション3で文書化されているように、発信するすべてのルートを集約するものとします。唯一の違いは、プロバイダーが現在配置されている特定のBGP顧客に完全なルートを提供している可能性があることです。経験によると、一貫性のないルートの発表（たとえば、相互接続での集計ではなく、特定の顧客には合わない）は、最も長い試合のルーティングのためにインターネット全体に深刻なルーティングの問題を引き起こす可能性があることが示されています。特定のケースでは、顧客により特定のものを発表することは、より正確なIGPメトリックを提供する可能性があり、より良い負荷分散に役立つ可能性があります。ただし、特に顧客が持つ可能性のある接続性の複雑さの増加を考えると、潜在的なリスクは利益を上回っているようです。その結果、すべてのBGPピアの一貫したルート集約を確保するためにあらゆる努力が払われるものとします。これは、完全なルートを受け取るBGPピア向けにフィルターを展開することを意味します。
In summary, the aggregation strategy for a provider shall be:
要約すると、プロバイダーの集約戦略は次のとおりです。
- In announcing customer routes:
- 顧客ルートの発表において：
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
それ自体が生まれたルートの場合/献身的な/プライベートAs：必要に応じて「exportなし」のタグを付け、大きなブロックを宣伝してより種を抑制します
For routes originated by other customer ASs: advertise
他の顧客のお尻から生まれたルートの場合：広告
For any other routes: do not advertise
他のルートの場合：宣伝しないでください
- In announcing full routes:
- フルルートの発表において：
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
それ自体が生まれたルートの場合/献身的な/プライベートAs：必要に応じて「exportなし」のタグを付け、大きなブロックを宣伝してより種を抑制します
For any other routes: advertise
他のルートの場合：広告
Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, and AS 2000 is a customer of AS 1000 with a "portable address" 160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000. Assume that 208.128.0.0/19 does not need to be propagated beyond AS 1000.
図3に示す例を考えてみましょう。AS1000は2つの大きな集合体208.128.0.0/12および166.55.0.0/16を持つ「ティア1」プロバイダーであり、2000年は「ポータブルアドレス」160.75のAS 1000の顧客です。0.0/16およびアドレス208.128.0.0/19は、AS 1000から割り当てられています。1090.128.0.0/19は、1000を超えて伝播する必要がないと仮定します。
+----------------+
| AS 1000 |
| 208.128.0.0/12 |
| 166.55.0.0/16 |
+----------------+
|
| BGP
|
|
+----------------+
| AS 2000 |
| 208.128.0.0/19 |
| 160.75.0.0/16 |
+----------------+
Figure 3
図3
Then, based on the framework presented, AS 1000 would
次に、提示されたフレームワークに基づいて、1000がそうするように
- originate and advertise the BGP routes 208.128.0.0/12 and 166.55.0.0/16, and suppress more-specifics originated by itself/private-ASs/dedicated-ASs
- BGPルート208.128.0.0/12および166.55.0.0/16を起源と宣伝し、それ自体が原因となるより多くの種類を抑制します/プライベートアス/専用
- advertise the routes received from the customer AS 2000
- 2000年として顧客から受け取ったルートを宣伝します
and AS 2000 would
そして2000年と同じように
- originate BGP route 208.128.0.0/19 and 160.75.0.0/16
- BGPルート208.128.0.0/19および160.75.0.0/16の発生
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS 1000 and suppress the more specifics originated by itself/private-AS/dedicated-AS, tagging the route 208.128.0.0/19 with "no-export"
- 160.75.0.0/16と208.128.0.0/19の両方をそのプロバイダーに1000として宣伝し、それ自体がより多くの詳細を抑制します/プライベートAs/献身的なものを抑制し、ルート208.128.0.0/19を「ノーエクスポート」でタグ付けします
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP customers (if any) and suppress the more-specifics originated by itself/private-AS/dedicated-AS, plus any other routes the customers may desire to receive
- 160.75.0.0/16と208.128.0.0/19の両方をBGPの顧客に宣伝し（もしあれば）、それ自体がより/プライベートAS/献身的なASから生じたより種を抑制し、さらに顧客が受け取ることを望む他のルート
The sample configuration which implement these policies (in Cisco syntax) is given in Appendix A.
これらのポリシーを実装するサンプル構成（シスコ構文）は、付録Aに記載されています。
The authors would like to thank Roy Alcala of MCI for a number of interesting hallway discussions related to this work. The IETF's IDR Working Group also provided many helpful comments and suggestions.
著者は、この作業に関連する多くの興味深い廊下の議論について、MCIのRoy Alcalaに感謝したいと思います。IETFのIDRワーキンググループは、多くの有用なコメントや提案も提供しました。
[1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[1] Rekhter、Y。およびT. Li、「CIDRによるIPアドレス割り当てのアーキテクチャ」、RFC 1518、1993年9月。
[2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[2] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所の割り当てと集約戦略」、RFC 1519、1993年9月。
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[3] Rekhter、Y。、およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[4] Rekhter, Y. and P., Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[4] Rekhter、Y。and P.、Gross、「インターネットでのBorder Gateway Protocolの適用」、RFC 1772、1995年3月。
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[5] Rekhter、Y。、「マルチプロバイダーインターネットでのルーティング」、RFC 1787、1995年4月。
[6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[6] Chandra、R.、Traina、P。and T. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[7] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996.
[7] Chen、E。、およびT. Bates、「マルチホームルーティングにおけるBGPコミュニティ属性のアプリケーション」、RFC 1998、1996年8月。
[8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[8] Ferguson、P。and H. Berkowitz、「ネットワークの名前を変更する概要：なぜ私はそれが欲しいのか、とにかくそれは何ですか？」、RFC 2071、1997年1月。
[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[9] Berkowitz、H。、「ルーターの名前を変更するガイド」、RFC 2072、1997年1月。
[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a Dedicated AS for Sites Homed to a Single Provider", RFC 2270, January 1998.
[10] Stewart、J.、Bates、T.、Chandra、R。、およびChen、E。、「単一のプロバイダーに拠点を置くサイトについて専用のように使用」、RFC 2270、1998年1月。
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[11] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[12] Carpenter、B。およびY. Rekhter、「Nemonling Needs Work」、RFC 1900、1996年2月。
[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Configuration Guide (Addendum), May 1995.
[13] Cisco Systems、Cisco IOSソフトウェアバージョン10.3ルーター製品構成ガイド（補遺）、1995年5月。
Enke Chen Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
Enke Chen Cisco Systems 170 West Tasman Drive San Jose、CA 95134-1706
Phone: +1 408 527 4652
EMail: enkechen@cisco.com
John W. Stewart, III Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043
John W. Stewart、III Juniper Networks、Inc。385 Ravendale Drive Mountain View、CA 94043
Phone: +1 650 526 8000
EMail: jstewart@juniper.net
A. Appendix A: Example Cisco Configuration
A.付録A：Cisco構成の例
This appendix lists the Cisco configurations for AS 2000 of the examples presented in Section 5. The configuration here uses the AS-path for outbound filtering although it can also be based on BGP community. Several route-maps are defined that can be used for peering with the upstream provider, and for peering with customers (announcing full routes or customer routes).
この付録には、セクション5に示されている例のAS Cisco構成がリストされています。ここでの構成では、BGPコミュニティに基づいていることもありますが、アウトバウンドフィルタリングにAS-PATHを使用しています。上流のプロバイダーとの覗き見に、および顧客との覗き見に使用できるいくつかのルートマップが定義されています（フルルートまたは顧客ルートの発表）。
!!# inject aggregates ip route 160.75.0.0 255.255.0.0 Null0 254 ip route 208.128.0.0 255.255.224.0 Null0 254 ! router bgp 2000 network 160.75.0.0 mask 255.255.0.0 network 208.128.0.0 mask 255.255.224.0 neighbor x.x.x.x remote-as 1000 neighbor x.x.x.x route-map export-routes-to-provider out neighbor x.x.x.x send-community ! !!# match all ip as-path access-list 1 permit .* ! !!# List of internal AS and private ASs that are safe to aggregate ip as-path access-list 10 permit ^$ ip as-path access-list 10 permit ^64999_ ip as-path access-list 10 deny .* ! !!# list of other customer ASs ip as-path access-list 20 permit ^3000_
!!＃注入集約IPルート160.75.0.0 255.255.0.0 NULL0 254 IPルート208.128.0.0 255.255.224.0 NULL0 254！ルーターBGP 2000ネットワーク160.75.0.0マスク255.255.0.0ネットワーク208.128.0.0マスク255.255.224.0ネイバーx.x.x.x remote-as 1000 neighbor-beighbory x.x.x.xルートマップエクスポートルーテスからパバイダーから隣人から!!＃すべてのIP As-Path Access-List 1許可を一致させます。*！！!!＃その他の顧客Ass IP as-pathアクセスリスト20許可 ^3000_のリスト
!!# List of prefixes to be tagged with "no-export" access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 !!# Filter out the more specifics of large aggregates, and permit the rest access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255 access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255 access-list 102 permit ip any any !
!!＃「no-export」アクセスリスト101でタグ付けするプレフィックスのリスト101許可IP 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0.0 !!-LIST 102許可IP 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 Access-List 102拒否IP 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255アクセスリスト1020.0.0.0アクセスリスト102拒否IP 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255アクセスリスト102
!!# route-map with the upstream provider route-map export-routes-to-provider permit 10 match ip address 101 set community no-export route-map export-routes-to-provider permit 20 match as-path 10 match ip address 102
!!＃上流プロバイダーのルートマップルートマップエクスポートルートからプロバイダーへの許可アドレス102
route-map export-routes-to-provider permit 30 match as-path 20 ! !!# route-map with BGP customers that desire only customer routes route-map export-customer-routes permit 10 match as-path 10 match ip address 102 route-map export-customer-routes permit 20 match as-path 20 ! !!# route-map with BGP customers that desire full routes route-map export-full-routes permit 10 match as-path 10 match ip address 102 route-map export-full-routes permit 20 match as-path 1 !
ルートマップエクスポートルートからプロバイダーへの許可30マッチAs-Path 20！!!＃ルートマップ顧客のみルートをルーティングするBGP顧客とルートマップエクスポートカスタマールートを許可する10マッチ10マッチIPアドレス102ルートマップエクスポート - カスタマールート許可20マッチAS-PATH 20！!!＃ルートマップフルルートを希望するルートマップルートマップエクスポート - フルルート許可10マッチ10マッチIPアドレス102ルートマップエクスポート-full-routes許可20マッチAs-path 1！
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。