[178290] in North American Network Operators' Group
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Feb 24 13:27:39 2015
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <CAD6AjGQg17LBvcxyzedidzcR_WVhSpudZxkZqZBUovZYjroHXg@mail.gmail.com>
Date: Tue, 24 Feb 2015 13:22:26 -0500
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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.
--=20
TTFN,
patrick
> On Feb 24, 2015, at 13:15 , Ca By <cb.list6@gmail.com> wrote:
>=20
> On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper =
<blair.trosper@gmail.com>
> wrote:
>=20
>> 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.
>>=20
>> But I'm assured they're rushing IPv6 deployment of CloudFront and =
other
>> services as fast as they can. I'm assured of this.
>>=20
>>=20
> 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
>=20
> http://www.worldipv6launch.org/measurements/
>=20
>=20
>=20
>=20
>> 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.
>>=20
>>=20
> work is hard
>=20
>=20
>> On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong <owen@delong.com> =
wrote:
>>=20
>>> Amazon is not the only public cloud.
>>>=20
>>> There are several public clouds that can support IPv6 directly.
>>>=20
>>> I have done some work for and believe these guys do a good job:
>>>=20
>>> Host Virtual (vr.org <http://vr.org/>)
>>>=20
>>>=20
>>> 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:
>>>=20
>>> Linode
>>> SoftLayer
>>> RackSpace
>>>=20
>>> There are others that I am not recalling off the top of my head.
>>>=20
>>> Owen
>>>=20
>>>> 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=99=
s):
>>>>>=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=9CWhy 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
>>>=20
>>>=20
>>=20
