The BGP Tunnel Encapsulation Attribute
obsoletes
- rfc-5512 — The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
- rfc-5566 — BGP IPsec Tunnel Encapsulation Attribute
updated by
- rfc-9830 — Advertising Segment Routing Policies in BGP
updates
- rfc-5640 — Load-Balancing for Mesh Softwires
Extracted elements (29)
RFC 5512 defined all sub-TLVs with a 1-octet Length field (max 255 bytes). RFC 9012 introduces a dual-width scheme where sub-TLV types 0–127 use 1-octet Length and types 128–255 use 2-octet Length, enabling sub-TLVs that need more than 255 octets without breaking existing parsers.
RFC 5512 required the Encapsulation SAFI (value 7) for carrying tunnel information, but this SAFI was never deployed in production because it required reconfiguration of every BGP session. RFC 9012 deprecates the Encapsulation SAFI and allows the Tunnel Encapsulation attribute on existing AFI/SAFIs.
The MPLS-in-GRE tunnel type (11) is functionally equivalent to a GRE tunnel type (2) with a Protocol Type sub-TLV specifying MPLS. It is retained solely for backwards compatibility with implementations of RFC 8365 and similar deployed code.
The Encapsulation Extended Community defined in RFC 5512 provides a backwards-compatible subset of the Tunnel Encapsulation attribute's functionality. RFC 9012 mandates that both encodings (barebones TLV and Extended Community) must be understood by compliant implementations, and they may coexist in the same BGP UPDATE.
A TLV containing a malformed Tunnel Egress Endpoint sub-TLV MUST be ignored entirely and MUST be removed from the Tunnel Encapsulation attribute before the route is distributed. This is stricter than the general rule for malformed sub-TLVs (which are treated as unrecognized).
Any BGP speaker that understands the Tunnel Encapsulation attribute MUST be able to filter it from both incoming and outgoing BGP UPDATE messages. For each EBGP session, filtering of the attribute on both incoming and outgoing UPDATEs MUST be enabled by default.
Each TLV in a Tunnel Encapsulation attribute carried in an UPDATE of an AFI/SAFI listed in Section 6 MUST contain exactly one Tunnel Egress Endpoint sub-TLV. A TLV lacking one is treated as containing a malformed Tunnel Egress Endpoint sub-TLV.
If a route includes a Tunnel Encapsulation attribute with no feasible tunnel, that route MUST NOT be considered resolvable for the purposes of the route resolvability condition (RFC 4271, Section 9.1.2.1), affecting the BGP best-route selection.
If a Tunnel Encapsulation attribute has no valid TLVs or lacks the transitive bit, the 'Treat-as-withdraw' procedure of RFC 7606 is applied. If a TLV's final octet is not the final octet of its final sub-TLV, the TLV MUST be considered malformed and Treat-as-withdraw applied.
In a situation where a tunnel could be encoded as a 'barebones' TLV (no sub-TLVs other than Tunnel Egress Endpoint), it MUST instead be encoded using the corresponding Encapsulation Extended Community for backwards compatibility. Implementations MUST also be prepared to process barebones TLVs.
The Tunnel Encapsulation attribute MAY be carried in BGP UPDATEs of AFI/SAFI: 1/1, 2/1, 1/4, 2/4, 1/128, 2/128, and 25/70. Use with other AFI/SAFIs is outside the scope of this document.
When a BGP UPDATE has a Tunnel Encapsulation attribute containing at least one feasible tunnel for packet P, router R MUST send packet P through one of those feasible tunnels. A tunnel is feasible only if its type is supported, it can carry the payload, its egress endpoint is reachable, and no local policy prohibits it.
When UPDATE U1 has no Tunnel Encapsulation attribute but resolves its next hop via UPDATE U2 that does have such an attribute, packet P MUST be sent through one of U2's tunnels. However, if a TLV in U2 has a Color sub-TLV, it MUST NOT be used unless U1 carries a matching Color Extended Community.
IANA deprecated Encapsulation SAFI (value 7) in the 'SAFI Values' registry and marked tunnel types 3–6 (Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP with IPsec Transport Mode, MPLS-in-IP with IPsec Transport Mode) as deprecated in the 'BGP Tunnel Encapsulation Attribute Tunnel Types' registry, following obsolescence of RFCs 5512 and 5566.
IANA maintains the 'BGP Tunnel Encapsulation Attribute Sub-TLVs' registry under the 'Border Gateway Protocol (BGP) Tunnel Encapsulation' grouping. Types 1–63 use Standards Action; 64–125 First Come First Served; 126–127 Experimental; 128–191 Standards Action; 192–252 First Come First Served; 253–254 Experimental. New entries added: 6 (Tunnel Egress Endpoint), 7 (DS Field), 8 (UDP Destination Port), 9 (Embedded Label Handling), 10 (MPLS Label Stack), 11 (Prefix-SID).
An optional procedure (Section 3.1.1) allows validation that the Tunnel Egress Endpoint address belongs to the same AS that originated the route, using RFC 6811 Route Origin ASN comparison. If Route_AS ≠ Egress_AS, the sub-TLV is considered invalid. This procedure MUST be reapplied if the forwarding route changes.
Misconfiguration or malicious alteration of the Tunnel Encapsulation attribute can create mutually recursive tunnel dependencies (X's egress is Y, Y's egress is X), rendering BGP routes unresolvable, or can cause long-lasting forwarding loops. TTL fields in payload packets bound loop duration but the control plane cannot detect the condition.
The Tunnel Encapsulation attribute is transitive and MUST be scoped to a well-defined administrative domain. Distribution beyond that scope can cause packets to traverse unintended tunnels. EBGP filtering of the attribute MUST be enabled by default to prevent leakage.
Each sub-TLV has a 1-octet Type, a 1-octet or 2-octet Length, and a variable Value. Sub-TLV types 0–127 use a 1-octet Length field; types 128–255 use a 2-octet Length field, allowing sub-TLVs larger than 255 octets.
The Color Extended Community is a Transitive Opaque Extended Community (type 0x03, sub-type 0x0b) with a 2-octet Flags field (MUST be zero, MUST NOT be changed in transit) and a 4-octet administrator-defined Color Value.
The Embedded Label Handling sub-TLV (type 9) has a 1-octet Value: value 1 means the embedded NLRI label appears at the top of the payload MPLS stack; value 2 means the label is placed in the Virtual Network Identifier field or ignored. Any other value is malformed.
The Encapsulation Extended Community is a Transitive Opaque Extended Community (type 0x03, sub-type 0x0c) with 4 reserved octets followed by a 2-octet Tunnel Type. It serves as a backwards-compatible minimal encoding equivalent to a 'barebones' Tunnel TLV with no sub-TLVs other than the Tunnel Egress Endpoint.
The GRE Encapsulation sub-TLV (tunnel type 2) is exactly 4 octets containing an optional GRE Key. The sub-TLV MUST NOT be present unless a key value is being advertised.
The L2TPv3 Encapsulation sub-TLV (tunnel type 1) contains a 4-octet non-zero Session ID followed by a 0–8 octet optional Cookie. Total length is 4–12 octets; cookie length is derived as (sub-TLV length − 4).
The MPLS Label Stack sub-TLV (type 10) carries a sequence of 4-octet MPLS label stack entries (Label 20 bits, TC 3 bits, S bit, TTL 8 bits) as defined in RFC 3032. The first entry is topmost; ordering MUST be preserved when pushing. TTL SHOULD be 255; a TTL of zero MUST be changed to non-zero.
The NVGRE Encapsulation sub-TLV (tunnel type 9) has the identical 12-octet structure as the VXLAN sub-TLV: Flags (V, M, R bits), 3-octet VN-ID (used as the VSID), 6-octet MAC Address, and 2 reserved octets.
The Tunnel Egress Endpoint sub-TLV (type 6) encodes a 4-octet Reserved field, a 2-octet Address Family, and a variable-length Address. For IPv4 the address is 4 octets (/32); for IPv6 it is 16 octets (/128). Address Family 0 indicates the next-hop address, with no Address subfield; in that case the Length MUST be 6.
The Tunnel Encapsulation TLV consists of a 2-octet Tunnel Type, a 2-octet Length (total octets of Value), and a variable-length Value field comprising sub-TLVs. Tunnel Type values are from the IANA 'BGP Tunnel Encapsulation Attribute Tunnel Types' registry.
The VXLAN Encapsulation sub-TLV (tunnel type 8) is 12 octets: a 1-octet Flags field with V (VN-ID present) and M (MAC Address present) bits, a 3-octet VN-ID, a 6-octet MAC Address, and 2 reserved octets. Reserved bits MUST be set to 0 by the originator, propagated unchanged, and ignored on receipt.