この文書はRFC3765の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書は範囲制御ボーダーゲートウェイプロトコル（ＢＧＰ）共同体の使
用法を記述します。この周知助言通過共同体は、起点ＡＳが特定の経路が外
部に広告される程度を指定することを許します。特にこの共同体ＮＯＰＥＥ
Ｒ、は起点ＡＳがこの属性を持つ経路が双方のピア接続を越えて広告される
必要がないことを明示することを許します。
1. Introduction
1. はじめに
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.
今日のＢＧＰは、ルーティングシステムの一部に経路を広告することを可能
にする、一般に定義された限定的な種類のメカニズムを持っています。ＮＯ
ＥＸＰＯＲＴ共同体はＢＧＰスピーカが広告が隣接するＡＳにだけ及ぶべき
ことを明示することを許します。プロバイダは一般に隣人にどのように広告
された経路を再広告されるべきか明示することを許す多くの共同体を定義し
ます。現在の運用上の慣習では、このような共同体がＡＳ対ＡＳをベースに
定義され、そしてそれらが隣接ＡＳから渡された経路の再広告の振る舞いに
影響を与えるが、遠隔ＡＳへの通過形式での渡される範囲の定義は許されて
いません。
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.
広告範囲仕様が経路広告の境界線状態を指定することが、ほとんどの使い方
です。仕様は、ＡＳ通過数カウント、対象ＡＳの集合、特定の経路オブジェ
クトの存在、ＡＳ間接続の特定の特徴など、数々の形式を取れます。
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.
ＢＧＰ経路表の分析は、集約経路を広告することに加えてより特定のプレフィッ
クスを広告する技術の重要な用途を明らかにします。この慣習の副作用、イ
ンターネットのＢＧＰ経路表の全体的な増加と、関連したこのようなより特
定のアドレスプレフィックス経路の到達性の動的変更の広域広告の負荷、を
改善する努力で、この文書はより特定の経路表項目が適切な条件下でＢＧＰ
表から捨てられる事を許す通過ＢＧＰ経路属性の使用法を記述します。特に、
この属性、ＮＯＰＥＥＲ、は、２つのＡＳが、プロバイダ／顧客配置を除き、
送信側が全ての配置を維持する状況下で接続しているときに、遠隔ＡＳが経
路オブジェクトを近隣ＡＳに広告しないことを許します。
2. NOPEER Attribute
2. ＮＯＰＥＥＲ属性
This memo defines the use a new well-known bgp transitive community,
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.
この属性の意味はＡＳがこのコミュニティの存在を、ＡＳが経路プレフィッ
クスを全ての外部の個別のピア近隣ＡＳに広告してはならないとの、経路プ
レフィックスの広告の条件通知と解釈するのを許すことです。これはＡＳが
ピアリングセッションからの受信プレフィックスを、個別のピアセッション
とみなしてフィルターする事と整合性があります。
3. Motivation
3. 動機
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].
ＢＧＰ経路表の大きさは１９９８年後半から加速的に増加しました。この文
書の公開時点でＢＧＰ転送表は１１８,０００以上の項目を含んでいます、
そしてこのテーブルの３年間の成長率は１年に１０％より少なくない程度[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.
現在のＢＧＰ経路表の１面は、集約と多くのより特定のアドレスプレフィッ
クスの両方を広告する技術の広範囲にわたる使用です。例えば、テーブルは
プレフィックス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の経路項目が経路表
に共に存在します。全部で、これらのより詳細な経路項目は経路表のおよそ
５１％を占領します、それで経路表の２分の１以上がルーティングシステム
にアドレス到達可能性情報を加えません、しかしその代わりに既存の到達可
能性情報の詳細のよりよいレベルを達成するために使われます。
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.
マルチホームのネットワーク設定で観察された共通条件の１つが、多くの異
なる隣接ＡＳへの外部接続から入ってくるトラフィックの負荷分散の形式で
す。もし、例えば、ＡＳがルーティングベースの負荷分散と、入りトラフィッ
クのマルチ接続間での相互の障害対策ためにマルチホームを望むなら、１つ
の方法はＡＳのいくつかの上流の中継プロバイダに集約アドレスプレフィッ
クスを広告し、そして次に個別の上流のプロバイダにより詳細な広告をする
ことです。このような場合、より特定のアドレスプレフィックス宛のトラ
フィックのすべては、より特定のアドレスプレフィックスを広告した接続で
だけ受け取られるでしょう。より特定の広告の近隣ＢＧＰピアリングセッショ
ンに障害があると、より特定の広告が止み、入りトラフィックが集約の広告
のパスに沿って、届くでしょう。この状態でより特定の経路は遠隔ＡＳで自
動的に集約の存在で包含されません。集約経路と関連した特定の経路の両方
で、全部の外部のＢＧＰルーティングドメインに再分配されます。多くの場
合、特にトラフィックエンジニアリングやサービス回復を望む場合、より特
定の経路はトラフィック識別に関する範囲を大きく越えて再配布されます。
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.
ＢＧＰテーブルの遠隔からの分析がこの設定を観察できる限りにおいて、よ
り特定の項目が直接の集約と同じ起源ＡＳを共有する多数のＢＧＰ転送表の
項目は、全ＦＩＢ項目のおよそ２０％になります。直接の集約とより特定の
経路のＡＳパスの一致により厳しい基準を使うと、より特定の経路を囲むＦ
ＩＢ項目の数はおよそ１４％です。
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.
列挙はそれ以上の再広告分配が必要ないＡＳのリストを指定する周知通過拡
張コミュニティの使用をカバーするでしょう。この方法の欠点は生成ＡＳが
絶えず列挙ＡＳリストを訂正し変更をＡＳ間のトポロジーに反映する必要が
あることで、そうでなければより特定の経路は意図する再広告範囲を超えて
漏れ出すでしょう。分類の方法は、その状態が予想される特定のＡＳを参照
せずに、生成ＡＳが再分配が必要ない状況を指定するのを許します。
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".
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.
この方法はプレフィックスの生成者が、一般に定義されたポリシを経路プレ
フィックスに付与し、ＡＳ間の接続の特徴に基づいて、経路が再度広告され
るべきであることを示すことを、許します。
4. IANA Considerations
4. ＩＡＮＡの考慮
The IANA has registered NOPEER as a well-known community, as defined
in [1], as having global significance.
ＩＡＮＡは、世界的な意味を持つと定義されるように、ＮＯＰＥＥＲを周知
共同体として登録しました。
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
これはＡＳがすべての外部の双方向ピア近隣ＡＳに経路プレフィックスを広
告させないのを許す、経路プレフィックスの再広告の制限です。これはＡＳ
が双方向ピアに関するセッションからの受信プレフィックスをフィルタする
かもしれないという意味と整合します。
5. Security Considerations
5. セキュリティの考察
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.
ＢＧＰは中継プロトコルの１つで、ここで経路情報を受けとり、処理し、転
送します。ＢＧＰは、経路情報の情報生成者や受信者の知識なしに、経路情
報の修正や削除や偽情報の挿入する事に対し、転送のエージェントによる無
権限の情報修正を妨げるために特定のメカニズムを含んでいません。
The NOPEER community does not alter this overall situation concerning
the integrity of BGP as a routing system.
ＮＯＰＲＥＥＲ共同体はルーティングシステムとしてＢＧＰの完全性に関し
てこの全体的な状態を変更しません。
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.
ＮＯＰＥＥＲ共同体の使用は、遠隔ＡＳの生成するアドレスプレフィックス
範囲で、中間者攻撃やセッションハイジャックやサービス妨害攻撃により、
ＢＧＰに追加の攻撃メカニズムを導入する能力を可能性があります。
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.
ＢＧＰは偽経路情報の注射に基づいたサービス妨害攻撃の被害をうけやすい
です。視界を限定するように偽経路項目の再広告を制限するためにこの共同
体を使うことは可能で、限定された再広告下で問題の発見と修正がより難し
くなります。
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
[1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
6.2. Informative References
6.2. 有益な参考文献
[2] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
RFC 3221, December 2001.
7. Author's Address
7. 著者のアドレス
Geoff Huston
Telstra
EMail: gih@telstra.net
8. Full Copyright Statement
8. 著作権表示全文
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.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。