BGP Extended Communities Attribute
updated by
Extracted elements (24)
Regular types use a 1-octet Type Field; Extended types use a 2-octet Type Field. The class (Regular or Extended) is not encoded in the type structure itself but is specified in the defining document and IANA registry. This allows policy filtering by type without exhaustive enumeration of community values.
The Extended Communities Attribute was designed to overcome two limitations of RFC 1997 BGP Communities: it provides an extended range to avoid overlap across many uses, and the addition of a structured Type Field enables policy based on community application type and explicit transitive/non-transitive designation.
The Local Administrator sub-field in Two-Octet AS Specific and IPv4 Address Specific communities is intentionally free-form: the organization identified by the Global Administrator field can encode any information, with semantics defined per sub-type. This delegation model avoids centralized coordination for local numbering spaces.
When the Route Target or Route Origin community's high-order type octet is 0x02, the Global Administrator sub-field carries a four-octet AS number, extending support to four-octet AS number spaces beyond the two-octet AS Specific community type.
A route may carry both the BGP Communities attribute (RFC 1997) and the Extended BGP Communities attribute simultaneously. In this case, each attribute is handled independently per its respective specification.
By default, when routes are aggregated without the ATOMIC_AGGREGATE attribute, the resulting aggregate SHOULD carry an Extended Communities attribute containing the set union of all Extended Communities from the aggregated routes. This default may be overridden by local configuration.
A BGP speaker receiving a route with the Extended Communities attribute MAY modify this attribute according to local policy.
A BGP speaker receiving a route without the Extended Communities attribute MAY append this attribute when propagating it to peers.
A Type value allocated for a regular Type MUST NOT be reused as the high-order octet when allocating an extended Type, and vice versa, to prevent ambiguity in the type space.
If a route has a non-transitive extended community, the community SHOULD be removed before advertising the route across an Autonomous System boundary, but SHOULD NOT be removed when advertising across a BGP Confederation boundary.
The Extended Communities attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops.
The BGP Extended Communities Attribute is a transitive optional BGP-4 attribute with Type Code 16. It consists of a set of extended communities, each encoded as an 8-octet quantity. All routes carrying this attribute belong to the communities listed.
The Route Origin Community identifies one or more routers that inject a set of routes into BGP. It is transitive across AS boundaries. The high-order octet of the Type field is 0x00, 0x01, or 0x02; the low-order octet is 0x03.
The Route Target Community identifies one or more routers that may receive a set of routes carrying this community. It is transitive across AS boundaries. The high-order octet of the Type field is 0x00, 0x01, or 0x02; the low-order octet is 0x02.
IANA created the 'BGP Extended Communities Type' registry for 8-bit (regular) and 16-bit (extended) Type values. Transitive regular types 0x00–0x3f and extended types 0x0000–0x3fff use First Come First Served; 0x90–0xbf (regular) and 0x9000–0xbfff (extended) use Standards Action or Early IANA Allocation. Values 0x80–0x8f, 0xc0–0xcf, 0x8000–0x8fff, 0xc000–0xcfff are reserved for Experimental use.
IANA created the 'IPv4 Address Specific Extended Community' registry. Transitive sub-types range 0x0100–0x01ff; non-transitive 0x4100–0x41ff. This document assigns IPv4 address specific Route Target (0x0102) and Route Origin (0x0103).
IANA created the 'Opaque Extended Community' registry. Transitive sub-types range 0x0300–0x03ff; non-transitive 0x4300–0x43ff. Future assignments use First Come First Served.
IANA created the 'Two-octet AS Specific Extended Community' registry. Transitive sub-types range 0x0000–0x00ff; non-transitive 0x4000–0x40ff. This document assigns Route Target (0x0002) and Route Origin (0x0003). Future assignments use First Come First Served.
The Extended Communities Attribute has similar security implications as the BGP Communities attribute (RFC 1997). An operator relying on BGP-carried information must have a transitive trust relationship back to the source; this document does not specify mechanisms for establishing such trust.
Each Extended Community is encoded as 8 octets: a Type Field of 1 or 2 octets followed by a Value Field occupying the remaining octets. Two communities are equal only when all 8 octets match.
The high-order octet of the Type Field encodes two control bits: bit I (IANA authority, 0=First Come First Serve, 1=Standard/Early IANA/Experimental) and bit T (transitive, 0=transitive across ASes, 1=non-transitive). The remaining 6 bits indicate community structure.
The IPv4 Address Specific Extended Community uses a 2-octet Type Field (high-order octet 0x01 or 0x41, low-order octet is sub-type) and a 6-octet Value Field split into a 4-octet Global Administrator sub-field (an IPv4 unicast address) and a 2-octet Local Administrator sub-field.
The Opaque Extended Community uses a 2-octet Type Field (high-order octet 0x03 or 0x43, low-order octet is sub-type) and a 6-octet opaque Value Field whose sub-type encoding is assigned by IANA.
The Two-Octet AS Specific Extended Community uses a 2-octet Type Field (high-order octet 0x00 or 0x40, low-order octet is sub-type) and a 6-octet Value Field split into a 2-octet Global Administrator sub-field (an IANA-assigned AS number) and a 4-octet Local Administrator sub-field.