IPv6 hub-spoke network topology

This article describes how to transition an IPv4 hub-and-spoke network topology to IPv6. It presents the hub-and-spoke network topology as a starting point and describes the steps you can take to implement IPv6 support.

In a hub-and-spoke network, the hub virtual network is a central point of connectivity for the spoke virtual networks. The spoke virtual networks connect to the hub and can provide isolation for application resources. For more information, see Transitioning to IPv6.

Architecture

Download a Visio file of this architecture.

Workflow

1. Public internet and cross-premises network: Users or services can access Azure resources via the public internet. The cross-premises network has on-premises virtual machines that connect securely to the Azure network via a VPN gateway.

2. Azure Virtual Network Manager: This component is the management layer that oversees the entire network infrastructure within Azure. It handles the routing, policies, and overall health of the virtual network.

3. Hub virtual network: The hub is the central point of the network topology. The network configuration supports both IPv4 and IPv6 (dual stack).

   • Azure Bastion provides secure and seamless Remote Desktop Protocol/Secure Shell (RDP/SSH) connectivity from the Azure portal to the virtual machines directly over Transport Layer Security (TLS).
   • Azure Firewall inspects and filters traffic between the hub and the public internet.
   • ExpressRoute connects the cross-premises network to the hub.
   • VPN Gateway also connects the cross-premises network to the hub and provides redundancy.
   • The services in the hub virtual network send logs and metrics (diagnostics) to Azure Monitor for monitoring.

4. Spoke virtual networks: There are four spokes connected to the hub. Each spoke is a dual-stack network, supporting both IPv4 and IPv6.

   • IPv6 user-defined routes (UDRs) define custom routes for IPv6 traffic from the spoke.
   • The spoke virtual networks are connected via peering connections or connected groups. Peering connections and connected groups are nontransitive, low-latency connections between virtual networks. Peered or connected virtual networks can exchange traffic over the Azure backbone.
   • All outbound traffic from the spoke virtual networks flows through the hub, using a configuration in Azure Firewall called forced tunneling.
   • Within each spoke, there are three subnets designated as resource subnets, each hosting a virtual machine.
   • Each virtual machine connects to an internal load balancer configured to support IPv4 and IPv6 address ranges. The load balancer distributes incoming network traffic across the virtual machines.

Components

• Azure Virtual Network is the fundamental building block for private networks in Azure. Virtual Network enables many Azure resources, such as Azure Virtual Machines, to securely communicate with each other, cross-premises networks, and the internet.
• A virtual network interface is required for virtual-machine communication. You can set up virtual machines and other resources to have multiple network interfaces, which allows you to create dual-stack (IPv4 and IPv6) configurations.
• A public IP address is used for inbound IPv4 and IPv6 connectivity to Azure resources.
• Virtual Network Manager is used to create and manage network groups and their connections.
• Azure Firewall is a managed, cloud-based network security service. It protects your Azure Virtual Network resources. An Azure Firewall managed firewall instance is in its own subnet.
• Azure VPN Gateway or Azure ExpressRoute can be used to create a virtual network gateway to connect a virtual network to a virtual private network (VPN) device or an ExpressRoute circuit. The gateway provides cross-premises network connectivity.
• Azure Load Balancer is used to enable multiple machines that have the same purpose to share traffic. In this architecture, the load balancers distribute traffic among multiple subnets that support IPv6.
• A route table in Azure is a set of UDRs that provide custom path definitions for network traffic.
• Azure Virtual Machines is an infrastructure as a service (IaaS) computing solution that supports IPv6.
• Azure Bastion is a fully managed platform as a service (PaaS) offering that Microsoft provides and maintains. It provides secure and seamless remote desktop protocol and SSH access to virtual machines without public IP address exposure.
• Monitor is a comprehensive monitoring solution for collecting, analyzing, and responding to monitoring data from cloud and on-premises environments. You can use Monitor to maximize the availability and performance of your applications and services.

Transition a hub virtual network to IPv6

To transition a hub virtual network to support IPv6, you must update the network infrastructure to accommodate IPv6 address ranges, so the central, controlling part of the network can handle IPv6 traffic. This approach ensures that the central hub can efficiently route and manage traffic among various network segments (spokes) by using IPv6. To implement IPv6 in the hub virtual network, follow these steps:

Add IPv6 address space to the hub virtual network and the hub subnets

You need to add IPv6 address ranges to the hub virtual network first and then to its subnets. Use the /56 address block for the virtual network and the /64 address block for each subnet. The following table shows an example setup.

These IPv6 addresses are examples. You should replace 2001:db8:1234:: with your organization's IPv6 address block. Carefully plan and document your IPv6 address allocations to avoid overlaps and ensure efficient use of the address space. To add the IPv6 address space to the hub virtual network, you can use the Azure portal, PowerShell, or Azure CLI.

Configure user-define routes (UDRs) for each hub subnet

UDRs are routes that you manually set up to override Azure's default system routes. In Azure, UDRs are essential for controlling the flow of network traffic in a virtual network. You can use UDRs to direct traffic from one subnet to specific appliances, gateways, or targets within Azure or to on-premises networks. When you add IPv6 support to the hub virtual network, you need to:

• Add IPv6 routes. If there's an established route table, add new routes that specify the IPv6 address prefixes.
• Modify existing routes. If there are already routes for IPv4, you might need to modify them to ensure that they also apply to IPv6 traffic, or create separate IPv6-specific routes.
• Associate the route table with subnets. After you define the routes, associate the route table with the relevant subnets within the virtual network. This association determines which subnets use the routes that you defined.

You don't need to add a route for every resource, but you do need a route for each subnet. Each subnet can have multiple resources, and they all follow the rules that are defined in the route table associated with their subnet. For more information, see User-define route overview.

For the example architecture, the hub virtual network has four subnets: Azure Bastion, Azure Firewall, VPN Gateway, and ExpressRoute. The following table shows example UDRs for each subnet.

When you set up your UDRs, you must align them with your organizational network policies and the architecture of your Azure deployment.

Modify the ExpressRoute circuit (if applicable)

To provide the ExpressRoute circuit with IPv6 support, you need to:

• Enable IPv6 private peering. Enable IPv6 private peering for the ExpressRoute circuit. This configuration enables IPv6 traffic between your on-premises network and the hub virtual network.
• Allocate IPv6 address space. Provide IPv6 subnets for the primary and secondary ExpressRoute links.
• Update route tables. Ensure that you direct IPv6 traffic appropriately through the ExpressRoute circuit.

These configurations extend IPv6 connectivity to your Azure services via an ExpressRoute circuit, so you can route dual-stack capabilities simultaneously. To modify ExpressRoute, you can use the Azure portal, PowerShell, or Azure CLI.

Transition spoke virtual networks to IPv6

Spoke virtual networks are connected to the central hub. When you provide the spoke virtual networks with IPv6 support, each spoke network can communicate via the more advanced IPv6 protocol, and it extends uniformity across the network. To provide the spoke virtual networks with IPv6 support, follow these steps:

Add IPv6 address space to the spoke virtual networks and spoke subnets

Like the hub virtual network, you must add IPv6 address ranges to every spoke virtual network and then their subnets. Use the /56 address block for the virtual networks and the /64 address block for the subnets. The following table provides an example of IPv6 address ranges for spoke virtual networks and their subnets.

For your setup, adjust the IPv6 addresses according to your organization's allocation and needs.

Modify spoke virtual network resources

Each spoke virtual network contains multiple virtual machines and an internal load balancer. The internal load balancer enables you to route IPv4 and IPv6 traffic to the virtual machines. You must modify the virtual machines and internal load balancers so they support IPv6.

For each virtual machine, you must create an IPv6 network interface and associate it with the virtual machine to add IPv6 support. For more information, see Add IPv6 configuration to a virtual machine.

If there isn't an internal load balancer in each spoke virtual network, you should create a dual-stack internal load balancer. For more information, see, Create a dual-stack internal load balancer. If there's an internal load balancer, you can use PowerShell or Azure CLI to add IPv6 support.

Configure user-defined routes (UDRs) for each spoke subnet

To configure UDRs, spoke virtual networks use the same configuration as hub virtual networks When you add IPv6 support to a spoke virtual network, you need to:

• Add IPv6 routes. If there's an established route table, add new routes that specify the IPv6 address prefixes.

• Modify existing routes. If there are already routes for IPv4, you might need to modify them to ensure that they also apply to IPv6 traffic, or create separate IPv6-specific routes.

• Associate the route table with subnets. After you define the routes, associate the route table with the relevant subnets within the virtual network. This association determines which subnets use the routes that you defined.

The following table shows example UDRs for each subnet in a spoke virtual network.

For your setup, you must align the UDRs with your organizational network policies and the architecture of your Azure deployment.

Contributors

Microsoft maintains this article. The following contributors originally wrote the article.

Principal author:

• Werner Rall | Senior Cloud Solutions Architect Engineer

Other contributors:

• Sherri Babylon | Senior Technical Program Manager
• Dawn Bedard | Principal Technical Program Manager
• Brandon Stephenson | Senior Customer Engineer

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• Create a virtual machine with a IPv6 dual-stack network
• Manage IP address ranges
• Cloud Adoption Framework: Plan for IP addressing
• IPv6 for Azure Virtual Network
• Add IPv6 support via ExpressRoute
• Azure DNS IPv6 support
• IPv6 for Azure Load Balancer
• Add IPv6 support for private peering using the Azure portal

Related resources

• Transition to IPv6
• Choose between virtual network peering and VPN gateways
• Firewall and Application Gateway for virtual networks
• Virtual network-integrated serverless microservices
• Deploy AD DS in an Azure virtual network