Google Hits 50% IPv6 • Hacker News Board

Re: Google Hits 50% IPv6

#481

Post by Dagger2 » Tue, Jun 23, 2026, 2:56 PM UTC

will4274 wrote: post #426

Dagger2 wrote: post #415

Earlier quoted context omitted.

You have to do that with range bans in v4 too, since you have no idea how big the pool of addresses a user can pull from is -- and with CGNAT in the picture you're kind of doomed to banning legitimate customers on v4 no matter what you do.

Yes, you ban some legitimate customers with v4. But the span between the smallest allocations and biggest allocations is much smaller, so simple strategies (like banning the bad address) scale further.

I think the span would be about the same, or smaller even, if you limited yourself to a granularity of 4 bits for v6. Allocations are often rounded to 4 bits in v6 because it correlates to exactly one character of the v6 address.

I'd also like to note that being worried about accidental overbanning in v6 but then being dismissive of it in v4 is a double standard.

Re: Google Hits 50% IPv6

#482

Post by Dagger2 » Tue, Jun 23, 2026, 4:11 PM UTC

mahboi wrote: post #467

Dagger2 wrote: post #464

Earlier quoted context omitted.

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too. At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much…

Github.com doesn't have an AAAA record, so I don't know how you're reaching it if you don't have a v4 anywhere. Even if they had that, they said that basic features like cloning repos won't work over v6. Only one example of many services like this. > In your proposal, where is that work being done? Work for longer v5 addrs would be similar in difficulty to what v6 had to do, but it'd be done at a different time and p…

  $ wget -4 https://github.com/HackerNews/API
  Resolving github.com (github.com)... 140.82.114.4
  Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable.
  $ git clone https://github.com/HackerNews/API
  Cloning into 'API'...
  remote: Enumerating objects: 142, done.
  remote: Counting objects: 100% (53/53), done.
  remote: Compressing objects: 100% (21/21), done.
  remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2)
  Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done.
  Resolving deltas: 100% (39/39), done.

Seems to work fine.

> Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4

Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of these things and works with them instantly when working with 4-byte addresses, so this isn't new.

> Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.

Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6.

All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it.

Re: Google Hits 50% IPv6

#483

Post by Dagger2 » Tue, Jun 23, 2026, 4:11 PM UTC

mahboi wrote: post #475

delotrag wrote: post #474

Earlier quoted context omitted.

> You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time. I guess I don't understand. This seems to boil down to: expand the address space, but don't actually use the additional space until a flag day that occurs after every piece of networking equipment on the Internet gets upgraded? Surely there would be even _les…

You can use the 8-byte addresses earlier if you want, just requires your hosts and stuff in between to support v5, same story as with v6 there. The point is that you aren't asking everyone to do nearly as difficult of a migration to support v5. Github would've been on it already, all the v6 pieces are already there.

Except you are, because all the same work needs to be done.

> You can use the 8-byte addresses earlier if you want

You can't have both this and "The 8-byte phase only starts when v4 has been abandoned" simultaneously. Decide whether you want a flag day or not and then be consistent about it. (And when you're deciding, bear in mind that flags days on the Internet are impossible.)

Re: Google Hits 50% IPv6

#484

Post by Dagger2 » Tue, Jun 23, 2026, 4:15 PM UTC

tgma wrote: post #472

Dagger2 wrote: post #416

Earlier quoted context omitted.

I have no v4 on this machine. I'd disable the v4 stack on it if that was a thing Linux could do, but as it stands it's just sitting there doing nothing. The thing you're claiming is not going to happen is something I'm already doing.

I was talking about internet at large. You , and many clients, are of course able to do it on your box, but to use the whole internet, you will at some point hit a translation point which uses v4. The point is the internet at large is never going to reach a point where there won't be two internets; at this point it is pretty clear v6-only will not be a thing with the current set of technologies before a future protoc…

There were always expected to be v4 hosts on the Internet effectively indefinitely. That's not a failure condition for v6.

"There are a couple of v4-only hosts out there somewhere" would be kind of irrelevant if most ISPs stop bothering to provide v4 service.

Re: Google Hits 50% IPv6

#485

Post by r3trohack3r » Tue, Jun 23, 2026, 5:05 PM UTC

WarOnPrivacy wrote: post #390

r3trohack3r wrote: post #358

Earlier quoted context omitted.

Starlink shattered this monopoly in my area.

> Starlink shattered this monopoly in my area. The parent was noting that most of the US lives in a region, that is under a monopoly of wireline ISP (DOCSIS, FTTH). Starlink can't shatter a wireline monopoly because it is OTA .

I fired my DOCSIS provider for starlink. For many consumers the service is fungible.

Re: Google Hits 50% IPv6

#486

Post by kortilla » Tue, Jun 23, 2026, 6:21 PM UTC

kalleboo wrote: post #398

kortilla wrote: post #339

Earlier quoted context omitted.

The p2p tech argument doesn’t work anymore. Most routers ship a stateful IPv6 firewall enabled by default now because IPv6 was resulting in people’s vulnerable shit getting popped. So p2p stuff still doesn’t work without explicit configuration that rules out 99% of your users. It’s super annoying.

Hole punching works fine for IPv6 p2p. It even mostly works fine on IPv4 NAT, but there are a bunch of edge cases (often involving CGNAT) where it breaks down so you can't rely on it, which are solved by IPv6. https://tailscale.com/blog/how-nat-traversal-works

Hole punching works fine for IPv4 as well outside of endpoint dependent NAT, which most ISPs don’t use because it visibly shows up to normies as a bad connection in PlayStations/Xboxes.

Once you have to hole punch, you’ve lost the thread of why people bother switching to IPv6.

Re: Google Hits 50% IPv6

#487

Post by the_real_cher » Tue, Jun 23, 2026, 6:42 PM UTC

mahboi wrote: post #302

the_real_cher wrote: post #285

Earlier quoted context omitted.

I dont think its that over engineered for what its capable of.

That's what overengineered implies, it's capable of things you don't need. The problem with v6 isn't 128-bit addrs though.

Oh right on. The 128 bit addrs was what I was referring to. I find it pretty intuitive. I don't know much more about the spec so please forgive my ignorance.

Re: Google Hits 50% IPv6

#488

Post by throw0101a » Wed, Jun 24, 2026, 1:34 AM UTC

mahboi wrote: post #458

BadBadJellyBean wrote: post #371

Earlier quoted context omitted.

The problem with IPv6 is really not the changes it made. Support was flaky for a while but that is pretty much over. The problem is that you have to deploy it. You have to handle the bigger IP space safely, you have to assign the IPs, add DNS records, routing, etc. All this is work and the pressure is low. NAT has mostly taken that away. Nothing would have saved us from that. There is no way to expand the number of a…

The problem is they designed v6 with no good compatibility in either direction. I get that there's no way for v6 to support v4, but at least going from v4 to v6 should've been easier. 6to4 etc didn't cut it. Assigning IPs, DNS records, etc is way easier if you don't need to change all of it immediately to get onto v5. You can just get to v5. Changing more things after is easier once nobody is using v4 anymore. The ot…

> The problem is they designed v6 with no good compatibility in either direction. I get that there's no way for v6 to support v4, but at least going from v4 to v6 should've been easier.

Here are the constraints:

"""

Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:

1. You have to change the version number.

2. You have to add new code to handle the new version.

Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,

3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol.

Two minutes of thought show that this third requirement has only two solutions:

(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.

(3B) Translation, in which something translates addresses between the old and new protocols.

This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it.

"""

* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...

It is impossible for IPv4 to connect to IPv6: IPv4 data structures have 32-bit data structures, and this includes the fact that DNS A records are 32-bit only. You cannot have a more-than-32-bit-addresses protocol scheme that can be reach by non-updated IPv4 systems.

If you want to add more bits there is no way around adding/changing code, in which case you are in the exact same situation as we have now with IPv6. You either go with 3A or 3B above.

Re: Google Hits 50% IPv6

#489

Post by throw0101a » Wed, Jun 24, 2026, 2:04 AM UTC

commandersaki wrote: post #445

throw0101a wrote: post #396

Earlier quoted context omitted.

> NAT / CGNAT has been doing the heavy lifting extending the life of the Internet; ipv6 has done jack shit. Given they made the transition to IPv6 on handsets, T-Mobile US, which has 140 million subscribers, would disagree: * https://www.youtube.com/watch?v=d6oBCYHzrTA > As for telco addressing handsets, they could use any addressing scheme to be honest. When people talk about averting address exhaustion, they're not…

You do realise that mobile usage is a subset of the Internet and the Internet is not just about end user connectivity. But you still haven't addressed my original point, how has IPv6 averted the impending (at the time) IP exhaustion problem? As I remember it, we were running out of IP addresses, then we did run out, and CGNAT helped extend the life of the Internet for people on IP, while v6 still remains an island th…

> You do realise that mobile usage is a subset of the Internet and the Internet is not just about end user connectivity.

I would argue that mobile usage is the primary way that many people access the Internet in their personal lives, as evidenced by fact that IPv6 usage goes up on weekends, when people are probably not browsing stuff on work laptops.

> But you still haven't addressed my original point, how has IPv6 averted the impending (at the time) IP exhaustion problem?

If T-Mobile US could not offload a lot of traffic to 'straight' IPv6 they'd need a lot more publicly accessible IPv4 addresses. As it stands now they can only have their IPv4 addresses assigned to CG-NAT boxes, but without IPv6 they'd have to have way more IPv4 to assign to handsets, or given handsets 10/8 or 100.64/10 and have may more IPv4 on their CG-NAT hardware. (They'd also need way beefier CG-NAT hardware to handle higher loads.)

See also for example Vodafone moving to IPv6 to deal with IPv4 address shortages:

* https://www.youtube.com/watch?v=3CzFkvJ2Kxs

Or how Sky wouldn't have been able to create a new ISP without it because of a lack of available IPv4:

* https://www.youtube.com/watch?v=03cwFIPdgQ8

* https://www.youtube.com/watch?v=9Cg3dLR95wY

Re: Google Hits 50% IPv6

#490

Post by Dagger2 » Wed, Jun 24, 2026, 2:29 AM UTC

wolvoleo wrote: post #348

vaylian wrote: post #286

Earlier quoted context omitted.

> Yeah but that ridiculous overdimensioning is something I object to. There's more IPs than is needed to give each grain of sand on this planet its whole IPv4-sized internet. That's just overkill. People also thought that 4 byte wide IPv4 Adresses would be large enough. It's really hard to estimate how much you will need. And because numbers are effectively a free resource, it is better to overestimate. IPv6 also giv…

Well considering the 4 bytes were designed in the time of a small research network between defense and universities, it's great foresight that they made it as big as it is. It still runs most of the internet to this day. But it's not free, after all every packet carries this burden. I know about the annotation but it also makes it very difficult to parse.

That's basically no burden at all. If we cut the address length down to increase throughput, we would get a one-time increase of about 0.8% -- but consider how much faster Internet connections have gotten over the past 30 years. They've improved by about 0.8% per week on average. You're worrying about something that's smaller than one or two weeks of natural progress in Internet connection speeds

Rather than trying to minmax the address length, it makes more sense to sacrifice a few bits per packet to the addresses, wait a week or two on average to get the lost throughput back, and then spend those bits elsewhere to make other things easier. (For example, avoiding NAT is an obvious one, but even just "everything is a /64" removes the need to ever need to think about the size of a network.)

If you can spend a few address bits to make something easier elsewhere, that's a good trade. Maybe start worrying if the addresses were a kilobit long or something, but they aren't even close to that.