RFC 2545

Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing 🦋

RFC 2545 💖 okay bestie, this one is a Standards Track doc from March 1999, and it's from the Network Working Group. P. Marques (cisco Systems, Inc.) and F. Dupont (Inria) wrote it. It doesn't obsolete or update anything, so it's its own little main character 💅

Status of this Memo

Okay, the status bit: this is an Internet standards track protocol for the Internet community ✨ It's open for discussion and suggestions for improvements 🫶 For where it sits in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 And the distribution of this memo is unlimited 🌈

Copyright Notice

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

Abstract

So basically, [BGP-MP] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, which are used to announce reachability information and withdraw those announcements 🦋 This doc explains how compliant systems should use those attributes to carry IPv6 routing information. It's giving clean, organized, and very intentional 💅

1. Introduction ✨

BGP-4 [BGP-4] and path vector routing protocols in general don't really care which Address Family they're carrying 🧚 They're pretty independent of it.

IPv6 is totally in the category of protocols that BGP-4 works well for. Unless this doc says otherwise, the BGP-4 procedures for carrying IPv6 reachability information are the ones in [BGP-4] and in later documents that extend or update the BGP-4 spec 🌸

The biggest routing difference between IPv6 and IPv4 (which BGP was originally designed for) is that IPv6 has scoped unicast addresses and specific situations where a particular address scope must be used 👑 This doc is mostly about the rules that make IPv6 address scope requirements work 🫶

2. IPv6 Address Scopes

IPv6 has 3 unicast address scopes [ADDR-ARCH]: global, site-local, and link-local 🌈 Site-local addresses are non-link-local addresses that are valid inside a "site" and can't be exported beyond it. This doc doesn't assume anything about the routing realm where BGP-4 is used, so it doesn't treat global and site-local addresses differently. It calls both of them "global" or "non-link-local" 🎀 Network administrators still have to respect address scope restrictions, though. A BGP-4 routing domain and a "site" are orthogonal ideas, and they may or may not line up in a given situation 🔥

Other IPv6 specs say that only link-local addresses can be used when generating ICMP Redirect Messages [ND], and as next hop addresses in some routing protocols (eg. RIPng [RIP]) 💅

This restriction means an IPv6 router needs a link-local next hop address for all directly connected routes. Those are the routes where the router and the next hop router share a common subnet prefix 🧚

Link-local addresses aren't a great fit for next hop attributes in BGP-4, though, because of the rules the protocol spec defines for that attribute [BGP-4] 😭

So when BGP-4 carries IPv6 reachability information, it sometimes has to announce a next hop attribute made of a global address and a link-local address 🍓 The next section explains the rules for building the Network Address of Next Hop field of an MP_REACH_NLRI attribute.

3. Constructing the Next Hop field

Okay, this is the core rule 💖 A BGP speaker shall advertise to its peer, in the Network Address of Next Hop field, the global IPv6 address of the next hop, optionally followed by the link-local IPv6 address of the next hop.

The Length of Next Hop Network Address field on an MP_REACH_NLRI attribute shall be set to 16 when only a global address is present. It shall be set to 32 if a link-local address is also included in the Next Hop field ✨

The link-local address shall be included in the Next Hop field if, and only if, the BGP speaker shares a common subnet with the entity identified by the global IPv6 address in the Network Address of Next Hop field, and with the peer the route is being advertised to 🫶

In all other cases, a BGP speaker shall advertise to its peer only the global IPv6 address of the next hop in the Network Address field. The value of the Length of Network Address of Next Hop field shall be set to 16 🌸

So a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop 🦋

4. Transport

TCP connections carry BGP-4 messages, and they can be set up over either IPv4 or IPv6 🌈 BGP-4 itself doesn't depend on the transport, but it does pick up implicit configuration info from the address used to set up the peering session 👀 That info (the network address of a peer) is part of the route dissemination procedure. So when you run TCP over IPv4 to carry IPv6 reachability information, you need extra explicit configuration of the peer's network address 🎀

Note that this info is different from the BGP Identifier used in the BGP-4 tie breaking procedure. The BGP Identifier is a 32 bit unsigned integer that two peers swap during session establishment, inside an OPEN message 🧚 It's a system-wide value set at startup, it must be unique in the network, and it should be derived from an IPv4 address, no matter which network protocol(s) that BGP-4 instance is set up to carry at a given moment 💅

Running TCP over IPv6 to carry IPv6 reachability information also has a perk: it gives explicit confirmation that IPv6 network reachability exists between the two peers ✨ Iconic behavior 👑

5. Security Considerations

🚨 Serious moment, bestie. The extensions in this doc let BGP propagate reachability information about IPv6 routes. No new security issues are raised beyond the ones that already exist in BGP-4 and its use with IPv4 💀

6. Acknowledgments

This doc comes from the BGP-4 Multiprotocol Extensions work by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter 🫶🌈

7. References

Here are the refs, all listed in full 📚

[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 2373, July 1998.

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

[BGP-MP]    Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
            "Multiprotocol Extensions for BGP-4", RFC 2283, February
            1998.

[IPv6]      Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

[ND]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", RFC 2461, December
            1998.

[RIP]       Malkin, G. and R. Minnear, "RIPng for IPv6",
            RFC 2080, January 1997.

8. Author Information

Who's who 🎀 Here's contact info for the authors, copied exactly as written:

Pedro R. Marques
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA

Phone: +1 408 527-5202
Fax:   +1 408 526-4952
EMail: roque@cisco.com


Francis Dupont
GIE DYADE
INRIA Rocquencourt
Domaine de Voluceau
BP 105
78153 Le Chesnay CEDEX
FRANCE

Phone: +33 1 39 63 52 13
Fax:   +33 1 39 63 58 66
EMail: Francis.Dupont@inria.fr

9. Full Copyright Statement

Last but not least, the legal part 🙈 Here's the full copyright statement, copied exactly so nothing gets lost:

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

---

That's the whole thing, bestie 🌈💖✨ Literally iconic work from these authors. Periodt 👑