Network Working Group D. Meyer
Request for Comments: 4384 February 2006
BCP: 114
Category: Best Current Practice
BGP Communities for Data Collection
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors.
BGPコミュニティ（RFC 1997）は、顧客、ピアのタグ付けを含め、多くの目的のためにサービス・プロバイダによって使用され、地理的にルートを発しています。このようなタグ付けは通常、プロバイダのネットワーク内およびその同僚や顧客へのルートの再配布の範囲を制御するために使用されます。大規模BGPデータ収集（および関連する研究）の出現により、そのような社会で運ばれた情報は、グローバルルーティングシステムのより深い理解のために不可欠であることが明らかになりました。このメモは、BGPルートコレクタにエクスポートするための標準（アウトバウンド）コミュニティとそのエンコーディングを定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Peers and Peering ..........................................3
2.2. Customer Routes ............................................3
2.3. Peer Routes ................................................3
2.4. Internal Routes ............................................4
2.5. Internal More Specific Routes ..............................4
2.6. Special Purpose Routes .....................................4
2.7. Upstream Routes ............................................4
2.8. National Routes ............................................4
2.9. Regional Routes ............................................4
3. RFC 1997 Community Encoding and Values ..........................5
4. Community Values for BGP Data Collection ........................5
4.1. Extended Communities .......................................7
4.2. Four-Octet AS Specific Extended Communities ................9
5. Note on BGP UPDATE Packing ......................................9
6. Acknowledgements ................................................9
7. Security Considerations ........................................10
7.1. Total Path Attribute Length ...............................10
8. IANA Considerations ............................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
BGP communities [RFC1997] are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its customers and peers. Communities are also used for a wide variety of other applications, such as allowing customers to set attributes such as LOCAL_PREF [RFC1771] by sending appropriate communities to their service provider. Other applications include signaling various types of Virtual Private Networks (VPNs) (e.g., Virtual Private LAN Service (VPLS) [VPLS]), and carrying link bandwidth for traffic engineering applications [RFC4360].
BGPコミュニティ[RFC1997]は、顧客、ピアのタグ付け、および地理的起源経路を含む多くの目的のためにサービスプロバイダによって使用されています。このようなタグ付けは、通常、プロバイダのネットワーク内とその顧客とピアにルートの再配布の範囲を制御するために使用されます。コミュニティはまた、顧客がサービスプロバイダに適切なコミュニティを送信することにより、このようなLOCAL_PREF [RFC1771]などの属性を設定することが可能などの他のアプリケーションのさまざまなに使用されています。他のアプリケーション（例えば、仮想プライベートLANサービス（VPLS）[VPLS]）、仮想プライベートネットワーク（VPN）の様々なタイプのシグナリング、およびトラフィックエンジニアリングアプリケーション[RFC4360]のリンクの帯域幅を持っています。
With the advent of large-scale BGP data collection [RV] [RIS] (and associated research), it has become clear that the geographical and topological information, as well as the relationship the provider has to the source of a route (e.g., transit, peer, or customer), carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard communities for export to BGP route collectors. These communities represent a significant part of information carried by service providers as of this writing, and as such could be useful for internal use by service providers. However, such use is beyond the scope of this memo. Finally, those involved in BGP data analysis are encouraged to verify with their data sources as to which peers implement this scheme (as there is a large amount of existing data as well as many legacy peerings).
大規模BGPデータ収集[RV] [RIS]（および関連する研究）の出現により、それはプロバイダは、経路（例えばのソースにあり、地理的および位相的な情報ということだけでなく、関係が明らかになってきましたそのような地域で実施トランジット、ピア、または顧客）は、グローバルルーティングシステムのより深い理解のために不可欠です。このメモは、BGPルートコレクターへの輸出のための標準的なコミュニティを定義します。これらのコミュニティはこれを書いているように、サービスプロバイダによって運ばれた情報の重要な部分を表し、そのようにサービスプロバイダによって内部で使用するために有用である可能性があります。しかし、そのような使用は、このメモの範囲を超えています。最後に、BGPのデータ分析に関与したものは、（既存の大量のデータだけでなく、多くのレガシーピアリングがあるので）このスキームを実装するピアにどのよう自分のデータソースと確認することを推奨します。
The remainder of this memo is organized as follows. Section 2 provides the definition of terms used as well as the semantics of the communities used for BGP data collection, and Section 3 defines the corresponding encodings for RFC 1997 [RFC1997] communities. Finally, Section 4 defines the encodings for use with extended communities [RFC4360].
次のように、このメモの残りの部分は構成されています。セクション2は、BGPデータ収集のために使用されるコミュニティの意味論と同様に使用される用語の定義を提供し、第3節では、RFC 1997 [RFC1997]のコミュニティのために、対応するエンコーディングを定義します。最後に、第4の拡張コミュニティ[RFC4360]で使用するためのエンコーディングを定義しています。
In this section, we define the terms used and the categories of routes that may be tagged with communities. This tagging is often referred to as coloring, and we refer to a route's "color" as its community value. The categories defined here are loosely modeled on those described in [WANG] and [HUSTON].
このセクションでは、我々は、使用される用語やコミュニティでタグ付けすることができる経路のカテゴリを定義します。このタグは、多くの場合、着色と呼ばれ、私たちはそのコミュニティ値としてルートの「色」を参照してくださいされています。ここで定義されたカテゴリは緩く[WANG]と[HUSTON]に記載のものをモデルにしています。
Consider two network service providers, A and B. Service providers A and B are defined to be peers when (i) A and B exchange routes via BGP, and (ii) traffic exchange between A and B is settlement-free. This arrangement is also typically known as "peering". Peers typically exchange only their respective customer routes (see "Customer Routes" below), and hence exchange only their respective customer traffic. See [HUSTON] for a more in-depth discussion of the business models surrounding peers and peering.
2つのネットワーク・サービス・プロバイダ、AとBのサービスプロバイダAとBを検討する（I）AおよびBGPを介してB交換経路、およびAとBの間の（ii）のトラフィック交換が決済を含まない場合、ピアになるように定義されています。この配置は、典型的には、「ピアリング」として知られています。ピアは、通常（以下「カスタマー・ルート」を参照）のみ、それぞれの顧客のルートを交換し、それゆえにのみ、それぞれの顧客のトラフィックを交換します。ピアとのピアリングを取り巻くビジネスモデルのより詳細な議論については[HUSTON]を参照してください。
Customer routes are those routes that are heard from a customer via BGP and are propagated to peers and other customers. Note that a customer can be an enterprise or another network service provider. These routes are sometimes called client routes [HUSTON].
カスタマールートは、BGPを介して顧客から聞いていると、同僚や他の顧客に伝播されているそれらのルートです。顧客は、企業や他のネットワーク・サービス・プロバイダになることに注意してください。これらのルートは、時々クライアントルート[HUSTON]と呼ばれています。
Peer routes are those routes heard from peers via BGP, and not propagated to other peers. In particular, these routes are only propagated to the service provider's customers.
ピアルートがBGPを経由してピアから聞いたそれらのルートであり、他のピアに伝播されません。特に、これらの空路は唯一のサービスプロバイダーの顧客に伝達されます。
Internal routes are those routes that a service provider originates and passes to its peers and customers. These routes are frequently taken out of the address space allocated to a provider.
内部ルートは、サービスプロバイダが発信され、その同僚や顧客に渡すそれらのルートです。これらのルートは頻繁にプロバイダに割り当てられたアドレス空間から取り出しています。
Internal more specific routes are those routes that are frequently used for circuit load balancing purposes and Interior Gateway Protocol (IGP) route reduction. They also may correspond to customer services that are not visible outside the service provider's network. Internal more specific routes are not exported to any external peer.
内部より具体的なルートは、しばしば、回路の負荷分散を目的とインテリアゲートウェイプロトコル（IGP）ルート還元のために使用されるそれらのルートです。彼らはまた、サービスプロバイダのネットワークの外に表示されていない顧客サービスに対応してもよいです。内部より具体的なルートは、任意の外部ピアにエクスポートされません。
Special purpose routes are those routes that do not fall into any of the other classes described here. In those cases in which such routes need to be distinguished, a service provider may color such routes with a unique value. Examples of special purpose routes include anycast routes and routes for overlay networks.
特別目的のルートは、ここで説明する他のクラスのいずれにも該当しないそれらのルートです。そのような経路を区別する必要のあるような場合、サービスプロバイダは、固有の値を持つような経路を着色してもよいです。特別な目的の経路の例には、エニーキャストルートやオーバーレイネットワークのための経路が含まれます。
Upstream routes are typically learned from an upstream service provider as part of a transit service contract executed with the upstream provider.
上流経路は、典型的には、上流のプロバイダに実行トランジットサービス契約の一部として、上流のサービスプロバイダから学習されます。
These are route sets that are sourced from and/or received within a particular country.
これらはから供給及び/又は特定の国内に受信された経路のセットです。
Several global backbones implement regional policy based on their deployed footprint and on strategic and business imperatives. Service providers often have settlement-free interconnections with an Autonomous System (AS) in one region, and that same AS is a customer in another region. This mandates use of regional routing, including community attributes set by the network in question to allow easy discrimination among regional routes. For example, service providers may treat a route set received from another service provider in Europe differently than the same route set received in North America, as it is common practice to sell transit in one region while peering in the other.
いくつかの世界的なバックボーンは、彼らの展開フットプリントにし、戦略的なビジネスの要請に基づき、地域政策を実施します。サービスプロバイダは、多くの場合、1つの地域の自律システム（AS）との和解のない相互接続を持っている、そしてその同じASは、他の地域での顧客です。これは、地域の経路のうち簡単な区別を可能にするために、問題のネットワークによって設定された属性のコミュニティを含む地域のルーティングの使用を義務付け。例えば、サービスプロバイダは、他にピアリングしながら、一方の領域でのトランジットを販売するのが一般的であるように、異なった北米で受信した同一ルートセットよりもヨーロッパでは、別のサービスプロバイダから受信した経路セットを扱うことがあります。
In this section, we provide RFC 1997 [RFC1997] community values for the categories described above. RFC 1997 communities are encoded as BGP Type Code 8, and are treated as 32-bit values ranging from 0x0000000 through 0xFFFFFFF. The values 0x0000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are reserved.
このセクションでは、我々は、上記のカテゴリのRFC 1997 [RFC1997]のコミュニティ値を提供します。 RFC 1997人のコミュニティはBGPタイプコード8としてエンコードされ、0x0000000から0xFFFFFFFまでの範囲の32ビット値として扱われています。 0xFFFFFFFFを通じ0x0000FFFFとを0xFFFF0000までの値0x0000000が予約されています。
The best current practice among service providers is to use the high-order two octets to represent the provider's AS number, and the low-order two octets to represent the classification of the route, as depicted below:
サービスプロバイダーの中で最高の現在のプラクティスは、下に示されているように、ルートの分類を表すために、プロバイダのAS番号、および下位の2つのオクテットを表すために、上位2つのオクテットを使用することです：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <AS> | <Value> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where <AS> is the 16-bit AS number. For example, the encoding 0x2A7C029A would represent the AS 10876 with value 666.
ここで、<AS> AS番号16ビットです。例えば、符号化0x2A7C029A値666とAS 10876を表します。
In this section, we define the RFC 1997 community encoding for the route types described above for use in BGP data collection. It is anticipated that a service provider's internal community values will be converted to these standard values for output to a route collector.
このセクションでは、BGPデータ収集で使用するために、上記のルートタイプのRFC 1997のコミュニティのエンコーディングを定義します。サービスプロバイダの内部のコミュニティ値がルートコレクタに出力するために、これらの標準値に変換されることが予想されます。
This memo follows the best current practice of using the basic format <AS>:<Value>. The values for the route categories are described in the following table:
<値>：このメモは、基本フォーマット<AS>を使用しての現在のベストプラクティスに従っています。ルートカテゴリの値は次の表に記載されています。
Category Value
===============================================================
Reserved <AS>:0000000000000000
Customer Routes <AS>:0000000000000001
Peer Routes <AS>:0000000000000010
Internal Routes <AS>:0000000000000011
Internal More Specific Routes <AS>:0000000000000100
Special Purpose Routes <AS>:0000000000000101
Upstream Routes <AS>:0000000000000110
Reserved <AS>:0000000000000111-
<AS>:0000011111111111
National and Regional Routes <AS>:0000100000000000-
<AS>:1111111111111111
Encoded as <AS>:<R><X><CC>
Reserved National and Regional values <AS>:0100000000000000-
<AS>:1111111111111111
Where
どこ
<AS> is the 16-bit AS <R> is the 5-bit Region Identifier <X> is the 1-bit satellite link indication X = 1 for satellite links, 0 otherwise <CC> is the 10-bit ISO-3166-2 country code [ISO3166]
AS 16ビットである<AS> <R>は5ビットの地域識別子である<X> 1ビット衛星リンク指示衛星リンク用X = 1、0は、そうでなければ、<CC>は10ビットのISO-3166であります-2国コード[ISO3166]
and <R> takes the values:
そして、<R>は値をとります。
Africa (AF) 00001 Oceania (OC) 00010 Asia (AS) 00011 Antarctica (AQ) 00100 Europe (EU) 00101 Latin America/Caribbean Islands (LAC) 00110 North America (NA) 00111 Reserved 01000-11111
アフリカ（AF）00001オセアニア（OC）00010・アジア（AS）00011南極（AQ）00100ヨーロッパ（EU）00101ラテンアメリカ/カリブ海諸島（LAC）00110北米（NA）00111予約済み01000から11111
That is:
あれは：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <AS> | <R> |X| <CC> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For example, the encoding for a national route over a terrestrial link in AS 10876 from the Fiji Islands would be:
例えば、フィジー諸島からAS 10876で、地上リンク上で国道のエンコーディングは、次のようになります。
<AS> = 10876 = 0x2A7C <R> = 00010 <X> = 0 <CC> = Fiji Islands Country Code = 242 = 0011110010
<AS> = 10876 = 0x2A7C <R> = 00010 <X> = 0 <CC>は=フィジー諸島国コード= 242 = 0011110010
In this case, the low-order 16 bits are 0001000011110010 = 0x10F2.
この場合、下位16ビットが0001000011110010 = 0x10F2あります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2A7C | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that a configuration language might allow the specification of this community as 10876:4338 (0x10F2 == 4338 decimal).
4338（0x10F2 == 4338 10進数）：設定言語が10876としてこのコミュニティの仕様を許す可能性があることに注意してください。
Finally, note that these categories are not intended to be mutually exclusive, and multiple communities can be attached where appropriate.
最後に、これらのカテゴリは相互に排他的であることが意図されていないことに注意し、複数のコミュニティには、適切な場合に添付することができます。
In some cases, the values and their encoding described in Section 4 may clash with a service provider's existing community assignments. Extended communities [RFC4360] provide a convenient mechanism that can be used to avoid such clashes.
いくつかのケースでは、第4章で説明した値とそのエンコーディングは、サービスプロバイダーの既存のコミュニティの割り当てと衝突することがあります。拡張コミュニティ[RFC4360]は、そのような衝突を回避するために使用することができる便利なメカニズムを提供します。
The Extended Communities attribute is a transitive optional BGP attribute with the Type Code 16 and consists of a set of extended communities of the following format:
拡張コミュニティ属性タイプコード16で推移オプションのBGP属性であり、次のフォーマットの拡張コミュニティのセットで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low(*) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For purposes of BGP data collection, we encode the communities described in Section 4 using the two-octet AS specific extended community type, which has the following format:
BGPデータ収集の目的のために、私たちは次の形式を持っている2オクテットAS固有の拡張コミュニティタイプを使用して、第4節で説明したコミュニティをエンコードします：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | Sub-Type | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The two-octet AS specific extended community attribute encodes the service provider's two-octet Autonomous System number (as assigned by a Regional Internet Registry, or RIR) in the Global Administrator field, and the Local Administrator field may encode any information.
2オクテットAS固有の拡張コミュニティ属性は、サービスプロバイダーのグローバル管理者フィールドに2オクテット自律システム番号（地域インターネットレジストリ、またはRIRによって割り当てられた）、およびローカル管理者フィールドは任意の情報を符号化することができる符号化します。
This memo assigns Sub-Type 0x0008 for BGP data collection, and specifies that the <Value> field, as defined in Section 3.1, is carried in the low-order octets of the Local Administrator field. The two high-order octets of the Local Administrator field are reserved, and are set to 0x00 when sending and ignored upon receipt.
このメモは、BGPデータ収集のためのサブタイプ0x0008でを割り当て、<値>フィールドは、3.1節で定義されるように、ローカル管理者フィールドの下位オクテットに運ばれることを指定します。ローカル管理者フィールドの上位2オクテットは予約されており、送信時に0x00に設定し、受信時に無視されます。
For example, the extended community encoding for 10876:4338 (representing a terrestrial national route in AS 10876 from the Fiji Islands) would be:
例えば、10876の拡張コミュニティをコード：（フィジーからAS 10876で地上波国道を表す）4338は次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x0008 | 0x2A7C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The four-octet AS specific extended community is encoded as follows:
以下のように4オクテットAS固有の拡張コミュニティが符号化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case, the four-octet Global Administrator sub-field contains a four-octet Autonomous System number assigned by the IANA.
この場合には、4オクテットグローバル管理者サブフィールドは、IANAによって割り当てられた4オクテット自律システム番号を含みます。
Note that data collection communities have the potential of making the attribute set of a specific route more unique than it would be otherwise (since each route collects data that is specific to its path inside one or more ASes). This, in turn, can affect whether multiple routes can be grouped in the same BGP update message, and it may lead to increased use of bandwidth, router CPU cycles, and memory.
そのデータ収集のコミュニティは（各ルートは、1つのまたは複数のAS内のそのパスに固有のデータを収集しているため）、それは本来よりも多くのユニークな特定のルートの属性セットを作成する可能性があります注意してください。これは、順番に、複数のルートが同じBGP更新メッセージにグループ化することができるかどうかに影響を与えることができ、そしてそれは、帯域幅、ルータのCPUサイクル、およびメモリの使用の増加につながる可能性があります。
The community encoding described in this memo germinated from an interesting suggestion from Akira Kato at WIDE. In particular, the idea would be to use the collection community values to select paths that would result in (hopefully) more efficient access to various services. For example, in the case of RFC 3258 [RFC3258] based DNS anycast service, BGP routers may see multiple paths to the same prefix, and others might be coming from the same origin with different paths, but others might be from different region/country (with the same origin AS).
このメモで説明するコミュニティのエンコーディングはWIDEでアキラ加藤から興味深い提案から発芽しました。具体的には、アイデアはさまざまなサービスに（たぶん）より効率的なアクセスにつながるパスを選択するために、コレクションのコミュニティ値を使用することです。例えば、[RFC3258]ベースのDNSエニーキャストサービスRFC 3258の場合には、BGPルータは同じプレフィックスを複数のパスが表示されることがあり、そして他のものは、異なる経路で同一の起源に由来するかもしれないが、他のものは、異なる地域/国からかもしれません（同じ起源ASを持ちます）。
Joe Abley, Randy Bush, Sean Donelan, Xenofontas Dimitropoulos, Vijay Gill, John Heasley, Geoff Huston, Steve Huter, Michael Patton, Olivier Marce, Ryan McDowell, Rob Rockell, Rob Thomas, Pekka Savola, Patrick Verkaik, and Alex Zinin all made many insightful comments on early versions of this document. Henk Uijterwaal suggested the use of the ISO-3166-2 country codes.
すべて作られたジョーAbley、ランディブッシュ、ショーンDonelan、Xenofontas Dimitropoulos、ビジェイ・ギル、ジョンHeasley、ジェフ・ヒューストン、スティーブHuter、マイケル・パットン、オリヴィエMarce、ライアン・マクダウェル、ロブロッケル、ロブ・トーマス、ペッカSavola、パトリックVerkaik、およびアレックスジニンこのドキュメントの初期バージョンに多くの洞察に満ちたコメント。ヘンクUijterwaalはISO-3166-2国コードを使用することを示唆しました。
While this memo introduces no additional security considerations into the BGP protocol, the information contained in the communities defined in this memo may in some cases reveal network structure that was not previously visible outside the provider's network. As a result, care should be taken when exporting such communities to route collectors. Finally, routes exported to a route collector should also be tagged with the NO_EXPORT community (0xFFFFFF01).
このメモは、BGPプロトコルに追加のセキュリティ問題を導入しないが、このメモで定義されたコミュニティに含まれる情報は、いくつかのケースでは、プロバイダのネットワーク外以前に見えなかった網目構造を明らかにすることができます。ルートコレクタに、このようなコミュニティをエクスポートするときその結果、注意が必要です。最後に、ルートコレクタにエクスポート経路もNO_EXPORTコミュニティ（0xFFFFFF01）でタグ付けされるべきです。
The communities described in this memo are intended for use on egress to a route collector. Hence an operator may choose to overwrite its internal communities with the values specified in this memo when exporting routes to a route collector. However, operators should in general ensure that the behavior of their BGP implementation is well-defined when the addition of an attribute causes a PDU to exceed 4096 octets. For example, since it is common practice to use community attributes to implement policy (among other functionality such as allowing customers to set attributes such as LOCAL_PREF), the behavior of an implementation when the attribute space overflows is crucial. Among other behaviors, an implementation might usurp the intended attribute data or otherwise cause indeterminate failures. These behaviors can result in unanticipated community attribute sets, and hence result in unintended policy implications.
このメモに記載のコミュニティは、ルートコレクタ出力での使用のために意図されています。したがって、オペレータは、ルートコレクタへのルートをエクスポートする際に、このメモで指定された値とその内部コミュニティを上書きすることを選択することができます。しかし、事業者は、一般的には、属性の追加が4096個のオクテットを超えるPDUを起こしたときに彼らのBGPの実装の振る舞いが明確に定義されていることを確認する必要があります。例えば、コミュニティが属性空間オーバーフローが重要である場合、（そのような顧客は、このようなLOCAL_PREFなどの属性を設定できるようにするなど、他の機能の中で）実装の振る舞いをポリシーを実装するために属性を使用するのが一般的であるため。他の行動の中で、実装が意図した属性データを奪うか、そうでない場合は、不確定の障害を引き起こす可能性があります。これらの動作は、予期せぬコミュニティ属性セットになり、ひいては意図しない政策的含意をもたらす可能性があります。
This memo assigns a new Sub-Type for the AS specific extended community type in the First Come First Served extended transitive category. The IANA has assigned Sub-Type 0x0008 as defined in Section 4.1.
このメモは、まず、拡張推移カテゴリを添え先着でAS特定拡張コミュニティのタイプのための新しいサブタイプを割り当てます。セクション4.1で定義されているIANAは、サブタイプ0x0008でを割り当てています。
In addition, the IANA has created two registries for BGP Data Collection Communities, one for standard communities and one for extended communities. Both of these registries will initially be populated by the values described in Section 4. IETF Consensus, as described in [RFC2434], usually through the Global Routing Operations Working Group (grow), is required for the assignment of new values in these registries (in particular, for <Value> or <R> in the table of values for the route categories in Section 4).
また、IANAは、BGPデータ収集のコミュニティのための2つのレジストリ、標準コミュニティ用と拡張コミュニティのための1つを作成しました。これらのレジストリの両方は、通常、グローバルルーティングオペレーションワーキンググループを通じて、[RFC2434]に記載されているように、最初に、（成長）、第4 IETF合意に記載の値によってポピュレートされる（これらのレジストリに新しい値を割り当てるために必要とされます特に、<値>または<R>）セクション4におけるルートカテゴリの値の表です。
[ISO3166] "ISO 3166 Maintenance agency (ISO 3166/MA)", Web Page: http://www.iso.org/iso/en/prods-services/ iso3166ma/index.html, 2004.
[ISO3166] "ISO 3166のメンテナンス機関（ISO 3166 / MA）"、ウェブページ：http://www.iso.org/iso/en/prods-services/ iso3166ma / index.htmlを、2004年。
[RFC1771] Rekhter, Y. and T. Li (Editors), "A Border Gateway Protocol (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李（編集者）、 "ボーダーゲートウェイプロトコル（BGP-4）"、RFC 1771、1995年3月。
[RFC1997] Chandra, R. and P. Traina, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997]チャンドラ、R.とP. Trainaの、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, January 2006.
[RFC4360]サングリ、S.、タッパン、D.、およびY. Rekhterは、RFC 4360、2006年1月の "BGP拡張コミュニティ属性"。
[HUSTON] Huston, G., "Interconnection, Peering, and Settlements", http://www.isoc.org/inet99/proceedings/1e/1e_1.htm
【HUSTON]ヒューストン、G.、 "相互接続、ピアリング、及び決済"、http://www.isoc.org/inet99/proceedings/1e/1e_1.htm
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.、およびH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3258]ハーディ、T.、 "共有ユニキャストアドレスを経由して権威ネームサーバの配布"、RFC 3258、2002年4月。
[RIS] "The RIPE Routing Information Service", Web Page: http://www.ripe.net/ris, 2004.
[RIS] "RIPEルーティング情報サービス"、Webページ：http://www.ripe.net/ris、2004。
[RV] Meyer, D., "The Routeviews Project", Web Page: http://www.routeviews.org, 2002.
[RV]マイヤー、D.、 "Routeviewsプロジェクト"、Webページ：http://www.routeviews.org、2002。
[VPLS] Kompella, K., et al., "Virtual Private LAN Service", Work in Progress, April 2005.
[VPLS] Kompella、K.、ら、 "仮想プライベートLANサービス"、進歩、2005年4月の作業。
[WANG] Wang, F. and L. Gao, "Inferring and Characterizing Internet Routing Policies", ACM SIGCOMM Internet Measurement Conference 2003.
[WANG]王、F.およびL.ガオ、 "推測し、キャラクタインターネットルーティングポリシー"、ACM SIGCOMMインターネット測定コンファレンス2003。
Author's Address
著者のアドレス
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。