What makes you think that, for critical systems, "IPv4 + NAT + bad firewall" is the default IPv4 deployment paradigm, rather than "IPV4 + bad firewall"?

Sure, big IaaS providers like AWS put you in a VPC by default. But most servers on the net are not hosted in an IaaS; they're hosted using a VPS or bare-metal hosting provider, or just coloed in a DC by their owner. And in all those cases, what that kind of deployment gets you, is a public IPv4 per VM/machine, that anyone on the Internet can march right up and talk to, where it's the responsibility of the machine itself to reject incoming packets (i.e. at the OS level with a kernel firewall.)

NAT on IPv4 is only really a default assumption for residential networks. Anywhere else, it's pretty much like the movie WarGames: even the mainframe has a phone number you can call. Staying on IPv4 isn't making anyone safe.

While I don't have any factual proof to refute your statements, in my personal experience almost every organization uses NAT & RFC1918 address space. The only client I can think of in my 20 years of experience that used a public IPv4 per VM/machine was the DoD, specifically, the U.S. Army.

From your very last statement, I think you've confused self hosting (like buying a VPS from Digital Ocean and hosting your own blag) and how the real world works (like going to Dell.com and ordering a new laptop). "The mainframe" these days is almost always behind a L4/L7 load balancer or other network device and very rarely directly addressable.

People assume that RFC1918 is not routable, but that's not the case... It's fully routable, but there is no global route. Have you ever tested routing to your RFC1918 address space from the ISP, or from a customer in the same neighborhood?

On some ISPs, all the customer routers in a given area are placed in a large legacy subnet, so if another customer adds a manual route to RFC1918 space using your router as next hop - the traffic will arrive on the WAN interface of your router. Some routers will actually route this traffic inside.

Have you ever tested this and verified that your router doesn't do this? Probably not, because most people haven't. They just assume that it can't, and get a nasty surprise if someone demonstrates that it can.

My company runs an API SaaS; my impressions come from a hobby I have of looking up the hosting providers behind our customer IPs as seen in our request logs (to find out what people think is a good idea for hosting a production web- or mobile-app service backend these days.)

By and large, our very-much "real world" customers are "self hosting" — usually on bare metal rather than a VPS, and usually with providers you've probably never heard of (ColoCrossing and ServerMania seem to come up fairly often among our US-based customers.) These hosting providers are all very much in the style of "you lease each machine as a separate contract; each machine gets one public IPv4 address included in the cost; private networking [i.e. an explicit VLAN] is an extra optional feature you can enable after the fact, and only works between higher-end machine types, rather than being a given, because our lower-end machines only have a single NIC in them [besides the one that's part of the BMC used for IPMI]."

What I assume is happening here isn't literal "self hosting" — these random non-IT-oriented customers wouldn't know the first thing about it — but rather that a given customer of ours has paid some "vertically-integrated IT consultancy" to both build and host their service for them; and said consultancy has chosen to use bare-metal hosting to host the resulting service, to minimize their own OpEx, and therefore maximize their margins. (In fact, I bet they're often packing several such customers onto a single box.)

---

Also, in a more professional capacity, I investigate the hosts behind IP addresses behind bulk-registration / DDoS attacks against our platform, in order to create signatures for them. Given the way some of these attacks seem to work, a large number of machines on the Internet — especially in Russia and [some parts of] Africa — seemingly aren't only un-NATed, but in fact have a public /24 or even /22 directly attached to a single box! (If traffic was originating from a random subset of a /24, it could just be someone spinning up a hundred VMs on top of some small colo's OpenStack deployment, sure. But tandem traffic from every IP in a /24, and only exactly said /24? That looks pretty much exactly like the sort of tandem IPv6 traffic that is generated when a box has a /48 or /56 assigned to it.)

Big universities (at least in my experience in the USA) are the other ones that would have a public IP address for every device, at least until rather recently. They were online very early and got allocated huge blocks of addresses, before anyone really imagined future scarcity.

In the mid-90's, every system at my university had a public IP address, including those on the campus residential networks. There were no firewalls. It was also a flat address space (/16, 255.255.0.0) for the whole campus! The 90's were certainly a different time.

> The claim is that IPv4 + NAT + bad firewall is better than IPv6 + bad firewall.

Even that is not true:

- It takes half-minute to scan an IPv4 public IP (NAT) for vulnerabilities.

- Good luck and have fun to scan a /64 for a potentially vulnerable machine. See you next century.

- And if it is not enough: most internet box support UPnP/NAT-PMP that allow any malware to get your NAT wild opened.