105 lines
3.7 KiB
Text
105 lines
3.7 KiB
Text
|
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).
|