[180345] in North American Network Operators' Group
RE: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Tony Hain)
Mon Jun 1 11:44:57 2015
X-Original-To: nanog@nanog.org
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Christopher Morrow'" <morrowc.lists@gmail.com>,
"'Matt Palmer'" <mpalmer@hezmatt.org>
In-Reply-To: <CAL9jLabepzMeci=FM4-d8g72eH5QACqJ3Reu_TWGx6yTSyLAwg@mail.gmail.com>
Date: Mon, 1 Jun 2015 08:41:11 -0700
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Cc: 'nanog list' <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> -----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
>=20
> 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?
> >>
>=20
> 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".
>=20
> >> o Is it most important to be able to address every VM you create =
with
> >> an ipv6 address?
>=20
> 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?
>=20
> 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.
>=20
> >> 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.
> >
>=20
> 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.
>=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?
> >>
> >> 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.
>=20
> 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')
>=20
> >> 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.
>=20
> 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.
>=20
> 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?=20
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.=20
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.=20
Tony
