AWS Elastic IP architecture
Hugo Slabbert
hugo at slabnet.com
Tue Jun 2 04:44:11 UTC 2015
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.sig>
More information about the NANOG
mailing list