RFC 8950 in Practice: IPv4 Prefixes with an IPv6 Next Hop

The Problem RFC 8950 Solves

Multiprotocol BGP (RFC 4760) carries routes for various address families, identified by the AFI/SAFI pair: "AFI 1 = IPv4", "AFI 2 = IPv6", ..., "SAFI 1 = Unicast", "SAFI 2 = Multicast", and so on. For IPv4 unicast (AFI 1, SAFI 1), the original definitions specified that the next-hop field in the MP_REACH_NLRI attribute must contain an IPv4 address. Anyone wishing to exchange IPv4 routes therefore needed IPv4 addresses on the connecting link, even if the BGP session itself had long been running over IPv6.

This is inconvenient architecturally in three respects. First, point-to-point links and peering LANs consume IPv4 addresses, which are scarce and expensive. Second, every link has to be addressed, documented and filtered twice. Third, ARP as a broadcast mechanism persists on large Layer 2 domains, which is a well-known source of disruption particularly in peering environments. What's more, the gateway is addressed via a Layer 2 address in any case – without it, the data would never arrive.

RFC 8950 removes this coupling: an IPv4 prefix may be advertised with an IPv6 next hop. The control plane becomes IPv6-only while the data plane remains unchanged. An IPv4 packet is still looked up in the FIB via longest-prefix match as before; the router then resolves an IPv6 address into a MAC address via Neighbor Discovery instead of resolving an IPv4 address via ARP. For the Ethernet frame, it makes no difference by which route the destination MAC was determined.

What the Standard Defines Technically

Encoding via Field Length

The receiver identifies the address family of the next hop solely by the length of the field. For the AFI/SAFI pairs 1/1 (unicast), 1/2 (multicast) and 1/4 (labelled unicast), 4 octets denote an IPv4 next hop, 16 octets a global IPv6 address, and 32 octets a global address followed by a link-local address. For VPN-IPv4 (1/128 and 1/129), the next hop is encoded as a VPN-IPv6 address preceded by an 8-octet route distinguisher, i.e. 24 or 48 octets. This is precisely where the difference from RFC 5549 lay, which specified 16 or 32 octets for VPN-IPv4. RFC 8950 aligned the specification with what implementations were already doing in practice.

Capability Negotiation

To ensure that no peer receives routes it cannot process, the standard defines the BGP capability with code 5, the Extended Next Hop Encoding Capability. It is exchanged in the OPEN message and contains a triple of NLRI AFI, NLRI SAFI and next-hop AFI for each entry. Only if both sides signal the same triple may an IPv6 next hop be sent for that address family. If the capability is absent, the session continues in classic mode, provided an IPv4 next hop is still available. In short: every router along the path carrying the traffic must also be capable of implementing RFC 8950.

This negotiation is precisely why RFC 8950 can be introduced into existing environments incrementally. However, it is also where most interoperability issues become apparent.

Status in Autumn 2026

Formally, RFC 8950 has remained an unchanged Proposed Standard (considered stable, though it may still have shortcomings) on the IETF Standards Track since November 2020, and it obsoletes RFC 5549. No successor revision is in progress. The movement is not happening within the standard itself, but in implementations and operations.

Data Centre Fabrics

The oldest production use case is BGP Unnumbered in leaf-spine fabrics. FRRouting and systems built on it, such as Cumulus Linux and NVIDIA Cumulus, have used link-local addresses for years as session endpoints and next hops for IPv4 prefixes. No fabric link there still carries an IPv4 address. One well-known detail: older FRR versions entered a synthetic next hop of 169.254.0.1 with a static neighbour entry into the Linux kernel, because the kernel previously did not accept an IPv6 next hop for IPv4 routes. With nexthop groups this is no longer necessary, though the artefacts remain visible in many installations. Have you ever noticed such a gateway IP on your own VPS at a cloud provider? :-)

Internet Exchanges and Peering

The real momentum came from the peering world. RIPE NCC reduced the standard allocation for IXP peering LANs from a /24 to a /26 in 2023, as the reserved /15 pool was visibly running out. An informal working group at Euro-IX prepared the rollout at exchanges from 2023 to 2026: containerlab environments, vendor-specific configuration examples, an interoperability matrix, and adaptations to ARouteServer, BIRD, Alice-LG and IXP Manager. The group concluded its regular meetings in March 2026, having achieved its main objectives.

As a result, BCIX in Berlin as well as NIX.CZ and NIX.SK operate route servers running RFC 8950 in production. TREX Turku in Finland has, since 2025, been the first exchange whose peering LAN has been operated entirely without IPv4 from the outset. On the network operator side, Meta already demonstrated in 2024 how IPv4 infrastructure addresses were removed from its edge network. Individual content networks such as DeepL state in PeeringDB that new BGP sessions are only established via "IPv6 with Extended Next Hop" (RFC 8950) for both address families. A flag "IPv4 with IPv6 next hop" has been proposed for PeeringDB so that support can be queried before session establishment.

MPLS and VPN Environments

The third use case is an IPv6-only core over which VPN-IPv4 routes (SAFI 128) are transported, often referred to as 4PE or 4VPE. Here the modified VPN encoding with route distinguisher applies, and this is precisely where differences between implementations are greatest.

Vendor Status, as Far as Verifiable

Support is now widespread, but not uniform. Anyone planning a deployment should answer three questions for each platform: Which AFI/SAFI combinations are supported? From which software version onward is the encoding standard-compliant? Is the IPv6 next hop held only in the RIB, or is it also programmed into the hardware FIB? The following details are based on vendor documentation and documented operational experience; version levels should be cross-checked in the relevant vendor's feature navigator before any decision is made.

• FRRouting: Has been the foundation for BGP Unnumbered in leaf-spine fabrics for years. For interface-based peerings without an IPv4 address, the Extended Next Hop capability is sent automatically. Included as a test partner in the Euro-IX working group's containerlab reference environments.
• Juniper Junos: RFC 5549 on MX since 17.3R1, with other platforms following later. By default, Junos uses a pre-standard encoding from the draft phase. Without the rfc8950-compliant keyword, exchange between Juniper routers works, but is highly unlikely to work against third-party vendors. Conformance issues were fixed in PR1649332 and PR1716946, with the corrections available from 22.4R2 and 23.2R1 respectively.
• Arista EOS: Extended Next Hop Encoding for IPv4 unicast has been available for some time; the extension to labelled unicast (1/4) and VPN-IPv4 (1/128) over IPv6 sessions arrived with EOS 4.34.2F.
• Nokia SR OS: Officially documented for IPv4 unicast over IPv6-only transport sessions. The function is enabled per session using advertise-ipv6-next-hops ipv4. The local IPv6 peering address then serves as the next hop, provided the peer has advertised the capability for the ⟨1, 1, 2⟩ triple. In use in the Euro-IX lab environment since 2024.
• Cisco NX-OS: The Nexus 9000 configuration guide references RFC 5549 for IPv4 prefixes with an IPv6 next hop, without separately identifying the RFC 8950 changes for VPN-IPv4.
• Cisco IOS XE: Documented from Release 17.8 onward for VPNv4 prefixes with an IPv6 next hop per RFC 8950: the capability is sent for the VPNv4 address family. No reliable information is available for IPv4 unicast (1/1) or for IOS XR. A query to the vendor would be needed here for the specific version.
• MikroTik RouterOS: According to the Euro-IX working group, the kernel has long been able to handle IPv6 next hops for IPv4 routes, but the BGP implementation only caught up with RouterOS 7.20.
• Route server software: BIRD with multi-channel configuration and ARouteServer support the standard; Alice-LG can display routes with an IPv6 next hop in the looking glass, and IXP Manager provides configuration templates. For ExaBGP, the feature was for a time only inadequately documented.

Version details date quickly. The interoperability matrix in the euro-ix/rfc8950-ixp repository on GitHub, which documents test results across multiple vendors, serves as a continuously maintained reference.

Pitfalls in Implementation

Traceroute, ICMP and Loopbacks

A router without an IPv4 address on the transit interface must nevertheless generate ICMP error messages such as Time Exceeded or Fragmentation Needed with an IPv4 source address. To achieve this, every router needs at least one IPv4 address on a loopback, and the platform must consistently source ICMP replies from there. If this is not configured correctly, Path MTU Discovery breaks, and IPv4 traceroutes show either only loopbacks or nothing at all. In operational terms, this means troubleshooting loses a familiar tool, and monitoring systems that query interface addresses need to be adapted.

iBGP and next-hop-self

When an IPv4 route learned at an exchange with an IPv6 next hop is passed into one's own network via iBGP, the border router must set the next hop to itself, and in a form that internal routers can resolve. Some implementations automatically revert to an IPv4 next hop in this case, while others pass through the IPv6 address, which is then unknown to the IGP. This behaviour is platform-dependent and belongs on the test list.

Brownfield: Peers Without Support

At an exchange with hundreds of participants, there will be routers without RFC 8950 support for years to come. A route server cannot deliver routes with an IPv6 next hop to such peers. The current internet draft draft-marenamat-grow-route-server-nh-translation from CZ.NIC and DE-CIX (version -01, February 2026) proposes that the route server use synthetic IPv4 next hops from a translation table for each legacy peer, with the exchange answering ARP requests for these by proxy. This is not yet a standard, but it shows that coexistence is being actively addressed. Bilateral sessions on the same LAN are unaffected by this and must be resolved by the participants themselves.

Security and filtering

Anyone using link-local addresses as the next hop shifts neighbour resolution entirely onto Neighbor Discovery. ND is multicast rather than broadcast, making it quieter than ARP, but not inherently more secure. RA-Guard, ND-Inspection and rate limits belong in the same due-diligence tier as Dynamic ARP Inspection did previously. Firewalls and ACLs between routers must permit ICMPv6 for ND and BGP peering over IPv6, while continuing to filter IPv4 user traffic at the same time. Rule sets that treat IPv4 and IPv6 as separate worlds no longer fit here.

Relevance for enterprise and production networks

Outside data centres and exchanges, RFC 8950 is still rarely encountered, even though the benefits are similar there. Corporate WANs with dozens of transit networks to sites, partners and cloud connections consume IPv4 address space, which often comes from private ranges with collisions occurring during mergers. An IPv6-only control plane decouples the transit networks from this problem and significantly reduces the number of address objects that need to be maintained.

In OT environments, the benefit lies elsewhere. The production cells themselves will remain IPv4 for the foreseeable future, because controllers, HMIs and protocols such as Profinet or EtherNet/IP depend on it. However, the transitions between zones under IEC 62443 – that is, zone boundaries, conduits and the connection to the industrial DMZ – are pure infrastructure links that nobody needs to address except the routers themselves. This is precisely where unnumbered BGP over IPv6 link-local can be used to build a segmentation concept that requires no IPv4 transit networks, is cleanly monitored via BFD, and generates no ARP broadcasts between zones. The prerequisite would then be that the industrial routers and firewalls in use support the capability. Many OT vendors currently do not, and this should be queried before any tender is issued.

Recommendation for planning

1. Create an inventory: which routers, firewalls and route servers are involved, with which software version, for which AFI/SAFI combinations?
2. Test in the lab: capture the capability negotiation, check the next hop in the RIB and FIB, verify traceroute and PMTUD using an IPv4 loopback, and test iBGP propagation.
3. Configure Junos peers explicitly with rfc8950-compliant and observe the minimum versions required.
4. Prepare monitoring, looking glass and documentation for IPv6 next hops, as many tools still expect IPv4 on every interface.
5. Introduce gradually: make new links and new peerings IPv6-only, and leave existing ones dual-stack until the peer has caught up.

RFC 8950 is no longer an experiment. The standard is stable, the major routing platforms support it, and it is running in production at several European exchanges. What remains open is not the fundamentals but the operational details: ICMP sourcing, iBGP behaviour, tooling support and coexistence with legacy devices. Anyone who has worked through these points in the lab can remove IPv4 addresses from infrastructure links without anything changing for IPv4 user traffic. It should not only be carefully considered where IPv6 can be deployed and where RFC 8950 makes sense. Many vendors of routers, L3 switches, firewalls, load balancers and other appliances promise compatibility but do not honour it down to the last detail. The data plane already goes further than the stated requirements, but in HA scenarios, with out-of-band management, and for somewhat more demanding requirements, vendor-side problems still persist. This is where a POC must establish whether everything works as intended. It is also important whether the service contract allows old bugs or feature gaps to be resolved quickly once they surface.