IPv6-Capable Cloud Infrastructure Services
The adoption of IPv6 has been increasing, but there have been a few areas where IPv6 has had difficulty gaining traction. One area where IPv6 hasn’t been widely implemented is within corporate enterprise internal networks and another is within Cloud Service Provider (CSP) infrastructure. For many years, Amazon Web Services (AWS), Google Compute Engine (GCE), Microsoft Azure, VMware vCloud Air, and Salesforce have had either limited or no IPv6 capability.
Thus, the web services that rely on these public cloud services have been relegated to being IPv4-only sites. The organizations who are using these cloud providers for their public web-based applications have been unable to take advantage of the performance benefits of IPv6 that other IPv6-enabled platforms enjoy. In other words, the IPv6 deployment delays of the CSPs has delayed other downstream organizations from deploying IPv6.
Historically, there have not been many cloud providers who have embraced IPv6 but there have been some shining stars and rays of hope. John Vail’s 2012 RMv6TF IPv6 Summit presentation and his Nephos6 sponsored whitepaper showed which cloud providers were early adopters of IPv6.
Among those cloud providers who have embraced IPv6 include: Bluelock, Brightbox, DigitalOcean, OVH, and Rackspace. Other auxiliary cloud-based services like Ping Identity are now starting to support IPv6.
Also, when it comes to building a private cloud infrastructure, OpenStack has supported IPv6 for several years now. Also, software container technologies like Docker have had IPv6 for years now and there are significant benefits when using containers with IPv6-enabled networking.
Recent AWS IPv6 Announcements
AWS has been diligently working on building out more IPv6 capabilities and now AWS is offering more IPv6-capable services.
In all fairness, AWS has had IPv6 support for their Elastic Load Balancing (ELB) service for several years. The Elastic Load Balancing (ELB) service distributes application traffic across multiple AWS virtual servers providing for increased performance, service elasticity, added security, and fault tolerance. You can create an IPv6 VIP in the configuration of the ELB service, but the real-servers (AWS Elastic Compute Cloud (EC2)) instances are IPv4-only. This functionality would allow an AWS public web application that uses an Internet Gateway (IGW) to be reachable by IPv6-enabled clients. This is a similar approach to organizations who have used an IPv6-enabled Server Load Balancer (SLB)/Application Delivery Controller (ADC) reverse proxy function.
The AWS Internet of Things (IoT) service has also supported IPv6 for a couple of years now. The AWS IoT service allows for application interactions with IoT devices. IoT has been a driver for IPv6 and some even say that there can be “no IoT without IPv6”. Now you can use AWS to facilitate MQ Telemetry Transport (MQTT) client interactions with the AWS IoT service using IPv6.
AWS Simple Storage Service (S3) is an Internet-reachable durable object file storage service available through a web interface. A few months ago, in August of 2016, AWS announced IPv6 support for Amazon S3. Now, if you store files in S3 and your bucket and Identity and Access Management (IAM) policies allow it, you can reach your files over IPv6 transport. To reach your S3 bucket over IPv6, you would simply refer to the URL using the “dualstack” keyword as shown below.
A couple of months ago, in October of 2016, AWS announced IPv6 capabilities for three related Internet edge services: CloudFront, WAF, and S3 transfer acceleration. CloudFront is AWS’s own CDN service that provides for Internet caching of web application contents for improved performance. AWS also offers a Web Application Firewall (WAF) service for adding security to vulnerable web front-ends. The AWS S3 transfer acceleration provides better file transfer performance levering the caching functionality of CloudFront’s distributed edge locations. To enable CloudFront for IPv6, you must check the box in the service settings through the AWS Management Console. IPv6 addresses will now appear in the X-Froward-For HTTP header field capturing the source IP address for client connections. The AWS customer logs then must take this into consideration and be aware that a client can be reaching your CloudFront web content over IPv6.
AWS’s Route53 service is their highly scalable and reliable DNS web service. Up until 2 months ago, it was an IPv4-only service, but now it is IPv6-capable. The Route53 service can now perform DNS resolutions over IPv6 transport and can contain AAAA records and IPv6 PTR records.
There were many exciting AWS announcements made at their annual re:Invent conference held in Las Vegas, NV November 27th through December 1st. One of the most exciting to the IPv6 community is that AWS now has IPv6 support for EC2 instances in Virtual Private Clouds (VPCs). VPCs are AWS’s virtual networking service that connects EC2 compute instances to subnets and can connect to various gateways for external connectivity.
Previously, VPCs did not support IPv6 and prevented customers from using IPv6 and connecting to the IPv6 Internet. VPCs also facilitate connectivity to and from AWS using Internet Gateways (IGWs) or using you own private network. VPCs can now have IPv6 routes and Network Access Control Lists (NACLs) as well as security groups are now IPv6-capable. AWS VPC Peering is also IPv6 capable and VPC Flow Logs can gather information about IPv6 network traffic. IPv6-enabled VPCs allow your internal EC2 instances to use DHCPv6 to obtain their IPv6 address and to reach the Internet via a default gateway route. IPv6 is supported over Direct Connect, but IPv6 is not yet supported for Virtual Private Gateway (VGW) VPN connections.
Since IPv6 does not need a NAT function, the global IPv6 addresses used for your VPC can traverse gateways without translation, therefore, there is no need for elastic IPv6 addresses. AWS has also introduced an Egress-Only Internet Gateway (EIGW) that statefully controls Internet reachability for your VPC. The EIGW prevents unsolicited IPv6 inbound connections for private VPC connectivity.
Now that you can configure native IPv6 service for VPCs, you can have your EC2 instances connected to your own VPCs and you will get a /56 IPv6 prefix from AWS’s global IPv6 address block. The IPv6 address allocated to your VPC will vary based on the region you are operating in. Today this IPv6 VPC capability is only offered within the US-East-2 (Ohio, US) region. Hopefully this IPv6 VPC capability will be coming soon to other commercial AWS regions and U.S. GovCloud.
If you are curious, you can see which IPv6 prefixes are being advertised from AWS’s ASN 16509. You will quickly notice that they are extensively disaggregating their IPv6 addresses across their regions. (Could this create issues for the Internet as a whole? Perhaps: Smokey Bear recently reminded us “Only You Can Prevent IPv6 Prefix Disaggregation”.)
You are also encouraged to watch this quick session recording titled “AWS re:Invent 2016: NEW LAUNCH IPv6 in the Cloud: Protocol and AWS Service Overview (NET204)”. IPv6 proponents always love a good IPv4 to IPv6 address space analogy and the ladybug analogy is a good one. If you are already familiar with IPv6 fundamentals, you can just jump to 10:37 in the video where the conversation changes to how AWS services use IPv6.
Another more-detailed technical session on AWS IPv6 capabilities you will want to watch is this YouTube video recording for the session titled “AWS re:Invent 2016: NEW LAUNCH IPv6 in the Cloud: Virtual Private Cloud Deep Dive (NET307)”.
AWS and Infoblox
Amazon Web Services (AWS) has become one of the most dominant Infrastructure as a Service (IaaS) public cloud service providers. AWS has a strong set of ecosystem partners and a thriving AWS Marketplace. You can even buy Infoblox NIOS DNS and IPAM systems through the AWS Marketplace and run it in your AWS environment. Even though Infoblox has supported IPv6 for many years, if the cloud provider you are using was not IPv6 capable, then the IPv6 functionality in NIOS would be diminished. If your AWS virtual networks are not yet IPv6-enabled, then your Infoblox instance will only function over IPv4 transport. In this situation, however, the Infoblox NIOS system could return AAAA DNS record responses over IPv4 transport. But now that AWS has IPv6 support for VPCs, your Infoblox NIOS instances could be connected to those dual-protocol VPCs, then your Infoblox system will easily support your dual-protocol architecture.
Summary
Amazon Web Services should be commended for putting forth substantial effort to IPv6-enable their services. Their customers should now leverage these capabilities to enable their public web applications and make sure that they are reachable by all the IPv6-capable clients. Hopefully sometime soon, all AWS services will be dual-protocol capable. At that point, there will be complete functional parity and all AWS services will use both IP versions. The current AWS offering is dual-protocol, but eventually, AWS will make their platform functional in an IPv6-only configuration. We can anticipate that AWS’s movement toward IPv6 will help inspire other cloud providers. There are signs that the larger public CSPs are starting to embrace IPv6. For example, now Microsoft Azure has support for IPv6 on VMs. We can expect more cloud providers to adopt IPv6 in the coming year which will result in even higher Alexa top sites gaining IPv6 benefits.
