BGP ACCEPT_OWN Community Attribute
Extracted elements (18)
ACCEPT_OWN is defined as a BGP community rather than a new attribute because a community is the minimal, backward-compatible signal needed. A PE that does not support ACCEPT_OWN will simply ignore the community and continue to reject its own routes, preserving existing behavior.
The core problem is that per RFC 4271, a BGP speaker rejects received prefix advertisements it originated itself — route reflectors attach ORIGINATOR_ID so originators can detect and reject their own routes, and NEXT_HOP matching the receiver's own IP is also grounds for rejection. This prevents the RT-modification technique from working when source and destination VRFs are on the same PE.
The extra ACCEPT_OWN preference step in the decision process is placed after LOCAL_PREF comparison to ensure that routes re-advertised by the route reflector with ACCEPT_OWN are selected as best over other paths the BGP speaker may have received, enabling the intended extranet VPN use case.
ACCEPT_OWN applies to VPN routes with a SAFI of 128 (and analogous constructs). In address families where the source VRF cannot be identified by Route Distinguisher inspection, the community must be discarded rather than acted upon.
The ACCEPT_OWN approach generalizes beyond RFC 4364 VPNs to any BGP speaker maintaining multiple routing contexts, provided the technology uses a Route-Distinguisher-like construct for source context and a Route-Target-like construct for import targeting.
The ACCEPT_OWN community is designed for use within a single autonomous system with a single layer of route reflectors. Its use with hierarchical route reflectors or across multiple autonomous systems is out of scope and requires further specification.
A route MUST NOT ever be accepted back into its source VRF, even if it carries one or more Route Targets that match that VRF.
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP matches its own address if: (1) ACCEPT_OWN processing is enabled by configuration, (2) the route carries the ACCEPT_OWN community, (3) the route originated from a source VRF on the router (matching Route Distinguisher), (4) the route is targeted to one or more destination VRFs on the router, and (5) at least one destination VRF differs from the source VRF.
If a route carrying the ACCEPT_OWN community is received in an address family that does not allow the source VRF to be looked up, the ACCEPT_OWN community MUST be discarded. An OPTIONAL log message may be emitted in this case.
If ACCEPT_OWN handling is controlled by configuration, it MUST default to being disabled. When disabled (explicitly or by default), the router MUST NOT apply the special route acceptance rules of Section 2.1.
Processing of the ACCEPT_OWN community SHOULD be controlled by configuration and SHOULD default to being disabled.
The ACCEPT_OWN community SHOULD NOT be attached to routes that cannot be associated with a source VRF. When propagating routes into a VRF, the ACCEPT_OWN community SHOULD NOT be propagated.
The ACCEPT_OWN decision process extra step MUST only be invoked during best path selection of VPN-IP routes (RFC 4364). It MUST NOT be invoked for best path selection of imported IP routes in a VRF.
When ACCEPT_OWN is disabled by configuration, the router SHOULD still apply the propagation rules of Section 2.2 (i.e., stripping the community when propagating into a VRF).
ACCEPT_OWN is a new well-known BGP community with IANA-assigned value 0xFFFF0001, defined in the First Come First Served range. It enables a route reflector to re-advertise a VPN route back to its originating PE with a modified Route Target list, allowing intra-PE VRF-to-VRF route import.
IANA assigned the value 0xFFFF0001 in the 'BGP Well-known Communities' registry for the ACCEPT_OWN community under the First Come First Served allocation policy.
ACCEPT_OWN permits a router's own route prefix to be advertised to a different VRF on the same router. Such a route shares the same security vulnerabilities as any other BGP route and does not introduce new vulnerabilities beyond those inherent in BGP VPN (RFC 4364).
If a BGP speaker supports and is configured for ACCEPT_OWN, an additional step is inserted after the LOCAL_PREF comparison in the BGP decision process: when comparing routes for a BGP destination, the route carrying ACCEPT_OWN is preferred over the route without it. All other decision process steps remain unchanged.