RFC4274 日本語訳
4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT=38200 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Meyer
Request for Comments: 4274 K. Patel
Category: Informational Cisco Systems
January 2006
コメントを求めるワーキンググループD.マイヤー要求をネットワークでつないでください: 4274年のK.パテルカテゴリ: 情報のシスコシステムズ2006年1月
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)インターネット協会(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)によってインターネットDraft Standardとしてのルーティング・プロトコルの公表のための要件がどう満たされたかを記録することです。
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.
このレポートはRFC1264のセクション6.0で説明されるように「2番目のレポート」のための要件を満たします。 要求にこたえるために、このレポートは、RFC1774を増大させて、BGP-4に関する重要な特色をまとめて、スケーリングと性能に関してプロトコルを分析します。
Meyer & Patel Informational [Page 1] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[1ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
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
1. 序論…2 2. BGPの重要な特色とアルゴリズム…3 2.1. 主要な特徴…3 2.2. BGPアルゴリズム…4 2.3. BGP有限状態機械(FSM)…4 3. BGP能力…5 4. BGPのしつこい同輩振動…6 5. 実現ガイドライン…6 6. BGPパフォーマンスの特性とスケーラビリティ…6 6.1. 帯域幅とCPU利用をリンクしてください…7 7. BGP Policy ExpressivenessとそのImplications…9 7.1. ユニークな安定したRoutingsの存在…10 7.2. 安定したRoutingsの存在…11 8. 適用性…12 9. 承認…12 10. セキュリティ問題…12 11. 参照…13 11.1. 標準の参照…13 11.2. 有益な参照…14
1. Introduction
1. 序論
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]のAppendix 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はClassless Inter-ドメインルート設定(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)によってインターネットDraft Standardとしてのルーティング・プロトコルの公表のための要件がどう満たされたかを記録することです。
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番目のレポート」のための要件を満たします。 要求にこたえるために、このレポートは、BGP-4に関する重要な特色を増大して[RFC1774]、まとめて、スケーリングと性能に関してプロトコルを分析します。
Meyer & Patel Informational [Page 2] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[2ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
2. Key Features and Algorithms of BGP
2. BGPの重要な特色とアルゴリズム
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を通して交換された情報がルーティング輪余計なものを取り除かれるかもしれない自律システムの接続性のグラフを作図できるくらい自律システムレベルにおける多くのルーティング政策決定が励行されるかもしれません。
2.1. Key Features
2.1. 重要な特色
The key features of the protocol are the notion of path attributes and aggregation of Network Layer Reachability Information (NLRI).
プロトコルに関する重要な特色は、経路属性の概念とNetwork Layer Reachability情報(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つは、Autonomous System Path、または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
BGPは、AS_SET属性を通したリストと同様に自律システムのセットを含むようにAS_PATH属性を高めます。 この拡張フォーマットで、発生している集合ルートは経路情報を運ぶことができます。
Meyer & Patel Informational [Page 3] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[3ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
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].
集合を発生させるのに使用されるより特定のルートから。 しかしながら、この書くこと現在AS_SETsがインターネット[ROUTEVIEWS]でめったに使用されないことに注意されるべきです。
2.2. BGP Algorithms
2.2. BGPアルゴリズム
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属性の中に格納されます。 AS輪を検出して、その結果、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は、帯域幅と処理能力を保存するのにアップデート増加戦略を使用します。 すなわち、完全なルーティング情報の初期の交換の後に、1組のBGPルータはその情報への変化だけを交換します。 そのようなアップデート増加デザインは、正しく機能するように1組の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は、独身のNetwork Layer Reachability(NLRI)として階層的なアドレス課題(例えば、CIDR)を使用する目的地のグループの情報を集めて、送ることができるようにルート集合の概念を加えました。
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スピーカーの間で。
2.3. BGP Finite State Machine (FSM)
2.3. BGP有限状態機械(FSM)
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スピーカーの構成された同輩のセットに適用される1セットの規則です。 BGP実現は、BGPスピーカーが同輩からどんな新しいBGP接続も受け入れるためにポート179を接続して、TCPで聴かなければならないのを必要とします。 それぞれの新しい送受信の同輩接続のためにBGP Finite州Machine、またはFSMを開始されて、維持しなければなりません。 しかしながら、定常状態操作には、1接続あたり1BGP FSMしか同輩単位でないでしょう。
Meyer & Patel Informational [Page 4] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[4ページ]のRFC4274BGP-4は分析2006年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同輩が別々の送受信の接続に同輩(1の代わりに)に関連する2異なったBGP FSMsの創造をもたらさせるかもしれない短期があるかもしれません。 [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.
OPENSENT: BGP同輩は同輩からのオープンメッセージを待っています。
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.
確立する: 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出来事はタイプに従うものです: 任意の出来事はOptional Session属性、Administrative Events、Timer Events、TCP ConnectionベースのEvents、およびBGP MessageベースのEventsにリンクされました。 FSMとBGP出来事の両方が[BGP4]で詳細に説明されます。
3. BGP Capabilities
3. BGP能力
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はシグナリングプロトコル拡大にフレキシブルなメカニズムを提供している間、不可欠の機能性しか含むことができません。
Meyer & Patel Informational [Page 5] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[5ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
4. BGP Persistent Peer Oscillations
4. 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がIDLEに述べる同輩と変化を止めます。 BGPスピーカーは、無駄な同輩接続を再開始するためにStart出来事を必要とします。 誤りがしつこいままでいて、BGPスピーカーがStart出来事を自動的に発生させるなら、それはしつこい同輩のばたつくことをもたらすかもしれません。 同輩振動はBGP実現で広範囲であることがわかっていますが、ベースBGP仕様の範囲の外にしつこい同輩振動を防ぐための方法があります。
5. Implementation Guidelines
5. 実施要綱
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. それが損をしているpeeringsなしでほぼ任意に高いレベルのルートフラップで作動できますか(keepalivesを送らないで)、または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実現は存在しています。 体力を要している実現を起こすのは、ざらにある出来事ではありませんが、明確に達成可能です。
6. BGP Performance Characteristics and Scalability
6. 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のスケーラビリティとその制限を記述するつもりです。
Meyer & Patel Informational [Page 6] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[6ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
6.1. Link Bandwidth and CPU Utilization
6.1. リンク帯域幅とCPU利用
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、Aとして同輩から受け取られた総経路属性(すべてのNルートへの)としてインターネットのルートの総数を指示して、ネットワークが自律システムの中で一様に分配されると思うなら、1組の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によって運ばれた外のルートのフルセットはおよそ13万4000のネットワークエントリー[ROUTEVIEWS]です。
6.1.1. CPU Utilization
6.1.1. CPU利用
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メッセージの交換のためです。 同輩だけの間でKEEPALIVEメッセージを交換します。 交換の提案された頻度は30秒です。 KEEPALIVEメッセージは、かなり短く(19の八重奏)、実際には処理するのを必要としません。 その結果、KEEPALIVEメッセージによって消費された帯域幅はおよそ5ビット/秒です。 運用経験は、KEEPALIVEメッセージに関連しているオーバーヘッド(帯域幅とCPUに関する)が取るにたらないとして見なされるべきであると確認します。
Meyer & Patel Informational [Page 7] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[7ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
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メッセージがただ一つのネットワークだけを含んでいると、UPDATEメッセージあたりの最もすばらしいオーバーヘッドは起こります。 ルーティング変化が実際にはルート属性に関して強い場所を示すと指摘されるべきです。 すなわち、変化するルートは一般的なルート属性を持っていそうです。 この場合、複数のネットワークをただ一つのUPDATEメッセージに分類できます、その結果、帯域幅の量をかなり減少させるのが必要です(また、[BGP4]のAppendix F.1を見てください)。
6.1.2. Memory Requirements
6.1.2. メモリ要件
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(自律システムの数で言い表された自律システムのレベルにおける距離)としてのインターネットの平均であるAS距離、A.Thenとしての最悪の場合メモリ要件(MR)を言い表すことができるユニークなAS経路の総数
MR = O(N + (M * A))
さんは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.
平均であるAS距離Mがインターネットの相互接続性("meshiness")の遅い感動的な関数であるので、ローカルシステムとじっと見ている同輩の数が掛けられたインターネットのネットワークの総数の注文には実際上は最悪の場合ルータメモリ要件があります。 私たちは、インターネットのネットワークの総数が1ルータあたりの同輩の平均した数よりはるかに速くなると予想します。 その結果、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を走らせながら、ルータの典型的なメモリ要件を例証します。 私たちはNとして各同輩によって広告に掲載されたルートの平均した数を指示します、AとしてのユニークなAS経路の総数、M(自律システムの数で言い表された自律システムのレベルにおける距離)としてのインターネットの平均であるAS距離、R、およびバイト数がPとしてAS経路に1ASを格納するのが必要であるのでネットワークを格納するのに必要である八重奏の数; 各ネットワークが4バイト、各ASが2バイトとしてコード化されるのでそれぞれコード化されて、ネットワークがすべての同輩(1ネットあたりの#BGP同輩/)のある部分を通して届いているということであると思われます。 ここの見積りの目的のために、私たちは、MRが(N*R)+(M*a)*P)*S)と等しいと見込むつもりです。
Meyer & Patel Informational [Page 8] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[8ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
# 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
# ネットのMemory Req(N)(M)(A)(P)(MR)あたりのMean AS Distance#ASes#BGP同輩/をネットワークでつなぎます。---------- ---------------- ------ ------------------- ------------- 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万のエントリーの注文のときにこの書くこと時点で、運ばれます。 この数を考えて、テーブルが100万のエントリーを含んでいて、人は、機能的なルータを持っているのが可能であるかどうか尋ねるかもしれません。 明確に、この質問の答えはBGPがどう実行されるかとさらに関係づけられます。 妥当なCPUとメモリがある体力を要しているBGP実現には、そのような限界に比例する問題があるべきではありません。
7. BGP Policy Expressiveness and its Implications
7. BGP Policy ExpressivenessとそのImplications
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ルーティング方針を指定するための言語とテクニックがプロトコル仕様の一部でないことに注意するのは重要です(そのような方針言語の例に関して[RFC2622]を見てください)。 さらに、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
少なくともプロバイダーネットワークにおける、典型的なBGP構成の複雑さは着実に増加しています。 ルータ業者は何百もの特別なコマンドをBGPの構成における使用に通常提供します、そして、このコマンドセットは絶えず膨張しています。 例えば、BGP共同体[RFC1997]は、方針作家に選択的にタグをルートに取り付けて、他のBGP-話しルータに方針情報に合図するのにこれらを使用させます。 多くのプロバイダーが顧客、および時々同輩を許容して、それを共同体に送るのはそれらのルートの範囲と好みを決定します。 これらの開発のため、BGPに構成を書くタスクには、終わった戸外のプログラミングに関連しているますますより多くの局面があります。 そしてこれが多くの予期しない状況を記述するためにネットワーク・オペレータが複雑な方針をコード化するのを許容して、多くの創造性のためにドアを開けた。
Meyer & Patel Informational [Page 9] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[9ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
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が現在のインターネットの商業環境にあまりによく合っている主な理由の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.
しかしながら、この豊かな方針表情の豊かさはしばしば認識されるというわけではない費用と共に来ました。 (故意ではありません)の非決定論などのプロトコル分岐と予期していなかったグローバルなルーティング例外につながることができる局所的に定義されたルーティング方針を構成するのは特に、可能です。 そのような例外を引き起こす相互作用方針が異なった自律システムで定義されるなら、これらの問題は、デバッグするのが非常に難しくて正しい場合があります。 以下のセクションで、私たちは安定したroutingsの存在(または、それの不足)に関連するそのような2つの場合について説明します。
7.1. Existence of Unique Stable Routings
7.1. ユニークな安定した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:
1つは容易にBGPが安定したroutingsがユニークであることを保証できない方針のセットを構成できます。 これは以下の簡単な例によって例証されます。 4Autonomous Systems、AS1、AS2、AS3、およびAS4を考えてください。 AS1とAS2は同輩です、そして、彼らはそれぞれAS3とAS4にトランジットを供給します。 AS3がトランジットをAS4に供給する(この場合AS3はAS1の顧客です、そして、AS4はAS3とAS2の両方の「マルチ-家へ帰」っている顧客である)と仮定してください。 AS4は、上流のプロバイダー(AS1)のものの下のレベルにAS4のルートの好みを下げるために、「バックアップ」リンクとしてAS3へのリンクを使用したいかもしれなくて、AS3が構成した共同体値をAS3に送ります。 AS4への意図している「バックアップルーティング」はここで例証されます:
AS1 ------> AS2
/|\ |
| |
| |
| \|/
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リンクが下がっているときだけ(アウトバウンドトラフィックのために、AS4は単により高い地方の優先をAS2からのルートに与えます)、すなわち、AS3-AS4リンクが使用されることを意図します。 これは今日のインターネットの共通したシナリオです。 しかし、この構成には別の安定した解決策があることに注意してください:
AS1 ------- AS2
| |
| |
| |
\|/ \|/
AS3 ------> AS4
AS1------- AS2| | | | | | \|/ \|/AS3------>AS4
Meyer & Patel Informational [Page 10] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[10ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
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が翻訳しない、「AS1のための」 共同体がAS4からaに受けた私のルートが「私のルートをdeprefする」というdepref共同体。 したがって、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方針が予期していなかった方法で相互作用できて、これらの相互作用が複数の安定したroutingsをもたらすことができるということであると認めないかもしれません。 人は、相互作用が本当のインターネットではるかに複雑であるかもしれないと想像できます。 私たちは、BGPが、より豊かな方針表情の豊かさで発展し続けているのに従ってそのような例外が、より一般的になるだけであると疑います。 例えば、拡張共同体は情報に合図する[RFC1997]共同体で可能であるよりさらにフレキシブルな手段を自律システム以内と自律システムの間に提供します。 同時に、ネットワーク・オペレータによる共同体のアプリケーションは、相互ドメイン交通工学の複雑な問題を記述するために発展します。
7.2. Existence of Stable Routings
7.2. 安定したRoutingsの存在
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.
また、1つはBGPが安定したルーティングが存在するのを保証できない1セットの方針を構成できます(よりひどく、そのa安定したルーティングは今までに、見つけられるでしょう)。 例えば、[RFC3345]はMulti-出口Discriminator(MED)属性の使用に関連しているルート振動につながるいくつかのシナリオを記録します。 1セットの方針に解決策が全くないとき、ルート振動は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属性の使用に関連している問題ではありません。 この可能性はBGPにMED属性の使用がなくても存在しています。 したがって、前項で説明された故意でない「非-決定論」のように、このタイプのプロトコル分岐はBGP方針言語の自由な本質の予期せぬ結果です。
Meyer & Patel Informational [Page 11] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[11ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
8. Applicability
8. 適用性
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で部分的に答えられます。(BGPは以下を述べます)。
"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がそれ自体が使用するそれらのルートの隣人ASesだけに広告を出すという規則に焦点を合わせなければなりません。」 この規則は一般に、現在のインターネット中で使用される「ホップごとの」ルーティングパラダイムを反映します。 いくつかの方針が「ホップごとの」ルーティングパラダイムによってサポートされて、その結果、実施するソースルーティングなどのテクニックを必要とすることができないことに注意してください。 例えば、BGPは、1ASが交通が隣人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.
ここの重要なポイントの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]に基づいているどんなインターネットのための相互自律システムルーティング・プロトコルとしてもよく合っています。
9. Acknowledgements
9. 承認
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に感謝申し上げます。 また、Elwynデイヴィース、ティム・グリフィン、ランディPresuhn、カーティスVillamizar、およびAtanuゴーシュはこのドキュメントの以前のバージョンの多くの洞察に満ちたコメントを提供しました。
10. Security Considerations
10. セキュリティ問題
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
BGPはセキュリティ目的のために異なったレベルの複雑さをフレキシブルなメカニズムに提供します。 BGPセッションは、BGPセッションアドレスと割り当てられたAS番号を使用することで認証されます。 BGPセッションが信頼できる輸送に、TCP(そして、IP)を使用するので、BGPセッションは、より遠いです。
Meyer & Patel Informational [Page 12] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[12ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
authenticated and secured by any authentication and security mechanisms used by TCP and IP.
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]で説明されます。 [RFC3562]でTCP MD5 Key管理について議論します。 IPsecメカニズム(IPペイロードデータを暗号化する)を使用することで(TCPとBGPデータを含んでいて)BGPデータ暗号化を提供します。 交通機関とトンネルモードの両方でIPsecメカニズムを使用できます。 IPsecメカニズムは[RFC2406]で説明されます。 TCP MD5オプションとIPsecメカニズムの両方が今日のインターネットのBGPのためのセキュリティー対策であることは広く配布されません。 BGPと共に使用するとき、したがって、それらの本当の性能影響を測るのは難しいです。 しかしながら、両方のメカニズムがTCPとIPベースのセキュリティー対策であるので、BGPによって消費されたLink Bandwidth、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徹底的な攻撃からもExternal BGP(EBGP)セッションを保護するのにIP TTL値を使用します。 それはフィルタリングBGP(TCP)セグメントの使用を示す簡単なメカニズムです、EBGPセッションの間で交換されるBGP(TCP)セグメントのIPヘッダーの中に運ばれたIP TTL値を使用して。 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]を含んでいます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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.野兎、Eds、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271、1月2006日
[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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
Meyer & Patel Informational [Page 13] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[13ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[RFC1997] チャンドラとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、1996年8月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、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.レタナは「ゲートウェイのプロトコルの(BGP)永続的なルート振動状態に接しています」、RFC3345、2002年8月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP
MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、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)」、RFC3682 2004年2月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC3392] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
[BGP-VULN] マーフィー、S.、「BGPセキュリティの脆弱性分析」、RFC4272、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.ケント、およびC.リン)は「ボーダ・ゲイトウェイ・プロトコル(安全なBGP)を保証します」、Communications Vol.18におけるSelected Areasの上のIEEE Journal、No.4、2000年4月、ページ 582- 592.
11.2. Informative References
11.2. 有益な参照
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC854] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1105, June 1989.
[RFC1105]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1105 1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1163, June 1990.
[RFC1163]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1163 1990年6月。
[RFC1264] Hinden, R., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[RFC1264] Hinden、R.、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、1991年10月。
Meyer & Patel Informational [Page 14] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[14ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[RFC1267]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267 1991年10月。
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application
of the Border Gateway Protocol in the Internet", RFC
1772, March 1995.
1995年3月の[RFC1772]Rekhter、Y.と総計のP.エディターズ、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」RFC1772。
[RFC1774] Traina, P., "BGP-4 Protocol Analysis", RFC 1774, March
1995.
[RFC1774] Traina、P.、「BGP-4プロトコル分析」、RFC1774、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)」、RFC2622(1999年6月)。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、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]ホワイト、仕事進行中の「安全な発生源BGP(soBGP)のためのアーキテクチャと展開問題」というR.は2005がそうするかもしれません。
Authors' Addresses
作者のアドレス
David Meyer
デヴィッド・マイヤー
EMail: dmm@1-4-5.net
メール: dmm@1-4-5.net
Keyur Patel Cisco Systems
Keyurパテルシスコシステムズ
EMail: keyupate@cisco.com
メール: keyupate@cisco.com
Meyer & Patel Informational [Page 15] RFC 4274 BGP-4 Protocol Analysis January 2006
マイヤーとパテル情報[15ページ]のRFC4274BGP-4は分析2006年1月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Meyer & Patel Informational [Page 16]
マイヤーとパテルInformationalです。[16ページ]
一覧
スポンサーリンク
