RFC 5549

Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop

📅 published May 2009, from ietf

Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop ✨

Okay bestie, this is RFC 5549 🎀, a Standards Track doc from F. Le Faucheur and E. Rosen at Cisco Systems, dated May 2009. It's from the Network Working Group 🌸. The title block doesn't list any RFCs that it obsoletes or updates, so it's not replacing or changing anything else 💅.

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and it's asking everyone for 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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document 👀.

Abstract

Okay so, Multiprotocol BGP (MP-BGP) says the set of network-layer protocols that the address in the Next Hop field can belong to gets decided by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) 🧚. The current AFI/SAFI definitions for the IPv4 address family only let you advertise a Next Hop address that belongs to IPv4 when you're advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This doc adds the extensions needed so you can advertise IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to IPv6 🌈. That covers extending the AFI/SAFI definitions so the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI can also be IPv6, the encoding that tells you which protocol the address actually belongs to, and a brand new BGP Capability so MP-BGP Peers can dynamically figure out whether they can swap IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop ✨.

Table of Contents

1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4
4. Use of BGP Capability Advertisement .............................5
5. Operations ......................................................7
6. Usage Examples ..................................................7
   6.1. IPv4 over IPv6 Core ........................................7
   6.2. IPv4 VPN over IPv6 Core ....................................8
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
   10.1. Normative References ......................................9
   10.2. Informative References ....................................9

1. Introduction ✨

Okay so Multiprotocol BGP (MP-BGP) [RFC4760] says the set of network-layer protocols that the address in the Next Hop field can belong to is decided by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) 💖. Lots of existing AFI/SAFIs already let the Next Hop address belong to a different address family than the NLRI does 🙈. For example, the AFI/SAFI <25/65> (used as per [L2VPN-SIG]) is for L2VPN auto-discovery. It lets you advertise NLRI that holds the identifier of a Virtual Private LAN Service (VPLS) instance, or that identifies a particular pool of attachment circuits at a given Provider Edge (PE), while the Next Hop field has the loopback address of a PE 🍓. Similarly, the AFI/SAFI <1/132> (defined in [RFC4684]) is for advertising Route Target (RT) membership information. It lets you advertise NLRI with that RT membership info, while the Next Hop field has the address of the advertising router 🦋.

Furthermore, a bunch of these existing AFI/SAFIs let the Next Hop belong to either the IPv4 Network Layer Protocol or the IPv6 Network Layer Protocol, and they spell out how the Next Hop info is encoded so you can tell which protocol the address actually belongs to 💅. For example, [RFC4684] allows the Next Hop address to be either IPv4 or IPv6. It says the Next Hop field address shall be interpreted as an IPv4 address whenever the length of the Next Hop address is 4 octets, and as an IPv6 address whenever the length of the Next Hop address is 16 octets 🔥.

There are situations, like the ones described in [RFC4925] and in [MESH-FMWK], where carriers (or big enterprise networks acting as carriers for their own internal resources) need to connect 'islands' of networks of one address family type across a transit core of a different address family type 🌸. That covers IPv6 islands across an IPv4 core, and IPv4 islands across an IPv6 core 🧚. When Multiprotocol BGP (MP-BGP) is being used to advertise that reachability info, it turns into a requirement for a BGP speaker to advertise Network Layer Reachability Information (NLRI) of one address family via a Next Hop of a different address family. In other words, IPv6 NLRI with an IPv4 Next Hop, and IPv4 NLRI with an IPv6 Next Hop 🫶.

The current AFI/SAFI definitions for the IPv6 address family assume that the Next Hop address belongs to the IPv6 address family type 👑. Specifically, as per [RFC2545] and [RFC3107], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop address is assumed to be IPv6-VPN type 🌈.

BUT, [RFC4798] and [RFC4659] already spell out how an IPv4 address can be encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 Next Hop ✨. [RFC4798] defines how the IPv4-mapped IPv6 address format (specified in the IPv6 addressing architecture, [RFC4291]) can be used for that when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4> 💜. [RFC4659] defines how the IPv4-mapped IPv6 address format, plus a null Route Distinguisher, can be used for that when the <AFI/SAFI> is <2/128> 🍓. So yep, there are already solutions for advertising IPv6 NLRI with an IPv4 Next Hop 🎀.

Now, the current AFI/SAFI definitions for advertising IPv4 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the IPv4 address family type 🙈. Specifically, as per [RFC4760] and [RFC3107], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the Next Hop address is assumed to be IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the Next Hop address is assumed to be VPN-IPv4 type. And there's clearly no generally applicable method for encoding an IPv6 address inside the IPv4 address field of the Next Hop 💀. So, honestly, there's currently no specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop 😭.

That's where this doc comes in 🦋. It specifies the extensions needed to do that. It extends the AFI/SAFI definitions so the Next Hop address for IPv4 NLRI or VPN-IPv4 NLRI can belong to either the IPv4 or the IPv6 protocol. It also covers the encoding of the Next Hop info, so you can tell which protocol the address actually belongs to, and a new BGP Capability so MP-BGP peers can dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop 👑. The new BGP Capability is what makes gradual deployment possible for advertising IPv4 reachability via an IPv6 Next Hop, with no flag day and no risk of traffic black-holing 💖🌸.

2. Requirements Language 🌷

Okay so the BCP 14 key words in this document are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 🧠. They're to be interpreted as described in RFC 2119 [RFC2119] 💅.

3. Extension of AFI/SAFI Definitions for the IPv4 Address Family 🎀

As we said earlier, MP-BGP says the set of network-layer protocols that the address in the Next Hop field can belong to is decided by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) 💖. The current AFI/SAFI definitions for IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, and <1/128>) only have room for a Next Hop address that belongs to IPv4 🙈. This doc extends the definition of the AFI/SAFI for advertising IPv4 NLRI and VPN-IPv4 NLRI, so the set of network-layer protocols for the Next Hop address now includes IPv6 as well as IPv4 🌈.

Specifically, this document allows advertising with [RFC4760] of an MP_REACH_NLRI with:

  • AFI = 1
  • SAFI = 1, 2, 4, or 128
  • Length of Next Hop Address = 16 or 32
  • Next Hop Address = IPv6 address of next hop (potentially followed by the link-local IPv6 address of the next hop). This field is to be constructed as per Section 3 of [RFC2545].
  • NLRI= NLRI as per current AFI/SAFI definition

This is in addition to the current way of doing things, where NLRI for <AFI/SAFI> of <1/1>, <1/2>, and <1/4> is advertised with a next hop address of IPv4 type, and NLRI for <AFI/SAFI> of <1/128> is advertised with a next hop address of VPN-IPv4 type 🍓.

The BGP speaker receiving the advertisement MUST use the Length of Next Hop Address field to determine which network-layer protocol the next hop address belongs to ✨. When the Length of Next Hop Address field is equal to 16 or 32, the next hop address is of type IPv6 🫶.

Note that using the Length of the Next Hop Address field to figure out which network-layer protocol the next hop address belongs to (out of the set of protocols that the AFI/SAFI definition allows) is the same method used in [RFC4684] and [L2VPN-SIG] 🦋. Iykyk, it's giving consistency 💜.

4. Use of BGP Capability Advertisement ✨

okay so [RFC5492] is the thing that lets two BGP speakers check whether their peer supports a given capability before they use it 🫶. This document adds a new capability called the Extended Next Hop Encoding capability, which is advertised through [RFC5492]. It lets BGP speakers find out whether, for a given NLRI <AFI/SAFI>, their peer can take a next hop whose network protocol is set by the value of the Length of Next Hop Address field, as described in Section 3. 🦋

A BGP speaker that wants to advertise an IPv6 Next Hop for IPv4 NLRI, or for VPN-IPv4 NLRI, under this specification MUST use the Capability Advertisement procedures defined in [RFC5492] together with the Extended Next Hop Encoding Capability. That's how it checks whether its peer supports this for the NLRI AFI/SAFI pair(s) it cares about. The fields in the Capabilities Optional Parameter MUST be set as follows: 💅

  • The Capability Code field MUST be set to 5, which means the Extended Next Hop Encoding capability.
  • The Capability Length field is a variable value. It's the length of the Capability Value field that follows.
  • The Capability Value field has this format:
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets)                             |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets)                            |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets)                          |
+-----------------------------------------------------+
| .....                                               |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets)                             |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets)                            |
+-----------------------------------------------------+
| Nexthop AFI - N (2 octets)                          |
+-----------------------------------------------------+

where:

  • each triple <NLRI AFI, NLRI SAFI, Nexthop AFI> says that NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a Next Hop address that belongs to the network-layer protocol of Nexthop AFI. 🌸
  • the AFI and SAFI values come from the Address Family Identifier and Subsequent Address Family Identifier registries that IANA maintains.

Since this document only covers advertising IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification only allows these values in the Capability Value field of the Extended Next Hop Encoding capability:

  • NLRI AFI = 1 (IPv4)
  • NLRI SAFI = 1, 2, 4, or 128
  • Nexthop AFI = 2 (IPv6)
⚠️ bestie, this spec does NOT propose using the Extended Next Hop Encoding capability with any other combination of <NLRI AFI, NLRI SAFI, Nexthop AFI>. 🙈

It especially doesn't propose using it for NLRI AFI/SAFIs whose definition already lets them use both IPv4 and IPv6 next hops, like AFI/SAFI = <1/132> from [RFC4684]. It also doesn't propose using it for NLRI AFI/SAFIs that already have a way to advertise a next hop from a different address family. Examples are AFI/SAFI = <2/1>, <2/2>, or <2/4> with an IPv4 Next Hop per [RFC4798], and AFI/SAFI = <2/128> with an IPv4 Next Hop per [RFC4659]. 💀

If new AFI/SAFIs get defined later, the expectation is that their definitions will include provisions (where that makes sense) for both IPv4 and IPv6 Next Hops from the start, with the choice based on the Length of Next Hop Address field. So new AFI/SAFIs aren't expected to use the Extended Next Hop Encoding capability. 🧚

A BGP speaker MUST only advertise IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop to a BGP peer after it has first confirmed, through BGP Capability Advertisement, that the peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 👑

The Extended Next Hop Encoding capability tells you about next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is allowed. It doesn't decide whether that AFI/SAFI is actually allowed. Whether an AFI/SAFI can be used between the BGP peers is determined purely by the Multiprotocol Extensions capability defined in [RFC4760]. 💖

The Extended Next Hop Encoding capability MAY be dynamically updated through the Dynamic Capability capability and the associated mechanisms defined in [DYN-CAP]. ✨

5. Operations 🌈

By default, if a BGP session is running over IPvx (where IPvx is IPv4 or IPv6), and the BGP speaker sending an update puts its own address in as the next hop, then the next hop address SHOULD be specified as an IPvx address. It uses the encoding rules from the AFI/SAFI definition of the NLRI being updated. This default behavior may be overridden by policy. 🎀

When a next hop address needs to be passed along unchanged, like when a Route Reflector (RR) is doing its thing, its encoding MUST NOT be changed. If a particular RR client can't handle that encoding (as the BGP Capability Advertisement tells you), then the NLRI in question can't be distributed to that client. For sound routing in certain scenarios, all the RR clients need to be able to handle whatever encodings any of them may generate. 😭

6. Usage Examples 🍓

6.1. IPv4 over IPv6 Core 🌐

The extensions in this document may be used as discussed in [MESH-FMWK] to interconnect IPV4 islands over an IPv6 backbone. In this setup, Address Family Border Routers (AFBRs; as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop. 💅

The MP_REACH_NLRI is encoded with:

  • AFI = 1
  • SAFI = 1
  • Length of Next Hop Network Address = 16 (or 32)
  • Network Address of Next Hop = IPv6 address of Next Hop
  • NLRI = IPv4 routes

During BGP Capability Advertisement, the PE routers would include these fields in the Capabilities Optional Parameter:

  • Capability Code set to "Extended Next Hop Encoding"
  • Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2>

6.2. IPv4 VPN over IPv6 Core 💜

The extensions in this document may also be used to support IPV4 VPNs over an IPv6 backbone. Here, PE routers advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 Next Hop. 🦋

The MP_REACH_NLRI is encoded with:

  • AFI = 1
  • SAFI = 128
  • Length of Next Hop Network Address = 16 (or 32)
  • Network Address of Next Hop = IPv6 address of Next Hop
  • NLRI = IPv4-VPN routes

During BGP Capability Advertisement, the PE routers would include these fields in the Capabilities Optional Parameter:

  • Capability Code set to "Extended Next Hop Encoding"
  • Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop AFI=2>

7. IANA Considerations 🧾

This document defines, in Section 4, a new Capability Code for the Extended Next Hop Encoding capability in the [RFC5492] Capabilities Optional Parameter. The value for this new Capability Code is 5. It sits in the range set aside for allocation under the "IETF Review" policy defined in [RFC5226]. ✨

8. Security Considerations 🔐

This document doesn't raise any security issues beyond the ones already in BGP-4 and the Multiprotocol extensions for BGP-4. The same security mechanisms apply. 🛡️

It's not expected to be the typical case, but the IPv6 address used as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as defined in [RFC4291]). So if the network operator has security mechanisms deployed (like security checks on the next hop address), their configuration needs to keep this case in mind too. 👀 Don't skip this one, it's the kind of edge case that sneaks up on people! 😱

9. Acknowledgments 🫶

The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in this document. 💖

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
  • [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
  • [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
  • [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.

10.2. Informative References

  • [DYN-CAP] Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, November 2006.
  • [L2VPN-SIG] Rosen, E., "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, May 2006.
  • [MESH-FMWK] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", Work in Progress, February 2009.
  • [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
  • [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
  • [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
  • [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Authors' Addresses 🎀

Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France

EMail: flefauch@cisco.com

Eric Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA

EMail: erosen@cisco.com

📦 where this page comes from