Recently I came across lot of requirements from customers to provide dual stack webservices support via IPv4 and IPv6 to cater to their regulatory requirements. Dual stacked services will also provide maximum service deployment flexibility wherein a single service instance can connect with both IPv4 and IPv6-capable internet clients thereby expanding their reach of Azure-hosted applications into the growing mobile and Internet of Things markets.
This change request also becomes more challenging as this needs to be done with minimal changes to existing architecture build over the years. This blog will share how to address the dual stack webservices requirement with minimal changes without the need to re-architect the application workloads.
❐ Lets understand — What is IPv6?
Every device be it a computer, mobile phone, IOT appliances connected to the Internet needs a numerical IP address in order to communicate with other devices. This is similar to a street addresses and pin code needed to communication for mailing a letter.
IPv6 is the latest version & next generation of Internet Protocol (IP) that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion. IPv6 is intended to replace IPv4.
❐ Azure IPv6 Support
Azure supports IPv6 for most of its foundational network and compute services enabling native implementations using IPv4 and IPv6. Supporting IPv6 natively everywhere means that every device along the path to the server must handle IPv6 traffic including the routers, firewalls, load balancers and of course the server itself. This is the most preferred option since it avoids any complications caused by translations and it provides the most information to the server.
Pleaser refer below diagram for a Simple dual stack (IPv4/IPv6) deployment in Azure.
It is also important to note that some of the Platform-as-a-Service (PaaS) services in Azure today do not support native IPv6. e.g. Azure platform (AKS, etc.) does not support IPv6 communication for Containers, Azure Application Gateway (AppGw) & API Management (APIM) also doesn’t support IPv6.
Coming back to customer scenarios, it is not possible to implement native IPv6 everywhere since the customer typically have a mix of 3rd-party applications and Platform-as-a-Service (PaaS) services like Azure Application Gateway (AppGw), AKS & Azure Database for PostgreSQL that do not support native IPv6 today. This forces us to think of NAT/NAT64 gateway or an IPv6 proxy solution(layer 4 (TCP) or layer 7 (HTTP/HTTPS)) to transition from IPv6 to IPv4 and vice versa while still leveraging IPv4-only infrastructure in the background.
This proxy layer accepts IPv4 and IPv6 traffic and translates it into IPv4-only traffic in the backend without the need to re-architect their existing application workloads and to overcome limitations in some Azure services that do not support IPv6 today.
❐ Azure Front door to rescue
Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. Azure Front door has native support of end-to-end IPv6 connectivity. Azure Front door can be used for proxying IPv6 client requests and routing the traffic to an IPv4-only backend instead of using a 3rd-party NVA. Front Door works at Layer 7 (HTTP/HTTPS layer) using anycast protocol with split TCP and Microsoft’s global network to improve global connectivity.
In the above example, http://stageapifd.azurefd.net/ is IPv6/IPv4 enabled dual stack webservice but the backend is still in IPv4.
Please refer below key features included with Front Door:
- Accelerated application performance by using split TCP-based anycast protocol.
- Intelligent health probe monitoring for backend resources.
- URL-path based routing for requests.
- Enables hosting of multiple websites for efficient application infrastructure.
- Cookie-based session affinity.
- SSL offloading and certificate management.
- Define your own custom domain.
- Application security with integrated Web Application Firewall (WAF).
- Redirect HTTP traffic to HTTPS with URL redirect.
- Custom forwarding path with URL rewrite.
- HTTP/2 protocol support
I used IPv6 test — web site reachability (ipv6-test.com) to test if the webservice is IPv6 ready.
Special thanks to Ameet & Saurabh Vartak who guided me towards the solution.
I hope this blog helped you in understanding how to address the dual stack webservices requirement with minimal changes to existing application architecture. Happy Learning!!!
Please Note — All opinions expressed here are my personal views and not of my employer.
Thought of the day -
Zindagi Badi Honi Chahiye Lambi Nahi…..
Life should be great rather than long — B.R Ambedkar
