• IPv6 with 6to4 setup on Debian / Ubuntu
  • Performing a 6to4 setup on a host behind a NAT gateway
  • MTU setting
• IPv6 with Xen routed setup
• NAT with a dynamic IPv6 prefix
  • Using the DHCPv6 client in a fail-over setup

IPv6 with 6to4 setup on Debian / Ubuntu

If you have a static IPv4 address, the easiest way to get IPv6 working is using the 6to4 protocol. 6to4 automatically assigns a /48 IPv6 subnet to each IP address. As the minimal recommended size for a IPv6 subnet is /64, you get nearly 2^16 subnets you can use behind one IPv4 address. This makes 6to4 an excellent choice, if you have a network behind a NAT gateway, with only one static IPv4 address.

You can generate a 6to4 configuration for Debian's or Ubuntu's /etc/network/interfaces using a nice and simple to use web-based tool.

Performing a 6to4 setup on a host behind a NAT gateway

However, if you cannot or do not want to do the IPv6 routing for your network on the NAT gateway with the global IPv4 address, the setup gets a little bit more complicated:

You have to forward all IPv6 traffic (that is protocol number 41) from your NAT gateway to the machine you are performing the 6to4 setup on. On Linux you can do this with iptables using the commands

(the second rule is only needed, if you are not using policy ACCEPT for the FORWARD chain). This will forward all 6to4 related traffic that hits ${EXTERNAL_IPV4_ADDRESS} to ${TARGET_HOST}.

MTU setting

With the default MTU setting of 1480 I experienced strange problems: Sometimes, connections got "stuck". By manually setting the MTU for the tun6to4 interface to 1280 these problems could be solved. I guess, that these problem might be related to packet fragmentation when encapsulating the IPv6 packet within an IPv4 packet.

See also: Path MTU Discovery issues

IPv6 with Xen routed setup

If you want to add IPv6 support to Xen DomUs in a routed network setup, you can either use 6to4 on each individual domU (as long as each has a unique, global IPv6 address), or you can create a routed setup for IPv6 in addition to the exiting IPv4 setup.

This How To expects that you already have IPv6 running for the Xen Dom0. You might want to refer to the section above, if you have not configured IPv6 for the Dom0 yet.

The core of this setup is the following script, which should be saved in /etc/xen/scripts/vif-route-ipv6 (do not forget to chmod a+x the file):

It refers to the config file /etc/xen/ipv6.cfg. This file might look like this:

As you can see, for each DomU, that shall be IPv6 enabled, a line with the DomU name in square brackets is written into the configuration file. The IPv6 address after the equals sign is the address that will be assigned to the virtual interface corresponding to the DomU in the Dom0.

This differs from the IPv4 routed setup, where you only specify the address of the DomU and a host route is created in order to connect the Dom0 with the DomU. For IPv6 we are using a different setup for three reasons:

1. Configuration gets easier: We do not have to create host routes, the routes will be automatically determined by the subnet prefix for the address. In the example

above, a route for target 2002:ffff:ffff:1::/64 using the correct vif-device will be created automatically. There is also no need to manually configure a host-route to the gateway within the domU: The gateway's address (for mydomu1 in the example it is 2002:ffff:ffff:1::1) is within the subnet of the DomU.

1. We can easily add extra IP addresses to the DomU: As the Dom0 routes the whole subnet to the DomU, we can just add any address (except the gateway address) within

the /64 subnet to the DomU, without having to change any configuration within the Dom0.

1. The IPv6 address space is vast: If we have a /48 subnet for the whole Xen host and we use a /64 subnet for each DomU, we can create up to nearly 2^16 DomUs on one Xen host. These are more DomUs than you will ever run on a single Xen host.

In order to make this setup work, we still have to ensure that the script /etc/xen/scripts/vif-routed-ipv6 is called on the startup of a DomU. The easiest way is to patch /etc/xen/scripts/vif-routed using the following patch:

Finally, the setup in the domU is pretty easy: You can just use a statically configured inet6 setup on eth0. Example:

NAT with a dynamic IPv6 prefix

Some Internet service providers only provide a dynamic prefix for IPv6 via DHCPv6 prefix delegation. This prefix changes from time to time (e.g. when the connection is interrupted and reestablished).

With such a setup, there are two challenges: First, one has to delegate the prefix to the various subnets / VLANs within one's network. Second, using addresses with a non permanent prefix causes extra challenges for example when defining firewall rules between the various VLANs.

For these reasons, I am going to describe a setup in which the LAN only uses addresses from the unique local address (ULA) space. When routing into the Internet, these addresses are replaced with addresses allocated using the dynamic prefix.

For this example, it is assumed that the ISP provides a sufficiently large prefix (typically a /56) via DHCPv6 prefix delegation and that the Internet router at the edge of the LAN is capable of further delegating (parts of) this prefix via DHCPv6 prefix delegation. In my case, I am using an AVM Fritz!Box 3370 connected to a VDSL2 line from Deutsche Telekom. Deutsche Telekom provides a dynamic /56 via prefix delegation and the Fritz!Box can be configured to serve prefix delegation requests from DHCPv6 clients.

A computer that is connected to the VLAN of the Internet router (Fritz!Box) and to all other VLANS acts as a firewall and router. On this computer, I run the DHCP client from the dhcpcd5 Ubuntu package. Please note that the version of this package included before Ubuntu 16.04 LTS is too old because it lacks critical features. Luckily, the package from Ubuntu 16.04 LTS can be installed on Ubuntu 14.04 LTS (and presumably newer versions of Ubuntu) without any problems.

I use the following configuration file (/etc/dhcpcd.conf):

Everything before the "allowinterfaces" line is the default configuration. I use the allowinterfaces option because the DHCPv6 client shall only run on the interface eth0 (the interface facing the Internet router in this example). All the other interfaces use a static configuration (remember that internally this computer is a router).

We are only interested in the delegated IPv6 prefix, so I disable everything else using the nooption lines and disable all hooks that would affect the computer's network configuration.

I request a /58 prefix (so Internet router gets a /56 from the ISP so it should easily be able to provide a /58) using the ia_pd line. I have to specify a network interface that uses the assigned prefix, otherwise dhcpcd will not work. However, I do not want to use this prefix on a network interface, but only want to use it in IPtables. Therefore I specify an interface name that does not exist (nosuch0). This causes the DHCP client to log a warning, but the prefix delegation will still work.

The ipv6only options disables DHCP for IPv4 (I use a static IP address for IPv4) and the nogateway and noipv6rs options ensure that the DHCP client will not add any routes.

The noauthrequired option ensures that the IPv6 prefix is updated when the Internet router gets a new prefix from the ISP. Obviously, actually configuring authentication would be preferrable, but in my case the Internet router does not seem to support this. If there only are trusted devices in the network connecting the computer running dhcpcd with the Internet router, disabling authentication should be safe.

Finally, the script specified in the script line is called whenever a DHCP lease is obtained, renewed or released. It allows us to use the assigned prefix (we will soon see how).

In /etc/network/interfaces I use the following configuration for eth0:

I disable the privacy extension because it does not make much sense for a router. I also disable DHCPv6 because Ubuntu uses ISC's DHCPv6 client (dhclient), which unfortunately cannot handle prefix delegations correctly. The dhcpcd5 DHCPv6 client on the other hand does not have to be triggered by the network scripts explicitly but will detect the new interface and start its work automatically.

The post-up script is needed because Linux does not accept router advertisements (RAs) by default when forwarding is enabled. The rational behind this is that a computer with forwarding enabled acts as a router and typically a router should not accept RAs from other routers. In our case however, we want to accept RAs from our upstream router and setting accept_ra to 2 will override the default behavior.

Finally, we need the script that is called when a dynamic prefix is assigned so that we can create the corresponding rules for ip6tables.

I use the following script (/etc/dhcpcd-pd-script):

In this script, you have to adjust your internally used prefix (when choosing a ULA prefix, you should use a random number from the range fc::/7 in order to avoid colissions when connecting different networks using addresses from the ULA space). Like in the other configuration files, you have to change the interface name from eth0 to whichever is the name of the interface that connects to the Internet router.

In order to work correctly when handling traffic that comes from the internal network and is directed at the internal network but using a destination address with the external prefix, the iptables rules use a mark. This will only work correctly if no other rules affecting the packet (in particular in the FORWARD chain) set the mark.

This script does the following: When called with the new_dhcp6_ia_pd1_prefix1 environment variable set, it uses this prefix to create iptables rules that replace the internal prefix with the dynamic external one when routing through the external interface.

These rules are created in separate chains (external_dnat and external_snat), so that we can easily replace the rules without affecting any other rules that might be present. Please note that these chains need to be called from the PREROUTING and POSTROUTING chains like this:

You might have noticed that there is no code that removes the rules when the prefix delegation expires. The rationale behind this is simple: Usually, we only expect a prefix to be replaced with a different prefix. The only case when we would expect no prefix at all is when our Internet connection is down. In this case, however, it does not matter if we still have a rule with the old prefix.

Using the DHCPv6 client in a fail-over setup

In my case, the actual setup is even a bit more complex: I do not want the internal router to be a single point of failure. For the DSL router on the edge of the network this is acceptable because there is no reasonable way to avoid this. A simple router box is also less likely to fail than a "real" computer and software updates requiring a reboot are less frequent, too.

I will not discuss here the details of the fail-over setup of the network interfaces. I use a HA solution involving OpenVSwitch. For the rest of this tutorial, it is assumed that fail-over is working for the network interfaces and that the network interface facing the Internet router (eth0) uses the same MAC address on all nodes of the HA cluster and is only active on a single node at once.

The remaining challenge is to ensure that the DHCPv6 client uses the same prefix when fail-over from one node to another one happens. If the prefix changed, existing connections would be interrupted.

DHCPv6 uses a DUID identifying the client when contacting the server. Typically, this ID is generated when the client runs for the first time and stored internally. This way, a client always has the same DUID when contacting a server. The DHCPv6 client from the dhcpcd5 package stores this DUID in /etc/dhcpcd.duid. We could copy this file to all nodes so that they will identify as the same DHCPv6 client, however this could be dangerous. If there happen to be other interfaces on which we want to use DHCPv6 and for one of these interfaces two nodes might be active at the same time, it could end up in the same addresses being assigned to two different clients. In addition to that, we would also have to keep the information about active leases in sync between nodes.

Luckily, there is a simpler approach to this issue: The DHCP client from dhcpcd5 has been specifically designed to work on computer where there is no permanent storage available (e.g. some embedded devices). On these devices, it generates a DUID based on the hardware address of the interface and it does not store lease information. This is exactly what we want. Typically, a DHCPv6 server will assign the same lease if the same client requests a new lease and its current lease has not expired yet (at least, this is what the DHCPv6 server in the Fritz!Box does). So if we fail-over from one node to another one, the delegated IPv6 prefix will be kept (the hardware address of the interfaces is the same as described earlier).

Unfortunately, there is no way to tell the DHCP client to operate with storing the DUID and lease information. It will simply try to store this information and fall-back to working without stored information if the write operation fails. We cannot use restrictive permissions on the relevant files because the DHCP clients runs with root privileges. However, we can set the immutable attribute on them, so that they cannot be changed any longer. We do this by running the following two commands:

Before doing this, ensure that etc/dhcpcd.duid is an existing empty file and that /var/lib/dhcpcd5 is an existing empty directory.

Now, the write operations will fail and the DHCP client will show the desired behavior.