Network Working Group D. McPherson
Request for Comments: 4277 Arbor Networks
Category: Informational K. Patel
Cisco Systems
January 2006
Experience with the BGP-4 Protocol
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 memo 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 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard.
このレポートは、要件を満たすために、RFC 1264のセクション6.0で説明したように「第二の報告」のための要件を満たし、このレポートは、RFC 1773を増強し、プロトコルが行われたときの間の時間で得られた付加的な知識と理解を記述するドラフト標準とそれが標準のために提出されました。
Table of Contents
目次
1. Introduction ................................................. 3
2. BGP-4 Overview ............................................... 3
2.1. A Border Gateway Protocol .............................. 3
3. Management Information Base (MIB) ............................ 3
4. Implementation Information ................................... 4
5. Operational Experience ....................................... 4
6. TCP Awareness ................................................ 5
7. Metrics ...................................................... 5
7.1. MULTI_EXIT_DISC (MED) .................................. 5
7.1.1. MEDs and Potatoes .............................. 6
7.1.2. Sending MEDs to BGP Peers ...................... 7
7.1.3. MED of Zero Versus No MED ...................... 7
7.1.4. MEDs and Temporal Route Selection .............. 7
8. Local Preference ............................................. 8
9. Internal BGP In Large Autonomous Systems ..................... 9
10. Internet Dynamics ............................................ 9
11. BGP Routing Information Bases (RIBs) ......................... 10
12. Update Packing ............................................... 10
13. Limit Rate Updates ........................................... 11
13.1. Consideration of TCP Characteristics ................... 11
14. Ordering of Path Attributes .................................. 12
15. AS_SET Sorting ............................................... 12
16. Control Over Version Negotiation ............................. 13
17. Security Considerations ...................................... 13
17.1. TCP MD5 Signature Option ............................... 13
17.2. BGP Over IPsec ......................................... 14
17.3. Miscellaneous .......................................... 14
18. PTOMAINE and GROW ............................................ 14
19. Internet Routing Registries (IRRs) ........................... 15
20. Regional Internet Registries (RIRs) and IRRs, A Bit
of History ................................................... 15
21. Acknowledgements ............................................. 16
22. References ................................................... 17
22.1. Normative References ................................... 17
22.2. Informative References ................................. 17
The purpose of this memo 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 [RFC1773] and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard.
[RFC1264]のセクション6.0に記載されているように、このレポートは、「第二のレポート」の要件を満たします。要件を満たすために、このレポートは、[RFC1773]を増強し、プロトコルが標準案行われたとき、それが標準のために提出されたときの間の時間で得た追加的な知識と理解を示しています。
BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability, from which routing loops may be pruned and some policy decisions, at the AS level, may be enforced.
BGPは、TCP / IPインターネットのために設計された相互自律システムルーティングプロトコルです。 BGP話すシステムの主な機能は他のBGPシステムとネットワーク到達可能性情報を交換することです。このネットワーク到達可能性情報は、到達可能性情報を横断する自律システム（のAS）のリストに関する情報を含みます。この情報は、ルーティングループが剪定されてもよく、いくつかの方針決定は、ASレベルで、実施することができるから、この到達可能性の接続としてのグラフを構築するのに十分です。
The initial version of the BGP protocol was published in [RFC1105]. Since then, BGP Versions 2, 3, and 4 have been developed and are specified in [RFC1163], [RFC1267], and [RFC1771], respectively. Changes to BGP-4 after it went to Draft Standard [RFC1771] are listed in Appendix N of [RFC4271].
BGPプロトコルの最初のバージョンは、[RFC1105]に掲載されました。それぞれ、それ以来、BGPバージョン2、3、及び4が開発されていると[RFC1163]、[RFC1267]及び[RFC1771]で指定されています。 BGP-4に変更し、それが標準[RFC1771]をドラフトに行った後は、[RFC4271]の付録Nに記載されています。
The initial version of the BGP protocol was published in [RFC1105]. BGP version 2 is defined in [RFC1163]. BGP version 3 is defined in [RFC1267]. BGP version 4 is defined in [RFC1771] and [RFC4271]. Appendices A, B, C, and D of [RFC4271] provide summaries of the changes between each iteration of the BGP specification.
BGPプロトコルの最初のバージョンは、[RFC1105]に掲載されました。 BGPバージョン2は、[RFC1163]で定義されています。 BGPバージョン3は、[RFC1267]で定義されています。 BGPバージョン4は、[RFC1771]及び[RFC4271]で定義されています。付録A、B、C、及びDの[RFC4271]はBGPの仕様の各反復の間に変更の要約を提供します。
The BGP-4 Management Information Base (MIB) has been published [BGP-MIB]. The MIB was updated from previous versions, which are documented in [RFC1657] and [RFC1269], respectively.
BGP-4管理情報ベース（MIB）[BGP-MIB]公開されています。 MIBは、それぞれ、[RFC1657]及び[RFC1269]に記載されている以前のバージョンから更新されました。
Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table.
BGPピア表とBGP受信したパス属性テーブル：別にいくつかのシステム変数から、BGP MIBは、二つのテーブルに分割されます。
The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table.
ピア・テーブルは、それらの状態と現在の活動としてBGPピア接続に関する情報を反映しています。ローカルルーティングポリシーが適用される前に受信したパス属性テーブルはすべてのピアから受信したすべての属性が含まれています。ルートを決定する際に使用される実際の属性は、受信した属性テーブルのサブセットです。
There are numerous independent interoperable implementations of BGP currently available. Although the previous version of this report provided an overview of the implementations currently used in the operational Internet, at that time it has been suggested that a separate BGP Implementation Report [RFC4276] be generated.
現在利用可能なBGPの多数の独立した相互運用可能な実装があります。このレポートの以前のバージョンが現在運用インターネットで使用される実装の概要を提供しますが、その時点では、個別のBGPの実施報告[RFC4276]が生成されることが示唆されています。
It should be noted that implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC1656].
シスコのBGP-4の実装と実装経験が[RFC1656]の一部として文書化されたことに留意すべきです。
For all additional implementation information please reference [RFC4276].
すべての追加実装の詳細については、[RFC4276]を参照してください。
This section discusses operational experience with BGP and BGP-4.
このセクションでは、BGPとBGP-4での運用経験について説明します。
BGP has been used in the production environment since 1989; BGP-4 has been used since 1993. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of link bandwidth, it varies from 56 Kbps to 10 Gbps. In terms of the actual routers that run BGP, they range from relatively slow performance, general purpose CPUs to very high performance RISC network processors, and include both special purpose routers and the general purpose workstations that run various UNIX derivatives and other operating systems.
BGPは1989年以来、本番環境で使用されてきました。 BGPの1993年生産の使用は、プロトコルのすべての重要な機能の利用が含まれているため、BGP-4が使用されてきました。 BGPがインター自律システムルーティングプロトコルとして使用されている現在の生産環境は、非常に不均一です。リンク帯域幅の点で、それは56 Kbpsのからの10Gbpsまで変化します。 BGPを実行し、実際のルータの観点から、それらは比較的遅く、性能、汎用CPUを非常に高性能RISCネットワークプロセッサの範囲で、および特殊目的のルータと、様々なUNIX誘導体および他のオペレーティングシステムを実行する汎用のワークステーションの両方を含みます。
In terms of the actual topologies, it varies from very sparse to quite dense. The requirement for full-mesh IBGP topologies has been largely remedied by BGP Route Reflection, Autonomous System Confederations for BGP, and often some mix of the two. BGP Route Reflection was initially defined in [RFC1966] and was updated in [RFC2796]. Autonomous System Confederations for BGP were initially defined in [RFC1965] and were updated in [RFC3065].
実際のトポロジーの面では、それは非常にまばらなのはかなり密に変わります。フルメッシュIBGPのトポロジーのための要件は、主にBGPルートリフレクション、BGPのための自律システム連合、および2つのことが多いいくつかの組み合わせによって改善されてきました。 BGPルート反射が最初に[RFC1966]で定義して、[RFC2796]に更新されました。 BGPのための自律システムコンフェデレーションズ最初は[RFC1965]で定義され、[RFC3065]に更新されました。
At the time of this writing, BGP-4 is used as an inter-autonomous system routing protocol between all Internet-attached autonomous systems, with nearly 21k active autonomous systems in the global Internet routing table.
これを書いている時点で、BGP-4は、グローバルインターネットルーティングテーブルにほぼ21Kアクティブ自律システムで、すべてのインターネット接続の自律システム間の相互自律システムルーティングプロトコルとして使用されます。
BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no protocol distinction between sites historically considered "backbones" versus "regional" or "edge" networks.
BGPはトランジットおよびスタブ自律システム間でルーティング情報の交換のため、および複数のトランジット自律システム間でルーティング情報の交換の両方に使用されます。歴史的に「地域」や「エッジ」ネットワーク対「バックボーン」とみなさサイトの間には、プロトコルの区別はありません。
The full set of exterior routes carried by BGP is well over 170,000 aggregate entries, representing several times that number of connected networks. The number of active paths in some service provider core routers exceeds 2.5 million. Native AS path lengths are as long as 10 for some routes, and "padded" path lengths of 25 or more autonomous systems exist.
BGPによって運ば外部ルートのフルセットは、数回接続されたネットワークの数を表す、優に超える17万集約エントリです。いくつかのサービスプロバイダーコアルータのアクティブパスの数は250万を超えています。ネイティブASパスの長さであれば、いくつかのルートの10通りであり、そして25の以上の自律システムの「パディング」経路長が存在します。
BGP employs TCP [RFC793] as it's Transport Layer protocol. As such, all characteristics inherent to TCP are inherited by BGP.
BGPは、トランスポート層プロトコルだとして[RFC793] TCPを採用しています。そのため、TCPに固有のすべての特性は、BGPによって継承されています。
For example, due to TCP's behavior, bandwidth capabilities may not be realized because of TCP's slow start algorithms and slow-start restarts of connections, etc.
例えば、TCPの動作のために、帯域幅能力があるためなどTCPのスロースタートアルゴリズムとの接続のスロースタートの再起動の実現することはできません
This section discusses different metrics used within the BGP protocol. BGP has a separate metric parameter for IBGP and EBGP. This allows policy-based metrics to overwrite the distance-based metrics; this allows each autonomous system to define its independent policies in Intra-AS, as well as Inter-AS. BGP Multi Exit Discriminator (MED) is used as a metric by EBGP peers (i.e., inter-domain), while Local Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
このセクションでは、BGPプロトコル内で使用される異なるメトリックを論じています。 BGPはIBGPとEBGP用に別のメトリックのパラメータを持っています。これは、距離ベースのメトリックを上書きするポリシーベースのメトリックを可能にします。これは、イントラAS、などのInter-ASでの独立したポリシーを定義するために、各自律システムを可能にします。ローカルプリファレンス（LOCAL_PREF）はIBGPピア（すなわち、ドメイン内）で使用されている間BGPマルチ終了ディスクリミネータ（MED）は、EBGPピア（すなわち、ドメイン間）でメトリックとして使用されます。
BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_DISC (MED). This value may be used in the tie-breaking process when selecting a preferred path to a given address space, and provides BGP speakers with the capability of conveying the optimal entry point into the local AS to a peer AS.
BGPバージョン4を再定義した古いINTER-AS MULTI_EXIT_DISC（MED）としてメトリック。この値は、指定されたアドレス空間への優先パスを選択する際にタイブレーク工程で使用され、ASピアようローカルに最適なエントリポイントを搬送する能力をBGPスピーカを提供することができます。
Although the MED was meant to only be used when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different autonomous systems.
MEDを比較するパスが同じASに異なる外部ピアから受信した場合にのみ使用されることを意図しているが、多くの実装は、異なる自律システム間のMEDを比較する能力を提供します。
Though this may seem a fine idea for some configurations, care must be taken when comparing MEDs of different autonomous systems. BGP speakers often derive MED values by obtaining the IGP metric associated with reaching a given BGP NEXT_HOP within the local AS. This allows MEDs to reasonably reflect IGP topologies when advertising routes to peers. While this is fine when comparing MEDs of multiple paths learned from a single adjacent AS, it can result in potentially bad decisions when comparing MEDs of different autonomous systems. This is most typically the case when the autonomous systems use different mechanisms to derive IGP metrics, BGP MEDs, or perhaps even use different IGP protocols with vastly contrasting metric spaces.
これは、いくつかの構成のために細かなアイデアに思えるかもしれないが異なる自律システムののMEDを比較する際、注意が必要です。 BGPスピーカは、多くの場合、ローカルAS内の所定BGP NEXT_HOPに達するに関連付けられているIGPメトリックを取得することによって、MED値を導き出します。これは、ピアへのルートをアドバタイズするときのMEDは、合理的IGPトポロジを反映することができます。単一の隣接ASから学んだ複数のパスののMEDを比較するとき、これが細かいですが異なる自律システムののMEDを比較するとき、それは潜在的に悪い意思決定につながることができます。これは、最も典型的には自律システムは、BGPのMEDをIGPメトリックを導き出すか、おそらく大幅に対照的な距離空間と異なるIGPプロトコルを使用する別のメカニズムを使用する場合です。
Another MED deployment consideration involves the impact of the aggregation of BGP routing information on MEDs. Aggregates are often generated from multiple locations in an AS to accommodate stability, redundancy, and other network design goals. When MEDs are derived from IGP metrics associated with said aggregates, the MED value advertised to peers can result in very suboptimal routing.
別のMED配備の考慮事項は、医療検査素子に関するルーティング情報をBGPの凝集の影響を含みます。凝集体は、多くの場合、安定性、冗長性、およびその他のネットワーク設計目標に対応するために、AS内の複数の場所から生成されています。医療検査素子は、前記凝集体に関連したIGPメトリックから導出されている場合、ピアにアドバタイズMED値が非常に準最適ルーティングをもたらすことができます。
The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was to ensure that peers could not "shed" or "absorb" traffic for networks they advertise.
MEDは、意図的に、最高のパス決定プロセスの後半で使用される「弱い」メトリックなるように設計されました。 BGPワーキンググループは、他の優先を指定しなかったかのように遠隔操作で指定されたメトリックは、ローカルにルーティング影響を与えることを懸念しました。 MEDの設計の最も重要な目標は、ピアは「小屋」や、彼らが宣伝のためにネットワークトラフィックを「吸収」ことができなかったことを確実にするためでした。
Where traffic flows between a pair of destinations, each is connected to two transit networks, each of the transit networks has the choice of sending the traffic to the peering closest to another transit provider or passing traffic to the peering that advertises the least cost through the other provider. The former method is called "hot potato routing" because, like a hot potato held in bare hands, whoever has it tries to get rid of it quickly. Hot potato routing is accomplished by not passing the EBGP-learned MED into the IBGP. This minimizes transit traffic for the provider routing the traffic. Far less common is "cold potato routing", where the transit provider uses its own transit capacity to get the traffic to the point in the adjacent transit provider advertised as being closest to the destination. Cold potato routing is accomplished by passing the EBGP-learned MED into IBGP.
トラフィックが宛先のペアの間を流れる場合、各々は二つのトランジットネットワークに接続され、トランジットネットワークの各々は、別のトランジットプロバイダにピアリング最も近くにトラフィックを送信または介して最小コストを広告ピアリングにトラフィックを渡す選択を有します他のプロバイダ。前者の方法は、「ホットポテトルーティング」と呼ばれている、なぜならそれはすぐにそれを取り除くしようとする人は誰でも持って素手で開催されたホットポテト、等です。ホットポテトルーティングはIBGPにEBGP学習MEDを渡していないことによって達成されます。これは、トラフィックをルーティングするプロバイダの通過トラフィックを最小限に抑えることができます。はるかに少ない共通のトランジットプロバイダが先に最も近いものとしてアドバタイズ隣接トランジット・プロバイダにポイントへのトラフィックを取得するために、独自の輸送能力を使用し、「コールドポテトルーティング」は、です。冷たいポテトルーティングはIBGPにEBGP学習MEDを通過させることによって達成されます。
If one transit provider uses hot potato routing and another uses cold potato routing, traffic between the two tends to be symmetric. Depending on the business relationships, if one provider has more capacity or a significantly less congested transit network, then that provider may use cold potato routing. The NSF-funded NSFNET backbone and NSF-funded regional networks are examples of widespread use of cold potato routing in the mid 1990s.
1つのトランジットプロバイダはホットポテトルーティングを使用し、別の冷たいポテトルーティングを使用する場合は、両者の間のトラフィックが対称になる傾向があります。 1つのプロバイダは、より多くの容量または大幅に少なく混雑トランジットネットワークを持っている場合は、ビジネスの関係によっては、そのプロバイダは冷たいポテトルーティングを使用することができます。 NSFが資金提供NSFNETバックボーンとNSFの資金による地域ネットワークは、1990年代半ば冷たいポテトルーティングの普及の例です。
In some cases, a provider may use hot potato routing for some destinations for a given peer AS, and cold potato routing for others. The different treatment of commercial and research traffic in the NSFNET in the mid 1990s is an example of this. However, this might best be described as 'mashed potato routing', a term that reflects the complexity of router configurations in use at the time.
いくつかのケースでは、プロバイダは、他のルーティング一部として与えられるピアの宛先、及び冷ポテトホットポテトルーティングを使用することができます。 1990年代半ばNSFNETの商業および研究トラフィックの異なる治療はその一例です。しかし、これは最高の「マッシュポテトルーティング」、一度に使用中のルータ設定の複雑さを反映している用語として記述される可能性があります。
Seemingly more intuitive references, which fall outside the vegetable kingdom, refer to cold potato routing as "best exit routing", and hot potato routing as "closest exit routing".
一見野菜王国の外に落ちるより直感的な参照は、「最高の出口ルーティング」、および「最も近い終了ルーティング」としてホットポテトルーティングなどの冷たいポテトルーティングを参照してください。
[RFC4271] allows MEDs received from any EBGP peers by a BGP speaker to be passed to its IBGP peers. Although advertising MEDs to IBGP peers is not a required behavior, it is a common default. MEDs received from EBGP peers by a BGP speaker SHOULD NOT be sent to other EBGP peers.
[RFC4271]はBGPスピーカによって任意EBGPピアから受信した医療検査素子は、そのIBGPピアに渡すことを可能にします。 IBGPピアにのMEDを宣伝することは必須の動作ではありませんが、それは一般的なデフォルトです。 BGPスピーカーによってEBGPピアから受信したのMEDは、他のEBGPピアに送るべきではありません。
Note that many implementations provide a mechanism to derive MED values from IGP metrics to allow BGP MED information to reflect the IGP topologies and metrics of the network when propagating information to adjacent autonomous systems.
多くの実装は、隣接する自律システムに情報を伝播するときBGP MED情報がネットワークのIGPトポロジ及びメトリックを反映できるようにIGPメトリックからMED値を導出するためのメカニズムを提供することに留意されたいです。
[RFC4271] requires an implementation to provide a mechanism that allows MED to be removed. Previously, implementations did not consider a missing MED value the same as a MED of zero. [RFC4271] now requires that no MED value be equal to zero.
[RFC4271]はMEDを除去することを可能にするメカニズムを提供するために実装を必要とします。以前は、実装がゼロのMEDと同じ行方不明MED値を考慮しませんでした。 [RFC4271]は今はMED値がゼロに等しくないことが必要です。
Note that many implementations provide a mechanism to explicitly define a missing MED value as "worst", or less preferable than zero or larger values.
多くの実装が明示的に「最悪の」、またはゼロ以上の値未満で好ましいとして欠落MED値を定義するためのメカニズムを提供することに留意されたいです。
Some implementations have hooks to apply temporal behavior in MED-based best path selection. That is, all things being equal up to MED consideration, preference would be applied to the "oldest" path, without preference for the lower MED value. The reasoning for this is that "older" paths are presumably more stable, and thus preferable. However, temporal behavior in route selection results in non-deterministic behavior, and as such, may often be undesirable.
いくつかの実装では、MED-基づいて、最適なパス選択に時間的挙動を適用するためのフックを持っています。すなわち、MED考慮まで等しい全てのものは、嗜好が低いMED値を優先することなく、「最も古い」パスに適用される、です。このための理由は、「古い」パスは、おそらくより安定し、したがって、好ましいことです。しかし、非決定論的行動における経路選択の結果では、時間的挙動、そのように、多くの場合、望ましくないかもしれません。
The LOCAL_PREF attribute was added to enable a network operator to easily configure a policy that overrides the standard best path determination mechanism without independently configuring local preference policy on each router.
LOCAL_PREF属性は容易に独立して、各ルータのローカル優先のポリシーを設定することなく、標準の最良パス決意機構をオーバーライドするポリシーを設定するために、ネットワークオペレータを可能にするために添加しました。
One shortcoming in the BGP-4 specification was the suggestion that a default value of LOCAL_PREF be assumed if none was provided. Defaults of zero or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL_PREF is a local administration attribute, there is no interoperability drawback across AS boundaries).
BGP-4仕様における1つの欠点は何も提供されなかった場合LOCAL_PREFのデフォルト値が仮定されていることが示唆ました。ゼロのデフォルト値または最大値の各範囲の制限があるので、一般的なデフォルトが同じASにマルチベンダルータの相互運用に役立つであろう（LOCAL_PREFは、局所投与の属性であるので、境界としてまたがって相互運用性の問題点が存在しません）。
[RFC4271] requires that LOCAL_PREF be sent to IBGP Peers and not to EBGP Peers. Although no default value for LOCAL_PREF is defined, the common default value is 100.
[RFC4271]はLOCAL_PREF IBGPピアに送信されると、EBGPピアにはないことが必要です。 LOCAL_PREFにはデフォルト値が定義されていないが、一般的なデフォルト値は100です。
Another area where exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup.
探査が必要とされる別の領域は、発信ASが最良パス選択プロセスに影響を与える可能性ができる方法です。例えば、デュアル接続サイトは、プライマリトランジットサービスプロバイダとしてASいずれかを選択し、バックアップとして1を有することができます。
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider. There is no mechanism to indicate a preference should the third provider wish to respect that preference.
2つのトランジットサービスプロバイダーは第三プロバイダに接続トポロジでは、実際の決定は、第三のプロバイダによって行われます。第三のプロバイダがその嗜好を尊重することを望むべきである好みを指示するメカニズムはありません。
A general purpose suggestion has been the possibility of carrying an optional vector, corresponding to the AS_PATH, where each transit AS may indicate a preference value for a given route. Cooperating autonomous systems may then choose traffic based upon comparison of "interesting" portions of this vector, according to routing policy.
汎用提案は各トランジットASが所与のルートの優先度値を示してもよいAS_PATHに対応する、任意のベクターを保有する可能性でした。協力自律システムは、ルーティングポリシーに基づいて、このベクトルの「面白い」の部分の比較に基づいてトラフィックを選択することができます。
While protecting a given autonomous systems routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols.
与えられた自律システムのルーティングポリシーの保護が最大の関心事でありながら、ルーティングポリシーの大規模な手の設定を回避することは、将来のBGPのようなプロトコルでは、より慎重に検討する必要があります。
While not strictly a protocol issue, another concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS.
厳密には、プロトコルの問題が、別の懸念は、多数のピアとの自律システムを維持するために必要なネットワークオペレータによって提起されてきました。外部ルータとピアリング各スピーカーはそのAS内の他のすべてのトランジットと境界ルータに到達可能とパス情報を伝播する責任があります。これは通常、ローカルAS内のすべてのトランジットと境界ルータへの内部BGP接続を確立することにより行われます。
Note that the number of BGP peers that can be fully meshed depends on a number of factors, including the number of prefixes in the routing system, the number of unique paths, stability of the system, and, perhaps most importantly, implementation efficiency. As a result, although it's difficult to define "a large number of peers", there is always some practical limit.
完全に噛合させることができるBGPピアの数は、ルーティングシステム内のプレフィクスの数、一意のパスの数、システムの安定性、そして、おそらく最も重要なことは、実装効率を含む多くの因子に依存することに留意されたいです。それは、「多数のピア」を定義することは困難ですが、その結果、常にいくつかの実用的な限界があります。
In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated. Therefore, alternatives, such as injecting BGP routing information into the local IGP, have been attempted, but turned out to be non-practical alternatives (to say the least).
大規模なASでは、これは、TCP接続（N *（N-1））と、それらの接続を設定し、維持するためのいくつかの方法のフルメッシュにつながります。 BGPは、この情報を伝播する方法を指定しません。したがって、そのようなローカルIGPにBGPルーティング情報を注入するなどの代替は、試みが、非実用的な代替物であることが判明してきた（控えめに言って）。
To alleviate the need for "full mesh" IBGP, several alternatives have been defined, including BGP Route Reflection [RFC2796] and AS Confederations for BGP [RFC3065].
「フルメッシュ」IBGPの必要性を軽減するために、いくつかの選択肢は、BGP [RFC3065]のためのBGPルートリフレクション[RFC2796]とASコンフェデレーションを含め、定義されています。
As discussed in [RFC4274], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the Internet has grown, the frequency of route changes per second has increased.
[RFC4274]で議論するように、CPUおよび帯域幅利用の駆動力は、インターネットのルーティングの動的な性質です。インターネットが成長してきたように、第二あたりのルート変更の頻度が増加しています。
We automatically get some level of damping when more specific NLRI is aggregated into larger blocks; however, this is not sufficient. In Appendix F of [RFC4271], there are descriptions of damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations.
我々は、より具体的なNLRIを大きなブロックに集約されたときに、減衰のいくつかのレベルを自動的に取得します。しかし、これは十分ではありません。 [RFC4271]の付録Fに、広告に適用すべき減衰技術の記述があります。 BGP-ようなプロトコルの将来の仕様では、減衰方法は、対応する実装に必須の包含のために考慮されるべきです。
BGP Route Flap Damping is defined in [RFC2439]. BGP Route Flap Damping defines a mechanism to help reduce the amount of routing information passed between BGP peers, which reduces the load on these peers without adversely affecting route convergence time for relatively stable routes.
BGPルートフラップダンピングは[RFC2439]で定義されています。 BGPルートフラップ減衰に悪影響が比較的安定したルートのルート収束時間に影響を与えることなく、これらのピアの負荷を低減するBGPピアとの間で渡される情報を、ルーティングの量を減らすためのメカニズムを定義します。
None of the current implementations of BGP Route Flap Damping store route history by unique NRLI or AS Path, although RFC 2439 lists this as mandatory. A potential result of failure to consider each AS Path separately is an overly aggressive suppression of destinations in a densely meshed network, with the most severe consequence being suppression of a destination after a single failure. Because the top tier autonomous systems in the Internet are densely meshed, these adverse consequences are observed.
ユニークNRLIによって、またはパスとして、RFC 2439本のリストこのとして必須であるがBGPルートフラップダンピングストアの経路履歴の現在の実装のなし。パスとして、それぞれを検討するために、障害の潜在的な結果は、別途最も深刻な結果は、単一の障害が発生した後、宛先の抑制された状態で密メッシュネットワーク内の目的地、の過度に積極的な抑制です。インターネットでトップティアの自律システムが密に噛み合っているので、これらの有害な影響が観察されています。
Route changes are announced using BGP UPDATE messages. The greatest overhead in advertising UPDATE messages happens whenever route changes to be announced are inefficiently packed. Announcing routing changes that share common attributes in a single BGP UPDATE message helps save considerable bandwidth and reduces processing overhead, as discussed in Section 12, Update Packing.
ルート変更は、BGPのUPDATEメッセージを使用して発表しています。ルート変更が非効率的にパックされて発表されるたび広告UPDATEメッセージの中で最大のオーバーヘッドが発生します。単一BGP UPDATEメッセージに共通の属性を共有するルーティングの変更を発表することは、かなりの帯域幅を節約し、第12項で説明したように、処理のオーバーヘッドが減少し、パッキングを更新できます。
Persistent BGP errors may cause BGP peers to flap persistently if peer dampening is not implemented, resulting in significant CPU utilization. Implementors may find it useful to implement peer dampening to avoid such persistent peer flapping [RFC4271].
永続的なBGPエラーが重大なCPU使用率で、その結果、ピア減衰が実装されていない場合は、BGPピアが持続的にフラップすることがあります。実装者は、それが便利な永続ピアの羽ばたき[RFC4271]を避けるために、ピア減衰を実装するかもしれません。
[RFC4271] states "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document".
[RFC4271]「は、ローカルBGPスピーカのフォワーディングテーブルに追加されることなくのAdj-RIB-Outに追加されたルートをもたらす任意のローカルポリシーは、この文書の範囲外である」と述べ。
However, several well-known implementations do not confirm that Loc-RIB entries were used to populate the forwarding table before installing them in the Adj-RIB-Out. The most common occurrence of this is when routes for a given prefix are presented by more than one protocol, and the preferences for the BGP-learned route is lower than that of another protocol. As such, the route learned via the other protocol is used to populate the forwarding table.
しかし、いくつかのよく知られた実装はのLoc-RIBのエントリが調整]-RIBアウトでそれらをインストールする前に、転送テーブルを移入するために使用されたことを確認していません。与えられたプレフィックスのルートが複数のプロトコルによって提示、およびBGP学習ルートの嗜好が他のプロトコルよりも低いされている場合、この最も一般的な発生があります。このように、他のプロトコルを介して学習した経路は、転送テーブルをポピュレートするために使用されます。
It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes.
実装が「非アクティブ」BGPルートの広告を許可するノブを提供することが望ましい場合があります。
It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected in the decision process.
実装が決定プロセスにおいて選択されなかったBGPルートをアドバタイズするBGPスピーカを可能にするノブを提供することも望ましいかもしれません。
Multiple unfeasible routes can be advertised in a single BGP Update message. In addition, one or more feasible routes can be advertised in a single Update message, as long as all prefixes share a common attribute set.
複数不可能ルートが単一のBGPアップデートメッセージでアドバタイズすることができます。また、一つ以上の実行可能なルートがある限り、すべてのプレフィックスが設定され、共通の属性を共有するように、単一の更新メッセージでアドバタイズすることができます。
The BGP4 protocol permits advertisement of multiple prefixes with a common set of path attributes in a single update message, which is commonly referred to as "update packing". When possible, update packing is recommended, as it provides a mechanism for more efficient behavior in a number of areas, including:
パスの共通セットは、一般に「更新パッキング」と呼ばれる単一の更新メッセージの属性とBGP4プロトコルは、複数のプレフィックスの広告を可能にします。可能な場合、それは含めて、多くの分野で、より効率的に行動するためのメカニズムを提供して、更新パックは、お勧めします。
o Reduction in system overhead due to generation or receipt of fewer Update messages.
世代またはそれ以下の更新メッセージを受信したことに起因するシステムオーバーヘッドのO削減。
o Reduction in network overhead as a result of less packets and lower bandwidth consumption.
以下、パケットと低帯域幅の消費の結果としてネットワークオーバーヘッドのO削減。
o Reduction in frequency of processing path attributes and looking for matching sets in the AS_PATH database (if you have one). Consistent ordering of the path attributes allows for ease of matching in the database, as different representations of the same data do not exist.
（使用している場合）の処理経路の周波数におけるOの削減は、属性とAS_PATHデータベースのセットを一致させるために探して。同じデータの異なる表現が存在しないように、パス属性の一貫した順序付けは、データベース内のマッチングを容易にします。
The BGP protocol suggests that withdrawal information should be packed in the beginning of an Update message, followed by information about reachable routes in a single UPDATE message. This helps alleviate excessive route flapping in BGP.
BGPプロトコルは、離脱情報が単一のUPDATEメッセージで到達可能なルートに関する情報、続いてUpdateメッセージの先頭に充填されるべきであることを示唆しています。これは、BGPでフラッピング過度のルートを軽減するのに役立ちます。
The BGP protocol defines different mechanisms to rate limit Update advertisement. The BGP protocol defines a MinRouteAdvertisementInterval parameter that determines the minimum time that must elapse between the advertisement of routes to a particular destination from a single BGP speaker. This value is set on a per-BGP-peer basis.
BGPプロトコルは、レートリミット更新広告に異なる機構を定義しています。 BGPプロトコルは、単一のBGPスピーカから特定の宛先へのルートの広告の間に経過しなければならない最小時間を決定MinRouteAdvertisementIntervalパラメータを定義します。この値は、あたり-BGPピアに基づいて設定されます。
Because BGP relies on TCP as the Transport protocol, TCP can prevent transmission of data due to empty windows. As a result, multiple updates may be spaced closer together than was originally queued. Although it is not common, implementations should be aware of this occurrence.
BGPは、トランスポートプロトコルとしてTCPに依存しているため、TCPが原因空のウィンドウにデータの送信を防ぐことができます。その結果、複数の更新は、元々キューに入れられたよりも互いに接近して離間されてもよいです。それは一般的ではありませんが、実装は、この発生に注意する必要があります。
If either a TCP receiver is processing input more slowly than the sender, or if the TCP connection rate is the limiting factor, a form of backpressure is observed by the TCP sending application. When the TCP buffer fills, the sending application will either block on the write or receive an error on the write. In early implementations or naive new implementations, setting options to block on the write or setting options for non-blocking writes are common errors. Such implementations treat full buffer related errors as fatal.
TCP受信機のいずれかが入力よりもゆっくり送信者を処理している場合TCP接続速度が制限要因である場合、又は、背圧の形態は、TCP送信側アプリケーションによって観察されます。 TCPバッファがいっぱいになると、送信側アプリケーションは、いずれかの書き込みにブロックまたは書き込み時にエラーが発生します。初期の実装やナイーブ新しい実装では、書き込みをブロックするオプションを設定または非ブロッキング書き込みのためのオプションを設定する一般的なエラーです。このような実装は致命的として、フルバッファ関連のエラーを処理します。
Having recognized that full write buffers are to be expected, additional implementation pitfalls exist. The application should not attempt to store the TCP stream within the application itself. If the receiver or the TCP connection is persistently slow, then the buffer can grow until memory is exhausted. A BGP implementation is required to send changes to all peers for which the TCP connection is not blocked, and is required to send those changes to the remaining peers when the connection becomes unblocked.
完全な書き込みバッファが予想されることを認識したので、追加の実装の落とし穴が存在します。アプリケーションは、アプリケーション自体の中にTCPストリームを保存するために試みるべきではありません。受信機またはTCP接続が永続的に遅い場合は、メモリが使い果たされるまで、バッファが成長することができます。 BGP実装は、TCP接続が遮断されていないすべてのピアに変更を送信する必要がある、との接続がブロックされていないとなった場合、残りのピアにそれらの変更を送信する必要があります。
If the preferred route for a given NLRI changes multiple times while writes to one or more peers are blocked, only the most recent best route needs to be sent. In this way, BGP is work conserving [RFC4274]. In cases of extremely high route change, a higher volume of route change is sent to those peers that are able to process it more quickly; a lower volume of route change is sent to those peers that are not able to process the changes as quickly.
与えられたNLRIのための好ましい経路が複数回変更した場合一の以上のピアへの書き込みがブロックされている一方で、唯一の最も最近の最適なルートを送信する必要があります。このように、BGPは、[RFC4274]を節約作品です。極めて高い経路変更の場合には、経路変更のより高い体積は、より迅速に処理することができるこれらのピアに送信されます。経路変更の低いボリュームが早く変更を処理することができないこれらのピアに送信されます。
For implementations that handle differing peer capacities to absorb route change well, if the majority of route change is contributed by a subset of unstable NRLI, the only impact on relatively stable NRLI that makes an isolated route change is a slower convergence, for which convergence time remains bounded, regardless of the amount of instability.
経路変更の大部分が不安定NRLIのサブセットによって寄与された場合、井戸経路変更を吸収するために、ピアの能力の異なるハンドルを実装するために、単離された経路変更を行う比較的安定NRLIにのみ影響が収束時間より遅い収束は、ありますかかわらず、不安定性の量の、有界のまま。
The BGP protocol suggests that BGP speakers sending multiple prefixes per an UPDATE message sort and order path attributes according to Type Codes. This would help their peers quickly identify sets of attributes from different update messages that are semantically different.
BGPプロトコルは、コードの種類に応じてBGPスピーカは、UPDATEメッセージごとに複数のプレフィックスを送信ソートし、順序パス属性ことを示唆しています。これは彼らの仲間はすぐに意味的に異なっている別の更新メッセージから属性のセットを識別するのに役立ちます。
Implementers may find it useful to order path attributes according to Type Code, such that sets of attributes with identical semantics can be more quickly identified.
実装者は、それが役に立つのパスが同じセマンティクスを持つ属性の集合は、より迅速に識別することができるようなタイプコード、属性に応じて注文するかもしれません。
AS_SETs are commonly used in BGP route aggregation. They reduce the size of AS_PATH information by listing AS numbers only once, regardless of the number of times it might appear in the process of aggregation. AS_SETs are usually sorted in increasing order to facilitate efficient lookups of AS numbers within them. This optimization is optional.
AS_SETsは、一般的にBGPルート集約に使用されています。彼らは関係なく、それが集約の過程で表示されることがあります回数、一回だけAS番号を一覧表示することでAS_PATH情報のサイズを小さくします。 AS_SETsは通常、その中にAS番号の効率的な検索を容易にするための増加にソートされています。この最適化はオプションです。
Because pre-BGP-4 route aggregation can't be supported by earlier versions of BGP, an implementation that supports versions in addition to BGP-4 should provide the version support on a per-peer basis. At the time of this writing, all BGP speakers on the Internet are thought to be running BGP version 4.
プレBGP-4経路集約はBGP、ピアごとにバージョンのサポートを提供するべきであるBGP-4に加えて、バージョンをサポートする実装の以前のバージョンによってサポートすることができないからです。この記事の執筆時点では、インターネット上のすべてのBGPスピーカは、BGPバージョン4を実行していると考えられています。
BGP provides a flexible and extendable mechanism for authentication and security. The mechanism allows support for schemes with various degrees of complexity. BGP sessions are authenticated based on the IP address of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer.
BGPは、認証およびセキュリティのための柔軟かつ拡張可能なメカニズムを提供します。機構が複雑種々の程度と方式のサポートを可能にします。 BGPセッションは、ピアのIPアドレスに基づいて認証されます。加えて、すべてのBGPセッションは、ピアによってアドバタイズ自律システム番号に基づいて認証されます。
Because BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP.
BGPはTCPとIP上で動作するので、BGPの認証方式は、TCPやIPのいずれかにより提供される任意の認証やセキュリティメカニズムによって拡張することができます。
[RFC2385] defines a way in which the TCP MD5 signature option can be used to validate information transmitted between two peers. This method prevents a third party from injecting information (e.g., a TCP Reset) into the datastream, or modifying the routing information carried between two BGP peers.
[RFC2385]はTCP MD5署名オプションは、2つのピア間で送信された情報を検証するために使用することができる方法を定義します。この方法は、2つのBGPピア間で運ばルーティング情報をデータストリームに情報（例えば、TCPリセット）を注入、または変更から第三者を防止します。
At the moment, TCP MD5 is not ubiquitously deployed, especially in inter-domain scenarios, largely because of key distribution issues. Most key distribution mechanisms are considered to be too "heavy" at this point.
現時点では、TCP MD5は普遍的に主な理由の鍵配布の問題の、特にドメイン間のシナリオでは、デプロイされていません。ほとんどのキー配布メカニズムは、この時点では、あまりにも「重い」と考えられています。
Many have naively assumed that an attacker must correctly guess the exact TCP sequence number (along with the source and destination ports and IP addresses) to inject a data segment or reset a TCP transport connection between two BGP peers. However, recent observation and open discussion show that the malicious data only needs to fall within the TCP receive window, which may be quite large, thereby significantly lowering the complexity of such an attack.
多くは、単純に攻撃者が正しくデータセグメントを注入するか、2つのBGPピア間のTCPトランスポート接続をリセットする（送信元ポートと宛先ポート及びIPアドレスとともに）正確なTCPシーケンス番号を推測しなければならないと仮定しています。しかし、近年の観測や悪質なデータのみをTCP内に入ることが必要であることをオープンな議論のショーが大幅ような攻撃の複雑さを低減する、非常に大きくなる可能性がある、ウィンドウを受け取ります。
As such, it is recommended that the MD5 TCP Signature Option be employed to protect BGP from session resets and malicious data injection.
このように、MD5 TCP署名オプションは、セッションがリセットされ、悪意のあるデータのインジェクションからBGPを保護するために使用することをお勧めします。
BGP can run over IPsec, either in a tunnel or in transport mode, where the TCP portion of the IP packet is encrypted. This not only prevents random insertion of information into the data stream between two BGP peers, but also prevents an attacker from learning the data being exchanged between the peers.
BGPは、トンネル内やIPパケットのTCP部分が暗号化されているトランスポートモード、のいずれかで、IPsecの上で実行することができます。これは、2つのBGPピア間のデータストリームに情報のランダムな挿入を防止するだけでなく、ピア間で交換されるデータを学習から攻撃を防ぐだけではなく。
However, IPsec does offer several options for exchanging session keys, which may be useful on inter-domain configurations. These options are being explored in many deployments, although no definitive solution has been reached on the issue of key exchange for BGP in IPsec.
しかし、IPsecは、ドメイン間の構成上有用である可能性があるセッション鍵を交換するためのいくつかのオプションを提供しません。決定的な解決策は、IPsecの中にBGPのための鍵交換の問題に到達していないが、これらのオプションは、多くの展開で検討されています。
Because BGP runs over TCP and IP, it should be noted that BGP is vulnerable to the same denial of service and authentication attacks that are present in any TCP based protocol.
BGPはTCPとIP上で動作するので、BGPが任意のTCPベースのプロトコルに存在しているサービスとの認証攻撃の同じ拒否に対して脆弱であることに留意すべきです。
Another routing protocol issue is providing evidence of the validity and authority of routing information carried within the routing system. This is currently the focus of several efforts, including efforts to define threats that can be used against this routing information in BGP [BGPATTACK], and efforts to develop a means of providing validation and authority for routing information carried within BGP [SBGP] [soBGP].
別のルーティングプロトコルの問題は、ルーティングシステム内の情報をルーティングの有効性と権威の証拠を提供しています。これは、現在BGP [BGPATTACK】このルーティング情報に対して使用することができる脅威を定義するための努力、およびBGP [SBGP] [soBGP内で運ばルーティング情報の検証と権限を提供する手段を開発する努力を含むいくつかの努力の焦点であります]。
In addition, the Routing Protocol Security Requirements (RPSEC) working group has been chartered, within the Routing Area of the IETF, to discuss and assist in addressing issues surrounding routing protocol security. Within RPSEC, this work is intended to result in feedback to BGP4 and future protocol enhancements.
また、ルーティングプロトコルのセキュリティ要件（RPSEC）ワーキンググループは、議論し、ルーティングプロトコルのセキュリティを取り巻く問題に対処を支援するために、IETFのルーティングエリア内、チャーターされました。 RPSECの中で、この作品は、BGP4へのフィードバックと今後のプロトコルの強化につながることを意図しています。
The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security, and VPN infrastructures.
最近、グローバルルーティングオペレーション（GROW）ワーキンググループによって置き換えプレフィックス分類（PTOMAINE）ワーキンググループは、検討し、ルーティングテーブルの成長の問題、内部と外部のルーティングプロトコル間の相互作用の効果、および効果を測定するためにチャーターされますグローバルルーティングシステム上のアドレスの割り当て方針や慣行の。最後に、適切な場合には、GROWも測定、ポリシー、セキュリティ、およびVPNインフラの運用面を文書化します。
GROW is currently studying the effects of route aggregation, and also the inability to aggregate over multiple provider boundaries due to inadequate provider coordination.
GROW現在ルート集約し、また不適切なプロバイダ連携による複数のプロバイダの境界を超える集約することができないの効果を検討しています。
Within GROW, this work is intended to result in feedback to BGPv4 and future protocol enhancements.
GROWの中で、この作品はBGPv4へのフィードバックと今後のプロトコルの強化につながることを意図しています。
Many organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry. These databases provide access to information using the RPSL language, as defined in [RFC2622]. While registered information may be maintained and correct for certain providers, the lack of timely or correct data in the various IRR databases has prevented wide spread use of this resource.
多くの組織では、インターネットルーティングレジストリの様々な分散データベースで自分のルーティングポリシーとプレフィックス発信を登録します。 [RFC2622]で定義されているこれらのデータベースは、RPSL言語を使用して情報へのアクセスを提供します。登録された情報は、特定のプロバイダのために維持し、正しいこともできるが、様々なIRRデータベースでタイムリーや正しいデータの欠如は、このリソースの普及の使用を妨げてきました。
The NSFNET program used EGP, and then BGP, to provide external routing information. It was the NSF policy of offering different prices and providing different levels of support to the Research and Education (RE) and the Commercial (CO) networks that led to BGP's initial policy requirements. In addition to being charged more, CO networks were not able to use the NSFNET backbone to reach other CO networks. The rationale for higher prices was that commercial users of the NSFNET within the business and research entities should subsidize the RE community. Recognition that the Internet was evolving away from a hierarchical network to a mesh of peers led to changes away from EGP and BGP-1 that eliminated any assumptions of hierarchy.
NSFNETプログラムは、外部のルーティング情報を提供するために、BGP次いで、EGPを使用し、。これは、異なる価格を提供し、研究と教育（RE）とBGPの初期ポリシー要件につながったコマーシャル（CO）ネットワークにさまざまなレベルのサポートを提供するのNSFの方針でした。以上充電されることに加えて、COネットワークは、他のCOのネットワークに到達するためにNSFNETバックボーンを使用することができませんでした。高い値段のための理論的根拠は、ビジネスや研究のエンティティ内のNSFNETの商用ユーザーはREコミュニティ助成金を支給すべきであるということでした。インターネットは、ピアのメッシュに離れた階層型ネットワークから進化したという認識は、階層のいずれかの仮定を排除離れEGPとBGP-1からの変更につながりました。
Enforcement of NSF policy was accomplished through maintenance of the NSF Policy Routing Database (PRDB). The PRDB not only contained each networks designation as CO or RE, but also contained a list of the preferred exit points to the NSFNET to reach each network. This was the basis for setting what would later be called BGP LOCAL_PREF on the NSFNET. Tools provided with the PRDB generated complete router configurations for the NSFNET.
NSFのポリシーの施行は、NSFポリシールーティングデータベース（PRDB）のメンテナンスを通じて達成されました。 PRDBはCOまたはREなどの各ネットワークの指定を含んでいただけでなく、各ネットワークに到達するためにNSFNETに好適出口ポイントのリストが含まれていないだけ。これは後でNSFNET上のBGP LOCAL_PREFと呼ばれるもの設定するための基礎となりました。 PRDBで提供されるツールは、NSFNETのための完全なルータの設定を生成しました。
Use of the PRDB had the fortunate consequence of greatly improving reliability of the NSFNET, relative to peer networks of the time. PRDB offered more optimal routing for those networks that were sufficiently knowledgeable and willing to keep their entries current.
PRDBの使用は、時間のネットワークをピアに比べ大幅にNSFNETの信頼性を向上させることの幸運な結果を、持っていました。 PRDBは、現在の自分のエントリを維持するのに十分な知識と喜んでいたこれらのネットワークのためのより最適なルーティングを提供しました。
With the decommission of the NSFNET Backbone Network Service in 1995, it was recognized that the PRDB should be made less single provider centric, and its legacy contents, plus any further updates, should be made available to any provider willing to make use of it. The European networking community had long seen the PRDB as too US-centric. Through Reseaux IP Europeens (RIPE), the Europeans created an open format in RIPE-181 and maintained an open database used for address and AS registry more than policy. The initial conversion of the PRDB was to RIPE-181 format, and tools were converted to make use of this format. The collection of databases was termed the Internet Routing Registry (IRR), with the RIPE database and US NSF-funded Routing Arbitrator (RA) being the initial components of the IRR.
1995年にNSFNETバックボーンネットワークサービスの運用停止と、それはPRDBが少なく、単一のプロバイダを中心になされるべきであることを認識し、そのレガシー内容に加え、任意の更なるアップデートは、それを利用するために喜んで任意のプロバイダーに利用できるようにすべきです。欧州のネットワーキングコミュニティは長く、あまりにも米国を中心としてPRDBを見ていました。 Reseaux IP Europeens（RIPE）を介して、ヨーロッパ人はRIPE-181にオープンフォーマットを作成し、アドレスおよびポリシーよりレジストリとして使用オープンデータベースを維持します。 PRDBの最初の変換は、RIPE-181形式にした、およびツールは、このフォーマットを使用するように変換しました。データベースの集合は、RIPEデータベースと米国NSFの資金によるルーティング仲裁（RA）IRRの初期成分であるとともに、インターネットルーティングレジストリ（IRR）と名付けました。
A need to extend RIPE-181 was recognized and RIPE agreed to allow the extensions to be defined within the IETF in the RPS WG, resulting in the RPSL language. Other work products of the RPS WG provided an authentication framework and a means to widely distribute the database in a controlled manner and synchronize the many repositories. Freely available tools were provided, primarily by RIPE, Merit, and ISI, the most comprehensive set from ISI. The efforts of the IRR participants has been severely hampered by providers unwilling to keep information in the IRR up to date. The larger of these providers have been vocal, claiming that the database entry, simple as it may be, is an administrative burden, and some acknowledge that doing so provides an advantage to competitors that use the IRR. The result has been an erosion of the usefulness of the IRR and an increase in vulnerability of the Internet to routing based attacks or accidental injection of faulty routing information.
RIPE-181を拡張する必要性が認識され、RIPEはRPSL言語で得られた、拡張がRPS WGにおけるIETF内で定義されることを可能にすることに合意しました。 RPS WGの他の作業成果物は、認証フレームワークと広く制御された方法で分散データベース、多くのリポジトリを同期させるための手段を提供しました。自由に利用できるツールは主に、RIPE、メリット、およびISI、ISIから最も包括的なセットにより、提供されました。 IRR参加者の努力は厳しく最新のIRRの情報を保つために不本意プロバイダによって妨げられてきました。これらのプロバイダの大きい方は、それがされるように、単純なデータベースエントリは、管理上の負担であることを主張し、ボーカルとなっている、といくつかは、やってはとてもIRRを使用し、競合他社への優位性を提供することを認めます。結果は、IRRの有用性とルーティングベースの攻撃や障害のあるルーティング情報を誤って注射に対するインターネットの脆弱性の増加の浸食されています。
There have been a number of cases in which accidental disruption of Internet routing was avoided by providers using the IRR, but this was highly detrimental to non-users. Filters have been forced to provide less complete coverage because of the erosion of the IRR; these types of disruptions continue to occur infrequently, but have an increasingly widespread impact.
インターネットルーティングの偶然の破壊はIRRを使用してプロバイダによって回避するが、これは非利用者に非常に有害だったされた例数がありました。フィルタは理由IRRの浸食の少ない完全なカバレッジを提供することを余儀なくされています。混乱のこれらのタイプは、まれにしか発生し続けるが、ますます広範な影響を持っています。
We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document and providing valuable input on this update. We would also like to acknowledge Curtis Villamizar for providing both text and thorough reviews. Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich, and Jude Ballard for supplying their usual keen eyes.
私たちは、この文書の以前のバージョンをオーサリングし、このアップデートの貴重な入力を提供するためのポールTrainaのとヤコフ・レックターに感謝したいと思います。また、テキストと徹底レビューの両方を提供するためのカーティスVillamizarを確認したいと思います。彼らのいつもの鋭い目を供給するためのラスホワイト、ジェフリーハース、ショーンMentzer、ミッチェルErblich、およびジュードバラードに感謝します。
Finally, we'd like to think the IDR WG for general and specific input that contributed to this document.
最後に、私たちは、この文書に貢献した一般的および特定の入力のためのIDR WGと思うしたいと思います。
[RFC1966] Bates, T. and R. Chandra, "BGP Route Reflection An alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC1966]ベイツ、T.、およびR.チャンドラ、 "BGPルートリフレクションフルメッシュIBGPへの代替"、RFC 1966、1996年6月。
[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月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、チャンドラ、R.、およびR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796]ベイツ、T.、チャンドラ、R.、およびE.チェン、 "BGPルートリフレクション - フルメッシュIBGPへの代替"、RFC 2796、2000年4月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065] Trainaの、P.、マクファーソン、D.、およびJ.スカダー、 "BGPのための自律システム同盟"、RFC 3065、2001年2月。
[RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC 4274, January 2006.
[RFC4274]マイヤー、D.及びK.パテル、 "BGP-4プロトコル分析"、RFC 4274、2006年1月。
[RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report", RFC 4276, January 2006.
[RFC4276]ノウサギ、S.およびA. Retana、 "BGP 4実施報告書"、RFC 4276、2006年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC1657] Willis, S., Burruss, J., Chu, J., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994.
[RFC1657]ウィリス、S.、Burruss、J.、チュー、J.、RFC 1657、1994年7月 "SMIv2のを使用してボーダーゲートウェイプロトコル（BGP-4）第4版のための管理オブジェクトの定義"。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[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 Engineering Task Force 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月。
[RFC1269] Willis, S. and J. Burruss, "Definitions of Managed Objects for the Border Gateway Protocol: Version 3", RFC 1269, October 1991.
[RFC1269]ウィリス、S.とJ. Burruss、 "ボーダーゲートウェイプロトコルのための管理対象オブジェクトの定義：バージョン3"、RFC 1269、1991年10月。
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, July 1994.
[RFC1656] Trainaの、P.、 "BGP-4プロトコルドキュメントのロードマップと実装経験"、RFC 1656、1994年7月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995.
[RFC1773] Trainaの、P.、RFC 1773、1995年3月 "BGP-4プロトコルの経験"。
[RFC1965] Traina, P., "Autonomous System Confederations for BGP", RFC 1965, June 1996.
[RFC1965] Trainaの、P.、 "BGPのための自律システムコンフェデレーション"、RFC 1965、1996年6月。
[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月。
[BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway Protocol", Work in Progress.
[BGPATTACK] Convery、C.、「ボーダーゲートウェイプロトコルのための攻撃の木」が進行中で働いています。
[SBGP] "Secure BGP", Work in Progress.
[SBGP]進行中の作業、 "BGPセキュア"。
[soBGP] "Secure Origin BGP", Work in Progress.
[soBGP]、進行中の作業 "起源BGPを固定します"。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks
ダニー・マクファーソンアーバーネットワークス
EMail: danny@arbor.net
メールアドレス：danny@arbor.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）によって提供されます。