EVPN over IPv6: how to prepare the underlay of the future in your ISP network
Most ISPs running EVPN/VXLAN in production do so over an IPv4 underlay. It is the proven, well-documented configuration, supported without surprises by all major vendors. But as the industry moves toward IPv6-native networks, a practical question more engineering teams are facing is: when and how should we migrate the EVPN underlay to IPv6?
This article does not argue to do it immediately regardless. It argues for understanding current support, identifying where real interoperability risks lie, and building a decision framework for your network on solid technical information.
What the underlay does in EVPN/VXLAN
EVPN (Ethernet VPN) runs over BGP and uses VXLAN to encapsulate Layer 2 traffic over a Layer 3 network. In this architecture there are two clear planes:
- Control plane (overlay): BGP iBGP or eBGP among VTEPs (VXLAN Tunnel Endpoints) to distribute MAC/IP reachability and VNI membership.
- Data plane (underlay): the IP network that carries VXLAN-encapsulated packets between VTEPs. It is essentially IP with UDP 4789 on top.
The underlay is transparent to the overlay: BGP EVPN does not care whether VTEPs talk over IPv4 or IPv6. What matters is that next-hops advertised in EVPN routes are reachable, and UDP transport works correctly between VTEPs.
On an IPv4 underlay, VTEPs have IPv4 loopback IPs (typically /32) as VXLAN tunnel source/destination. On an IPv6 underlay, those loopbacks would be IPv6 addresses, and VXLAN tunnels would run over IPv6.
Standard VXLAN (RFC 7348) was originally defined to run over IPv4. Extending to IPv6 as underlay transport is technically straightforward — UDP over IPv6 works the same — but control-plane implementation (how VTEPs signal their IPv6 loopbacks via BGP EVPN) requires explicit support on each platform.
Why consider IPv6 underlay now
The driver is not IPv6 for its own sake. It is operational:
Simpler addressing plan. An ISP that already moved subscriber access to IPv6 and runs dual stack in the core has a chance to simplify: if the EVPN underlay also runs on IPv6, management and monitoring can unify. A single protocol family for the whole transport plane reduces configuration surface and the number of routing protocols running in parallel.
No NAT in the data-center transport plane. In architectures where the data-center fabric connects directly to the ISP network, keeping IPv4 on the EVPN underlay means keeping private IPv4 space (RFC 1918) for VTEP loopbacks. As IPv4 space gets more expensive, removing that dependency has value.
Alignment with industry direction. Newer network platforms are investing in IPv6 underlay support for EVPN. Operators who do not assess this capability today will make architecture decisions without having analyzed the implications.
Readiness for IoT and 5G environments. In access networks for massive device deployments (IoT, sensors, 5G small cells), edge VTEPs may in the future be platforms that only support IPv6. A native IPv6 EVPN underlay is the foundation for that architecture.
Current state by platform
This is the most important part: IPv6 underlay support in EVPN varies significantly between vendors, and interoperability among them still has friction.
Huawei VRP
Huawei documents IPv6 underlay support in EVPN for data-center switch platforms (CE series) and core routers (NE series) in recent VRP releases. Configuration follows the same model as IPv6: IPv6 loopbacks, IPv6 IGP (OSPFv3 or IS-IS with IPv6 TLVs), and BGP EVPN with IPv6 next-hops.
An important detail for Huawei teams: verify the exact VRP version before planning deployment. Support appears in release notes as “EVPN IPv6 Underlay,” and availability differs across CE6800, CE8800, and NE platforms.
Cisco IOS-XE / NX-OS
On NX-OS, Cisco supports IPv6 underlay in EVPN for the Nexus 9000 family from 9.3.x onward, with some features maturing in 10.x. Support on other NX-OS platforms (Nexus 7000, campus platforms) is more limited.
On IOS-XE (Cat9k, campus platforms with EVPN), IPv6 underlay support is newer and less mature than on NX-OS. We recommend checking release notes for your specific version.
Juniper Junos
Junos supports IPv6 underlay in EVPN on QFX and MX platforms. The implementation is technically complete: BGP EVPN can advertise IPv6 next-hops, and VXLAN encapsulation over IPv6 works. Junos documentation details EVPN configuration with “extended next-hop encoding” to advertise IPv6 next-hops in EVPN routes.
Junos has an advantage here: its BGP stack is consistent across platforms, and IPv6 support in the EVPN control plane is stable.
FRRouting (Linux / white-box environments)
FRRouting, the open-source routing stack used on white-box switches and Linux deployments, added experimental support for IPv6 VTEPs in EVPN in recent releases (10.x). Support exists and works in controlled environments, but production stability at large scale is still being validated by the community.
One area where FRRouting has seen issues recently: interoperability with commercial platforms when the underlay is IPv6. Specifically, cases have been documented where BGP EVPN capability negotiation between FRRouting and commercial gear fails for IPv6 next-hops, even when both ends claim support.
The real problem: interoperability between vendors
This is the most critical aspect for ISP networks, which are typically multi-vendor: declared support for a feature from one vendor does not guarantee it will work with another vendor that also claims support.
EVPN IPv6 underlay involves several control-plane mechanisms that must negotiate correctly between BGP peers:
-
Extended Next Hop Encoding (RFC 8950): allows advertising IPv6 next-hops in IPv4-family BGP updates (needed in some topologies). Both peers must negotiate this capability correctly.
-
VTEP source encoding in EVPN Type-3 (IMET) routes: the VTEP address advertised in inclusive multicast Ethernet tag routes must be IPv6 when the underlay is IPv6. Encoding details vary between implementations.
-
Next-hop resolution for VXLAN encapsulation: when a VTEP receives an EVPN route with an IPv6 next-hop, it must resolve that IPv6 to the next hop in the underlay to encapsulate the VXLAN packet correctly. Vendors may implement this process slightly differently.
Interoperability issues typically do not show up in controlled labs (same vendor both ends) but in real multi-vendor environments. The recommendation is to explicitly test the vendor combination in your network before committing to IPv6 underlay in production.
What to evaluate before migrating
If you are considering IPv6 underlay for EVPN on your ISP network, this is the minimum technical evaluation checklist:
1. Firmware / software version on all VTEPs. Document exact versions of every device that will participate in the underlay. Check each vendor’s release notes to see whether IPv6 underlay support is marked “GA” (Generally Available) or “experimental.” Do not mix firmware versions in the same fabric if you have compatibility doubts.
2. Interoperability lab test before production. If you have more than one switch vendor in your EVPN fabric, build a test lab that mirrors your production vendor and version mix. Bring up BGP EVPN sessions between VTEPs, activate test VNIs, and verify VXLAN traffic flows correctly over IPv6.
3. Monitoring and observability plane validation. Does your current monitoring (NetFlow, sFlow, SNMP traps, BGP logs) handle IPv6 addresses correctly in next-hop and source fields? Systems not updated for IPv6 may lose visibility or show wrong data.
4. Impact on underlay routing. The EVPN underlay needs an IGP to distribute VTEP loopback routes. If you use OSPF today, you will need OSPFv3 or IS-IS with IPv6 TLVs for an IPv6 underlay. Assess whether your current IGP supports the configuration and whether your IPv6 numbering plan is defined.
5. Rollback plan. Every underlay migration needs a rollback procedure executable in under 30 minutes. Before migrating, document the exact steps to revert to an IPv4 underlay if IPv6 migration fails. On a production EVPN fabric, there is no room to improvise rollback.
The right stance today: assess, do not rush migration
IPv6 underlay in EVPN is technically viable on mature vendor platforms (Cisco, Juniper, Huawei) in recent releases. Open-source (FRRouting) support is still maturing.
But “technically viable on one vendor” is not the same as “ready for production in your specific multi-vendor environment.” Interoperability problems are real and can appear in platform combinations that seem up to date on paper.
The right stance for an ISP today is:
- Audit support for your specific vendor and version mix.
- Build the lab that mirrors your fabric and test IPv6 underlay before touching production.
- Set clear criteria for when to migrate: IPv6 traffic share on the subscriber network, hardware refresh cycle, vendor support convergence.
- Put it on the core modernization roadmap, alongside subscriber IPv6 migration.
There is no urgency to migrate the EVPN underlay to IPv6 today if the IPv4 underlay works. There is urgency to understand what your current gear supports, so when the decision comes, it is based on technical data, not assumptions.
How Ayuda.LA can help
At Ayuda.LA we work with ISPs and operators in Latin America on EVPN/VXLAN architecture audits and design, including readiness assessment for IPv6 underlay migration:
- Audit of the current EVPN fabric: we review firmware versions, VTEP configuration, and IPv6 underlay compatibility for your vendor mix.
- Interoperability test lab: we design and run IPv6 underlay interoperability tests in environments that mirror your production fabric.
- IPv6 modernization roadmap design: we integrate EVPN underlay migration into a coherent IPv6 adoption plan for the whole ISP network.
If your network runs EVPN/VXLAN and you are thinking about the IPv6 roadmap, now is the time for a technical assessment with clear criteria.
Let’s talk about your architecture →
Running EVPN on your ISP network and want to assess your gear for IPv6 underlay? Write to us at [email protected] — we answer every message.