[196132] in North American Network Operators' Group
Re: RFC 1918 network range choices
daemon@ATHENA.MIT.EDU (Steve Feldman)
Fri Oct 6 04:12:54 2017
X-Original-To: nanog@nanog.org
From: Steve Feldman <feldman@twincreeks.net>
In-Reply-To: <CAP-guGWkeAzRXbxGtmAf5-4zj=dN9aQtG3NTqW8RGwq4PDzC2Q@mail.gmail.com>
Date: Thu, 5 Oct 2017 16:52:54 -0700
To: William Herrin <bill@herrin.us>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Oct 5, 2017, at 4:14 PM, William Herrin <bill@herrin.us> wrote:
>=20
> On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe <jerry@jtcloe.net> wrote:
>=20
>> Several years ago I remember seeing a mathematical justification for =
it,
>> and I remember thinking at the time it made a lot of sense, but now I =
can't
>> find it.
>>=20
>=20
> Hi Jerry,
>=20
> If there's special ASIC-friendly math here, beyond what was later
> generalized with CIDR, it's not obvious.
>=20
> 10.0: 0000 1010 0000 0000
>=20
> 172.16: 1010 1100 0001 0000
>=20
> 172.31: 1010 1100 0001 1111
>=20
> 192.168: 1100 0000 1010 1000
>=20
> AFAIK, it was simply one range each from classes A, B and C.
As mentioned in one of the links posted earlier, 10.0.0.0/8 was the =
original ARPANET class A assignment. (See RFC 970, which brings back a =
lot of memories.) Once the ARPANET was shut down in 1990 that block was =
no longer used, so it became available for reuse in RFC1918.
I have a vague recollection of parts of 192.168.0.0/16 being used as =
default addresses on early Sun systems. If that's actually true, it =
might explain that choice.
Steve
