Re: AWS Elastic IP architecture

[Owen DeLong <owen () delong com>]

> On May 31, 2015, at 7:46 PM, Christopher Morrow <morrowc.lists () gmail com> wrote:
>
> On Sun, May 31, 2015 at 9:07 PM, Owen DeLong <owen () 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