IPv6

19 Articles

The IPV4 We Didn’t Get

March 16, 2026 by 24 Comments

If you have ever read science fiction, you’ve probably seen “alternate history” stories. You know, where Europeans didn’t discover the New World until the 19th century, or the ancient Egyptians stumbled upon electricity. Maybe those things happened in an alternate universe. [BillPG] has an alternate history tale for us that imagines IPv6 was shot down and a protocol called IPv4x became prominent instead.

The key idea is that in 1993, the IP-Next-Generation working group could have decided that any solution that would break the existing network wouldn’t work. There is precedent. Stereo records play on mono players and vice versa. Color TV signals play on black and white sets just as well as black and white signals play on color TVs. It would have made perfect sense.

How could this be? The idea was to make everyone who “owns” an IPv4 address the stewards of a 96-bit sub-address block. IPv4x-aware equipment extracts the entire 128-bit address. IPv4-only equipment routes the packet to the controlling IPv4 address. Wasteful? Sure. Most people don’t need 79 octillion addresses. But if everyone has that many, then why not?

The fictional timeline has DNS and DHCP, along with dial-up stacks, changing to accommodate the new addresses. Again, you had to assume some parts of the network were still IPv4-only. DNS would return both addresses, and it was up to you to pick the IPv4x address if you understood it.

Your ISP would probably not offer you the entire extra space. A regional router could handle all traffic for your neighborhood and then direct it to your specific 128-bit address or your pool of addresses, if you have multiple devices. No need for NAT to hide your devices, nor strange router configurations to punch traffic through.

Of course, back in the real world, we have two incompatible systems: IPv4 and IPv6. IPv6 adoption has been slow and painful. We wondered why [BillPG] wrote about this future that never was. Turns out, he’s proposed a gateway that IPv6 hosts can provide to allow access from IPv4-only networks. Pretty sneaky, but we can admire it. If reading all this makes you wonder what happened to IPv5, we wondered that, too.

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

July 3, 2025 by 79 Comments

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?

March 9, 2025 by 37 Comments

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

December 8, 2024 by 11 Comments

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…

December 3, 2024 by 91 Comments

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

October 26, 2024 by 72 Comments

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

August 30, 2024 by 2 Comments

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” →