Editing Border Gateway Protocol (section)

=== Communities ===

BGP communities are attribute tags that can be applied to incoming or outgoing prefixes to achieve some common goal.<ref>{{IETF RFC|1997}}</ref> While it is common to say that BGP allows an administrator to set policies on how prefixes are handled by ISPs, this is generally not possible, strictly speaking. For instance, BGP natively has no concept to allow one AS to tell another AS to restrict advertisement of a prefix to only North American peering customers. Instead, an ISP generally publishes a list of well-known or proprietary communities with a description for each one, which essentially becomes an agreement of how prefixes are to be treated.

{| class="wikitable"
|+ Well-known BGP communities<ref>{{Cite web |title=Border Gateway Protocol (BGP) Well-known Communities |url=https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml |access-date=2022-12-04 |website=www.iana.org}}</ref>
! Attribute value  !! Attribute  !! Description !! Reference
|-
| 0x00000000–0x0000FFFF || Reserved ||  || {{IETF RFC|1997}}
|-
| 0x00010000–0xFFFEFFFF || Reserved for private use ||  || {{IETF RFC|1997}}
|-
| 0xFFFF0000 || GRACEFUL_SHUTDOWN || At neighbor AS-peer, set LOCAL_PREF, lower to route away from source.  || {{IETF RFC|8326}}
|-
| 0xFFFF0001 || ACCEPT_OWN || Used to modify how a route originated within one VRF is imported into other VRFs ||  {{IETF RFC|7611}}
|-
| 0xFFFF0002 || ROUTE_FILTER_TRANSLATED_v4 ||  || RFC draft-l3vpn-legacy-rtc
|-
| 0xFFFF0003 || ROUTE_FILTER_v4 ||  || RFC draft-l3vpn-legacy-rtc
|-
| 0xFFFF0004 || ROUTE_FILTER_TRANSLATED_v6 ||  || RFC draft-l3vpn-legacy-rtc
|-
| 0xFFFF0005 || ROUTE_FILTER_v6 ||  || RFC  draft-l3vpn-legacy-rtc
|-
| 0xFFFF0006 || LLGR_STALE || Stale routes are retained for longer after a session failure  || {{IETF RFC|9494}}
|-
| 0xFFFF0007 || NO_LLGR || LLGR capability should not apply || {{IETF RFC|9494}}
|-
| 0xFFFF0008 || accept-own-nexthop ||  || RFC draft-agrewal-idr-accept-own-nexthop
|-
| 0xFFFF0009 || Standby PE || Allow for faster recovery of connectivity on different types of failures, with multicast in BGP/MPLS VPNs.  || {{IETF RFC|9026}}
|-
| 0xFFFF029A || BLACKHOLE || To temporarily protect against [[denial-of-service attack]] by asking the neighbour AS to discard all traffic to the prefix (blackholing)  || {{IETF RFC|7999}}
|-
| 0xFFFFFF01 || NO_EXPORT || Limit to a BGP confederation boundary || {{IETF RFC|1997}}
|-
| 0xFFFFFF02 || NO_ADVERTISE || Limit to a BGP peer || {{IETF RFC|1997}}
|-
| 0xFFFFFF03 || NO_EXPORT_SUBCONFED || Limit to an AS ||{{IETF RFC|1997}}
|-
| 0xFFFFFF04 || NOPEER || "No need" to advertise over a peer link || {{IETF RFC|3765}}
|}

Examples of common communities include:
* local preference adjustments,
* geographic 
* peer type restrictions
* [[denial-of-service attack]] identification
* AS prepending options.

An ISP might state that any routes received from customers with following examples:
*   To Customers North America (East Coast) 3491:100
*   To Customers North America (West Coast) 3491:200
The customer simply adjusts their configuration to include the correct community or communities for each route, and the ISP is responsible for controlling who the prefix is advertised to. The end user has no technical ability to enforce correct actions being taken by the ISP, though problems in this area are generally rare and accidental.<ref>{{Cite web |title=BGP Community Support {{!}} iFog GmbH |url=https://ifog.ch/en/blog/bgp-community-support |access-date=2022-12-04 |website=ifog.ch}}</ref><ref>{{Cite web |title=BGP communities |url=https://retn.net/bgp-communities |access-date=2022-12-04 |website=retn.net |language=en}}</ref>

It is a common tactic for end customers to use BGP communities (usually ASN:70,80,90,100) to control the local preference the ISP assigns to advertised routes instead of using MED (the effect is similar). The community attribute is transitive, but communities applied by the customer very rarely propagated outside the next-hop AS. Not all ISPs give out their communities to the public.<ref>{{cite web|title=BGP Community Guides|url=http://www.onesc.net/communities/|access-date=13 April 2015}}</ref>

==== BGP Extended Community Attribute ====
The BGP Extended Community Attribute was added in 2006,<ref>{{IETF RFC|4360}}</ref> in order to extend the range of such attributes and to provide a community attribute structuring by means of a type field. The extended format consists of one or two octets for the type field followed by seven or six octets for the respective community attribute content. The definition of this Extended Community Attribute is documented in RFC 4360. The IANA administers the registry for BGP Extended Communities Types.<ref>{{Cite web |title=Border Gateway Protocol (BGP) Extended Communities |url=https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml |access-date=2022-12-04 |website=www.iana.org}}</ref> The Extended Communities Attribute itself is a transitive optional BGP attribute. A bit in the type field within the attribute decides whether the encoded extended community is of a transitive or non-transitive nature. The IANA registry therefore provides different number ranges for the attribute types. Due to the extended attribute range, its usage can be manifold. RFC 4360 exemplarily defines the "Two-Octet AS Specific Extended Community", the "IPv4 Address Specific Extended Community", the "Opaque Extended Community", the "Route Target Community", and the "Route Origin Community". A number of BGP QoS drafts also use this Extended Community Attribute structure for inter-domain QoS signalling.<ref>[http://www.bgp-qos.org/forum/viewforum.php?f=6 IETF drafts on BGP signalled QoS] {{webarchive|url=https://web.archive.org/web/20090223214439/http://www.bgp-qos.org/forum/viewforum.php?f=6 |date=2009-02-23 }}, Thomas Knoll, 2008</ref>

With the introduction of 32-bit AS numbers, some issues were immediately obvious with the community attribute that only defines a 16-bit ASN field, which prevents the matching between this field and the real ASN value. Since RFC 7153, extended communities are compatible with 32-bit ASNs. RFC 8092 and RFC 8195 introduce a Large Community attribute of 12 bytes, divided in three field of 4 bytes each (AS:function:parameter).<ref>{{cite web |url=http://largebgpcommunities.net/ |title=Large BGP Communities |access-date=2021-11-27}}</ref>