Summary

  • RFC 8097 defines a non-transitive extended community that carries a route’s Valid, NotFound or Invalid origin-validation state inside an autonomous system.
  • The state can inform policy, but it does not execute policy: EBGP carriage is disabled by default, delegated validation requires trust, and route rejection or preference remains an explicitly configured local decision.

Three values carry a result, not a command

RFC 6811 defines the underlying lookup. A route is Valid when at least one validated ROA payload covers its prefix, permits its length and matches its origin AS; NotFound when no payload covers it; and Invalid when at least one payload covers it but none matches. RFC 8097 encodes those states as 0, 1 and 2 in a non-transitive opaque extended community. IANA assigns subtype 0x00 under type 0x43. Reserved bits MUST be sent as zero and ignored on receipt.

A configured router SHOULD attach the community to UPDATEs sent to IBGP peers. A receiver without a validation state calculated from local data SHOULD derive one from the community when it is present. That is a transfer of a result. It is not proof that the sender’s cache is current, that the path is valid, or that the receiver should accept or reject the route.

RFC 6811 makes the authority boundary explicit. Validation state is a local property. An implementation MUST NOT exclude a route from Adj-RIB-In or from the decision process merely because of the state unless policy explicitly says so. The label supplies evidence to policy; it does not replace policy.

The trust boundary stops at EBGP by default

RFC 8097 requires implementations to drop this community when it arrives from an EBGP peer by default, without processing it further. By default they also SHOULD NOT send it to EBGP peers. Configuration may permit external exchange when warranted, such as between adjacent autonomous systems under one administration, but that is an affirmative trust decision rather than the protocol baseline.

The security section describes the arrangement plainly: one router may outsource validation to another. The participants therefore need an appropriate trust relationship and must consider protection of the transport between them. The community carries a validation result but is not itself cryptographically authenticated; it can be falsified, stale or attached by the wrong speaker. Origin validation itself does not validate the full AS path.

Mixed support creates a policy translation obligation

Not every router has to implement RFC 8097 at once. If some internal speakers do not, RFC 8097 recommends that the operator define policies that match the community and set another BGP attribute influencing best-path selection in the same way. Otherwise the same route can carry different practical meaning across the internal topology.

The format has its own defensive rules. An implementation SHOULD NOT send more than one instance. If several arrive, it MUST disregard all but the numerically greatest value. For a value above 2, the erroneous community MUST be discarded using an RFC 7606-like approach, while the implementation SHOULD log the error. Those rules contain malformed state; they do not certify the remaining route.

Evidence and limits

RFC 8097 defines encoding, state carriage, EBGP defaults, mixed-deployment handling and the delegated-trust warning. RFC 6811 defines the state calculation and keeps route action under local policy. RFC 7606 supplies the constrained error-handling analogy. RFC 7454 supplies transport-protection guidance, and IANA records the assigned subtype.

The sources do not identify which networks use the community today, quantify a universal operational saving, or guarantee that two validators have identical data. Statements about ownership, beneficiaries, cost and counterfactual are analysis derived from the standards.

Sources