title: How IPv4 stops me from working in the train --- pub_date: 2019-12-24 --- author: Nico Schottelius --- twitter_handle: NicoSchottelius --- _hidden: no --- _discoverable: yes --- abstract: Real world IPv4 problems: today in the train --- body: On the way in the fast ICE train in Germany. With free Wifi that most of the time works. Well, not if you rely on IPv4. But let's start at the beginning ## Working and hacking in the train As you might know, some members of ungleich are visiting the [chaos communication congress]() this year. I like travelling by train and some days before the congress, I usually verify the security on my notebook, especially network related. ## The Internet doesn't work: is it a firewall problem? While testing my [nftables configuration](https://www.nico.schottelius.org/blog/my-notebook-firewall-36c3/), I was unable to reach the Internet. Fair enough, I am experimenting with my firewall, so things can stop to work on my notebook. After finishing above article I disabled my firewall (yes!) to check whether this is actually a configuration bug. ## Not the firewall Turns out that even after flushing my nftable rules, I am unable to query the local dns server, **172.18.0.1**. So it isn't my nftable rule set. First I suspected that this is due to missing uplink connectivity (I am in a train), it turned out that I am also unable to ping the DNS server. I was not too puzzled by this, as some networks block icmp. However, this is also not the root cause this time. ## Overlapping IPv4 networks Turns out that my LXC/docker experiments created a bridge with the same network as the train is using: ``` [root@diamond ~]# ip r default via 172.18.0.1 dev wlp0s20f3 proto dhcp src 172.18.111.45 metric 302 mtu 1440 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev br-afd64455b4a2 proto kernel scope link src 172.18.0.1 172.18.0.0/16 dev wlp0s20f3 proto dhcp scope link src 172.18.111.45 metric 302 mtu 1440 ``` We usually talk about overlapping IPv4 network problems when merging companies, but this is something potentially more annoying here. ## IPv4 effectively stops me from working So there are a couple of problems with this situation now: [Docker cannot turn off IPv4](https://github.com/moby/moby/issues/32850) at the moment. So even though all my containers use IPv6, I cannot turn off IPv4 and thus I cannot work with the default docker settings in this network. Sure, I can modify the docker network configuration to use a different IPv4 network. But to what? A range in 10.0.0.0/8? I'll have a conflict in the next enterprise network. To a range in 192.168.0.0/16? I'll have a conflict in the next consumer network. There is **no reliable way** to work with docker or any container or virtualisation framework in a network with IPv4 anymore, **IPv4 network conflicts are bound to happen**. ## IPv6 re-enables productivity At the moment I might be one of the more "power users", a person seeing this problem early However when it gets more common for people to develop on their notebooks or if any operating system defaults to run applications in containers (like [Canoncial's snap](https://snapcraft.io/), this problem will occur more often. That said, none of this would be a problem if the train provider, in this case Deutsche Bahn, would switch to an IPv6 only network with NAT64. So if you reading this and you run a network, please **switch to IPv6 only networks** to permanently avoid headache. It is urgently needed. ## More of this If you are new to IPv6 or if you want to discuss IPv6, I invite you to join me on the [IPv6 Chat](https://IPv6.chat). If you want to give IPv6 a try, you can do that easily on [IPv6onlyhosting](https://ipv6onlyhosting.com).