Network Working Group G. Huston
Request for Comments: 3765 Telstra
Category: Informational April 2004
NOPEER Community for Border Gateway Protocol (BGP)
Route Scope Control
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 (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections.
この文書では、スコープ制御ボーダーゲートウェイプロトコル（BGP）コミュニティの使用を記載しています。このよく知られた諮問推移コミュニティは、特定のルートが外部に伝播すべき範囲を指定するAS起源することができます。特に、このコミュニティは、NOPEER、この属性を持つルートが二国間のピア接続間で宣伝する必要がないことを指定するAS起源することができます。
BGP today has a limited number of commonly defined mechanisms that allow a route to be propagated across some subset of the routing system. The NOEXPORT community allows a BGP speaker to specify that redistribution should extend only to the neighbouring AS. Providers commonly define a number of communities that allow their neighbours to specify how advertised routes should be re-advertised. Current operational practice is that such communities are defined on as AS by AS basis, and while they allow an AS to influence the re-advertisement behaviour of routes passed from a neighbouring AS, they do not allow this scope definition ability to be passed in a transitive fashion to a remote AS.
BGPは、今日では、ルートは、ルーティングシステムのサブセットに伝播することを可能にする一般的定義されたメカニズムの限定された数を有します。 NOEXPORTコミュニティはその再配布を指定するBGPスピーカのみを隣接ASに拡張する必要がありますことができます。プロバイダは、一般的に彼らの隣人が再公示しなければならないか、アドバタイズルートを指定することができ、コミュニティの数を定義します。現在の運用練習は、このような社会がようASによって基礎として上で定義されていることである、と彼らはASが隣接ASから渡されたルートの再広告の行動に影響を与えることができるようにしながら、彼らはこのスコープ定義能力が渡さすることはできません。リモートASに推移ファッション。
Advertisement scope specification is of most use in specifying the boundary conditions of route propagation. The specification can take on a number of forms, including as AS transit hop count, a set of target ASs, the presence of a particular route object, or a particular characteristic of the inter-AS connection.
広告スコープ仕様は、ルートの伝播の境界条件を指定する際に最も有用です。仕様は、通過ホップ数、目標お尻のセット、特定のルートオブジェクトの存在、またはインターAS接続の特定の特徴ASとして含め、多くの形をとることができます。
There are a number of motivations for controlling the scope of advertisement of route prefixes, including support of limited transit services where advertisements are restricted to certain transit providers, and various forms of selective transit in a multi-homed environment.
広告が特定のトランジットプロバイダーに制限されている限らトランジットサービスのサポート、およびマルチホーム環境での選択的輸送の様々な形態を含むルートプレフィックスの広告の範囲を制御するための動機の数があります。
This memo does not attempt to address all such motivations of scope control, and addresses in particular the situation of both multi-homing and traffic engineering. The commonly adopted operational technique is that the originating AS advertises an encompassing aggregate route to all multi-home neighbours, and also selectively advertises a collection of more specific routes. This implements a form of destination-based traffic engineering with some level of fail over protection. The more specific routes typically cease to lever any useful traffic engineering outcome beyond a certain radius of redistribution, and a means of advising that such routes need not to be distributed beyond such a point is of some value in moderating one of the factors of continued route table growth.
このメモは、特にマルチホーミングおよびトラフィックエンジニアリングの両方の状況をこのようなすべてのスコープコントロールの動機、およびアドレスを解決しようとしません。一般的に採用され運用技術が発信されたものとしては、すべてのマルチホーム隣人への包括的な集約ルートをアドバタイズことであり、また、選択的に、より具体的なルートのコレクションをアドバタイズします。これは、保護をフェールオーバーのいくつかのレベルで宛先ベースのトラフィックエンジニアリングのフォームを実装しています。より具体的なルートは、典型的には、再配布の特定の半径を超えて、任意の有用なトラフィックエンジニアリング結果をレバーに停止し、そのような経路は、このような点を越えて配布する必要はないことを助言する手段を継続経路の要因の一つを緩和にある値でありますテーブルの成長。
Analysis of the BGP routing tables reveals a significant use of the technique of advertising more specific prefixes in addition to advertising a covering aggregate. In an effort to ameliorate some of the effects of this practice, in terms of overall growth of the BGP routing tables in the Internet and the associated burden of global propagation of dynamic changes in the reachability of such more specific address prefixes, this memo describes the use of a transitive BGP route attribute that allows more specific route tables entries to be discarded from the BGP tables under appropriate conditions. Specifically, this attribute, NOPEER, allows a remote AS not to advertise a route object to a neighbour AS when the two AS's are interconnected under the conditions of some form of sender keep all arrangement, as distinct from some form of provider / customer arrangement.
BGPルーティングテーブルの分析は、被覆骨材を広告に加えて、広告のより具体的なプレフィックスの技術の有意な使用を明らかにする。この練習の効果の一部を改善するための努力では、インターネットでのBGPルーティングテーブルの全体的な成長や、より具体的なアドレスプレフィックスの到達可能性の動的変化の世界的な伝播の関連した負担という点で、このメモは説明しますより具体的なルートテーブルエントリは、適切な条件下でBGPテーブルから破棄することができます推移BGPルート属性を使用します。具体的には、この属性、NOPEERは、リモートAS 2 ASのは、すべての配置、プロバイダー/顧客配置のいくつかのフォームとは区別を維持し、送信者のいくつかのフォームの条件の下で相互に接続されている場合など、ネイバーにルートオブジェクトを宣伝していないことができます。
This memo defines the use a new well-known bgp transitive community, NOPEER.
このメモは使用の新しい、よく知られたBGPの推移コミュニティ、NOPEERを定義します。
The semantics of this attribute is to allow an AS to interpret the presence of this community as an advisory qualification to readvertisement of a route prefix, permitting an AS not to readvertise the route prefix to all external bilateral peer neighbour AS's. It is consistent with these semantics that an AS may filter received prefixes that are received across a peering session that the receiver regards as a bilateral peer sessions.
この属性の意味は、ASすべての外部の二国間のピア隣人ASのへのルートプレフィックスをreadvertiseしない許せば、ASは、ルートプレフィックスの再広告するための諮問資格として、このコミュニティの存在を解釈できるようにすることです。これは、ASがピアリングセッションを横切って受信されたプレフィックスを受信しフィルタリングすることができるこれらのセマンティクスと一貫していることを両側ピアセッションとして受信に関して。
The size of the BGP routing table has been increasing at an accelerating rate since late 1998. At the time of publication of this memo the BGP forwarding table contains over 118,000 entries, and the three year growth rate of this table shows a trend rate which can be correlated to a compound growth rate of no less than 10% per year [2].
BGPルーティングテーブルのサイズは、後半に1998年以来、加速度的に増加しており、このメモの公開時点でBGP転送テーブルには、118,000以上のエントリが含まれており、この表の3年間の成長率はでき傾向率を示し[2]、年間10％以上の化合物の成長率に相関します。
One of the aspects of the current BGP routing table is the widespread use of the technique of advertising both an aggregate and a number of more specific address prefixes. For example, the table may contain a routing entry for the prefix 10.0.0.0/23 and also contain entries for the prefixes 10.0.0.0/24 and 10.0.1.0/24. In this example the specific routes fully cover the aggregate announcement. Sparse coverage of aggregates with more specifics is also observed, where, for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both exist in the routing table. In total, these more specific route entries occupy some 51% of the routing table, so that more than one half of the routing table does not add additional address reachability information into the routing system, but instead is used to impose a finer level of detail on existing reachability information.
現在のBGPルーティングテーブルの側面の一つは、凝集より特定のアドレスプレフィックスの数の両方広告の技術の普及です。例えば、テーブルは、プレフィックス10.0.0.0/23のルーティングエントリを含み、また、プレフィクス10.0.0.0/24と10.0.1.0/24のエントリを含んでいてもよいです。この例では、特定の経路は、完全集約アナウンスを覆います。例えば、10.0.0.0/8と10.0.1.0/24の両方のためのルーティングエントリがルーティングテーブルに存在する場合、より具体的有する凝集体の疎カバレッジも、観察されました。ルーティングテーブルの半分以上は、ルーティングシステムに追加のアドレスの到達可能性情報を追加しません、その代わりより詳細なレベルを課すために使用されるように、合計で、これらのより特定のルートエントリは、ルーティングテーブルの一部の51％を占め既存の到達可能性情報に。
There are a number of motivations for having both an aggregate route and a number of more specific routes in the routing table, including various forms of multi-homed configurations, where there is a requirement to specify a different reachability policy for a part of the advertised address space.
アドバタイズの一部に異なる到達可能性ポリシーを指定する必要があるマルチホームの構成の様々な形態を含む集約経路とルーティングテーブルのより具体的なルートの数の両方を有するための動機の数は、ありますアドレス空間。
One of the observed common requirements in the multi-homed network configuration is that of undertaking some form of load balancing of incoming traffic across a number of external connections to a number of different neighbouring ASs. If, for example, an AS wishes to use a multi-homed configuration for routing-based load balancing and some form of mutual fail over between the multiple access connections for incoming traffic, then one approach is for the AS to advertise the same aggregate address prefix to a number of its upstream transit providers, and then advertise a number of more specifics to individual upstream providers. In such a case all of the traffic destined to the more specific address prefixes will be received only over those connections where the more specific has been advertised. If the neighbour BGP peering session of the more specific advertisement fails, the more specific will cease to be announced and incoming traffic will then be passed to the originating network based on the path associated with the advertisement of the encompassing aggregate. In this situation the more specific routes are not automatically subsumed by the presence of the aggregate at any remote
マルチホームネットワーク構成において観察された一般的な要件の1つは、異なる隣接のASの番号への外部接続の数を横切って着信トラフィックの負荷分散のいくつかのフォームを引き受けるのものです。例えば、ASは、ルーティング・ベースのロード・バランシングのためのマルチホームの構成及び相互着信トラフィックに複数のアクセス接続の間にフェイルオーバーのいくつかのフォームを使用したい場合には、一つのアプローチは、ASが同じ集約アドレスをアドバタイズするためのものですその上流のトランジットプロバイダの数に接頭辞、その後、個々の上流のプロバイダに、より詳細の数を広告。そのような場合には、より具体的なアドレスプレフィックス宛てのトラフィックのすべては、より具体的には宣伝されてきたこれらの接続を介して受信されます。より具体的な広告の隣人BGPピアリングセッションが失敗した場合は、より具体的には、発表されなくなり、着信トラフィックはその後、包括的な集計の広告に関連するパスに基づいて発信ネットワークに渡されます。この状況では、より具体的なルートは自動的に遠隔での凝集体の存在によって包含されていません
AS. Both the aggregate and the associated more specific routes are redistributed across the entire external BGP routing domain. In many cases, particularly those associated with desire to undertake traffic engineering and service resilience, the more specific routes are redistributed well beyond the scope where there is any outcomes in terms of traffic differentiation.
なので。骨材および関連するより具体的なルートの両方が全体の外部BGPルーティングドメインを横切って再分配されます。多くの場合、トラフィックエンジニアリングとサービスの回復力に着手したいと関連する特にでは、より具体的なルートが良く、交通分化の面で何らかの成果がある範囲を超えて再配布されています。
To the extent that remote analysis of BGP tables can observe this form of configuration, the number of entries in the BGP forwarding table where more specific entries share a common origin AS with their immediately enclosing aggregates comprise some 20% of the total number of FIB entries. Using a slightly stricter criteria where the AS path of the more specific route matches the immediately enclosing aggregate, the number of more specific routes comprises some 14% of the number of FIB entries.
BGPテーブルのリモート解析は、構成のこの形態を観察することができる程度まで、より具体的なエントリは、そのすぐ封入凝集体と同様に共通の起源を共有するBGP転送テーブル内のエントリの数は、FIBエントリの総数の約20％を占めます。より具体的なルートのASパスが直接囲む骨材と一致する若干厳格な基準を用いて、より具体的なルートの数は、FIBエントリ数のいくつかの14％を含みます。
One protocol mechanism that could be useful in this context is to allow the originator of an advertisement to state some additional qualification on the redistribution of the advertisement, allowing a remote AS to suppress further redistribution under some originator-specified criteria.
この文脈において有用であり得る一つのプロトコルメカニズムは、広告の発信者は、いくつかの発信者が指定した基準の下でさらなる再配布を抑制するよう遠隔を可能に、広告の再分配にいくつかの追加の資格を述べるようにすることです。
The redistribution qualification condition can be specified either by enumeration or by classification. Enumeration would encompass the use of a well-known transitive extended community to specify a list of remote AS's where further redistribution is not advised. The weakness of this approach is that the originating AS would need to constantly revise this enumerated AS list to reflect the changes in inter-AS topology, as, otherwise, the more specific routes would leak beyond the intended redistribution scope. An approach of classification allows an originating AS to specify the conditions where further redistribution is not advised without having to refer to the particular AS's where a match to such conditions are anticipated.
再配布の資格条件を列挙するか、分類のいずれかで指定することができます。列挙はさらに再配布がお勧めされていないところだASリモートのリストを指定するには、よく知られている推移拡張コミュニティの使用を包含します。このアプローチの弱点は、そうでない場合は、より具体的なルートが意図した再配布の範囲を超えて漏れてしまうほどの発信元は、常にこれはインターASトポロジの変更を反映するために、リストとして列挙改正する必要があるだろうということです。さらに再配布は、このような条件に一致が予想される特定のASのを参照することなく、お勧めされていない条件を指定する分類のアプローチは、発信を可能にします。
The approach described here to specifying the redistribution boundary condition is one based on the type of bilateral inter-AS peering. Where one AS can be considered as a customer, and the other AS can be considered as a contracted agent of the customer, or provider, then the relationship is one where the provider, as an agent of the customer, carries the routes and associated policy associated with the routes. Where neither AS can be considered as a customer of the other, then the relationship is one of bilateral peering, and neither AS can be considered as an agent of the other in redistributing policies associated with routes. This latter arrangement is commonly referred to as a "sender keep all peer" relationship, or "peering".
再配布境界条件を指定するここで説明するアプローチは、二国間の相互ASピアリングの種類に基づいて、1です。一つには、顧客と見なすことができ、他のASは、顧客、またはプロバイダの契約エージェントとみなすことができる場合、その後の関係は、顧客の代理人としてプロバイダは、ルートおよび関連するポリシーを運ぶものですルートに関連付けられています。どちらのASが他の顧客とみなすことができる場合は、その関係は二国間のピアリングの一つであり、どちらもASルートに関連付けられたポリシーを再配布の他の薬剤として考えることができます。この後者の配置は、一般的な関係「送信者がすべてのピアを維持する」、又は「ピアリング」と呼ばれます。
This peer boundary can be regarded as a logical point where the redistribution of additional reachability policy imposed by the origin AS on a route is no longer an imposed requirement.
このピア境界は、ルート上のAS起源によって課される追加の到達可能性ポリシーの再分配がもはや課せられる要件である論理ポイントとみなすことができます。
This approach allows an originator of a prefix to attach a commonly defined policy to a route prefix, indicate that a route should be re-advertised conditionally, based on the characteristics of the inter-AS connection.
このアプローチは、経路プレフィックスに共通に定義されたポリシーを付加するプレフィックスの発信者が、ルートがAS間の接続の特性に基づいて、条件付きで再アドバタイズされるべきであることを示すことができます。
The IANA has registered NOPEER as a well-known community, as defined in [1], as having global significance.
グローバルな意味を有するものとして、[1]で定義されるようにIANAは、よく知られたコミュニティとしてNOPEERが登録されています。
NOPEER (0xFFFFFF04)
NOPEER（0xFFFFFF04）
This is an advisory qualification to readvertisement of a route prefix, permitting an AS not to readvertise the route prefix to all external bilateral peer neighbour AS's. It is consistent with these semantics that an AS may filter received prefixes that are received across a peering session that the receiver regards as a bilateral peer sessions
これは、AS、すべての外部の二国間のピア隣人ASのへのルートプレフィックスをreadvertiseしない許可、ルートプレフィックスの再広告する諮問資格です。これは、ピアリングセッションを横切って受信されたASは、プレフィックスを受信しフィルタリングすることができるこれらのセマンティクスと一貫していることを両側ピアセッションとして受信みなし
BGP is an instance of a relaying protocol, where route information is received, processed and forwarded. BGP contains no specific mechanisms to prevent the unauthorized modification of the information by a forwarding agent, allowing routing information to be modified, deleted or false information to be inserted without the knowledge of the originator of the routing information or any of the recipients.
BGPは、経路情報は、受信処理及び転送される中継プロトコルのインスタンスです。 BGPは、ルーティング情報が削除または誤った情報が、ルーティング情報、または受信者の任意の発信者の知識なしに挿入されるように、改変することができるように、転送エージェントが情報の不正改変を防止するために特別な機構を含んでいません。
The NOPEER community does not alter this overall situation concerning the integrity of BGP as a routing system.
NOPEERコミュニティは、ルーティングシステムとしてBGPの整合性について、この全体的な状況を変更しません。
Use of the NOPEER community has the capability to introduce additional attack mechanisms into BGP by allowing the potential for man-in-the-middle, session-hijacking, or denial of service attacks for an address prefix range being launched by a remote AS.
NOPEERコミュニティの使用は、イン・ザ・ミドル男-、セッション・ハイジャック、またはリモートASによって起動されているアドレスのプレフィックス範囲のためのサービス拒否攻撃の可能性を可能にすることにより、BGPに追加攻撃の仕組みを導入する能力を持っています。
Unauthorized addition of this community to a route prefix by a transit provider where there is no covering aggregate route prefix may cause a denial of service attack based on denial of reachability to the prefix. Even in the case that there is a covering aggregate, if the more specific route has a different origin AS than the aggregate, the addition of this community by a transit AS may cause a denial of service attack on the origin AS of the more specific prefix.
集約ルートのプレフィックスをカバーする何がプレフィックスへの到達性の否定に基づいてサービス拒否攻撃を引き起こすことがありませんトランジットプロバイダーによってルートプレフィックスにこのコミュニティの無断追加。でも、被覆集合体が、より具体的なルートが集約よりAS異なる起源を持っている場合、がある場合には、ASのトランジットによってこのコミュニティの追加は、より具体的な接頭辞のAS起源にサービス拒否攻撃を引き起こす可能性があり。
BGP is already vulnerable to a denial of service attack based on the injection of false routing information. It is possible to use this community to limit the redistribution of a false route entry such that its visibility can be limited and detection and rectification of the problem can be more difficult under the circumstances of limited redistribution.
BGPは、既に偽のルーティング情報の注入に基づいて、サービス拒否攻撃に対して脆弱です。その視認性を制限することができ、問題の検出および整流は限られた再分配の状況下ではより困難になることができるような誤ったルートエントリの再配布を制限するために、このコミュニティを使用することが可能です。
[1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[1] Chandrasekeran、R.、Trainaの、P.およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[2] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[2]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
Geoff Huston Telstra
ジェフ・ヒューストンテルストラ
EMail: gih@telstra.net
メールアドレス：gih@telstra.net
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。