[要約] RFC 4274は、BGP-4プロトコルの分析を提供し、BGPの動作とセキュリティに関する洞察を提供します。このRFCの目的は、BGP-4プロトコルの理解を深め、ネットワークの安全性と信頼性を向上させることです。
Network Working Group D. Meyer
Request for Comments: 4274 K. Patel
Category: Informational Cisco Systems
January 2006
BGP-4 Protocol Analysis
BGP-4プロトコル分析
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
このレポートの目的は、インターネットドラフト標準としてのルーティングプロトコルの公開要件が、Border Gateway Protocolバージョン4（BGP-4）によってどのように満たされているかを文書化することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.
このレポートは、RFC 1264のセクション6.0で説明されているように、「2番目のレポート」の要件を満たしています。要件を満たすために、このレポートはRFC 1774を増強し、BGP-4の主要な特徴を要約し、スケーリングとパフォーマンスに関するプロトコルを分析します。
Table of Contents
目次
1. Introduction ....................................................2
2. Key Features and Algorithms of BGP ..............................3
2.1. Key Features ...............................................3
2.2. BGP Algorithms .............................................4
2.3. BGP Finite State Machine (FSM) .............................4
3. BGP Capabilities ................................................5
4. BGP Persistent Peer Oscillations ................................6
5. Implementation Guidelines .......................................6
6. BGP Performance Characteristics and Scalability .................6
6.1. Link Bandwidth and CPU Utilization .........................7
7. BGP Policy Expressiveness and its Implications ..................9
7.1. Existence of Unique Stable Routings .......................10
7.2. Existence of Stable Routings ..............................11
8. Applicability ..................................................12
9. Acknowledgements ...............................................12
10. Security Considerations .......................................12
11. References ....................................................13
11.1. Normative References ....................................13
11.2. Informative References ..................................14
BGP-4 is an inter-autonomous system routing protocol designed for TCP/IP internets. Version 1 of BGP-4 was published in [RFC1105]. Since then, BGP versions 2, 3, and 4 have been developed. Version 2 was documented in [RFC1163]. Version 3 is documented in [RFC1267]. Version 4 is documented in [BGP4] (version 4 of BGP will hereafter be referred to as BGP). The changes between versions are explained in Appendix A of [BGP4]. Possible applications of BGP in the Internet are documented in [RFC1772].
BGP-4は、TCP/IPインターネット向けに設計された自律システム間ルーティングプロトコルです。BGP-4のバージョン1は[RFC1105]で公開されました。それ以来、BGPバージョン2、3、および4が開発されました。バージョン2は[RFC1163]で文書化されました。バージョン3は[RFC1267]に文書化されています。バージョン4は[BGP4]に文書化されています（BGPのバージョン4は、これ以降、BGPと呼ばれます）。バージョン間の変化は、[BGP4]の付録Aで説明されています。インターネットでのBGPの可能なアプリケーションは、[RFC1772]に記録されています。
BGP introduced support for Classless Inter-Domain Routing (CIDR) [RFC1519]. Because earlier versions of BGP lacked the support for CIDR, they are considered obsolete and unusable in today's Internet.
BGPは、クラスレスインタードメインルーティング（CIDR）[RFC1519]のサポートを導入しました。BGPの以前のバージョンにはCIDRのサポートが欠けていたため、今日のインターネットでは時代遅れで使用できないと考えられています。
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
このレポートの目的は、インターネットドラフト標準としてのルーティングプロトコルの公開要件が、Border Gateway Protocolバージョン4（BGP-4）によってどのように満たされているかを文書化することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [RFC1774] and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.
このレポートは、[RFC1264]のセクション6.0で説明されているように、「2番目のレポート」の要件を満たしています。要件を満たすために、このレポートは[RFC1774]を強化し、BGP-4の主要な機能を要約し、スケーリングとパフォーマンスに関するプロトコルを分析します。
This section summarizes the key features and algorithms of BGP. BGP is an inter-autonomous system routing protocol; it is designed to be used between multiple autonomous systems. BGP assumes that routing within an autonomous system is done by an intra-autonomous system routing protocol. BGP also assumes that data packets are routed from source towards destination independent of the source. BGP does not make any assumptions about intra-autonomous system routing protocols deployed within the various autonomous systems. Specifically, BGP does not require all autonomous systems to run the same intra-autonomous system routing protocol (i.e., interior gateway protocol or IGP).
このセクションでは、BGPの主要な機能とアルゴリズムをまとめます。BGPは、自律間のルーティングプロトコルです。複数の自律システム間で使用するように設計されています。BGPは、自律システム内のルーティングは、自律型システムルーティングプロトコルによって行われることを想定しています。BGPはまた、データパケットがソースから宛先に向かってルーティングされていることを想定しています。BGPは、さまざまな自律システム内に展開されている自律的なシステムルーティングプロトコルについての仮定を行いません。具体的には、BGPは、すべての自律システムが同じ自律的なシステムルーティングプロトコル（つまり、インテリアゲートウェイプロトコルまたはIGP）を実行する必要はありません。
Finally, note that BGP is a real inter-autonomous system routing protocol; and, as such, it imposes no constraints on the underlying interconnect topology of the autonomous systems. The information exchanged via BGP is sufficient to construct a graph of autonomous systems connectivity from which routing loops may be pruned, and many routing policy decisions at the autonomous system level may be enforced.
最後に、BGPは実際の自律システムルーティングプロトコルであることに注意してください。そして、そのため、自律システムの基礎となる相互接続トポロジに制約はありません。BGPを介して交換された情報は、ルーティングループが剪定される可能性のある自律システム接続のグラフを構築するのに十分であり、自律システムレベルでの多くのルーティングポリシー決定が施行される可能性があります。
The key features of the protocol are the notion of path attributes and aggregation of Network Layer Reachability Information (NLRI).
プロトコルの主な特徴は、パス属性の概念とネットワークレイヤーの到達可能性情報（NLRI）の集約です。
Path attributes provide BGP with flexibility and extensibility. Path attributes are either well-known or optional. The provision for optional attributes allows experimentation that may involve a group of BGP routers without affecting the rest of the Internet. New optional attributes can be added to the protocol in much the same way that new options are added to, for example, the Telnet protocol [RFC854].
パス属性は、BGPに柔軟性と拡張性を提供します。パス属性は、よく知られているかオプションです。オプションの属性の規定は、インターネットの残りに影響を与えることなくBGPルーターのグループを含む可能性のある実験を可能にします。たとえば、Telnetプロトコル[RFC854]に新しいオプションが追加されるのとほぼ同じ方法で、新しいオプションの属性をプロトコルに追加できます。
One of the most important path attributes is the Autonomous System Path, or AS_PATH. As the reachability information traverses the Internet, this (AS_PATH) information is augmented by the list of autonomous systems that have been traversed thus far, forming the AS_PATH. The AS_PATH allows straightforward suppression of the looping of routing information. In addition, the AS_PATH serves as a powerful and versatile mechanism for policy-based routing.
最も重要なパス属性の1つは、自律システムパス、またはAS_Pathです。到達可能な情報がインターネットを横断すると、この（AS_PATH）情報は、これまでに通過した自律システムのリストによって補強され、AS_PATHを形成します。AS_PATHは、ルーティング情報のループを簡単に抑制します。さらに、AS_Pathは、ポリシーベースのルーティングの強力で多用途のメカニズムとして機能します。
BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET attribute. This extended format allows generated aggregate routes to carry path information from the more specific routes used to generate the aggregate. It should be noted, however, that as of this writing, AS_SETs are rarely used in the Internet [ROUTEVIEWS].
BGPは、AS_PATH属性を強化して、AS_SET属性を介してリストを含むだけでなく、自律システムのセットを含めます。この拡張形式により、生成された集計ルートが、集合体を生成するために使用されるより具体的なルートからパス情報を伝達することができます。ただし、この執筆時点では、AS_SETSがインターネット[Routeviews]で使用されることはめったにないことに注意する必要があります。
BGP uses an algorithm that is neither a pure distance vector algorithm or a pure link state algorithm. Instead, it uses a modified distance vector algorithm, referred to as a "Path Vector" algorithm. This algorithm uses path information to avoid traditional distance vector problems. Each route within BGP pairs information about the destination with path information to that destination. Path information (also known as AS_PATH information) is stored within the AS_PATH attribute in BGP. The path information assists BGP in detecting AS loops, thereby allowing BGP speakers to select loop-free routes.
BGPは、純粋な距離ベクトルアルゴリズムでも純粋なリンク状態アルゴリズムでもないアルゴリズムを使用します。代わりに、「パスベクトル」アルゴリズムと呼ばれる修正距離ベクトルアルゴリズムを使用します。このアルゴリズムは、パス情報を使用して、従来の距離ベクトルの問題を回避します。BGP内の各ルートは、その宛先へのパス情報と宛先に関する情報を組み合わせます。パス情報（AS_PATH情報とも呼ばれます）は、BGPのAS_Path属性内に保存されます。パス情報は、BGPがループとして検出されるのを支援し、それによりBGPスピーカーがループフリーのルートを選択できるようにします。
BGP uses an incremental update strategy to conserve bandwidth and processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. Such an incremental update design requires reliable transport between a pair of BGP routers in order to function correctly. BGP solves this problem by using TCP for reliable transport.
BGPは、増分更新戦略を使用して、帯域幅と処理能力を保護します。つまり、完全なルーティング情報の最初の交換後、BGPルーターのペアはその情報の変更のみを交換します。このような増分更新設計には、正しく機能するために、BGPルーターのペア間の信頼できる輸送が必要です。BGPは、信頼できる輸送のためにTCPを使用してこの問題を解決します。
In addition to incremental updates, BGP has added the concept of route aggregation so that information about groups of destinations that use hierarchical address assignment (e.g., CIDR) may be aggregated and sent as a single Network Layer Reachability (NLRI).
増分更新に加えて、BGPはルート集約の概念を追加して、階層アドレスの割り当て（CIDRなど）を使用する目的地のグループに関する情報を集計し、単一のネットワーク層の到達可能性（NLRI）として送信することができます。
Finally, note that BGP is a self-contained protocol. That is, BGP specifies how routing information is exchanged, both between BGP speakers in different autonomous systems, and between BGP speakers within a single autonomous system.
最後に、BGPは自己完結型プロトコルであることに注意してください。つまり、BGPは、さまざまな自律システムのBGPスピーカー間、および単一の自律システム内のBGPスピーカー間のルーティング情報の交換方法を指定します。
The BGP FSM is a set of rules that is applied to a BGP speaker's set of configured peers for the BGP operation. A BGP implementation requires that a BGP speaker must connect to and listen on TCP port 179 for accepting any new BGP connections from its peers. The BGP Finite State Machine, or FSM, must be initiated and maintained for each new incoming and outgoing peer connection. However, in steady state operation, there will be only one BGP FSM per connection per peer.
BGP FSMは、BGP操作のためにBGPスピーカーの構成ピアのセットに適用される一連のルールです。BGPの実装では、BGPスピーカーがピアからの新しいBGP接続を受け入れるためにTCPポート179に接続してリッスンする必要があります。BGP有限状態マシン（FSM）は、新しい着信および発信ピア接続ごとに開始および維持する必要があります。ただし、定常状態の操作では、ピアごとに接続ごとにBGP FSMが1つしかありません。
There may be a short period during which a BGP peer may have separate incoming and outgoing connections resulting in the creation of two different BGP FSMs relating to a peer (instead of one). This can be resolved by following the BGP connection collision rules defined in the [BGP4] specification.
BGPピアが別々の着信と発信接続を持ち、ピアに関連する2つの異なるBGP FSMが作成される可能性がある短い期間があるかもしれません（1つではなく）。これは、[BGP4]仕様で定義されているBGP接続衝突ルールに従うことで解決できます。
The BGP FSM has the following states associated with each of its peers:
BGP FSMには、各ピアに関連する次の状態があります。
IDLE: State when BGP peer refuses any incoming connections.
アイドル：BGPピアが着信接続を拒否した場合。
CONNECT: State in which BGP peer is waiting for its TCP connection to be completed.
接続：BGPピアがTCP接続が完了するのを待っている状態。
ACTIVE: State in which BGP peer is trying to acquire a peer by listening and accepting TCP connection.
アクティブ：BGPピアがTCP接続を聞いて受け入れることでピアを取得しようとしている状態。
OPENSENT: BGP peer is waiting for OPEN message from its peer.
オープンセント：BGPピアは、ピアからのオープンメッセージを待っています。
OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION message from its peer.
OpenConfirm：BGPピアは、ピアからのKeepAliveまたは通知メッセージを待っています。
ESTABLISHED: BGP peer connection is established and exchanges UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
確立：BGPピア接続が確立され、そのピアとの更新、通知、およびキープライブメッセージを交換します。
There are a number of BGP events that operate on the above mentioned states of the BGP FSM for BGP peers. Support of these BGP events is either mandatory or optional. These events are triggered by the protocol logic as part of the BGP or by using an operator intervention via a configuration interface to the BGP protocol.
BGPピア用のBGP FSMの上記の状態で動作する多くのBGPイベントがあります。これらのBGPイベントのサポートは、必須またはオプションのいずれかです。これらのイベントは、BGPの一部としてプロトコルロジックによって、または構成インターフェイスを介してBGPプロトコルへのオペレーター介入を使用することによってトリガーされます。
These BGP events are of following types: Optional events linked to Optional Session attributes, Administrative Events, Timer Events, TCP Connection-based Events, and BGP Message-based Events. Both the FSM and the BGP events are explained in detail in [BGP4].
これらのBGPイベントは、オプションのセッション属性、管理イベント、タイマーイベント、TCP接続ベースのイベント、BGPメッセージベースのイベントにリンクされたオプションのイベントです。FSMイベントとBGPイベントの両方について、[BGP4]で詳細に説明されています。
The BGP capability mechanism [RFC3392] provides an easy and flexible way to introduce new features within the protocol. In particular, the BGP capability mechanism allows a BGP speaker to advertise to its peers during startup various optional features supported by the speaker (and receive similar information from the peers). This allows the base BGP to contain only essential functionality, while providing a flexible mechanism for signaling protocol extensions.
BGP機能メカニズム[RFC3392]は、プロトコル内で新しい機能を導入するための簡単で柔軟な方法を提供します。特に、BGP機能メカニズムにより、BGPスピーカーは、スタートアップでスピーカーによってサポートされているさまざまなオプション機能（および同様の情報をピアから受け取る）中に同僚に宣伝することができます。これにより、ベースBGPは、シグナル伝達プロトコル拡張のための柔軟なメカニズムを提供しながら、重要な機能のみを含めることができます。
Whenever a BGP speaker detects an error in a peer connection, it shuts down the peer and changes its FSM state to IDLE. BGP speaker requires a Start event to re-initiate an idle peer connection. If the error remains persistent and BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations are outside the scope of base BGP specification.
BGPスピーカーがピア接続のエラーを検出すると、ピアをシャットダウンし、FSM状態をアイドル状態に変更します。BGPスピーカーでは、アイドルピア接続を再開するために開始イベントが必要です。エラーが永続的なままで、BGPスピーカーが自動的に開始イベントを生成すると、永続的なピアフラッピングになる可能性があります。ピア振動はBGPの実装で広く普及していることがわかりましたが、持続的なピア振動を防ぐ方法は、ベースBGP仕様の範囲外です。
A robust BGP implementation is "work conserving". This means that if the number of prefixes is bounded, arbitrarily high levels of route change can be tolerated. High levels can be tolerated with bounded impact on route convergence for occasional changes in generally stable routes.
堅牢なBGP実装は、「作業保存」です。これは、接頭辞の数が境界を獲得した場合、ルートの変化のレベルが任意に容認できることを意味します。高レベルは、一般的に安定したルートの時折の変化のために、ルート収束に境界のある影響を与え、容認できます。
A robust implementation of BGP should have the following characteristics:
BGPの堅牢な実装には、次の特性が必要です。
1. It is able to operate in almost arbitrarily high levels of route flap without losing peerings (failing to send keepalives) or losing other protocol adjacencies as a result of BGP load.
1. BGP負荷の結果として、ピーリングを失うこと（キープライブの送信に失敗する）または他のプロトコルの隣接を失うことなく、ほぼ任意の高レベルのルートフラップで動作することができます。
2. Instability of a subset of routes should not affect the route advertisements or forwarding associated with the set of stable routes.
2. ルートのサブセットの不安定性は、安定したルートのセットに関連するルート広告や転送に影響を及ぼさないはずです。
3. Instability should not be caused by peers with high levels of instability or with different CPU speed or load that result in faster or slower processing of routes. These instable peers should have a bounded impact on the convergence time for generally stable routes.
3. 不安定性は、不安定なレベルの高いピアや、ルートの処理が速くなったり遅いか遅いCPU速度または負荷がある仲間によって引き起こされるべきではありません。これらの不安定なピアは、一般的に安定したルートの収束時間に境界のある影響を与える必要があります。
Numerous robust BGP implementations exist. Producing a robust implementation is not a trivial matter, but is clearly achievable.
多数の堅牢なBGP実装が存在します。堅牢な実装を作成することは些細な問題ではありませんが、明らかに達成可能です。
In this section, we provide "order of magnitude" answers to the questions of how much link bandwidth, router memory and router CPU cycles BGP will consume under normal conditions. In particular, we will address the scalability of BGP and its limitations.
このセクションでは、帯域幅、ルーターメモリ、ルーターCPUサイクルBGPが通常の条件下で消費する量の質問に対する「順序」の回答を提供します。特に、BGPのスケーラビリティとその制限に対処します。
Immediately after the initial BGP connection setup, BGP peers exchange complete sets of routing information. If we denote the total number of routes in the Internet as N, the total path attributes (for all N routes) received from a peer as A, and assume that the networks are uniformly distributed among the autonomous systems, then the worst-case amount of bandwidth consumed during the initial exchange between a pair of BGP speakers (P) is
最初のBGP接続セットアップの直後に、BGPピアはルーティング情報の完全なセットを交換します。インターネット内のルートの総数をnとして示す場合、ピアから受け取った総パス属性（すべてのNルート）がAとして均一に分布していると仮定します。
BW = O((N + A) * P)
BGP-4 was created specifically to reduce the size of the set of NLRI entries, which has to be carried and exchanged by border routers. The aggregation scheme, defined in [RFC1519], describes the provider-based aggregation scheme in use in today's Internet.
BGP-4は、NLRIエントリのセットのサイズを縮小するために特別に作成されました。[RFC1519]で定義されている集約スキームは、今日のインターネットで使用されているプロバイダーベースの集約スキームについて説明しています。
Due to the advantages of advertising a few large aggregate blocks (instead of many smaller class-based individual networks), it is difficult to estimate the actual reduction in bandwidth and processing that BGP-4 has provided over BGP-3. If we simply enumerate all aggregate blocks into their individual, class-based networks, we would not take into account "dead" space that has been reserved for future expansion. The best metric for determining the success of BGP's aggregation is to sample the number NLRI entries in the globally-connected Internet today, and compare it to growth rates that were projected before BGP was deployed.
いくつかの大きな集計ブロックを広告することの利点により（多くの小規模なクラスベースの個々のネットワークの代わりに）、BGP-4がBGP-3よりも提供した帯域幅と処理の実際の削減を推定することは困難です。すべての集計ブロックを単純に個々のクラスベースのネットワークに列挙している場合、将来の拡張のために予約されている「死んだ」スペースを考慮しません。BGPの集約の成功を決定するのに最適なメトリックは、今日グローバルに接続されたインターネットのNLRIエントリの数をサンプリングし、BGPが展開される前に予測された成長率と比較することです。
At the time of this writing, the full set of exterior routes carried by BGP is approximately 134,000 network entries [ROUTEVIEWS].
この執筆時点では、BGPが運ぶ外部ルートの完全なセットは、約134,000のネットワークエントリです[Routeviews]。
An important and fundamental feature of BGP is that BGP's CPU utilization depends only on the stability of its network which relates to BGP in terms of BGP UPDATE message announcements. If the BGP network is stable, all the BGP routers within its network are in the steady state. Thus, the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. The KEEPALIVE messages are exchanged only between peers. The suggested frequency of the exchange is 30 seconds. The KEEPALIVE messages are quite short (19 octets) and require virtually no processing. As a result, the bandwidth consumed by the KEEPALIVE messages is about 5 bits/sec. Operational experience confirms that the overhead (in terms of bandwidth and CPU) associated with the KEEPALIVE messages should be viewed as negligible.
BGPの重要かつ基本的な特徴は、BGPのCPU使用率が、BGP更新メッセージの発表に関してBGPに関連するネットワークの安定性にのみ依存することです。BGPネットワークが安定している場合、ネットワーク内のすべてのBGPルーターは定常状態にあります。したがって、BGPによって消費される唯一のリンク帯域幅とルーターCPUサイクルは、BGPキープライブメッセージの交換によるものです。キープライブメッセージは、ピア間でのみ交換されます。交換の推奨頻度は30秒です。Keepaliveメッセージは非常に短い（19オクテット）、処理が事実上必要ではありません。その結果、KeepAliveメッセージによって消費される帯域幅は約5ビット/秒です。運用の経験により、キープライブメッセージに関連するオーバーヘッド（帯域幅とCPUの観点から）は、無視できると見なされるべきであることが確認されています。
During periods of network instability, BGP routers within the network are generating routing updates that are exchanged using the BGP UPDATE messages. The greatest overhead per UPDATE message occurs when each UPDATE message contains only a single network. It should be pointed out that, in practice, routing changes exhibit strong locality with respect to the route attributes. That is, routes that change are likely to have common route attributes. In this case, multiple networks can be grouped into a single UPDATE message, thus significantly reducing the amount of bandwidth required (see also Appendix F.1 of [BGP4]).
ネットワークの不安定性の期間中、ネットワーク内のBGPルーターは、BGP更新メッセージを使用して交換されるルーティングアップデートを生成しています。更新メッセージごとに最大のオーバーヘッドは、各更新メッセージに単一のネットワークのみが含まれている場合に発生します。実際には、ルーティングの変更は、ルート属性に関して強い地域性を示すことを指摘する必要があります。つまり、その変化のルートには、共通のルート属性がある可能性があります。この場合、複数のネットワークを単一の更新メッセージにグループ化できるため、必要な帯域幅の量を大幅に削減できます（[BGP4]の付録F.1も参照）。
To quantify the worst-case memory requirements for BGP, we denote the total number of networks in the Internet as N, the mean AS distance of the Internet as M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the total number of unique AS paths as A. Then the worst-case memory requirements (MR) can be expressed as
BGPの最悪のメモリ要件を定量化するために、インターネット内のネットワークの総数をn、インターネットの平均としてM（自律システムのレベルでの距離での距離）を示します。
MR = O(N + (M * A))
Because a mean AS distance M is a slow moving function of the interconnectivity ("meshiness") of the Internet, for all practical purposes the worst-case router memory requirements are on the order of the total number of networks in the Internet multiplied by the number of peers that the local system is peering with. We expect that the total number of networks in the Internet will grow much faster than the average number of peers per router. As a result, BGP's memory-scaling properties are linearly related to the total number of networks in the Internet.
距離mとしての平均は、インターネットの相互接続性（「メシネス」）の遅い移動関数であるため、すべての実用的な目的のために、最悪のルーターメモリ要件は、インターネットのネットワークの総数にローカルシステムに覗き込むピア数を掛けた順序であるためです。インターネット内のネットワークの総数は、ルーターあたりの平均ピア数よりもはるかに速く成長すると予想しています。その結果、BGPのメモリスケーリングプロパティは、インターネット内のネットワークの総数に直線的に関連しています。
The following table illustrates typical memory requirements of a
router running BGP. We denote the average number of routes
advertised by each peer as N, the total number of unique AS paths as
A, the mean AS distance of the Internet as M (distance at the level
of an autonomous system, expressed in terms of the number of
autonomous systems), the number of octets required to store a network
as R, and the number of bytes required to store one AS in an AS path
as P. It is assumed that each network is encoded as four bytes, each
AS is encoded as two bytes, and each networks is reachable via some
fraction of all the peers (# BGP peers/per net). For purposes of the
estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
# Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
(N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000
In analyzing BGP's memory requirements, we focus on the size of the BGP RIB table (ignoring implementation details). In particular, we derive upper bounds for the size of the BGP RIB table. For example, at the time of this writing, the BGP RIB tables of a typical backbone router carry on the order of 120,000 entries. Given this number, one might ask whether it would be possible to have a functional router with a table containing 1,000,000 entries. Clearly, the answer to this question is more related to how BGP is implemented. A robust BGP implementation with a reasonable CPU and memory should not have issues scaling to such limits.
BGPのメモリ要件を分析する際に、BGPリブテーブルのサイズに焦点を当てます（実装の詳細を無視します）。特に、BGPリブテーブルのサイズの上限を導き出します。たとえば、この執筆時点で、典型的なバックボーンルーターのBGPリブテーブルは、120,000エントリのオーダーを記録します。この番号を考えると、1,000,000エントリを含むテーブルを備えた機能的なルーターを持つことができるかどうかを尋ねるかもしれません。明らかに、この質問に対する答えは、BGPの実装方法により関連しています。合理的なCPUとメモリを使用した堅牢なBGP実装には、そのような制限に合わせてスケーリングする問題はありません。
BGP is unique among deployed IP routing protocols in that routing is determined using semantically rich routing policies. Although routing policies are usually the first BGP issue that comes to a network operator's mind, it is important to note that the languages and techniques for specifying BGP routing policies are not part of the protocol specification (see [RFC2622] for an example of such a policy language). In addition, the BGP specification contains few restrictions, explicit or implicit, on routing policy languages. These languages have typically been developed by vendors and have evolved through interactions with network engineers in an environment lacking vendor-independent standards.
BGPは、ルーティングが意味的にリッチなルーティングポリシーを使用して決定されるという点で、展開されたIPルーティングプロトコルの間でユニークです。ルーティングポリシーは通常、ネットワークオペレーターの心に至る最初のBGP問題ですが、BGPルーティングポリシーを指定するための言語と手法は、そのようなポリシー言語の例についてはプロトコル仕様の一部ではないことに注意することが重要です。さらに、BGP仕様には、ルーティングポリシー言語に関する明示的または暗黙的な制限がほとんど含まれていません。これらの言語は通常、ベンダーによって開発されており、ベンダーに依存しない基準がない環境でネットワークエンジニアとのやり取りを通じて進化しました。
The complexity of typical BGP configurations, at least in provider networks, has been steadily increasing. Router vendors typically provide hundreds of special commands for use in the configuration of BGP, and this command set is continually expanding. For example, BGP communities [RFC1997] allow policy writers to selectively attach tags to routes and to use these to signal policy information to other BGP-speaking routers. Many providers allow customers, and sometimes peers, to send communities that determine the scope and preference of their routes. Due to these developments, the task of writing BGP configurations has increasingly more aspects associated with open-ended programming. This has allowed network operators to encode complex policies in order to address many unforeseen situations, and has opened the door for a great deal of creativity and experimentation in routing policies. This policy flexibility is one of the main reasons why BGP is so well suited to the commercial environment of the current Internet.
少なくともプロバイダーネットワークでは、典型的なBGP構成の複雑さは着実に増加しています。ルーターベンダーは通常、BGPの構成で使用するために何百もの特別なコマンドを提供し、このコマンドセットは継続的に拡大しています。たとえば、BGPコミュニティ[RFC1997]により、ポリシーライターはルートにタグを選択的に接続し、これらを使用して他のBGP語を話すルーターにポリシー情報を信号することができます。多くのプロバイダーは、顧客、時には仲間が、ルートの範囲と好みを決定するコミュニティを送ることを許可しています。これらの開発により、BGP構成を作成するタスクは、オープンエンドプログラミングに関連する側面がますます増えています。これにより、ネットワークオペレーターは多くの予期せぬ状況に対処するために複雑なポリシーをエンコードすることができ、ルーティングポリシーの多くの創造性と実験のための扉を開きました。このポリシーの柔軟性は、BGPが現在のインターネットの商業環境に非常に適している主な理由の1つです。
However, this rich policy expressiveness has come with a cost that is often not recognized. In particular, it is possible to construct locally defined routing policies that can lead to protocol divergence and unexpected global routing anomalies such as (unintended) non-determinism. If the interacting policies causing such anomalies are defined in different autonomous systems, then these problems can be very difficult to debug and correct. In the following sections, we describe two such cases relating to the existence (or lack thereof) of stable routings.
しかし、この豊かな政策表現には、しばしば認識されないコストが伴います。特に、プロトコルの発散や（意図しない）非決定的なものなどの予期しないグローバルなルーティング異常につながる可能性のあるローカルで定義されたルーティングポリシーを構築することが可能です。このような異常を引き起こす相互作用するポリシーが異なる自律システムで定義されている場合、これらの問題はデバッグして修正することが非常に困難になる可能性があります。次のセクションでは、安定したルーティングの存在（またはその欠如）に関連する2つのそのようなケースについて説明します。
One can easily construct sets of policies for which BGP cannot guarantee that stable routings are unique. This is illustrated by the following simple example. Consider four Autonomous Systems, AS1, AS2, AS3, and AS4. AS1 and AS2 are peers, and they provide transit for AS3 and AS4, respectively. Suppose AS3 provides transit for AS4 (in this case AS3 is a customer of AS1, and AS4 is a multihomed customer of both AS3 and AS2). AS4 may want to use the link to AS3 as a "backup" link, and sends AS3 a community value that AS3 has configured to lower the preference of AS4's routes to a level below that of its upstream provider, AS1. The intended "backup routing" to AS4 is illustrated here:
安定したルーティングが一意であることをBGPが保証できないポリシーのセットを簡単に作成できます。これは、次の簡単な例で説明されています。AS1、AS2、AS3、およびAS4の4つの自律システムを考慮してください。AS1とAS2はピアであり、それぞれAS3とAS4のトランジットを提供します。AS3がAS4のトランジットを提供するとします（この場合、AS3はAS1の顧客であり、AS4はAS3とAS2の両方のマルチホームの顧客です）。AS4は、AS3へのリンクを「バックアップ」リンクとして使用し、AS3がAS3のルートの好みを上流プロバイダーAS1のレベルより低いレベルに下げるように構成したコミュニティ価値をAS3に送信します。AS4への意図した「バックアップルーティング」をここに示します。
AS1 ------> AS2
/|\ |
| |
| |
| \|/
AS3 ------- AS4
That is, the AS3-AS4 link is intended to be used only when the AS2- AS4 link is down (for outbound traffic, AS4 simply gives routes from AS2 a higher local preference). This is a common scenario in today's Internet. But note that this configuration has another stable solution:
つまり、AS3-AS4リンクは、AS2-AS4リンクがダウンしている場合にのみ使用することを目的としています（アウトバウンドトラフィックの場合、AS4はAS2からのルートをより高いローカル好みを提供します）。これは、今日のインターネットの一般的なシナリオです。ただし、この構成には別の安定したソリューションがあることに注意してください。
AS1 ------- AS2
| |
| |
| |
\|/ \|/
AS3 ------> AS4
In this case, AS3 does not translate the "depref my route" community received from AS4 into a "depref my route" community for AS1. Therefore, if AS1 hears the route to AS4 that transits AS3, it will prefer that route (because AS3 is a customer). This state could be reached, for example, by starting in the "correct" backup routing shown first, bringing down the AS2-AS4 BGP session, and then bringing it back up. In general, BGP has no way to prefer the "intended" solution over the anomalous one. The solution picked will depend on the unpredictable order of BGP messages.
この場合、AS3はAS4から受け取った「Depref My Route」コミュニティをAS1の「Depref My Route」コミュニティに翻訳しません。したがって、AS1がAS3を通過するAS4へのルートを聞くと、そのルートを好むでしょう（AS3は顧客であるため）。この状態は、たとえば、最初に表示された「正しい」バックアップルーティングで開始し、AS2-AS4 BGPセッションを削減してからバックアップすることで到達できます。一般に、BGPには、異常なソリューションよりも「意図された」ソリューションを好む方法はありません。選択されたソリューションは、BGPメッセージの予測不可能な順序に依存します。
While this example is relatively simple, many operators may fail to recognize that the true source of the problem is that the BGP policies of ASes can interact in unexpected ways, and that these interactions can result in multiple stable routings. One can imagine that the interactions could be much more complex in the real Internet. We suspect that such anomalies will only become more common as BGP continues to evolve with richer policy expressiveness. For example, extended communities provide an even more flexible means of signaling information within and between autonomous systems than is possible with [RFC1997] communities. At the same time, applications of communities by network operators are evolving to address complex issues of inter-domain traffic engineering.
この例は比較的単純ですが、多くのオペレーターは、問題の真のソースは、ASESのBGPポリシーが予期しない方法で相互作用できること、およびこれらの相互作用が複数の安定したルーティングをもたらす可能性があることを認識できない場合があります。実際のインターネットでは、相互作用がはるかに複雑になる可能性があると想像できます。BGPがより豊かな政策表現力で進化し続けるため、このような異常はより一般的になるだけであると思われます。たとえば、拡張されたコミュニティは、[RFC1997]コミュニティで可能なよりも、自律システム内および自律システム間で情報を通知するより柔軟な手段を提供します。同時に、ネットワークオペレーターによるコミュニティの応用は、ドメイン間の交通工学の複雑な問題に対処するために進化しています。
One can also construct a set of policies for which BGP cannot guarantee that a stable routing exists (or, worse, that a stable routing will ever be found). For example, [RFC3345] documents several scenarios that lead to route oscillations associated with the use of the Multi-Exit Discriminator (MED) attribute. Route oscillation will happen in BGP when a set of policies has no solution. That is, when there is no stable routing that satisfies the constraints imposed by policy, BGP has no choice but to keep trying. In addition, even if BGP configurations can have a stable routing, the protocol may not be able to find it; BGP can "get trapped" down a blind alley that has no solution.
また、BGPが安定したルーティングが存在することを保証できない一連のポリシーを構築することもできます（または、さらに悪いことに、安定したルーティングが発見されることがあります）。たとえば、[RFC3345]は、マルチエキシット識別子（MED）属性の使用に関連するルート振動につながるいくつかのシナリオを文書化しています。一連のポリシーに解決策がない場合、BGPでルート振動が発生します。つまり、ポリシーによって課される制約を満たす安定したルーティングがない場合、BGPは試し続ける以外に選択肢がありません。さらに、BGP構成に安定したルーティングがある場合でも、プロトコルがそれを見つけることができない場合があります。BGPは、解決策のない盲目の路地に「閉じ込められる」ことができます。
Protocol divergence is not, however, a problem associated solely with use of the MED attribute. This potential exists in BGP even without the use of the MED attribute. Hence, like the unintended nondeterminism described in the previous section, this type of protocol divergence is an unintended consequence of the unconstrained nature of BGP policy languages.
ただし、プロトコルの発散は、MED属性の使用のみに関連する問題ではありません。この可能性は、MED属性を使用しなくてもBGPに存在します。したがって、前のセクションで説明されている意図しない非決定論のように、このタイプのプロトコルの発散は、BGP政策言語の制約のない性質の意図しない結果です。
In this section we identify the environments for which BGP is well suited, and the environments for which it is not suitable. This question is partially answered in Section 2 of BGP [BGP4], which states:
このセクションでは、BGPが適している環境と、適切でない環境を特定します。この質問は、BGP [BGP4]のセクション2で部分的に回答されています。
"To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that an AS advertises to its neighbor ASes only those routes that it itself uses. This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. Note that some policies cannot be supported by the "hop-by-hop" routing paradigm and thus require techniques such as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighbor AS intending that the traffic take a different route from that taken by traffic originating in the neighbor AS. On the other hand, BGP can support any policy conforming to the "hop-by-hop" routing paradigm. Since the current Internet uses only the "hop-by-hop" routing paradigm and since BGP can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-AS routing protocol for the current Internet."
「BGPを使用して実施できるポリシー決定のセットを特徴付けるには、AS ASがそれ自体が使用するルートのみを宣伝するというルールに焦点を当てる必要があります。このルールは、現在のインターネット全体で一般的に使用される「ホップバイホップ」ルーティングパラダイムを反映しています。一方、BGPは「ホップバイホップ」ルーティングパラダイムに準拠しているポリシーをサポートできます。現在のインターネットは「ホップバイホップ」ルーティングパラダイムのみを使用しているため、BGPはインターネットを使用しているため、bgpがbgpocmsを使用することをサポートできるため、「ホップバイホップ」ルーティングパラダイムをサポートできます。 「
One of the important points here is that BGP contains only essential functionality, while at the same time providing a flexible mechanism within the protocol that allows us to extend its functionality. For example, BGP capabilities provide an easy and flexible way to introduce new features within the protocol. Finally, because BGP was designed to be flexible and extensible, new and/or evolving requirements can be addressed via existing mechanisms.
ここでの重要な点の1つは、BGPには必須機能のみが含まれていると同時に、プロトコル内で機能を拡張できる柔軟なメカニズムを提供することです。たとえば、BGP機能は、プロトコル内で新機能を導入するための簡単で柔軟な方法を提供します。最後に、BGPは柔軟で拡張可能であるように設計されているため、既存のメカニズムを介して新しい要件および/または進化する要件に対処できます。
To summarize, BGP is well suited as an inter-autonomous system routing protocol for any internet that is based on IP [RFC791] as the internet protocol and the "hop-by-hop" routing paradigm.
要約すると、BGPは、インターネットプロトコルおよび「ホップバイホップ」ルーティングパラダイムとしてIP [RFC791]に基づいたインターネットの自律システム間ルーティングプロトコルとして適しています。
We would like to thank Paul Traina for authoring previous versions of this document. Elwyn Davies, Tim Griffin, Randy Presuhn, Curtis Villamizar and Atanu Ghosh also provided many insightful comments on earlier versions of this document.
このドキュメントの以前のバージョンを作成してくれたPaul Trainaに感謝します。Elwyn Davies、Tim Griffin、Randy Presuhn、Curtis Villamizar、Atanu Ghoshも、この文書の以前のバージョンについて多くの洞察に富んだコメントを提供しました。
BGP provides flexible mechanisms with varying levels of complexity for security purposes. BGP sessions are authenticated using BGP session addresses and the assigned AS number. Because BGP sessions use TCP (and IP) for reliable transport, BGP sessions are further authenticated and secured by any authentication and security mechanisms used by TCP and IP.
BGPは、セキュリティ目的でさまざまなレベルの複雑さを備えた柔軟なメカニズムを提供します。BGPセッションは、BGPセッションアドレスと番号として割り当てられたものを使用して認証されます。BGPセッションは信頼できる輸送にTCP（およびIP）を使用しているため、BGPセッションはTCPおよびIPが使用する認証およびセキュリティメカニズムによってさらに認証および保護されます。
BGP uses TCP MD5 option for validating data and protecting against spoofing of TCP segments exchanged between its sessions. The usage of TCP MD5 option for BGP is described at length in [RFC2385]. The TCP MD5 Key management is discussed in [RFC3562]. BGP data encryption is provided using the IPsec mechanism, which encrypts the IP payload data (including TCP and BGP data). The IPsec mechanism can be used in both the transport mode and the tunnel mode. The IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option and the IPsec mechanism are not widely deployed security mechanisms for BGP in today's Internet. Hence, it is difficult to gauge their real performance impact when using with BGP. However, because both the mechanisms are TCP- and IP-based security mechanisms, the Link Bandwidth, CPU utilization and router memory consumed by BGP would be the same as any other TCP- and IP-based protocols.
BGPは、データを検証し、セッション間で交換されるTCPセグメントのスプーフィングから保護するためにTCP MD5オプションを使用します。BGPのTCP MD5オプションの使用法は、[RFC2385]で詳細に説明されています。TCP MD5キー管理については、[RFC3562]で説明されています。BGPデータ暗号化は、IPペイロードデータ（TCPおよびBGPデータを含む）を暗号化するIPSECメカニズムを使用して提供されます。IPSECメカニズムは、輸送モードとトンネルモードの両方で使用できます。IPSECメカニズムは[RFC2406]で説明されています。TCP MD5オプションとIPSECメカニズムの両方は、今日のインターネットでBGPのセキュリティメカニズムが広く展開されていません。したがって、BGPで使用する場合、実際のパフォーマンスへの影響を測定することは困難です。ただし、両方のメカニズムがTCPベースのセキュリティメカニズムであるため、BGPで消費されるリンク帯域幅、CPU使用率、およびルーターメモリは、他のTCPベースおよびIPベースのプロトコルと同じです。
BGP uses the IP TTL value to protect its External BGP (EBGP) sessions from any TCP- or IP-based CPU-intensive attacks. It is a simple mechanism that suggests the use of filtering BGP (TCP) segments, using the IP TTL value carried within the IP header of BGP (TCP) segments that are exchanged between the EBGP sessions. The BGP TTL mechanism is described in [RFC3682]. Usage of [RFC3682] impacts performance in a similar way as using any access control list (ACL) policies for BGP.
BGPは、IP TTL値を使用して、TCPまたはIPベースのCPU集約型攻撃から外部BGP（EBGP）セッションを保護します。これは、EBGPセッション間で交換されるBGP（TCP）セグメントのIPヘッダー内で運ばれるIP TTL値を使用して、BGP（TCP）セグメントのフィルタリングの使用を示唆する単純なメカニズムです。BGP TTLメカニズムは[RFC3682]で説明されています。[RFC3682]の使用は、BGPのアクセス制御リスト（ACL）ポリシーを使用するのと同様の方法でパフォーマンスに影響を与えます。
Such flexible TCP- and IP-based security mechanisms, allow BGP to prevent insertion/deletion/modification of BGP data, any snooping of the data, session stealing, etc. However, BGP is vulnerable to the same security attacks that are present in TCP. The [BGP-VULN] explains in depth about the BGP security vulnerability. At the time of this writing, several efforts are underway for creating and defining an appropriate security infrastructure within the BGP protocol to provide authentication and security for its routing information; these efforts include [SBGP] and [SOBGP].
このような柔軟なTCPおよびIPベースのセキュリティメカニズムにより、BGPはBGPデータの挿入/削除/変更、データのスヌーピング、セッション盗みなどを防ぐことができます。ただし、BGPはTCPに存在する同じセキュリティ攻撃に対して脆弱です。[BGP-Vuln]は、BGPセキュリティの脆弱性について深く説明しています。この執筆時点では、BGPプロトコル内の適切なセキュリティインフラストラクチャを作成および定義して、ルーティング情報の認証とセキュリティを提供するためのいくつかの努力が進行中です。これらの取り組みには、[SBGP]と[SOBGP]が含まれます。
[BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP4] Rekhter、Y.、Li。、T。、およびS. Hares編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、1993年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities属性」、RFC 1997、1996年8月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345] McPherson、D.、Gill、V.、Walton、D。、およびA. Retana、「Border Gateway Protocol（BGP）持続ルート振動条件」、RFC 3345、2002年8月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、M。、「TCP MD5署名オプションの主要な管理上の考慮事項」、RFC 3562、2003年7月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392] Chandra、R。およびJ. Scudder、「BGP-4による機能広告」、RFC 3392、2002年11月。
[BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[BGP-Vuln] Murphy、S。、「BGP Security脆弱性分析」、RFC 4272、2006年1月。
[SBGP] Seo, K., S. Kent and C. Lynn, "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000, pp. 582- 592.
[SBGP] Seo、K.、S。KentおよびC. Lynn、「Secure Border Gateway Protocol（Secure-BGP）」、IEEE Journal on Communications Vol。18、No。4、2000年4月、pp。582-592。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1105、1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1163、1990年6月。
[RFC1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264] Hinden、R。、「インターネットルーティングプロトコル標準化基準」、RFC 1264、1991年10月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol 3（BGP-3）」、RFC 1267、1991年10月。
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1772] Rekhter、Y。、およびP. Gross、編集者、「インターネットでのBorder Gatewayプロトコルの適用」、RFC 1772、1995年3月。
[RFC1774] Traina, P., "BGP-4 Protocol Analysis", RFC 1774, March 1995.
[RFC1774] Traina、P。、「BGP-4プロトコル分析」、RFC 1774、1995年3月。
[RFC2622] 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.
[RFC2622] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、Meyer、D.、Bates、T.、Karrenberg、D。、およびM. Terpstra、「ルーティングポリシー仕様言語（RPSL）」、RFC 2622、1999年。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[ROUTEVIEWS] Meyer, D., "The Route Views Project", http://www.routeviews.org.
[Routeviews] Meyer、D。、「The Route Views Project」、http：//www.routeviews.org。
[SOBGP] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Work in Progress, May 2005.
[SOBGP] White、R。、「安全な起源BGP（SOBGP）のアーキテクチャと展開の考慮事項」、2005年5月の作業。
Authors' Addresses
著者のアドレス
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
Keyur Patel Cisco Systems
Keyur Patel Cisco Systems
EMail: keyupate@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。