Summary

  • RFC 8092 defines an optional transitive attribute whose values contain a Global Administrator namespace and two operator-defined data fields.
  • A syntactically valid value can request or describe policy, but it does not authenticate who attached it, guarantee integrity, or oblige the receiving AS to act.

More space, the same governance question

The original BGP Communities attribute gave operators a compact way to label routes. A common convention divided its 32 bits into a two-octet ASN and a two-octet local value. Four-octet ASNs broke that convenient fit. RFC 8092 answers with a 12-octet value: four octets for the Global Administrator and four octets for each of two local data parts. An attribute can carry an unordered set of those values.

The format restores room for operator-defined signalling. It also creates a clean namespace boundary. When the Global Administrator is an ASN, the owner of that ASN defines what the two remaining numbers mean. The canonical form is three unsigned decimal integers separated by colons, without leading zeros. Duplicate values must not be transmitted, receivers silently remove redundancies, and their order carries no meaning.

Those are facts about representation and handling. They do not answer the governance question: who may ask for an action, and who has power to perform it? RFC 8195 makes the distinction practical. Informational communities can describe where a route entered a network, the relationship attached to it, or its intended audience. Action communities can request changes to propagation, local preference, next hop, or prepending. In either case, the operator of the relevant AS defines the policy.

A namespace is not a mandate

The first field is often called the Global Administrator, but it is not an administrator account and it does not remotely control another router. It says whose namespace supplies the meaning. A customer may attach a value using its provider’s ASN to request a documented action. Any AS can also attach such a value, including one with a non-adjacent ASN. The receiver therefore needs more than syntax: it needs a policy that says which neighbors may make which requests, on which routes, and in what order competing signals are processed.

That is the authorization boundary. The sender can express intent; the receiver owns enforcement. A transit provider may honor a customer’s request to reduce propagation while ignoring the same value from an unauthorized peer. A route server may offer clients documented distribution controls while retaining safeguards that prevent one client from rewriting another’s reachability. The attribute carries a message. The commercial relationship, configuration, and local policy decide whether that message has standing.

This separation identifies the beneficiaries. Customers gain a portable way to ask for treatment without opening a ticket for every route. Providers and peers gain structured labels that can support predictable automation, troubleshooting, and capacity planning. Operations teams gain a shared vocabulary. But each benefit depends on published semantics and observable handling rather than the field name alone.

Transitivity without integrity

Large Communities are optional and transitive. That helps a signal survive beyond the AS that first propagated it, but RFC 8092 is explicit about the cost: the mechanism does not protect the integrity of a value. An intermediate AS may add, remove, or alter communities. Trust in every AS along the path, or some separate mechanism, is required if a receiver wants to infer provenance. The standard does not provide that mechanism.

Aggregation adds another operational burden. The resulting aggregate is expected to contain the Large Communities of its component routes. Signals can accumulate, collide, or become ambiguous when policies combine. Malformed lengths are handled with treat-as-withdraw, but an unallocated or reserved number in the Global Administrator field does not by itself make the attribute malformed. Protocol validity and policy legitimacy remain different tests.

The cost is therefore governance work: maintain a public repertoire, validate the neighbor and route context, publish processing order, monitor unexpected additions or stripping, test aggregation, and preserve a rollback path. A community that is convenient to automate is also convenient to misinterpret at scale.

Evidence and limits

RFC 8092 defines the wire format, canonical representation, aggregation, duplicate handling, errors, and lack of integrity protection. RFC 8195 provides operator use cases and distinguishes informational from action communities. RFC 1997 supplies the earlier community model; RFC 7454 provides broader BGP operational guidance. The conclusions about power, beneficiaries, cost, and institutional control are analysis grounded in those facts.

The sources do not prove deployment by a named operator. They do not authenticate the AS that attached a value, require a receiver to honor it, define a universal conflict order, or guarantee preservation along every path. A value can be correctly formatted and still be unauthorized, stale, altered, or irrelevant.

Sources