If the device you are reading this on has an IPv4 address, it is very likely not a publicly routeable one. This is because the wide scale deployment of NAT and RFC1918 space has ensured that billions of devices (for better or worse) are addressed using a small set of “private” IPv4 addresses that are then translated on the way out to the wider internet with universally addressable ones.
These private (RFC1918) IPv4 address ranges are:
For the average user, the choice of address range does not matter as the only purpose of the network address is to communicate with the outside world (via translation) or to talk to devices inside the same LAN without any IP routing.
However a large problem begins to show up when you wish to actually IP route between these private address ranges, in the they are not guaranteed to be unique between two different sites (especially in the case of company mergers), so when routing two networks with private addressing together there is a high chance that there will be a conflict somewhere.
I recently came across this exact problem while staying at somebody else’s place whose home subnet overlapped with my Out Of Band (OOB) network range, meaning my VPN to reach it would not work without careful manual hacks to the routing table. That being said this wasn’t entirely surprising given that the OOB was setup on 192.168.1.0/24, as that is what OpenWRT shipped with. This happened to also be what their NETGEAR LTE WiFi router (very reasonably) decided was a good range too.
This is obviously quite annoying, and reminds me that I should probably re-number (aka change the IPv4 subnet) of my OOB network, but what to? This made me consider if it would be possible to do better than a simple guess for a RFC1918 range that is less likely to collide with other people, and I think there is!
In a previous blog post I explored using “WD Cloud” network attached hard disks that are aimed for consumers wishing to run their own “cloud” storage hosted within their home/office as a way to see who is using non RFC1918 space on their local LANs, this is because these WD Cloud devices issue two TLS certificates, one for the local IP of the device (so that local communication can be forced if available) and one of the WAN IP of the device (so that the device can be used outside of the NAT via port forwarding).
Using the same data but in reverse we can get a population count of how many devices are using which RFC1918 spaces.
This gives us a data set of 1.79 million devices, which should be enough to make some basic conclusions, for example we can take a look at it what of the 3 RFC1918 blocks are most popular:
Private Address Range | Count of Devices |
192.168.0.0/16 | 1,602,092 |
172.16.0.0/12 | 22,132 |
10.0.0.0/8 | 149,901 |
The large bias towards 192.168.0.0/16 implies to me that most of the uses of these devices are in home networks using default configurations, as 192.168.0.0/16 ranges are very common default configurations for Home/SOHO routers.
IP Block | Count | Known Default User |
192.168.1.0/24 | 647,220 | Common Default |
192.168.0.0/24 | 280,952 | Common Default |
192.168.178.0/24 | 229,398 | FritzBox |
192.168.2.0/24 | 98,341 | Common Default |
192.168.68.0/24 | 36,555 | TP-Link |
192.168.50.0/24 | 33,942 | TP-Link |
192.168.100.0/24 | 26,695 | Huawei |
192.168.4.0/24 | 24,834 | Zyxel |
192.168.86.0/24 | 24,736 | Google WiFi? |
192.168.10.0/24 | 20,381 | Zyxel/Motorola |
192.168.3.0/24 | 14,311 | Huawei |
192.168.8.0/24 | 13,554 | Huawei |
192.168.188.0/24 | 11,000 | FritzBox |
Or wider as a graph from 0 to 255:
So while there are no 192.168.XXX.0/24 subnets that have no known users, what about the other ranges, after all we have only touched 256 out of the 69,888 /24 subnets available to us!
The 172.16.0.0/12 subnet offers 4096 of /24’s for us to potentially use, and people often forget about it since it uses a CIDR range that people often cannot easily calculate in their head. Meaning it’s often seen in appliance workloads (Like VPNs) rather than ones where humans manually pick ranges.
This would go some way to explain why only 22,132 (or 1.2% of all) WD Cloud devices have internal LAN addresses in this range, however this means there is a lot of opportunity for finding likely under used RFC1918 /24’s
Here we can see there are a lot of under-used areas of 172.16.0.0/12, with most people using only the first /16 of the area, leaving another 15 /16’s worth of space quite empty.
If we turn all of the empty (according to the data set) subnets white, the scale of this becomes a lot more stark
Well, if you thought that 172.16.0.0/12 was not very well used, 10.0.0.0/8 is huge, and outside of many subnets, is also deserted.
Again, with the actually totally unused areas set to white:
There are 55,388 /24 subnets without known users, one of them should be listed below for you to use that has been randomly picked from that list:
In case you want to play with this data yourself, you can find all of the subnet numbers here (Zip file)
With all of this, I now have a /24 for my new Out Of Band LAN that is very unlikely to collide with someone else’s network. Sure I could use some other fancy tool to manage the OOB, but sometimes the simple tool is the one that survives even the biggest outages!
If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Fediverse @benjojo@benjojo.co.uk
Until next time!
Related Posts:
Where is all of the fediverse? (2024)
Reclaiming IPv4 Class E's 240.0.0.0/4 (2024)
Random Post:
Ghost in the ethernet optic (2022)