[要約] RFC 4384は、データ収集のためのBGPコミュニティに関する規格であり、BGPルーター間でのデータ収集を容易にするための方法を提供します。目的は、ネットワークトラフィックの分析やトラブルシューティングなどの目的でデータを収集するための効果的な手段を提供することです。
Network Working Group D. Meyer
Request for Comments: 4384 February 2006
BCP: 114
Category: Best Current Practice
BGP Communities for Data Collection
データ収集のためのBGPコミュニティ
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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]などの属性を設定できるようにするなど、さまざまな他のアプリケーションにも使用されます。その他のアプリケーションには、さまざまなタイプの仮想プライベートネットワーク（VPNS）（例えば、仮想プライベートLANサービス（VPLS）[VPLS]）、およびトラフィックエンジニアリングアプリケーションのリンク帯域幅を運ぶ[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は、BGPを介した（i）AとBの交換ルート、および（ii）AとBの間のトラフィック交換が解決されない場合、ピアと定義されます。この配置は、通常「ピアリング」としても知られています。ピアは通常、それぞれの顧客ルートのみを交換し（以下の「顧客ルート」を参照）、したがって、それぞれの顧客トラフィックのみを交換します。ピアやピアリングを取り巻くビジネスモデルのより詳細な議論については、[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.
特別な目的のルートは、ここで説明する他のクラスのいずれにも該当しないルートです。そのようなルートを区別する必要がある場合、サービスプロバイダーはそのようなルートを一意の価値で色付けすることがあります。特別な目的のルートの例には、オーバーレイネットワーク用のAnycastルートとルートが含まれます。
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.
いくつかのグローバルバックボーンは、展開されたフットプリントと戦略的およびビジネス上の命令に基づいて、地域政策を実装しています。サービスプロバイダーは、ある地域の自律システム（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ビット値として扱われます。値0x0000000から0x0000ffffおよび0xffff0000〜0xffffffffは予約されています。
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:
サービスプロバイダーの中で最良の現在の慣行は、高次の2オクテットを使用してプロバイダーのAS番号を表すことと、以下に示すように、ルートの分類を表す低次の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>は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>：<value>を使用する最良の現在のプラクティスに従います。ルートカテゴリの値については、次の表で説明します。
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]
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-11111111
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:
たとえば、フィジー諸島からの10876の地上リンク上の国家ルートのエンコーディングは次のとおりです。
<AS> = 10876 = 0x2A7C
<R> = 00010
<X> = 0
<CC> = Fiji Islands Country Code = 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).
構成言語は、このコミュニティの仕様を10876：4338（0x10f2 == 4338 10進数）として許可する場合があることに注意してください。
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オクテットを特定の拡張コミュニティタイプとして使用して、セクション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オクテットは、グローバル管理者フィールドのサービスプロバイダーの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：4338の拡張コミュニティ（フィジー諸島から10876の地上国家ルートを表す）は次のとおりです。
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オクテットは、次のようにエンコードされます。
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つ以上のASE内のパスに固有のデータを収集するため）。これは、同じ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).
このメモに記載されているコミュニティエンコーディングは、広くてたわごとの興味から興味深い提案から発芽しました。特に、アイデアは、コレクションコミュニティの値を使用して、さまざまなサービスへの（できれば）より効率的なアクセスをもたらすパスを選択することです。たとえば、RFC 3258 [RFC3258]ベースのDNS Anycastサービスの場合、BGPルーターは同じプレフィックスへの複数のパスが表示される場合があり、他のパスは異なるパスを持つ同じ起源から来ている可能性がありますが、他の地域/国からはそうかもしれません。（同じ起源と同じ）。
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.
ジョー・イービー、ランディ・ブッシュ、ショーン・ドネラン、Xenofontas Dimitropoulos、Vijay Gill、John Heasley、Geoff Huston、Steve Huter、Michael Patton、Olivier McDowell、Rob Rockell、Rob Thomas、Pekka Savola、Patrick Verkaik、Alex Zinin and Alex Zininこのドキュメントの初期バージョンに関する多くの洞察に富んだコメント。Henk 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.
このメモで説明されているコミュニティは、出口でルートコレクターに使用することを目的としています。したがって、オペレーターは、ルートコレクターにルートをエクスポートするときに、このメモで指定された値で内部コミュニティを上書きすることを選択できます。ただし、オペレーターは一般に、属性を追加するとPDUが4096オクテットを超えると、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固有の拡張コミュニティタイプに新しいサブタイプを割り当てます。IANAは、セクション4.1で定義されているように、サブタイプ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つは標準コミュニティ向けで、もう1つは拡張コミュニティ向けです。これらのレジストリはどちらも、最初にセクション4で説明されている値が入力されます。これは、[RFC2434]で説明されているように、通常はグローバルルーティング運用ワーキンググループ（成長）を介して、これらのレジストリの新しい値を割り当てるために必要です（成長）。特に、セクション4のルートカテゴリの値の表に<値>または<r>の場合）。
[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）」、Webページ：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. Li（編集者）、「Border Gateway Protocol（BGP-4）」、RFC 1771、1995年3月。
[RFC1997] Chandra, R. and P. Traina, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R。およびP. Traina、「BGP Communities属性」、RFC 1997、1996年8月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, January 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年1月。
[HUSTON] Huston, G., "Interconnection, Peering, and Settlements", http://www.isoc.org/inet99/proceedings/1e/1e_1.htm
[Huston] 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] Hardie、T。、「共有ユニキャストアドレスを介した権威ある名前サーバーの配布」、RFC 3258、2002年4月。
[RIS] "The RIPE Routing Information Service", Web Page: http://www.ripe.net/ris, 2004.
[ris]「熟したルーティング情報サービス」、Webページ：http：//www.ripe.net/ris、2004。
[RV] Meyer, D., "The Routeviews Project", Web Page: http://www.routeviews.org, 2002.
[RV] Meyer、D。、「The Routeviews Project」、Webページ：http：//www.routeviews.org、2002。
[VPLS] Kompella, K., et al., "Virtual Private LAN Service", Work in Progress, April 2005.
[VPLS] Kompella、K.、et al。、「仮想プライベートLANサービス」、2005年4月、進行中の作業。
[WANG] Wang, F. and L. Gao, "Inferring and Characterizing Internet Routing Policies", ACM SIGCOMM Internet Measurement Conference 2003.
[Wang] Wang、F。、およびL. Gao、「インターネットルーティングポリシーの推測と特徴づけ」、ACM Sigcomm Internet Measurement Conference 2003。
Author's Address
著者の連絡先
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。