Hacker News Reader

Comment by craftkiller | Hacker News Reader

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.

View on HN

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.

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?

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.

You don't put your server IP in your DNS? You type the IPv6 address every time?

A lot of servers expose something public so they can be found. Otherwise what's the point of being publicly accessible?

You can't just list out all the DNS names. The three ways that names get discovered are:

1. You listen on IPv4 and someone probes all the IPv4 space and your server announces "Hi, I am web123.example.com" or similar in its responsible

2. You have HTTPS on the server and the HTTPS address ends up in the certificate transparency logs.

3. You have a public service on that server and announce the address somewhere.

But when you have billions of IP addresses, why does SSH need to listen on the same address as HTTPS or anything you're running publicly? It's also infeasible to probe the entirety of IPv6 space the way you can probe all of IPv4, even though we're only assigning addresses in 3/65535 of it right now.

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.

Reply on news.ycombinator.com