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

Tue Feb 24 18:59:15 UTC 2015

That's sort of what I meant to say.  I did not articulate it well.

The problem *with* AWS is that in VPC (or different regions), the internal
network space is unique to each region.  So, in theory, I could get
10.1.2.3 in two regions on two instances.  In VPC, you can also designate
your own subnets, which makes things a little more tough a la
interconnecting the disparate regions.

But, as you say, IPv6 would be an elegant solution to that problem...and
that's what I meant to articulate.  IPv6 as a region unification tool as
well as an Internet-facing protocol.

On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen <lnguyen at opsource.net> wrote:

> Shouldn't it be the other way around? Ipv6 as the unique universal
> external network and you can define your own IPv4 within your cloud context
> separate from the cloud provider network and from other customers. So if
> you have contexts in different region - you can interconnect using layer 3
> or layer 2 - through the cloud provider network...bring your own IPv4. If
> you need internet access, you'll get NATted. If you need connections to
> your branches/HQs...etc, build your own tunnel or use the cloud provider -
> which by the way gives you your own vrf so no need to worry about
> overlapping anything.
> Noone heard of Dimension Data Cloud? :)
>
> On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper <blair.trosper at gmail.com>
> wrote:
>
>> ADDENDUM:  They're taking into consideration my suggestion of using IPv6
>> as
>> a "universal" internal network so that the different regions could be
>> interconnected without having to give up the region-independent use of
>> 10.0.0.0/8, which I think would be an elegant solution.
>>
>> On Tue, Feb 24, 2015 at 12:08 PM, 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.
>> >
>> > 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.
>> >
>> > 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
>> >>
>> >>
>> >
>>
>
>