RFC 2858

Multiprotocol Extensions for BGP-4

📅 published June 2000, from ietf

RFC 2858: Multiprotocol Extensions for BGP-4 💖

okay bestie, so this one is RFC 2858, Multiprotocol Extensions for BGP-4 🦋 It's a Standards Track doc from June 2000, written by T. Bates and Y. Rekhter (Cisco Systems), R. Chandra (Redback Networks Inc), and D. Katz (Juniper Networks). It obsoletes RFC 2283, and the header doesn't list any updates. Let's gooo ✨

Status of this Memo

ok so this section is the boring-but-important bit 🙈 It says this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. If you want to know where this protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 💅

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

Abstract

so BGP-4 [BGP-4] can only carry routing info for IPv4 [IPv4] right now 🥺 This doc adds extensions so BGP-4 can carry routing info for multiple Network Layer protocols, like IPv6, IPX, etc... 🌈 The extensions are backward compatible, which is the iconic part: a router that supports them can still interoperate with a router that doesn't 🫶

This document obsoletes RFC 2283.

1. Overview

okay here's the main idea 🧚 In BGP-4, only three things are IPv4-specific:

  • (a) the NEXT_HOP attribute, which is expressed as an IPv4 address
  • (b) AGGREGATOR, which contains an IPv4 address
  • (c) NLRI, which is expressed as IPv4 address prefixes

This doc assumes that any BGP speaker has to have an IPv4 address, including the ones that support the multiprotocol capabilities defined here. That address gets used for stuff like the AGGREGATOR attribute. So to make BGP-4 support routing for multiple Network Layer protocols, you only need to add two things: (a) a way to link a particular Network Layer protocol with the next hop info, and (b) a way to link a particular Network Layer protocol with NLRI. To identify each Network Layer protocol, this doc uses Address Family, as defined in [RFC1700] 💅

ngl this next part is so smart 🧠 The next hop info (what the NEXT_HOP attribute carries) only matters when you're advertising reachable destinations. When you're withdrawing unreachable destinations from service, the next hop info is meaningless 💀 So it makes sense to group the reachable destinations with the next hop you'll use for them, and keep them separate from the unreachable ones 🍓

To keep backward compatibility and make it easier to bring multiprotocol capabilities into BGP-4, this doc uses two new attributes: Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) ✨

  • MP_REACH_NLRI carries the set of reachable destinations, plus the next hop info used to forward to them.
  • MP_UNREACH_NLRI carries the set of unreachable destinations.

Both attributes are optional and non-transitive. So a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the info in these attributes, and it won't pass them on to other BGP speakers. Iconic behaviour, honestly 👑

2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14) ✨

this is an optional non-transitive attribute, and it's giving multitasking. It can be used for:

  • (a) advertising a feasible route to a peer
  • (b) letting a router advertise the Network Layer address of the router that should be used as the next hop to the destinations listed in the Network Layer Reachability Information field of the MP_NLRI attribute
  • (c) letting a given router report some or all of the Subnetwork Points of Attachment (SNPAs) that exist within the local system

Here's how the attribute is encoded 🎀

      +---------------------------------------------------------+
      | Address Family Identifier (2 octets)                    |
      +---------------------------------------------------------+
      | Subsequent Address Family Identifier (1 octet)          |
      +---------------------------------------------------------+
      | Length of Next Hop Network Address (1 octet)            |
      +---------------------------------------------------------+
      | Network Address of Next Hop (variable)                  |
      +---------------------------------------------------------+
      | Number of SNPAs (1 octet)                               |
      +---------------------------------------------------------+
      | Length of first SNPA(1 octet)                           |
      +---------------------------------------------------------+
      | First SNPA (variable)                                   |
      +---------------------------------------------------------+
      | Length of second SNPA (1 octet)                         |
      +---------------------------------------------------------+
      | Second SNPA (variable)                                  |
      +---------------------------------------------------------+
      | ...                                                     |
      +---------------------------------------------------------+
      | Length of Last SNPA (1 octet)                           |
      +---------------------------------------------------------+
      | Last SNPA (variable)                                    |
      +---------------------------------------------------------+
      | Network Layer Reachability Information (variable)       |
      +---------------------------------------------------------+

Now let's break down what each field means 🔍

Address Family Identifier: this field carries the identity of the Network Layer protocol linked to the Network Address that follows. The values defined right now are specified in RFC 1700 (see the Address Family Numbers section) 🌸

Subsequent Address Family Identifier: this field gives extra info about the type of Network Layer Reachability Information carried in the attribute 💜

Length of Next Hop Network Address: a 1 octet field. Its value is the length of the "Network Address of Next Hop" field, measured in octets 📏

Network Address of Next Hop: a variable length field with the Network Address of the next router on the path to the destination system 🛣️

Number of SNPAs: a 1 octet field with the number of distinct SNPAs listed in the following fields. The value 0 may be used to show that no SNPAs are listed in this attribute 🙌

Length of Nth SNPA: a 1 octet field. Its value is the length of the "Nth SNPA of Next Hop" field, measured in semi-octets 🧮

Nth SNPA of Next Hop: a variable length field with an SNPA of the router whose Network Address is in the "Network Address of Next Hop" field. The field length is an integral number of octets: it's the rounded-up integer value of one half the SNPA length in semi-octets. If the SNPA has an odd number of semi-octets, a value in this field gets padded with a trailing all-zero semi-octet 🧩

Network Layer Reachability Information: a variable length field that lists the NLRI for the feasible routes being advertised in this attribute. When the Subsequent Address Family Identifier field is set to one of the values defined in this document, each NLRI is encoded as specified in the "NLRI encoding" section of this document 🦋

Next hop info is the vibe here 🌈 The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the border router that should be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message. When a router advertises an MP_REACH_NLRI attribute to an external peer, it may use one of its own interface addresses in the next hop component, as long as the external peer shares a common subnet with that next hop address. This is called a "first party" next hop 💖

A BGP speaker can also advertise an interface of any internal peer router to an external peer in the next hop component, as long as the external peer shares a common subnet with the next hop address. This is called a "third party" next hop information 🔮

And there's a second kind of third party next hop 🫣 A BGP speaker can advertise any external peer router in the next hop component, as long as the Network Layer address of this border router was learned from an external peer, and the external peer receiving the route shares a common subnet with the next hop address. This is a second form of "third party" next hop information 💅

Normally, the next hop info gets chosen so the shortest available path will be taken 🏃‍♀️ A BGP speaker must be able to support disabling advertisement of third party next hop information, to handle imperfectly bridged media or for reasons of policy. Main character energy for sure 👑

A BGP speaker must never advertise an address of a peer to that peer as a next hop, for a route that the speaker is originating. And a BGP speaker must never install a route with itself as the next hop. No exceptions bestie 🚫

When a BGP speaker advertises the route to an internal peer, the advertising speaker should not modify the next hop information associated with the route. When a BGP speaker receives the route via an internal link, it may forward packets to the next hop address if the address in the attribute is on a common subnet with the local and remote BGP speakers 🫶

An UPDATE message that carries the MP_REACH_NLRI must also carry the ORIGIN and the AS_PATH attributes, in both EBGP and IBGP exchanges. Also, in IBGP exchanges, such a message must also carry the LOCAL_PREF attribute 📦 If such a message is received from an external peer, the local system shall check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If that isn't the case, the local system shall send the NOTIFICATION message with Error Code UPDATE Message Error, and the Error Subcode set to Malformed AS_PATH. 🚨

Last bit for this part: an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. If such a message does contain the NEXT_HOP attribute, the BGP speaker that receives the message should ignore this attribute 🙈

3. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15): 🦋

okay so this one is the withdrawal twin of the last attribute 🫶 it's an optional non-transitive attribute, and its whole job is to pull multiple unfeasible routes out of service in one go. no cap, it's giving clean breakup energy 💀

the layout looks like this:

   +---------------------------------------------------------+
   | Address Family Identifier (2 octets)                    |
   +---------------------------------------------------------+
   | Subsequent Address Family Identifier (1 octet)          |
   +---------------------------------------------------------+
   | Withdrawn Routes (variable)                             |
   +---------------------------------------------------------+

here's what each piece does ✨

Address Family Identifier:

This one tells you which Network Layer protocol the NLRI that follows belongs to. The values that are defined right now are specified in RFC 1700 (see the Address Family Numbers section) 🌸

Subsequent Address Family Identifier:

This one gives extra detail about what kind of Network Layer Reachability Information is riding along in the attribute 🎀

Withdrawn Routes:

This is a variable-length field that lists the NLRI for every route being withdrawn from service 😭 When the Subsequent Address Family Identifier is set to one of the values defined in this document, each NLRI is encoded the way the "NLRI encoding" section of this document says, so go check Section 4 for that 👑

An UPDATE message that carries the MP_UNREACH_NLRI is not required to carry any other path attributes. so yes, it can be solo and still slay 💅

4. NLRI encoding 🧚

okay this is the bit where the actual prefixes get packed up 📦 The Network Layer Reachability information is encoded as one or more 2-tuples of the form <length, prefix>, and each field looks like this:

   +---------------------------+
   |   Length (1 octet)        |
   +---------------------------+
   |   Prefix (variable)       |
   +---------------------------+

here's how the two fields work 🍓

a) Length:

The Length field tells you the length in bits of the address prefix. A length of zero means a prefix that matches all addresses (as specified by the address family), and that prefix has zero octets, itself 🌈

b) Prefix:

The Prefix field carries an address prefix, then keeps adding trailing bits until the end of the field lands on an octet boundary. Also, the value of those trailing bits is irrelevant, so don't stress about them 🙈

5. Subsequent Address Family Identifier 💜

this section is the SAFI menu for the attributes. This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes:

  • 1 - Network Layer Reachability Information used for unicast forwarding 💖
  • 2 - Network Layer Reachability Information used for multicast forwarding ✨
  • 3 - Network Layer Reachability Information used for both unicast and multicast forwarding 🔥

6. Error Handling 🚨

okay this part is lowkey serious, so listen up 👂 If a BGP speaker gets an Update message from a neighbor that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the speaker decides that the attribute is incorrect, the speaker MUST delete all the BGP routes it received from that neighbor whose AFI/SAFI matches the one in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute. For as long as the BGP session that carried that Update message stays up, the speaker SHOULD then ignore all the later routes with that AFI/SAFI that come in over that session 🫠

Also, the speaker MAY terminate the BGP session that the Update message came in on. If it does, the session SHOULD be terminated with the Notification message code/subcode indicating "Update Message Error"/"Optional Attribute Error" 💀

the vibe check here is: bad attribute means the routes go, and the session might get closed out too. not a good look for anyone 🙅‍♀️

7. Use of BGP Capability Advertisement 🎀

A BGP speaker that uses Multiprotocol Extensions SHOULD use the Capability Advertisement procedures [BGP-CAP] to figure out whether the speaker could use Multiprotocol Extensions with a particular peer 🧚

The fields in the Capabilities Optional Parameter get set like this. The Capability Code field is set to 1 (which means Multiprotocol Extensions capabilities). The Capability Length field is set to 4. The Capability Value field is defined as:

      The use and meaning of this field is as follow:

                        0       7      15      23      31
                        +-------+-------+-------+-------+
                        |      AFI      | Res.  | SAFI  |
                        +-------+-------+-------+-------+

the three parts are 🫶

  • AFI - Address Family Identifier (16 bit), encoded the same way as in the Multiprotocol Extensions
  • Res. - Reserved (8 bit) field. The sender sets it to 0, which is the expected move, and the receiver just ignores it 🌸
  • SAFI - Subsequent Address Family Identifier (8 bit), encoded the same way as in the Multiprotocol Extensions

A speaker that supports multiple <AFI, SAFI> tuples includes each of them as multiple Capabilities in the Capabilities Optional Parameter 🌈

For a bi-directional exchange of routing information for a particular <AFI, SAFI> between a pair of BGP speakers, each speaker MUST advertise to the other one (via the Capability Advertisement mechanism) the capability to support that particular <AFI, SAFI> routes. no skipping this step, bestie 👑

8. IANA Considerations 🍓

As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI attributes contain the Subsequence Address Family Identifier (SAFI) field. The SAFI name space is defined in Section 9. The IANA will maintain and register values for the SAFI namespace as follows. SAFI value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this document. SAFI values 4 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. SAFI values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. SAFI values 128 through 255 are for "private use", and values in this range are not to be assigned by IANA 🔒

9. Comparison with RFC 2283 🦋

this section is the glow-up summary, comparing everything to RFC 2283 💅

  • This document restricts the MP_REACH_NLRI attribute to carry only a single instance of <AFI, SAFI, Next Hop Information, ...>.
  • This document restricts the MP_UNREACH_NLRI attribute to carry only a single instance of <AFI, SAFI, ...>.
  • This document clarifies handling of an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute.
  • This document clarifies error handling in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI attributes.
  • This document specifies the use of BGP Capabilities Advertisements in conjunction with Multi-protocol extensions.
  • Finally, this document includes the "IANA Consideration" Section.

10. Security Considerations 🔐

okay this one is serious, so I'm keeping it full strength 😤 This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan]. so the BGP security problems that were already there are still there, and this extension does not fix them 💀 go read [Heffernan] and treat BGP sessions with respect 🫶

11. Acknowledgements 🌸

The authors would like to thank members of the IDR Working Group for their review and comments. the squad that helped make this happen 🎀

12. References 📚

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

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

   [Heffernan]  Heffernan, A., "Protection of BGP Sessions via the TCP
                MD5 Signature Option", RFC 2385, August 1998.

   [IPv4]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [RFC1700]    Postel, J. and J. K. Reynolds, "Assigned Numbers", STD
                2, RFC 1700, October 1994. (see also
                http://www.iana.org/iana/assignments.html)

13. Authors' Addresses 💌

   Tony Bates
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

   EMail: tbates@cisco.com


   Ravi Chandra
   Redback Networks Inc.
   350, Holger Way
   San Jose, CA 95134


   EMail: rchandra@redback.com

   Dave Katz
   Juniper Networks, Inc.
   3260 Jay St.
   Santa Clara, CA 95054

   EMail: dkatz@jnx.com


   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

   EMail: yakov@cisco.com

Copyright (C) The Internet Society (2000). 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