Hacker News

Sure they didn't just mean they'd change your static IPv4 address to a different one?

The slow adoption of IPv6 by many older companies is at least in part a paradoxical result of the success of IPv6 elsewhere, particularly in new builds where there is practically no overhead in deploying IPv6 in a green-field environment - see for example the mobile telecoms market in developing countries, where new builds are IPv6-first.

This has taken pressure off the IPv4 legacy address pool, reducing the urgency for older providers.

End-users are typically completely unaware of whether their traffic is being carried over IPv6 or IPv4, and so simply do not care one way or the other. (This particular post is more than likely being made over IPv6, since news.ycombinator.com has an IPv6 address and my OS, browser, router and ISP all support IPv6 straight out of the box, as is now true for the majority of users in my country.)

Right. Which is why this is not a choice businesses should be allowed to make.

They also got hacked recently and all their customer details were published.

PS: From the millions of customers' details leaked it sounds like their market share is a hell of a lot higher than 17%!

It is difficult to retire with house equity. Housing is just one element of what you need to have in retirement and after a certain point, and especially in retirement, once the house is what you plan to stay in forever it is better if it is worth less (all other social factors aside) so that you don't pay as much in taxes on it.

Be a good neighbour, the AI data centres need to live somewhere.

Prices have been coming down for years in nominal terms, let alone real terms. Cg nat does everything that’s needed, there are no significant ip6 only services, there are plenty of ip4 only services, so you have to support ip4 anyway, so why bother with ip6

My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.

All the “promise” of ip6, direct connections etc, were lost when stateful firewalls became required and memory became cheaper than $20 a megabyte. Some bespoke old protocols don’t like ports changing, which can be a problem, but it’s a very small number and easier to work around with modern protocols than support a dual stack environment securely for the majority of places that struggle securing a single stack.

About 2023 I think

>Every ISP has to pay Hurricane Electric for their tunnels, that's why it's free to you.

Is there a law mandating this?

And wouldn’t it add a considerable latency?

Old Nanostations as a client need to do proxy arp or something, which doesn't handle ipv6. That said it's probably 15 year old hardware. I ended up using a wireguard tunnel across it instead.

The corporate world tend to be easy to do, just put a gateway to IPv6 on their zScaler (or similar) exit points and done. However, that is not really needed as they are "only" consuming a few IPs around the world (for that purpose). No one in the corporate world wants to go back to the days of Public IPs on all devices. Internally the enterprises have no reason to switch as it just complicates their setups.

TP-Link hardware is decent, if you buy one with OpenWrt support.

I don't think this is inherently a problem. It's good for home routers to have sensible defaults. Blocking incoming IPv6 connections is such a thing. Opening a port in the firewall shows the same kind of intent as forwarding a port with NAT. The burden is on the router manufacturers to expose these options in a sensible way. My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.

Using NAT as a firewall might work but it brings it's own problems. I find the IPv6 way better.

> There was a time when the designers believed that you'd use your 48 bit MAC address as part of this. Now we know that's a PII nightmare and nobody does it.

Nobody includes their MAC address in their public IPv6 addresses anymore, but every IPv6 setup that I've seen still gives every device a unique globally-routable IPv6 address, with no NAT at all.

> One of my favorite is the decision to default to /64 blocks.

The nice thing is that a /64 is big enough that clients can just randomly pick any address, and it will almost certainly be available, meaning that you don't need DHCP. This is actually widely implemented, and is known as SLAAC [0].

> Yet we're still stuck with the 128 bit addresses that came from that.

The extra address space only adds 16 bytes to every packet, and it ensures that we will never run out of addresses like we did with IPv4.

[0]: https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...

The point of local networks of a minimum size of 64 bit isn't only to have MAC-based addresses (48 bit would have been enough for that, fwiw), but in general to support non-coordinated/probabilistic self-assignment schemes with negligible collision probability.

Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).

> So is the bigger address range better?

Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.

Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.

> Now we know that's a PII nightmare and nobody does it. Yet we're still stuck with the 128 bit addresses that came from that.

Randomizing the local address doesn't mean it isn't useful. You can't scan a /64 so that's already a major improvement. The fact that randomly selecting a number is effectively never going to collide greatly simplifies automatic network configuration.

The major issue is that the /64 isn't mandatory from a technical perspective. Being merely a subset of the larger address it's nothing more than a convention. In the end not all providers make it available to you even though supposedly they ought to.

If we're going to complain about anything it should be the godawful notation that so easily breaks parsers. Or the fact that the width is massively excessive which creates a usability nightmare due to normal humans not being able to readily recall 128 bit numbers (let alone how long it takes to type them in).

> IPv6 doesn't have that intent, which forces home router makers do block addresses by default because you don't want most PCs on the Internet such that an external agent can scan your PC. You may end up with an unintended service on the open Internet.

Every residential router already has PCP (RFC 6887) and UPnP IGD to deal with the NAT44 non-sense that is the status quo, and both protocols support IPv6 hole punching, so IPv6 default deny as a policy is hardly an issue in the residential space.

MiniUPnPd, which many Linux-based CPEs use, has supported IGDv2 (needed for IPv6) since 2012 (as well as PCP).

Well, France has 99% IPv6 deployment through both mobile and landline these days

https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...

(2025, from 2024 data)

Reason that Google isn't seeing more is a) some BigCo v4 holdouts b) happy eyeballs sometimes landing on v4 because their v6 is shitty 6rd or something (e.g Free SAS)

Here in Belgium it's the other way around. we've had IPv6 for over 10 years for basically all home internet, but mobile is still ipv4 only. Not sure why since it's all the same companies.

I'd however mention, the two biggest ISPs that remain today both have adopted IPv6 on their fiber connections. They're also heavily using CGNAT for IPv4. It makes sense, the volume at which they're working makes dedicated IPv4 very uneconomical.

My home internet has IPv6 but my mobile carrier doesn't. IPv6 on mobile carriers is unfortunately still not universal.

People connect through cellphones more on weekends, and cellular has higher IPv6 usage.

People connect from home more at the weekends and home ISPs support ipv6 more than offices do.

In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.

This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.

Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.

Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean. This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.

Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.

I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.

It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.

The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.

True but not deploying any IPv4 connectivity would be a worse experience than not deploying IPv6.

I have yet to see any ISP use CGNAT here in Sweden. It seems to be a highly regional problem for some reason. Both on mobile and on broadband I get publicly routable IPv4.

When CGNAT is present, my guess is that's the case. It would be nice to see a study on that; don't know if there is one already.

Users doing speed tests in CGNAT may be seeing numbers that aren't exactly real for a (still) mostly IPv4 Internet.

That depends on your isp. Mine certainly doesn’t, and I’ve never had an isp on the U.K. which didn’t give me at least a dynamic ipv4 address to my router.

Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.

That fraction of a millisecond doesn't meaningfully translate into a better experience for users.

Sparing a few hundred microseconds of latency is tangibly a better experience?

and anything P2P. Maybe that would have been a driver 20 years ago, but now everything is expected to be centralised. Our culture has shifted. Remember when people used to host their game servers? If you're under 16, you don't because it was never in your lifetime.

I was saying adding a byte to the address so its a 40 bit address which would be two bytes to the header. Obviously it would still have the same issue where hardware and software would be incompatible and would need to be replaced but the same concepts that worked in IPv4 would work in my fake protocol instead of IPv6 where the network needs to be redesigned from the ground up.

Also IPv6 addresses are ugly

Yeah but they could've picked something that at least lets the 4 byte host talk to a 5 byte one. Like if I have 8.8.8.8 and they want to give me 8.8.8.8.0, cool. Or make it 8 bytes instead of 5, same thing.

For people like me: DS Lite stands for "IPv6 dual-stack lite". My mind went directly to Nintendo and I was confused.

Unfortunately, individual actions would never be enough to solve the IPv6 chicken and egg problem. See djb's "IPv6 mess" article:

https://cr.yp.to/djbdns/ipv6mess.html

Yes, it is old, many examples are outdated, but the main points still hold. Decades later his suggestions for making IPv6 succeed are still not implemented.

For client server web browsing what's the downside of CGNAT? I'd understand if we were talking about self hosting a service from home but for typical consumer usage?

So your isp is rinsing you for the cost of a an IPv4 address. £10 a month will pay for a whole /24 in 3 years.

Chances are they also skimping on other areas including over subscription. Choose a better isp if you want a better service.

Your “just open traffic to internal host 1 on your firewall is the same no matter if it has nat or not, unless you are using a non stateful firewall? Or perhaps your configuration layer splits the two for reasons.

Thank you for the advice. By any chance, have you worked with Ruby before? I remember seeing your username back when Ruby was popular and I first started learning it in university

I accidentally became the user of an IPv6-only device a while back for some obscure reason I never could figure out. Let me tell you: There are no IPv6-only users. Absolutely nothing except Google, Facebook, and YouTube works. Any website not in the top 20 are IPv4-only. It was so bad I briefly thought I didn't have an internet connection at all. Anyone stuck on an IPv6-only connection would immediately cancel their contract on the grounds that they don't have de-facto internet access.

Shouldn't blocking v6 also be based on /32 if you want the attacker's cost to be the same?

Larger. A /56 and get multiple hits from nearby /56s and you block the /48.

If your ipv6 internet is broken you should probably turn it off on your router - hosts on the LAN can still communicate using ipv6 link-local, as some apps will want to do.

It is harder to maintain two networks instead of one. Potential problems double. Hacks like RFC8305 "Happy Eyeballs" become a must.

Fair enough. I do question it often.

It's a standard Asus router but it's given me a lot of ire. I hate to say it but it's never a problem when I install windows on the same machines

(I'm currently in the process of trying to completely remove windows from my life)

After 30 years, with 99% of servers and devices having been designed decades after ip6 was created, half of traffic is still ip4.

If that’s not a failure I hate to see what is.

It was also predicted that the address exhaustion problem would be averted, in fact that was the purpose of v6. It failed to deliver.

2 is a security nightmare but that’s why firewalls prevent it by default

3 well you can set the dont fragment bit at a client side or a router can drop the packet. These are choices. If a 1500 byte IPv6 packet arrives on a router with an 1100 byte next hop, does it just drop? Or send back a fragmentation needed icmp? How is that different from setting a “don’t fragment” option on a router.

4 isn’t created from a security or management point of view either. And v4 has the 169.254 range for this purpose. I guess the lack of router advertisement is the primary difference. And the operational expectations.

5a I’m not sure about. My main experience with multicast is pim-sm on v4. SSM v4 multicast however seems simple, and while I don’t use it as I have kit that’s too old for it is v6 really easier than v4/ssm/igmp3?

As for arp, I don’t see any real complexity with it as a network operator, but maybe that’s because I’m used to it. Perhaps it’s easier to implement nd rather than arp, but given almost every v6 deployment for the last 30 years is dual stack all it does is increase complexity.

NDP is not simpler than ARP. For one, NDP relies on link-local addresses to work which in turn relies on MAC multicast where ARP relies on MAC broadcast only.

The only one I don't understand is how NDP is simpler than ARP. ARP is an Ethernet broadcast while NDP is built on IPv6 multicast which creates a recursive chicken and egg situation.

Considerably simpler? There's two ways (maybe more?) to autoconfigure v6 addresses on a host, I'll never know or remember which to use. In v4 there's DHCP, that's all you need to know (nobody uses BOOTP). These endless choices go on and on with v6 with umpteen transition technologies to work with v4.

> apart from the chicken egg problem

"But other than that, Ms. Lincoln, how was the play?"

Just remove the A record, and nearly all the scrapers disappear. :-) (And then you get one email per month or so that “your host does not resolve in DNS”.)

Google is having a real issue with LLMs using it for search. As in, real load issues. Unless you're running a publicly accessible search engine, and the top one at that, the LLM traffic you're seeing is not representative.

And there’s no reason we should be limited to 128. It’s all just so dated and stagnant.

Chips can be made that dwarf that limitation, instead we’re stuck with this decade old nonsense to “work around” again.

Flip flopping between “the code needs it” and “the chips need it”.

The issue the GP is making is that rather than devising a whole new protocol altogether, including resolution and assignments, other things like that, adoption likely would have been much faster and wider.

Had the original plan been simply "extend address space" instead of "extend address space and while we are at it revamp and rewrite every part of the whole scheme including assignment, discovery, and everything else we see wrong with ipv4"; we would be in a much better place.

Adding extra address bytes would of course require new changes across the internet, but that change would be easier to swallow compared to having to rip and replace large swaths of processes to make ipv6 work because of all of the other changes that came with ipv6.

Also, the stupid idea of turning addresses to hex as the default, and more specifically the dumb :: shortening methods really made it confusing for everyone and didnt help at all in the efforts.

Yes, we want ipv5 that just does 1, 2, 3 instead of ipv6 which does the most complicated variants of those and more. We didn't have requirements 4. change all the pre-existing addresses 5. make addresses randomly assigned 6. make routers accept inbound connections by default 7. give every device its own public IP by default. Ipv6 did those anyway.

Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.

getaddrinfo was added after ipv6. Software had to be rewritten to use getaddrinfo.

Prior to that programs used gethostbyname() etc, which only works with ipv4.

Are you just talking about how you write the addresses or are you talking about the actual protocol?

The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more.

If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.

They added 12 more octets. I mean we could have written IPv6 addresses in the old format but I don't think that

42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113

is easier to remember than

2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)

You have not heard if before, because that is the most naive and stupid take imaginable. It is the “let them eat cake” of networking.

It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers?

You would still need to replace all of the software and hardware and have the exact same problem.

One big advantage of IPv6 local addresses is that you can pack a lot of semantic information in an address that's easy to remember, plus bits to help with routing and/or firewalling if you need.

DNS and mDNS don't "just work". You don't need but probably really want HA for DNS which is overkill for a homelab user, and you really want a fixed address for that DNS, because who wants to fix issues when you can't even address your services, and you really want your routers to have fixed addresses for the same reasons; you need VLAN and/or Avahi reflecting for mDNS, and if you need firewalling on your LAN, have fun dealing with the fact that mDNS clients prefer GUAs, then IPv4s, then ULAs in that order, by RFC rule, and having managing GUAs sensibly when your ISP keeps changing your prefix -- well, IPv6 is almost 30 years old and home/SMB equipment still can't handle that reliably or flexibly, if it even lets you do anything besides assign /64s, and there's nothing stopping your ISP from saying "here just have a single /64, sorry if you wanted to actually use IPv6 for anything clever like having multiple subnets, who would ever want that?" So you say "I'll just use DHCPv6" and it turns out that DHCPv6 kind of sucks and it also turns out many devices don't support that by default or at all, including every single Android and Chrome device, for starters.

IPv6 is full of these design issues where you have a lot of things that are supposed to Just Work, Look It's So Much Simpler Than IPv4, and look at all these address bytes (excuse us while we take 64 of them away for no reason), except you discover that nothing Just Works with anything else in mildly nontrivial cases.You end up on a yak shave only to discover no yak underneath. The whole story above is just one example. IPv6 is a migraine in RFC form, and if it weren't that I accidentally bought some expensive IOT devices that are IPv6-only, I'd be happy to never touch it. At this point, it would have been a better time-money tradeoff to have thrown those in the trash as soon as I had seen the problem.

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.

And the problem seems to be solving itself as the world is turning its back on globalism. China and North Korea already have separated themselves. Iran too. China still uses the same address space but it's not like there's open connectivity with the rest of the world. We'll probably cut off Russia at some point completely as part of some sanction (they've been preparing for that for years), and Europe will break with America if things continue. We'll just have interoperability at a few controlled border points then, like China already does with its great firewall. It'll be easy to do some address translation then.

Ps that's not something I'm necessarily happy about but I do see this trend emerging of every region trying to wall itself off.

If ipv5 worked just like ipv4 except with a larger address space, it would be easier than moving to ipv6. I shouldn't have to change my address to switch for example.

But for an IPv4 device I only have to remember one number :) And nothing to do with a long random serial number.

It wouldn't. I've gone down this rabbit hole in another thread, tldr there are alternatives that would've been easier initially but with the downside of leaving the routes fragmented.

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