Is the public cloud ready for IPv6?

By on 19 Apr 2023

Category: Tech matters

Tags: , ,

Blog home

When connecting machines over the public Internet (or over private networks), we use IPv4 addresses. For many years we’ve heard about IPv4 address exhaustion or the fact that sometime in the future we will not able to request new IPv4 addresses to connect over the public Internet. We all heard that IPv6 address space will resolve this problem, but will it?

In this blog post, I will compare common use cases for using cloud services and see if they are ready for IPv6.

Before we begin, when working with IPv6, we need to clarify what ‘dual-stack‘ means — A device with dual-stack implementation in the operating system has an IPv4 and IPv6 address and can communicate with other nodes in the LAN or the Internet using either IPv4 or IPv6.

Step 1. Cloud network infrastructure

The first step in building our cloud environment begins with network services.

The goal is to be able to create a network environment with subnets, an access control list, be able to create peering between cloud accounts (for the same cloud provider) and get ingress access to our cloud environment (either from the public Internet or from our on-premise data centre).

Amazon VPCAzure VNetGoogle VPC
Dual-stack supportYesYesYes
IPv6-only supportYesYesYes
Ability to create network access controlsYes (security groups and networks ACLs)Yes (network security groups)Yes (VPC firewall rules)
DHCPv6 supportYesYesYes
Peering supportYesYesYes
Table 1 — Comparing cloud network infrastructure support.

Step 2. Private network connectivity — managed VPN services

Now that we have a network environment in the cloud, how do we connect to it from our on-premise data centre using site-to-site VPN? Let’s compare the cloud providers’ alternatives:

AWS site-to-site VPNAzure VPN GatewayGoogle Cloud VPN
Dual-stackNoNoYes (using HA VPN only)
IPv6-onlyYesNoNo
Table 2 — Vendor support for dual-stack and IPv6 only.

Step 3. Private network connectivity — dedicated network connections

Assuming we managed to create a VPN tunnel between our on-premise data centre and the cloud environment, what happens if we wish to set up a dedicated network connection (and have low latency and promised bandwidth)? Let’s compare the cloud providers’ alternatives:

AWS Direct ConnectAzure Express RouteGoogle Cloud Interconnect
Dual-stack supportYesYesNo
IPv6-only supportUnknownUnknownNo
Private IPv6 peering supportYesYesNo
Public IPv6 peering supportYesYesNo
Table 3 — Vendor support for dedicated network connection.

Step 4. Private Network Connectivity — resources on the subnet level

We have managed to provision the network environment in the cloud using IPv6.

What happens if we wish to connect to managed services using private network connectivity (inside the cloud provider’s backbone and not over the public Internet)? Let’s compare the cloud providers’ alternatives:

AWS PrivateLinkAzure Private Link
Dual-stack supportYesYes
IPv6-only supportYesUnknown
Customer endpoint support for IPv6YesUnknown
Service provider endpoint support for IPv6Yes (using dual-stack only)Unknown
Table 4 — Vendor support for subnet-level resources.

Step 5. Name resolution — managed DNS service

In the previous step we configured network infrastructure. Before provisioning resources, let’s make sure we can access resources, that is, having a managed DNS service.

By name resolution, I mean both external customers over the public Internet and name resolution from our on-premise data centres. Let’s compare the cloud providers’ alternatives:

Amazon Route 53Azure DNSGoogle Cloud DNS
Support both forward (AAAA) and reverse (PTR) IPv6 recordsYesYesYes
Recursive DNS resolvers on IPv6 networksYesYesYes
Public IPv6 DNS resolutionYesYesYes
Private DNS resolutionYesYesYes
Health checks of IPv6 endpointsYesUnknownUnknown
Table 5 — Vendor support for name resolution.

Step 6. Resource provisioning — compute (VM)

In the previous steps we have set up the network infrastructure and name resolution, and now it is time to provision resources.

The most common resource we can find in Infrastructure as a Service (IaaS) is compute or Virtual Machines (VMs). Let’s compare the cloud providers’ alternatives:

Amazon EC2Azure Virtual MachinesGoogle Compute Engine
Dual-stack supportYesYesYes
IPv6 only supportYesNoNo
Table 6 — Vendor support for compute VMs.

Step 7. Resource provisioning — compute (managed Kubernetes)

Another common use case is to provision containers based on a managed Kubernetes service. Let’s compare the cloud providers’ alternatives:

Amazon Elastic Kubernetes Service (EKS)Azure Kubernetes Service (AKS)Google Kubernetes Engine (GKE)
Dual-stack supportYesYes (Preview in 02/2023)Yes
IPv6-only supportYes (AWS Nitro-based Amazon EC2 or Fargate nodes)NoYes
Assign IPv6 address to nodesYesYesYes
Assign IPv6 address to podsYesYesYes
Assign IPv6 address to servicesYesYesYes
Table 7 — Vendor support for managed Kubernetes.

Step 8. Resource provisioning — compute (serverless / Function as a Service)

If we have already managed to provision VMs and containers, what about provisioning serverless or Function-as-a-Service (FaaS)? Let’s compare the cloud providers’ alternatives:

AWS LambaAzure FunctionsGoogle Cloud Functions
Dual-stack supportYesNoNo
IPv6-only supportNoNoNo
Table 8 — Vendor support for serverless / FaaS compute.

Step 9. Resource provisioning — managed load balancers

If we are planning to expose services either to the public Internet or allow connectivity from our on-premise, we will need to use a managed load-balancer service. Let’s compare the cloud providers’ alternatives:

Amazon Elastic Load BalancingAzure Load BalancerGoogle Cloud Load Balancing
Dual-stack supportYesYesYes
IPv6-only supportYes (using AWS Transit Gateway)NoNo
External load balancer IPv6 supportYesYesYes
Internal load balancer IPv6 supportYes (using Internet Gateway)YesYes (using dual-stack only)
Layer 4 load balance support for IPv6Yes (using AWS NLB)YesNo
Layer 7 load balance support for IPv6Yes (using AWS ALB)NoYes
IPv6 target group / backend pool / target pool supportYes (using dual-stack only)YesYes
Table 9 — Vendor support for managed load balancers.

Step 10. Resource provisioning — managed object storage

The next step after provisioning compute services is to allow us to store data in an object storage service. Let’s compare the cloud providers’ alternatives:

Amazon S3Azure Blob StorageGoogle Cloud Storage
Dual-stack supportYesNoNo
IPv6-only supportNoNoNo
IPv6 public endpoint supportYesNoNo
IPv6 private endpoint supportNoNoNo
Table 10 — Vendor support for managed object storage.

Step 11. Resource provisioning — managed database services

Most of the applications we provision require a backend database to store and retrieve data. Let’s compare the cloud providers’ alternatives:

Amazon RDSAzure SQLGoogle Cloud SQL
Dual-stack supportYesYesNo
IPv6-only supportNoNoNo
Ability to configure database firewall rulesYes (using dual-stack only)Yes (using dual-stack only)No
Table 11 — Vendor support for managed database services.

Step 12. Protecting network access — managed firewall services

If we are planning to expose services to the public Internet using IPv6 or allow access from on-premise, we need to consider a managed network firewall service. Let’s compare the cloud providers’ alternatives:

AWS Network FirewallAzure Firewall ManagerGoogle Cloud Firewall
Dual-stack supportYesNoUnknown
IPv6-only supportNoNoUnknown
Table 12 — Vendor support for managed firewall services.

Step 13. Protecting network access — managed DDoS protection services

On the topic of exposing services to the public Internet, we need to take into consideration protection against DDoS attacks. Let’s compare the cloud providers’ alternatives:

AWS ShieldAzure DDS ProtectionGoogle Cloud Armor
Dual-stack supportYesYesYes
IPv6-only supportYesUnknownUnknown
Table 13 — Vendor support for managed DDoS protection services.

Step 14. Protecting network access — managed Web Application Firewalls (WAFs)

We know that protection against network-based attacks is possible using IPv6 but what about protection against application-level attacks? Let’s compare the cloud providers’ alternatives:

AWS WAFAzure Front DoorGoogle Cloud Armor
Dual-stack supportYesYesYes
IPv6-only supportUnknownUnknownUnknown
Table 14 — vendor support for managed Web Application Firewalls

Summary

In this blog post we have compared various cloud services, intending to answer the question — is the public cloud ready for IPv6?

As we have seen, many cloud services do support IPv6 today (mostly in dual-stack mode), and AWS does seem to be more mature than its competitors, however, at the time of writing this post, the public cloud is not ready to handle IPv6-only services.

The day we will be able to develop cloud-native applications while allowing end-to-end IPv6-only addresses, in all layers (from the network, compute, database, storage, event-driven / message queuing, and so on), is the day we know the public cloud is ready to support IPv6.

For the time being, dual-stack (IPv4 and IPv6) is partially supported by many services in the cloud, but we cannot rely on end-to-end connectivity.

For some additional references, read AWS services that support IPv6 and An Introduction to IPv6 on Google Cloud.

This post is adapted from the original at Medium.

Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7, and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry. Eyal is an AWS Community Builder since 2020. You can connect with him on Twitter and LinkedIn.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top