IPv6 Link-Local Next Hop Capability for BGP

When it comes to IPv6, there are several categories of IPv6 addresses, each with its own use case. For example, IPv6 link-Local addresses are intended for addressing on a single link for purposes such as automatic address configuration or neighbor discovery.

For this reason, routers do not forward packets with a source or destination link-local address to other links. Despite this, some BGP installations can benefit from using local IPv6 addresses on point-to-point links. Let’s look at an interesting IETF proposal, which aims to address and standardize the Border Gateway Protocol on point-to-point links using IPv6 link-local addressing.

BGP in Data Center Fabrics

BGP is designed to provide reachability between different autonomous systems (AS) or in the same AS. BGP assumes that the next hop towards any reachable destination may not reside on the advertising speaker but rather may either be learned through a router connected to the same subnet as a speaker or through a router only reachable by traversing multiple hops through the network.

However, BGP speakers are often deployed in data center fabrics where they are directly connected via a point-to-point connection. In such cases, multi-hop reachability is not required because the next hops are reachable via point-to-point links. Given the limited autoconfiguration capabilities of IPv4, IPv6 may become the preferred choice in such scenarios.

As we all know, IPv6 employs a Stateless Address Autoconfiguration (SLAAC) mechanism, which allows hosts to generate a global IPv6 unicast address from the received global IPv6 prefix on the link and the prefix length. However, a pre-configured router must be on the segment, which will send a Router Advertisement with the prefix and its length to a node. Therefore, the use of global IPv6 addresses for next-hops may not always be desirable and, conversely, may be detrimental to Zero Touch Provisioning.

BGP Deployments on Point-to-Point Links with IPv6 Link-local Addresses

BGP deployment models in which BGP runs on a point-to-point link and a link-local IPv6 address is used for BGP next-hop can lead to simplified orchestration and configuration management. Unlike global IPv6 unicast addresses, link-local addresses are generated for interfaces as soon as IPv6 is enabled on them. Each interface is, therefore, uniquely identified by its link-local address. Suppose BGP uses the interface name for peer configuration, and the link-local IPv6 address of the BGP peer is learned through the Neighbor Discovery Protocol. In that case, configuration is faster and less error-prone. This is because the IPv6 addresses do not need to be configured for BGP neighbors; BGP‘s autodiscovery capabilities take care of that.

Link-Local Next-Hop Capability

The draft of interest implements the new Link-Local Next Hop capability, which the BGP speaker inserts into an OPEN BGP message at the beginning of a BGP session. A BGP speaker that is willing to send and receive only link-local addresses as next hops with a peer should advertise the capability to the peer. The peers can include either link-local and global next hops or link-local next hops only.

BGP Next Hop Attribute to Support Link-Local on Point-to-Point

RFC2545 defines that the value of the Length of Next Hop Network Address field on the MP_REACH_NLRI attribute shall be set to 16 when only a global address is present or 32 if a link-local address is also included in the Next Hop field.

The first address should be the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop (Figure 1).

Figure 1 – BGP UPDATE Message with the Global and Link-local IPv6 Addresses of Next-Hop

RFC2545 does not, however, explain situations when there is only a link-local IPv6 address in the Next Hop field of the MP_REACH_NLRI. There are implementations where link-local addresses for the next-hop are implemented as one of these three options:

• :: ll IPv6 global unicast address is null
• ll Only one link-local address
• ll ll Two link-local addresses

Cisco BGP Implementation depicted in Figure 2 implements IPv6 link-local address FE80::1 as two link-local next-hop addresses (ll ll).

Figure 2 – BGP UPDATE Message with Second Link-local Address for Next-Hops

Changes to the BGP Next Hop Attribute to Support Link-Local on Point-to-Point

The draft clears out doubts about the construction of the Next Hop field when there is only a link-local address or a global reachable address along with a link-local address for next-hop:

If an implementation intends to send a single link-local forwarding address in the Next Hop field of the MP_REACH_NLRI, it must set the length of the Next Hop field to 16 and include only the IPv6 link-local address in the Next Hop field.

If an implementation intends to send both a link-local and a global IPv6 forwarding address in the Next Hop field of the MP_REACH_NLRI, it must set the length of the Next Hop field to 32 and include both the IPv6 link-local and the global IPv6 forwarding addresses in the Next Hop field.

Suppose the BGP speaker receives MP_REACH_NLRI with a Next Hop length of 16. In that case, implementations should form the forwarding information using the IPv6 next hop contained in the Next Hop field, regardless of whether it is a link-local or a globally reachable IPv6 address.

When the BGP speaker receives MP_REACH_NLRI with two link-local IPv6 addresses (Figure 2) and the Next Hop Field set to 32, the implementation may ignore the second link-local address for backward compatibility. Similarly, if there is 0::0/0 included with an IPv6 link-local address, the implementation may ignore 0::0/0.

However, a single link-local next-hop address must always be reset as next hop self when passed to another link.

---

Conclusion

The new Link-Local Next-Hop capability introduced in the draft does not affect the support of global IPv6 only (16 bytes next hop) and global IPv6 combined with link-local IPv6 (32 bytes next hop), which should continue to be supported as before.

The new draft only removes the complication of what IPv6 address a router should include in its updates towards an IPv4 or IPv6 neighbor, preserving the backward compatibility with existing implementations. Although the document exists only as a proposal, for now, it seems to be a step in the right direction, as it removes doubt about the construction of the Next Hop field when a link-local address is used alone or in combination with a globally reachable IPv6 address.