„Coding is solved” or something, I dunno, I’ve landed on another continent the moment I’ve barely touched the screen.

Someone at my office said "code is a commodity now". I would personally say that slob code indeed has become a commodity.

Code is a liability, generating more of it is solving the wrong problem.

Every Fucking Website 2026:

- Paragraphs emerge from the background as you scroll, sometimes only after 3/4 of your screen is empty.

- Some paragraphs are hidden until you expand them. You can’t expand more than one at a time.

- Horizontal scrolling for some items, like e.g. meal categories in a restaurant. The buttons for the scrolling are different on each site, or are dots you must click on.

I'm not sure why you're asking here instead of opening the ticket and having a look at the current status.

It's not a bug but a suggestion rejected by the team (cuttent status: Won't fix, obsolete)

> I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

iPhone does that, and I’m pretty sure I’ve seen Android doing the same. The phone keeps a single /128 from the /64 assigned by the mobile network on its mobile interface and the re-assigns the /64 on the WiFi interface. No NAT is involved.

> Nothing is stopping an ISP from implementing it by taking one ip and assigning ports 1-10.000 to customer A, 10.001 - 20.000 to customer B, and so on. Similarly, nothing is stopping an ISP from adding long-lived mappings to an otherwise-random pool which outlive the initial connection.

I’m pretty sure that the scarcity of Legacy IP addresses and port numbers (!) is exactly what stops providers from doing that, at least by default. I’ve seen NAT running out of ports way too many times, and shortening of connection tracking lifetime comes with a whole set of hard to spot bugs.

> Even if you want to geek out and manage it yourself, a VPS is a very attractive option.

And some VPS providers already started charging extra for hosting the server on Legacy IP.

While debugging some issues in some system Claude refused to write test case because it broke terms of use.

Oh shit, all this fantastic technology is in hands of corporations and they get to decide what we’re allowed to use it for.

The availability of GitHub is still at 0% - it can't be reached over IPv6.

> not fully compatible with OpenBSD one

The OpenBSD NAT and scrub syntax, and af-to are available in FreeBSD 15.

Even with IPv6 you still might have stateful firewalls allowing only for outbound connection at both ends (e.g. a CPE a.k.a. “WiFi router”) and to establish communication you’d need to punch a hole in those firewalls.

That’s true we won’t get rid of hole-punching with IPv6. But at least it will get rid of TURN.

The hole punching is so much simpler because you don't need to guess your own address and port - you just know it

IPv6 still allows proper NAT (prefix translation), but even then finding your global address wouldn’t need TURN, just STUN, actually not even that, just a service like “What’s My IP.”

It does allow it in the sense that it's possible, and even useful in some scenarios, but then you're on a weird experimental network and not a normal one.

Yes, you are right, quite literally, as RFC 6296 is marked ‘experimental.’

Doesn't that assume that your machine is given its own world-routable (and unfiltered) v6 address?

That's how it works in ipv6. If your network doesn't give you an address, it's broken. We do not assume unfiltered since we are talking about hole punching.

How will it get rid of TURN? Can't IPv6 addresses still be firewalled by your carrier like they do already for IPv4?

I thought TURN was for symmetrical PAT, not for proper NAT (which just needs STUN for address determination) or full/restricted cone PATs (which need STUN for address and port determination, and then, in case of restricted cone, performs a hole punch).

Standard-conforming IPv6 at most allows prefix translation (i.e., proper NAT, not PAT), which wouldn’t need it.