Why did the Internet Engineering Task Force (IETF) choose 192.168/16 to be a private IP address classand not something else?
Why specifically 192.168/16 and 10/8 and 172.16/12 and not 145.243/16 for example?
Is there a reason those IP addresses were chosen to be the standard for private IP addresses over all the other possibilities?
I know who chose these address ranges. Unfortunately, he is dead, so I cannot ask him exactly why he chose them, but I can make some well informed guesses.
There isn't much online dating prior to the mid-1990s, when the Internet really started to take off. What history of the Internet exists is mostly in the RFCs which define it, which date back to 1969, at the start of the ARPANET. Through them you can watch the Internet progress from a fledgling network of a few primitive mainframes, being designed by some of the most brilliant minds of the time, to the network we can hardly imagine living without today.
This answer draws almost entirely from those RFCs, and in small part from my personal experience as I was on the Internet in this era.
First, the IETF did not pick these IP address ranges, or any others. Allocation of special use addresses is currently and has always been the job of the Internet Assigned Numbers Authority.
The IANA has always been a role, rather than a specific organization, and that role has changed hands exactly once. Currently it is held by ICANN, but from 1972 until his death in 1998 when that organization was created to replace him, IANA was essentially one man, Jon Postel. Of course, he first called the role czar of socket numbers, a necessary task he took on himself because it needed to be done. He ended up the czar of virtually every number that could be assigned: addresses, protocol numbers, ports, you name it, largely because he was willing to do it, and by the time the Internet opened to public commerce he had been doing it for over 20 years. He assigned the numbers, and the Internet Registry (then SRI-NIC, this was expanded to a distributed collection of registries worldwide) published them.
The last RFC from SRI showing a list of Internet address assignments was RFC 1166 from 1990. It is a very lengthy list, so it should not be surprising that this data was moved to online databases. Comparing it to its predecessor RFC 1117 shows the rate of expansion of the Internet even then, years before it opened to the public.
So, now we are in a position to understand the address ranges in RFC 1918 a little better. This is actually the second revision of the RFC; the first was RFC 1597, published almost two years earlier in March 1994. In its little-known rebuttal, RFC 1627, the contemporary arguments against private address spaces were laid out. RFC 1627 also happens to mention who assigned the three address spaces.
They were assigned by IANA, that is, Jon Postel, at the request of the authors of RFC 1597, and if the complaint in RFC 1627 is to be believed, he did so via back channels rather than the usual open processes. You can see that RFC 1597 itself went straight to RFC status without the usual preceding Internet-Drafts, so it too was approved via back channels, again by Postel, who was also RFC editor at the time. So it might never be possible to answer this question conclusively.
Now as to why he chose these three address ranges, let me return your attention to the RFCs 1166 and 1117 from SRI which had the then-current IP address range assignments. In both of them you will notice that network 10 was still allocated to the defunct ARPANET, which had shut down in 1990. Postel, in his role as IANA, would know that this range was no longer in use and could be reassigned. I posit that Postel picked network 10 because he knew it to be available and not in use.
Similarly, I expect Postel picked 192.168 because, at the time he made the choice, it was the next available, or nearly the next available, network to be assigned from the former Class C space. This probably can't be proved one way or the other, but the pace of address assignments shown in the RFCs strongly suggests that they would have been in this general vicinity around 1993-1994 when the assignments were made. (Addresses in 192.159 were being assigned in 1992. No dates are available for assignments in 192.160-192.167 as these were at some point reallocated to RIPE.)
Answering this question for 172.16-172.31 is more difficult. Nothing I could find suggests why this range was selected. Assignments in the former Class B space had not gotten nearly that high yet, as far as I can discover. I can only speculate that IANA threw a dart at a dartboard, rolled dice, or otherwise pulled the number out of his nether regions.
Finally, a note about Jon Postel. Despite the apparent way in which this RFC was brought about fully formed without (initial) input from the community, I do not mean to imply that, and this should not be construed as, Jon Postel somehow executed the IANA role poorly or unfairly. He was one of the strongest influences on the early Internet, and you still feel that influence today every time you get a glimpse of the behind-the-scenes machinery of the Internet, but he was always concerned with doing the job right. To quote from one remembrance:
There is no glory in doing administration and operations. Quite the opposite. People notice when it is done badly but rarely offer praise when it is done well. People in administrative positions often become petty bureaucrats. Since there is so little reward in the job, they artificially make it a base of power. So it has confused some who heard Jon referred to as the Internet numbers "czar". They did not realize that the community imparted the title to Jon out of affection and deep appreciation for his having brought order to essential infrastructure services. In particular the community used that term in full knowledge that Jon took his position as a trust, rather than as an opportunity for personal power. We always knew that his views came from legitimate beliefs and we never had to worry that he was somehow considering political or personal advantage. We might not agree with him, but we always knew was driven first by a concern that the right thing be done.
Because it made sense at the time? :-D
Remember, back when the private IP address ranges were assigned, there were several issues network engineers had to contend with: Some of the most powerful routers at the time had about as much CPU power and RAM storage as today's pocket graphing calculators--and some of the ones today still run circles around yester-years routers (I remember when CPU speed was measured in kilohertz and RAM storage was measured in kilobytes, not the giga*'s like they are today!). The Internet was growing quickly, the IPv4 address space was limited, and looking like it was going to run out by year 2000 or so, et cetera. Thus, many IP address ranges were already assigned, and they didn't want to have to ask companies to give back the IP address ranges just so they could re-assign them to private ranges. They also wanted to try to make it as easy as possible for companies to work with the private ranges--few companies would have cooperated if they had to invests a lot of money in to making their networks cope with one or two dozen ranges/IP addresses here and there.
This part is admittedly guesswork on my part, but based largely on both logic and experience in setting up networks.. They probably gathered together a listing of all unassigned network numbers and looked for a distinguishing pattern that met with the desired criteria: One single Class A (network numbers which have a high bit of 0xxxxxxx binary in the network number were Class A), 16 Class B (network numbers 10xxxxxx binary), and 256 Class C (network numbers 110xxxx binary) addresses. The Class B and C addresses should all be consecutive, as well. (The choice for 16 and 256 was probably partially arbitrary--after doing this stuff for awhile, you tend to start to think in powers of 2--and probably partially because it was what the could find that was available for reservation.)
From this, they probably selected the final ranges from those available addresses which would allow router manufacturers to do a simple bit-wise test on the address to determine whether to route/forward/drop the packet. There are also some properties of the bit patterns that I can see helping to build compact NAT tables, as well. The 10.x.y.z address is obvious, since it only has to match one network number. The 172.16.y.z to 172.32.y.z has the pattern that if you build a table with the low order four bits cross referencing the high-order four bits, the entire range fills across one single row of the table, without splitting in to two rows--that is, the second octet is always 0001xxxx (binary). In 192.168.y.z, the binary for 168 is 10101000--that is, the lower three bits are always 0, and the higher 5 bits alternate 1 and 0.
While these may appear arbitrary, if you've ever done any machine language programming or microcode decoding, these kind of patterns allow you to test only a few bits to make a private/public determination without having to decode the entire IP address first. This would allow routers to process such addresses quickly without having to maintain extensive lookup tables in memory. Thus, the router could push a private network packet back out to the private network without fully decoding it first, shaving precious clock cycles off the speed of the router and network.
If you're curious, look in to how serial data transmission (like a UART) handles each byte of data: It can only send/receive one single bit at a time, at the speed of the controlling clock, and usually frames the data in additional bits such as parity and "sync" bits. It would be too time consuming to try to calculate things like parity on a whole byte at once, so instead, it maintains a special bit that each clock cycle. That bit gets modified by the next bit that gets shifted in/out of the send/receive register. As soon as the entire byte is sent/received, the value left in the parity bit is already correct without having to recalculate it. The concept is more or less "do the work at the same time as you're doing something else", in the case of a serial chip, it's calculating parity at the same time that it's sending/receiving. For a router/switch, you can get higher performance if it's already decoding the IP address as each bit of the address comes in from the wire, and possibly already knows where to send the packet next before it's even finished being read in from the network cable!
Also, this IS just logic/guesswork on my part, based on 25 years of doing this kind of work. I don't know if we'll ever know the exact reasons behind the final numbers chosen as I don't recall any papers/RFC's/etc. ever giving the full rationale. The closest I've seen are just some comments suggesting the chosen ranges should make it relatively easy and efficient for companies to use them with minimal effort/investment/re-engineering.
In the primordial Internet, the network now denoted 10.0.0.0/8 was allocated to the ARPANET. By the time the IETF and IANA got around to assigning private address ranges, ARPANET was defunct, and its former address space was available for private use.
The other two ranges made Class B and Class C networks available for private IPs, in addition to aforementioned Class A.
This is a remnant of Classful Networking, where the IPv4 address range was sub-divided into classes:
We have since moved on (in 1993) to Classless Inter-Domain Routing, however the classes still have their legacy in various places (the 127 network is "home/loopback" - 127.0.0.1 anyone?, 192.168.X is common for home routers, the 10 network is common in more "enterprisy" network hardware, and multicast is still multicast.
Because 192 starts with 11xxxxxx in binary, indicating a class C network. It is the lowest number that starts with two consecutive 1's. Class A's have 0 as their highest order bit(s), and Class B's have 10.
RFC 1918 which defines the private IP ranges, does not clarify on this point, so there is no definitive answer on why they chose .168 for the 16-bit block, but I posit that this was because the RFC was not released until 1996, after a huge number of registrations had already taken place. because 192 is the first 8-bit block in the class C allocations, its likely that many of the addresses were already taken. 168 may have been the first available.
Also keep in mind, some of these choices are arbitrary. Note that the rfc1918 class B range is 172.16 - 172.31? I can't think of the reason for 172, but I am pretty sure they chose to use 16 class Bs so they had a block of 1 million contiguous addresses (1048576).
Sometimes protocols are just that way. someone had to make a choice, and they made it. for a while, the linux kernel was limited to a max of 1024 CPUs per system, and eventually they had to issue a patch, after some supercomputers had issues. whoever decided to use 1024 probably had no good reason to do so other than that he needed a value, and 1024 is nice and round.
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 went 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)
