> On May 31, 2015, at 7:46 PM, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>
> On Sun, May 31, 2015 at 9:07 PM, Owen DeLong <o...@delong.com> wrote:
>> As I said before:
>>
>> Host Virtual (vr.org <http://vr.org/>)
>> Softlayer (softlayer.com <http://softlayer.com/>)
>> Linode (Linode.com <http://linode.com/>)
>>
>> All have full dual-stack support.
>
> <snip>
>
>>> At the risk of feeding the troll...
>>>
>>> This isn't just an AWS problem.
>
> So... ok. What does it mean, for a customer of a cloud service, to be
> ipv6 enabled?
It means that I should be able to develop my cloud application(s) with full
native IPv6 support and expect to be able to serve IPv4-only, IPv6-only, and
dual-stack customers using native IP stacks on my virtual machines without
requiring external proxies, translators, etc. from the cloud service provider.
> What really matters for a cloud service user? What information could
> be surfaced to the cloud providers in order to get the most important
> ipv6 'stuff' done 'now’?
Ideally, simple native routing of IPv6 to provisioned hosts should suffice in
most cases.
> o Is it most important to be able to address ever VM you create with
> an ipv6 address?
Yes.
> o Is it most important to be able to talk to backend services (perhaps
> at your prem) over ipv6?
It’s hard to imagine how you could provide the first one above without having
this one come along for the ride.
>
> 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?
This would be the one where I would most be able to tolerate a delay.
> o Is it most important to be able to terminate ipv6 connections (or
> datagrams) on a VM service for the public to use?
If you can’t get the first one, this might be adequate as a short-term fallback
for some applications. However, it’s far from ideal and not all that useful.
> 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.
Here’s the thing… In order to land IPv6 services without IPv6 support on the
VM, you’re creating an environment where:
1. The services basically have to be supported by some form of
proxy/nat/etc.
So long as you are using a supported L4 protocol, that might be
fine, but not everything fits in TCP/UDP/ICMP.
Generally supporting GRE, IKE, and application-specific
protocols becomes an issue.
2. The developer has to develop and maintain an IPv4-compatible
codebase rather than be able to use
the dual stack capabilities of a host with IPV6_V6ONLY=FALSE in
the socket options. This delays the
ability to produce native IPv6 applications.
3. Proxies and translators add complexity, increase fragility, and
reduce performance.
> 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?
For the reasons outlined above, I don’t really think so.
Owen
