AWS Elastic IP architecture

Mon Jun 1 14:23:53 UTC 2015

On Mon, Jun 1, 2015 at 1:19 AM, Matt Palmer <mpalmer at hezmatt.org> wrote:
> On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote:
>> So... ok. What does it mean, for a customer of a cloud service, to be
>> ipv6 enabled?
>
> IPv6 feature-parity with IPv4.
>
> My must-haves, sorted in order of importance (most to least):
>
>> o Is it most important to be able to terminate ipv6 connections (or
>> datagrams) on a VM service for the public to use?
>>

and would a headerswapping 'proxy' be ok? there's (today) a 'header
swapping proxy' doing 'nat' (sort of?) for you, so I imagine that
whether the 'headerswapping' is v4 to v4 or v6 to v4 you get the same
end effect: "People can see your kitten gifs".

>> o Is it most important to be able to address every VM you create with
>> an ipv6 address?

why is this bit important though? I see folk, I think, get hung up on
this, but I can't figure out WHY this is as important as folk seem to
want it to be?

all the vms have names, you end up using the names not the ips... and
thus the underlying ip protocool isn't really important? Today those
names translate to v4 public ips, which get 'headerswapped' into v4
private addresses on the way through the firehedge at AWS. Tomorrow
they may get swapped from v6 to v4... or there may be v6 endpoints.

>> o Is it most important to be able to talk to backend services (perhaps
>> at your prem) over ipv6?
>
> If, by "backend services", you mean things like RDS, S3, etc, this is in the
> right place.
>

I meant 'your oracle financials installation at $HOMEBASE'. Things
like 'internal amazon services' to me are a named endpoint and:
  1) the name you use could be resolving to something different than
the external view
  2) it's a name not an ip version... provided you have the inny and
it's an outy, I'm not sure that what ip protocol you use on the
RESTful request matters a bunch.

>> 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?
>>
>> 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.
>
> Being able to address VMs over IPv6 (and have VMs talk to the outside world
> over IPv6) is *really* useful.  Takes away the need to NAT anything.

but the nat isn't really your concern right (it all happens magically
for you)? presuming you can talk to 'backend services' and $HOMEBASE
over ipv6 you'd also be able to make connections to other v6 endpoints
as well. there's little difference REALLY between v4 and v6 ... and
jabbing a connection through a proxy to get v6 endpoints would work
'just fine'. (albeit protocol limitations at the higher levels could
be interesting if the connection wasn't just 'swapping headers')

>> 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?
>
> No.  I'm currently building an infrastructure which is entirely v6-native
> internally; the only parts which are IPv4 are public-facing incoming service
> endpoints, and outgoing connections to other parts of the Internet, which
> are proxied.  Everything else is talking amongst themselves entirely over
> IPv6.

that's great, but I'm not sure that 'all v6 internally!' matters a
whole bunch? I look at aws/etc as "bunch of goo doing
computation/calculation/storage/etc" with some public VIP (v4, v6,
etc) that are well defined and which are tailored to your userbase's
needs/abilities.

You don't actually ssh to 'ipv6 literal' or 'ipv4 literal', you ssh to
'superawesome.vm.mine.com' and provide http/s (or whatever) services
via 'external-service-name.com'. Whether the 1200 vms in your private
network cloud are ipv4 or ipv6 isn't important (really) since they
also talk to eachother via names, not literal ip numbers. There isn't
NAT that you care about there either, the name/ip translation does the
right thing (or should) such that 'superawesome.vm.availzone1.com' and
'superawesome.vm.availzone2.com' can chat freely by name without
concerns for underlying ip version numbers used (and even without
caring that 'chrissawesome.vm.availzone1.com' is 10.0.0.1 as well.