[要約] RFC 3765は、BGPルートのスコープ制御のためのNOPEERコミュニティについての要約です。このRFCの目的は、BGPネットワークでのルートの範囲を制御するためのNOPEERコミュニティの使用方法を提案することです。
Network Working Group G. Huston
Request for Comments: 3765 Telstra
Category: Informational April 2004
NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
ボーダーゲートウェイプロトコル（BGP）ルートスコープ制御のためのNoperコミュニティ
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）The Internet Society（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.
このドキュメントでは、Scope Control Border Gateway Protocol（BGP）コミュニティの使用について説明します。このよく知られているアドバイザリング積極的なコミュニティは、特定のルートを外部的に伝播する程度を指定する起源を許可します。特に、このコミュニティ、Noperは、この属性を持つルートを二国間ピア接続全体に宣伝する必要がないことを指定する原点を許可します。
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から渡されたルートの再承認挙動に影響を与えることを許可しているが、このスコープ定義機能がリモコンへの換算ファッション。
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.
広告範囲の仕様は、ルート伝播の境界条件を指定するのに最も役立ちます。この仕様は、トランジットホップ数、ターゲットASSのセット、特定のルートオブジェクトの存在、またはAS Inter-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.
このメモは、そのような範囲制御のすべての動機に対処しようとせず、特にマルチホミングと交通工学の両方の状況に対処します。一般的に採用されている運用手法は、すべてのマルチホームの隣人への包括的な総ルートを宣伝し、より具体的なルートのコレクションを選択的に宣伝することです。これは、ある程度の失敗を保護するために、目的地ベースのトラフィックエンジニアリングの形を実装します。より具体的なルートは、通常、特定の再分配半径を超えて有用な交通工学の結果をレバーに停止します。そのようなルートをそのような点を超えて分配する必要がないことを助言する手段は、継続的なルートの要因の1つを緩和する上で何らかの価値があることです。テーブルの成長。
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ルート属性の使用。具体的には、この属性であるNoperは、何らかの形でプロバイダー /顧客の取り決めとは異なるため、何らかの形の送信者がすべての配置を維持する条件下で2つのASが相互接続されている場合、隣人にルートオブジェクトを宣伝しないようにリモートを許可します。
This memo defines the use a new well-known bgp transitive community, NOPEER.
このメモは、新しい有名なBGP推移的なコミュニティであるNoperを使用することを定義しています。
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フィルターが受信者が二国間ピアセッションと見なすピアリングセッションで受信されるプレフィックスを受け取ったということです。
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年間の成長率は、缶の傾向率を示しています。年間10％以上の複合成長率と相関する[2]。
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ルーティングテーブルの側面の1つは、集計とより具体的なアドレスプレフィックスの両方を宣伝する手法の広範な使用です。たとえば、テーブルには、プレフィックス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 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.
多数の異なる隣接するお尻への多くの外部接続にわたる入ってくるトラフィックの何らかの形の負荷分散を引き受けることは、マルチホームネットワーク構成で観察された一般的な要件の1つです。たとえば、ルーティングベースのロードバランシングにマルチホーム構成を使用したいAS AS AS AS AS AS ASが、着信トラフィック用の複数アクセス接続間で何らかの形の相互失敗を負担したい場合、同じ集計アドレスを宣伝するための1つのアプローチがあります。多くのアップストリームトランジットプロバイダーにプレフィックスを付け、個々のアップストリームプロバイダーにさらに多くの詳細を宣伝します。このような場合、より具体的なアドレスのプレフィックスに導かれるすべてのトラフィックは、より具体的な宣伝が宣伝されている接続に対してのみ受信されます。より具体的な広告の近隣BGPピアリングセッションが失敗した場合、より具体的に発表されなくなり、その後、着信トラフィックは、包括的な集約の広告に関連するパスに基づいて発信ネットワークに渡されます。この状況では、より具体的なルートは、任意のリモートASに集合体が存在することによって自動的に包含されません。集合体と関連するより具体的なルートの両方が、外部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.
このコンテキストで役立つ可能性のあるプロトコルメカニズムの1つは、広告の発信者が広告の再分配に関する追加の資格を述べることを可能にし、一部のオリジネーターによって指定された基準に基づくさらなる再分配を抑制できるようにすることです。
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を参照することなく、さらなる再分配がアドバイスされない条件を指定することを発信することができます。
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".
ここで説明するアプローチは、再分配境界条件を指定するためのアプローチは、覗き見としての二国間のタイプに基づいています。顧客と見なすことができる場合、もう1つは顧客またはプロバイダーの契約エージェントと見なすことができる場合、関係は顧客のエージェントとしてプロバイダーがルートと関連するポリシーを運ぶ場所です。ルートに関連付けられています。どちらも他者の顧客と見なすことができない場合、関係は二国間ピアリングの1つであり、ルートに関連する再配布ポリシーの他者のエージェントと見なすことはできません。この後者の配置は、一般に「送信者をすべてのピア」関係、または「ピアリング」と呼ぶものと呼ばれます。
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.
このピア境界は、ルート上に起源によって課される追加の到達可能性ポリシーの再分配がもはや課せられていない要件ではない論理的なポイントと見なすことができます。
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 Inter-AS接続の特性に基づいて、ルートを条件付きで再承認する必要があることを示します。
The IANA has registered NOPEER as a well-known community, as defined in [1], as having global significance.
IANAは、[1]で定義されているように、グローバルな重要性があると定義されている、有名なコミュニティとしてNoperを登録しています。
NOPEER (0xFFFFFF04)
noper（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フィルターが受信されたプレフィックスを受け取ったプレフィックスを受け取り、受信者が二国間ピアセッションと見なしていることを受け取ったプレフィックスを受け取ったことが一致しています。
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.
Noperコミュニティは、ルーティングシステムとしての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.
Noper Communityの使用には、リモコン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.
このコミュニティが、カバーする総ルートプレフィックスがないためのトランジットプロバイダーによるルートプレフィックスへの不正な追加により、プレフィックスの到達可能性の拒否に基づいてサービス攻撃の拒否を引き起こす可能性があります。カバーの集合体がある場合でも、より具体的なルートが集合体と同じように異なる起源を持っている場合、より具体的なプレフィックスとしての原点へのサービス拒否攻撃を引き起こす可能性のある交通機関によるこのコミュニティの追加。
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。and T. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[2] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[2] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
Geoff Huston Telstra
ジェフ・ヒューストン・テルストラ
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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://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エディター機能の資金は現在、インターネット協会によって提供されています。