The collapse in IPv4 transfer prices is what caught my eye here, dropping from a ~$55 peak in 2021 to a mean of $22 in early 2026 (figure 12). This validates my hypothesis that the run-up in 2020–2022 was an artificial scarcity bubble driven largely by hyperscalers. AWS was right up there stockpiling before they shifted their pricing model. Once AWS introduced the hourly charge for public IPv4 addresses (effectively…
When IPv6 was developed, over 30 years ago, connecting everything to the internet seemed like a great idea. I know that IPv6 can be made secure, but I don't have the background or research time to learn how to do so, and the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy that makes it impossible to accidentally directly connect anything to the internet.
I'm hoping I can keep using IPv4 until IPv8 or IPv4.5 or whatever comes next is developed with the modern proliferation of cheap insecure IoT in mind.
For some background on why IoT products are so insecure:
Hardware manufacturers don't really comprehend the idea of updates, let alone timely of security patches. Hardware has to work on the day of release, so everything is documented and tested to verify it will work. I have hardware with a TCP/IP stack that was released 20 years, (https://docs.wiznet.io/Product/Chip/Ethernet/W5500) and doesn't have a single errata published, despite widespread use. This is expected for every single component, for even the smallest 1-cent transistor, which has dozens of guaranteed performance characteristics laid out over several pages of documentation (https://en.mot-mos.com/vancheerfile/files/pdf/MOT2302B2.pdf).
When manufacturers venture into a product that runs software, they don't realize that for a given complexity, working through undocumented or, worse yet, incorrectly documented APIs takes more time than the equivalent hardware development and documentation. I've worked on multiple projects where software bugs were fixed with hardware workarounds, because it's faster, cheaper, and easier to develop, test, document, retool, and add a few cents of bill-of-materials cost per product, than to get reliable output from the already-written library that's supposed to provide the functionality.
The hardware TCP/IP stack that I linked to was developed at a time when it was the cheapest way to connect a low-power embedded system to a network. Modern low-power embedded systems have multiple cores running at hundreds to thousands of MIPS making the resources to run a softtware TCP/IP stack trivial, but the product still sells well, because when security is an absolute must, the hardware development and maintenance cost for the functionality is still cheaper than through software, even when there's no marginal cost to run the software.