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