Operators managing interconnections at Internet Exchange Points face a persistent constraint: dual-stack address assignment consumes scarce IPv4 resources on transfer networks. RFC8950 offers a practical solution by allowing Border Gateway Protocol to carry IPv4 routes across IPv6 next-hops, a capability now supported by most current network operating systems.

The interconnection puzzle

Adding a new peering link requires solving multiple problems simultaneously: securing a router port, establishing physical connectivity, and provisioning IP address space through an IP address management system. Organizations operating autonomous systems and BGP speakers must configure these resources across multiple systems, often with some degree of automation depending on network scale.

IPv4 scarcity compounds the challenge. Newer network operators frequently lack abundant IPv4 allocations, and IXPs can exhaust available address space on their peering LANs, forcing members to renumber. This constraint naturally raises the question of whether IPv4 is truly necessary for interconnection.

IPv6 next-hops for IPv4 routes

Conventional wisdom holds that IPv4 transport requires IPv4 next-hops, since routers need an IPv4 address to forward IPv4 traffic. However, RFC8950 and its predecessor RFC5549 changed this equation by enabling BGP to advertise IPv4 routes with IPv6 next-hops. The Euro-IX RFC8950 IXP working group has documented compatibility across multiple network operating systems.

The mechanism relies on existing router capabilities. Packet processors forward traffic based on a target interface and MAC address; the CPU resolves next-hop IP addresses to MAC addresses using either Address Resolution Protocol for IPv4 or Neighbour Discovery for IPv6. BGP's variable-length next-hop field, defined in RFC4760, traditionally required the next-hop address family to match the advertised routes. RFC8950 removes this restriction by identifying the next-hop's address family through field length alone.

Both BGP peers must support the "Extended Next Hop" capability, which is negotiated during session establishment. Once a router receives IPv4 routes with IPv6 next-hops, it resolves the corresponding MAC address via Neighbour Discovery and programs the forwarding lookup table. Packet forwarding then proceeds through normal mechanisms.

Deployment at exchange points

Bilateral BGP sessions between IXP members can adopt IPv6 next-hops for IPv4 routes at each operator's discretion. Most IXPs also operate route servers to efficiently exchange routes among many members; these servers should also support extended next-hops. IXP operators can request this capability from their exchange point.

Route server configuration generation tools vary in their support. Arouteserver includes native RFC8950 support, while IXP Manager currently requires customization of BIRD configuration templates. BCIX has published its modified route server templates for community use.

Bridging legacy and new deployments

A chicken-and-egg problem emerges when new members connect using only IPv6 and RFC8950: they cannot receive IPv4 routes from members still using IPv4 next-hops. Proposed solutions involving next-hop translation or MAC addresses in BGP remain far from deployable.

A practical bridge exists today: a Layer-3-aware router reachable via both IPv4 and IPv6, acting as a translator. This router connects to the route server and re-advertises received routes with its own address as the next-hop, using the next-hop self technique. This normally prepends the translator's Autonomous System Number to the BGP path, creating a route-leak scenario that requires the route server to sanitize the path by removing the leading AS. Additional parameter tuning may be necessary to prevent unnecessary traffic through the translator.

This approach enables new members without IPv4 peering LAN addresses to reach legacy members and remain reachable by them. At BCIX, two networks have connected using this model: Tobias Fiebig's V4LESS and RIPE NCC's Authoritative DNS Service.

The operational challenge

While routers and peers may readily support IPv4 with IPv6 next-hops, support systems often require modification. Automated provisioning workflows need awareness of RFC8950 specifics. Web forms may currently mandate IPv4 address fields. Configuration templates may need an "extended-next-hop" keyword. Looking glass tools may require updates to handle BGP sessions with multiple address families enabled. IXP operators should audit their tooling to enable this capability.

Looking forward

Although many in the networking community envision an IPv6-only Internet, IPv4 will persist for the foreseeable future. For interconnection purposes, however, IPv4 is no longer mandatory. RFC8950 enables IPv4 packet transport across IPv6 networks, advancing the path toward an IPv6-only Internet core.