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

[patrick at ianai.net (Patrick W. Gilmore)]

I personally find it amusing that companies try to have it both ways.

"We are huge, you should use us instead of $LITTLE_GUY because our resources & scale make us better able to handle things. Oh, what, you want IPv6? We're too big to do that quickly...."

But hey, I would try the same thing in their position.

-- 
TTFN,
patrick

> On Feb 24, 2015, at 13:15 , Ca By <cb.list6 at gmail.com> wrote:
> 
> On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper <blair.trosper at gmail.com>
> wrote:
> 
>> I have an unimpeachable source at AWS that assures me they're working hard
>> to deploy IPv6.  As it was explained to me, since AWS was sort of first to
>> the table -- well before IPv6 "popped", they had designed everything on the
>> v4 only.  Granted, you can get an IPv6 ELB, but only in EC2 classic, which
>> they're phasing out.
>> 
>> But I'm assured they're rushing IPv6 deployment of CloudFront and other
>> services as fast as they can.  I'm assured of this.
>> 
>> 
> talk is cheap.  I suggest people use Cloudflare or Akamai for proper IPv6
> CDN reach to major IPv6 eyeball networks at AT&T, Verizon, Comcast, and
> T-Mobile US -- all of which have major ipv6 deployments
> 
> http://www.worldipv6launch.org/measurements/
> 
> 
> 
> 
>> But you also have to appreciate the hassle of retrofitting a cloud
>> platform of that scale, so I do not envy the task that AWS is undertaking.
>> 
>> 
> work is hard
> 
> 
>> On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>>> 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
>>> 
>>> 
>>