On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman <matt...@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, > Facebook selected IPv6-only as outlined above http://blog.ipspace.net/2014/03/facebook-is-close-to-having-ipv6-only.html > > 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 > >
