BGP Prefix Origin Validation State Extended Community
Extracted elements (16)
The extended community is marked non-transitive (high-order octet 0x43) so that it is not propagated across AS boundaries by default, preventing external ASes from receiving or injecting validation state that could affect routing decisions inside another AS.
When multiple instances of the community are received, the one with the numerically greatest validation state value takes precedence. This prioritizes 'invalid' (2) over 'not found' (1) over 'valid' (0), implementing a conservative preference for the most alarming state.
In deployments where not all speakers in an AS are upgraded to support this extension, operators must define policies that match on the origin validation extended community and set another BGP attribute (per RFC 6811) to influence best-path selection equivalently.
A receiving BGP speaker, in the absence of validation state set based on local data, SHOULD derive a validation state from the last octet of the extended community, if present.
An implementation SHOULD NOT send more than one instance of the origin validation state extended community in a single UPDATE message.
By default, an implementation SHOULD NOT send the origin validation state extended community to EBGP peers, though it SHOULD be possible to configure an implementation to send or accept the community when warranted (e.g., when adjacent ASes are under the same administration).
By default, implementations MUST drop the origin validation state extended community if received from an EBGP peer, without processing it further.
If more than one instance of the community is received, an implementation MUST disregard all instances other than the one with the numerically greatest validation state value.
If the received validation state value is greater than 2 (the largest specified value), the implementation MUST apply a strategy similar to attribute discard (RFC 7606) by discarding the erroneous community and logging the error.
If the router is configured to support this extension, it SHOULD attach the origin validation state extended community to BGP UPDATE messages sent to IBGP peers by mapping the computed validation state into the last octet of the extended community.
The Reserved field in the extended community encoding MUST be set to 0 on transmission and ignored upon receipt.
The validation state field in the last octet of the extended community encodes three possible values: 0 (valid), 1 (not found), and 2 (invalid), corresponding to the BGP prefix origin validation lookup result defined in RFC 6811.
IANA registered the value 0x00 with the name 'BGP Origin Validation State Extended Community' in the 'Non-Transitive Opaque Extended Community Sub-Types' registry.
This document introduces an extended community used to affect route selection; the falsification analysis of RFC 4593 Section 4.5 is relevant, as a compromised router could inject fraudulent validation states to influence path selection across the AS.
This scheme allows router A to outsource validation to router B; participating routers must have an appropriate trust relationship (same administrative control or equivalent), and the TCP session between them should be secured per RFC 7454 Section 5.1.
The origin validation state extended community is an 8-octet opaque extended community. The first octet is 0x43 (non-transitive type), the second is 0x00 (sub-type assigned by IANA), octets 3-7 are Reserved (MUST be zero), and the last octet is an unsigned integer encoding the validation state (0=valid, 1=not found, 2=invalid).