13 ms·
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 parti
by mort96 15d ago
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.
- pfa87 15d ago[dead]
- throw0101a 15d ago> 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. ¯\_(ツ)_/¯
- mort96 14d agoThe 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.
- throw0101a 9d ago> NAT is perfectly fine […] The length of Tailscale's 2020 weblog post "How NAT traversal works": * https://tailscale.com/blog/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 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 https://datatracker.ietf.org/doc/html/rfc1631
- Arya_xiaofan 15d ago[dead]