It’s 2025, And We Still Need IPv4! What Happens When We Lose It?

Some time last year, a weird thing happened in the hackerspace where this is being written. The Internet was up, and was blisteringly fast as always, but only a few websites worked. What was up? Fortunately with more than one high-end networking specialist on hand it was quickly established that we had a problem with our gateway’s handling of IPv4 addresses, and normal service was restored. But what happens if you’re not a hackerspace with access to the dodgy piece of infrastructure and you’re left with only IPv6? [James McMurray] had this happen, and has written up how he fixed it.

His answer came in using a Wireguard tunnel to his VPS, and NAT mapping the IPv4 space into a section of IPv6 space. The write-up goes into extensive detail on the process should you need to follow his example, but for us there’s perhaps more interest in why here in 2025, the loss of IPv4 is still something that comes with the loss of half the Internet. As of this writing, that even includes Hackaday itself. If we had the magic means to talk to ourselves from a couple of decades ago our younger selves would probably be shocked by this.

Perhaps the answer lies in the inescapable conclusion that IPv6 answers an address space problem of concern to many in technical spaces, it neither solves anything of concern to most internet users, nor is worth the switch for so much infrastructure when mitigations such as NAT make the IPv4 address space problem less of a problem. Will we ever entirely lose IP4? We’d appreciate your views in the comments. For readers anxious for more it’s something we looked at last year.

IPV4, IPV6… Hey! What Happened To IPV5?

If you’ve ever been configuring a router or other network device and noticed that you can set up IPv4 and IPv6, you might have wondered what happened to IPv5. Well, thanks to [Navek], you don’t have to wonder anymore. Just watch the video below.

We will warn you of two things. First, the video takes a long time to get around to what IPv5 was. In addition, if you keep reading, there will be spoilers.

Continue reading “IPV4, IPV6… Hey! What Happened To IPV5?”

Front view of blue bicycle with Raspberry Pi webserver

Pedaling Your Mobile Web Server Across The Globe

We tinkerers often have ideas we know are crazy, and we make them up in the most bizarre places, too. For example, just imagine hosting a website while pedaling across the world—who would (not) want that? Meet [Jelle Reith], a tinkerer on an epic cycling adventure, whose bicycle doubles as a mobile web server. [Jelle]’s project, jelle.bike, will from the 6th of December on showcase what he’s seeing in real time, powered by ingenuity and his hub dynamo. If you read this far, you’ll probably guess: this hack is done by a Dutchman. You couldn’t be more right.

At the heart of [Jelle]’s setup is a Raspberry Pi 4 in a watertight enclosure. The tiny powerhouse runs off energy generated by a Forumslader V3, a clever AC-to-DC converter optimized for bike dynamos. The Pi gets internet access via [Jelle]’s phone hotspot, but hosting a site over cellular networks isn’t as simple as it sounds. With no static IP available, [Jelle] routes web traffic through a VPS using an SSH tunnel. This crafty solution—expanded upon by Jeff Geerling—ensures seamless access to the site, even overcoming IPv6 quirks.

The system’s efficiency and modularity exemplify maker spirit: harnessing everyday tools to achieve the extraordinary. For more details, including a parts list and schematics, check out [Jelle]’s Hackaday.io project page.

A Month Without IPV4 Is Like A Month Without…

Recently, there was a Mastodon post from [nixCraft] challenging people to drop their NAT routers for the month of November and use only IPv6. What would it be like to experience “No NAT November?” [Alex Haydock] decided to find out.

What did he learn? You’d imagine he’d either wholeheartedly embrace IPv6 or stagger back in and warn everyone not to mess with their configuration. Instead, he recommends you go IPv6 mostly. He notes he is only talking about a home network, not necessarily networks for a big company or an Internet carrier. That’s a different topic.

IPv6 has been around since 1998, but it has been slow to catch on. However, OS support seems universal at this point. [Alex] was able to easily switch on IPv6 only using Windows, macOS, and several Linux flavors. He didn’t use any Android devices, but they should be OK. His iOS phones were fine.

Continue reading “A Month Without IPV4 Is Like A Month Without…”

The Glacial IPv6 Transition: Raising Questions On Necessity And NAT-Based Solutions

A joke in networking circles is that the switch from IPv4 to IPv6 is always a few years away. Although IPv6 was introduced in the early 90s as a result of the feared imminent IPv4 address drought courtesy of the blossoming Internet. Many decades later, [Geoff Huston] in an article on the APNIC blog looks back on these years to try to understand why IPv4 is still a crucial foundation of the modern Internet while IPv6 has barely escaped the need to (futilely) try to tunnel via an IPv4-centric Internet. According to a straight extrapolation by [Geoff], it would take approximately two more decades for IPv6 to truly take over from its predecessor.

Although these days a significant part of the Internet is reachable via IPv6 and IPv6 support comes standard in any modern mainstream operating system, for some reason the ‘IPv4 address pool exhaustion’ apocalypse hasn’t happened (yet). Perhaps ironically, this might as [Geoff] postulates be a consequence of a lack of planning and pushing of IPv6 in the 1990s, with the rise of mobile devices and their use of non-packet-based 3G throwing a massive spanner in the works. These days we are using a contrived combination of TLS Server Name Indication (SNI), DNS and Network Address Translation (NAT) to provide layers upon layers of routing on top of IPv4 within a content-centric Internet (as with e.g. content distribution networks, or CDNs).

While the average person’s Internet connection is likely to have both an IPv4 and IPv6 address assigned to it, there’s a good chance that only the latter is a true Internet IP, while the former is just the address behind the ISP’s CG-NAT (carrier-grade NAT), breaking a significant part of (peer to peer) software and services that relied on being able to traverse an IPv4 Internet via perhaps a firewall forwarding rule. This has now in a way left both the IPv4 and IPv6 sides of the Internet broken in their own special way compared to how they were envisioned to function.

Much of this seems to be due to the changes since the 1990s in how the Internet got used, with IP-based addressing of less importance, while giants like Cloudflare, AWS, etc. have now largely become ‘the Internet’. If this is the path that we’ll stay on, then IPv6 truly may never take over from IPv4, as we will transition to something entirely else. Whether this will be something akin to the pre-WWW ‘internet’ of CompuServe and kin, or something else will be an exciting revelation over the coming years and decades.

Header: Robert.Harker [CC BY-SA 3.0].

This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA

We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.

The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.

So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.

This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.

Continue reading “This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA”

This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2

You may have heard about a very large data breach, exposing the Social Security numbers of three billion individuals. Now hang on. Social Security numbers are a particularly American data point, and last time we checked there were quite a few Americans shy of even a half of a billion’s worth. As [Troy Hunt] points out, there are several things about this story that seem just a bit odd.

First up, the claim is that this is data grabbed from National Public Data, and there’s even a vague notice on their website about it. NPD is a legitimate business, grabbing data on as many people as possible, and providing services like background checks and credit checks. It’s not impossible that this company has records on virtually every citizen of the US, UK, and Canada. And while that’s far less than 2.9 billion people, it could feasibly add up to 2.9 billion records as was originally claimed.

The story gets strange as we consider the bits of data that have been released publicly, like a pair of files shared with [Troy] that have names, birthdays, addresses, phone numbers, and social security numbers. Those had a total of 2.69 billion records, with an average of 3 records for each ID number. That math is still just a little weird, since the US has to date only generated 450 million SSNs and change.

So far all we have are partial datasets, and claims on the Internet. The story is that there’s a grand total of 4 TB of data once uncompressed. The rest of the details are unclear, and it’s likely to take some time for the rest of the story to come out. Continue reading “This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2”