On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: > So... ok. What does it mean, for a customer of a cloud service, to be > ipv6 enabled?
IPv6 feature-parity with IPv4. My must-haves, sorted in order of importance (most to least): > o Is it most important to be able to terminate ipv6 connections (or > datagrams) on a VM service for the public to use? > > o Is it most important to be able to address ever VM you create with > an ipv6 address? > > o Is it most important to be able to talk to backend services (perhaps > at your prem) over ipv6? If, by "backend services", you mean things like RDS, S3, etc, this is in the right place. > o Is it most important that administrative interfaces to the VM > systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be > ipv6 reachable? > > I don't see, especially if the vm networking is unique to each > customer, that 'ipv6 address on vm' is hugely important as a > first/important goal. I DO see that landing publicly available > services on an ipv6 endpoint is super helpful. Being able to address VMs over IPv6 (and have VMs talk to the outside world over IPv6) is *really* useful. Takes away the need to NAT anything. > Would AWS (or any other cloud provider that's not currently up on the > v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service > (perhaps not just http/s services even?) be enough to relieve some of > the pressure on other parties and move the ball forward meaningfully > enough for the cloud providers and their customers? No. I'm currently building an infrastructure which is entirely v6-native internally; the only parts which are IPv4 are public-facing incoming service endpoints, and outgoing connections to other parts of the Internet, which are proxied. Everything else is talking amongst themselves entirely over IPv6. - Matt -- "After years of studying math and encountering surprising and counterintuitive results, I came to accept that math is always reasonable, by my intuition of what is reasonably is not always reasonable." -- Steve VanDevender, ASR