6 ms·

> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. Skype was originally peer-to-peer for comms,

> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port. But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.

ndiddy 1mo ago
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.
- throw0101a 1mo ago
  "Client-server" thinking may in general be a 'hobbled' way of thinking of things.
  - mort96 1mo 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 1mo ago
      [dead]
    - throw0101a 1mo 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 1mo ago
        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.
        throw0101a 29d 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
- GoblinSlayer 1mo ago
  There's DC++, Tox.
- Arya_xiaofan 1mo ago
  [dead]
mort96 1mo ago
> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port. This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port. More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port. (I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)

ndiddy 1mo ago

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.

throw0101a 1mo ago
"Client-server" thinking may in general be a 'hobbled' way of thinking of things.
- mort96 1mo 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 1mo ago
    [dead]
  - throw0101a 1mo 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 1mo ago
      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.
      - throw0101a 29d 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
GoblinSlayer 1mo ago
There's DC++, Tox.
Arya_xiaofan 1mo ago
[dead]

mort96 1mo ago

> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port. This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port. More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port. (I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)