AWS Elastic IP architecture

Mon Jun 1 17:49:09 UTC 2015

On 6/1/2015 12:06 AM, Owen DeLong wrote:
> ... Here’s the thing… In order to land IPv6 services without IPv6 
> support on the VM, you’re creating an environment where...

Let's hypothetically say that it is much easier for the cloud provider 
if they provide just a single choice within their network, but allow 
both v4 and v6 access from the outside via a translator (to whichever 
one isn't native internally).

Would you rather have:
1) An all-IPv6 network inside, so the hosts can all talk to each other 
over IPv6 without using (potentially overlapping copies of) RFC1918 
space... but where very little of the open-source software you build 
your services on works at all, because it either doesn't support IPv6 or 
they put some IPv6 support in but it is always lagging behind and the 
bugs don't get fixed in a timely manner. Or,

2) An all-IPv4 network inside, with the annoying (but well-known) use of 
RFC1918 IPv4 space and all your software stacks just work as they always 
have, only now the fraction of users who have IPv6 can reach them over 
IPv6 if they so choose (despite the connectivity often being worse than 
the IPv4 path) and the 2 people who are on IPv6-only networks can reach 
your services too.

Until all of the common stacks that people build upon, including 
distributed databases, cache layers, web accelerators, etc. all work 
*better* when the native environment is IPv6, everyone will be choosing #2.

And both #1 and #2 are cheaper and easier to manage that full dual-stack 
to every single host (because you pay all the cost of supporting v6 
everywhere with none of the savings of not having to deal with the 
ever-increasing complexity of continuing to use v4)

Matthew Kaufman