Using BGP to Bind MPLS Labels to Address Prefixes
obsoletes
- rfc-3107 — Carrying Label Information in BGP-4
Extracted elements (27)
RFC 3107 is obsoleted because it had multiple interoperability problems: undefined semantics for binding a sequence of labels to a prefix, unclear withdrawal procedures, an unimplemented 'Advertising Multiple Routes to a Destination' feature, silent treatment of concurrent SAFI-1 and SAFI-4 UPDATEs, and no mention of VPN-IPv4/VPN-IPv6 address families.
The 'Advertising Multiple Routes to a Destination' feature from RFC 3107 (Capability Code 4) is removed because it was never implemented as specified. RFC 7911 (ADD-PATH) provides the same functionality and is the preferred mechanism; Capability Code 4 is now deprecated.
The Compatibility field in the withdrawal NLRI is recommended to be 0x800000 (not 0x000000) for backwards compatibility with RFC 3107 implementations, even though its value is never significant. RFC 3107 allowed specifying a label value here, but that functionality was never implemented and is dropped.
A BGP speaker MAY convert a received SAFI-4 route to a SAFI-1 route for propagation to peers where SAFI-4 is not enabled, but whether this is done is a matter of local policy. These differences in behavior between implementations may result in unexpected behavior or lack of interoperability.
Implementations conforming to this document are believed to interoperate correctly with existing deployed implementations of RFC 3107, because backwards compatibility is preserved: Section 2.2 encoding is required when the Multiple Labels Capability has not been negotiated, matching legacy behavior.
The relationship between SAFI-1 (unlabeled unicast) and SAFI-4 routes for the same prefix is implementation-defined. Some implementations treat them independently ('ships in the night'), others treat them as comparable for best-path selection, and some treat SAFI-1 receipt as an implicit withdrawal of SAFI-4 and vice versa.
A BGP speaker SHOULD NOT send an UPDATE binding more labels than its peer's announced Count. If a speaker receives an UPDATE with more labels than it announced it can receive, it MUST apply the 'treat-as-withdraw' strategy of RFC 7606 to that UPDATE.
A Multiple Labels Capability triple with Count=0 or Count=1 MUST NOT be sent; if received it MUST be ignored. A Capability whose length is not a multiple of four MUST be considered malformed.
After BGP Graceful Restart, if the Multiple Labels Capability for a given AFI/SAFI was exchanged on the failed session but not on the restarted session (or if Count decreased), any prefixes advertised with more labels than now valid MUST be explicitly withdrawn, and Accelerated Routing Convergence procedures MUST NOT be applied.
If the Multiple Labels Capability has been both sent and received on a given BGP session and both specify AFI/SAFI x/y, then UPDATEs of that AFI/SAFI MUST use the Section 2.3 encoding—even if only one label is being bound.
In the multi-label NLRI encoding, the S bit MUST be 0 in all labels except the last (the one immediately preceding the prefix), and MUST be 1 in the last label. Failure to set the S bit in the last label makes correct NLRI parsing impossible.
Per RFC 4760, the NLRI field is limited to 255 bits total (not octets), including prefix bits. In a SAFI-128 UPDATE, a VPN-IPv6 host route prefix can be up to 192 bits, severely limiting the number of labels that can be encoded.
Two SAFI-4 or SAFI-128 UPDATEs for the same prefix received on different BGP sessions (or on the same session with different RFC 7911 path identifiers) MUST be considered comparable by the BGP best-path selection procedure, even if they carry different labels.
Unless the Multiple Labels Capability has been both sent and received on a given BGP session, a SAFI-4 or SAFI-128 UPDATE MUST bind a prefix to only a single MPLS label and MUST use the Section 2.2 encoding.
When a new SAFI-4/128 UPDATE U2 specifying label L2 and prefix P arrives on the same session as a prior UPDATE U1 specifying label L1 and the same prefix and next hop (without RFC 7911 add-paths), U2 MUST be interpreted as replacing U1, i.e., L1 is implicitly withdrawn.
When propagating a SAFI-4 or SAFI-128 route with a changed Next Hop field, the Label field(s) MUST contain the label(s) bound to the prefix at the new next hop. The number and values of labels may change in any combination allowed by local policy.
SAFI 4 (Labeled Unicast) is used with AFI 1 (IPv4) or AFI 2 (IPv6) to carry label bindings for IP address prefixes. SAFI 128 (Labeled VPN) is used with AFI 1 or 2 for VPN-IPv4 and VPN-IPv6 prefixes (RFC 4364, RFC 4659). Use of SAFI 4 or 128 with other AFIs is outside the scope of this document.
The Multiple Labels Capability (BGP Capability Code 8, assigned by IANA) is a new BGP Optional Capabilities parameter that allows two BGP speakers to negotiate per-AFI/SAFI support for binding a sequence of more than one MPLS label to an address prefix. It is new to this document and does not appear in RFC 3107.
IANA assigned value 8 to the Multiple Labels Capability in the BGP 'Capability Codes' registry. Value 4 ('Multiple routes to a destination capability') is marked deprecated. SAFI 4 reference is updated to this document, and this document is added as a reference for SAFI 128.
BGP UPDATE distribution techniques can control which BGP speakers learn a given label binding, but if BGP sessions do not provide privacy, other routers may learn of the binding. There is no guarantee that a received MPLS packet's label was applied by an authorized router.
If a BGP implementation non-conformant with this document encodes multiple labels in the NLRI without having negotiated the Multiple Labels Capability, a conformant implementation will likely reset the BGP session upon receiving such an UPDATE.
This document requires tunneling data packets between BGP speakers but does not mandate a specific encapsulation. The most commonly used tunnel encapsulation (MPLS) does not provide integrity or authentication, making it possible for a packet's label stack to be modified in transit, resulting in misdelivery.
To mitigate label spoofing, a BGP speaker SHOULD distinguish internal from external interfaces and avoid advertising the same labels to both. An incoming data packet whose top label was not advertised over the interface type from which the packet was received can then be discarded.
NLRI encoding with Multiple Labels Capability (Figure 3): Length (8 bits), then one or more 24-bit label entries each consisting of Label (20 bits) + Rsrv (3 bits) + S (1 bit), followed by the address prefix. The S bit MUST be 0 in all labels except the last, and MUST be 1 in the last label.
NLRI encoding without Multiple Labels Capability (Figure 2): Length (8 bits), Label (20-bit MPLS label value), Rsrv (3 bits, SHOULD be zero on TX, MUST be ignored on RX), S (1 bit, MUST be set to 1 on TX, MUST be ignored on RX), followed by the address prefix.
NLRI for explicit label-binding withdrawal (Figure 4): Length (8 bits), Compatibility field (24 bits, SHOULD be set to 0x800000 on TX and MUST be ignored on RX), followed by the address prefix. This encoding is used regardless of whether Multiple Labels Capability was negotiated.
The Multiple Labels Capability value field consists of one or more 4-octet triples: AFI (2 octets), SAFI (1 octet), Count (1 octet). Count specifies the maximum number of labels the sender can process in a received UPDATE of that AFI/SAFI; Count=255 means no limit.