As organizations begin to convert new and existing IPv4 workloads to IPv6, they will need to manage communications between these different IP versions. This article provides an overview of three common Azure workload scenarios organizations need to plan for, and how to execute by leveraging the dual-stack nature of Azure networks.
Azure IPv6 enabled services are deployed in a dual-stack configuration that allows them to maintain both IPv4 addresses and IPv6 addresses. These IPv4 do not need to be unique inside of the private network. For more information on reusing IPv4 addresses, see Conceptual planning for IPv6 networking - Azure Architecture Center | Microsoft Learn
You can also use these patterns in reverse to enable IPv4 to IPv6 communication, but depending on your environment you may have additional considerations.
IPv6 Azure workloads to IPv4 Azure workloads
In this scenario, the organization has an application that uses IPv6 and is hosted on Azure virtual machines. These VMs are deployed in Virtual Network A. This application may be receiving queries from IoT devices over the public internet or servicing another sort of IPv6 clients.
The application in Virtual Network A needs to be able to connect to another existing application in order to send data back to its clients. This other application is running on IPv4, and is deployed in Virtual Network B.
These networks can be directly peered together or use a hub and spoke traffic pattern as defined in Hub-spoke network topology in Azure - Azure Architecture Center | Microsoft Learn.
Because the Azure VM workload is dual stacked, it already has a private IPv4 address available. When it needs to communicate to Virtual Network B, it will use its IPv4 network interface to send the traffic to the IPv4 virtual machine directly over the Microsoft backbone infrastructure.
There is no need to set up network address translation or use any synthetic communication between resources, as normal peering provides this function.
The IP addresses assigned to Virtual Network A do not need to be globally unique in the environment. However, they do need to be unique to any networks peered with Virtual Network A, such as Virtual Network B. They also need to be unique to any other networks that need to communicate with Virtual Network A without using NATing.
IPv6 Azure workloads to IPv4 on-prem workloads
In this scenario, the organization has an IPv6 workload operating in Azure with a similar configuration to the one in the previous scenario. However, in this scenario it also has a backend service in Subnet B of Virtual Network A that calls to a data source operating in the corporate data center.
Virtual Network A is peered to a hub that contains a virtual network gateway connecting to the data center.
The backend service is IPv4 only. This virtual machine has no IPv6 addresses and no network address translation.
Like in the previous scenario, the backend service in Subnet B can use its IPv4 network interface to communicate to the on-prem data source. It can continue to use its IPv6 interface to communicate with the application in Subnet A. The gateway can accept the IPv4 or IPv6 address traffic without any translation needed, and connect the backend to the OnPrem Network C.
Return traffic, or traffic originating from the IPv4 service in the data center, can flow to the IPv4 address assigned to the service in Subnet B. It is important to note in this flow, only Subnet B needs to be unique for Network C to be able to communicate with it. Subnet A could contain non-routable IPv4 addresses and reuse the addresses elsewhere in the environment.
IPv6 on-prem workloads to IPv4 Azure workloads
Unlike the previous scenarios, this scenario starts with an application operating in the on-premises network space. This application is hosted on a server that is IPv6 only, and it needs to make a call to a data source hosted on a server in Azure that is configured only to use IPv4.
The diagram below shows the desired flow as dotted lines.
There are a few different solutions available to address this communication flow. The first option you should consider is updating your Azure server or services to operate in a dual-stack configuration. This is a direct process of adding new IP space and a new interface, and won’t disrupt the existing IPv4 traffic. This will enable more communication patterns for your workloads, without having to maintain new technologies.
However, if you cannot update the service you can instead use third-party NAT64 services to NAT traffic between the two IP versions.
Option 1: Update the Azure server to be dual-stack
Depending on your workload, the simplest solution is to configure a specific virtual machine to be dual-stack. By assigning an IPv6 address range to the virtual network and subnet, you can then create a new network interface to the Azure virtual machine. This allows the target server to begin receiving the traffic from the data center.
This dual-stack configuration does not disrupt the application’s existing IPv4 communication to other servers or services in its virtual network.
To support this scenario, an organization must establish a connection between Network C and the Azure networks using ExpressRoute. ExpressRoute Circuits and ExpressRoute gateways allow for IPv6 traffic, but VPN gateways do not. If you are using a third party VPN provider to connect Azure to Network C, refer to your vendor’s documentation for what kinds of traffic are supported.
Option 2: Configure NAT64 solutions in on-premises networks
If you are not able to dual-stack the servers in Azure, you can investigate NAT64 service implementation as part of your on-prem networks. In this scenario, the NAT64 service is deployed in Network C. This enables address translation to IPv4 from the IPv6 device.
The IPv6 virtual machine initiating the connection imbeds the IPv4 address it wishes to communicate with inside of an IPv4 address with a specific well known prefix (64:ff9b::/96). The NAT64 gateway receives the traffic, and then strips out the well-known address. It is then left with a viable IPv4 address it can use to reach the IPv4 target.
The IPv4 service then responds to the gateway’s IPv4 address, where the gateway then re-packages the IPv4 address into the IPv6 packet with the same prefix.
This has the advantage of not explicitly needing an IPv6 enabled gateway in Azure, as the traffic is converted to IPv4 before entering the Azure space.
While you can deploy the NAT64 gateway in different locations in your network topology through the use of NVAs or virtual appliances, keeping the NATing close to the IPv6 services on-prem can simplify the routing pattern by keeping it from changing IP versions after crossing the connection to Azure.
Next Steps
If you are looking for more on connectivity with IPv6, see the following:
- Overview of IPv6 for Azure Virtual Network | Microsoft Learn for more about IPv6 networking in Azure
- Conceptual planning for IPv6 networking - Azure Architecture Center | Microsoft Learn to review conceptual planning concepts for adopting IPv6.
- IPv6 hub-spoke network topology - Azure Architecture Center | Microsoft Learn for planning a hub and spoke network with IPv6.
- Configure Application Gateway with a frontend public IPv6 address using the Azure portal - Azure App... to learn more about using an IPv6 public IP as a front end for an IPv4 application.
- Add an IPv4 application to IPv6 in Azure Virtual Network - PowerShell | Microsoft Learn for more on adding IPv6 to an existing IPv4 services using load balancers.