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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-... On Thu, Oct 5, 2017 at 10:40 AM, Jay R. Ashworth <jra@baylink.com> wrote:
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
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: https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-... Thanks, Akshay. Cheers, -- jra ----- Original Message -----
From: "jra" <jra@baylink.com> To: "North American Network Operators' Group" <nanog@nanog.org> Sent: Thursday, October 5, 2017 10:40:57 AM Subject: RFC 1918 network range choices
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
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. -----Original message----- From:Jay R. Ashworth <jra@baylink.com> Sent:Thu 10-05-2017 09:41 am Subject:RFC 1918 network range choices To:North American Network Operators‘ Group <nanog@nanog.org>; 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
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. :-) On October 5, 2017 1:32:19 PM EDT, Jerry Cloe <jerry@jtcloe.net> wrote:
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.
-----Original message----- From:Jay R. Ashworth <jra@baylink.com> Sent:Thu 10-05-2017 09:41 am Subject:RFC 1918 network range choices To:North American Network Operators‘ Group <nanog@nanog.org>; 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
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said:
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)
On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletnieks@vt.edu wrote:
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...
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
On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletnieks@vt.edu wrote:
On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said:
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... [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 -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe <jerry@jtcloe.net> wrote:
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.
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 -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Oct 5, 2017, at 4:14 PM, William Herrin <bill@herrin.us> wrote:
On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe <jerry@jtcloe.net> wrote:
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.
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.
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
On Oct 5, 2017, at 4:52 PM, Steve Feldman <feldman@twincreeks.net> wrote:
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.
192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation.
On 10/05/2017 05:14 PM, Lyndon Nerenberg wrote:
On Oct 5, 2017, at 4:52 PM, Steve Feldman <feldman@twincreeks.net> wrote:
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. 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 :( ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 10/05/17 20:14, Lyndon Nerenberg wrote:
On Oct 5, 2017, at 4:52 PM, Steve Feldman <feldman@twincreeks.net> wrote:
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. 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation.
On Oct 5, 2017, at 5:14 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
On Oct 5, 2017, at 4:52 PM, Steve Feldman <feldman@twincreeks.net> wrote:
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.
192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation.
I recall 192.9.200.X being used both in documentation and in default system configurations. Owen (Former) Sun Employee #10056
On 05/10/2017 07:40, Jay R. Ashworth wrote:
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? ...
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)
participants (14)
-
Akshay Kumar -
Alain Hebert -
Brian Kantor -
Daniel Karrenberg -
Jay Ashworth -
Jay R. Ashworth
-
Jerry Cloe -
Joe Provo -
Lyndon Nerenberg -
Michael Thomas -
Owen DeLong -
Steve Feldman -
valdis.kletnieks＠vt.edu -
William Herrin