Does anyone have a pointer to an *authoritative* source on why
10/8
172.16/12 and
192.168/16
were the ranges chosen to enshrine in the RFC? Came up elsewhere, and I can't
find a good citation either.
To list or I'll summarize.
Cheers,
-- jra
The answer seems to be "no, Jon's not answering his email anymore".
This seems semi-authoritative, though, and probably as close as we're
going to get:
Thanks, Akshay.
Cheers,
-- jra
You might get a better answer over on the internet-history list. Lots
of people are still around that could probably shed some light on it.
<http://www.postel.org/internet-history/>
John
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.
I think the goal was to make it easier for routers to dump private ranges based on simple binary math, but not sure that concept ever got widely used.
Time to start writing out all the binary.
I have seen a number of versions of that in reading things people sent me and things I found myself, and all of them seem to depend on ASICs that didn't exist at the time the ranges were chosen, and probably also CIDR which also didn't exist. They sound good, but I'm not buying em. 
Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the
times and still calling stuff class A/B/C. (Such nonsense persisted well into
this century). Check the dates...
1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz,
D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format:
TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761)
(Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI:
10.17487/RFC1918)
1517 Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R.
Hinden. September 1993. (Format: TXT=7357 bytes) (Status: HISTORIC)
(DOI: 10.17487/RFC1517)
1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T.
Li. September 1993. (Format: TXT=72609 bytes) (Status: HISTORIC)
(DOI: 10.17487/RFC1518)
1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan.
September 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338)
(Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC1519)
1520 Exchanging Routing Information Across Provider Boundaries in the
CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format:
TXT=20389 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1520)
The concept of using a number-of-bits to describe
what is now called CIDR existed as early as 1987:
http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8706.mm.www/0011.html
- Brian
The answer seems to be "no, Jon's not answering his email anymore".
jon was not a big supporter of rfc1918
[snip]
To be fair, the actual formal allocation was 1994 with rfc1597.
1918 was the reconciliation of 1597 and 1627 (ISTR the division
was also why we saw 1796 and 1814).
The practice had been used for a while before the codification
but I don't have a good citation. IAB minutes of 1992 speak of
the practice and the tut-tutting of not wanting people to do
it, but not citing specific numbers and math.
Cheers!
Joe
Hi Jerry,
If there's special ASIC-friendly math here, beyond what was later
generalized with CIDR, it's not obvious.
10.0: 0000 1010 0000 0000
172.16: 1010 1100 0001 0000
172.31: 1010 1100 0001 1111
192.168: 1100 0000 1010 1000
AFAIK, it was simply one range each from classes A, B and C.
Regards,
Bill Herrin
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
192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation.
That's what i recall too. For some reason i thought it was hp, but that could easily be wrong.
Mike
Well,
Some HP unixes, and documentation, still uses 192\.1\.1\.x\.
Hey free publicity for BBN\.
I have a client still using 192\.1\.10/24 just because of it\. Been 4 years and they still won't change it :\(Which part? The allocation of the addresses or the security model (section
2, 4 & 5)?
Note: Very few system, network, or security professionals have even read
anything besides section 3, the private address allocation. Could be why
we have some many compromises --- just saying.
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8
Interesting you call sections 2,4,5 a security model when section 6 explicitly states "Security issues are not addressed in this memo.”
Sections 2, 4, and 5 are motivational and design considerations. Using RFC1918 space is not and should not be considered a security practice.
/Ryan
Ryan Harden
Research and Advanced Networking Architect
University of Chicago - ASN160
P: 773.834.5441
I recall 192.9.200.X being used both in documentation and in default system configurations.
Owen
(Former) Sun Employee #10056
The RFC explains the reason why we chose three ranges from "Class A,B &
C" respectively: CIDR had been specified but had not been widely
implemented. There was a significant amount of equipment out there that
still was "classful".
As far as I recall the choice of the particular ranges were as follows:
10/8: the ARPANET had just been turned off. One of us suggested it and
Jon considered this a good re-use of this "historical" address block. We
also suspected that "net 10" might have been hard coded in some places,
so re-using it for private address space rather than in inter-AS routing
might have the slight advantage of keeping such silliness local.
172.16/12: the lowest unallocated /12 in class B space.
192.168/16: the lowest unallocated /16 in class C block 192/8.
In summary: IANA allocated this space just as it would have for any
other purpose. As the IANA, Jon was very consistent unless there was a
really good reason to be creative.
Daniel (co-author of RFC1918)
If I recall correctly not one of the authors was a "big supporter". Some
things are not full of beauty and glory; yet they have to be done.
I recall a number of conversations with Jon about this, at least one of
them face-to-face. I am convinced he fully agreed that it was necessary.
Daniel