10/8 only has 16.7 million IPs. According to Google, Rogers has 10.8 million subscribers. Considering private IP blocks usually can't be 100% utilized (because of subnetting), it wouldn't surprise me if they've exhausted the actual private IP ranges.
10../8 could be split into three hierarchies each with 2^8 entries:
• 10.X../16: sites (e.g. global offices)
• 10.X.Y../24: on site vlans / individual buildings, typically a broadcast network (although switches use MACs to limit actual broadcasting.)
• 10.X.Y.Z/32: individual hosts
It’s not an enormous amount of space, really, hence IPAM. You could divide it on non-8-bit boundaries. Oof.
With 128-bit IPv6, each ISP has a /32, each client a /48, and each broadcast domain a /64, leaving a remaining 64 bits for clients to just randomly make up addresses as they wish.
That’s still 16-bits of address space to work with when creating networks (just as you have 16-bits for the X.Y in 10.X.Y../24) but all addresses are globally routable and each network can support essentially infinite hosts and without needing DHCP, instead of just 254.
But seeing as the ISP uses NAT anyway, is there any way to further route the private ranges behind private ranges? I don't know if this is what 'Double NAT' is, I tried searching online to see if this would work or if it would cause all sorts of issues. I'm not too familiar with ISP Natting as my home ISP has always assigned a public IP address.
So that their customers are free to use any RFC1918 space they want for their own networks, either on the customer network behind NAT or on VPNs the customer's connected to.
25.x is assigned to UK defence ministry as per the thread. Any ideas?
The "correct" way to handle this would be to reuse real private IPv4 addresses within your network by segmenting it somehow, or do what some networks have done (T-Mobile US is probably the biggest) - use IPv6 with NAT64. That lets them forego internal IPv4 entirely and only use it at the edge for NAT.
[1] https://support.logmeininc.com/central/help/about-the-hamach...
I had some troubles with AWS when I created a VPC private subnet that happened to conflict with an internal IP range used by Docker. (You can change that, but not if you use their managed k8s offering. At the time it made sense, but, upon further reflection, I am baffled as to why Docker needs IP ranges outside of what the k8s CNI gives it. But I can assure you -- stuff broke in exciting and fun ways!) It was at that point I realized we had to have some central management of "internal" IP addresses, just like the IANA but for internal addresses. We were an ISP, so we already used Netbox, and it ended up being quite straightforward. Plus, the documentation was great -- you would see a connection from 10.42.123.8, look it up in Netbox, and see "oh that's the management network in NYC-FOOBAR-42".
Anyway, be careful about private subnets. Someone else already has a private subnet with that IP range, and those two networks can never talk to each other. No doubt, some Hamachi customer ran into this problem at some point in the past ;)
By using 7.x IP assigned loopback interfaces in customer MPLS space, we could export just the loopback interfaces into our managment vrfs (without burning our supply of public IPs.) Of course the one problem is that we'd never have been able to take a Federal contract...
Because people typically use IPs designated as private behind a NAT, this isn't a problem in practice. But if you start using publicly-routable IP addresses internally, then you can create some fun problems. Actually, not even that fun. Just annoying.
Your CGNAT looks after translating your customer's ISP address (ie, the 100.64.0.0/10 side of their CPE).
Of course, the best solution is to move to IPv6 and allocate each customer: * a /64 address out of the ISP's network space * a /48 (or /56) delegation for their own network
Turns out that they had some piece of hardware that came with a "hard-coded" IP address (from Japan) and instead of figuring out how to change it, they just used that entire subnet as their internal range.
It took me several hours to figure this out as I was working on their Cisco equipment and trying to add sane firewall rules...
Another comment put it as "25.x.x.x is not advertised globally, not announced with BGP, so they're using it as private IP space. This works because you will never connect to a 25.x.x.x IP. It's just NAT."
That sounds fine but you run into trouble when the owner suddenly starts using the space or it’s reallocated. This has happened quite a lot in the last decade as IP space was ever more in demand and thus ever more scarce. An example is the use of 1.0.0.0/8 - allocated to APNIC in 2010 - there is a detailed analysis of the "unintentional" traffic this network was receiving when first used https://www.potaroo.net/studies/1slash8/1slash8.html - over 165 megabits in 2010.
Among various lazy configs and people using the range as it was convenient I recall there was some default popular Cisco recommended config that used it. Though I can’t find a link right now.
Similar problems also happened in the 2007-2010 timeframe as a lot of people used to have static “Bogon filter” firewalls that dropped traffic from unallocated IP ranges (not those marked as 'never to be used', just those not allocated yet). As more and more ranges were allocated the people receiving them had all sorts of connectivity problems to random networks because of these old out of date static filters - in my experience as a hosting provider the most common offender was banks hilariously. In practice these filters provided relatively little security and just broke things instead some years after they were put in place. If you had a dedicated team managing your network and constantly watching these kinds of things - hyper-aware the filter was in place and vigilant to update them then maybe it’s a tactic you could use but as static network config that is left and forgotten about it was a terrible idea and I spent a lot of time chasing down working contacts for various networks to get them to fix their firewalls. Meanwhile as far as our customers (trying to use the IP space) are concerned it was our problem since it worked fine should they use another provider. And this was just a network in the 110.0.0.0/8 range - no fancy 1.0.0.0.
Back to this specific case. If for example we wanted to extend IPv4 a little more and the UK DOD decided to sell or allow this range to be reallocated (since as rightfully pointed out, it's not really being used right now) there would be a lot of problems using it because of configurations like this. And you have a bit of a chicken and egg problem in that you can’t really use it until it mostly works but people won’t fix their networks unless people are using it.
Hence why sounds kind of innocent but in practice these are terrible ideas and using IP ranges for purposes they are not intended for shouldn't be done.
This is partly why for CGNAT applications like this a new range was reserved in 2012 - 100.64.0.0/10 which is what should be used here. The reason to have a dedicated range for the “ISP side” rather than just using RFC1918 space is so it doesn't clash with whatever RFC1918 space the end user wants on the LAN side of their network. If both sides used RFC1918 and accidentally chose an overlapping range then the connection would not work.
