ipv4 stops me from working

content/u/blog/how-ipv4-stops-me-from-working-in-the-train/contents.lr

@@ -0,0 +1,105 @@
+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).