IANA Registries for BGP Extended Communities
Extracted elements (23)
IPv6-Address-Specific Extended Community sub-type codepoints were historically suggested to match IPv4-Address-Specific sub-types, but actual IANA allocations did not always match. RFC 7153 resolves this by creating independent IPv6-specific registries decoupled from the IPv4 registries.
RFC 4360 was insufficiently specific about how IANA registries for Extended Community Types and Sub-Types should be organized, causing confusion. RFC 7153 reorganizes these registries to remove interdependencies, making IANA codepoint allocation more straightforward without changing any protocol semantics or affecting implementations.
All registry reorganization changes are compatible with existing codepoint allocations and do not affect protocol implementations. Only the 'IANA Considerations' sections of future protocol specifications will be impacted.
RFC 5575 contains narrative text declaring the 'Flow spec traffic-rate' to be non-transitive, but assigns it a codepoint (0x06 under Type 0x80) indicating transitive. This error in RFC 5575 is noted but not corrected by RFC 7153.
This document modifies RFC 5701 by removing any requirement for the second octet of IPv6-Address-Specific Extended Community Type codepoints to match the codepoints in IPv4-Address-Specific Sub-Types registries. Separate transitive and non-transitive IPv6-Address-Specific registries are established.
When a codepoint is needed for a new Extended Community, the requester SHOULD first determine whether an existing Type can be used. If a new Type is needed with Sub-Types, the requester must specify whether an existing Sub-Type registry can be reused or a new one is needed.
When requesting allocations from both Transitive and Non-Transitive Type registries simultaneously, if the requester wants both allocations to share the same low-order six bits, it is the requester's responsibility to explicitly request this of IANA.
When requesting the same codepoint value across multiple Sub-Type registries (a common practice for communities that span multiple types), it is the requester's explicit responsibility to ask IANA to allocate the same value in each registry.
Sub-Type registries always have a range of 0x00-0xFF. Values 0x00-0xBF are assignable under 'First Come First Served' policy; values 0xC0-0xFF are assignable under 'IETF Review' policy.
Whether a given Extended Community Type has Sub-Types is determined when the Type is initially defined and cannot be changed later. When requesting a new Type, the requester must specify whether a Sub-Type registry is to be associated with that Type.
BGP Non-Transitive Extended Community Types registry: range 0x40-0x7F is First Come First Served, 0xC0-0xCF is Experimental Use, 0xD0-0xFF is Standards Action. Assigned values include 0x40 (Non-Transitive Two-Octet AS-Specific), 0x41 (Non-Transitive IPv4-Address-Specific), 0x42 (Non-Transitive Four-Octet AS-Specific), 0x43 (Non-Transitive Opaque), 0x44 (QoS Marking).
BGP Transitive Extended Community Types registry: range 0x00-0x3F is First Come First Served, 0x80-0x8F is Experimental Use, 0x90-0xBF is Standards Action. Assigned values include 0x00 (Two-Octet AS-Specific), 0x01 (IPv4-Address-Specific), 0x02 (Four-Octet AS-Specific), 0x03 (Opaque), 0x04 (QoS Marking), 0x05 (CoS Capability), 0x06 (EVPN), 0x08 (Flow spec redirect), 0x80 (Generic Transitive Experimental).
EVPN Extended Community Sub-Types registry (for Type 0x06): 0x00-0xBF First Come First Served, 0xC0-0xFF IETF Review. Assigned sub-types: 0x00 (MAC Mobility), 0x01 (ESI MPLS Label), 0x02 (ES Import).
Generic Transitive Experimental Use Extended Community Sub-Types registry (for Type 0x80): assigned values include 0x06 (Flow spec traffic-rate), 0x07 (Flow spec traffic-action), 0x08 (Flow spec redirect), 0x09 (Flow spec traffic-remarking), 0x0A (Layer2 Info Extended Community).
Non-Transitive IPv6-Address-Specific Extended Community Types registry: range 0x4000-0x40FF First Come First Served. No values currently assigned.
Non-Transitive Opaque Extended Community Sub-Types registry (for Type 0x43): assigned value 0x00 (BGP Origin Validation State).
Transitive Four-Octet AS-Specific Extended Community Sub-Types registry (for Type 0x02): assigned values include 0x02 (Route Target), 0x03 (Route Origin), 0x04 (Generic), 0x05 (OSPF Domain Identifier), 0x08 (BGP Data Collection), 0x09 (Source AS), 0x10 (Cisco VPN Identifier).
Transitive IPv4-Address-Specific Extended Community Sub-Types registry (for Type 0x01): assigned values include 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).
Transitive IPv6-Address-Specific Extended Community Types registry: range 0x0000-0x00FF First Come First Served. Assigned values include 0x0002 (Route Target), 0x0003 (Route Origin), 0x0004 (OSPFv3 Route Attributes, deprecated), 0x000B (VRF Route Import), 0x0010 (Cisco VPN-Distinguisher), 0x0011 (UUID-based Route Target).
Transitive Opaque Extended Community Sub-Types registry (for Type 0x03): assigned values include 0x06 (OSPF Route Type), 0x0B (Color Extended Community), 0x0C (Encapsulation Extended Community), 0x0D (Default Gateway).
Transitive Two-Octet AS-Specific Extended Community Sub-Types registry (for Type 0x00): assigned values include 0x02 (Route Target), 0x03 (Route Origin), 0x05 (OSPF Domain Identifier), 0x08 (BGP Data Collection), 0x09 (Source AS), 0x0A (L2VPN Identifier), 0x10 (Cisco VPN-Distinguisher).
No security considerations are raised by this document. The reorganization of IANA registries is purely administrative and does not alter protocol semantics or behavior.
A BGP Extended Community is an eight-octet quantity. The high-order octet is the 'Type' field. For 'Extended Types', the second octet is a 'Sub-Type' field and the remaining six octets are the 'Value' field. For 'Regular Types', there is no Sub-Type and the Value field occupies seven octets.