Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 7153 Cisco Systems, Inc.
Updates: 4360, 5701 Y. Rekhter
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 March 2014
Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 7153 Cisco Systems, Inc.
Updates: 4360, 5701 Y. Rekhter
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 March 2014
IANA Registries for BGP Extended Communities
BGP扩展社区的IANA注册
Abstract
摘要
This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.
本文档为BGP扩展社区属性和BGP IPv6地址特定扩展社区属性的类型值和子类型值重新组织IANA注册表。这样做是为了消除注册中心之间的相互依赖性，从而使IANA更容易确定哪些代码点可用于分配哪些注册中心。本文件还澄清了当从一个或多个登记处请求分配时必须向IANA提供的信息。这些更改与现有分配兼容，因此不会影响协议实现。然而，这些变化将影响未来协议规范的“IANA注意事项”部分。本文件更新了RFC 4360和RFC 5701。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7153.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7153.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Types, Sub-Types, and Registries ................................4
3. Applicability to IPv6-Address-Specific EC Attribute .............4
4. How to Request EC Type and/or Sub-Type Codepoints ...............5
5. IANA Considerations .............................................6
5.1. Registries for the "Type" Field ............................7
5.1.1. Transitive Types ....................................7
5.1.2. Non-Transitive Types ................................8
5.2. Registries for the "Sub-Type" Field ........................9
5.2.1. EVPN Extended Community Sub-Types ...................9
5.2.2. Transitive Two-Octet AS-Specific Extended Community
Sub-Types ..........................................10
5.2.3. Non-Transitive Two-Octet AS-Specific Extended
Community Sub-Types ................................10
5.2.4. Transitive Four-Octet AS-Specific Extended
Community Sub-Types ................................11
5.2.5. Non-Transitive Four-Octet AS-Specific Extended
Community Sub-Types ................................11
5.2.6. Transitive IPv4-Address-Specific Extended Community
Sub-Types ..........................................12
5.2.7. Non-Transitive IPv4-Address-Specific Extended
Community Sub-Types ................................12
5.2.8. Transitive Opaque Extended Community Sub-Types .....13
5.2.9. Non-Transitive Opaque Extended Community
Sub-Types ..........................................13
5.2.10. Generic Transitive Experimental Use Extended
Community Sub-Types ...............................14
5.2.11. Registries for the "Value" Field ..................14
5.2.11.1. Traffic Action Fields ....................14
5.3. Registries for IPv6-Address-Specific ECs ..................15
5.3.1. Transitive Types ...................................15
5.3.2. Non-Transitive Types ...............................15
6. Security Considerations ........................................15
7. Acknowledgments ................................................16
8. Normative References ...........................................16
1. Introduction ....................................................3
2. Types, Sub-Types, and Registries ................................4
3. Applicability to IPv6-Address-Specific EC Attribute .............4
4. How to Request EC Type and/or Sub-Type Codepoints ...............5
5. IANA Considerations .............................................6
5.1. Registries for the "Type" Field ............................7
5.1.1. Transitive Types ....................................7
5.1.2. Non-Transitive Types ................................8
5.2. Registries for the "Sub-Type" Field ........................9
5.2.1. EVPN Extended Community Sub-Types ...................9
5.2.2. Transitive Two-Octet AS-Specific Extended Community
Sub-Types ..........................................10
5.2.3. Non-Transitive Two-Octet AS-Specific Extended
Community Sub-Types ................................10
5.2.4. Transitive Four-Octet AS-Specific Extended
Community Sub-Types ................................11
5.2.5. Non-Transitive Four-Octet AS-Specific Extended
Community Sub-Types ................................11
5.2.6. Transitive IPv4-Address-Specific Extended Community
Sub-Types ..........................................12
5.2.7. Non-Transitive IPv4-Address-Specific Extended
Community Sub-Types ................................12
5.2.8. Transitive Opaque Extended Community Sub-Types .....13
5.2.9. Non-Transitive Opaque Extended Community
Sub-Types ..........................................13
5.2.10. Generic Transitive Experimental Use Extended
Community Sub-Types ...............................14
5.2.11. Registries for the "Value" Field ..................14
5.2.11.1. Traffic Action Fields ....................14
5.3. Registries for IPv6-Address-Specific ECs ..................15
5.3.1. Transitive Types ...................................15
5.3.2. Non-Transitive Types ...............................15
6. Security Considerations ........................................15
7. Acknowledgments ................................................16
8. Normative References ...........................................16
RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC) attribute. This attribute consists of a sequence of eight-octet "extended communities". The high-order octet is defined to be the "Type" field. Each Type has a range of values for "Transitive Extended Community Types" and a range of values for "Non-transitive Extended Community Types". Some of these ranges are further subdivided into a sub-range of values to be assigned by IANA under the "Standards Action" policy, a sub-range of values to be assigned
RFC 4360[RFC4360]定义了BGP“扩展社区”（EC）属性。此属性由八个八位组的序列“扩展社区”组成。高阶八位组定义为“类型”字段。每个类型都有一系列“可传递的扩展社区类型”的值和一系列“非可传递的扩展社区类型”的值。其中一些范围进一步细分为IANA根据“标准行动”政策分配的数值子范围，即分配的数值子范围
by IANA under the "First Come First Served" policy, and a sub-range for "experimental use". (See [RFC5226], [RFC7120], and [RFC3692] for an explanation of these policies.)
由IANA根据“先到先得”的政策，分为“试验性使用”和“试验性使用”两个范围。（有关这些政策的解释，请参见[RFC5226]、[RFC7120]和[RFC3692]）
For some Extended Community Types, the second octet of the Extended Community is a "Sub-Type" field, and the remaining six octets are the "Value" field. These are referred to as "Extended Types". For other types, there is no "Sub-Type" field, and the "Value" field contains seven octets. These are referred to as "Regular Types".
对于某些扩展社区类型，扩展社区的第二个八位字节是“子类型”字段，其余六个八位字节是“值”字段。这些被称为“扩展类型”。对于其他类型，没有“子类型”字段，“值”字段包含七个八位字节。这些被称为“常规类型”。
RFC 4360 is not very specific about how the IANA registries for Extended Community Types and/or Sub-Types are to be organized, and this has led to some confusion. The purpose of this document is to reorganize the registries to make the IANA codepoint allocation task more straightforward.
RFC 4360对扩展社区类型和/或子类型的IANA注册中心的组织方式不是很具体，这导致了一些混乱。本文档的目的是重新组织注册表，使IANA代码点分配任务更加简单。
The high-order octet of an Extended Community will be known as the "Type" field.
扩展社区的高阶八位组称为“类型”字段。
There will be one IANA registry for "Transitive Extended Community Types" (see Section 5.1.1) and one for "Non-transitive Extended Community Types" (Section 5.1.2). Each registry specifies three ranges, and each range is associated with a particular IANA allocation policy.
将有一个IANA注册表用于“可传递的扩展社区类型”（见第5.1.1节），一个用于“非可传递的扩展社区类型”（第5.1.2节）。每个注册表指定三个范围，每个范围与特定的IANA分配策略相关联。
There will be a set of IANA registries for Extended Community Sub-Types (see Section 5.2). Each such registry will have a range of 0x00-0xFF. Values in the range 0x00-0xBF are assignable by IANA according to the "First Come First Served" allocation policy of [RFC5226]. Values in the range 0xC0-0xFF are assignable by IANA according to the "IETF Review" allocation policy of [RFC5226].
扩展社区子类型将有一套IANA注册中心（见第5.2节）。每个这样的注册表的范围为0x00-0xFF。IANA可根据[RFC5226]的“先到先得”分配策略分配0x00-0xBF范围内的值。IANA可根据[RFC5226]的“IETF审查”分配政策分配0xC0-0xFF范围内的值。
If a particular Type has Sub-Types, that Type's entry in its Type registry identifies its Sub-Type registry. Note that some Types do not have Sub-Types. When the request is made to establish a new Type registry, the request must specify whether or not there is to be a Sub-Type registry associated with that Type.
如果特定类型具有子类型，则该类型在其类型注册表中的条目将标识其子类型注册表。请注意，某些类型没有子类型。当请求建立新类型注册表时，该请求必须指定是否存在与该类型关联的子类型注册表。
Whether a given Type has Sub-Types is determined when the Type is initially defined; this cannot be changed later.
初始定义类型时，确定给定类型是否具有子类型；这不能在以后更改。
RFC 5701 [RFC5701] defines the IPv6-Address-Specific Extended Community to be a 20-octet quantity whose high-order two octets may be considered to be the "Type" field. The high-order octet is either
RFC 5701[RFC5701]将IPv6地址特定的扩展社区定义为20个八位字节的数量，其高阶两个八位字节可被视为“类型”字段。高阶八位组是
0x00, indicating a transitive Extended Community; or 0x40, indicating a Non-transitive Extended Community. The second octet is said to be a "Sub-Type", and it is suggested that the Sub-Types are the same as the Sub-Types for the IPv4-Address-Specific Extended Community. However, the existing IANA codepoint allocations for this octet do not always match the corresponding allocations for the IPv4-Address-Specific Extended Community Sub-Types.
0x00，表示可传递的扩展社区；或0x40，表示不可传递的扩展社区。第二个八位组被称为“子类型”，建议子类型与IPv4地址特定扩展社区的子类型相同。但是，此八位字节的现有IANA代码点分配并不总是与IPv4地址特定扩展社区子类型的相应分配相匹配。
This document modifies RFC 5701 by removing any requirement for the values of the second octet of the IPv6-Address-Specific Extended Community Type codepoints to match the codepoints in either of the IPv4-Address-Specific Sub-Types registries.
本文档对RFC 5701进行了修改，删除了IPv6地址特定扩展社区类型代码点第二个八位字节的值的任何要求，以匹配IPv4地址特定子类型注册表中的任何一个代码点。
This document requests IANA to create two IPv6-Address-Specific Extended Community registries -- one for transitive communities and one for non-transitive communities. See Section 5.3.
本文档要求IANA创建两个IPv6地址特定的扩展社区注册中心——一个用于可传递社区，另一个用于不可传递社区。见第5.3节。
When a codepoint is needed for a new Extended Community, the requester should first determine whether an existing Type can be used. If so, IANA should be asked to allocate a codepoint from the corresponding Sub-Type registry, if there is one.
当新的扩展社区需要一个代码点时，请求者应该首先确定是否可以使用现有类型。如果是这样，应该要求IANA从相应的子类型注册表中分配一个代码点（如果有）。
If a new Extended Community Type is needed, the requester should ask IANA to allocate a new type from the "BGP Transitive Extended Community Types" registry, the "BGP Non-Transitive Extended Community Types" registry, or both. It is up to the requester to state whether an allocation is needed from one or both of these registries. When an allocation from both registries is requested, the requester may find it desirable for both allocations to share the same low-order six bits. If so, it is the responsibility of the requester to explicitly request this of IANA.
如果需要新的扩展社区类型，请求者应要求IANA从“BGP可传递扩展社区类型”注册表、“BGP不可传递扩展社区类型”注册表或两者中分配新类型。由请求者声明是否需要从一个或两个注册中心进行分配。当请求来自两个注册中心的分配时，请求者可能会发现两个分配共享相同的低阶六位是可取的。如果是这样的话，请求者有责任明确请求IANA的批准。
Of course, any request for a codepoint from a particular registry must follow the defined registration procedures for that registry.
当然，来自特定注册表的任何代码点请求都必须遵循该注册表定义的注册过程。
If a new Extended Community Type is needed and the new Type is to have Sub-Types, the requester should specify whether an existing Sub-Type registry can be used for the new Type or a new Sub-Type registry is needed. (At the current time, every Type that has Sub-Types is associated with a unique Sub-Type registry. It is possible that in the future a new Type registry may be created that is associated with a pre-existing Sub-Type registry.) In either case, if a new Sub-Type value needs to be allocated from a particular Sub-Type registry, the request should explicitly identify the registry.
如果需要新的扩展社区类型，并且新类型将具有子类型，则请求者应指定现有子类型注册表可用于新类型还是需要新的子类型注册表。（目前，每个具有子类型的类型都与唯一的子类型注册表相关联。将来可能会创建一个与预先存在的子类型注册表相关联的新类型注册表。）在任何一种情况下，如果需要从特定子类型注册表分配新的子类型值，请求应明确标识注册表。
If the creation of a new Sub-Type registry is requested, the range of values is always 0x00-0xFF. It is recommended that the allocation policy described in Section 2 be used, i.e., 0x00-0xBF to be allocated by IANA under the "First Come First Served" policy and 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy.
如果请求创建新的子类型注册表，则值的范围始终为0x00-0xFF。建议使用第2节中所述的分配策略，即IANA根据“先到先得”策略分配0x00-0xBF，IANA根据“IETF审查”策略分配0xC0-0xFF。
Commonly, a new Extended Community is defined such that it can be of several Types. For example, one may want to define a new Extended Community so that it can be either transitive or non-transitive, either the two-octet AS Number Type or the four-octet AS Number Type, etc. The requester is responsible for explicitly asking IANA to allocate codepoints in all the necessary Type and/or Sub-Type registries.
通常，定义一个新的扩展社区，使其具有多种类型。例如，可能需要定义一个新的扩展社区，以便它可以是可传递的或不可传递的，可以是两个八位组作为数字类型，也可以是四个八位组作为数字类型，等等。请求者负责明确要求IANA在所有必要的类型和/或子类型注册表中分配代码点。
When a new Extended Community is defined, it may be necessary to ask IANA to allocate codepoints in several Sub-Type registries. In this case, it is a common practice to ask IANA to allocate the same codepoint value in each registry. If this is desired, it is the responsibility of the requester to explicitly ask IANA to allocate the same value in each registry.
定义新的扩展社区时，可能需要要求IANA在几个子类型注册表中分配代码点。在这种情况下，通常要求IANA在每个注册表中分配相同的代码点值。如果需要，请求者有责任明确要求IANA在每个注册表中分配相同的值。
When a new Extended Community Sub-Type codepoint is allocated, it may also be desirable to allocate a corresponding value in one or both of the IPv6-Address-Specific Extended Community registries. The requester is responsible for requesting this allocation explicitly. If the requester would like the same numerical value to be allocated in an IPv6-Address-Specific Extended Community registry that is allocated in some other registry, it is the responsibility of the requester to explicitly ask this of IANA.
当分配新的扩展社区子类型代码点时，还可能需要在一个或两个特定于IPv6地址的扩展社区注册表中分配相应的值。请求者负责明确请求此分配。如果请求者希望在其他注册表中分配的IPv6地址特定扩展社区注册表中分配相同的数值，则请求者有责任明确询问IANA。
IANA has replaced the pre-existing BGP Extended Communities registries with the registries described in this section.
IANA已经用本节所述的注册中心取代了原有的BGP扩展社区注册中心。
The registries reproduced below do not include the "references" or "date" fields for the individual codepoints in the registries, because it is difficult to incorporate those within the 72-character line limitation of RFCs. The references and associated dates have been copied from the existing registries when creating the new registries; the authors have worked with IANA to ensure that this information has been carried over correctly to the reorganized registry. As this document does not change the usage or semantics of any of the codepoints, the references associated with the individual codepoints do not change.
下文复制的登记册不包括登记册中各个代码点的“参考”或“日期”字段，因为很难将这些字段纳入RFC的72个字符行限制内。在创建新登记处时，参考号和相关日期已从现有登记处复制；作者与IANA合作，以确保这些信息已正确转入重组后的注册中心。由于本文档不会更改任何代码点的用法或语义，因此与各个代码点关联的引用不会更改。
On the other hand, the references for each of the registries defined in this section have been changed to refer to this document.
另一方面，本节中定义的每个登记处的参考文献已更改为本文件。
The following note has been added to the "BGP Transitive Extended Community Types" registry.
以下注释已添加到“BGP可传递扩展社区类型”注册表中。
This registry contains values of the high-order octet (the "Type" field) of a Transitive Extended Community.
此注册表包含可传递扩展社区的高阶八位字节（“类型”字段）的值。
Registry Name: BGP Transitive Extended Community Types
注册表名称：BGP可传递扩展社区类型
RANGE REGISTRATION PROCEDURES
射程登记程序
0x00-0x3F First Come First Served 0x80-0x8F Experimental Use (see RFC 3692) 0x90-0xBF Standards Action
0x00-0x3F先到先得0x80-0x8F实验使用（参见RFC 3692）0x90-0xBF标准行动
TYPE VALUE NAME
类型值名称
0x00 Transitive Two-Octet AS-Specific Extended Community (Sub-Types are defined in the "Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry)
0x00作为特定扩展社区的可传递两个八位组（子类型在“作为特定扩展社区子类型的可传递两个八位组”注册表中定义）
0x01 Transitive IPv4-Address-Specific Extended Community (Sub-Types are defined in the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry)
0x01特定于IPv4地址的可传递扩展社区（子类型在“特定于IPv4地址的可传递扩展社区子类型”注册表中定义）
0x02 Transitive Four-Octet AS-Specific Extended Community (Sub-Types are defined in the "Transitive Four-Octet AS-Specific Extended Community Sub-Types" registry)
0x02作为特定扩展社区的可传递四个八位组（子类型在“作为特定扩展社区子类型的可传递四个八位组”注册表中定义）
0x03 Transitive Opaque Extended Community (Sub-Types are defined in the "Transitive Opaque Extended Community Sub-Types" registry)
0x03可传递不透明扩展社区（子类型在“可传递不透明扩展社区子类型”注册表中定义）
0x04 QoS Marking
0x04 QoS标记
0x05 CoS Capability
0x05 CoS能力
0x06 EVPN (Sub-Types are defined in the "EVPN Extended Community Sub-Types" registry)
0x06 EVPN（子类型在“EVPN扩展社区子类型”注册表中定义）
0x08 Flow spec redirect/mirror to IP next-hop
0x08流规范重定向/镜像到IP下一跳
0x80 Generic Transitive Experimental Use Extended Community (Sub-Types are defined in the "Generic Transitive Experimental Use Extended Community Sub-Types" registry)
0x80通用传递性实验使用扩展社区（子类型在“通用传递性实验使用扩展社区子类型”注册表中定义）
The following note has been added to the "BGP Non-Transitive Extended Community Types" registry.
以下注释已添加到“BGP非传递扩展社区类型”注册表中。
This registry contains values of the high-order octet (the "Type" field) of a Non-transitive Extended Community.
此注册表包含不可传递的扩展社区的高阶八位字节（“类型”字段）的值。
Registry Name: BGP Non-Transitive Extended Community Types
注册表名称：BGP非传递扩展社区类型
RANGE REGISTRATION PROCEDURES
射程登记程序
0x40-0x7F First Come First Served 0xC0-0xCF Experimental Use (see RFC 3692) 0xD0-0xFF Standards Action
0x40-0x7F先到先得0xC0-0xCF实验使用（参见RFC 3692）0xD0-0xFF标准行动
TYPE VALUE NAME
类型值名称
0x40 Non-Transitive Two-Octet AS-Specific Extended Community (Sub-Types are defined in the "Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry)
0x40作为特定扩展社区的非传递双八位组（子类型在“作为特定扩展社区子类型的非传递双八位组”注册表中定义）
0x41 Non-Transitive IPv4-Address-Specific Extended Community (Sub-Types are defined in the "Non-Transitive IPv4-Address-Specific Extended Community Sub-Types" registry)
0x41非传递性IPv4地址特定扩展社区（子类型在“非传递性IPv4地址特定扩展社区子类型”注册表中定义）
0x42 Non-Transitive Four-Octet AS-Specific Extended Community (Sub-Types are defined in the "Non-Transitive Four-Octet AS-Specific Extended Community Sub-Types" registry)
0x42非传递四个八位组作为特定扩展社区（子类型在“非传递四个八位组作为特定扩展社区子类型”注册表中定义）
0x43 Non-Transitive Opaque Extended Community (Sub-Types are defined in the "Non-Transitive Opaque Extended Community Sub-Types" registry)
0x43非传递不透明扩展社区（子类型在“非传递不透明扩展社区子类型”注册表中定义）
0x44 QoS Marking
0x44 QoS标记
The following note has been added to the "EVPN Extended Community Sub-Types" registry:
以下注释已添加到“EVPN扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x06.
当第一个八位字节（“类型”字段）的值为0x06时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: EVPN Extended Community Sub-Types
注册表名称：EVPN扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x00 MAC Mobility 0x01 ESI MPLS Label 0x02 ES Import
0x00 MAC移动0x01 ESI MPLS标签0x02 ES导入
The following note has been added to the "Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry:
以下注释已添加到“作为特定扩展社区子类型的可传递两个八位组”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x00.
当第一个八位字节（“类型”字段）的值为0x00时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Transitive Two-Octet AS-Specific Extended Community Sub-Types
注册表名：可传递的两个八位组作为特定的扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x02 Route Target 0x03 Route Origin 0x05 OSPF Domain Identifier 0x08 BGP Data Collection 0x09 Source AS 0x0A L2VPN Identifier 0x10 Cisco VPN-Distinguisher
0x02路由目标0x03路由来源0x05 OSPF域标识符0x08 BGP数据收集0x09源作为0x0A L2VPN标识符0x10 Cisco VPN标识符
5.2.3. Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types
5.2.3. 作为特定扩展社区子类型的非传递双八位组
The following note has been added to the "Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry:
以下注释已添加到“非传递的两个八位字节作为特定扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x40.
当第一个八位字节（“类型”字段）的值为0x40时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types
注册表名称：不可传递的两个八位组作为特定的扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x04 Link Bandwidth Extended Community
0x04链路带宽扩展社区
The following note has been added to the "Transitive Four-Octet AS-Specific Extended Community Sub-Types" registry:
以下注释已添加到“作为特定扩展社区子类型的可传递四个八位字节”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x02.
当第一个八位字节（“类型”字段）的值为0x02时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Transitive Four-Octet AS-Specific Extended Community Sub-Types
注册表名称：作为特定扩展社区子类型的可传递四个八位组
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x02 Route Target 0x03 Route Origin 0x04 Generic 0x05 OSPF Domain Identifier 0x08 BGP Data Collection 0x09 Source AS 0x10 Cisco VPN Identifier
0x02路由目标0x03路由源0x04通用0x05 OSPF域标识符0x08 BGP数据收集0x09源作为0x10 Cisco VPN标识符
5.2.5. Non-Transitive Four-Octet AS-Specific Extended Community Sub-Types
5.2.5. 作为特定扩展社区子类型的非传递四个八位组
The following note has been added to the "Non-Transitive Four-Octet AS-Specific Extended Community Sub-Types" registry:
以下注释已添加到“非传递四个八位字节作为特定扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x42.
当第一个八位字节（“类型”字段）的值为0x42时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Non-Transitive Four-Octet AS-Specific Extended Community Sub-Types
注册表名称：作为特定扩展社区子类型的非传递四个八位组
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x04 Generic
0x04通用
The following note has been added to the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry:
以下注释已添加到“特定于IPv4地址的可传递扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x01.
当第一个八位字节（“类型”字段）的值为0x01时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Transitive IPv4-Address-Specific Extended Community Sub-Types
注册表名称：特定于IPv4地址的可传递扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x02 Route Target 0x03 Route Origin 0x05 OSPF Domain Identifier 0x07 OSPF Route ID 0x0A L2VPN Identifier 0x0B VRF Route Import 0x10 Cisco VPN-Distinguisher
0x02路由目标0x03路由来源0x05 OSPF域标识符0x07 OSPF路由ID 0x0A L2VPN标识符0x0B VRF路由导入0x10 Cisco VPN标识符
5.2.7. Non-Transitive IPv4-Address-Specific Extended Community Sub-Types
5.2.7. 不可传递的IPv4地址特定扩展社区子类型
The following note has been added to the "Non-Transitive IPv4-Address-Specific Extended Community Sub-Types" registry:
以下注释已添加到“非传递IPv4地址特定扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x41.
当第一个八位字节（“类型”字段）的值为0x41时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Non-Transitive IPv4-Address-Specific Extended Community Sub-Types
注册表名称：不可传递的IPv4地址特定扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
None Assigned
未分配
The following note has been added to the "Transitive Opaque Extended Community Sub-Types" registry:
以下注释已添加到“可传递不透明扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x03.
当第一个八位字节（“类型”字段）的值为0x03时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Transitive Opaque Extended Community Sub-Types
注册表名称：可传递的不透明扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x06 OSPF Route Type 0x0B Color Extended Community 0x0C Encapsulation Extended Community 0x0D Default Gateway
0x06 OSPF路由类型0x0B彩色扩展社区0x0C封装扩展社区0x0D默认网关
The following note has been added to the "Non-Transitive Opaque Extended Community Sub-Types" registry:
以下注释已添加到“非传递不透明扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x43.
当第一个八位字节（“类型”字段）的值为0x43时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Non-Transitive Opaque Extended Community Sub-Types
注册表名称：非传递不透明扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x00 BGP Origin Validation State
0x00 BGP源验证状态
5.2.10. Generic Transitive Experimental Use Extended Community Sub-Types
5.2.10. 泛型传递实验使用扩展社区子类型
The following note has been added to the "Generic Transitive Experimental Use Extended Community Sub-Types" registry:
以下注释已添加到“通用传递实验使用扩展社区子类型”注册表中：
This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is 0x80.
当第一个八位字节（“类型”字段）的值为0x80时，此注册表包含扩展社区的第二个八位字节（“子类型”字段）的值。
Registry Name: Generic Transitive Experimental Use Extended Community Sub-Types
注册表名称：泛型传递实验使用扩展社区子类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x00-0xBF First Come First Served 0xC0-0xFF IETF Review
0x00-0xBF先到先得0xC0-0xFF IETF评审
SUB-TYPE VALUE NAME
子类型值名称
0x06 Flow spec traffic-rate 0x07 Flow spec traffic-action (Use of the "Value" field is defined in the "Traffic Action Fields" registry) 0x08 Flow spec redirect 0x09 Flow spec traffic-remarking 0x0A Layer2 Info Extended Community
0x06流量规格流量率0x07流量规格流量操作（使用“流量操作字段”注册表中定义的“值”字段）0x08流量规格重定向0x09流量规格流量注释0x0A Layer2信息扩展社区
Note: RFC 5575 contains narrative text that declares the "Flow spec traffic-rate" to be non-transitive but then assigns it a codepoint that indicates that it is transitive. Addressing this error in RFC 5575 is not within the scope of this document.
注：RFC 5575包含叙述性文本，该文本声明“流量规格流量率”为非传递性，但随后为其分配一个代码点，指示其为传递性。在RFC 5575中解决此错误不在本文档的范围内。
At the time of the writing of this document, there is only one registry containing codepoints for the "Value" field of an Extended Community.
在编写本文档时，只有一个注册表包含扩展社区“Value”字段的代码点。
This registry has not been modified.
此注册表尚未修改。
The following note has been added to the "Transitive IPv6-Address-Specific Extended Community Types" registry:
以下注释已添加到“可传递IPv6地址特定的扩展社区类型”注册表中：
This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Community.
此注册表包含特定于IPv6地址的扩展社区的两个高阶八位字节的值。
Registry Name: Transitive IPv6-Address-Specific Extended Community Types
注册表名称：可传递IPv6地址特定的扩展社区类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x0000-0x00FF First Come First Served
0x0000-0x00FF先到先得
TYPE VALUE NAME
类型值名称
0x0002 Route Target 0x0003 Route Origin 0x0004 OSPFv3 Route Attributes (deprecated) 0x000B VRF Route Import 0x0010 Cisco VPN-Distinguisher 0x0011 UUID-based Route Target
0x0002路由目标0x0003路由源0x0004 OSPFv3路由属性（不推荐使用）0x000B VRF路由导入0x0010 Cisco VPN区分器0x0011基于UUID的路由目标
The following note has been added to the "Non-Transitive IPv6-Address-Specific Extended Community Types" registry:
以下注释已添加到“非传递IPv6地址特定扩展社区类型”注册表中：
This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Community.
此注册表包含特定于IPv6地址的扩展社区的两个高阶八位字节的值。
Registry Name: Non-Transitive IPv6-Address-Specific Extended Community Types
注册表名称：不可传递的IPv6地址特定扩展社区类型
RANGE REGISTRATION PROCEDURE
射程登记程序
0x4000-0x40FF First Come First Served
0x4000-0x40FF先到先得
None assigned
未分配
No security considerations are raised by this document.
本文件未提出任何安全注意事项。
The authors wish to thank Jon Mitchell, Hyojeong Kim, and Pearl Liang for their review and comments.
作者要感谢Jon Mitchell、Hyojong Kim和Pearl Liang的评论和评论。
The authors wish to thank Amanda Baber of IANA for educating us on some of the problems faced by IANA staff when responding to requests for BGP Extended Community Type and Sub-Type codepoint allocations.
作者希望感谢IANA的Amanda Baber，感谢他在回应BGP扩展社区类型和子类型代码点分配请求时，就IANA员工面临的一些问题对我们进行了教育。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[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月。
[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月。
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009.
[RFC5701]Rekhter，Y.，“特定于IPv6地址的BGP扩展社区属性”，RFC 57012009年11月。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，2014年1月。
Authors' Addresses
作者地址
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
加利福尼亚州桑尼维尔北马蒂尔达大道1194号雅科夫·雷克特·朱尼珀网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com