[178285] in North American Network Operators' Group
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC
daemon@ATHENA.MIT.EDU (Blair Trosper)
Tue Feb 24 13:12:06 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <CAA5Ek4cm2efNPGvXuEdaBGyuSX60j5vfbrF0i9sJORjaAk4kPQ@mail.gmail.com>
Date: Tue, 24 Feb 2015 12:10:14 -0600
From: Blair Trosper <blair.trosper@gmail.com>
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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@gmail.com>
wrote:
> I have an unimpeachable source at AWS that assures me they're working har=
d
> to deploy IPv6. As it was explained to me, since AWS was sort of first t=
o
> the table -- well before IPv6 "popped", they had designed everything on t=
he
> v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, whic=
h
> 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@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@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 V=
PC
>> >> 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 conne=
ct
>> >> have multiple overlapping RFC1918 space (including overlapping what w=
as
>> >> proposed for the VPC networks). Finding a hole that is big enough an=
d
>> not
>> >> in use by someone else is nearly impossible AND the customers could g=
o
>> >> through mergers which make them renumber even more in to overlapping
>> 1918
>> >> space.
>> >>
>> >> Initially, I was looking at doing something like (example IP=E2=80=99=
s):
>> >>
>> >>
>> >> 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=
=9CWhy 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 th=
e
>> 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 ap=
pear to be
>> >> able to do.
>> >>
>> >> 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.
>> >>
>> >> 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 ar=
e
>> 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 wou=
ld
>> >> 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
>>
>>
>
