Re: AWS Elastic IP architecture

[Hugo Slabbert <hugo () slabnet com>]

On Mon 2015-Jun-01 13:20:57 -0400, Christopher Morrow <morrowc.lists () gmail com> wrote:

> On Mon, Jun 1, 2015 at 12:21 PM, Hugo Slabbert <hugo () slabnet com> wrote:
> > 2.  Just do it properly the first time around.
> >
> > I would opt for #2.
>
> sure, so would everyone... but they didn't so... what gets you enough
> there to help customers and also doesn't required a forklift of your
> running operation?

Sorry; I worded this poorly.  Obviously they didn't go dual stack right at 
the outset.  Options #1 and #2 I listed were done from the perspective that 
it's currently a v4-only environment, and some measure of work has to be 
done to get it to have v6 capability of *some* form.

I'm working with the (soon to be not) unspoken assumption of a future state 
of the platform where we've "v6'd all the things", checking off all of the 
boxes in your original message on this; paraphrased:

- Every VM has a v6 address
- VMs can talk to backend services (including on your prem) over v6
- VM/system admin interfaces are reachable over v6
- You can serve up v6-accessible services from your VM(s)

If my (previously unspoken) assumption of a fully v6-capable future state 
of the platform holds, I'm saying that going with a proxy-type solution as 
an interim stopgap solution carries a whole bunch of additional 
labor/operational cost.  Implementing either option #1 or option #2 carries 
some combination of cost from hardware, software, and elbow grease, with 
values of 0 to $bigint in each category.  To be fair: some of the 
additional elbow grease cost from option #1 is externalized from the hoster 
to either customers and/or the developers of the software stacks used by 
customers.  That notwithstanding:  if you're going to need to do #2 at some 
point anyway, why not just skip #1 and put your energy into #2 to start 
with?

To be honest:  I don't think we are diametrically opposed on this.  Backing 
up a bit:

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

Relieve some pressure and possibly generate at least *some* forward 
momentum?  Sure.  And AWS is obviously free to do as they see fit.  I think 
a lot of folks in this discussion are just tired of seeing half measures 
that expend a bunch of resources to delay the inevitable and push us 
further into CGN hell when those resources could rather have been allocated 
to a proper dual-stack or v6-only solution.

--
Hugo

Attachment: signature.asc
Description: Digital signature