Hacker News Reader

Comment by ndiddy | Hacker News Reader

Yeah I feel like a lot of the people criticizing this are still being client-server brained. There's a lot of use cases that "everyone is a server" would open up without turning everyone into a sysadmin and they'd likely get turned into user-friendly software like BitTorrent or Skype or early Spotify.

View on HN

"Client-server" thinking may in general be a 'hobbled' way of thinking of things.

It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT.

All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.

> For p2p, you need both parties to not be behind CGNAT.

I have been told in many HN discussions that IPv4 is good enough and that IPv6 doesn't solve any problems. ¯\_(ツ)_/¯

The problem is that everyone who's championing IPv6 is talking about how it makes NAT unnecessary and about how bad NAT is. See TFA as one example. NAT is perfectly fine, so all the IPv6 boosters who make this huge deal of it get dismissed as IPv6 hype men. "Every household gets an IPv4 address which is shared between their computers using NAT" is a good solution.

The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem. It took a long time before I understood this due to all the noise IPv6 people make, but newer ISPs don't have enough IPv4 addresses to give every household its own address, so they use CGNAT for residential Internet access. This is what people should be focusing on, but it's not. All arguments for IPv6 are irrelevant drivel about how bad NAT is.

> NAT is perfectly fine […]

The length of Tailscale's 2020 weblog post "How NAT traversal works":

* https://tailscale.com/blog/how-nat-traversal-works

and their 2025 "NAT traversal, and how we're improving it (pt. 1)"

* https://tailscale.com/blog/nat-traversal-improvements-pt-1

indicates the opposite to me.

Certainly there are still (SPI) firewalls with IPv6, but at least with CPEs things are limited to 'only' hole punching with PCP (or UPnP) as opposed to all the ICE/TURN/STUN layers (and heaven help you if you're behind CG-NAT).

> The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem.

NAT was intended to be a "short-term solution" as noted in the NAT RFC (from 1994):

* https://datatracker.ietf.org/doc/html/rfc1631

There's DC++, Tox.

Reply on news.ycombinator.com