Frank Ridderbusch

About things, that are of interest to me (in English and in German).

IPv6 @Home

Friday, 2016-03-25

Intro

In an effort to learn more about IPv6 I created an IPv6 tunnel with SixXS in April 2013. The FRITZ!Box 6360 supplied by the TV cable operator, who also provides the internet access, has all the necessary setup options to operate this tunnel with SixXS in parallel to the standard IPv4 connection.

This has been running pretty smoothly over the last three years and allowed me to collect 370ISK token. Each new tunnel or configuration change with SixXS costs a number of tokens. The tokens are awarded to each user for keeping the tunnel alive and well.

The below graphic is a traffic statistic from the last 3 years. SixXS 3 Year Statistic

And the statistic for only the last year. SixXS Statistic

The Problem

However in the above graphic notice the three arrows pointing to periods, when the tunnel was not running.

When I originally setup the SixXS tunnel, the first step is to configure the tunnel credentials for the SixXS tunnel type. Apart from the tunnel setup, there are some additional IPv6 configuration options under Home Network → Network → IPv6 available. The top button (top red circle) is selected by default, which means Unique Local Addresses are only assigned unless a IPv6 internet connection exists.

FRITZ configuration

This basically worked for 2 years until the tunnel apparently stopped working around November 2015. I don’t know, what actually caused this interuption, whether it’s a new Linux kernel version with a somehow changed behaviour towards the router or if it has something to do with an updated firmware in the router. Anyway, I could only get it going again by activating to lowest button, to alway assign Unique Local Addresses (as it’s shown in the above picture). The other interruptions in February and March I could get going again by temporarily deactivating IPv6. This seems to indicate that the behaviour of the FRITZ router is not kosher.

Actually it’s not exactly correct to say “The tunnel stopped working”. The real cause is the IPv6 configuration of the clients through the DHCP protocol of the router. The client didn’t receive a configuration from the router, which allowed them the successful communication through IPv6. So, essentially the clients stopped using IPv6 for any network communication.

The other two times, when the tunnel basically stopped working, I got it going again, by temporarily disabling IPv6 in the FRITZ box.

I’ve decided to rely on systemd-networkd to start networking instead of the ubiquitous NetworkManager. I’m using this configuration:

# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes
Domains=fritz.box
IPv6PrivacyExtensions=true

If you want to configure it yourself, I suggest you look at the Arch Wiki, which has an excellent description.

After booting the system the network status is:

# networkctl status
●        State: routable
       Address: 192.168.178.62 on eth0
                2001:4dd0:ff00:92e8:be5f:xxxx:yyyy:zzzz on eth0
                fd00::99:xxxx:yyyy:zzzz on eth0
                fd00::be5f:xxxx:yyyy:zzzz on eth0
                fe80::be5f:xxxx:yyyy:zzzz on eth0
       Gateway: 192.168.178.1 (AVM GmbH) on eth0
                fe80::be05:xxxx:yyyy:zz (AVM GmbH) on eth0
           DNS: 192.168.178.1
Search Domains: fritz.box
           NTP: 192.168.178.1

Systemd 228 had some problems after a “suspend to RAM” cycle, which I typically do during weekend nights. After resuming, IPv4 would be working, but to get IPv6 going, I have to manually restart the network daemon.

system restart systemd-networkd

Systemd 229 works better in that respect. IPv6 is correctly set up after resuming. However with systemd 229 the DNS and NTP option are unconfigured after a suspend/resume cycle over night. So I still have to do a manual network restart.

Update 2016-03-25

Apparently Systemd 229 is not better compared to System 228. I suspended my computer yesterday evening around midnight and this is, what I saw after the computer resumed this morning after about another 2 hours of running:

# networkctl status
●        State: routable
       Address: 192.168.178.62 on eth0
                fe80::be5f:xxxx:yyyy:zzzz on eth0
       Gateway: 192.168.178.1 (AVM GmbH) on eth0
                fe80::be05:xxxx:yyyy:zz (AVM GmbH) on eth0
Search Domains: fritz.box

  # ping6 google.com
PING google.com(fra07s32-in-x06.1e100.net) 56 data bytes
From gateway icmp_seq=1 Destination unreachable: Beyond scope of source address
From gateway icmp_seq=2 Destination unreachable: Beyond scope of source address
^CFrom fe80::be05:xxxx:yyyy:zz icmp_seq=3 Destination unreachable: Beyond scope of source address

--- google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2001ms

Only after another systemctl restart systemd-networkd the appropriate network status was restablished.

ipv6, networking