[要約] RFC 5668は、4オクテットAS固有のBGP拡張コミュニティに関する仕様です。このRFCの目的は、BGPネットワークでAS固有の情報を伝達するための拡張コミュニティの仕組みを提供することです。
Network Working Group Y. Rekhter Request for Comments: 5668 Juniper Networks Category: Standards Track S. Sangli Cisco Systems D. Tappan Consultant October 2009
4-Octet AS Specific BGP Extended Community
特定のBGP拡張コミュニティとしての4-オクテット
Abstract
概要
This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number.
このドキュメントでは、新しいタイプのBGP拡張コミュニティを定義します。これには、4オクテットの自律システム(AS)番号が含まれています。
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 (http://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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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としての出版またはそれを英語以外の言語に翻訳するため。
This document defines a new type of BGP extended community [RFC4360]: a 4-octet AS specific extended community. This type of extended community is similar to the 2-octet AS specific extended community, except that it can carry a 4-octet Autonomous System number.
このドキュメントでは、新しいタイプのBGP拡張コミュニティ[RFC4360]を定義します。特定の拡張コミュニティとして4-OCTETです。このタイプの拡張コミュニティは、特定の拡張コミュニティとして2-OCTETに似ていますが、4-OCTETの自律システム番号を運ぶことができます。
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]で説明されているように解釈されます。
This is an extended type with a Type field comprising 2 octets and a Value field comprising 6 octets.
これは、2オクテットと6オクテットを含む値フィールドを含むタイプフィールドを備えた拡張タイプです。
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 or 0x42 | Sub-Type | Global Administrator : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the high-order octet of this extended type is either 0x02 (for transitive communities) or 0x42 (for non-transitive communities). The low-order octet of this extended type is used to indicate sub-types.
この拡張タイプの高次オクテットの値は、0x02(推移的なコミュニティの場合)または0x42(非転換コミュニティの場合)です。この拡張タイプの低次のオクテットは、サブタイプを示すために使用されます。
The Value field consists of 2 sub-fields:
値フィールドは2つのサブフィールドで構成されています。
Global Administrator sub-field: 4 octets
グローバル管理者サブフィールド:4オクテット
This sub-field contains a 4-octet Autonomous System number assigned by IANA.
このサブフィールドには、IANAによって割り当てられた4-OCTETの自律システム番号が含まれています。
Local Administrator sub-field: 2 octets
ローカル管理者サブフィールド:2オクテット
The organization identified by the Autonomous System number in the Global Administrator sub-field can encode any information in this sub-field. The format and meaning of the value encoded in this sub-field should be defined by the sub-type of the community.
グローバル管理者サブフィールドの自律システム番号によって識別された組織は、このサブフィールドの情報をエンコードできます。このサブフィールドでエンコードされた値の形式と意味は、コミュニティのサブタイプによって定義する必要があります。
As per [RFC4893], a 2-octet Autonomous System number can be converted into a 4-octet Autonomous System number by setting the 2 high-order octets of the 4-octet field to zero.
[RFC4893]によると、4オクテットのフィールドの2つの高次オクテットをゼロに設定することにより、2オクセテスの自律システム番号を4オクテットの自律システム番号に変換できます。
As a consequence, at least in principle, an Autonomous System that uses a 2-octet Autonomous System number could use either 2-octet or 4-octet AS specific extended communities. This is undesirable, as both communities would be treated as different, even if they had the same Sub-Type and Local Administrator values.
結果として、少なくとも原則として、2-OCTETの自律システム番号を使用する自律システムは、特定の拡張コミュニティとして2-OCTETまたは4-OCTETのいずれかを使用できます。両方のコミュニティが同じサブタイプとローカル管理者の値を持っていても、両方のコミュニティが異なるものとして扱われるため、これは望ましくない。
Therefore, for backward compatibility with existing deployments and to avoid inconsistencies between 2-octet and 4-octet specific extended communities, Autonomous Systems that use 2-octet Autonomous System numbers SHOULD use 2-octet AS specific extended communities rather than 4-octet AS specific extended communities.
したがって、既存の展開との逆方向の互換性と、2-OCTETおよび4-OCTET固有の拡張コミュニティ間の矛盾を回避するために、2オクタートの自律システム番号を使用する自律システムは、特定の拡張コミュニティとして特定の拡張コミュニティとして2-OCTETを特定の拡張コミュニティとして使用する必要があります。拡張コミュニティ。
This document defines a class of extended communities, called 4-octet AS specific extended communities, for which the IANA has created and will maintain a registry entitled Four-octet AS Specific Extended Community. All the communities in this class are of extended Types. Future assignments are to be made using the "First Come First Served" policy defined in [RFC5226]. The Type values for the transitive communities of the 4-octet AS specific extended community class are 0x0200-0x02ff; for the non-transitive communities of that class, they are 0x4200-0x42ff. Assignments consist of a name and the value.
このドキュメントでは、4-OCTETと呼ばれる特定の拡張コミュニティと呼ばれる拡張コミュニティのクラスを定義します。これは、IANAが特定の拡張コミュニティとしてFour-OCTETというタイトルのレジストリを作成し、維持します。このクラスのすべてのコミュニティは、拡張タイプです。将来の割り当ては、[RFC5226]で定義された「First Come First Server」ポリシーを使用して行われます。特定の拡張コミュニティクラスとしての4-OCTETの推移的なコミュニティのタイプ値は0x0200-0x02ffです。そのクラスの非緊急コミュニティの場合、それらは0x4200-0x42ffです。割り当ては、名前と値で構成されています。
This document makes the following assignments for the 4-octet AS specific extended community:
このドキュメントは、特定の拡張コミュニティとして4-OCTETの次の割り当てを行います。
Name Type Value ---- ---------- four-octet AS specific Route Target 0x0202 four-octet AS specific Route Origin 0x0203
This document does not add new security issues. All the security considerations for BGP extended communities apply here. At the time that this document was written, there were significant efforts underway to improve the security properties of BGP. For examples of documents that have been produced up to this time of publication, see [RFC4593] and [SIDR].
このドキュメントでは、新しいセキュリティの問題は追加されません。BGP拡張コミュニティのすべてのセキュリティに関する考慮事項は、ここに適用されます。この文書が書かれた時点で、BGPのセキュリティプロパティを改善するための重要な努力が進行中でした。この出版時までに作成されたドキュメントの例については、[RFC4593]および[SIDR]を参照してください。
There is a potential serious issue if a malformed, optional transitive attribute is received. This issue and the steps to avoid it are discussed in [OPT_TRANS].
奇形のオプションの推移的属性を受信した場合、潜在的な深刻な問題があります。この問題とそれを回避する手順については、[opt_trans]で説明します。
Thanks to Bruno Decraene for his contributions to this document.
この文書への貢献をしてくれたブルーノ・デクレエンに感謝します。
[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月。
[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月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893] Vohra、Q。およびE. Chen、「Number Spaceとしての4オクテットのBGPサポート」、RFC 4893、2007年5月。
[OPT_TRANS] Scudder, J., and E. Chen, "Error Handling for Optional Transitive BGP Attributes", Work in Progress, April 2009.
[Opt_trans] Scudder、J。、およびE. Chen、「オプションの推移的BGP属性のエラー処理」、2009年4月、進行中の作業。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[SIDR] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, July 2009.
[SIDR] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、2009年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks、Inc。電子メール:yakov@juniper.net
Srihari R. Sangli Cisco Systems, Inc. EMail: rsrihari@cisco.com
Srihari R. Sangli Cisco Systems、Inc。メール:rsrihari@cisco.com
Dan Tappan Boxborough MA EMail: Dan.Tappan@Gmail.com
Dan Tappan Boxborough MAメール:dan.tappan@gmail.com