[180348] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Mon Jun 1 12:21:54 2015
X-Original-To: nanog@nanog.org
Date: Mon, 1 Jun 2015 09:21:44 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAL9jLaZz7XuiWF0X+d_AYCJW1JU4U4A=TM8Qt31RhFXD2u7SNg@mail.gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--vk/v8fjDPiDepTtA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>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.=20
Why? Honestly: why would you want to abstract v6 up into the application=
=20
layer rather than just having the network address and address family=20
visible right at the network layer? =20
>For 'web' stuff 'X-forwarded-for' seems simple, but breaks for https :(
Which is an example of why people are pushing to just do the network layer=
=20
stuff in the network layer, rather than pushing it up the stack.
>'compensate' ? do you mean 'get some extra information about the real
>source address for further policy-type questions to be answered' ?
Hopefully without speaking for someone else, but probably yes. It also=20
necessitates having application-/protocol-specific methods for extracting=
=20
that information (e.g. the X-forwarded-for you cited). So the options are:
1. Go with the header-swap-type setup you describe, which requires=20
protocol-/application-specific means to extract network-layer information=
=20
out of the application layer, and will also eventually require your=20
application to do this with native v6 addresses down the line as well (i.e.=
=20
do a bunch of work now only to have it redo it later).
or
2. Just do it properly the first time around.
I would opt for #2.
--
Hugo
On Mon 2015-Jun-01 11:52:15 -0400, Christopher Morrow <morrowc.lists@gmail.=
com> wrote:
>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 wheth=
er 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 t=
his, 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 t=
hus
>>> 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 anyt=
hing.
>>>
>>> but the nat isn't really your concern right (it all happens magically f=
or 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 whol=
e 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 netwo=
rk
>>> 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 c=
are
>>> about there either, the name/ip translation does the right thing (or sh=
ould)
>>> 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 addres=
ses often matter. What if you want to deny ssh connections from a particula=
r 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 yo=
u want to deploy an MTA on your VM and block connections from SPAM-A-LOT da=
ta centers? How do you do that when the header-swap function presents usele=
ss 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 mas=
ks 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 do=
es 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 utili=
ty.
>
>'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
--vk/v8fjDPiDepTtA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJVbIaYAAoJEJqxD/2xeDE+rn0P/3zlPvP4dEEubzmQ82uRlVBP
HfM1BmbKgsmyNv475HIGvaaoWTnC0fH7vpSbujE4H97KrRKECJvxz7Bh2D4vYsEl
xkrHFnWb2Nh3iemANjPFONPw6QF3R83fQgLh76O0JVCzR7O1FpQnyCsFWlrV9qLi
POus8qYl7HY3nuCMO9JOlpDtP8qdNOb2Wi3Q0KiFU8UVaQtoZaEyK3rDOILhOHJh
8GXj03u/R43S3Dmkt6S6KOLfw6Q+aQ/ojnpynvnsZRAwK0ssgfmcC59WyZDbKiI/
kU+4SF7MsQABKK38aS0vYGLvYYSssdv7gffXfZe5x7kUUi6tfg1P5HgwKptamU4J
PEey0/OHKw0QVHyXWE1RVWf+nb6rWuMa7ZnIyXMzI/W5JF5YtkhOccZ+N8y5PoRC
0GYx0TtzCey+rCrCi0jK7gbO+FndLUj18GarKAcIVjL30YZRMXs1rIpNz2W0HU1U
BLjqFFFGPkIw24jLjNiyHtPQ+9hlCrPDe2PP44ccXTZ7GxiQvSGoIIhQVtPn79Bd
f276TuMw6+KN7NnvrkqBsErTf+ypP0Sm8rw4fy7c1NFAGFXeWfC8hZOZv4NEreQl
so84LIb3rrC/y8Iv6AO/QUxURUwVII1qbRquAeeDM0a6VzfblBwl7OkOqkYPBfLr
ULdeBQkXR+tJmlbzlFSn
=VJn3
-----END PGP SIGNATURE-----
--vk/v8fjDPiDepTtA--
