BGP Communities Attribute
A tag on BGP routes that lets operators group destinations and apply policy to the whole group.
Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.
@misc{rfc1997,
series = {Request for Comments},
number = 1997,
howpublished = {RFC 1997},
publisher = {RFC Editor},
doi = {10.17487/RFC1997},
url = {https://www.rfc-editor.org/info/rfc1997},
author = {R. Chandra and P. Traina and T. Li},
title = {{BGP Communities Attribute}},
pagetotal = 5,
year = 1996,
month = aug,
} RFC text
Contents
Network Working Group R. Chandra
Request for Comments: 1997 P. Traina
Category: Standards Track cisco Systems
T. Li
August 1996
BGP 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.
Abstract
Border Gateway Protocol [1] is an inter-autonomous system routing
protocol designed for TCP/IP internets.
This document describes an extension to BGP which may be used to pass
additional information to both neighboring and remote BGP peers.
The intention of the proposed technique is to aid in policy
administration and reduce the management complexity of maintaining
the Internet.
Introduction
BGP supports transit policies via controlled distribution of routing
information. Mechanisms for this are described in [1] and have been
successfully used by transit service providers. However, control
over the distribution of routing information is presently based on
either IP address prefixes or on the value of the AS_PATH attribute
(or part of it).
To facilitate and simplify the control of routing information this
document suggests a grouping of destinations so that the routing
decision can also be based on the identity of a group. Such a scheme
is expected to significantly simplify a BGP speaker's configuration
that controls distribution of routing information.
Terms and Definitions
Community
A community is a group of destinations which share some common
property.
Each autonomous system administrator may define which communities
a destination belongs to. By default, all destinations belong to
the general Internet community.
Examples
A property such as "NSFNET sponsored/AUP" could be added to all AUP
compliant destinations advertised into the NSFNET. NSFNET operators
could define a policy that would advertise all routes, tagged or not,
to directly connected AUP compliant customers and only tagged routes
to commercial or external sites. This would insure that at least one
side of a given connection is AUP compliant as a way of enforcing NSF
transit policy guidelines.
In this example, we have just eliminated the primary motivation for a
complex policy routing database that is used to generate huge prefix
and AS path based filter rules. We have also eliminated the delays
caused by the out-of-band maintenance of this database (mailing in
NACRs, weekly configuration runs, etc.)
A second example comes from experience with aggregation. It is often
useful to advertise both an aggregate prefix and the component more-
specific prefixes that were used to form the aggregate to optimize
"next hop" routing. These component prefixes are only useful to the
neighboring BGP peer or perhaps the autonomous system of the
neighboring BGP peer, so it is desirable to filter this information.
By specifying a community value that the neighboring peer or peers
will match and filter on, these more specific routes may be
advertised with the assurance that they will not propagate beyond
their desired scope.
COMMUNITIES attribute
This document creates the COMMUNITIES path attribute is an optional
transitive attribute of variable length. The attribute consists of a
set of four octet values, each of which specify a community. All
routes with this attribute belong to the communities listed in the
attribute.
The COMMUNITIES attribute has Type Code 8.
Communities are treated as 32 bit values, however for administrative
assignment, the following presumptions may be made:
The community attribute values ranging from 0x0000000 through
0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
The rest of the community attribute values shall be encoded using an
autonomous system number in the first two octets. The semantics of
the final two octets may be defined by the autonomous system (e.g. AS
690 may define research, educational and commercial community values
that may be used for policy routing as defined by the operators of
that AS using community attribute values 0x02B20000 through
0x02B2FFFF).
Well-known Communities
The following communities have global significance and their
operations shall be implemented in any community-attribute-aware BGP
speaker.
NO_EXPORT (0xFFFFFF01)
All routes received carrying a communities attribute
containing this value MUST NOT be advertised outside a BGP
confederation boundary (a stand-alone autonomous system that
is not part of a confederation should be considered a
confederation itself).
NO_ADVERTISE (0xFFFFFF02)
All routes received carrying a communities attribute
containing this value MUST NOT be advertised to other BGP
peers.
NO_EXPORT_SUBCONFED (0xFFFFFF03)
All routes received carrying a communities attribute
containing this value MUST NOT be advertised to external BGP
peers (this includes peers in other members autonomous
systems inside a BGP confederation).
Operation
A BGP speaker may use this attribute to control which routing
information it accepts, prefers or distributes to other neighbors.
A BGP speaker receiving a route that does not have the COMMUNITIES
path attribute may append this attribute to the route when
propagating it to its peers.
A BGP speaker receiving a route with the COMMUNITIES path attribute
may modify this attribute according to the local policy.
Aggregation
If a range of routes is to be aggregated and the resultant aggregates
attribute section does not carry the ATOMIC_AGGREGATE attribute, then
the resulting aggregate should have a COMMUNITIES path attribute
which contains all communities from all of the aggregated routes.
Applicability
The COMMUNITIES path attribute may be used with BGP version 2 and all
subsequent versions of BGP unless specifically noted otherwise.
Security Considerations
Security issues are not discussed in this memo.
Acknowledgments
We'd like to thank Vince Fuller, Sean Doran, and Andrew Partan for
bringing to our attention the problems that we believe the BGP
communities attribute will help solve. We'd also like to thank Yakov
Rekhter his review of this document as well as his constructive and
valuable comments.
Authors' Addresses
Paul Traina
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
EMail: pst@cisco.com
Ravishanker Chandrasekeran
(Ravi Chandra)
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
EMail: rchandra@cisco.com
Tony Li
EMail: tli@skat.usc.edu
References
[1] RFC 1771
Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
March 1995.
[2] RFC 1965
Traina, P., "Autonomous System Confederations for BGP", June 1996.
ISO Plain Language
On this page
§1Grouping Destinations
Border Gateway Protocol (BGP) supports transit policies by controlling how routing information is distributed, but that control was based on IP address prefixes or on the value of the AS_PATH attribute. RFC 1997 suggests grouping destinations so a routing decision can also rest on a group identity. A community is a group of destinations that share some common property. Each autonomous system administrator defines which communities a destination belongs to; by default, every destination belongs to the general Internet community.
The RFC gives two examples. An operator could tag destinations that comply with an acceptable-use policy and advertise only tagged routes to commercial or external sites, instead of maintaining a large prefix and AS path filter database. Aggregation is a second use: component prefixes that form an aggregate are only useful to the neighboring peer, so they can carry a community value the neighbor matches and filters on, which keeps them from spreading beyond their desired scope.
BGP routers once matched long lists of addresses to decide what to share. This RFC lets an operator put one tag on a group of destinations and write the policy rule once, against the tag.
§2The COMMUNITIES Attribute
The RFC creates the COMMUNITIES path attribute: an optional transitive attribute of variable length, with Type Code 8. It holds a set of four-octet values, and every route carrying the attribute belongs to the communities listed in it.
Communities are treated as 32-bit values. For administrative assignment, two ranges are reserved: 0x0000000 through 0x0000FFFF, and 0xFFFF0000 through 0xFFFFFFFF. All other values are encoded with an autonomous system number in the first two octets. The meaning of the final two octets is defined by that autonomous system. For example, AS 690 may define its own community values from 0x02B20000 through 0x02B2FFFF.
Each community is a 32-bit code attached to a route. The first half of the code names the autonomous system that defined it, and the second half means whatever that autonomous system says it means. Two ranges of codes are reserved.
§3Well-known Values and Operation
Three well-known communities have global significance, and any community-aware BGP speaker must implement them. NO_EXPORT (0xFFFFFF01) means routes must not be advertised outside a BGP confederation boundary. NO_ADVERTISE (0xFFFFFF02) means routes must not be advertised to any other BGP peer. NO_EXPORT_SUBCONFED (0xFFFFFF03) means routes must not be advertised to external BGP peers, including peers in other member autonomous systems inside a confederation.
A speaker may use the attribute to control which routing information it accepts, prefers or distributes. A speaker that receives a route without the attribute may add it when passing the route on, and may modify the attribute by local policy. If routes are aggregated and the result does not carry the ATOMIC_AGGREGATE attribute, the aggregate should carry all communities from all of the aggregated routes. The attribute works with BGP version 2 and later versions. The RFC states that security issues are not discussed.
Three tag values have the same meaning in every network: do not export this route, do not advertise it to any peer, or keep it inside the confederation. Routers can also add, change or filter tags under their own policy.
- 0xFFFFFF01NO_EXPORT — Do not advertise outside a confederation boundary.
- 0xFFFFFF02NO_ADVERTISE — Do not advertise to other BGP peers.
- 0xFFFFFF03NO_EXPORT_SUBCONFED — Do not advertise to external BGP peers.