RFC 8950

Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

📅 published November 2020, from ietf

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

Okay bestie, this is RFC 8950 🫶 It's an IETF doc, filed as a Standards Track document, dated November 2020. The ISSN is 2070-1721 if you're into that 💅. The authors are S. Litkowski, S. Agrawal, and K. Ananthamurthy from Cisco, plus K. Patel from Arrcus. And the big drama: this doc obsoletes RFC 5549 👑

Abstract 🦋

Okay so MP-BGP (Multiprotocol BGP) decides which next-hop address families are allowed by using the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) 💅. The AFI/SAFI definitions for the IPv4 address family only have room for a next-hop address that belongs to the IPv4 protocol, and that's when you're advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. Not me being like, wait, what 🙈

This doc lays out the extensions that let you advertise IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to IPv6 ✨ There are three pieces. First, the AFI/SAFI definitions get extended so the next hop for IPv4 NLRI or VPN-IPv4 NLRI can also be an IPv6 address. Second, the next-hop encoding tells you which protocol the address actually belongs to. Third, there's a 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. Iconic 🔥 This document obsoletes RFC 5549.

Status of This Memo 📜

This is an Internet Standards Track document, so it's the real deal 🌟

It comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🎀

Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8950 💌

Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions with respect to this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🙏

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  Changes Compared to RFC 5549
3.  Extension of AFI/SAFI Definitions for the IPv4 Address Family
4.  Use of BGP Capability Advertisement
5.  Operations
6.  Usage Examples
  6.1.  IPv4 over IPv6 Core
  6.2.  IPv4 VPN Unicast over IPv6 Core
  6.3.  IPv4 VPN Multicast over IPv6 Core
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌸

Okay so MP-BGP [RFC4760] decides which network-layer protocols the address in the Next Hop Address field can belong to, and that's determined by the AFI and SAFI. Here's the tea: a bunch of existing AFIs/SAFIs let the next hop belong to a different address family than the NLRI does. For example, AFI/SAFI <25/65> (used as per [RFC6074]) for Layer 2 Virtual Private Network (L2VPN) auto-discovery carries NLRI with the identifier of a Virtual Private LAN Service (VPLS) instance, or with a particular pool of attachment circuits at a given Provider Edge (PE), while the Next Hop Address field holds the loopback address of a PE. Similarly, AFI/SAFI <1/132> (defined in [RFC4684]) for advertising Route Target (RT) membership info carries that RT membership info in the NLRI, while the Next Hop Address field holds the address of the advertising router 💖

Plus, a lot of those AFIs/SAFIs let the next hop be either IPv4 or IPv6, and they spell out the encoding so you can tell which one it is. For example, [RFC4684] lets the next-hop address be either an IPv4 or IPv6 address, and says the Next Hop Address field is interpreted as an IPv4 address whenever the next-hop address is 4 octets long, and as an IPv6 address whenever it's 16 octets long 🧠

There are situations, like the ones in [RFC4925] and [RFC5565], where carriers (or big enterprise networks acting as a carrier for their own internal resources) may need to connect 'islands' 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 used to advertise that reachability info, it turns into a requirement for a BGP speaker to advertise the NLRI of one address family via a next hop of a different address family. So that's IPv6 NLRI with an IPv4 next hop, and IPv4 NLRI with an IPv6 next hop 🌍

The AFI/SAFI definitions for the IPv6 address family assume the next-hop address belongs to IPv6. Specifically, as per [RFC2545] and [RFC8277], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the next-hop address is assumed to be an IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the next-hop address is assumed to be a VPN-IPv6 type.

However, [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the next-hop IPv6 address field when IPv6 NLRI needs to go out with an IPv4 next hop. [RFC4798] defines how the IPv4-mapped IPv6 address format from 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 (RD), can be used for that when the <AFI/SAFI> is <2/128>. So yes, there are existing solutions for advertising IPv6 NLRI with an IPv4 next hop ✅

Similarly, the AFI/SAFI definitions for advertising IPv4 NLRI or VPN-IPv4 NLRI assume the next-hop address belongs to the IPv4 address family type. Specifically, as per [RFC4760] and [RFC8277], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the next-hop address is assumed to be an IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the next-hop address is assumed to be a VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the <AFI/SAFI> is <1/129>, the next-hop address is assumed to be a VPN-IPv4 type. There is clearly no generally applicable method for encoding an IPv6 address inside the IPv4 address field of the next hop. So right now there is no specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 next hop 😭

This document specifies the extensions needed to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. That includes an extension of the AFI/SAFI definitions so the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI can belong to either IPv4 or IPv6, the next-hop encoding that determines which protocol the address actually belongs to, and a BGP Capability letting MP-BGP peers dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. The BGP Capability allows gradual deployment of advertising IPv4 reachability via an IPv6 next hop, without any flag day and without any risk of traffic black-holing 🎉

This document obsoletes [RFC5549].

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Basically, those keywords only count when they show up in all caps, just like that 💅

2. Changes Compared to RFC 5549 🔥

This document introduces two significant changes compared to [RFC5549]:

  • In [RFC5549], when AFI/SAFI <1/128> is used, the next-hop address is encoded as an IPv6 address with a length of 16 or 32 bytes. To accommodate all existing implementations and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document changes how the next-hop address is encoded. The next-hop address is now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes (see Sections 3 and 6.2). This change addresses Erratum ID 5253 ([Err5253]). Since all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability 💖
  • This document allows AFI/SAFI <1/129> (IPv4 multicast) to use an IPv6 underlay, using similar encoding and procedures to AFI/SAFI <1/128> (see Sections 3 and 6.3). 🌈

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

Okay so, as we said earlier, MP-BGP decides which next-hop address families you're allowed to use based on the AFI and the SAFI 🦋. The AFI/SAFI definitions for IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, <1/2>, <1/4>, <1/128>, and <1/129>) only have room for a next hop that belongs to IPv4. This document expands that list to include IPv6 as well, whenever you're advertising an IPv4 or VPN-IPv4 NLRI. It's giving flexibility 💅

Specifically, this document lets you send the MP_REACH_NLRI attribute [RFC4760] with this content:

  • AFI = 1
  • SAFI = 1, 2, or 4
  • Length of Next Hop Address = 16 or 32
  • Next Hop Address = IPv6 address of a 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 the AFI/SAFI definition

It also lets you send the MP_REACH_NLRI attribute [RFC4760] with this content:

  • AFI = 1
  • SAFI = 128 or 129
  • Length of Next Hop Address = 24 or 48
  • Next Hop Address = VPN-IPv6 address of a next hop with an 8-octet RD set to zero (potentially followed by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set to zero).
  • NLRI = NLRI as per the AFI/SAFI definition

This is on top of the existing setup, which already lets you advertise NLRI for <AFI/SAFI> of <1/1>, <1/2>, and <1/4> with an IPv4-type next hop, and NLRI for <1/128> and <1/129> with a VPN-IPv4-type next hop. Same vibe, bigger options 🌸

The BGP speaker receiving the advertisement MUST use the Length of Next Hop Address field to figure out which network-layer protocol the next-hop address belongs to. Bestie, this part is the whole trick ✨

  • When the AFI/SAFI is <1/1>, <1/2>, or <1/4> and the Length of Next Hop Address field is equal to 16 or 32, the next-hop address is of type IPv6.
  • When the AFI/SAFI is <1/128> or <1/129> and the Length of Next Hop Address field is equal to 24 or 48, the next-hop address is of type VPN-IPv6.

Note that using the Length of Next Hop Address field to decide which network-layer protocol the next-hop address belongs to (out of the protocols the AFI/SAFI definition allows) is the same method used in [RFC4684] and [RFC6074]. It's a vibe we've seen before, and it's iconic 🧚

4. Use of BGP Capability Advertisement 💜

[RFC5492] defines a mechanism that lets two BGP speakers find out whether a particular capability is supported by their BGP peer, and therefore whether it can be used with that peer. This document defines a capability that can be advertised using [RFC5492], called the "Extended Next Hop Encoding capability". This capability lets BGP speakers discover whether, for a given NLRI <AFI/SAFI>, a peer supports advertisement with a next hop whose network protocol is determined by the value of the Length of Next Hop Address field, as specified in Section 3.

A BGP speaker that wants to advertise an IPv6 next hop for IPv4 NLRI, or for VPN-IPv4 NLRI, to a BGP peer under this specification MUST use the Capability Advertisement procedures defined in [RFC5492] with the Extended Next Hop Encoding capability. This is 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 indicates the Extended Next Hop Encoding capability).
  • The Capability Length field is set to a variable value, which is the length of the Capability Value field (which follows).
  • The Capability Value field has the following 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> indicates that the NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a next-hop address belonging to the network-layer protocol of Nexthop AFI.
  • the AFI and SAFI values are defined in the "Address Family Numbers" and "Subsequent Address Family Identifier (SAFI) Parameters" registries (see [IANA-AFI] and [IANA-SAFI], respectively).

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

  • NLRI AFI = 1 (IPv4)
  • NLRI SAFI = 1, 2, 4, 128, or 129
  • Nexthop AFI = 2 (IPv6)

This document doesn't specify using the Extended Next Hop Encoding capability with any other <NLRI AFI, NLRI SAFI, Nexthop AFI> combinations. For example, the Next Hop Encoding capability specified here isn't meant for NLRI AFIs/SAFIs whose definitions already allow both IPv4 and IPv6 next hops (for instance, AFI/SAFI = <1/132> as defined in [RFC4684]). It's also not meant for the Extended Next Hop Encoding capability to be used with NLRI AFIs/SAFIs that already have a way to advertise a next hop of a different address family (for instance, AFI/SAFI = <2/1>, <2/2>, or <2/4> with an IPv4 next hop as per [RFC4798], and AFI/SAFI = <2/128> with an IPv4 next hop as per [RFC4659]). Those already have their own lanes 🛣️

It's expected that if new AFIs/SAFIs get defined in the future, their definitions will (where appropriate) include provisions for both IPv4 and IPv6 next hops from the very beginning, with the choice based on the Length of Next Hop Address field. So new AFIs/SAFIs aren't expected to use the Extended Next Hop Encoding capability. Future-proof, periodt 💅

A BGP speaker MUST only advertise the IPv4 or VPN-IPv4 NLRI with an IPv6 next hop to a BGP peer if the BGP speaker has first confirmed, through the BGP Capability Advertisement, that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. No skipping the check, no cap 🙈

The Extended Next Hop Encoding capability gives information 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]. Different job, different capability 🎀

5. Operations 🌈

By default, if a particular 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, using the encoding rules specified in the AFI/SAFI definition of the NLRI being updated. Policy is allowed to override this default behavior.

When a next-hop address needs to be passed along unchanged (for example, the way a Route Reflector (RR) does it), its encoding MUST NOT be changed. If a particular RR client can't handle that encoding (as determined by the BGP Capability Advertisement), then the NLRI in question can't be distributed to that client. For sound routing in certain scenarios, all the RR clients will need to be able to handle whatever encodings any of them may generate. Teamwork makes the dream work 👑

6. Usage Examples 🍓

6.1. IPv4 over IPv6 Core

The extensions defined in this document may be used as discussed in [RFC5565] for interconnecting IPv4 islands over an IPv6 backbone. In this application, 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 Address field = 16 (or 32)
  • Next Hop Address = IPv6 address of the next hop
  • NLRI = IPv4 routes

During BGP Capability Advertisement, the PE routers would include the following 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 Unicast over IPv6 Core

The extensions defined in this document may be used to support IPv4 VPNs over an IPv6 backbone. In this application, PE routers would 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 Address field = 24 (or 48)
  • Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero
  • NLRI = IPv4-VPN routes

During BGP Capability Advertisement, the PE routers would include the following 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>

6.3. IPv4 VPN Multicast over IPv6 Core

The extensions defined in this document may be used to support IPv4 multicast VPNs over an IPv6 backbone. In this application, PE routers would 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 = 129
  • Length of Next Hop Address field = 24 (or 48)
  • Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero
  • NLRI = IPv4-VPN routes

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

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

7. IANA Considerations 📋

This document doesn't define any new code points beyond the ones already included in [RFC5549].

[RFC5549] added "Extended Next Hop Encoding" to the "Capability Codes" registry ([IANA-CAP-CODE]), which was created by [RFC5492]. IANA has updated the registration of that entry to refer to this document. The value allocated for this Capability Code is 5. Registry glow-up complete 🦋

8. Security Considerations ✨

Okay bestie, so this part is kind of serious, but I still want you to read it 🫶. This document doesn't add any new security issues beyond the ones BGP-4 and the Multiprotocol Extensions for BGP-4 already have. The same security mechanisms apply, so no new toolkit needed 💅.

BUT 😭 as [RFC4272] talks about, BGP is vulnerable to traffic diversion attacks. Being able to advertise an IPv6 next hop gives an attacker a new way to divert traffic off its normal path 🙈. This one is kind of scary because the traffic could get forwarded to a faraway target across some network in between (like an IPv6 core 🦋). That means the attack could work more easily, since less infrastructure would need to be compromised. The possible fallout includes "hijacking" of traffic or denial of service 💀.

Also, this isn't expected to be the usual case, but the IPv6 address used as the BGP next-hop address could be an IPv4-mapped IPv6 address (as defined in [RFC4291]) 👑. So any security checks the network operator sets up on next-hop addresses (or any other security mechanisms they deploy) need to keep this case in mind 🔥.

9. References 🌸

9.1. Normative References 💜

9.2. Informative References 🧚

Acknowledgments 🫶

The authors would like to thank Francois Le Faucheur and Eric Rosen for their work on [RFC5549] 💖.

The authors would like to thank Yakov Rekhter, Pranav Mehta, and John Scudder for their contributions to the approach defined in [RFC5549] ✨.

Authors' Addresses 🎀

  • Stephane Litkowski, Cisco, Email: slitkows@cisco.com
  • Swadesh Agrawal, Cisco, Email: swaagraw@cisco.com
  • Krishna Muddenahally Ananthamurthy, Cisco, Email: kriswamy@cisco.com
  • Keyur Patel, Arrcus, Email: keyur@arrcus.com
📦 where this page comes from