On 6/1/15, 1:49 PM, "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, > >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. ³fraction² is nearly 1/5 in the U.S., and growing fast: https://www.vyncke.org/ipv6status/project.php I don¹t know your source for ³often being worse,² but I have several sources saying, ³lower latency.² (see NANOG60, IPv6 Performance Panel, and see Facebook¹s numbers from World IPv6 Congress). > >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. For certain values of ³everyone.² > >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) I agree with that. Lee > >Matthew Kaufman > >
