Summary

  • RFC 8092 made room for a four-octet namespace, function and parameter. It did not make the Global Administrator an authenticated sender, protect the tuple from alteration, or require the named AS to execute it.
  • A Large Community becomes operational authority only where a receiving policy admits the sender, interprets the function, validates the parameter and changes route handling. Evidence must follow that whole chain from received bytes to packets.
  • Safe adoption separates informational values from executable actions, scrubs unauthorized use of the local namespace, preserves legitimate foreign context, canaries mixed deployments and provides a rollback that accounts for route state as well as configuration.

A valid instruction from the wrong principal

Consider a synthetic multihomed customer, AS 4200004100, attached to two transit providers and an Internet exchange route server. Its primary provider publishes a Large Community dictionary. One value asks the provider to lower LOCAL_PREF for a prefix in a named region; another requests that the prefix not be distributed to one peer class. The customer attaches the documented tuples before moving traffic away from a congested link.

The first provider receives the UPDATE from the contracted customer, confirms that this customer may use the two action functions, validates the parameters and applies its current policy version. Its Adj-RIB-In retains the received values. Its policy trace records the authorization match. Its Loc-RIB shows the intended preference change, its Adj-RIB-Out proves the bounded export result, and packet measurements show traffic moving through the planned alternative.

The second provider has completed only half of a migration. Some edge routers understand Large Communities; an older import rule set deletes the entire attribute before the common policy stage. The route remains reachable and the BGP session stays green, but the requested action never exists inside the decision process. A dashboard that checks only neighbor state and received prefix count reports success.

The third provider has the opposite defect. Its policy matches the provider's own Global Administrator value wherever it appears, without first checking which neighbor was permitted to invoke that function. A peer—or a customer of a customer—can attach the same syntactically valid tuple. If the receiving policy executes it, the outsider has not forged a packet format. It has crossed an authorization boundary that the operator forgot to build.

Nothing in this incident requires broken RFC 8092 encoding. The three-part value can be perfectly formed in all cases. The failure lies between representation, authorship, permission, interpretation and observed result.

Why twelve octets were needed

RFC 1997 Communities are four-octet values. Operational practice commonly split the value into two 16-bit fields: an ASN-like high word and a locally defined low word. That convention was compact and useful, but a four-octet ASN cannot fit inside its 16-bit namespace position.

Extended Communities added structure and an eight-octet value. RFC 5668 defined a four-octet-AS-specific form, yet its Global Administrator consumes four octets and its Local Administrator has only two. That works for the typed purposes the attribute defines, but it cannot support the common desire to place full-width ASNs or other four-octet values in both the operator namespace and local policy data.

RFC 8092 answered with a deliberately simple value: four octets for Global Administrator, four for Local Data Part 1 and four for Local Data Part 2. IANA assigned path attribute type code 32. RFC 8195 then offered an operational convention that reads naturally as ASN:Function:Parameter.

The design expands expressiveness without pretending to standardize every operator's vocabulary. One network can define a function for import location, another for relationship class, another for selective export, and another for a bounded preference request. This is the strength of the mechanism. It is also the reason the receiving boundary matters so much: the wire format can carry a meaning, but only local policy can decide what that meaning is allowed to do.

Namespace is not signature

RFC 8092 says the Global Administrator should be an ASN. When it is, the owner of that ASN defines how the two local fields are interpreted. That is namespace allocation, not cryptographic authorship.

A route bearing 64497:9:3 does not prove that AS 64497 attached it. It does not prove that the immediate neighbor was authorized to request function 9. It does not prove that an intermediate preserved the value, or that the receiving AS still maps parameter 3 to the definition printed on a public web page. RFC 8092 is explicit that an intermediate AS may add, delete or alter Large Communities and that the attribute does not protect value integrity.

Even the field's numeric plausibility is not an authentication check. RFC 8092 discourages reserved ASNs 0, 65535 and 4294967295 as Global Administrators, but a reserved, unassigned or unallocated value does not make the attribute malformed. A parser answers whether the value is twelve well-formed octets. An authorization policy answers whether this neighbor may cause this action. Those are different questions and must produce different evidence.

Transport protection does not close the gap end to end. TCP-AO or another session control can help identify the peer on one hop. It cannot attest who created a transitive value several ASes earlier or whether every intermediate left it untouched. RPKI origin validation answers whether an origin AS is authorized for a prefix under the available ROA. It does not validate community authorship or permission to alter LOCAL_PREF inside another network.

Information and action share a format, not a risk class

RFC 8195 divides common uses into informational and action communities. An informational value might record where a route entered, the relationship class of the neighbor, or its intended audience. It can help debugging, capacity planning and downstream interpretation. An action value asks a network to do something: alter propagation, set LOCAL_PREF, change a next hop or add AS_PATH prepends.

The bits do not announce which class they belong to. The operator's dictionary and policy do. If the dictionary is unpublished, stale or inconsistent across routers, the same tuple can be telemetry in one place and executable input in another.

That distinction should appear in the namespace design. Information and action functions need separate documented ranges. Every action needs a named owner, authorized sender classes, a parameter domain, conflict precedence, affected address families, expiry behavior and a rollback. A request to lower preference in one region must not silently become permission to lower it globally. A value intended for one customer contract must not become a capability inherited by every peer group that shares a configuration fragment.

RFC 8195 encourages operators to publish the meanings of both informational and action values they support or make visible. Publication is necessary for coordination but remains only the specification layer. The running policy version, received route, matched rule and forwarding outcome are the execution layer.

Scrub your commands; preserve other people's context

RFC 7454 supplies a useful authority boundary. It recommends scrubbing inbound communities that use the receiving network's own number in the namespace position, permitting only those signals that customers or peers are allowed to use. It also recommends not generally deleting other communities, because customers may need them to communicate with networks farther along the path.

Applied to Large Communities, the rule is not “delete everything” and not “preserve everything.” It is a classification problem.

A receiver should distinguish at least four sets:

  1. Local-namespace action values the immediate neighbor is explicitly authorized to invoke.
  2. Local-namespace informational values the receiver itself may attach or accept under a documented contract.
  3. Foreign values that should remain opaque and transitive because downstream networks may rely on them.
  4. Values prohibited by policy because they are unauthorized, deprecated, nonsensical in this relationship or dangerous in combination.

Blanket preservation lets a customer synthesize a provider-owned action if the provider matches the tuple without checking the session class. Blanket deletion breaks legitimate coordination that should pass through. Replacing the set while adding one local mark can erase evidence attached earlier. Additive behavior can preserve that evidence, but it may also accumulate obsolete or conflicting values unless the policy has explicit cleanup.

Route servers complicate the rule by design. RFC 7948 describes an environment where clients may use communities to control per-client export. RFC 8195 gives Large Community examples for announce-to-all, announce-to-none and specific exceptions. Here, allowing a client to influence export is not a security accident; it is the service contract. The route-server operator must still authenticate the client session, bind allowed functions to that client, resolve conflicts and prove the resulting Adj-RIB-Out per recipient. An exception designed for this broker must not leak into ordinary transit policy sets.

A set has no first command

RFC 8092 defines the attribute as an unordered set. Encoding order has no significance. A policy that resolves conflict by “first value wins” is imposing an implementation artifact on a protocol set.

Duplicate values must not be sent, and receivers silently remove redundant duplicates. That prevents multiplicity from becoming an accidental counter. It also means an observer cannot use repeated identical values as evidence that several parties endorsed the action. Once normalized, one value remains.

Matching semantics deserve the same precision. “Contains 64497:9:3” is different from “the complete set equals these values.” A match-any rule is different from match-every; a policy that treats an empty set as satisfying a broad containment expression can surprise an operator. Current Cisco IOS XR documentation exposes several of these matching forms as well as additive setting, deletion and attribute filtering. FRRouting exposes value and exact-set readback, including JSON. Those tools make evidence possible. They do not select a safe policy on the operator's behalf.

Aggregation adds another boundary. RFC 8092 says an aggregate should contain the union of the Large Communities attached to its contributors. This preserves information, but the union may carry values that do not describe every component uniformly. If one more-specific requested backup preference and another requested selective export, the aggregate can inherit both. A receiver must not assume that union means unanimous instruction. Operators need an explicit rule for which action classes are allowed to survive aggregation and how contributor evidence is retained.

Malformed is not unauthorized

Wire validity has one crisp edge. A Large Communities attribute value must be a non-zero multiple of twelve octets. If it is not, RFC 8092 invokes RFC 7606 treat-as-withdraw.

That action contains the failure better than resetting the whole BGP session. It can also hide behind healthy session telemetry. KEEPALIVEs continue, the peer remains Established, and unrelated routes survive while the affected NLRI disappears from Adj-RIB-In. The operator must correlate the raw attribute error with the route delta and service impact.

An unauthorized but correctly encoded tuple is different. It should reach the authorization decision, fail that decision and produce an auditable policy outcome. Depending on the contract, the safe response might strip the unauthorized local action while preserving the route, reject the route, or quarantine it for review. Calling every permission failure “malformed” erases whether the parser, the dictionary or the principal boundary failed.

The migration is a distributed program change

The dangerous migration is not merely from an old four-octet Community to a new twelve-octet one. It is from one distributed program to another. Producers, edge import policies, route reflectors, route servers, collectors, customer documentation and incident tooling all need the same epoch.

Dual signalling can help while some neighbors understand only the legacy value. It can also cause the action to execute twice, or execute with different parameters when old and new dictionaries drift. A router that strips Large Communities while preserving ordinary Communities may appear compatible until the legacy signal is retired. A collector that stores the new tuple while a decision policy still ignores it proves transport, not adoption.

The canary should therefore use a prefix whose expected outcome is safe and independently measurable. Record the received legacy and large sets, the normalized set after scrubbing, the exact rule and policy version, the changed attribute or export decision, every relevant Adj-RIB-Out, the selected route, the installed next hop and packet behavior. Test an unauthorized sender as well as an authorized one. Test malformed length in a lab, not on production peers. Test aggregation if the service creates aggregates.

Rollback must specify state, not only configuration. Removing the new rule may leave routes selected under the earlier LOCAL_PREF until policy is reevaluated. A route refresh can rebuild the view, but its scope and timing must be controlled. A hard session reset has a larger convergence cost. If the community action helped produce a BGP wedgie—a stable but unintended policy state—restoring a single line may not restore the intended traffic pattern. RFC 4264 shows why coordinated changes can be necessary.

The evidence ledger

For each received route, retain the peer and peer class, prefix, AFI/SAFI, session epoch, raw received Large Community set, normalized set, removed values, values added locally, dictionary version, authorization result, matched policy clause and resulting route attributes. Preserve the Loc-RIB selection reason, Adj-RIB-Out sets per neighbor class, FIB next hop and packet probes.

This ledger answers different questions without collapsing them:

  • Was it carried? Raw UPDATE and Adj-RIB-In evidence.
  • Was it well formed? Parser result and RFC 8092 length handling.
  • Was it authorized? Peer identity, relationship class and function allowlist.
  • What did it mean here? Dictionary and policy version.
  • Was it executed? LOCAL_PREF, next-hop, prepend or export delta.
  • Did the service move? FIB and packet observations.
  • Did the meaning survive onward? Per-neighbor Adj-RIB-Out and downstream evidence.

A public collector can support the final question at one vantage point. It cannot reconstruct every prior transformation, authenticate the first writer or reveal an action applied only inside another AS. Absence of a value at the collector may mean stripping, policy, path selection, aggregation or a different export view.

Sources