/home/adrian

» The joys of IPv6

» September 24, 2015 | english linux network opinion | Adrian Kummerländer

A couple of weeks ago I moved to Karlsruhe where I will study Mathematics starting this fall. Among other things this meant that I had to search for an Internet provider for my new appartment. Previously I used a DSL connection by Telekom which offered nothing to complain about if one disregards the abysmal bandwidth available in my small home village in southern Germany. Luckily my new appartment offers the option of accessing the Internet via TV-cable instead of POTS which promises a better connection bandwidth than DSL even in the city. As my new provider uses a special kind of dual stack system I was finally confronted with IPv6 and want to summarize my experiences in this article.

Besides the promise of a better bandwidth and despite my good experiences with their connection over many years the main reason for considering alternatives to Telekom was that they don’t offer the kind of Internet-only package I wanted. At first I also considered a O2 DSL connection because I already use their mobile offerings but as I recently suffered problems with their contract management when they mixed up my contract with the contracts of my family members I opted to disregard them in favor of Unitymedia¹.

After some initial confusion when I received the router days before my connection was installed without any communication² concerning this waiting period, my new Internet connection works as well as expected with stable response times and ~ 6 MiB per second downstream.

Remaining problems with Unitymedia

As I still work as a part time software developer at my former training company but live in Karlsruhe I do most of my work remotely. While the bandwidth requirements for this task are negligible some of our customers require IPSec based VPNs in order to access their SAP systems. Sadly the special IP-packets required for this kind of VPN seem to be dropped by Unitymedia which means that I require an additional Level-2 VPN to a non-dropping connection in order to use these VPNs. But all things considered this is still an acceptable tradeoff.

If one reads forum and blog posts concerning Unitymedia’s service one will find lots of whining about their DSlite technology for providing a dual stack IPv4 and IPv6 connection. This is mostly because they don’t seem to have enough IPv4 addresses to offer each customer their own address. This means that IPv4 addresses of DSlite connections are shared between multiple customers³. The only globally accessible address each customer gets is a IPv6 address - for each device connected to the router.

This brings me to the main point of this article: IPv6 instantly enables all my devices to be globally accessible without any hindrances such as NAT hopping. With IPv6 the network address translation system of IPv4 is not required anymore - there are enough addresses for everyone. This also defeats many of the complaints about DSlite as one simply doesn’t need IPv4 natting, port forwarding and dynamic DNS providers anymore.

The vision

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group 
default qlen 1000
    link/ether 00:50:##:##:##:## brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.2/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a02:8071:####:####:###:####:####:####/64 scope global mngtmpaddr 
    dynamic 
       valid_lft 604799sec preferred_lft 302399sec
    inet6 fe80::250:43ff:fe01:6d36/64 scope link 
       valid_lft forever preferred_lft forever

As we can see my examplary device connected to my new provider’s router not only gets the normal IPv4 and IPv6 subnet addresses but also a scope global IPv6 address which is accessible from any IPv6 enabled host on the Internet using e.g. ping6.

This does away with the smokescreen that is NAT in IPv4 and forces one to consider that all devices connected to the Internet are a potential target and act accordingly by e.g. setting up iptable firewalls on each and every device.

IPv6 opens the Internet up in a sense as I now don’t have to forward any ports in my router anymore and can access my personal mail server from everywhere without any further setup on the clientside. Furthermore I can ssh into every one of my devices from every other device without thinking on how to circumvent the given NAT hiding the devices from each other. I look forward to the time where IPv4 is replaced by IPv6 accross the board and the Internet looks more like a decentral mesh of all participating devices again.

The only challenge standing in the way of actually being able to do all the nice things mentioned above is that not all Internet providers are already assigning IPv6 addresses to all their customers. This means that I currently can not directly access IPv6 hosts from both my home village and mobile connections. Luckily this issue is easily circumvented by tunneling those connections through a Layer-3 OpenVPN setup.

Bringing the joys to all devices via OpenVPN

While I already had various OpenVPN instances set up on both my virtual server hosting this website as well as the SheevaPlug, neither of them were IPv6 enabled. This required some trickery to change - especially in combination with my chosen iptable manager UFW and some systemd details previously unknown to me.

proto udp
proto udp6

dev tun
tun-ipv6

# [...] certificates

server      10.8.0.0 255.255.255.0
server-ipv6 2a01:4f8:c17:77a:4000::/66

# [...] further unrelated settings

push "redirect-gateway def1"
push "redirect-gateway-ipv6 def1"
push "route-ipv6 ::/0 fe80::1 100"

These are the relevant sections of the server configuration of my IPv6 proxy VPN. The proto udp6 flag enables access to the VPN via IPv6. tun-ipv6 enables IPv6 support on the TUN interface created by OpenVPN while the server-ipv6 statement declares the global IPv6 subnet designated for clients of the VPN⁴. Finally the push directives tell the clients that they should route all their IPv6 traffic through the VPN.

To make this configuration work one also has to add the following statements to the head of /etc/ufw/before.rules⁵:

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Allow traffic from clients to ens3
-F
-A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE

Additionally the net.ipv6.conf.all.forwarding parameter has to be set to 1 using e.g. sysctl. If you also use systemd-networkd as your network manager, make sure that the parameter IPv6Forward is set to yes for your external interface.
Note that these are all the settings I changed while playing around in order to make the VPN work - it very well may be that not all of them are strictly required.

If you don’t access the VPN server via IPv6 which is obviously the case if you require it to gain IPv6 connectivity in the first place, no changes to the client configuration should be necessary.

Remaining problems with IPv6

One disadvantage of IPv6 in comparison to IPv4 is that the addresses are not as easily remembered anymore which is sadly an inherent issue if one wants to increase the available address space from only 32 to 128 bits⁶.

One possible solution for this is to build some kind of private DNS that announces the IPv6 addresses of all my devices so they can more easily find each other. But before doing that I will first wait until the SheevaPlug gets assigned a new IPv6 address by my provider - in the best case that will never happen.

There are some privacy concerns around this property of IPv6 as never changing addresses allow for even easier long-term tracking of individual Internet usage. These concerns are addressed by its privacy extensions. While these extensions may be a good idea for devices used to consume the Internet⁷ I have disabled them on my dynamically addressed servers by setting net.ipv6.conf.all.use_tempaddr to zero.