AWS Elastic IP architecture

Owen DeLong owen at delong.com
Tue Jun 2 09:12:27 UTC 2015


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




More information about the NANOG mailing list