BGP Communities Attribute
RFC 1997

Document Type RFC - Proposed Standard (August 1996; Errata)
Updated by RFC 8642, RFC 7606
Authors Tony Li  , Ravi Chandra  , Paul Traina 
Last updated 2014-02-13
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1997 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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.


   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.

Chandra, et. al.            Standards Track                     [Page 1]
RFC 1997               BGP Communities Attribute             August 1996

Terms and Definitions

      A community is a group of destinations which share some common

      Each autonomous system administrator may define which communities
      a destination belongs to.  By default, all destinations belong to
      the general Internet community.


   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.


   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

   The COMMUNITIES attribute has Type Code 8.

Chandra, et. al.            Standards Track                     [Page 2]
RFC 1997               BGP Communities Attribute             August 1996

   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
Show full document text