RFC 3107

Carrying Label Information in BGP-4

📅 published May 2001, from ietf

RFC 3107: Carrying Label Information in BGP-4 ✨

Okay bestie, this one's by Y. Rekhter (Juniper Networks) and E. Rosen (Cisco Systems, Inc.), published May 2001 as a Standards Track doc 🎀 It's giving official Internet protocol energy. The title block doesn't mention anything it obsoletes or updates, so that's a no for both 💅

Status of this Memo

This is an Internet standards track protocol for the Internet community, and the authors want discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract

This doc explains how the label mapping info for a route gets piggybacked onto the same BGP Update message that carries the route itself 🦋 So when BGP is already sending a route, it can also send a Multiprotocol Label Switching (MPLS) label that's mapped to that route. Main character energy ✨

Table of Contents

1      Specification of Requirements  ..........................   2
2      Overview  ...............................................   2
3      Carrying Label Mapping Information  .....................   3
4      Advertising Multiple Routes to a Destination  ...........   4
5      Capability Advertisement  ...............................   4
6      When the BGP Peers are not Directly Adjacent  ...........   5
7      Security Considerations  ................................   5
8      Acknowledgments  ........................................   6
9      References  .............................................   6
10     Authors' Addresses  .....................................   7
11     Full Copyright Statement  ...............................   8

1. Specification of Requirements 📝

Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way RFC 2119 describes 🔥 Those are the rules of the game, so pay attention to them 👑

2. Overview 🌸

When BGP is distributing a route, it can also distribute an MPLS label that's mapped to that route [MPLS-ARCH]. This doc says how to do that. The label mapping for a route gets piggybacked in the same BGP Update message that carries the route, so it's all in one go 🚀

Here's when this is useful, iykyk 🙈

  • If two immediately adjacent Label Switched Routers (LSRs) are also BGP peers, then label distribution can happen without any other label distribution protocol. No extra drama 💅
  • Picture a network with two "classes" of LSR: exterior LSRs, which connect to other networks, and interior LSRs, which only carry traffic between exterior LSRs. Say the exterior LSRs are BGP speakers. If they send MPLS labels to each other along with every route they send, then as long as the interior routers support MPLS, they don't need to receive any of the BGP routes from the BGP speakers. Lowkey genius 🧚

Here's the flow. If exterior router A needs to send a packet to destination D, and A's BGP next hop for D is exterior router B, and B has mapped label L to D, then A first pushes L onto the packet's label stack. Then A checks its IGP to find the next hop to B, which we'll call C. If C has sent A an MPLS label for the route to B, A can push that label onto the stack too, and then send the packet to C 💖

If a group of BGP speakers are swapping routes through a Route Reflector [BGP-RR], then piggybacking the label distribution on the route distribution means the Route Reflector can distribute the labels too ✨ This scales way better, like, significantly 😭 Also, if the Route Reflector isn't in the forwarding path, it doesn't even need to be able to forward MPLS packets 🫧

Label distribution gets piggybacked in the BGP Update message using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The label is encoded into the NLRI field of that attribute, and the SAFI ("Subsequent Address Family Identifier") field is used to signal that the NLRI has a label in it 🎀 A BGP speaker may not use BGP to send labels to a particular BGP peer unless that peer says, through BGP Capability Advertisement, that it can process Update messages with the specified SAFI field. No skipping that step, bestie 🙅‍♀️

3. Carrying Label Mapping Information 🦋

Label mapping info is carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes. The AFI tells you, as usual, the address family of the associated route. The NLRI contains a label when SAFI value 4 is used 💜

The NLRI is encoded as one or more triples of the form <length, label, prefix>. Here's the layout 🍓

+---------------------------+
|   Length (1 octet)        |
+---------------------------+
|   Label (3 octets)        |
+---------------------------+
.............................
+---------------------------+
|   Prefix (variable)       |
+---------------------------+

Here's what each field does 👀

  • a) Length: The Length field gives the length in bits of the address prefix plus the label(s).
  • b) Label: The Label field carries one or more labels, which match the stack of labels [MPLS-ENCAPS]. Each label is 3 octets. The high-order 20 bits hold the label value, and the low order bit holds "Bottom of Stack" (as defined in [MPLS-ENCAPS]) ⭐
  • c) Prefix: The Prefix field has address prefixes followed by enough trailing bits to make the end of the field land on an octet boundary. The value of those trailing bits is irrelevant, so don't stress about them 🫶

The label(s) for a particular route (and tied to its address prefix) must be assigned by the LSR that's identified by the value of the route's Next Hop attribute 🔥

When a BGP speaker redistributes a route, the label(s) assigned to that route must not change (except by omission), unless the speaker changes the value of the route's Next Hop attribute. Don't mess with the labels, periodt 💅

A BGP speaker can withdraw a route it previously advertised, along with the binding between that route and its label, in one of two ways. It can (a) advertise a new route (and a label) with the same NLRI as the previous one, or (b) list the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. When the label info (carried as part of the NLRI) is in the Withdrawn Routes field, it should be set to 0x800000. (Of course, ending the BGP session also withdraws all the previously advertised routes, obviously 🙈)

4. Advertising Multiple Routes to a Destination 💖

A BGP speaker may keep (and advertise to its peers) more than one route to a given destination, as long as each of those routes has its own label(s) ✨

The encoding above lets one BGP Update message carry multiple routes, each with its own label(s) 🧚

When a BGP speaker advertises multiple routes to a destination and a route gets withdrawn, here's the deal 🌈 If a label(s) is specified at the time of withdrawal, only the matching route with the matching label is withdrawn. If no label is specified at withdrawal, only the matching unlabeled route is withdrawn, and the labeled routes stay right where they are 🫧

5. Capability Advertisement 🎀

A BGP speaker that uses Multiprotocol Extensions to carry label mapping info should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to tell its peers about this capability. The MP_EXT Capability Code, as defined in [BGP-MP], is used to advertise the (AFI, SAFI) pairs available on a particular connection 📡

A BGP speaker should not advertise this capability to another BGP speaker unless there's a Label Switched Path (LSP) between the two speakers. No LSP, no capability, no cap 🙅‍♀️

A BGP speaker that can handle multiple routes to a destination (like we talked about above) should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to tell its peers about this capability. The value of this capability is 4 🦋

6. When the BGP Peers are not Directly Adjacent 🌸

Okay, picture this LSR topology: A--B--C--D. Suppose D distributes a label L to A. In this setup, A can't just push L onto a packet's label stack and send the result to B. D has to be the only LSR that sees L at the top of the stack 👑 So before A sends the packet to B, A has to push on another label, which B distributed. Then B has to swap that label for yet another one, which C distributed. In other words, there has to be an LSP between A and D. If there's no such LSP, A can't make use of label L. This is true any time labels get distributed between non-adjacent LSRs, whether BGP does it or some other method 😭

This document does NOT specify any procedure for making sure, in real time, that label distribution between non-adjacent LSRs only happens when the right MPLS infrastructure exists in the network (or networks) connecting the two LSRs. Making sure that infrastructure is in place is a job for network management and operation. Not this doc's problem, sweetie 🫶

7. Security Considerations 🔐

Okay bestie, this part is serious, so listen up 👀. When LSR A is directly connected to LSR B over a point-to-point interface, A knows that any packet arriving on that interface came from B. 🎯 That makes it super easy for A to toss any packet from B whose top labels aren't among the labels A handed out to B. So A can make sure B only uses the labels it's actually allowed to use. 💅 This trick can stop "label spoofing," which is when an LSR slaps on a label that was never properly distributed to it. 🚫

The procedures in this document would usually come into play when the label distribution peers are separated by more than just a point-to-point link, and are instead connected through an MPLS network. 🌐 That means when LSR A processes a labeled packet, it literally has no way to figure out which LSR B pushed on the top label. 😭 So it can't tell whether that label is one B is entitled to use. And ngl, when Route Reflectors are in use, A may not even know the set of LSRs that receive its label mappings. 💀 So the previous paragraph's technique for preventing label spoofing doesn't apply here. Not me having to say that. 🙈

Good news though, there are other ways to dodge label spoofing problems 🦋. For example, if you never accept labeled packets from the network's "external" interfaces, and all the BGP-distributed labels are advertised via IBGP, then there's no way for an untrusted router to sneak a labeled packet into the network. 🛡️ You can generally assume that your IBGP peers (or the IBGP peers of your Route Reflector) won't try label spoofing, because they're all under the control of a single administration. 👑

This condition can actually be weakened a LOT ✨. You don't have to refuse every single labeled packet from external interfaces. You just need to make sure that any labeled packet received on an external interface has a top label that was actually distributed out that interface. 🎀

So a label spoofing problem would only exist if there are both trusted and untrusted systems out the same interface. 🧐 One way to avoid this problem is simply to avoid that situation. Iconic, honestly 💖.

8. Acknowledgments 🫶

Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and Liam Casey for their comments. 🌸 Ily, you legends 💜.

9. References 📚

[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.

[BGP-MP] Bates, T., Rekhter, Y, Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.

[MPLS-ARCH] Rosen, E., Vishwanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture" RFC 3031, January 2001.

[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

10. Authors' Addresses 🧚

Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089

EMail: yakov@juniper.net


Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

EMail: erosen@cisco.com

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🍓

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from