3 ms·

Heh. The only reason things are the way they are now is that the proponents of IPv6 were some cocky idiots who believed transition systems were not necessary be

by vahno 8y ago

Heh. The only reason things are the way they are now is that the proponents of IPv6 were some cocky idiots who believed transition systems were not necessary because IPv6 was the best thing since sliced bread and IPv4 was going to implode anyway. Looks like they've been proven wrong. ISPs are happily using CG-NAT, all services are being adapted to that (moving away from p2p like Skype did) and end users don't care too much. Ouch!

pilif 8y ago
> ISPs are happily using CG-NAT I wonder how "happily" they are using CG-NAT. NAT is inherently stateful and keeping track of that state becomes more expensive as the amount of hosts behind the NAT is increasing. Running CG-NAT at scale is complicated and resource-intensive, so I'm totally willing to imagine that it's better long-term value for a carrier to switch to IPv6 than to expand CG-NAT.
- AstralStorm 8y ago
  You cannot for now just stop providing the CG-NAT, not when so much of the Internet is still v4 only. V6 deployment will reduce the load on it though.
- vahno 8y ago
  ISPs don't usually care too much about long-term value. When most of your core network is IPv4-only, getting some CG-NAT equipment is indeed cheaper than buying a completely new core network.
- londons_explore 8y ago
  The cost of maintaining the state tables used to be a concern in the ninties... Right now, my laptop has 4 open TCP sockets, and my phone has 3. Even assuming the average user has 50 sockets open, and assuming you are an ISP with 300 million users, that's still only 175 gigabytes of RAM. The total cost is under $1000, or peanuts for what would be the worlds largest ISP.
  - kazen44 8y ago
    except that for high performance networking, storing stuff in normal RAM is simply not an option if you want to keep an acceptable throughput. (>40gbit). One would need to store NAT state in some sort of TCAM/CAM table. Guess what, having a 175 gigabyte of (T)CAM is drastically more expensive.
Dagger2 8y ago
v6 has dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... it has pretty much every possible transition method that can work with v4. You could make a reasonable argument that it has too many of them, even. Where did you get the idea that we didn't think it needed any?

by vahno 8y ago

pilif 8y ago

> ISPs are happily using CG-NAT I wonder how "happily" they are using CG-NAT. NAT is inherently stateful and keeping track of that state becomes more expensive as the amount of hosts behind the NAT is increasing. Running CG-NAT at scale is complicated and resource-intensive, so I'm totally willing to imagine that it's better long-term value for a carrier to switch to IPv6 than to expand CG-NAT.

AstralStorm 8y ago
You cannot for now just stop providing the CG-NAT, not when so much of the Internet is still v4 only. V6 deployment will reduce the load on it though.
vahno 8y ago
ISPs don't usually care too much about long-term value. When most of your core network is IPv4-only, getting some CG-NAT equipment is indeed cheaper than buying a completely new core network.
londons_explore 8y ago
The cost of maintaining the state tables used to be a concern in the ninties... Right now, my laptop has 4 open TCP sockets, and my phone has 3. Even assuming the average user has 50 sockets open, and assuming you are an ISP with 300 million users, that's still only 175 gigabytes of RAM. The total cost is under $1000, or peanuts for what would be the worlds largest ISP.
- kazen44 8y ago
  except that for high performance networking, storing stuff in normal RAM is simply not an option if you want to keep an acceptable throughput. (>40gbit). One would need to store NAT state in some sort of TCAM/CAM table. Guess what, having a 175 gigabyte of (T)CAM is drastically more expensive.

Dagger2 8y ago

v6 has dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... it has pretty much every possible transition method that can work with v4. You could make a reasonable argument that it has too many of them, even. Where did you get the idea that we didn't think it needed any?