RFC4277 日本語訳
4277 Experience with the BGP-4 Protocol. D. McPherson, K. Patel. January 2006. (Format: TXT=45117 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. McPherson
Request for Comments: 4277 Arbor Networks
Category: Informational K. Patel
Cisco Systems
January 2006
コメントを求めるワーキンググループD.マクファーソン要求をネットワークでつないでください: 4277年のあずまやはカテゴリをネットワークでつなぎます: 情報のK.パテルシスコシステムズ2006年1月
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)インターネット協会(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)によってインターネットDraft Standardとしてのルーティング・プロトコルの公表のための要件がどう満たされたかを記録することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 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.
このレポートはRFC1264のセクション6.0で説明されるように「2番目のレポート」のための要件を満たします。 Draft StandardといつStandardのためにそれを提出したかという理解は、要求にこたえるために、このレポートが、RFC1773を増大させて、追加知識について説明して、プロトコルが作られた時の間の時間、獲得されました。
McPherson & Patel Informational [Page 1] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[1ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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
1. 序論… 3 2. BGP-4概観… 3 2.1. ボーダ・ゲイトウェイ・プロトコル… 3 3. 管理情報ベース(MIB)… 3 4. 実現情報… 4 5. 操作上の経験… 4 6. TCP認識… 5 7. 測定基準… 5 7.1. マルチ_は_ディスク(医学の)を出ます… 5 7.1.1. 薬とじゃがいも… 6 7.1.2. 薬をBGPに送るのはじっと見ます… 7 7.1.3. 医学に対するゼロにおける医学… 7 7.1.4. 薬と時のルート選択… 7 8. 地方の好み… 8 9. 大きい自律システムの内部のBGP… 9 10. インターネット力学… 9 11. BGP経路情報は(あばら骨)を基礎づけます… 10 12. パッキングをアップデートしてください… 10 13. レートアップデートを制限してください… 11 13.1. TCPの特性の考慮… 11 14. 経路属性を注文します… 12 15. _として、ソーティングを設定してください… 12 16. バージョン交渉の上で制御してください… 13 17. セキュリティ問題… 13 17.1. TCP MD5署名オプション… 13 17.2. IPsecの上のBGP… 14 17.3. その他… 14 18. そして、プトマイン、成長してください… 14 19. インターネットルート設定登録(IRRs)… 15 20. 局地的なインターネット登録(RIRs)とIRRs、少しの歴史… 15 21. 承認… 16 22. 参照… 17 22.1. 標準の参照… 17 22.2. 有益な参照… 17
McPherson & Patel Informational [Page 2] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[2ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
1. Introduction
1. 序論
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)によってインターネットDraft Standardとしてのルーティング・プロトコルの公表のための要件がどう満たされたかを記録することです。
This report satisfies the requirement for "the second report", as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [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番目のレポート」のための要件を満たします。 Draft StandardといつStandardのためにそれを提出したかという理解は、要求にこたえるために、このレポートが、追加知識について増大して[RFC1773]、説明して、プロトコルが作られた時の間の時間、獲得されました。
2. BGP-4 Overview
2. BGP-4概観
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システムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASes)のリストの上の情報を含んでいます。 この情報は、この可到達性のために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]でそれぞれ指定されています。 Draft Standard[RFC1771]に行った後にBGP-4への変化はN Appendix[RFC4271]に記載されます。
2.1. A Border Gateway Protocol
2.1. ボーダ・ゲイトウェイ・プロトコル
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仕様の各繰り返しの間の変化の概要を提供します。
3. Management Information Base (MIB)
3. 管理情報ベース(MIB)
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 Management Information基地(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.
いくつかのシステム変数は別として、2個のテーブルがBGP MIBに細かく分けられます: BGP同輩テーブルとBGPは経路属性テーブルを受けました。
McPherson & Patel Informational [Page 3] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[3ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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.
Peer Tableは彼らの状態や現在の活動などのBGP同輩接続の情報を反映します。 Received Path Attribute Tableはローカルのルーティング方針が適用される前にすべての同輩から受け取られたすべての属性を含んでいます。 ルートを決定する際に使用される実際の属性は容認された属性テーブルの部分集合です。
4. Implementation Information
4. 実現情報
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 Implementation Report[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]のために。
5. Operational Experience
5. 運用経験
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.
1989年以来BGPは実稼動環境に使用されています。 1993年以来BGP-4は使用されています。 BGPの生産使用はプロトコルに関するすべての著しい特徴の利用を含んでいます。 現在の実稼動環境はBGPが相互自律システムルーティング・プロトコルとして使用されるところで非常に異種です。 リンク帯域幅に関して、それは56Kbpsから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].
実際のtopologiesに関して、それは非常にまばらであるのから全く濃く異なります。 完全なメッシュIBGP topologiesのための要件はBGP Route Reflection、BGP、およびしばしば2つのものの何らかのミックスのためのAutonomous System Confederationsによって主に改善されました。 BGP Route Reflectionを初めは、[RFC1966]で定義して、[RFC2796]でアップデートしました。 BGPのための自治のSystem Confederationsを初めは、[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のアクティブな自律システムが世界的なインターネット経路指定テーブルにある状態で。
McPherson & Patel Informational [Page 4] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[4ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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以上の自律システムの「そっと歩いている」経路の長さは存在しています。
6. TCP Awareness
6. TCP認識
BGP employs TCP [RFC793] as it's Transport Layer protocol. As such, all characteristics inherent to TCP are inherited by BGP.
BGPは、それがTransport Layerプロトコルであるので、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の遅れた出発アルゴリズムのために実現されないかもしれなくて、遅れた出発は接続などを再開します。
7. Metrics
7. 測定基準
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のための別々のメートル法のパラメタがあります。 これで、方針ベースの測定基準は距離ベースの測定基準を上書きできます。 これで、各自律システムはIntra-AS、およびInter-ASの独立している方針を定義できます。 EBGPによるメートル法のaがじっと見るとき(すなわち、相互ドメイン)、BGP Multi Exit Discriminator(MED)は使用されています、Local Preference(LOCAL_PREF)はIBGP同輩(すなわち、イントラドメイン)によって使用されますが。
7.1. MULTI_EXIT_DISC (MED)
7.1. マルチ_出口_ディスク(医学)です。
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はMULTI_EXIT_DISC(MED)としてのメートル法の古いINTER-ASを再定義しました。 この値は、都合のよい経路を与えられたアドレス空間に選択するとき、繋がりを壊す過程で使用されるかもしれなくて、同輩ASへの地方の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.
同じASで異なった外部の同輩から受け取られた経路を比較するときだけ、MEDは使用されることになっていましたが、多くの実現がMEDsを比較する能力を異なった自律システムの間に提供します。
Though this may seem a fine idea for some configurations, care must be taken when comparing MEDs of different autonomous systems. BGP
これはいくつかの構成のためのすばらしい考えに見えるかもしれませんが、異なった自律システムBGPのMEDsを比較するとき、注意しなければなりません。
McPherson & Patel Informational [Page 5] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[5ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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.
スピーカーは地方のASの中でしばしば与えられたBGP NEXT_HOPに達すると関連していた状態でIGPを入手するのによるメートル法のMED値を引き出します。 同輩にルートの広告を出すとき、これで、MEDsは合理的にIGP topologiesを反映できます。 異なった自律システムのMEDsを比較するとき、独身の隣接しているASから学習された複数の経路のMEDsを比較するとき、これがすばらしい間、それは潜在的に悪い決定をもたらすことができます。自律システムがIGP測定基準、BGP MEDsを引き出すか、または恐らく広大に距離空間を対照する異なった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ルーティング情報の集合のMEDsへの影響にかかわります。 集合は、安定性、冗長、および他のネットワークデザイン目標に対応するためにASで複数の所在地からしばしば発生します。 前述の集合に関連しているIGP測定基準からMEDsを得るとき、同輩に広告に掲載された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は、a「弱い」メートル法であるためにわざわざ設計されました。 BGPワーキンググループは関係があった、それ、少しもメートル法、リモートオペレータによって指定されて、他の好みが全く指定されない場合にだけ、地方のASでのルーティングに影響するでしょうに。 MEDのデザインの最高の目標は同輩がそれらが広告を出すネットワークのために交通を「落ちる」か、または「吸収できないこと」を保証することでした。
7.1.1. MEDs and Potatoes
7.1.1. 薬とじゃがいも
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.
交通が1組の目的地の間を流れるところでは、それぞれが2つの輸送網に関連づけられて、それぞれの輸送網は別のトランジットプロバイダーか交通の最も近くにもう片方のプロバイダーを通して最小費用の広告を出すじっと見るのに交通をじっと見るのに送ることの選択を持っています。 それを持っている人なら誰でも素手に保持された困難な立場のようにすばやくそれを取り除こうとするので、前の方法は「困難な立場ルーティング」と呼ばれます。 困難な立場ルーティングは、EBGPが学術的なMEDをIBGPに渡さないことによって、達成されます。 これは交通を発送するプロバイダーのためのトランジット交通を最小にします。 はるかに一般的でないのは、「冷たいじゃがいもルーティング」(トランジットプロバイダーは目的地の最も近くにあるとして広告に掲載された隣接しているトランジットプロバイダーに交通が肝心になるそれ自身のトランジット能力を使用する)です。 冷たいじゃがいもルーティングは、EBGPが学術的なMEDを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
1つのトランジットプロバイダーが困難な立場ルーティングを使用して、別のものが冷たいじゃがいもルーティングを使用するなら、2つの間の交通は、左右対称である傾向があります。 取引関係によって、1つのプロバイダーにより多くの容量かかなり混雑していないトランジットネットワークがあるなら、そのプロバイダーは冷たいじゃがいもルーティングを使用するかもしれません。 NSFによって資金を供給されたNSFNET背骨
McPherson & Patel Informational [Page 6] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[6ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
and NSF-funded regional networks are examples of widespread use of cold potato routing in the mid 1990s.
そして、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.
いくつかの場合、プロバイダーは、与えられた同輩ASのためのいくつかの目的地に困難な立場ルーティングを使用して、他のものに冷たいじゃがいもルーティングを使用するかもしれません。 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".
外観上より直感的な参照(植物界をそらせる)は、「最も良い出口ルーティング」と冷たいじゃがいもルーティングを呼んで、「最も近い出口ルーティング」として困難な立場ルーティングを呼びます。
7.1.2. Sending MEDs to BGP Peers
7.1.2. BGP同輩に薬を送ります。
[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同輩からも受け取られたMEDsがIBGP同輩に渡されるのを許容します。 IBGP同輩への広告MEDsは必要な振舞いではありませんが、それは一般的なデフォルトです。 MEDsはBGPでEBGP同輩からスピーカーSHOULD NOTを受けました。他の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 topologiesと測定基準を反映するのを許容するためにIGP測定基準からMED値を得るためにメカニズムを提供することに注意してください。
7.1.3. MED of Zero Versus No MED
7.1.3. ゼロでは、医学に対してではなく医学です。
[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値を定義するためにメカニズムを提供することに注意してください。
7.1.4. MEDs and Temporal Route Selection
7.1.4. 薬と時のルート選択
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値のための好みなしで。 これのための推理は「より古い」経路がおそらく、より安定していて、その結果、望ましいということです。 しかしながら、非決定論的な振舞いと、そのようなものとしたルート選択結果における時の振舞いはしばしば望ましくないかもしれません。
McPherson & Patel Informational [Page 7] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[7ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
8. Local Preference
8. 地方の好み
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のマルチベンダルータのinteroperationで支援されるでしょう(LOCAL_PREFが地方行政属性であるので、相互運用性欠点が全くAS境界のむこうにありません)。
[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 Peersではなく、IBGP Peersに送られるのを必要とします。 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が影響を及ぼすかもしれない中で経路選択の過程最も良い方法です。 例えば、二元的に接続されたサイトは、第一のトランジットサービスプロバイダーとして1つを選んで、バックアップとして1つを持っているかもしれません。
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
/---- トランジットB----\末端顧客トランジットA---- /---- トランジット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に対応しています。そこで、各トランジットASは好みの値を与えられたルートに示すかもしれません。 そして、協力自律システムはルーティング方針によると、このベクトルの「おもしろい」部分の比較に基づく交通を選ぶかもしれません。
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のようなプロトコルで、より慎重に調べられるべきルーティング方針の必要性の大規模な手の構成を避けて。
McPherson & Patel Informational [Page 8] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[8ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
9. Internal BGP In Large Autonomous Systems
9. 大きい自律システムの内部の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は伝播されるこの情報がことである方法を指定しません。 したがって、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[RFC3065]のためのBGP Route Reflection[RFC2796]とAS Confederationsを含んでいて。
10. Internet Dynamics
10. インターネット力学
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と帯域幅利用における原動力はインターネットでのルーティングのダイナミックな本質です。 インターネットが発展するのに従って、1秒あたりのルート変化の頻度は増加しました。
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]のAppendix 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 Route Flap Dampingは[RFC2439]で定義されます。 BGP Route Flap Dampingは、BGP同輩の間で通過されたルーティング情報の量を減少させるのを助けるためにメカニズムを定義します。情報はこれらの同輩で比較的安定したルートへの悪影響を与えているルート集合時間なしで負荷を減少させます。
McPherson & Patel Informational [Page 9] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[9ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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.
BGP Route Flap Dampingの現在の実現のいずれもユニークなNRLIかAS Pathによるルート歴史を格納しません、RFC2439は、これが義務的であると記載しますが。 別々に各AS Pathを考えないことの潜在的結果は密にかみ合っているネットワークで、目的地のひどく攻撃的な抑圧です、ただ一つの失敗の後の目的地の抑圧である最も厳しい結果で。 インターネットの最高層の自律システムが密に網の目にかけられるので、これらの不利な結果は観測されます。
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で議論するように、Update Packing。
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誤りで持続してばたつくかもしれません、重要なCPU使用率をもたらして。 作成者は、そのようなしつこい同輩のばたつくこと[RFC4271]を避けるために同輩の湿りを実行するのが役に立つのがわかるかもしれません。
11. BGP Routing Information Bases (RIBs)
11. BGP経路情報基地(あばら骨)
[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".
「また、地元のBGPスピーカーの推進テーブルに加えられないで外のAdj-RIBに加えられるルートをもたらすどんなローカルの方針もこのドキュメントの範囲の外のそうです。」と、[RFC4271]は述べます。
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にそれらをインストールする前に推進テーブルに居住するのに使用されたと確認しません。 この最も一般的な発生はBGPが学術的なルートが別のプロトコルのものより低いので与えられた接頭語のためのルートが1つ以上のプロトコル、および好みで提示される時です。 そういうものとして、もう片方のプロトコルで学習されたルートは、推進テーブルに居住するのに使用されます。
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ルートの広告を出すことができるノブを提供するのも、望ましいかもしれません。
12. Update Packing
12. アップデートパッキング
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 Updateメッセージに複数の実行不可能なルートの広告を出すことができます。 さらに、ただ一つのUpdateメッセージに1つ以上の可能なルートの広告を出すことができます、すべての接頭語が一般的な属性セットを共有する限り。
McPherson & Patel Informational [Page 10] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[10ページ]のRFC4277Experienceは2006年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 より少ないUpdateメッセージの世代か受領によるシステムオーバーヘッドの減少。
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データベースにセットします(1がありましたら)。 経路属性の一貫した注文はデータベースで合う容易さを考慮します、同じデータの異なった表現が存在しないとき。
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でばたつく過度のルートを軽減するのを助けます。
13. Limit Rate Updates
13. 限界レートアップデート
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プロトコルはレート限界Update広告と異なったメカニズムを定義します。 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.
Transportが議定書を作るときBGPがTCPを当てにして、TCPは空の窓のためデータの伝達を防ぐことができます。 その結果、複数のアップデートが元々列に並ばせられたより近くで一緒に区切られるかもしれません。 それは一般的ではありませんが、実装はこの発生を意識しているべきです。
13.1. Consideration of TCP Characteristics
13.1. 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バッファがいっぱいになるとき、送付アプリケーションがいっぱいにすることのようにどちらかのブロックの後でなる、誤りを書くか、または受ける、書いてください。 早めの実装かナイーブな新しい実装、ブロックへの進行中の設定オプション、書いてください。さもないと、非ブロッキングが書くので、設定オプションは一般的な誤りです。 そのような実装は致命的であるとして完全なバッファ関連する誤りを扱います。
McPherson & Patel Informational [Page 11] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[11ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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.
複数の回がゆったり過ごすa当然のことの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の上の孤立しているルート変更を行う唯一の影響が、より遅い集合です、どの集合時間が残っているかがバウンドしたので、不安定性の量にかかわらず。
14. Ordering of Path Attributes
14. 経路属性の注文
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プロトコルは、Type Codesによると、複数のUPDATEメッセージあたりの接頭語を送る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.
Implementersは、Type Codeによると、経路属性を命令するのが役に立つのがわかるかもしれません、よりはやく同じ意味論がある属性のセットを特定できるように。
15. AS_SET Sorting
15. _セットソーティングとして
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番号の効率的なルックアップを容易にする増加する命令で分類されます。 この最適化は任意です。
McPherson & Patel Informational [Page 12] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[12ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
16. Control Over Version Negotiation
16. バージョン交渉のコントロール
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の以前のバージョンでプレBGP-4ルート集合をサポートすることができないので、BGP-4に加えたバージョンをサポートする実装は1同輩あたり1個のベースでサポートをバージョンに提供するべきです。 この書くこと時点で、インターネットのすべてのBGPスピーカーがBGPバージョン4を実行していると考えられます。
17. Security Considerations
17. セキュリティ問題
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のどちらかによって提供されたどんな認証やセキュリティー対策によっても増大させられるかもしれません。
17.1. TCP MD5 Signature Option
17.1. TCP MD5署名オプション
[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]は2人の同輩の間に伝えられた情報を有効にするのにTCP MD5署名オプションを使用できる方法を定義します。 第三者がこのメソッドによって、情報(例えば、TCP Reset)をdatastreamに注ぐことができませんか、またはルーティング情報を変更するのは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.
多くが、攻撃者が、正確なTCP一連番号(ソース、仕向港、およびIPアドレスに伴う)が2人のBGP同輩の間にデータ・セグメントを注入するか、または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 Signature Optionがセッションリセットと悪意があるデータ注射からBGPを保護するのに使われるのは、お勧めです。
McPherson & Patel Informational [Page 13] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[13ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
17.2. BGP Over IPsec
17.2. IPsecの上の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はトンネルか交通機関でIPsecをひくことができます。そこでは、IPパケットのTCP部分が暗号化されています。 これによって、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のベースのプロトコルでも存在しているサービスと認証攻撃の同じ否定に被害を受け易いのが有名であるべきです。
17.3. Miscellaneous
17.3. その他
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[SBGP][soBGP]の中で運ばれたルーティング情報に合法化と権威を提供する手段を開発するのにBGP[BGPATTACK]、および取り組みに使用できる脅威を定義するために取り組みを含んでいて。
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.
さらに、ルート設定プロトコルSecurity Requirements(RPSEC)ワーキンググループは、問題提示周辺ルーティング・プロトコルセキュリティについて議論して、助けるためにIETFのルート設定Areaの中でチャーターされました。 RPSECの中では、この仕事がBGP4へのフィードバックと今後のプロトコル増進をもたらすことを意図します。
18. PTOMAINE and GROW
18. プトマイン、成長してください。
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.
最近Globalルート設定Operations(GROW)ワーキンググループに取って代わられたPrefix Taxonomy(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は現在、ルート集合の効果を研究して、また、不十分なプロバイダーコーディネートのため複数のプロバイダー限界にわたって集めることができないことを研究しています。
McPherson & Patel Informational [Page 14] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[14ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
Within GROW, this work is intended to result in feedback to BGPv4 and future protocol enhancements.
GROWの中では、この仕事がBGPv4へのフィードバックと今後のプロトコル増進をもたらすことを意図します。
19. Internet Routing Registries (IRRs)
19. インターネットルート設定登録(IRRs)
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.
多くの組織がインターネットルート設定Registryの様々な分散データベースにおける彼らのルーティング方針と接頭語創作を登録します。 これらのデータベースは、[RFC2622]で定義されるようにRPSL言語を使用することで情報入手を提供します。 あるプロバイダーに、登録された情報は、維持されていて正しいかもしれませんが、様々なIRRデータベースにおける、タイムリーであるか正しいデータの不足はこのリソースの広い普及の使用を防ぎました。
20. Regional Internet Registries (RIRs) and IRRs, A Bit of History
20. 局地的なインターネット登録(RIRs)とIRRs、少しの歴史
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を使用しました。 それは、ResearchとEducation(RE)に異なった価格を提供して、異なったレベルのサポートを供給するNSF方針とBGPの初期の方針要件につながったCommercial(CO)ネットワークでした。 もう少し請求されることに加えて、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 Policyルート設定Database(PRDB)のメインテナンスで実行されました。 PRDBは、COかREとしてそれぞれのネットワーク名称を含んでいるだけではなく、各ネットワークに達するように都合のよいエキジットポイントのリストをNSFNETに含みもしました。 これは後でNSFNETの上のBGP LOCAL_PREFと呼ばれるものを設定する基礎でした。 ツールはNSFNETのための完全なルータ構成であると生成されるPRDBに供給されました。
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
1995年にNSFNET Backbone Network Serviceを解任してください、そして、それほどPRDBをただ一つのプロバイダー中心にするべきでないと認められて、それを利用しても構わないと思っているどんなプロバイダーもレガシーコンテンツ、およびどんなさらなるアップデートも入手するべきです。 ヨーロッパのネットワーク共同体は、長い間、PRDBがも米国であることを中心であることの形で見ていました。 Reseaux IP Europeens(RIPE)を通して、ヨーロッパ人は、RIPE-181で開いている形式を作成して、使用されているのにオープンデータベースを維持しました。
McPherson & Patel Informational [Page 15] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[15ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
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.
方針より多くのアドレスとAS登録。 RIPE-181形式にはPRDBの初期の変換がありました、そして、ツールは、この形式を利用するために変換されました。 データベースの収集はインターネットルート設定Registry(IRR)と呼ばれました、IRRの初期の部品であるRIPEデータベースとUS NSFによって資金を供給されたルート設定Arbitrator(RA)で。
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は拡大がRPS WGのIETFの中で定義されるのを許容するのに同意しました、RPSL言語をもたらして。 RPS WGの他の作業生産物は認証フレームワークと広く制御方法によるデータベースを分配して、多くの倉庫を連動させる手段を提供しました。 自由に利用可能なツールは主としてRIPE、Merit、および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の浸食のためにやむを得ずより少ない徹底した報道を提供しました。 これらのタイプの分裂には、まれに起こり続けていますが、ますます広範囲の影響力があります。
21. Acknowledgements
21. 承認
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とヤコフRekhterに感謝申し上げます。 また、テキストと徹底的なレビューの両方を提供するためにカーティスVillamizarを承認したいと思います。 ラス・ホワイト、ジェフリー・ハース、ショーンMentzer、ミッチェルErblich、およびジュード・バラードに彼らの普通の鋭い目を供給してくださってありがとうございます。
Finally, we'd like to think the IDR WG for general and specific input that contributed to this document.
最終的に、このドキュメントに貢献した一般的で特定の入力のためにIDR WGを考えたいと思います。
McPherson & Patel Informational [Page 16] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[16ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
22. References
22. 参照
22.1. Normative References
22.1. 引用規格
[RFC1966] Bates, T. and R. Chandra, "BGP Route Reflection An
alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC1966] ベイツとT.とR.チャンドラ、「完全なメッシュIBGPへのBGP Route Reflection An代替手段」、RFC1966、1996年6月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998.
[RFC2439] VillamizarとC.とチャンドラ、R.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、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への代替手段」、RFC2796、2000年4月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, February 2001.
2001年2月の[RFC3065]TrainaとP.とマクファーソン、D.とJ.Scudder、「BGPのための自律システム同盟者」RFC3065。
[RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC
4274, January 2006.
[RFC4274] マイヤーとD.とK.パテル、「BGP-4プロトコル分析」、RFC4274、2006年1月。
[RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report",
RFC 4276, January 2006.
[RFC4276] 野兎とS.とA.レタナ、「BGP4実装レポート」、RFC4276、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.野兎、Eds、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271、1月2006日
[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.、「SMIv2"を使用して、境界ゲートウェイの第4バージョンのための管理オブジェクトの定義は(BGP-4)について議定書の中で述べます、RFC1657、1994年7月。」
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
22.2. Informative References
22.2. 有益な参照
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1105, June 1989.
[RFC1105]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1105 1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1163, June 1990.
[RFC1163]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1163 1990年6月。
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet
Routing Protocol Standardization Criteria", RFC 1264,
October 1991.
[RFC1264] Hinden、R.、「インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準」、RFC1264、1991年10月。
McPherson & Patel Informational [Page 17] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[17ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[RFC1267]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267 1991年10月。
[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インチ、RFC1269、1991年10月。
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, July 1994.
[RFC1656] Traina、P.、「BGP-4プロトコルは道路地図と実装経験を記録する」RFC1656、1994年7月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995.
[RFC1773] Traina、P.、「BGP-4プロトコルの経験」、RFC1773、1995年3月。
[RFC1965] Traina, P., "Autonomous System Confederations for BGP",
RFC 1965, June 1996.
[RFC1965] Traina、P.、「BGPのための自律システム同盟者」、RFC1965、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)」、RFC2622(1999年6月)。
[BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway
Protocol", Work in Progress.
C.、「ボーダ・ゲイトウェイ・プロトコルのための攻撃木」という[BGPATTACK]Converyは進行中で働いています。
[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
Keyurパテルシスコシステムズ
EMail: keyupate@cisco.com
メール: keyupate@cisco.com
McPherson & Patel Informational [Page 18] RFC 4277 Experience with the BGP-4 Protocol January 2006
BGP-4のマクファーソンとパテル情報[18ページ]のRFC4277Experienceは2006年1月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
McPherson & Patel Informational [Page 19]
マクファーソンとパテルInformationalです。[19ページ]
一覧
スポンサーリンク
