Network Working Group S. Sangli
Request for Comments: 4360 D. Tappan
Category: Standards Track Cisco Systems
Y. Rekhter
Juniper Networks
February 2006
BGP Extended Communities Attribute
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the "extended community" BGP-4 attribute.
This attribute provides a mechanism for labeling information carried
in BGP-4. These labels can be used to control the distribution of
this information, or for other applications.
1. Introduction
The Extended Community Attribute provides a mechanism for labeling
information carried in BGP-4 [BGP-4]. It provides two important
enhancements over the existing BGP Community Attribute [RFC1997]:
- An extended range, ensuring that communities can be assigned for
a plethora of uses, without fear of overlap.
- The addition of a Type field provides structure for the
community space.
The addition of structure allows the usage of policy based on the
application for which the community value will be used. For example,
one can filter out all communities of a particular type, or allow
only certain values for a particular type of community. It also
allows one to specify whether a particular community is transitive or
non-transitive across an Autonomous System (AS) boundary. Without
structure, this can only be accomplished by explicitly enumerating
Sangli, et al. Standards Track [Page 1]
RFC 4360 BGP Extended Communities Attribute February 2006
all community values that will be denied or allowed and passed to BGP
speakers in neighboring ASes based on the transitive property.
1.1. Specification of Requirements
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].
2. BGP Extended Communities Attribute
The Extended Communities Attribute is a transitive optional BGP
attribute, with the Type Code 16. The attribute consists of a set of
"extended communities". All routes with the Extended Communities
attribute belong to the communities listed in the attribute.
Each Extended Community is encoded as an 8-octet quantity, as
follows:
- Type Field : 1 or 2 octets
- Value Field : Remaining octets
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low(*) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(*) Present for Extended types only, used for the Value field
otherwise.
Type Field:
Two classes of Type Field are introduced: Regular type and
Extended type.
The size of Type Field for Regular types is 1 octet, and the
size of the Type Field for Extended types is 2 octets.
The value of the high-order octet of the Type Field determines
if an extended community is a Regular type or an Extended type.
The class of a type (Regular or Extended) is not encoded in the
structure of the type itself. The class of a type is specified
in the document that defines the type and the IANA registry.
Sangli, et al. Standards Track [Page 2]
RFC 4360 BGP Extended Communities Attribute February 2006
The high-order octet of the Type Field is as shown below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
datatracker.ietf.org