AWS Elastic IP architecture

Mon Jun 1 15:30:00 UTC 2015

On Mon, Jun 1, 2015 at 3:06 AM, Owen DeLong <owen at delong.com> wrote:
>
>> 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.
>

Ok, I suppose as a long term goal that seems fine. I don't get why
'ipv6 address on my vm' matters a whole bunch (*in a world where v4 is
still available to you I mean), but as a long term goal, sure fine.

In the short term though, that was my question: "What should be
prioritized, and then get that information to aws/gce/rackspace/etc
product managers" because I suspect their engineers are not silly,
they know that v6 should be part of the plan... but the PM folk are
saying: "No one is asking for this v6 thing, but lots of people want
that other shiney bauble...so build the shiney!!"

>> 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.
>

long term sure, short term though.. really?? isn't it more important
to be able to terminate v6 services from 'public' users? (and v4 as
well because not everyone has v6 at home/work/mobile)

>> 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 agree it's not ideal, and I was making a list of 'short term goals'
that could be prioritized and get us all to the v6 utopia later.

>> 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.
>

I figured the simplest path from v6 to v4 was: "Rip the header and
extension headers off, make a v4 packet, deliver to vm"

aside from "yes, your request came from <ipv6 literal>" that should
'just work', you do have to maintain some state to deliver back,
depending on the implementation (but even that is probably able to be
hidden from the 'user' and provisioned/capacity planned independent of
the 'user').

>         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.
>

I think this point is cogent, but ... also part of the pie that 'aws'
pays for you the user... Or rather they run a 'service' which takes
care of this, has slas and slos...
   "All packets delivered with 99.99% having Xms extra latency!"
   "Service has 99.999% uptime!"
   "Throughput comparable (99.99% at peak, 99% of the time) to
straight/native v4"

>> 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.

ok, I figured that for short-term while the providers figure out: "Oh
yea, this v6 thing is pretty simple in our encap'd world... why didn't
we just turn it on originally?"

getting v6 endpoints with little hassle for the 'user' (vm user) would
help us all a bunch.