The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
obsoleted by
- rfc-9012 — The BGP Tunnel Encapsulation Attribute
Extracted elements (23)
A separate Encapsulation SAFI is used (rather than attaching the tunnel encapsulation attribute directly to each prefix) so that a change in encapsulation information requires only a single BGP update, avoiding a large number of updates that would result if every prefix carried encapsulation information directly.
A single Encapsulation SAFI is used for all tunnel types (rather than one SAFI per tunnel type) so that encapsulation information can pass transparently through intermediate BGP speakers (e.g., route reflectors) that do not understand the encapsulation attribute, since the Tunnel Encapsulation Attribute is defined as optional transitive. This allows new encapsulations to be added without reconfiguring intermediate BGP systems.
For encapsulation protocols requiring no explicit parameter signaling (e.g., GRE without key), the BGP Encapsulation Extended Community can be attached to payload-prefix UPDATE messages to indicate the encapsulation protocol type, serving as a lightweight alternative to the full Encapsulation SAFI mechanism.
A BGP speaker wishing to exchange tunnel endpoint information must use the Multiprotocol Extensions Capability (RFC 4760) to advertise the corresponding (AFI, SAFI) pair.
An UPDATE message carrying MP_REACH_NLRI or MP_UNREACH_NLRI with the Encapsulation SAFI MUST also carry the BGP mandatory attributes: ORIGIN, AS_PATH, and LOCAL_PREF (for IBGP neighbors).
For interoperability, a BGP speaker supporting Encapsulation SAFI MUST implement the Encapsulation Extended Community.
If a BGP speaker originates an update for prefix P with color C and with itself as next hop, it MUST also originate an Encapsulation SAFI update containing color C.
If a BGP speaker receives an update for prefix P with color C whose best-route next hop is N, but no Encapsulation SAFI update from N containing color C has been received, no route to P will be installed until the corresponding Encapsulation SAFI update is received or the decision process selects a different route.
The GRE encapsulation sub-TLV MUST NOT be present unless a key value is being advertised. The Protocol Type sub-TLV MUST be encoded for L2TPv3 tunnel type.
When a BGP speaker encounters an error parsing the tunnel encapsulation attribute, it MUST treat the UPDATE as a withdrawal of existing routes to the included Encapsulation SAFI NLRIs, or discard the UPDATE if no such routes exist. A log entry should be raised for local analysis.
When a BGP speaker processing a TLV for encapsulation encounters unknown sub-TLVs, it MUST ignore and skip them. However, if the TLV itself is understood, the entire TLV MUST NOT be ignored just because it contains an unknown sub-TLV.
The Encapsulation SAFI (value 7) is used with AFI 1 (IPv4) or AFI 2 (IPv6) to carry tunnel encapsulation information. The NLRI consists solely of the endpoint address (4 octets for IPv4, 16 octets for IPv6) identifying the BGP speaker originating the update.
The Protocol Type sub-TLV (type 2) contains a 2-octet payload protocol type using IANA Ethertype values (e.g., IPv4=0x0800, IPv6=0x86dd, MPLS=0x8847). It MUST be encoded for L2TPv3 and is not required for IP-in-IP or GRE tunnels.
The Tunnel Encapsulation Attribute is an optional transitive BGP path attribute (type code 23) composed of TLVs. Each TLV has a 2-octet Tunnel Type, 2-octet Length, and variable Value containing sub-TLVs. Defined tunnel types are: L2TPv3 over IP (1), GRE (2), and IP in IP (7).
IANA assigned value 7 to 'Encapsulation SAFI' in the Subsequent Address Family Registry (Standards Action range) and value 23 to 'Tunnel Encapsulation Attribute' in the BGP Path Attributes Registry.
IANA created the 'BGP Tunnel Encapsulation Attribute Sub-TLVs' registry (1-octet values, standards action/early allocation) with initial assignments: Encapsulation=1, Protocol Type=2, Color=4. IANA also assigned two BGP Opaque Extended Community values: Color Extended Community (0x030b) and Encapsulation Extended Community (0x030c).
IANA created the 'BGP Tunnel Encapsulation Attribute Tunnel Types' registry (2-octet values, first-come first-served) with initial assignments: L2TPv3 over IP=1, GRE=2, IP in IP=7.
Security issues of the tunnel protocols signaled through Encapsulation SAFI are inherited from those protocols. If a third party can modify encapsulation headers, tunnel type selection, or tunnel-to-payload-type mappings, user data packets may be misrouted, misdelivered, or dropped.
The BGP Encapsulation Extended Community is a transitive opaque extended community with high-order type octet 0x03 and low-order type octet 0x0c. The last 2 octets of the value field encode the tunnel type as defined in this document.
The Color Extended Community is an opaque transitive extended community with high-order type octet 0x03 and low-order type octet 0x0b, followed by 2 reserved octets and a 4-octet user-defined Color Value.
The GRE Encapsulation sub-TLV value field contains a GRE Key (4 octets) per RFC 2890, generated by the advertising router and inserted into the GRE encapsulation header by ingress routers. The GRE encapsulation sub-TLV MUST NOT be present unless a key value is being advertised.
The L2TPv3 Encapsulation sub-TLV value field contains: Session ID (4 octets, non-zero, locally assigned) and an optional Cookie (0–8 octets, variable). Cookie length is derived as sub-TLV length minus 4.
The Tunnel Encapsulation Attribute TLV encodes: Tunnel Type (2 octets), Length (2 octets), and Value (variable). Sub-TLVs within Value each have Sub-TLV Type (1 octet), Sub-TLV Length (1 octet), and Sub-TLV Value (variable).