AWS Elastic IP architecture

Mon Jun 1 07:06:18 UTC 2015

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