Microsoft use 25.0.0.0/8 for some of their cloud services: you can see it in mail headers from Hotmail and Exchange Online. (Or could - I have not looked recently to see if this is still the case.) Microsoft stated on the mailop list on 16 July 2016 that they have an agreement with the MOD that it is OK to use these addresses like this. I don’t know if other organisations squatting on this address range have similar agreements...
NAT breaks certain things, and broken NAT breaks them further. The specific thing I can speak of is VoIP or more accurately SIP. SIP was designed for the public internet and so there are NAT workarounds, such as: if my interface has an RFC 1918 IP, I’ll use STUN along with certain SIP headers and tags to indicate I’m behind a NAT and need special treatment by the remote SIP agent. Using public IP space as NAT foils this logic entirely.
Apparently hamachi also uses the 25.x.x.x ip range for their vpn interfaces[1]. Not sure why anyone would use a random delegated range when there are plenty available, especially the 100.64.0.0/10 range.<p>[1] <a href="https://support.logmeininc.com/central/help/about-the-hamachi-virtual-ip-address-central-c-hamachi-virtual-ip" rel="nofollow">https://support.logmeininc.com/central/help/about-the-hamach...</a>
I saw this years ago on Rogers mobile devices in Canada. Freaked me out when I noticed it. But then it's behind NAT, so whatever. Always wondered why they chose that address space though. Like there aren't enough addresses to use in 10/8 or 172.16/12
I used to work for a service provider, that solved the MPLS administration problem by hijacking 7.0.0.0 DoD space that wasn't publicly routed.<p>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...
I rebuilt a corporate network for a relatively well known CGI company around a decade ago. They had chosen to use a subnet owned by a big tech company as their internal network. Took me months to convince the CEO that a change was necessary. Ultimately they were unable to download something important that caused them to suddenly care.
Back when I worked in IT (15+ years ago), I went onsite to a bank that used some seemingly-random /20 subnet for their internal network.<p>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.<p>It took me several hours to figure this out as I was working on their Cisco equipment and trying to add sane firewall rules...
This kind of thing seems innocent, but it really isn't.<p>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."<p>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 <a href="https://www.potaroo.net/studies/1slash8/1slash8.html" rel="nofollow">https://www.potaroo.net/studies/1slash8/1slash8.html</a> - over 165 megabits in 2010.<p>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.<p>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.<p>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.<p>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.<p>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.