IPv6 support or alternative for aws vpc instances

Solution 1:

Unfortunately AWS has been severely neglecting meaningful IPv6 support. Their "solution", if you can call it that, is to throw a non-VPC ELB in front of your application. For many reasons that is a non-tenable solution for many use cases.

As a stopgap fix, the tactic I've seen used by several organizations is to stand up an IPv6-capable VPS with another provider, point the AAAA record there, and then use haproxy or another similar software package to proxy requests to your IPv4 infrastructure. Yes, this is a really awkward and admittedly broken way of doing things, but until AWS releases meaningful IPv6 support, there aren't all that many other options.

Edit:

Regarding Craig's assertion that all ELBs (VPC or otherwise) have IPv6 addresses. Yes, that is correct, but in my testing, and in discussions with other AWS experts, the ELBs don't actually listen on those IPs for traffic. My guess is that enabling IPv6 on the ELBs as they've done is a first step towards offering full IPv6 support at some point. My suspicion is that they will make an announcement about this during or right before their re:Invent conference the first week of December 2016.

Solution 2:

You can create IPv6 records for your ELB by prepending ipv6. to your ELB's public hostname.

Hostnames and IPs redacted due to it being a customer environment - this is in the eu-west-1 region in a non-default VPC.

[email protected]:~$ dig AAAA ipv6.blah-0000000000.eu-west-1.elb.amazonaws.com +short
2a01:xxx:3::xxx:3314
2a01:xxx:3::xxx:ff14
2a01:xxx:3::xxx:7f20

[email protected]:~$ dig A blah-0000000000.eu-west-1.elb.amazonaws.com +short
54.xxx.xxx.xxx
52.xxx.xxx.xxx
54.xxx.xxx.xxx

Note that you can also use the dualstack prefix to return both A and AAAA records for your ELB.


Solution 3:

In us-east I use an IPv6 tunnel broker to provide an IPv6 tunnel which allows the instance to be addressed directly using an IPv6 address. Since the tunnel broker's point of presence is cross-connected to Amazon locally, this adds only about 1ms of latency.

The down side is that, to get IPv6 to other instances in the subnet, you have to route it yourself (e.g. with radvd).


Solution 4:

Came across an interesting article (published 1 December 2016).

https://aws.amazon.com/about-aws/whats-new/2016/12/announcing-internet-protocol-version-6-support-for-ec2-instances-in-amazon-virtual-private-cloud/

You can enable IPv6 on VPC's in the "Ohio" region.


Solution 5:

Put CloudFlare in front of your application. They will accept requests on IP6 but route traffic to your IP4 ELB.