This explains the reason private ranges were designated but not why 192.168.0.0 in particular within the Class C range was designated to be private. Does anyone know why that number in particular was chosen?
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.)
Text formatted as code on HN is very difficult to read when on mobile. Using italics or > to quote things is better.
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.)
What the given article does not address is when to choose 10.x.x.x, 172.x.x.x and 192.168.x.x and why it's important to choose the right one.
Here is the prescribed solution:
- Use 10.x.x.x for office/enterprise LANs
- Use 192.168.x.x for home LANs
- Use 172.x.x.x for supplementary services like guest networks, DMZ etc
Why so? The reason is VPN.
When you connect to office VPN from home, you connect from 192.168.x.x to 10.x.x.x. This makes it very easy for routers to avoid address range clashes.
If you break that rule then you may end up with a weird situation when you connect from a home network 10.0.1.1/24 to an office network 10.0.1.1/24. Good luck trying to connect to that specific 10.0.1.12 machine: there is no easy way to determine where the packet should be routed.
Hmmm ... it's easy to avoid clashes by choosing somewhat unique addressing schemes in those ranges.
For example, the 10. private network allows 255 different addressing schemes if you use a 16 bit subnet mask (10.0/16, 10.1/16, 10.2/16 .. 10.254/16), and ~64,000 schemes with an 24 bit subnet mask (10.0.0/24, 10.0.1/24, 10.0.2/24 .. 10.254.254/24). Just don't choose the common ones: 10.0/16, 10.0.0/24, 192.168/16, 192.168.0/24, etc.
> Something I never understood is why people choose 192.168.1.1 for private networks
While interviewing someone for an entry-level job, I told the interviewee that there was a network using 10.0/16 (a 16-bit subnet mask, or more popularly 10.0.x.x). He corrected me and said that 10.0.0.0 networks should have an 8 bit subnet mask (10.x.x.x). On one hand, I definitely liked that he was willing to challenge me, even during an interview, and that he knew the spec (RFC 1918 does assign an 8-bit mask to the 10. private network). On the other hand, I wasn't sure he was technically correct that a 16-bit mask was wrong, even if 8-bits was 'correct', and I couldn't see what negative consequence the 16-bit subnet had - his thinking seemed a bit rigid. Anyway, maybe there are other purists who believe smaller networks should use 192.168/16, or maybe they instinctively use it because the RFC gives it the smaller network allocation. Or maybe they know something that I don't.
> isn't 10.1.1.1 easier to type and more "aesthetically pleasant"?
And it's much easier for non-technical people to understand and to remember without error. In fact, I recommend something even easier, such as 10.9.8.x. For people supporting the non-technical, those little details can save hours, even a day. I've seen cases where after hours of frustration, the support tech discovers that the user typed in something like 129.168, or 192.16.8. Great support reps are great humanitarians, able to handle those situations with grace, without humiliating the poor user, and without heavy drinking.
For some reason courses that cover some networking used to make a huge point about the network classes for many years after CIDR made them completely irrelevant.
10/8 is a class A range (high order bit = 0), but CIDR says that you can separately describe which bits are for the network. Unless this interview was conducted more than 20 years ago I'd say your interviewer was mistaken.
Is that what you meant to say? The interviewer (me) thought that 10.0/16 was fine, which I think agrees with your analysis. The interviewee said only 10/8 was correct.
(Re-reading my GP comment I realize that my role might have been ambiguous, so I've clarified it.)
If you said 10/24, I'd immediately think 10.0.0.0/24. 10/8 would certainly be valid. 10.0/16 is too.
I remember when CIDR came around back in the 90's. Man people were pissed off when you would call out a 'Class A/B/C/D/E' block. I prefer to always be specific when writing my CIDR. I understand when people don't do it.
Be liberal in what you accept and conservative in what you send.
It depends. Some use 10.0.0.x, some use 192.168.1.x and some use 192.168.178.x
There's also 172.16.0.x, which I have never seen used by default on any networking devices.. which makes it perfect if you have a piece of network that you visibly want to separate from the rest of the LAN.
I almost always put my VPN connections in this range for that reason. Nobody ever uses it. Makes it obvious when you see that address in a webserver log or a route table.
IIRC, I used to have one of the old Apple Airport travel routers back in the day and it used 10.0.0.1 by default. I've tended to prefer that block for my home network ever since.
Yep. We use both 10.x.x.x and 192.168.x.x at my workplace (who knows why). I had to request a special change to our VPN settings so I could still access my home network while connected to it.
Easier to change address allocations and DNS entries of a dozen devices in my network to fix the problem for just me, than to make a request to corporate IT to fix the problem for everyone? No.
It's the smallest of the private IPv4 ranges. Corporate and academic networks tend to use the larger ones, so it's the least likely to cause a numbering conflict.
Up until 4 years ago, I used to always allocate addresses specifically on bit boundaries. I did this mainly for one reason - aligning the bytes and trying not to waste CPU cycles.
For example, in a /24 network:
0-15 - network equipment
16-31 - some special gear
32-63 - mail servers or something like that
64-127 - split it up and align more things
128-191... you get the point.
...
The ultimate goal was to hit everything on a bit boundary so the CPU wouldn't work so hard
These days, CPU power is so prominent, it doesn't matter. DHCP is probably the way to go.
IPv6 is here. We have the opportunity to really make CPU's fast again with IPv6!
I wish there was a netblock reserved for packets that never leave a physical (or virtual) host, that could be used for the default internal network for things like Docker. In my case, Docker defaulted to 172.17.0.0/16, which happened to conflict with one of the IP ranges for my wing of the building at work.
I've resorted to using RFC 5737 (test-net-1 through 3) IP ranges for this purpose, even though that isn't what they are designed for.
Too late to edit my message, so I'll use a response instead. Docker rebinds the 127 network to each container, so you cant - by default - communicate through these IP Addresses.
An easy fix could be to just let the container use the hosts network stack (so, not network type: bridge).
After that, you can bind the daemons to specific IP Addresses in the subnet - i.e. 127.0.0.2:3306 DB1 127.0.0.3:3306 DB2 and they'll be able to communicate directly.
But as mentioned before: this is not the primary usecase for docker, so its cumbersome to use.
Ugh, not another site that blocks pinch to zoom gestures on mobile. It doesn’t make sense to me why so many (quite popular) sites care so little about enabling their users to comfortably read their content. The solution, for now, is to use Safari since it started ignoring that setting, but unfortunately Chrome still allows it for some reason.
