Network Working Group D. Meyer
Request for Comments: 4274 K. Patel
Category: Informational Cisco Systems
January 2006
BGP-4 Protocol Analysis
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).
著作権（C）インターネット協会（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).
このレポートの目的は、インターネットドラフト標準のようなルーティングプロトコルの公表のための要件は、ボーダーゲートウェイプロトコルバージョン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で説明したように「第二の報告」のための要件を満たし、このレポートは、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).
このレポートの目的は、インターネットドラフト標準のようなルーティングプロトコルの公表のための要件は、ボーダーゲートウェイプロトコルバージョン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に記載されているように、このレポートは、「第二のレポート」の要件を満たします。要件を満たすために、このレポートは、[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.
最も重要なパスの一つは、自律システムパス、または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_SET属性を経由して自律システムのセットと同様にリストを含めるようにAS_PATH属性を強化します。この拡張形式は、生成された集約ルート集約を生成するために使用される、より特定のルートからのパス情報を搬送することを可能にします。 [ROUTEVIEWS]これを書いている時点では、AS_SETsはほとんどインターネットで使用されていないことに留意すべきです。
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は、それぞれの新しい着信および発信ピア接続のために開始し、維持しなければなりません。しかし、定常状態の動作で、ピアごとの接続ごとに1つだけのBGP FSMがあるでしょう。
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ピアが（代わりに一方の）ピアに関連する二つの異なるBGP用のFSMの生成をもたらす別の着信および発信接続を有していてもよく、その間に短い期間があってもよいです。これは[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.
IDLE：BGPピアは、すべての着信接続を拒否状態。
CONNECT: State in which BGP peer is waiting for its TCP connection to be completed.
CONNECT：そのTCP接続を完了するためにBGPピアを待っている状態を。
ACTIVE: State in which BGP peer is trying to acquire a peer by listening and accepting TCP connection.
ACTIVE：BGPピアがTCP接続をリスニングし、受け入れることによってピアを取得しようとされている状態。
OPENSENT: BGP peer is waiting for OPEN message from its peer.
OPENSENT：BGPピアはそのピアからOPENメッセージを待っています。
OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION message from its peer.
OPENCONFIRM：BGPピアはそのピアからのKEEPALIVEかNOTIFICATIONメッセージを待っています。
ESTABLISHED: BGP peer connection is established and exchanges UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
ESTABLISHED：BGPピア接続確立とそのピアとUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換します。
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スピーカがピア接続でエラーを検出するたびに、ピアをシャットダウンし、IDLEにその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.
この節では、「大きさの順序」BGPは、通常の条件で消費されますどのくらいのリンク帯域幅、ルータのメモリおよびルータCPUサイクルの質問に対する回答を提供します。特に、我々は、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のようなピアから受信され、ネットワークが均一自律システム間で分散されていることを前提としていBGPスピーカ（P）の対の間の最初の交換中に消費される帯域幅であります
BW = O((N + A) * P)
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によって運ば外部ルートのフルセットは、約134000ネットワークエントリー[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 UPDATEメッセージの発表に関して、BGPに関連し、そのネットワークの安定性に依存していることです。 BGPネットワークが安定している場合は、そのネットワーク内のすべてのBGPルータは、定常状態です。このように、BGPによって消費される唯一のリンク帯域幅とルータCPUサイクルはBGP KEEPALIVEメッセージの交換によるものです。キープアライブメッセージは、唯一のピア間で交換されています。為替の推奨頻度は30秒です。キープアライブメッセージは、（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アップデートメッセージを使用して交換されるルーティングアップデートを生成しています。各UPDATEメッセージは、単一のネットワークが含まれている場合、UPDATEメッセージ当たりの最大のオーバーヘッドが発生します。実際には、ルーティングの変更は、ルート属性に対する強い局所性を発揮する、ということを指摘しなければなりません。つまり、共通ルートの属性を持っている可能性があり変更するルートです。この場合には、複数のネットワーク（これも[BGP4]の付録F.1参照）を大幅に必要な帯域幅の量を減少させる、単一のUPDATEメッセージにグループ化することができます。
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
M（自律システムのレベルでの距離は、数で表したようにBGPのための最悪の場合のメモリ要件を定量化するために、我々は、インターネットの距離として平均、N、インターネットにおけるネットワークの総数を表します自律システム）、そして最悪の場合のメモリ要求（MR）A.としてパスAS一意の総数は、のように表すことができます。
MR = O(N + (M * A))
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は、インターネットの相互接続性（「meshiness」）の低速で移動機能で、平均は、すべての実用的な目的のために、最悪の場合、ルータのメモリ要件を乗じたインターネットでのネットワークの総数のオーダーであるため、ローカルシステムがとピアリングしていることをピアの数。私たちは、インターネットでのネットワークの総数はルータあたりのピアの平均数よりもはるかに速く成長することを期待しています。その結果、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).
次の表は、BGPを実行しているルータの典型的なメモリ要件を示しています。 M（自律システムのレベルでの距離は、数で表したように、我々は、インターネットの距離としてNとして、各ピアによってアドバタイズされたルートの平均数、Aのように一意のパスの総数、平均値を表します符号化される各AS自律システム）、Rなどのネットワークを格納するのに必要なオクテットの数、各ネットワークは4バイトとして符号化されているものとするP.としてAS経路におけるASいずれかを格納するのに必要なバイト数、 2バイト、及び各ネットワークは、すべてのピア（正味あたり＃BGPピア/）のいくつかの画分を介して到達可能です。ここでの見積もりの目的のために、私たちは=（（（N * R）+（M * A）* P）* S）MRを計算します。
# 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 RIBテーブルのサイズに焦点を当てます。特に、我々は、BGP RIBテーブルのサイズに上限を導き出します。たとえば、この記事の執筆時点では、典型的なバックボーンルータのBGPのRIBテーブル12万のエントリの順序に運びます。この数を考えると、一つは、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の問題ですが、（そのような例については、[RFC2622]を参照して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は現在のインターネットの商業環境に非常に適しています主な理由の一つです。
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.
しかし、この豊かなポリシー表現は、多くの場合、認識されないコストが付属しています。特に、プロトコル発散など（意図しない）非決定論として予期しないグローバルルーティング異常につながる可能性がローカルに定義されたルーティングポリシーを構築することが可能です。このような異常の原因となる相互作用のポリシーが異なる自律システムに定義されている場合は、これらの問題は、非常にデバッグが困難と正しいことができます。以下のセクションでは、我々は、安定した作業手順の存在に関連する二つのそのような場合について説明（またはその欠如します）。
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が安定したルーティングが一意であることを保証できないため、ポリシーのセットを構築することができます。これは、次の簡単な例で示されています。 4つの自律システム、AS1、AS2、AS3、およびAS4を考えてみましょう。 AS1とAS2は仲間であり、それらはそれぞれ、AS3とAS4のための輸送を提供しています。仮定AS3（この場合、AS3はAS1の顧客であり、AS4は、AS3とAS2の両方のマルチホーム顧客である）AS4のための通過を提供します。 AS4は、「バックアップ」リンクとしてAS3へのリンクを使用したい、とAS3はその上流プロバイダ、AS1のそれより下のレベルにAS4のルートの優先度を下げるように構成されていることをコミュニティ値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:
AS2-のAS4リンクがダウンしている場合には、AS3、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は、「私のルートをdepref」コミュニティはAS1のための「私のルートをdepref」コミュニティにAS4から受信した変換されません。 AS1はAS3を通過AS4へのルートを聞く場合（AS3は、顧客であるため）ので、それはそのルートを好むでしょう。この状態は、例えば、AS2、AS4 BGPセッションをダウンさせ、次にそれを戻す、最初示す「正しい」バックアップルーティングで開始することにより、到達することができます。一般的に、BGPは、異常な1以上の「意図」ソリューションを好むする方法がありません。選んだ解決策は、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.
この例では、比較的簡単ですが、多くの事業者は、問題の本当の原因は、のASの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を使用して適用することができます政策決定のセットを特徴づけるために、1はASがネイバーのAS、それ自体が使用するだけでそれらのルートにアドバタイズルールに焦点を当てる必要があります。このルールは反映します』一般的に、現在インターネット全体で使用される。いくつかのポリシーは、「ホップバイホップ」ルーティングパラダイムによって支持され、このように強制するようなソースルーティングのような技術を必要とすることはできません。にトラフィックを送信するように、例えば、BGPが1つをイネーブルしません現在のインターネットでのみ使用しているため、トラフィックがAS隣人に発信されるトラフィックで撮影したものとは別のルートを取ることを意図AS隣人。一方、BGPは「ホップバイホップ」ルーティングパラダイムに準拠した任意のポリシーをサポートすることができます「ホップバイホップ」ルーティングパラダイムとBGPがそのパラダイムに準拠する任意のポリシーをサポートすることができるので、BGPは現在のインターネットのためのAS間ルーティングプロトコルとして非常に適用可能です。」
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.
同時に、私たちはその機能を拡張することを可能にするプロトコル内で柔軟なメカニズムを提供しながら、ここで重要なポイントの一つは、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は、インターネットプロトコルと「ホップバイホップ」ルーティングパラダイムとして[RFC791] IPに基づいており、任意のインターネット相互自律システムルーティングプロトコルとして適しています。
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.
私たちは、この文書の以前のバージョンを作成するためのポールTrainaのを感謝したいと思います。エルウィン・デイヴィス、ティム・グリフィン、ランディPresuhn、カーティスVillamizarとアタヌ・ゴーシュも、この文書の以前のバージョンに多くの洞察に満ちたコメントを提供しました。
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セッションのアドレスを使用して認証し、AS番号割り当てられています。 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データ暗号化は、（TCPとBGPデータを含む）IPペイロードデータを暗号化するIPsecの機構を使用して提供されます。 IPsecの機構は、トランスポートモードとトンネルモードの両方で使用することができます。 IPsecの機構は、[RFC2406]に記載されています。 TCP MD5オプションとIPsecメカニズムの両方が広く、今日のインターネットでBGPのためのセキュリティメカニズムを展開されていません。したがって、BGPで使用しているとき彼らの本当のパフォーマンスへの影響を測ることは困難です。メカニズムの両方がTCP-およびIPベースのセキュリティ・メカニズムであるため、しかし、リンク帯域幅、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は、任意のTCP-またはIPベースのCPU集約型攻撃からその外部BGP（EBGP）セッションを保護するためにIP TTL値を使用しています。これはEBGPセッションの間で交換されるBGP（TCP）セグメントのIPヘッダ内で運ばIP TTL値を使用して、フィルタリングBGP（TCP）セグメントを使用することを示唆している単純な機構です。 BGP TTL機構は、[RFC3682]に記載されています。任意のアクセス制御リスト（ACL）BGPのポリシーを使用して、同様の方法で、[RFC3682]の衝撃性能の使用。
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プロトコル内で適切なセキュリティ・インフラストラクチャを作成し、定義するため進行中です。これらの取り組みは、[SOBGP] [SBGP]含めると。
[BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP4] Rekhter、Y.、李、T.、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP4）"、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]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997]チャンドラ、R.、Trainaの、P.、およびT.李、 "BGPコミュニティ属性"、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]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、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]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 3682、2004年2月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]チャンドラ、R.及びJ.スカダー、 "BGP-4との機能広告"、RFC 3392、2002年11月。
[BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[BGP-VULN]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、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]ソ、K.、S.ケント及びC.リンは、「セキュアボーダーゲートウェイプロトコル（BGP-セキュア）」通信VOLの選択された領域に、IEEEジャーナル。 18、第4号、2000年4月、頁。582- 592。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC854]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105]ロッキード、K.、およびY. Rekhter、 "ボーダーゲートウェイプロトコル（BGP）"、RFC 1105、1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]ロッキード、K.、およびY. Rekhter、 "ボーダーゲートウェイプロトコル（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]ロッキード、K.、およびY. Rekhter、 "ボーダーゲートウェイプロトコル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.グロス、エディタ、 "インターネットでのボーダゲイトウェイプロトコルの応用"、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.、マイヤー、D.、ベイツ、T.、Karrenberg、D.、およびM.テルプストラ、「ルーティングポリシー仕様言語（RPSL ）」、RFC 2622、1999年6月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[ROUTEVIEWS] Meyer, D., "The Route Views Project", http://www.routeviews.org.
[ROUTEVIEWS]マイヤー、D.は、http://www.routeviews.org、 "ルートプロジェクトビュー"。
[SOBGP] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Work in Progress, May 2005.
[SOBGP]ホワイト、R.、 "セキュア起源BGP（soBGP）のためのアーキテクチャと実装の考慮事項"、進歩、2005年5月での作業。
Authors' Addresses
著者のアドレス
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Keyur Patel Cisco Systems
Keyuraパテルシスコシステムズ
EMail: keyupate@cisco.com
メールアドレス：keyupate@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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）によって提供されます。