[要約] RFC 5492は、BGP-4での能力広告に関する標準化されたプロトコル仕様です。このRFCの目的は、BGPピア間でのネットワーク機能の交換を容易にすることです。
Network Working Group J. Scudder
Request for Comments: 5492 Juniper Networks
Obsoletes: 3392 R. Chandra
Category: Standards Track Sonoa Systems
February 2009
Capabilities Advertisement with BGP-4
BGP-4の機能広告
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
このドキュメントでは、BGPのピアリングを終了することを要求することなく優雅な機能広告を提供することにより、ボーダーゲートウェイプロトコル（BGP）に新しい機能の導入を促進することが期待される、機能と呼ばれるオプションのパラメーターを定義します。
This document obsoletes RFC 3392.
このドキュメントは、RFC 3392を廃止します。
The base BGP-4 specification [RFC4271] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate the BGP peering. This complicates the introduction of new capabilities in BGP.
ベースBGP-4仕様[RFC4271]では、BGPスピーカーが1つ以上の認識されていないオプションパラメーターを使用して開かれたメッセージを受信する場合、スピーカーはBGPピアリングを終了する必要があります。これにより、BGPへの新しい機能の導入が複雑になります。
This specification defines an Optional Parameter and processing rules that allow BGP speakers to communicate capabilities in an OPEN message. A pair of BGP speakers that supports this specification can establish the peering even when presented with unrecognized capabilities, so long as all capabilities required to support the peering are supported.
この仕様は、BGPスピーカーがオープンメッセージで機能を通信できるようにするオプションのパラメーターと処理ルールを定義します。この仕様をサポートするBGPスピーカーのペアは、ピアリングをサポートするために必要なすべての機能がサポートされている限り、認識されていない機能が提示された場合でもピアリングを確立できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
When a BGP speaker [RFC4271] that supports capabilities advertisement sends an OPEN message to its BGP peer, the message MAY include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
機能広告をサポートするBGPスピーカー[RFC4271]がBGPピアに開かれたメッセージを送信する場合、メッセージには機能と呼ばれるオプションのパラメーターが含まれる場合があります。パラメーターは、スピーカーによってサポートされる機能をリストします。
A BGP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer.
BGPスピーカーは、スピーカーがピアから受け取るオープンメッセージによって伝達される機能に存在する機能に存在する機能のリストを調べることにより、ピアによってサポートされる機能を決定します。
A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines (as described above) that the peer supports this capability. Simply put, a given capability can be used on a peering if that capability has been advertised by both peers. If either peer has not advertised it, the capability cannot be used.
特定の機能をサポートするBGPスピーカーは、スピーカーが（上記のように）この機能がこの機能をサポートすると判断した後、ピアでこの機能を使用する場合があります。簡単に言えば、その機能が両方のピアによって宣伝されている場合、特定の機能をピアリングに使用できます。いずれかのピアがそれを宣伝していない場合、機能を使用できません。
A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter.
BGPスピーカーは、PEERが機能をサポートしていないと判断します。機能オプションのパラメーターを搭載する機能を搭載しているオープンメッセージに応じて、スピーカーがサポートされていないオプションパラメーターに設定されたエラーサブコードを使用して通知メッセージを受信します。（これは、ベースBGP-4仕様[RFC4271]の結果であり、新しい要件ではありません。）この場合、スピーカーは、ピアにピアを送信せずにピアとのBGP接続を再確立しようとする必要があります。
If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer and terminate peering (see Section "Extensions to Error Handling" for more details). For example, a BGP speaker may need to terminate peering if it established peering to exchange IPv6 routes and determines that its peer does not support Multiprotocol Extensions for BGP-4 [RFC4760]. The Error Subcode in the NOTIFICATION message is then set to Unsupported Capability. The message MUST contain the capability or capabilities that cause the speaker to send the message. The decision to send the message and terminate the peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically.
特定の機能をサポートするBGPスピーカーが、ピアがこの機能をサポートしていないと判断した場合、スピーカーはピアに通知メッセージを送信してピアリングを終了する場合があります（詳細については「エラー処理の拡張」を参照）。たとえば、BGPスピーカーは、IPv6ルートを交換するためにピアリングを確立し、そのピアがBGP-4のマルチプロトコル拡張をサポートしていないと判断した場合、ピアリングを終了する必要がある場合があります[RFC4760]。通知メッセージのエラーサブコードは、サポートされていない機能に設定されます。メッセージには、スピーカーにメッセージを送信する機能または機能が含まれている必要があります。メッセージを送信してピアリングを終了するという決定は、スピーカーにローカルです。終了した場合、そのようなピアリングは自動的に再確立されるべきではありません。
If a BGP speaker receives from its peer a capability that it does not itself support or recognize, it MUST ignore that capability. In particular, the Unsupported Capability NOTIFICATION message MUST NOT be generated and the BGP session MUST NOT be terminated in response to reception of a capability that is not supported by the local speaker.
BGPスピーカーがピアからそれ自体がサポートまたは認識しない能力を受け取る場合、その能力を無視する必要があります。特に、サポートされていない機能通知メッセージを生成する必要はなく、BGPセッションは、ローカルスピーカーによってサポートされていない機能の受容に応じて終了してはなりません。
4. Capabilities Optional Parameter (Parameter Type 2):
4. 機能オプションパラメーター（パラメータータイプ2）：
This is an Optional Parameter that is used by a BGP speaker to convey to its BGP peer the list of capabilities supported by the speaker. The encoding of BGP Optional Parameters is specified in Section 4.2 of [RFC4271]. The parameter type of the Capabilities Optional Parameter is 2.
これは、BGPスピーカーによって使用されるオプションのパラメーターであり、スピーカーがサポートする機能のリストをBGPピアに伝えます。BGPオプションパラメーターのエンコードは、[RFC4271]のセクション4.2で指定されています。パラメータータイプ機能オプションパラメーターは2です。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
パラメーターには、1つ以上のトリプル<機能コード、機能の長さ、機能値>が含まれています。各トリプルは、以下に示すようにエンコードされます。
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
~ ~
+------------------------------+
The use and meaning of these fields are as follows:
これらのフィールドの使用と意味は次のとおりです。
Capability Code:
機能コード：
Capability Code is a one-octet unsigned binary integer that unambiguously identifies individual capabilities.
機能コードは、個々の機能を明確に識別する1オクテットの署名されていないバイナリ整数です。
Capability Length:
機能の長さ：
Capability Length is a one-octet unsigned binary integer that contains the length of the Capability Value field in octets.
機能長は、オクテットの機能値フィールドの長さを含む1オクテットの符号なしバイナリ整数です。
Capability Value:
機能値：
Capability Value is a variable-length field that is interpreted according to the value of the Capability Code field.
機能値は、機能コードフィールドの値に従って解釈される可変長さフィールドです。
BGP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value. Note, however, that processing of multiple instances of such capability does not require special handling, as additional instances do not change the meaning of the announced capability; thus, a BGP speaker MUST be prepared to accept such multiple instances.
BGPスピーカーは、同じ機能コード、機能の長さ、および機能値を持つ機能のインスタンスを複数含めるべきではありません。ただし、そのような機能の複数のインスタンスの処理には、追加のインスタンスが発表された機能の意味を変更しないため、特別な取り扱いは必要ないことに注意してください。したがって、BGPスピーカーは、そのような複数のインスタンスを受け入れる準備をする必要があります。
BGP speakers MAY include more than one instance of a capability (as identified by the Capability Code) with non-zero Capability Length field, but with different Capability Value and either the same or different Capability Length. Processing of these capability instances is specific to the Capability Code and MUST be described in the document introducing the new capability.
BGPスピーカーには、非ゼロ機能長さフィールドを持つ機能（機能コードで識別される）の複数のインスタンスを含めることができますが、機能値が異なり、同じまたは異なる機能長のいずれかが含まれます。これらの機能インスタンスの処理は機能コードに固有であり、新しい機能を導入するドキュメントで説明する必要があります。
The Capabilities Optional Parameter (OPEN Optional Parameter Type 2) SHOULD only be included in the OPEN message once. If the BGP speaker wishes to include multiple capabilities in the OPEN message, it SHOULD do so as discussed above -- by listing all those capabilities as TLVs within a single Capabilities Optional Parameter. However, for backward compatibility, a BGP speaker MUST be prepared to receive an OPEN message that contains multiple Capabilities Optional Parameters, each of which contains one or more capabilities TLVs. The set of capabilities should be processed in the same way in either case, whether it is enumerated within a single Capabilities Optional Parameter of the OPEN message or split across multiple Capabilities Optional Parameters.
機能オプションのパラメーター（オプションのオプションパラメータータイプ2）は、オープンメッセージに1回のみ含める必要があります。BGPスピーカーがオープンメッセージに複数の機能を含めることを希望する場合、上記のように、それらすべての機能を単一の機能オプションパラメーター内でTLVとしてリストすることにより、それを行う必要があります。ただし、後方互換性のためには、BGPスピーカーを、複数の機能を含むオプションのオプションパラメーターを含むオープンメッセージを受信するために準備する必要があります。一連の機能は、どちらの場合でも同じ方法で処理する必要があります。単一の機能のオプションパラメーター内で列挙されているか、複数の機能オプションパラメーターに分割されます。
This document defines a new Error Subcode, Unsupported Capability. The value of this Subcode is 7. The Data field in the NOTIFICATION message MUST list the set of capabilities that causes the speaker to send the message. Each such capability is encoded in the same way as it would be encoded in the OPEN message.
このドキュメントでは、新しいエラーサブコード、サポートされていない機能を定義します。このサブコードの値は7です。通知メッセージのデータフィールドは、スピーカーにメッセージを送信する機能のセットをリストする必要があります。そのような各機能は、開いたメッセージでエンコードされるのと同じ方法でエンコードされます。
As explained in the "Overview of Operations" section, the Unsupported Capability NOTIFICATION is a way for a BGP speaker to complain that its peer does not support a required capability without which the peering cannot proceed. It MUST NOT be used when a BGP speaker receives a capability that it does not understand; such capabilities MUST be ignored.
「操作の概要」セクションで説明されているように、サポートされていない機能通知は、BGPスピーカーがピアがピアリングが進むことができない必要な機能をサポートしていないと不満を言う方法です。BGPスピーカーが理解できない機能を受け取ったときに使用してはなりません。そのような機能は無視する必要があります。
This document defines a Capability Optional Parameter along with a Capability Code field. IANA maintains the registry for Capability Code values. Capability Code value 0 is reserved. Capability Code values 1 through 63 are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226]. Capability Code values 64 through 127 are to be assigned by IANA using the "First Come First Served" policy defined in [RFC5226]. Capability Code values 128 through 255 are for "Private Use" as defined in [RFC5226].
このドキュメントは、機能コードフィールドとともに機能オプションパラメーターを定義します。IANAは、機能コード値のレジストリを維持しています。機能コード値0は予約されています。機能コード値1〜63は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てられます。機能コード値64〜127は、[RFC5226]で定義された「First Come First Server」ポリシーを使用してIANAによって割り当てられます。機能コード値128〜255は、[RFC5226]で定義されている「プライベート使用」用です。
IANA created and maintains a registry for OPEN message Optional Parameters called "BGP OPEN Optional Parameter Types". Optional Parameters are identified by the Parameter Type, which is a one-octet unsigned integer. Values (0 reserved, 1-255) are to be allocated according to the "IETF Review" policy as defined in [RFC5226].
IANAは、「BGPオプションオプションパラメータータイプ」と呼ばれるオープンメッセージオプションパラメーターのレジストリを作成および維持します。オプションのパラメーターは、パラメータータイプによって識別されます。これは、1オクテットの符号なし整数です。[RFC5226]で定義されている「IETFレビュー」ポリシーに従って、値（0予約済み、1-255）は割り当てられます。
The registry has been populated with the two Parameter Type codes that are currently defined:
レジストリには、現在定義されている2つのパラメータータイプコードが入力されています。
o Parameter Type 1: Authentication (deprecated) [RFC4271] [RFC5492]
o パラメータータイプ1：認証（非推奨）[RFC4271] [RFC5492]
o Parameter Type 2: Capabilities [RFC5492]
o パラメータータイプ2：機能[RFC5492]
This extension to BGP does not change the underlying security issues inherent in the existing BGP [RFC4272].
BGPへのこの拡張は、既存のBGPに固有の基礎となるセキュリティ問題を変更しません[RFC4272]。
The authors would like to thank members of the IDR Working Group and the IESG and its Directorates for their review and comments.
著者は、IDRワーキンググループのメンバーとIESGとその総局のレビューとコメントに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272] Murphy、S。、「BGP Security脆弱性分析」、RFC 4272、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
In addition to several minor editorial changes, RFC 3392 also clarified how to handle multiple instances of the same capability.
いくつかの小さな編集上の変更に加えて、RFC 3392は、同じ機能の複数のインスタンスを処理する方法も明確にしました。
This document makes minor editorial changes and updated references, clarifies the use of the Unsupported Optional Parameter NOTIFICATION message, clarifies behavior when the Capabilities Parameter is included in the OPEN message multiple times, and clarifies requirements by changing a number of SHOULDs to MUSTs.
このドキュメントは、マイナーな編集の変更と更新された参照を作成し、サポートされていないオプションのパラメーター通知メッセージの使用を明確にし、機能パラメーターが複数回オープンメッセージに含まれている場合の動作を明確にし、多くの肩を必須に変更することで要件を明確にします。
Authors' Addresses
著者のアドレス
John G. Scudder Juniper Networks
John G. Scudder Juniper Networks
EMail: jgs@juniper.net
Ravi Chandra Sonoa Systems
ラビチャンドラソノアシステム
EMail: rchandra@sonoasystems.com