RFC 8642 既知のBGPコミュニティのポリシーの動作

この文書はRFC8642の日本語訳です。この文書の翻訳内容の正確さは保障できないため、正確な知識を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Internet Engineering Task Force (IETF) J. Borkenhagen
Request for Comments: 8642 AT&T
Updates: 1997 R. Bush
Category: Standards Track IIJ & Arrcus
ISSN: 2070-1721 R. Bonica
Juniper Networks
S. Bayraktar
Cisco Systems
August 2019

Policy Behavior for Well-Known BGP Communities
既知のBGPコミュニティのポリシーの動作

Abstract
概要

Well-known BGP communities are manipulated differently across various
current implementations, resulting in difficulties for operators.
Network operators should deploy consistent community handling across
their networks while taking the inconsistent behaviors from the
various BGP implementations into consideration. This document
recommends specific actions to limit future inconsistency: namely,
BGP implementors must not create further inconsistencies from this
point forward. These behavioral changes, though subtle, actually
update RFC 1997.
既知BGPコミュニティは、現在のさまざまな実装で異なる方法で操作されるた
め、オペレーターにとっては困り者です。ネットワークオペレータは、さま
ざまなBGP実装の一貫性のない動作を考慮しながら、ネットワーク全体で一貫
したコミュニティ処理を展開する必要があります。この文書では、将来の不
整合を制限するための特定の動作を推奨しています：つまり、BGP実装者は、
これ以降、さらに不整合を作ってはなりません。これらの動作の変更は、わ
ずかではありますが、実際にはRFC 1997を更新しています。

Status of This Memo
この文書の状態

This is an Internet Standards Track document.
この文書はインターネット標準化作業中です。

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネット技術特別調査委員会（IETF）の成果です。IETF会
員の合意を表しています。これは公開レビューを受けており、インターネッ
ト技術運営委員会（IESG）による公開が承認されています。インターネット
標準の詳細については、RFC 7841の２章を参照してください。

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8642.
この文書の現在の状態、誤記、評価に関する情報は、
http：//www.rfc-editor.org/info/rfc8642で入手できます。

Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
著作権（Ｃ）２０１９、IETF信託と文書の著者と認識される人々。す
べての権利は当方に帰属します。

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
この文書はこの文書の公開日に有効なBCP 78とIETF信託のIETF文書に関連
する法的条項（http://trustee.ietf.org/license-info）の対象となりま
す。これらの文書は、この文書に関するあなたの権利と制限を説明してい
るので、注意深く確認してください。この文書内のプログラムコードの利
用には、IETF信託の法的条項の4.e章に記載されているSimplified BSD
Licenseテキストを含める必要があり、Simplified BSD Licenseに記載さ
れている保証なしで提供されます。

Table of Contents
目次

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Manipulation of Communities by Policy . . . . . . . . . . . . 3
3. Community Manipulation Policy Differences . . . . . . . . . . 3
4. Documentation of Vendor Implementations . . . . . . . . . . . 4
4.1. Note on an Inconsistency . . . . . . . . . . . . . . . . 5
5. Note for Those Writing RFCs for New Community-Like Attributes 5
6. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction
1. はじめに

The BGP Communities attribute was specified in [RFC1997], which
introduced the concept of well-known communities. In hindsight,
[RFC1997] did not prescribe as fully as it should have how well-known
communities may be manipulated by policies applied by operators.
Currently, implementations differ in this regard, and these
differences can result in inconsistent behaviors that operators find
difficult to identify and resolve.
[RFC1997]でBGP Communities属性が指定され、既知コミュニティの概念が導入
されました。後から考えると[RFC1997]は、オペレーターが適用したいポリシー
によって既知コミュニティがどのように操作されるかについて、完全に規定し
ていませんでした。現在、この点は実装によって異なり、これらの違いは一貫
性のない動作をもたらす可能性があり、オペレータが識別して解決するのが難
しいと感じます。

This document describes the current behavioral differences in order
to assist operators in generating consistent community-manipulation
policies in a multi-vendor environment and to prevent the
introduction of additional divergence in implementations.
この文書では、マルチベンダー環境で、オペレータが一貫したコミュニティ
操作ポリシーを生成し、実装にさらなる差異が導入されないようにするため
に、現在の動作の違いについて説明します。

This document recommends specific actions to limit future
inconsistency: namely, BGP implementors MUST NOT create further
inconsistencies from this point forward.
この文書は、将来の不整合を制限するための特定の動作を推奨します。つま
り、BGP実装者は、この時点からさらなる不整合を作成してはなりません(MUST NOT)。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
本書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"NOT RECOMMENDED"
と"MAY"と"OPTIONAL"はBCP 14 [RFC2119] [RFC8174] で説明されるように解
釈されるべきです。

2. Manipulation of Communities by Policy
2. ポリシーによるコミュニティの操作

[RFC1997] says:
[RFC1997]の記述：

A BGP speaker receiving a route with the COMMUNITIES path
attribute may modify this attribute according to the local policy.
COMMUNITIESパス属性を持つ経路を受信するBGPスピーカーは、
ローカルポリシーに従ってこの属性を変更できます。

One basic operational need is to add or remove one or more
communities to or from the set. The focus of this document is
another common operational need: to replace all communities with a
new set. To simplify this second case, most BGP policy
implementations provide a syntax to "set" a community that operators
use to mean "remove any/all communities present on the route and
apply this set of communities instead".
基本的な運用上の要請の1つは、セットからの1つ以上のコミュニティの追加
や削除です。この文書の焦点は、もう1つの一般的な運用上の要請です：
すべてのコミュニティを新しいセットに置き換えること。この2番目のケース
を簡素化するために、ほとんどのBGPポリシー実装は、オペレーターが
「経路に存在するすべて/すべてのコミュニティを削除し、代わりにこの
コミュニティセットを適用する」ことを意味するコミュニティ"set"構文
を提供します。

Some operators prefer to write explicit policy to delete unwanted
communities rather than use "set", i.e., using "delete community *:*"
and then "add community x:y ..." configuration statements in an
attempt to replace all communities. The same community-manipulation
policy differences described in the following section exist in the
syntax for both "set" and "delete community *:*". For simplicity,
the remainder of this document refers only to the "set" behaviors,
which we refer to collectively as each implementation's '"set"
directive'.
一部のオペレーターは"set"を使用するのではなく、不要なコミュニティを
削除する明示的なポリシーを作成することを好みます、つまり、すべての
コミュニティを置き換えるのに"delete community *:*"構文を使用し、
"add community x:y ..."構文使用します。"set"と"delete community *:*"
の両方の構文には、次章で説明する同じコミュニティ操作ポリシーの違い
があります。簡単化のために、この文書の残りの部分では、"set"動作のみ
を参照します。これは、各実装の「"set"命令」と総称します。

3. Community Manipulation Policy Differences
3. コミュニティ操作ポリシーの違い

Vendor implementations differ in the treatment of certain well-known
communities when modified using the syntax to "set" the community.
Some replace all communities, including the well-known ones, with the
new set; others replace all non-well-known communities but do not
modify any well-known communities that are present.
"set"構文でコミュニティを変更する場合、ベンダーの実装により、特定の
既知のミュニティの扱いが異なります。いくつかは既知コミュニティを含む
すべてのコミュニティを新しいセットで置き換えます；その他は、すべての
非既知コミュニティを置き換えますが、存在する既知コミュニティを変更し
ません。

These differences result in what would appear to be identical policy
configurations having very different results on different platforms.
これらの違いにより、同一のポリシー設定と思われるものが、異なるプラッ
トフォーム上で非常に異なる結果になります。

4. Documentation of Vendor Implementations
4. ベンダー実装の文書化

In this section, we document the syntax and observed behavior of the
"set" directive in several popular BGP implementations to illustrate
the severity of the problem operators face.
この章では、いくつかの一般的なBGP実装の"set"命令の構文と観察された動
作を文書化し、オペレーターが直面する問題の重大度を示します。

In Juniper Networks' Junos OS, "community set" removes all
communities, well-known or otherwise.
ジュニパーネットワークスのJunos OSでは、"community set"により、既知や
その他のすべてのコミュニティが削除されます。

In Cisco IOS XR, "set community" removes all communities except for
the following:
Cisco IOS XRでは、"set community"は次を除くすべてのコミュニティを削除
します。

+-------------+-----------------------------------+
| Numeric | Common Name |
+-------------+-----------------------------------+
| 0:0 | internet |
| 65535:0 | graceful-shutdown |
| 65535:1 | accept-own rfc7611 |
| 65535:65281 | NO_EXPORT |
| 65535:65282 | NO_ADVERTISE |
| 65535:65283 | NO_EXPORT_SUBCONFED (or local-AS) |
+-------------+-----------------------------------+

Table 1: Communities Not Removed by Cisco's IOS XR
表１：Cisco IOS XRで削除されないコミュニティ

Cisco IOS XR allows well-known communities to be removed only by
explicitly enumerating one at a time and not in the aggregate -- for
example, "delete community accept-own". Operators are advised to
consult Cisco IOS XR documentation and/or Cisco support for full
details.
Cisco IOS XRでは、既知コミュニティを削除するには、一度に１つづつ明示
的に列挙する必要はあり、まとめてできません、例えば
"delete community accept-own"。詳細は、Cisco IOS XRのドキュメントま
たはシスコサポートを参照することをお勧めします。

On Extreme networks' Brocade NetIron, "set community X" removes all
communities and sets X.
ExtremeネットワークのBrocade NetIronでは、"set community X"はすべての
コミュニティを削除し、Xを設定します。

In Huawei's VRP product, "community set" removes all communities,
well-known or otherwise.
HuaweiのVRP製品では、"community set"により、既知またはその他のすべて
のコミュニティが削除されます。

In OpenBGPD, "set community" does not remove any communities, well-
known or otherwise.
OpenBGPDでは、"set community"は、既知コミュニティまたはその他のコミュ
ニティを削除しません。

Nokia's SR OS has several directives that operate on communities.
Its "set" directive is called using the "replace" keyword, replacing
all communities, well-known or otherwise, with the specified
communities.
NokiaのSR OSは、コミュニティに機能するいくつかの命令があります。
"replace"キーワードを使用した"set"命令は、既知またはその他のすべて
のコミュニティを指定されたコミュニティに置き換えます。

4.1. Note on an Inconsistency
4.1. 不整合に関する注意

IANA publishes a list of well-known communities [IANA-WKC].
IANAは、既知コミュニティのリスト[IANA-WKC]を公開しています。

Cisco IOS XR's set of well-known communities that "set community"
will not overwrite diverges from the IANA's list of well-known
communities. Quite a few well-known communities from IANA's list do
not receive special treatment in Cisco IOS XR, and at least one
community on Cisco IOS XR's special treatment list, internet == 0:0,
is not formally a well-known community as it is not in [IANA-WKC] (it
is taken from the Reserved range [0x00000000-0x0000FFFF]).
"set community"でのCisco IOS XRの既知のコミュニティの設定は、IANAの
既知コミュニティのリストにあるコミュニティを上書きしません。 IANAの
リストの中の少数の既知コミュニティはCisco IOS XRで特別な扱いを受けて
おらず、Cisco IOS XRの特別扱いリストの少なくとも1つのコミュニティ、
internet == 0:0は[IANA-WKC]に無いので、正式な既知コミュニティではあ
りません（予約範囲[0x00000000-0x0000FFFF]の一部です）。

This merely notes an inconsistency. It is not a plea to protect the
entire IANA list from "set community".
これは単に矛盾を示しているだけです。"set community"でIANAリスト全体
を保護することは要請ではありません。

5. Note for Those Writing RFCs for New Community-Like Attributes
5. 新しいコミュニティの様な属性のRFCを作る場合の注意

When establishing new attributes similar to those in [RFC1997] (large
communities, wide communities, etc.), RFC authors should state
explicitly how the new attribute is to be handled.
[RFC1997]の属性（大規模コミュニティ、広域コミュニティなど）と同様の新
しい属性を定義する場合、RFCの作者は、新しい属性の処理方法を明示的に述
べる必要があります。

6. Action Items
6. アクションアイテム

Network operators are encouraged to limit their use of the "set"
directive (within reason) to improve consistency across platforms.
ネットワークオペレータは、プラットフォーム間の一貫性を改善するために、
"set"命令の使用を（理由で示した範囲内で）制限することが推奨されます。

Unfortunately, it would be operationally disruptive for vendors to
change their current implementations.
残念ながら、ベンダーが現在の実装を変更すると、運用上混乱が生じます。

Vendors MUST clearly document the behavior of the "set" directive in
their implementations.
ベンダーは、実装内の"set"ディレクティブの動作を明確に文書化する必要が
あります(MUST)。

Vendors MUST ensure that their implementations' "set" directive
treatment of any specific community does not change if/when that
community becomes a new well-known community through future
standardization. For most implementations, this means that the "set"
directive MUST continue to remove the community; for those
implementations where the "set" directive removes no communities,
that behavior MUST continue.
ベンダーは、将来の標準化により特定のコミュニティが新しい既知コミュ
ニティになった場合に、実装の"set"命令のそのコミュニティに対する処
理が変更されないことを保証しなければなりません(MUST)。ほとんどの実
装で、これは、"set"命令がコミュニティを削除し続けなければならない
(MUST)ことを意味します。"set"命令がコミュニティを削除しない実装の
場合、その動作を継続する必要があります(MUST)。

Given the implementation inconsistencies described in this document,
network operators are urged never to rely on any implicit
understanding of a neighbor ASN's BGP community handling. That is,
before announcing prefixes with NO_EXPORT or any other community to a
neighbor ASN, the operator should confirm with that neighbor how the
community will be treated.
この文書で説明されている実装の不一致を考えると、ネットワークオペレー
タに対し、通信相手のASNのBGPコミュニティ処理について思い込みで対応しな
いように勧めます。つまり、NO_EXPORTまたは他のコミュニティのプレフィッ
クスを通信相手のASNに広告する前に、オペレーターは通信相手のコミュニ
ティの処理方法を確認する必要があります。

7. Security Considerations
7. セキュリティの考察

Surprising defaults and/or undocumented behaviors are not good for
security. This document attempts to remedy that.
驚くべきデフォルトや文書化されていない動作は、セキュリティ上よくあり
ません。この文書はこれを改善しようとします。

8. IANA Considerations
8. IANAの考慮事項

The IANA has listed this document as an additional reference for the
[IANA-WKC] registry.
IANAは、この文書を[IANA-WKC]レジストリの追加リファレンスとしてリスト
しています。

9. Normative References
9. 引用参考文献

[IANA-WKC] IANA, "Border Gateway Protocol (BGP) Well-known
Communities", <https://www.iana.org/assignments/
bgp-well-known-communities>.

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgments
謝辞

The authors thank Martijn Schmidt and Qin Wu for the Huawei data
point as well as Greg Hankins, Job Snijders, David Farmer, John
Heasley, and Jakob Heitz.
著者は、HuaweiデータポイントのMartijn SchmidtとQin Wuと、
Greg HankinsとJob SnijdersとDavid FarmerとJohn Heasleyと
Jakob Heitzに感謝します。

Authors' Addresses
著者のアドレス

Jay Borkenhagen
AT&T
200 Laurel Avenue South
Middletown, NJ 07748
United States of America

Email: jayb@att.com

Randy Bush
IIJ & Arrcus
5147 Crystal Springs
Bainbridge Island, WA 98110
United States of America

Email: randy@psg.com

Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
United States of America

Email: rbonica@juniper.net

Serpil Bayraktar
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America

Email: serpil@cisco.com

Japanese translation by Ishida So