|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org In-Reply-To: <CAD6AjGTJQpwP26uK912BREBv8f-a9-ap=eA73cFu94HD8ZDT=A@mail.gmail.com> From: Todd Underwood <toddunder@gmail.com> Date: Mon, 1 Jun 2015 14:43:27 -0400 To: Ca By <cb.list6@gmail.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org fb is not a 'cloud provider'. it's orthogonal to the question. t On Mon, Jun 1, 2015 at 2:36 PM, Ca By <cb.list6@gmail.com> wrote: > On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman <matthew@matthew.at> > wrote: > > > On 6/1/2015 12:06 AM, Owen DeLong wrote: > > > >> ... Here=E2=80=99s the thing=E2=80=A6 In order to land IPv6 services w= ithout IPv6 > support > >> on the VM, you=E2=80=99re 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 yo= ur > > services on works at all, because it either doesn't support IPv6 or the= y > > 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.htm= l > > > > > > 2) An all-IPv4 network inside, with the annoying (but well-known) use o= f > > RFC1918 IPv4 space and all your software stacks just work as they alway= s > > 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-stac= k > > 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 > > > > >
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |