← Back to context

Comment by jpdb

5 days ago

That particular benefit has no value if you still need to support v4.

It's almost a self-inflicted tragedy of the commons or reverse network-effect.

Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.

It still helps. I have a 1U in a colo which gives me a /64 for ipv6 and ~5 addresses for ipv4. I just set up a dual stack kubernetes cluster on 6 virtual machines. When I want to ssh into one of the machines, my options are either:

  1. Use IPv6 which works and goes directly to the virtual machine because each virtual machine grabs its own address from one of my 18446744073709551616 addresses.
  2. Use IPv4 and either have to do a jumphost or do port forwarding, giving each virtual machine its own port which forwards to port 22 on the virtual machine.
  3. Use a VPN.

I have all 3 working, but #1 was significantly less setup and works the best.

Also being able to generate unique ULA subnets is super nice.

  • Really using port 22 is very ill advised anyway because you will get constant nuisance brute force attacks (accomplishing nothing because you're using keys or certificates I hope) but still eating up cycles for the crypto handshake.

    • By that same logic, using IPv4 is ill-advised because I could easily give the ssh endpoints their own IPv6 addresses, avoiding the need to hide behind non-standard ports. Scanning through 18446744073709551616 addresses is going to be a lot slower than scanning through 65536 ports.

      2 replies →

    • I've had SSH open on a static v6 that isn't even SLAAC or temporary, it's not my/58::1 but not far off and in DNS, and I have not in 8 years seen a single scan or connection attempt over IPv6 (other than myself). This is not to say there is no risk, but it really is a night and day difference.

    • Really? I get somewhere in the region of none to barely any, depending on the server.

      I mean, yes, you'll get a constant stream of them on IPv4, but why would you run a server on v4 unless you absolutely needed to? The address space is so small you can scan every IP in 5 minutes per port, and if you have my v4 address you can enumerate every single server I'm running just by scanning 65k ports.

      Meanwhile, on v6, even the latter of those takes a thousand years. How would people even find the server?

If you are an ISP running dual stack ipv4 with NAT plus ipv6, the more connections happen via ipv6 and the more traffic happens via ipv6, the better, because it doesn't have to go through the NAT infrastructure which is more expensive, and cost scales with traffic (each packet needs its header to be modified) and number of parallel open connections (each public v4 address gives you only 65k port numbers, plus this mapping needs to be stored in RAM and databases).

> Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.

Sure it does: the more server-side stuff has IPv6 the fewer IPv4 addresses you need.

If you have money (or were around early in the IPv4 land grab) you have plenty of IPv4 addresses so can give each customer one to for NATing. But if you don't have money to spend (many community-based ISPs) you have to start sharing addresses (16:1 to 64:1 is common in MAP-T deployments). You also have to spend CapEx on CG-NAT hardware to handle traffic loads.

Some of the highest bandwidth loads on the Internet are for video, and Youtube/Google, Netflix, and MetaBook all support IPv6: that's a lot of load that can skip the CG-NAT if the client is given a IPv6 address.

If you can go from 1:1 to 16:1 (or higher) because so few things use IPv4 that means every ISPs can reduce their legacy addressing needs.

On company/university wifi networks, v6 cuts your v4 DHCP pool address usage by something like 70%, without hurting connectivity to v4 hosts.

You can run a V6 first network with a tiny bit of v4 sprinkled in on the edge where it's needed. The tech to do this is mature and well understood.