AWS Elastic IP architecture

Hugo Slabbert hugo at slabnet.com
Mon Jun 1 16:21:44 UTC 2015


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

Why?  Honestly: why would you want to abstract v6 up into the application 
layer rather than just having the network address and address family 
visible right at the network layer?  

>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 
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 
necessitates having application-/protocol-specific methods for extracting 
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 
protocol-/application-specific means to extract network-layer information 
out of the application layer, and will also eventually require your 
application to do this with native v6 addresses down the line as well (i.e.  
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 at gmail.com> wrote:

>On Mon, Jun 1, 2015 at 11:41 AM, Tony Hain <alh-ietf at tndh.net> wrote:
>>
>>
>>> -----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?
>
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150601/7a525e50/attachment.sig>


More information about the NANOG mailing list