Re: AWS Elastic IP architecture

[Owen DeLong <owen () delong com>]

> On Jun 1, 2015, at 6:49 PM, Matthew Kaufman <matthew () matthew at> wrote:
>
> 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,

Yes.

For one thing, if AWS did this, the open source software would very quickly catch up and IPv4 would be the stack no 
longer getting primary maintenance in that software.

Additionally, it’s easy for me to hide an IPv4 address in a translated to IPv6 packet header. Not so much the other way 
around.


> 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.

There are a lot more than 2 people on IPv6-only networks at this point. Most T-Mobile Droid users, for example are on 
an IPv6-only network at this time. True, T-Mo provides 464Xlat services for those users (which is why T-Mo doesn’t work 
for iOS users), but that’s still an IPv6-only network.

> 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.

To the best of my knowledge, Postgress, MySQL, Oracle, NoSQL all support IPv6.
Squid and several other caches have full IPv6 support.

We don’t even need better… We just need at least equal.

However, if, instead of taking a proactive approach and deploying IPv6 in a useful way prior to calamity you would 
rather wait until the layers and layers of hacks that are increasingly necessary to keep IPv4 alive reach such a 
staggering proportion that no matter how bad the IPv6 environment may be, IPv4 is worse, I suppose that’s one way we 
can handle the transition.

Personally, I’d rather opt for #1 early and use it to drive the necessary improvements to the codebases you mentioned 
and probably some others you didn’t.

> 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)

Sure, sort of. You actually do get some savings with dual-stack because you reduce the cost and the rate at which the 
iPv4 complexity continues to increase. You also reduce the time before you’ll be able to fully deprecate IPv4 and the 
amount of additional capital that has to be expended hacking, cobbling, and otherwise creating cruft for the sole 
purpose of keeping IPv4 alive and somewhat functional.


Owen