Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

Tue Feb 24 17:35:13 UTC 2015

Amazon is not the only public cloud.

There are several public clouds that can support IPv6 directly.

I have done some work for and believe these guys do a good job:

Host Virtual (vr.org <http://vr.org/>)

In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following:

Linode
SoftLayer
RackSpace

There are others that I am not recalling off the top of my head.

Owen

> On Feb 23, 2015, at 07:52 , Ca By <cb.list6 at gmail.com> wrote:
> 
> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgermann at cctec.com> wrote:
> 
>> Currently engaged on a project where they’re building out a VPC
>> infrastructure for hosted applications.
>> 
>> Users access apps in the VPC, not the other direction.
>> 
>> The issue I'm trying to get around is the customers who need to connect
>> have multiple overlapping RFC1918 space (including overlapping what was
>> proposed for the VPC networks).  Finding a hole that is big enough and not
>> in use by someone else is nearly impossible AND the customers could go
>> through mergers which make them renumber even more in to overlapping 1918
>> space.
>> 
>> Initially, I was looking at doing something like (example IP’s):
>> 
>> 
>> Customer A (172.28.0.0/24)  <—> NAT to 100.127.0.0/28 <——> VPN to DC <——>
>> NAT from 100.64.0.0/18 <——>  VPC Space (was 172.28.0.0/24)
>> 
>> Classic overlapping subnets on both ends with allocations out of
>> 100.64.0.0/10 to NAT in both directions.  Each sees the other end in
>> 100.64 space, but the mappings can get tricky and hard to keep track of
>> (especially if you’re not a network engineer).
>> 
>> 
>> In spitballing, the boat hasn’t sailed too far to say “Why not use
>> 100.64/10 in the VPC?”
>> 
>> Then, the customer would be allocated a /28 or larger (depending on needs)
>> to NAT on their side and NAT it once.  After that, no more NAT for the VPC
>> and it boils down to firewall rules.  Their device needs to NAT outbound
>> before it fires it down the tunnel which pfSense and ASA’s appear to be
>> able to do.
>> 
>> I prototyped this up over the weekend with multiple VPC’s in multiple
>> regions and it “appears” to work fine.
>> 
>> From the operator community, what are the downsides?
>> 
>> Customers are businesses on dedicated business services vs. consumer cable
>> modems (although there are a few on business class cable).  Others are on
>> MPLS and I’m hashing that out.
>> 
>> The only one I can see is if the customer has a service provider with
>> their external interface in 100.64 space.  However, this approach would
>> have a more specific in that space so it should fire it down the tunnel for
>> their allocated customer block (/28) vs. their external side.
>> 
>> Thoughts and thanks in advance.
>> 
>> Eric
>> 
> 
> Wouldn't it be nice if Amazon supported IPv6 in VPC?
> 
> I have disqualified several projects from using the "public cloud" and put
> them in the on-premise "private cloud"  because Amazon is missing this key
> scaling feature -- ipv6.   It is odd that Amazon, a company with scale
> deeply in its DNA, fails so hard on IPv6.  I guess they have a lot of
> brittle technical debt they can't upgrade.
> 
> I suggest you go with private cloud if possible.
> 
> Or, you can double NAT non-unique IPv4 space.
> 
> Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just
> an augment of RFC1918 and i have already deployed it as such.
> 
> CB