draft-ietf-idr-extcomm-iana-02.txt   rfc7153.txt 
IDR Working Group Eric C. Rosen Internet Engineering Task Force (IETF) E. Rosen
Internet Draft Cisco Systems, Inc. Request for Comments: 7153 Cisco Systems, Inc.
Intended Status: Standards Track Updates: 4360, 5701 Y. Rekhter
Updates: 4360,5701 Yakov Rekhter Category: Standards Track Juniper Networks, Inc.
Expires: June 4, 2014 Juniper Networks, Inc. ISSN: 2070-1721 March 2014
December 4, 2013
IANA Registries for BGP Extended Communities IANA Registries for BGP Extended Communities
draft-ietf-idr-extcomm-iana-02.txt
Abstract Abstract
This document reorganizes the IANA Registries for the type values and This document reorganizes the IANA registries for the type values and
sub-type values of BGP Extended Communities attribute and the BGP sub-type values of the BGP Extended Communities attribute and the BGP
IPv6-Address-Specific Extended Communities attribute. This is done IPv6-Address-Specific Extended Communities attribute. This is done
in order to remove inter-dependencies among the registries, thus in order to remove interdependencies among the registries, thus
making it easier for IANA to determine which codepoints are available making it easier for IANA to determine which codepoints are available
for assignment in which registries. This document also clarifies the for assignment in which registries. This document also clarifies the
information that must be provided to IANA when requesting an information that must be provided to IANA when requesting an
allocation from one or more of these registries. These changes are allocation from one or more of these registries. These changes are
compatible with the existing allocations, and thus do not affect compatible with the existing allocations and thus do not affect
protocol implementations. The changes will however impact the "IANA protocol implementations. The changes will, however, impact the
Considerations" sections of future protocol specifications. This "IANA Considerations" sections of future protocol specifications.
document updates RFC 4360 and RFC 5701. This document updates RFC 4360 and RFC 5701.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7153.
Copyright and License Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction .......................................... 4 1. Introduction ....................................................3
2 Types, Sub-Types, and Registries ...................... 4 2. Types, Sub-Types, and Registries ................................4
3 Applicability to IPv6 Address Specific EC Attribute ... 5 3. Applicability to IPv6-Address-Specific EC Attribute .............4
4 How to Request EC Type and/or Sub-Type Codepoints ..... 5 4. How to Request EC Type and/or Sub-Type Codepoints ...............5
5 IANA Considerations ................................... 7 5. IANA Considerations .............................................6
5.1 Registries for the TYPE Field ......................... 7 5.1. Registries for the "Type" Field ............................7
5.1.1 Transitive Types ...................................... 7 5.1.1. Transitive Types ....................................7
5.1.2 Non-Transitive Types .................................. 9 5.1.2. Non-Transitive Types ................................8
5.2 Registries for the Sub-Type Field ..................... 10 5.2. Registries for the "Sub-Type" Field ........................9
5.2.1 EVPN Sub-Types ........................................ 10 5.2.1. EVPN Extended Community Sub-Types ...................9
5.2.2 Transitive Two-Octet AS-Specific Sub-Types ............ 10 5.2.2. Transitive Two-Octet AS-Specific Extended Community
5.2.3 Non-Transitive Two-Octet AS-Specific Sub-Types ........ 11 Sub-Types ..........................................10
5.2.4 Transitive Four-Octet AS-Specific Sub-Types ........... 12 5.2.3. Non-Transitive Two-Octet AS-Specific Extended
5.2.5 Non-Transitive Four-Octet AS-Specific Sub-Types ....... 12 Community Sub-Types ................................10
5.2.6 Transitive IPv4-Address-Specific Sub-Types ............ 13 5.2.4. Transitive Four-Octet AS-Specific Extended
5.2.7 Non-Transitive IPv4-Address-Specific Sub-Types ........ 14 Community Sub-Types ................................11
5.2.8 Transitive Opaque Extended Community Sub-Types ........ 14 5.2.5. Non-Transitive Four-Octet AS-Specific Extended
5.2.9 Non-Transitive Opaque Extended Community Sub-Types .... 15 Community Sub-Types ................................11
5.2.10 Generic Transitive Experimental Use Sub-Types ......... 15 5.2.6. Transitive IPv4-Address-Specific Extended Community
5.2.11 Registries for the Value Field ........................ 16 Sub-Types ..........................................12
5.2.11.1 Traffic Action Field .................................. 16 5.2.7. Non-Transitive IPv4-Address-Specific Extended
5.3 Registries for IPv6-Address-Specific ECs .............. 16 Community Sub-Types ................................12
5.3.1 Transitive Types ...................................... 16 5.2.8. Transitive Opaque Extended Community Sub-Types .....13
5.3.2 Non-Transitive Types .................................. 17 5.2.9. Non-Transitive Opaque Extended Community
6 Security Considerations ............................... 17 Sub-Types ..........................................13
7 Acknowledgments ....................................... 17 5.2.10. Generic Transitive Experimental Use Extended
8 Authors' Addresses .................................... 17 Community Sub-Types ...............................14
9 Normative References .................................. 18 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 1. Introduction
RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC) RFC 4360 [RFC4360] defines the BGP "Extended Communities" (EC)
attribute. This attribute consists of a sequence of eight-octet attribute. This attribute consists of a sequence of eight-octet
"extended communities". The high-order octet is defined to be the "extended communities". The high-order octet is defined to be the
"Type" field. Each Type has a range of values for "Transitive "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" and a range of values for "Non-transitive
Extended Community Types". Some of these ranges are further sub- Extended Community Types". Some of these ranges are further
divided into a sub-range of values to be assigned by IANA under the subdivided into a sub-range of values to be assigned by IANA under
"Standards Action (with Early Allocation)" policy a sub-range of the "Standards Action" policy, a sub-range of values to be assigned
values to be assigned by IANA under the "First Come First Served" by IANA under the "First Come First Served" policy, and a sub-range
policy, and a sub-range for "experimental use". (See [RFC5226], for "experimental use". (See [RFC5226], [RFC7120], and [RFC3692] for
[RFC4020], and [RFC3692] for an explanation of these policies.) an explanation of these policies.)
For some Extended Community Types, the second octet of the Extended For some Extended Community Types, the second octet of the Extended
Community is a "Sub-Type" field, and the remaining six octets are the Community is a "Sub-Type" field, and the remaining six octets are the
"Value" field. These are referred to as "Extended Types". For other "Value" field. These are referred to as "Extended Types". For other
types, there is no Sub-Type field, and the Value field contains seven types, there is no "Sub-Type" field, and the "Value" field contains
octets. These are referred to as "Regular Types". seven octets. These are referred to as "Regular Types".
RFC 4360 is not very specific about how the IANA registries for RFC 4360 is not very specific about how the IANA registries for
Extended Community Types and/or Sub-Types are to be organized, and 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 this has led to some confusion. The purpose of this document is to
reorganize the registries to make the IANA codepoint allocation task reorganize the registries to make the IANA codepoint allocation task
more straightforward. more straightforward.
2. Types, Sub-Types, and Registries 2. Types, Sub-Types, and Registries
The high-order octet of an Extended Community will be known as the The high-order octet of an Extended Community will be known as the
"Type Field". "Type" field.
There will be one IANA registry for "Transitive Extended Community There will be one IANA registry for "Transitive Extended Community
Types" (see section 5.1.1), and one for "Non-transitive Extended Types" (see Section 5.1.1) and one for "Non-transitive Extended
Community Types" (section 5.1.2). Each registry specifies three Community Types" (Section 5.1.2). Each registry specifies three
ranges, and each range is associated with a particular IANA ranges, and each range is associated with a particular IANA
allocation policy. allocation policy.
There will be a set of IANA registries for Extended Community Sub- There will be a set of IANA registries for Extended Community
Types (see section 5.2). Each such registry will have a range of 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 0x00-0xFF. Values in the range 0x00-0xBF are assignable by IANA
according to the "First Come, First Served" allocation policy of according to the "First Come First Served" allocation policy of
[RFC5226]. Values in the range 0xC0-0xFF are assignable by IANA [RFC5226]. Values in the range 0xC0-0xFF are assignable by IANA
according to the "IETF Review" allocation policy of [RFC5226]. according to the "IETF Review" allocation policy of [RFC5226].
If a particular Type has Sub-Types, that Type's entry in its Type 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 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 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 registry, the request must specify whether or not there is to be a
Sub-Type registry associated with that Type. Sub-Type registry associated with that Type.
Whether a given Type has Sub-Types is determined when the Type is Whether a given Type has Sub-Types is determined when the Type is
initially defined; this cannot be changed later. initially defined; this cannot be changed later.
3. Applicability to IPv6 Address Specific EC Attribute 3. Applicability to IPv6-Address-Specific EC Attribute
RFC 5701 [RFC5701] defines the IPv6 Address Specific Extended RFC 5701 [RFC5701] defines the IPv6-Address-Specific Extended
Community to be a 20-octet quantity whose high order two octets may 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 be considered to be the "Type" field. The high-order octet is either
0x00, indicating a transitive Extended Community, or 0x40, indicating 0x00, indicating a transitive Extended Community; or 0x40, indicating
a Non-transitive Extended Community. The second octet is said to be 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 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. the Sub-Types for the IPv4-Address-Specific Extended Community.
However, the existing IANA codepoint allocations for this octet do However, the existing IANA codepoint allocations for this octet do
not always match the corresponding allocations for the IPv4-Address- not always match the corresponding allocations for the
Specific Extended Community Sub-Types. IPv4-Address-Specific Extended Community Sub-Types.
This document modifies RFC 5701 by removing any requirement for the This document modifies RFC 5701 by removing any requirement for the
values of the second octet of the IPv6-Address-Specific Extended values of the second octet of the IPv6-Address-Specific Extended
Community Type codepoints to match the codepoints in the Community Type codepoints to match the codepoints in either of the
IPv4-Address-Specific Sub-Types registry. IPv4-Address-Specific Sub-Types registries.
This document requests IANA to create two IPv6-Address-Specific This document requests IANA to create two IPv6-Address-Specific
Extended Community registries, one for transitive communities and one Extended Community registries -- one for transitive communities and
for non-transitive communities. See section 5.3. one for non-transitive communities. See Section 5.3.
4. How to Request EC Type and/or Sub-Type Codepoints 4. How to Request EC Type and/or Sub-Type Codepoints
When a codepoint is needed for a new Extended Community, the When a codepoint is needed for a new Extended Community, the
requester should first determine whether an existing Type can be requester should first determine whether an existing Type can be
used. If so, IANA should be asked to allocate a codepoint from the used. If so, IANA should be asked to allocate a codepoint from the
corresponding Sub-Type registry, if there is one. corresponding Sub-Type registry, if there is one.
If a new Extended Community Type is needed, the requester should ask If a new Extended Community Type is needed, the requester should ask
IANA to allocate a new type from either the "Transitive Extended IANA to allocate a new type from the "BGP Transitive Extended
Community Types" registry, the "Non-transitive Extended Community Community Types" registry, the "BGP Non-Transitive Extended Community
Types" registry, or both. It is up to the requester to state whether 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 is needed from one or both of these registries. When
an allocation from both registries is requested, the requester may an allocation from both registries is requested, the requester may
find it desirable for both allocations to share the same low-order find it desirable for both allocations to share the same low-order
six bits. If so, it is the responsibility of the requester to six bits. If so, it is the responsibility of the requester to
explicitly request this of IANA. explicitly request this of IANA.
Of course, any request for a codepoint from a particular registry Of course, any request for a codepoint from a particular registry
must follow the defined registration procedures for that registry. must follow the defined registration procedures for that registry.
If a new Extended Community Type is needed, and the new Type is to 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- have Sub-Types, the requester should specify whether an existing
Type registry can be used for the new Type, or whether a new Sub-Type 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- registry is needed. (At the current time, every Type that has
Types is associated with a unique Sub-Type registry. It is possible Sub-Types is associated with a unique Sub-Type registry. It is
that in the future a new Type registry may be created that is possible that in the future a new Type registry may be created that
associated with a pre-existing Sub-Type registry.) In either case, is associated with a pre-existing Sub-Type registry.) In either
if a new Sub-Type value needs to be allocated from a particular Sub- case, if a new Sub-Type value needs to be allocated from a particular
Type registry, the request should explicitly identify the registry. Sub-Type registry, the request should explicitly identify the
registry.
If the creation of a new Sub-Type registry is requested, the range of 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 values is always 0x00-0xFF. It is recommended that the allocation
policy described in section 2 be used. I.e., 0x00-0xBF to be policy described in Section 2 be used, i.e., 0x00-0xBF to be
allocated by IANA under the "First Come, First Served" policy, and allocated by IANA under the "First Come First Served" policy and
0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy.
Commonly, a new Extended Community is defined such that it can be of Commonly, a new Extended Community is defined such that it can be of
several Types. E.g., one may want to define a new Extended Community several Types. For example, one may want to define a new Extended
so that it can be either transitive or non-transitive, so that it can Community so that it can be either transitive or non-transitive,
be either of the Two-octet AS Number Type or the Four-octet AS Number either the two-octet AS Number Type or the four-octet AS Number Type,
Type, etc. The requester is responsible for explicitly asking IANA etc. The requester is responsible for explicitly asking IANA to
to allocate codepoints in all the necessary Type and/or Sub-Type allocate codepoints in all the necessary Type and/or Sub-Type
registries. registries.
When a new Extended Community is defined, it may be necessary to ask When a new Extended Community is defined, it may be necessary to ask
IANA to allocate codepoints in several Sub-Type registries. In this IANA to allocate codepoints in several Sub-Type registries. In this
case, it is a common practice to ask IANA to allocate the same 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 codepoint value in each registry. If this is desired, it is the
responsibility of the requester to explicitly ask IANA to allocate responsibility of the requester to explicitly ask IANA to allocate
the same value in each registry. the same value in each registry.
When a new Extended Community Sub-Type codepoint is allocated, it may 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 also be desirable to allocate a corresponding value in one or both of
the IPv6-Address-Specific Extended Community registries. The the IPv6-Address-Specific Extended Community registries. The
requester is responsible for requesting this allocation explicitly. requester is responsible for requesting this allocation explicitly.
If the requester would like the same numerical value to be allocated If the requester would like the same numerical value to be allocated
in an IPv6-Address-Specific Extended Community registry that is in an IPv6-Address-Specific Extended Community registry that is
allocated in some other registry, it is the responsibility of the allocated in some other registry, it is the responsibility of the
requester to explicitly ask this of IANA. requester to explicitly ask this of IANA.
5. IANA Considerations 5. IANA Considerations
IANA is to replace the pre-existing BGP Extended Communities IANA has replaced the pre-existing BGP Extended Communities
registries with the registries described in this section. registries with the registries described in this section.
Any Extended Community Type or Sub-type codepoints allocated by IANA
between the date of this document and the date at which the
registries are reorganized must also be incorporated into the new
registry organization. The authors will work with IANA to ensure
that this is done correctly.
The registries reproduced below do not include the "references" or The registries reproduced below do not include the "references" or
"date" fields for the individual codepoints in the registries, "date" fields for the individual codepoints in the registries,
because it is difficult to incorporate those within the 72-character because it is difficult to incorporate those within the 72-character
line limitation of RFCs. The references and associated dates must be line limitation of RFCs. The references and associated dates have
copied from the current registries when the new registries are been copied from the existing registries when creating the new
introduced; the authors will work with IANA to ensure that this registries; the authors have worked with IANA to ensure that this
information is carried over correctly to the new registry information has been carried over correctly to the reorganized
organization. As this document does not change the usage or registry. As this document does not change the usage or semantics of
semantics of any of the codepoints, the references associated with any of the codepoints, the references associated with the individual
the individual codepoints do not change. codepoints do not change.
On the other hand, the reference for each of the registries defined On the other hand, the references for each of the registries defined
in this section should be changed to this document. in this section have been changed to refer to this document.
5.1. Registries for the TYPE Field 5.1. Registries for the "Type" Field
5.1.1. Transitive Types 5.1.1. Transitive Types
This registry shall contain the following note: The following note has been added to the "BGP Transitive Extended
Community Types" registry.
This registry contains values of the high-order octet (the "Type This registry contains values of the high-order octet (the "Type"
Field") of a Transitive Extended Community. field) of a Transitive Extended Community.
Registry Name: BGP TRANSITIVE EXTENDED COMMUNITY TYPES Registry Name: BGP Transitive Extended Community Types
RANGE REGISTRATION PROCEDURES RANGE REGISTRATION PROCEDURES
0x00-0x3F First Come, First Served 0x00-0x3F First Come First Served
0x80-0x8F Experimental Use (see RFC 3692) 0x80-0x8F Experimental Use (see RFC 3692)
0x90-0xBF Standards Action (early allocation per RFC 4020) 0x90-0xBF Standards Action
TYPE VALUE NAME TYPE VALUE NAME
0x00 Transitive Two-Octet AS-specific Extended 0x00 Transitive Two-Octet AS-Specific Extended
Community (Sub-Types are defined in the Community (Sub-Types are defined in the
"Transitive Two-Octet AS-specific Extended "Transitive Two-Octet AS-Specific Extended
Community Sub-Types" Registry) Community Sub-Types" registry)
0x01 Transitive IPv4-Address-specific Extended 0x01 Transitive IPv4-Address-Specific Extended
Community (Sub-Types are defined in the Community (Sub-Types are defined in the
"Transitive IPv4-Address-specific Extended "Transitive IPv4-Address-Specific Extended
Community Sub-Types" Registry) Community Sub-Types" registry)
0x02 Transitive Four-Octet AS-specific Extended 0x02 Transitive Four-Octet AS-Specific Extended
Community (Sub-Types are defined in the Community (Sub-Types are defined in the
"Transitive Four-Octet AS-specific Extended "Transitive Four-Octet AS-Specific Extended
Community Sub-Types" Registry) Community Sub-Types" registry)
0x03 Transitive Opaque Extended Community 0x03 Transitive Opaque Extended Community
(Sub-Types are defined in the "Transitive (Sub-Types are defined in the "Transitive
Opaque Extended Community Sub-Types" Opaque Extended Community Sub-Types"
Registry) registry)
0x04 QoS Marking 0x04 QoS Marking
0x05 CoS Capability 0x05 CoS Capability
0x06 EVPN (Sub-Types are defined in the "EVPN 0x06 EVPN (Sub-Types are defined in the "EVPN
Extended Community Sub-types" Registry) Extended Community Sub-Types" registry)
0x08 Flow spec redirect/mirror to IP next-hop 0x08 Flow spec redirect/mirror to IP next-hop
0x80 Generic Transitive Experimental Use Extended
Community (Sub-Types are defined in the
"Generic Transitive Experimental Use Extended
Community Sub-Types" registry)
0x80 Generic Transitive Experimental Extended 5.1.2. Non-Transitive Types
Community (Sub-Types are defined in the
"Generic Transitive Experimental Extended
Community Sub-Types" Registry)
5.1.2. Non-Transitive Types The following note has been added to the "BGP Non-Transitive Extended
Community Types" registry.
This registry shall contain the following note: This registry contains values of the high-order octet (the "Type"
field) of a Non-transitive Extended Community.
This registry contains values of the high-order octet (the "Type Registry Name: BGP Non-Transitive Extended Community Types
Field") of a Non-transitive Extended Community.
Registry Name: BGP NON-TRANSITIVE EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURES
RANGE REGISTRATION PROCEDURES 0x40-0x7F First Come First Served
0xC0-0xCF Experimental Use (see RFC 3692)
0xD0-0xFF Standards Action
0x40-0x7F First Come, First Served TYPE VALUE NAME
0xC0-0xCF Experimental Use (see RFC 3692)
0xD0-0xFF Standards Action (early allocation per RFC 4020)
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 Non-Transitive Two-Octet AS-specific Extended 0x41 Non-Transitive IPv4-Address-Specific Extended
Community (Sub-Types are defined in the Community (Sub-Types are defined in the
"Non-Transitive Two-Octet AS-specific Extended "Non-Transitive IPv4-Address-Specific Extended
Community Sub-Types" Registry) Community Sub-Types" registry)
0x41 Non-Transitive IPv4-Address-specific Extended 0x42 Non-Transitive Four-Octet AS-Specific Extended
Community (Sub-Types are defined in the Community (Sub-Types are defined in the
"Non-transitive IPv4-Address-specific Extended "Non-Transitive Four-Octet AS-Specific Extended
Community Sub-Types" Registry) Community Sub-Types" registry)
0x42 Non-Transitive Four-Octet AS-specific Extended 0x43 Non-Transitive Opaque Extended Community
(Sub-Types are defined in the "Non-Transitive (Sub-Types are defined in the "Non-Transitive
Four-Octet AS-specific Extended Community Opaque Extended Community Sub-Types" registry)
Sub-Types" Registry)
0x43 Non-Transitive Opaque Extended Community 0x44 QoS Marking
(Sub-Types are defined in the "Non-Transitive
Opaque Extended Community Sub-Types" Registry)
0x44 QoS Marking 5.2. Registries for the "Sub-Type" Field
5.2. Registries for the Sub-Type Field 5.2.1. EVPN Extended Community Sub-Types
5.2.1. EVPN Sub-Types The following note has been added to the "EVPN Extended Community
Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: EVPN Extended Community Sub-Types
field") of an extended community, when the value of the first
octet (the "Type field") is 0x06.
Registry Name: EVPN EXTENDED COMMUNITY SUB-TYPES RANGE REGISTRATION PROCEDURE
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x00 MAC Mobility
0x01 ESI MPLS Label
0x02 ES Import
0x00 MAC Mobility 5.2.2. Transitive Two-Octet AS-Specific Extended Community Sub-Types
0x01 ESI MPLS Label
0x02 ES Import
5.2.2. Transitive Two-Octet AS-Specific Sub-Types The following note has been added to the "Transitive Two-Octet
AS-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Transitive Two-Octet AS-Specific Extended
field") of an extended community, when the value of the first Community Sub-Types
octet (the "Type field") is 0x00.
Registry Name: TRANSITIVE TWO-OCTET AS-SPECIFIC RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
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 Route Target 5.2.3. Non-Transitive Two-Octet AS-Specific Extended Community
0x03 Route Origin Sub-Types
0x05 OSPF Domain Identifier
0x08 BGP Data Collection
0x09 Source AS
0x0A L2VPN Identifier
0x10 Cisco VPN-Distinguisher
5.2.3. Non-Transitive Two-Octet AS-Specific Sub-Types The following note has been added to the "Non-Transitive Two-Octet
AS-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Non-Transitive Two-Octet AS-Specific Extended
field") of an extended community, when the value of the first Community Sub-Types
octet (the "Type field") is 0x40.
Registry Name: NON-TRANSITIVE TWO-OCTET AS-SPECIFIC RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x04 Link Bandwidth Extended Community
0x04 Link Bandwidth Extended Community 5.2.4. Transitive Four-Octet AS-Specific Extended Community Sub-Types
5.2.4. Transitive Four-Octet AS-Specific Sub-Types The following note has been added to the "Transitive Four-Octet
AS-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Transitive Four-Octet AS-Specific Extended
field") of an extended community, when the value of the first Community Sub-Types
octet (the "Type field") is 0x02.
Registry Name: TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED RANGE REGISTRATION PROCEDURE
COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
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 Route Target 5.2.5. Non-Transitive Four-Octet AS-Specific Extended Community
0x03 Route Origin Sub-Types
0x04 Generic
0x05 OSPF Domain Identifier
0x08 BGP Data Collection
0x09 Source AS
0x10 Cisco VPN Identifier
5.2.5. Non-Transitive Four-Octet AS-Specific Sub-Types The following note has been added to the "Non-Transitive Four-Octet
AS-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Non-Transitive Four-Octet AS-Specific
field") of an extended community, when the value of the first Extended Community Sub-Types
octet (the "Type field") is 0x42.
Registry Name: NON-TRANSITIVE FOUR-OCTET AS-SPECIFIC RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x04 Generic
0x04 Generic 5.2.6. Transitive IPv4-Address-Specific Extended Community Sub-Types
5.2.6. Transitive IPv4-Address-Specific Sub-Types The following note has been added to the "Transitive
IPv4-Address-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Transitive IPv4-Address-Specific Extended
field") of an extended community, when the value of the first Community Sub-Types
octet (the "Type field") is 0x01.
Registry Name: TRANSITIVE IPV4-ADDRESS-SPECIFIC RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
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 Route Target 5.2.7. Non-Transitive IPv4-Address-Specific Extended Community
0x03 Route Origin Sub-Types
0x05 OSPF Domain Identifier
0x07 OSPF Route ID
0x0A L2VPN Identifier
0x0B VRF Route Import
0x10 Cisco VPN-Distinguisher
5.2.7. Non-Transitive IPv4-Address-Specific Sub-Types The following note has been added to the "Non-Transitive
IPv4-Address-Specific Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Non-Transitive IPv4-Address-Specific Extended
field") of an extended community, when the value of the first Community Sub-Types
octet (the "Type field") is 0x41.
Registry Name: NON-TRANSITIVE IPV4-ADDRESS-SPECIFIC RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served None Assigned
0xC0-0xFF IETF Review
None Assigned 5.2.8. Transitive Opaque Extended Community Sub-Types
5.2.8. Transitive Opaque Extended Community Sub-Types The following note has been added to the "Transitive Opaque Extended
Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Transitive Opaque Extended Community
field") of an extended community, when the value of the first Sub-Types
octet (the "Type field") is 0x03.
Registry Name: TRANSITIVE OPAQUE RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x06 OSPF Route Type
0x0B Color Extended Community
0x0C Encapsulation Extended Community
0x0D Default Gateway
0x06 OSPF Route Type 5.2.9. Non-Transitive Opaque Extended Community Sub-Types
0x0B Color Extended Community
0x0C Encapsulation Extended Community
0x0D Default Gateway
5.2.9. Non-Transitive Opaque Extended Community Sub-Types The following note has been added to the "Non-Transitive Opaque
Extended Community Sub-Types" registry:
This registry shall contain the following note: 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.
This registry contains values of the second octet (the "Sub-Type Registry Name: Non-Transitive Opaque Extended Community
field") of an extended community, when the value of the first Sub-Types
octet (the "Type field") is 0x43.
Registry Name: NON-TRANSITIVE OPAQUE RANGE REGISTRATION PROCEDURE
EXTENDED COMMUNITY SUB-TYPES
RANGE REGISTRATION PROCEDURE 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x00-0xBF First Come, First Served SUB-TYPE VALUE NAME
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x00 BGP Origin Validation State
0x00 BGP Origin Validation State 5.2.10. Generic Transitive Experimental Use Extended Community
Sub-Types
5.2.10. Generic Transitive Experimental Use Sub-Types The following note has been added to the "Generic Transitive
Experimental Use Extended Community Sub-Types" registry:
Registry Name: BGP GENERIC TRANSITIVE EXPERIMENTAL USE This registry contains values of the second octet (the "Sub-Type"
EXTENDED COMMUNITY SUB-TYPES field) of an extended community when the value of the first octet
(the "Type" field) is 0x80.
RANGE REGISTRATION PROCEDURE Registry Name: Generic Transitive Experimental Use Extended Community
Sub-Types
0x00-0xBF First Come, First Served RANGE REGISTRATION PROCEDURE
0xC0-0xFF IETF Review
SUB-TYPE VALUE NAME 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
0x06 Flow spec traffic-rate SUB-TYPE VALUE NAME
0x07 Flow spec traffic-action (Use of the Value Field
is defined in the "Traffic Action Field"
registry)
0x08 Flow spec redirect
0x09 Flow spec traffic-remarking
0x0A Layer2 Info Extended Community
Note: RFC 5575 contains narrative text that declares the "Flow spec 0x06 Flow spec traffic-rate
traffic-rate" to be non-transitive, but then assigns it a codepoint that 0x07 Flow spec traffic-action (Use of the
indicates it to be transitive. Addressing this error in RFC 5575 is not "Value" field is defined in the
within the scope of the current document. "Traffic Action Fields" registry)
0x08 Flow spec redirect
0x09 Flow spec traffic-remarking
0x0A Layer2 Info Extended Community
5.2.11. Registries for the Value Field 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.
At the time of writing of this document, there is only one registry 5.2.11. Registries for the "Value" Field
containing codepoints for the Value Field of an Extended Community.
5.2.11.1. Traffic Action Field At the time of the writing of this document, there is only one
registry containing codepoints for the "Value" field of an Extended
Community.
This registry does not need to be modified. 5.2.11.1. Traffic Action Fields
5.3. Registries for IPv6-Address-Specific ECs This registry has not been modified.
5.3.1. Transitive Types 5.3. Registries for IPv6-Address-Specific ECs
This registry shall contain the following note: 5.3.1. Transitive Types
This registry contains values of the two high-order octets of an The following note has been added to the "Transitive
IPv6-Address-Specific Extended Communities attribute. IPv6-Address-Specific Extended Community Types" registry:
Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC This registry contains values of the two high-order octets of an
EXTENDED COMMUNITY TYPES IPv6-Address-Specific Extended Community.
RANGE REGISTRATION PROCEDURE Registry Name: Transitive IPv6-Address-Specific Extended
Community Types
0x0000-0x00FF First Come, First Served RANGE REGISTRATION PROCEDURE
TYPE VALUE NAME 0x0000-0x00FF First Come First Served
0x0002 Route Target TYPE VALUE NAME
0x0003 Route Origin
0x0004 OSPFv3 Route Attributes (deprecated)
0x000B VRF Route Import
0x0010 Cisco VPN-Distinguisher
0x0011 UUID-based Route Target
5.3.2. Non-Transitive Types 0x0002 Route Target
0x0003 Route Origin
0x0004 OSPFv3 Route Attributes (deprecated)
0x000B VRF Route Import
0x0010 Cisco VPN-Distinguisher
0x0011 UUID-based Route Target
This registry shall contain the following note: 5.3.2. Non-Transitive Types
This registry contains values of the two high-order octets of an The following note has been added to the "Non-Transitive
IPv6-Address-Specific Extended Communities attribute. IPv6-Address-Specific Extended Community Types" registry:
Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC This registry contains values of the two high-order octets of an
EXTENDED COMMUNITY TYPES IPv6-Address-Specific Extended Community.
RANGE REGISTRATION PROCEDURE Registry Name: Non-Transitive IPv6-Address-Specific Extended
Community Types
0x4000-0x40FF First Come, First Served RANGE REGISTRATION PROCEDURE
None assigned 0x4000-0x40FF First Come First Served
6. Security Considerations None assigned
6. Security Considerations
No security considerations are raised by this document. No security considerations are raised by this document.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Jon Mitchell, Hyojeong Kim, and Pearl Liang The authors wish to thank Jon Mitchell, Hyojeong Kim, and Pearl Liang
for their review and comments. for their review and comments.
The authors wish to thank Amanda Baber of IANA for educating us on 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 some of the problems faced by IANA staff when responding to requests
for BGP Extended Community Type and Sub-Type codepoint allocations. for BGP Extended Community Type and Sub-Type codepoint allocations.
8. Authors' Addresses 8. Normative References
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, November 2009.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
Authors' Addresses
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net
EMail: yakov@juniper.net
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA, 01719 Boxborough, MA 01719
Email: erosen@cisco.com
9. Normative References
[RFC3692] "Assigning Experimental and Testing Numbers Considered
Useful", Narten, RFC 3692, January 2004
[RFC4020] "Early IANA Allocation of Standards Track Code Points",
Kompella, Zinin, RFC 4020, February 2005
[RFC4360] "BGP Extended Communities Attribute", Sangli, Tappan,
Rekhter, RFC 4360, February 2006
[RFC5226] "Guidelines for Writing an IANA Considerations Section in
RFCs", Narten, Alvestrand, RFC 5226, May 2008
[RFC5701] "IPv6 Address Specific BGP Extended Community Attribute", EMail: erosen@cisco.com
Rekhter, RFC 5701, November 2009
 End of changes. 173 change blocks. 
392 lines changed or deleted 412 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/