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 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 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.