Hacker News Reader

Comment by usr1106 | Hacker News Reader

The root cause is the ridiculously small private address space in IPv4. Conflicts have a non-negligible probability. You might even want to use a container on the train, so the daemon is not the root cause of problems in this case.

Using IPv6 would have reduced the probability a lot. But the excuse for the last 20 years has been, why bother with learning something new as long as "it works for me"... (I don't claim I would do differently.)

View on HN

I won't address the IPv6 landmine here, because that is its own can of worms, and there are plenty of real, legitimate criticisms for not adopting it.

That aside, while I do agree that small private IPv4 space availability is a real concern, I'd also argue that Docker choosing to make the default network size a /16 compounds this problem significantly. I've never had a workflow where a Docker network needed more than a /24, and most could get away with a /26 or /27 without it being considered an aggressive limitation of IP space. Assigning the default Docker network size to something much more reasonable for a development context would do wonders for limiting collisions like this in the first place.

I mean the "excuse" as you call it is more, "why bother with learning something which doesn't work when I could use the thing which works, even if it's imperfect". I'd bet the train wifi doesn't support IPv6.

I agree. It absolutely is IPv4. Hosts could use DHCPv6 with prefix delegation (DHCPv6-PD), and use that delegated /64 for its internal Docker bridge and get rid of NAT. And yes, you can still have your Netfilters stateful packet filtering in place! People are going through so much pain because they won't embrace the tools IPv6 gives you! This solution is 20 years old. God help you if your network is actually using 172.17.0.0/16. grumble grumble get off my lawn, kids.

Reply on news.ycombinator.com