[要約] 要約：RFC 4277は、BGP-4プロトコルの実装と運用に関する経験を共有するためのドキュメントです。 目的：BGP-4プロトコルの利用者や開発者に対して、実装上の問題やベストプラクティスに関する知識を提供することを目的としています。
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
BGP-4プロトコルの経験
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The purpose of this 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).
このメモの目的は、インターネットドラフト標準としてのルーティングプロトコルの公開要件が、Border Gateway Protocolバージョン4（BGP-4）によってどのように満たされているかを文書化することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 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で説明されているように、「2番目のレポート」の要件を満たしています。要件を満たすために、このレポートは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).
このメモの目的は、インターネットドラフト標準としてのルーティングプロトコルの公開要件が、Border Gateway Protocolバージョン4（BGP-4）によってどのように満たされているかを文書化することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [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で説明されているように、「2番目のレポート」の要件を満たしています。要件を満たすために、このレポートは[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システムとネットワークリーチ性情報を交換することです。このネットワークリーチビリティ情報には、到達可能性情報が横断する自律システム（ASE）のリストに関する情報が含まれています。この情報は、この到達可能性の接続性のグラフを構築するのに十分であり、ルーティングループが剪定される可能性があり、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]で定義されています。[RFC4271]の付録A、B、C、およびDは、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 MIBはBGPピアテーブルとBGP受信パス属性テーブルの2つのテーブルに分割されます。
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].
Ciscoの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-4は1993年から使用されています。BGPの生産使用には、プロトコルのすべての重要な機能の利用が含まれます。現在の生産環境では、BGPが自律システム間ルーティングプロトコルとして使用されているため、非常に不均一です。リンク帯域幅の点では、56 kbpsから10 gbpsまで変化します。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によって運ばれる外部ルートの完全なセットは、170,000を超える総合的なエントリであり、その数の接続されたネットワークの数倍を表しています。一部のサービスプロバイダーコアルーターのアクティブパスの数は250万を超えています。パスの長さとしてのネイティブは、一部のルートでは10個の長さであり、25個以上の自律システムの「パッド入り」パス長が存在します。
BGP employs TCP [RFC793] as it's Transport Layer protocol. As such, all characteristics inherent to TCP are inherited by BGP.
BGPは、輸送層プロトコルとしてTCP [RFC793]を採用しています。そのため、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の個別のメトリックパラメーターがあります。これにより、ポリシーベースのメトリックが距離ベースのメトリックを上書きすることができます。これにより、各自律システムは、Inter-ASおよびASで独立したポリシーを定義できます。BGPマルチエグジット識別子（MED）はEBGPピア（つまり、ドメイン間）によってメトリックとして使用されますが、ローカル嗜好（local_pref）はIBGPピア（つまり、ドメイン内）で使用されます。
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は、古いASメトリックをmulti_exit_disc（med）として再定義しました。この値は、特定のアドレススペースへの優先パスを選択するときにタイブレークプロセスで使用でき、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は、同じように異なる外部ピアから受信したパスを比較するときにのみ使用されることを意図していましたが、多くの実装は、異なる自律システム間で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.
これは一部の構成にとっては素晴らしいアイデアのように思えるかもしれませんが、異なる自律システムの薬を比較する場合は注意が必要です。BGPスピーカーは、多くの場合、ローカルAS内の特定のBGP Next_hopに到達することに関連するIGPメトリックを取得することにより、MED値を導き出します。これにより、MEDはピアへのルートを広告するときにIGPトポロジを合理的に反映できます。これは、隣接する単一のASから学んだ複数の経路のMEDを比較する場合は問題ありませんが、異なる自律システムのMEDを比較すると、潜在的に悪い決定をもたらす可能性があります。これは、自律システムが異なるメカニズムを使用してIGPメトリック、BGP MEDを導き出すか、おそらく膨大な対照的なメトリック空間を備えた異なる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展開考慮事項には、MEDに対するBGPルーティング情報の集約の影響が含まれます。集合体は、安定性、冗長性、およびその他のネットワーク設計目標に対応するために、複数の場所から生成されることがよくあります。MEDが上記の凝集体に関連付けられた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.
トラフィックが一対の目的地の間を流れる場合、それぞれが2つのトランジットネットワークに接続されています。各トランジットネットワークは、他のトランジットプロバイダーに最も近いピアリングにトラフィックを送信するか、他のプロバイダーを通じて最小コストを宣伝するピアリングにトラフィックを渡すという選択があります。前者の方法は「ホットポテトルーティング」と呼ばれます。なぜなら、素手の手で抱いているホットポテトのように、それをすぐに取り除こうとする人は誰でも。ホットポテトルーティングは、EBGP学習の薬をIBGPに渡さないことで達成されます。これにより、トラフィックをルーティングするプロバイダーのトランジットトラフィックが最小化されます。それほど一般的ではない「コールドポテトルーティング」は、トランジットプロバイダーが独自の輸送容量を使用して、隣接するトランジットプロバイダーのトラフィックを目的地に最も近いと宣伝しています。コールドポテトルーティングは、EBGP学習の薬をIBGPに渡すことによって達成されます。
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つのトランジットプロバイダーがホットポテトルーティングを使用し、別のトランジットプロバイダーがコールドポテトルーティングを使用している場合、2つの間のトラフィックは対称的である傾向があります。ビジネス関係に応じて、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ピアから受け取ったMEDをIBGPピアに渡すことを許可します。IBGPピアへの広告医療は必要な動作ではありませんが、一般的なデフォルトです。BGPスピーカーによってEBGPピアから受け取った薬は、他の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.
多くの実装は、IGPメトリックからMED値を導き出すメカニズムを提供し、BGP MED情報が隣接する自律システムに情報を伝播する際にネットワークのIGPトポロジとメトリックを反映できるようにすることに注意してください。
[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.
ローカル_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のデフォルト値が提供されていない場合に想定されるという提案でした。デフォルトのゼロまたはそれぞれの最大値には範囲の制限があるため、共通のデフォルトは、同じものと同じマルチベンダールーターの相互操作に役立ちます（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をEBGPピアではなくIBGPピアに送信する必要があります。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.
探索が必要なもう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つのトランジットサービスプロバイダーが3番目のプロバイダーに接続するトポロジでは、実際の決定は3番目のプロバイダーによって実行されます。3番目のプロバイダーがその好みを尊重したい場合、好みを示すメカニズムはありません。
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_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のすべてのトランジットおよびボーダールーターへの内部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は、この情報を伝播する方法を指定していません。したがって、BGPルーティング情報をローカルIGPに注入するなどの代替案は試みられていますが、非実用的な代替品であることが判明しました（控えめに言っても）。
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ルートリフレクション[RFC2796]やBGP [RFC3065]のコンフェデーションなど、いくつかの選択肢が定義されています。
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.
RFC 2439はこれを必須であるとリストしていますが、BGPルートフラップダンピングストアルート履歴の現在の実装は一意のNRLIまたはパスとしての履歴のいずれもありません。それぞれを個別に考慮しなかったことの潜在的な結果は、密にメッシュ化されたネットワーク内の目的地の過度に攻撃的な抑制であり、最も深刻な結果は、単一の障害後の目的地の抑制です。インターネット内の最上位層の自律システムは密集しているため、これらの悪影響が観察されます。
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更新メッセージを使用して発表されます。広告更新メッセージの最大のオーバーヘッドは、発表されるルートの変更が非効率的にパックされるたびに発生します。単一のBGPアップデートメッセージで共通属性を共有するルーティングの変更を発表すると、セクション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エラーにより、ピアダンプニングが実装されていない場合、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エントリがadj-rib-outにインストールする前に転送テーブルを設置するために使用されたことを確認していません。これの最も一般的な発生は、特定のプレフィックスのルートが複数のプロトコルによって提示される場合であり、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アップデートメッセージで、複数の実行不可能なルートを宣伝できます。さらに、すべてのプレフィックスが共通属性セットを共有している限り、1つ以上の実行可能なルートを単一の更新メッセージで宣伝できます。
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 PATH属性の頻度の削減と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プロトコルは、更新メッセージの先頭に引き出し情報が詰め込まれ、その後に単一の更新メッセージに到達可能なルートに関する情報が含まれるべきであることを示唆しています。これにより、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スピーカーから特定の宛先へのルートの広告間で経過しなければならない最小時間を決定するMinrouteadisementementIntervalパラメーターを定義します。この値は、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接続が持続的に遅い場合、メモリが使い果たされるまでバッファーが成長する可能性があります。TCP接続がブロックされていないすべてのピアに変更を送信するには、BGPの実装が必要であり、接続がブロックされていないときにそれらの変更を残りのピアに送信するために必要です。
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の優先ルートが1つ以上のピアに書き込み中に複数回変更されている場合、最新の最高のルートのみを送信する必要があります。このように、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スピーカーが更新メッセージソートとタイプコードに従ってパス属性を並べ替えて複数のプレフィックスを送信することを示唆しています。これは、彼らの仲間が、意味的に異なるさまざまな更新メッセージから属性のセットを迅速に識別するのに役立ちます。
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ルート集約で一般的に使用されます。それらは、集約のプロセスに表示される可能性のある回数に関係なく、1回だけ数字としてリストすることにより、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.
Pre-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つのピア間で送信される情報を検証する方法を定義します。この方法により、サードパーティは情報（たとえば、TCPリセット）をデータストリームに注入したり、2つのBGPピア間にあるルーティング情報を変更したりすることを防ぎます。
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輸送接続をリセットするために、正確なTCPシーケンス番号（ソースおよび宛先ポートおよびIPアドレスとともに）を正しく推測する必要があると単純に仮定しています。ただし、最近の観察とオープンディスカッションは、悪意のあるデータがTCP受信ウィンドウ内に該当するだけである必要があることを示しています。
As such, it is recommended that the MD5 TCP Signature Option be employed to protect BGP from session resets and malicious data injection.
そのため、セッションリセットと悪意のあるデータインジェクションからBGPを保護するために、MD5 TCP署名オプションを使用することをお勧めします。
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）ワーキンググループは、ルーティングテーブルの成長の問題、内部ルーティングプロトコルと外部ルーティングプロトコル間の相互作用の影響、およびグローバルルーティングシステムでの住所配分ポリシーと実践の影響を検討および測定するようチャーターされています。最後に、必要に応じて、成長は測定、ポリシー、セキュリティ、および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.
成長は現在、ルート集約の効果と、プロバイダーの調整が不十分なため、複数のプロバイダーの境界を越えて集約することができないことを研究しています。
Within GROW, this work is intended to result in feedback to BGPv4 and future protocol enhancements.
成長内では、この作業は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プログラムは、EGP、およびBGPを使用して外部ルーティング情報を提供しました。これは、さまざまな価格を提供し、BGPの初期ポリシー要件につながった研究と教育（RE）と商業（CO）ネットワークにさまざまなレベルのサポートを提供するというNSFポリシーでした。より多くの請求に加えて、COのネットワークはNSFNETバックボーンを使用して他のCOネットワークに到達することができませんでした。より高い価格の理論的根拠は、ビジネスおよび研究機関内の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形式に対するものであり、この形式を使用するためにツールが変換されました。データベースのコレクションは、インターネットルーティングレジストリ（IRR）と呼ばれ、RIPEデータベースとUS NSFファンディングルーティング仲裁人（RA）が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.
RPSWGのIETF内で拡張機能を定義し、RPSL言語になることを認識し、RPSL言語になりました。RPS WGのその他の作業製品は、認証フレームワークと、制御された方法でデータベースを広く配布し、多くのリポジトリを同期する手段を提供しました。自由に利用可能なツールは、主にRipe、Merit、およびISIの最も包括的なセットであるISIによって提供されました。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.
このドキュメントの以前のバージョンを執筆し、このアップデートに関する貴重な入力を提供してくれたPaul TrainaとYakov Rekhterに感謝します。また、テキストと徹底的なレビューの両方を提供してくれたCurtis Villamizarに感謝します。Russ White、Jeffrey Haas、Sean Mentzer、Mitchell Erblich、およびJude Ballardに感謝します。
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.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、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] Bates、T.、Chandra、R。、およびE. Chen、「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.、McPherson、D。、およびJ. Scudder、「BGPの自律システムコンフェデレーション」、RFC 3065、2001年2月。
[RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC 4274, January 2006.
[RFC4274] Meyer、D。およびK. Patel、「BGP-4プロトコル分析」、RFC 4274、2006年1月。
[RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report", RFC 4276, January 2006.
[RFC4276] Hares、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.、Li、T。、およびS. Hares、eds。、「A Border Gateway Protocol 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] Willis、S.、Burruss、J.、Chu、J。、「SMIV2を使用したBorder Gateway Protocol（BGP-4）の4番目のバージョンの管理オブジェクトの定義」、RFC 1657、1994年7月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1105、1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1163、1990年6月。
[RFC1264] Hinden, R., "Internet 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] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol 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] Willis、S。およびJ. Burruss、「Border Gateway Protocolの管理オブジェクトの定義：バージョン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. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995.
[RFC1773] Traina、P。、「BGP-4プロトコルの経験」、RFC 1773、1995年3月。
[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.、Meyer、D.、Bates、T.、Karrenberg、D。、およびM. Terpstra、「ルーティングポリシー仕様言語（RPSL）」、RFC 2622、1999年。
[BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway Protocol", Work in Progress.
[BGPATTACK] Convery、C。、「Border Gateway Protocolの攻撃ツリー」、進行中の作業。
[SBGP] "Secure BGP", Work in Progress.
[SBGP]「Secure BGP」、進行中の作業。
[soBGP] "Secure Origin BGP", Work in Progress.
[sobgp] "安全な起源BGP"、進行中の作業。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks
ダニーマクファーソンアーバーネットワーク
EMail: danny@arbor.net
Keyur Patel Cisco Systems
Keyur Patel Cisco Systems
EMail: keyupate@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。