Saving IPv4 Addresses on Interconnection with RFC8950

Interconnection is: lots of strings coming together

Many people in the RIPE community have experience with operating autonomous systems (AS) and routers speaking the border gateway protocol (BGP).

Adding another link turns into a puzzle for the operator. Let’s find a suitable port on the router, get the physical connection up and running and, yes, we need some IP addresses for the transfer network. Of course we need IPv4 and IPv6 connectivity, so we’re consulting our IP address management (IPAM) for suitable address space. And eventually all this needs to be configured in several systems. Depending on the number of links in our networks, we may have added automation of some degree to support this endeavour.

Managing IP resources can be a challenge in itself. Newer players in the Internet game might not be gifted with a plethora of IPv4 addresses, and Internet Exchange Points (IXPs) can grow beyond the number of available IPv4 addresses in their peering LAN, forcing all their members to renumber.

So the question that might quite naturally emerge is:

Can we do without IPv4 for interconnection?

Most people will answer: no, we still need IPv4. To transport IPv4, routers need an IPv4 next-hop.

This answer was correct - and may still be correct for some BGP routers.

However, most current network operating systems (NOS) have implemented support for RFC8950 (or its predecessor RFC5549). This allows BGP to exchange IPv4 routes associated with an IPv6 next-hop.

Together with the Euro-IX RFC8950 IXP working group we have assembled compatibility information for several common NOS.

How does it work?

In our Ethernet-dominated world, the packet processors in routers need a target interface and a MAC address to forward packets. It’s the CPU’s job to resolve the next-hop IP address into a MAC address and program the lookup tables. In general the software already knows how to resolve IPv4 to MAC using ARP or IPv6 to MAC using Neighbour Discovery (ND).

It is the job of routing protocols to provide routing information with IPv6 next-hop addresses. While BGP (defined in RFC4760) has a variable length field for next-hops, it mandates that the next-hop is of the same address family as the advertised routes. To transport IPv4 via IPv6 next-hops, this restriction needs to be lifted. Instead, the next-hop's address family is identified by the field's length. Obviously changes of expected behaviour require both parties to agree. Therefore the "Extended Next Hop" capability is introduced and needs to be negotiated during BGP session start.

When the router receives IPv4 routes with an IPv6 next-hop, it can use ND to resolve the corresponding MAC address and program the lookup table. From there on, IP packet forwarding proceeds as it always has.

Applying this to an IXP

We see that employing IPv6 next-hop for IPv4 is not hard. While Tobias Fiebig once called it "Fun things", the use case is serious and the implementation can be at your own pace. Whenever neighbouring routers support extended next-hops, both can be configured to start exchanging IPv4 routes on their IPv6 BGP session with extended next-hop enabled. Once this is working fine, you can remove the IPv4 BGP session and eventually the IPv4 addresses on the link between them.

Since we're talking about interconnection, we should also talk about Internet Exchange Points (IXPs). In the first place, IXPs just provide Layer-2 transport between routers. So for bilateral BGP sessions it is up to the members to employ IPv6 next-hops. Most IXPs also provide route servers to exchange routes with many members efficiently. So IXP route servers should also support extended next-hops. Feel free to ask your fellow IXP operator to implement this.

Many IXPs use Arouteserver or IXP Manager to generate their route servers' configurations. While the former has native support for RFC8950, the latter currently needs customisation of the BIRD configuration templates. BCIX (Berlin Commercial Internet Exchange) has published its customised version of the route server templates.

Bridging the gap

Exchanging IPv4 routes with an IPv6 next-hop via route servers is great, but it presents a chicken and egg problem similar to the introduction of IPv6. Only other IXP members doing the same will receive your IPv4 routes. If a new member connects using only IPv6 and RFC8950, it would not be able to reach networks supporting only IPv4 with IPv4 next-hops.

Adventurous people have suggested that route servers could do some kind of translation of the next-hop or even include MAC next-hops in BGP. Yet this is a long from being deployable.

If you want this to work today, your "translator" needs to be Layer-3 aware; i.e., be a router. A router that is reachable via IPv4 and IPv6 feeding each side with the next-hop it understands.

The easiest approach is to use an ordinary router which connects to the route server and forwards the routes it receives on either BGP session with its own address as next-hop (next-hop self). Doing so will normally prepend the Translator's ASN to the BGP path. Having the ASN on the path poses several issues - this would be a classic route-leak. As this is a controlled environment, the route server will need to sanitise the BGP path by removing the leading AS. Some additional tweaks to parameters influencing the route preference may be necessary to avoid preferring routes through the translator where this is not necessary.

By employing this translator, new IXP members without an IPv4 address can still reach other legacy members and be reachable by them.

At the time of writing, two networks have connected to BCIX using this technology and without having been assigned an IPv4 Peering LAN address: Tobias Fiebig's V4LESS and RIPE NCC's Authoritative DNS Service.

What’s the actual challenge?

While your routers and your peers may easily support IPv4 with IPv6 next-hop, your support systems may need some work.

Anything you have automated will need to know about some peculiarities. Your webform may currently require IPv4 address fields to be filled. Your configuration template may need an additional "extended-next-hop" keyword. Your looking glass may need to cope with a BGP session with two address families enabled.

So go ahead and check your tooling to make this work.

Conclusion

While many of us are dreaming of an IPv6-only Internet, the reality is that IPv4 will be with us for the foreseeable future. Yet for interconnection it is no longer required. RFC8950 makes it possible to transfer IPv4 packets over an IPv6 network, and paves the way to an IPv6-only Internet core.

So, inspired by Gert Doering, I am left asking: have you enabled RFC8950 on something today...?