[178282] in North American Network Operators' Group
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Feb 24 12:44:49 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAD6AjGQOzCYdp8_XYtPbmwh9gqSAcB54YbOj0hEsL-pgx=C7zA@mail.gmail.com>
Date: Tue, 24 Feb 2015 09:35:13 -0800
To: Ca By <cb.list6@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@gmail.com> wrote:
>=20
> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgermann@cctec.com> =
wrote:
>=20
>> Currently engaged on a project where they=E2=80=99re building out a =
VPC
>> infrastructure for hosted applications.
>>=20
>> Users access apps in the VPC, not the other direction.
>>=20
>> 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.
>>=20
>> Initially, I was looking at doing something like (example IP=E2=80=99s)=
:
>>=20
>>=20
>> 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)
>>=20
>> 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).
>>=20
>>=20
>> 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
>>=20
>> 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 =
appear to be
>> able to do.
>>=20
>> I prototyped this up over the weekend with multiple VPC=E2=80=99s in =
multiple
>> regions and it =E2=80=9Cappears=E2=80=9D to work fine.
>>=20
>> =46rom the operator community, what are the downsides?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Thoughts and thanks in advance.
>>=20
>> Eric
>>=20
>=20
> Wouldn't it be nice if Amazon supported IPv6 in VPC?
>=20
> 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.
>=20
> I suggest you go with private cloud if possible.
>=20
> Or, you can double NAT non-unique IPv4 space.
>=20
> 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.
>=20
> CB
