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