AWS Elastic IP architecture

Mon Jun 1 15:41:11 UTC 2015

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
> Christopher Morrow
> Sent: Monday, June 01, 2015 7:24 AM
> To: Matt Palmer
> Cc: nanog list
> Subject: Re: AWS Elastic IP architecture
> 
> 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.

Look at the problem in the other direction, and you will see that addresses often matter. What if you want to deny ssh connections from a particular address range? The source isn't going to tell you the name it is coming from. What if you want to deploy an MTA on your VM and block connections from SPAM-A-LOT data centers? How do you do that when the header-swap function presents useless crap from an external proxy mapping function? 

That said, if you double nat from the vip to the stack in a way that masks the internal transport of the service (so that a native stack on the VM behaves as if it is directly attached to the outside world), then it doesn't matter what the service internal transport is. 

What I read in your line of comments to Owen is that the service only does a header swap once and expects the application on the VM to compensate. In that case there is an impact on the cost of deployment and overall utility. 

Tony