What changed
Azure Route Server IPv4/IPv6 dual-stack mode is in preview. Until now Microsoft's own guidance was blunt. The Route Server FAQ, last updated November 3, 2026, says that deploying Route Server into a virtual network that has an IPv6 address space breaks IPv6 connectivity in that network. That is a paraphrase of the FAQ's warning. The FAQ also says a dual-stack VNet peered to the Route Server VNet keeps IPv4 connectivity, but IPv6 over that peering isn't supported.
Several other Microsoft pages still carried the older position when this preview landed. The IP planning guide says Route Server (IPv4 only) is among the services that don't support IPv6. The Azure Architecture Center's IPv6 hub-spoke guide has the same table entry: Azure Route Server supports IPv4 traffic only. Expect those pages to be revised. Until they are, they'll contradict the preview.
What the preview documentation says
A new Microsoft Learn tutorial describes how the preview is set up. These details come from that tutorial:
- Access is gated. Prerequisites include an Azure account with an active subscription where Route Server dual-stack preview access is enabled. This is not a switch every subscription already has.
- Regions are limited. The tutorial says dual-stack mode is available in preview only in specific Azure regions. The region list didn't come through in the material I could read, so check the tutorial before planning.
- Address families come first. The tutorial's warning is don't deploy Route Server until both address families are present on RouteServerSubnet.
- Dual-stack mode follows the subnet. Because RouteServerSubnet already has an IPv6 prefix, the route server is created in dual-stack mode, and the setting shows Enabled.
- The walkthrough is hands-on. It covers deploying dual-stack Azure Route Server, establishing BGP peering with a Linux network virtual appliance (NVA), and verifying IPv4 and IPv6 routes.
The tutorial's example still uses IPv4 for some pieces. It has you create a Standard IPv4 public IP address for Route Server, and it tells you to record the Route Server's two IPv4 addresses. Don't read that as "IPv6 BGP peering is fully proven." The material I could read doesn't say how IPv6 route exchange with NVAs is configured beyond the dual-stack subnet setup. It doesn't cover whether gateway route exchange works over IPv6 either.
Why network teams should care
Route Server exists to exchange routes over BGP between NVAs, such as SD-WAN and firewall appliances, and the virtual network. It doesn't forward data traffic. The FAQ says the data traffic goes directly from the NVA to the destination virtual machine. That makes IPv6 support a control-plane question: can your NVAs learn and advertise IPv6 prefixes with Azure's routing, instead of relying on static user-defined routes?
Before this preview, hub-and-spoke designs with IPv6 had to work around the gap. Microsoft's architecture guidance advised designs where IPv6 traffic is handled before reaching these components. This preview is the first sign Microsoft is closing that gap for Route Server. It is a preview, though, and the documentation I could read doesn't cover production support.
Cautions before you try it
- Preview means non-production. Azure's own update-page definitions say preview is available for non-production use and testing. That wording comes from the Azure Updates page. Treat this as a lab and pilot feature.
- Neighboring services have their own status. Azure Firewall's dual-stack IPv6 support is in preview; application rules joined the IPv6 preview on November 4, 2026, so it is no longer limited to network rules and DNS proxy. VPN Gateway IPv6 is currently in PREVIEW and covers inner traffic only. Virtual WAN was listed as IPv4-only in the sources I read. A dual-stack Route Server doesn't automatically give you an end-to-end IPv6 path through those services.
- Existing limits still apply. These come from the FAQ and are general Route Server facts. The service has only one instance per VNet, in a dedicated subnet named RouteServerSubnet. There is a 16-peer limit and a 4,000-route limit per BGP peer. Creating or deleting Route Server in a VNet with a VPN or ExpressRoute gateway can cause about 10 minutes of downtime. Microsoft suggests a 60-minute maintenance window. It's unconfirmed whether the preview changes any of these numbers.
- Check ordering. Because the tutorial says the subnet must have both address families before Route Server is deployed, plan the sequence deliberately. Don't add IPv6 to a VNet that already hosts Route Server on the assumption it will convert cleanly. The FAQ's warning about breaking IPv6 traffic applies to the pre-preview behavior, and I found no documentation on how existing deployments migrate.
What to do next
- Confirm your subscription has preview access and that your target region is on the supported list.
- Build a test VNet with a dual-stack RouteServerSubnet and a separate NVA subnet.
- Peer a test NVA with both Route Server instances, as the FAQ requires for high availability, and check that IPv4 and IPv6 routes both show up.
- Test failure and maintenance behavior before you rely on it.
- Keep production designs on the documented IPv4-only workarounds until Microsoft publishes general availability and updates its limitation tables.
The takeaway
The preview ends a long-standing line in Microsoft's documentation, but only partly. It is gated, regional and non-production, and neighboring services like Firewall and VPN Gateway are still in preview themselves. For IPv6 planners, it's a good reason to start lab testing. It isn't yet a reason to change production routing designs.
Correction (November 10, 2026): An earlier version of this article said Azure Firewall's dual-stack IPv6 support covers network rules and DNS proxy only. Application rules entered the IPv6 public preview on November 4, 2026, so that scope statement was out of date.