Carrying Label Information in BGP-4
obsoleted by
- rfc-8277 — Using BGP to Bind MPLS Labels to Address Prefixes
updated by
- rfc-6790 — The Use of Entropy Labels in MPLS Forwarding
Extracted elements (20)
Label mapping information is piggybacked in the same BGP Update message used to distribute the route itself, eliminating the need for a separate label distribution protocol between adjacent BGP/LSR peers and allowing Route Reflectors to distribute labels alongside routes, significantly improving scalability.
The label value is placed in the NLRI rather than a BGP path attribute so that different routes to the same destination can carry distinct labels within a single Update message, enabling per-route label granularity without requiring separate messages.
When BGP label distribution peers are not directly adjacent (e.g., A--B--C--D topology), an LSP must exist between them before labels can be used. RFC 3107 does not specify any real-time mechanism to ensure this; ensuring proper infrastructure is left to network management and operations.
When Route Reflectors are used, the advertising LSR (A) may not know the full set of LSRs that receive its label mappings, since the Route Reflector need not be in the forwarding path and need not be capable of forwarding MPLS packets itself.
A BGP speaker may not use BGP to send labels to a particular BGP peer unless that peer indicates, through BGP Capability Advertisement, that it can process Update messages with SAFI value 4.
A BGP speaker may withdraw a previously advertised labeled route by (a) advertising a new route with the same NLRI, or (b) listing the NLRI in the Withdrawn Routes field. The label information in the Withdrawn Routes field should be set to 0x800000.
A BGP speaker should not advertise the label-carrying capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers.
A BGP speaker that uses Multiprotocol Extensions to carry label mapping information should use the Capabilities Optional Parameter (RFC 2842) to advertise the (AFI, SAFI) pairs available; the MP_EXT Capability Code (RFC 2858) is used for this purpose.
The label(s) specified for a particular route must be assigned by the LSR identified by the value of the Next Hop attribute of that route.
When a BGP speaker redistributes a route, the label(s) assigned to that route must not be changed (except by omission) unless the speaker changes the value of the Next Hop attribute of the route.
When multiple routes to a destination exist and a labeled route is withdrawn with a label specified, only the route matching that specific label is withdrawn. If no label is specified at withdrawal, only the unlabeled route is withdrawn; labeled routes remain.
A BGP speaker capable of handling multiple routes to a destination should advertise this capability using the Capabilities Optional Parameter (RFC 2842); the capability value for this feature is 4.
A BGP speaker may maintain and advertise more than one route to a given destination, provided each such route has its own distinct label(s). A single BGP Update message may carry multiple such labeled routes.
Label mapping information is carried in the NLRI field of the BGP-4 Multiprotocol Extensions attribute (RFC 2858). SAFI value 4 indicates that the NLRI contains label information, and the AFI indicates the address family of the associated route.
The Label field carries one or more labels corresponding to a label stack. Each label is 3 octets: the high-order 20 bits contain the label value, and the low-order bit is the Bottom of Stack indicator as defined in RFC 3032 (MPLS Label Stack Encoding).
When withdrawing a labeled route via the Withdrawn Routes field, the label value must be set to the reserved value 0x800000.
A weaker but sufficient mitigation is to accept labeled packets from external interfaces only if the top label was actually distributed out that interface, ensuring that untrusted external parties cannot inject packets with arbitrary internal labels.
Label spoofing can be mitigated by rejecting labeled packets from external interfaces when all BGP-distributed labels are advertised via IBGP, since IBGP peers are under a single administrative domain and can generally be trusted not to spoof labels.
When BGP label peers are separated by an MPLS network rather than a direct point-to-point link, an LSR processing a labeled packet cannot determine which LSR imposed the top label and thus cannot verify whether that LSR is entitled to use it, making direct label-spoofing prevention infeasible.
The labeled NLRI is encoded as one or more triples of the form <length, label, prefix>: Length (1 octet) gives the bit length of the prefix plus label(s); Label (3 octets per label, high-order 20 bits = label value, low-order bit = Bottom of Stack); Prefix (variable, padded to octet boundary).