AWS Elastic IP architecture

[hugo at slabnet.com (Hugo Slabbert)]

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

>On Mon, Jun 1, 2015 at 12:21 PM, Hugo Slabbert <hugo at 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
-------------- 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/59c2ac7f/attachment.pgp>