The State of IPv6 in AWS — August 2016
Issues & Concerns
More and more, I’m asked *exactly* what IPv6 on the AWS platform really means, by more than a few confused people. Working within the Higher Ed and Federal markets, IPv6 is a topic on folks mind — whether its a point of pride at being at the “edge” of solving IPv4 starvation problems, or just fully adhering to the OMB’s IPv6 Mandate for Federal Clients — which has come and gone in 2007.
I must say, I do share the frustration of these customers as they navigate the many asterisks and small print exceptions when addressing their IPv6 adoption / readiness on the AWS Cloud. Counter point to this is that AWS needs to know that people need (not just “want”) the feature.
For better or worse, it is what it is — and only a large vocal out cry from the affected communities of users, as well as the low constant growl of their wallets, will bring us a faster, more complete adoption. Just posting on the support forums that you need it is not as powerful of a tool as really leaning on your AWS Account Reps and Solutions Architects — and showing them that it is critical to your workloads. I bug/pester/annoy/put-on-the-spot each AWS SA I meet concerning IPv6 for my customers — but the more that the customers lean in, the more momentum we will get towards a more robust support of the protocol. I’m one voice represting 100’s — that isn’t as powerful as 100 individual voices.
That said, this month we have some movement on the IPv6 support effort. S3 has received some of the most extensive IPv6 support that any service has ever seen within AWS. I’m hoping that this is a lead up to re:Invent, and we will see lots of IPv6 feature adds leading up to and at the show this year.
I’ll update/build on this post as we get new features, but until then, here are all the services that support any type of IPv6 in AWS. Let me break your heart upfront however: There is no native IPv6 support for Instances within AWS. Period. You can impliment a dual stack overlay, however it will not be able to take advantage of any native AWS services — even a VPN. You will have to roll your own like it’s 2005.
Where We Are Now — August 2016
Elastic Load Balancers — A load balancer deployed in the legacy EC2-Classic mode can support IPv6, sort of. The ELB can be reached via IPv6 using a DNS lookup — you don’t assign it an IP. Also, AWS can provide 3 FQDN to access the ELB: One for IPv4, one for IPv6, and one for IPv6 dualstack. I’ve found that the dualstack address works much more reliably. Regardless, the ELB will communicate with the backend EC2 instances using IPv4 only.
Interestingly enough, EC2-Classic networking has not seen any sort of feature progression in years. What we have seen is a number of migration features to move you from EC2-Classic to the VPC Networking mode. Newer accounts don’t have EC2-Classic mode enabled at all, you will have to enter a support ticket to obtain it.
Regardless of EC2-Classic’s future, if you want an AWS supported/maintained ingress/egress to for IPv6, you would use an ELB in that mode, and configure it for dualstack support.
Virtual Private Cloud (VPC) — There is no support for IPv6 natively in the VPC services. There is nothing stopping you from implimenting an overlay network however. The downside here is that the native AWS services can not interact with the IPv6 protocol, so your IPv6 traffic is largely “trapped” inside of the VPC, unless you build some sort of self run proxy or egress to allow it to traverse the VPC.
That said, if you issue a “show status tunnel” command on a VPC Virtual Private Network (VPN) tunnel, you will see a IPv6 counter on the rec/xmit stats. I’m hoping this means that there is at least a stubbing for IPv6 support here, however that is 100% speculation on my part.
S3 — Some good news here, finally! As of this month, you can access your S3 buckets and objects via IPv6 using the dualstack URL. You access the bucket using one of the two URL formats for S3:
All regions (even GovCloud!!) are supported, except Beijing/China. A few features gotchas here, but not too bad for a version 1 release of the feature:
· S3 Features — Most features are supported except Static Website Hosting, S3 Transfer Acceleration, and BitTorrent Support. Not supporting S3 Transfer Acceleration makes sense, since that feature works hand-in-hand with CloudFront.
· Policy Changes — Your IAM and Bucket Policies will need to be modified to enumerate IPv6 addressing, if you wish to allow or deny it once you’ve set up your dual stack access.
Route 53 — AWS Hosted DNS supports AAAA and PTR records for EXTERNAL resolution. No movement here since 2011, sadly.
My Wish List
The S3 support is a great place to start, but besides full EC3 and VPC support, I’d love to see IPv6 support within the CloudFront service line. Being a realist, if I can wrap the consumption of my services in IPv6, then I can continue to wait a little bit for “real” support.