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”

Embrace IPv6 Before Its Too Late?

Many hackers have familiar sayings in their heads, such as “If it ain’t broke, don’t fix it” and KISS (Keep it simple, stupid). Those of us who have been in the field for some time have habits that are hard to break. When it comes to personal networks, simplicity is key, and the idea of transitioning from IPv4 to IPv6 addresses seems crazy. However, with the increasing number of ‘smart’ devices, streaming media gadgets, and personal phones, finding IPv4 space for our IoT experiments is becoming difficult. Is it time to consider embracing IPv6?

The linked GitHub Gist by [timothyham] summarizes the essential concepts for home network admins to understand before making changes. The first major point is that IPv6 has a vastly larger address space than IPv4, eliminating the need to find spare IPv4 addresses. IPv6 assigns multiple addresses to the same interface. The 128-bit addresses are split into a 64-bit prefix assigned by your ISP and a 64-bit interface identifier. Using SLAAC (Stateless Address Autoconfiguration), clients can manage their own addresses. You don’t have to use SLAAC, but it will make life easier. The suffix typically remains static, allowing integration with a local DNS server.

Continue reading “Embrace IPv6 Before Its Too Late?”

FLOSS Weekly Episode 770: 10% More Internet

This week, Jonathan Bennett and Doc Searls talk with David Taht about the state of the Internet and, specifically, IPv4 exhaustion. We’re running out of IPv4 addresses! But we’ve been running out for something like ten years now. What gives? And why are nearly 20% of the world’s IPv4 addresses sitting unused? David has a hack that would give the world 10% more Internet, but Amazon might have something to say about it.

There’s even more, like Kessler Syndrome, some musing on what the Interplanetary Internet will look like, the worth of real paper books, and a long-term bet for some IPv4 addresses to come to fruition in 2038.

Continue reading “FLOSS Weekly Episode 770: 10% More Internet”

Where Exactly Did That Network Packet Come From?

Have you ever noticed that some websites can figure out, at least roughly, where you are? Sometimes they use it to find you a closer content provider. Or they might block you from seeing certain things while offering you other things specific to your location. This is possible because there are databases that map IPs to locations. [Mark Litwintschik] looks at using those databases from an API or downloading them into your own database. He also shows some very large database queries, which is interesting, too. He uses IPInfo, although there are other providers. Some only provide a limited number of lookups, but there are plenty of free tiers for low-volume usage.

The database changes every day. Of course, each provider has a different way of getting data, and so there are differences. [Mark] compares the IPInfo dataset against MaxMind’s also free database. That involved comparing over 3 billion records! Actually, the 3 billion are the number of IPs that matched up in both databases. There were an additional 118 million that didn’t match and 34 million that were not in the MaxMind database.

Continue reading “Where Exactly Did That Network Packet Come From?”

Starlink: A Review And Some Hacks

I could probably be described as a SpaceX enthusiast. I catch their launches when I can, and I’ve watched the development of Starship with great interest. But the side-effect of SpaceX’s reusable launch system is that getting to space has become a lot cheaper. Having excess launch capacity means that space projects that were previously infeasible become suddenly at least plausible. One of those is Starlink.

Starlink is SpaceX’s satellite Internet service. Wireless and cellular internet have helped in some places, but if you really live out in the sticks, satellite internet is your only option. And while satellite Internet isn’t exactly new, Starlink is a bit different. Hughesnet, another provider, has a handful of satellites in geostationary orbit, which is about 22,000 miles above the earth. To quote Grace Hopper, holding a nearly foot-long length of wire representing a nanosecond, “Between here and the satellite, there are a very large number nanoseconds.”

SpaceX opted to do something a bit different. In what seemed like an insane pipe dream at the time, they planned to launch a satellite constellation of 12,000 birds, some of them flying as low as 214 mile altitude. The downside of flying so low is that they won’t stay in orbit as long, but SpaceX is launching them significantly faster than they’re coming down. So far, nearly 1,600 Starlink satellites are in orbit, in a criss-crossing pattern at 342 miles (550 km) up.

This hundred-fold difference in altitude matters. A Hughesnet connection has a minimum theoretical latency of 480 ms, and in reality runs closer to 600 ms. Starlink predicts a theoretical minimum of under 10 ms, though real-world performance isn’t quite that low yet. In the few weeks I’ve had the service, ping times have fallen from mid-60s down to 20s and 30s. The way Starlink works right now, data goes up to the closest satellite and directly back to the connected ground station. The long-term plan is to allow the satellites to talk directly to each other over laser links, skipping over the ground stations. Since the speed of light is higher in a vacuum than in a fiber-optic cable, the fully deployed system could potentially have lower latency than even fiber Internet, depending on the location of the endpoint and how many hops need to be made.

I got a Starlink setup, and have been trying out the beta service. Here’s my experience, and a bonus hack to boot.

Continue reading “Starlink: A Review And Some Hacks”