Worth Reading: BGP Unnumbered in 2025
Gabriel sent me a pointer to a blog post by Rudolph Bott describing the details of BGP Unnumbered implementations on Nokia, Juniper, and Bird.
Even more interestingly, Rudolph points out the elephant I completely missed: RFC 8950 refers to RFC 2545, which requires a GUA IPv6 next hop in BGP updates (well, it uses the SHALL wording, which usually means “troubles ahead”). What do you do if you’re running EBGP on an interface with no global IPv6 addresses? As expected, vendors do different things, resulting in another fun interoperability exercise.
Finally, there’s RFC 7404 that advocates LLA-only infrastructure links, so we might find the answer there. Nope; it doesn’t even acknowledge the problem in the Caveats section.
For even more information, read the Unnumbered IPv4 Interfaces and BGP in Data Center Fabrics blog posts.
There is an active individual Internet-Draft hotly discussed in the IETF that attempts to select one of the possible link-local next hop variants (known in Bird as
link local next hop format single) and adds a BGP capability to inform the peer that this is supported:I tried this in Netlab, a static BGP session to fe80::1 does not come up in FRR (with advertisements still enabled) - there is an error about setting the next hop.
Interface neighbors to both leaves (each having fe80::1/64 statically assigned) do come up
Some templates needed tweaking to statically assign a link-local ipv6 address - missing test case...