Re: AWS Elastic IP architecture

[Christopher Morrow <morrowc.lists () gmail com>]

On Mon, Jun 1, 2015 at 11:41 AM, Tony Hain <alh-ietf () tndh net> wrote:
> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces () 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 () 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?

this sounds like a manage-your-vm question... keep that on v4 only
until native v6 gets to your vm. (short term vs long term solution
space)


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

yup, 'not http' services are harder to deal with in a 'swap headers' world.

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

I was mostly envisioning this, but the header-swap seems easy for a
bunch of things (to me at least).

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

'compensate' ? do you mean 'get some extra information about the real
source address for further policy-type questions to be answered' ?

I would hope that in the 'header swap' service there's as little
overhead applied to the end system as possible... I'd like my apache
server to answer v6 requests without having a v6
address-listening-port on my machine. For 'web' stuff
'X-forwarded-for' seems simple, but breaks for https :(

Oh, so what if the 'header swap' service simply shoveled the v6 into a
gre (or equivalent) tunnel and dropped that on your doorstep?
potentially with an 'apt-get install aws-tunnelservice'  ? I would bet
in the 'vm network' you could solve a bunch of this easily enough, and
provide a v6 address inside the tunnel on the vm providing the
services.

loadbalancing is a bit rougher (more state management) but .. is doable.

-chris