[180326] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 1 03:09:33 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAL9jLaYKwBt8XqjU9ikci1iXYeK-CkUpFx3dSiZtX=d7zKnm0Q@mail.gmail.com>
Date: Mon, 1 Jun 2015 00:06:18 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On May 31, 2015, at 7:46 PM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
>=20
> On Sun, May 31, 2015 at 9:07 PM, Owen DeLong <owen@delong.com> wrote:
>> As I said before:
>>=20
>> Host Virtual (vr.org <http://vr.org/>)
>> Softlayer (softlayer.com <http://softlayer.com/>)
>> Linode (Linode.com <http://linode.com/>)
>>=20
>> All have full dual-stack support.
>=20
> <snip>
>=20
>>> At the risk of feeding the troll...
>>>=20
>>> This isn't just an AWS problem.
>=20
> 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=E2=80=99?
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=E2=80=99s hard to imagine how you could provide the first one above =
without having this one come along for the ride.
>=20
> 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=E2=80=99t get the first one, this might be adequate as a =
short-term fallback for some applications. However, it=E2=80=99s 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=E2=80=99s the thing=E2=80=A6 In order to land IPv6 services without =
IPv6 support on the VM, you=E2=80=99re 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=3DFALSE 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=E2=80=99t really think so.
Owen
