[178255] in North American Network Operators' Group
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC
daemon@ATHENA.MIT.EDU (Luan Nguyen)
Mon Feb 23 13:10:32 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <CAD6AjGQOzCYdp8_XYtPbmwh9gqSAcB54YbOj0hEsL-pgx=C7zA@mail.gmail.com>
Date: Mon, 23 Feb 2015 10:57:05 -0500
From: "Luan Nguyen" <lnguyen@opsource.net>
To: "Ca By" <cb.list6@gmail.com>
Cc: nanog@nanog.org
Reply-To: luan.nguyen@dimensiondata.com
Errors-To: nanog-bounces@nanog.org
I put lots of these to good use
http://en.wikipedia.org/wiki/Reserved_IP_addresses
Regarding public cloud with ipv6 support, contact me off-list i might even
get you a special discount
On Mon, Feb 23, 2015 at 10:52 AM, Ca By <cb.list6@gmail.com> wrote:
> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgermann@cctec.com> wrote:
>
> > Currently engaged on a project where they=E2=80=99re 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 19=
18
> > space.
> >
> > Initially, I was looking at doing something like (example IP=E2=80=99s):
> >
> >
> > Customer A (172.28.0.0/24) <=E2=80=94> NAT to 100.127.0.0/28 <=E2=80=
=94=E2=80=94> VPN to DC
> <=E2=80=94=E2=80=94>
> > NAT from 100.64.0.0/18 <=E2=80=94=E2=80=94> 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=E2=80=99re not a network engineer).
> >
> >
> > In spitballing, the boat hasn=E2=80=99t sailed too far to say =E2=80=9C=
Why not use
> > 100.64/10 in the VPC?=E2=80=9D
> >
> > 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=E2=80=99s appe=
ar to be
> > able to do.
> >
> > I prototyped this up over the weekend with multiple VPC=E2=80=99s in mu=
ltiple
> > regions and it =E2=80=9Cappears=E2=80=9D 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=E2=80=99m 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
>
