[180371] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Lee Howard)
Mon Jun 1 16:27:09 2015
X-Original-To: nanog@nanog.org
Date: Mon, 01 Jun 2015 16:25:06 -0400
From: Lee Howard <Lee@asgard.org>
To: Matthew Kaufman <matthew@matthew.at>, <nanog@nanog.org>
In-Reply-To: <556C9B15.7010403@matthew.at>
Errors-To: nanog-bounces@nanog.org
On 6/1/15, 1:49 PM, "Matthew Kaufman" <matthew@matthew.at> wrote:
>On 6/1/2015 12:06 AM, Owen DeLong wrote:
>> ... Here=B9s the thing=8A In order to land IPv6 services without IPv6
>> support on the VM, you=B9re 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.
=B3fraction=B2 is nearly 1/5 in the U.S., and growing fast:
https://www.vyncke.org/ipv6status/project.php
I don=B9t know your source for =B3often being worse,=B2 but I have several
sources saying, =B3lower latency.=B2 (see NANOG60, IPv6 Performance Panel, and
see Facebook=B9s 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 =B3everyone.=B2
>
>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
>
>
