Policy Behavior for Well-Known BGP Communities
updates
- rfc-1997 — BGP Communities Attribute
Extracted elements (15)
Authors of RFCs defining new community-like attributes (large communities, wide communities, etc.) should explicitly state how the 'set' directive and similar operations are expected to handle the new attribute, to avoid repeating the ambiguity of RFC 1997.
RFC 1997 did not prescribe fully how well-known communities may be manipulated by operator policies, leading to divergent implementations. This document exists to document those differences and prevent further divergence rather than mandate a single unified behavior, because changing existing implementations would be operationally disruptive.
Cisco IOS XR's list of communities exempted from 'set community' diverges from the IANA BGP Well-known Communities registry: several IANA well-known communities receive no special treatment in IOS XR, and community 0:0 (internet) which IOS XR does protect is not formally in the IANA well-known list (it falls in the Reserved range 0x00000000–0x0000FFFF).
In Cisco IOS XR, 'set community' removes all communities except six preserved well-known ones: internet (0:0), graceful-shutdown (65535:0), accept-own (65535:1), NO_EXPORT (65535:65281), NO_ADVERTISE (65535:65282), and NO_EXPORT_SUBCONFED/local-AS (65535:65283). Removing these requires explicit per-community enumeration.
In Juniper Networks' Junos OS, the 'community set' directive removes all communities, well-known or otherwise.
In OpenBGPD, 'set community' does not remove any communities, well-known or otherwise, making its behavior the most conservative and divergent from most other implementations.
Nokia SR OS's 'set' operation uses the keyword 'replace' and replaces all communities, well-known or otherwise, with the specified communities, matching Juniper and Huawei behavior.
Vendor implementations differ fundamentally: some (Juniper Junos, Huawei VRP, Extreme Brocade NetIron, Nokia SR OS) replace all communities including well-known ones on 'set', while others (Cisco IOS XR) preserve certain well-known communities, and OpenBGPD does not remove any communities at all.
BGP implementors MUST NOT create further inconsistencies in the treatment of well-known communities from this point forward. This is the central normative action of the document, updating RFC 1997.
Network operators are urged never to rely on any implicit understanding of a neighbor ASN's BGP community handling; before announcing prefixes with NO_EXPORT or any other community to a neighbor, operators should confirm with that neighbor how the community will be treated.
Vendors MUST clearly document the behavior of the 'set' directive in their implementations so operators can reason about community-manipulation policy behavior.
Vendors MUST ensure that their implementations' 'set' directive treatment of any specific community does not change if or when that community becomes a new well-known community through future standardization. For most implementations this means the 'set' directive MUST continue to remove the community; for those where 'set' removes no communities, that behavior MUST continue.
The 'set' directive is a common BGP policy syntax meaning 'remove any/all communities present on the route and apply this set of communities instead'. Implementations differ on whether this applies to well-known communities or only non-well-known ones.
IANA has listed RFC 8642 as an additional reference for the BGP Well-known Communities registry. No new communities are registered; the document supplements existing registry documentation.
Surprising defaults and undocumented behaviors in community manipulation are bad for security. The document's documentation of implementation divergence and its requirement for vendor documentation are intended to remedy this.