IPv4/IPv6 dual stack webservices in Azure
This article is contributed. See the original author and article here.
IPv6 is the most recent version of the Internet Protocol (IP) and the Internet Engineering Task Force (IETF) standard is already more than 20 years old, but for most of us is it still not something we have to deal with on a day-to-day basis. This is slowly changing as some areas of the world are running out of IPv4 addresses and local governments start to make IPv6 support mandatory for some verticals. This results in urgent requests by some of our customers to provide their webservices via IPv4 and IPv6 (so called dual stack) to fulfill their regulatory requirements.
The Internet Society published an article already back in June 2013 (see “Making Content Available Over IPv6”) on what potential implementations could look like. Their article is covering native IPv6, proxy servers and Network Address Translation (NAT). Even though the article is already a few years old, the different options are still valid.
So how does this apply to Azure? Azure supports IPv6 and has done for quite some time now for most of its the foundational network and compute services. This enables native implementations using IPv4 and IPv6 by leveraging Azure’s dual stack capabilities.
For example, in scenarios where applications are mainly based on Virtual Machines (VMs) and other Infrastructure-as-a-Service (IaaS) services with full IPv6 support, we are able to use native IPv4 and IPv6 end-to-end. This avoids any complications caused by translations and it provides the most information to the server and the application. But it also means that every device along the path between the client and the server must handle IPv6 traffic.
The following diagram depicts a simple dual stack (IPv4/IPv6) deployment in Azure:
The native end-to-end implementation is most interesting for scenarios and use cases where direct server-to-server or client-to-server communication is required. This is not the case for most webservices and applications as they are typically already exposed through, or shielded behind a Firewall, a Web Application Firewall (WAF) or a reverse proxy.
Other more complex deployments and applications often times contain a set of 3rd-party applications or Platform-as-a-Service (PaaS) services like Azure Application Gateway (AppGw), Azure Kubernetes Services (AKS), Azure SQL databases and others that do not necessarily support native IPv6 today. And there might be also other backend services and solutions, in some cases hosted on IaaS VMs that are also not capable of speaking IPv6. This is where NAT/NAT64 or an IPv6 proxy solution comes to play. These solutions allow us to transition from IPv6 to IPv4 and vice versa.
Besides the technical motivation and need to translate from IPv6 to IPv4 are there also other considerations especially around education, the costs of major application changes and modernization as well as the complexity of an application architecture why customers consider using a gateway to offer services via IPv4/IPv6 while still leveraging IPv4-only infrastructure in the background.
A very typical deployment today, for example using a WAF, looks like this:
The difference between the first and the second drawing in this post is that the latter has a front-end subnet that contains for example a 3rd-Party Network Virtual Appliance (NVA) that accepts IPv4 and IPv6 traffic and translates it into IPv4-only traffic in the backend.
This allows customers to expose existing applications via IPv4 and IPv6, making them accessible to their end-users natively via both IP versions without the need to re-architect their application workloads and to overcome limitations in some Azure services and 3rd-Party services that do not support IPv6 today.
Here is a closer look on how a typical architecture could look like:
The Azure Virtual Network is enabled for IPv6 and has address prefixes for IPv4 and IPv6 (these prefixes are examples only). The “Front-end subnet” is enabled for IPv6 as well and contains a pair of NVAs. These NVAs are deployed into an Azure Availability Set, to increase their availability, and exposed through an Azure Load Balancer (ALB). The first ALB (on the left) has a public IPv4 and a public IPv6 address.
The NVAs (for example a WAF) in the Front-end subnet accept IPv4 and IPv6 traffic and can offer, depending on the ISV solution and SKU a broad set of functionality and translate the inbound traffic into IPv4 to access the application that is running in our “Application subnet”. The application is again exposed (internally; no public IP addresses) via IPv4 only through an internal ALB and only accessible from the NVAs in the front-end subnet.
This results in an architecture that provides services via IPv4 and IPv6 to end-users while the backend application is still using IPv4-only. The benefit of this approach is the reduced complexity, the application teams do not need to know and take care of IPv6, on one hand and on the other hand a reduced attach surface as between the front-end and the application subnet we’re only using the well-known and fully supported IPv4 protocol.
Instead of using a 3rd-party NVA, Azure offers similar, managed capabilities using the Azure Front Door (AFD) service. AFD is a global Azure service that “enables you to define, manage and monitor global routing for web traffic by optimizing for best performance and quick global failover for high availability” (see “What is Azure Front Door?”). AFD works at Layer 7 (OSI model) or HTTP/HTTPS layer and uses the anycast protocol and allows you to route client requests to the fastest and most available application backend. An application backend can be any Internet-facing service hosted inside or outside of Azure.
AFD’s capabilities include proxying IPv6 client requests and traffic to an IPv4-only backend as shown below:
The main architectural difference between the NVA-based approach we have described in the beginning of this post and the use of AFD service is, that the NVAs are customer-managed, work at Layer 4 (OSI model) and can be deployed into the same Azure Virtual Network as the application in a way where the NVA has a private and a public interface. The application is then only accessible through the NVAs which allows filtering of all ingress (and egress) traffic. Whereas AFD is a global PaaS service in Azure, living outside of a specific Azure Region and works at Layer 7 (HTTP/HTTPS). The application backend is an Internet-facing service hosted inside or outside of Azure and can be locked down to accept traffic only from your specific Front Door.
While we are in this post explaining these two solutions as different options to make IPv4-only applications and services hosted in Azure available to users via IPv4 and IPv6, it is in general and especially in more complex environments not either a WAF/NVA solution or Azure Front Door. It can be a combination of both where NVAs are used within a regional deployment while AFD is used to route the traffic to one or more regional deployments in different Azure regions (or other Internet-facing locations).
What’s next? Take a closer look into Azure Front Door service and its documentation to learn more about its capabilities to decide if either native end-to-end IPv4/IPv6 dual stack, a 3rd-party NVA-based solution or Azure Front Door services fulfils your needs to support IPv6 with your web application.
Recent Comments