The idea
Carry IPv4 routes over IPv6 BGP sessions with IPv6 next hops, so core routers need no IPv4 addresses at all. Built on VyOS: the missing router ID, what breaks without the extended next hop capability, native IPv4 on the wire, and why traceroute shows 192.0.0.8.
By the end you will be able to:
- Explain how RFC 8950 lets IPv6 BGP sessions carry IPv4 routes with IPv6 next hops
- Set a BGP router ID on a router with no IPv4 addresses
- Recognise the symptoms of IPv4 routes on IPv6 sessions without the extended next hop capability
- Enable extended next hop on VyOS and verify it in BGP, the routing table and the kernel
- Show that the data plane stays native IPv4, and interpret 192.0.0.8 in a traceroute
Prerequisites: IPv6 on VyOS: setup and routing, BGP Fundamentals
Many networks would like to run their backbone on IPv6 only: one protocol to address, one IGP, one set of filters, no IPv4 addresses to find for every link. But customers, peers and the rest of the internet still need IPv4. RFC 8950 (which replaced RFC 5549) makes that possible without tunnels or translation:
- BGP carries IPv4 routes over IPv6 sessions. That part is ordinary Multiprotocol BGP: any BGP session can carry any address family.
- Each IPv4 route gets an IPv6 next hop. That's the new part, negotiated with the extended next hop capability.
- Routers resolve that IPv6 next hop to a MAC address with IPv6 Neighbor Discovery, and then forward ordinary IPv4 packets to it. The data plane doesn't change at all; only the control plane does.
The result is a core where routers have no IPv4 addresses, yet still forward IPv4 between customers that have nothing but IPv4. The same trick lets an IX run an IPv6-only route server that still serves IPv4, or a transit network exchange IPv4 routes with customers over IPv6 sessions.
This lesson was inspired by Anurag Bhatia's write-up, RFC 8950: announce IPv4 with an IPv6 next hop, which demonstrates it with FRR in Containerlab. Here the same idea runs on VyOS (rolling 2026.10.16) as the provider routers, with FRR 10.2.1 containers as the customers. It turned up two things worth knowing that a lab with management IPv4 addresses hides: what happens to the BGP router ID, and what traceroute shows for a hop with no IPv4 address.
- IPv4 routes, IPv6 sessions. Every session between C1, R1 and R2 is over IPv6, with the IPv4 unicast address family enabled. C2 speaks ordinary IPv4 BGP to R2.
- Without extended next hop. R2 can only give the route an IPv4 next hop, 192.0.2.1, which R1 can't reach. The route is inaccessible and goes no further.
- With extended next hop (RFC 8950). The IPv4 route carries R2's IPv6 address as its next hop. R1 installs it via R2's link-local address and passes it to C1.
- Plain IPv4 on the wire. C1's IPv4 packets to C2 cross the IPv6-only core unchanged. Each router finds the next hop's MAC address with IPv6 Neighbor Discovery.
- Traceroute through R1. R1 has no IPv4 address to send "time exceeded" from, so it uses 192.0.0.8, the IPv4 dummy address.
Check your understanding
With RFC 8950, what changes on the wire between two IPv6-only core routers forwarding IPv4 traffic?
- The IPv4 packets are tunnelled inside IPv6
- Nothing in the packets: they're ordinary IPv4, sent to a MAC address found with IPv6 Neighbor Discovery
- The packets are translated to IPv6 and back
- They use MPLS labels