How to use UMIP with tunnel interfaces (Miredo)

Back to index

Context   Miredo   Changelog


If you play the game and use MIPv6 on a daily basis, you will find after some time that the ability to keep a static vision of the network no matter where you are is just great. But you will also encounter some frustrations on foreign network that still only provide IPv4 access.

This document will teach you how to make MIPv6 working from IPv4 foreign networks using tunnel interfaces. From a theoretical standpoint, there are two main solutions available for that purpose:

Pros and Cons of Teredo and DS-MIPv6

Here is a list of pros and cons for both solutions in the context of a use with IPsec/IKE-protected MIPv6:

In the end, Teredo keeps thing separate: MIPv6 (and IPsec/IKE) do not get involved in IPv4 and NAT issues. Teredo handles those, with a MTU fee per packet, but it is worth it.

Context   Miredo   Changelog

Setting up miredo

Under Linux, miredo is the implementation of Teredo protocol. It supports both relay and client mode. Here, we cover the setup of client mode on a (Debian) MN.

UMIP and tunnel interfaces

Before spending some time on the configuration, let's take a few lines to describe how UMIP and miredo will work together. Usually, UMIP is the one handling address configuration by sending RS, parsing RA, constructing addresses, installing them and so on. With Miredo, this is obviously not possible, because the configuration of the Teredo interface (address and routes) is completely handled by Miredo.

For that reason, it is possible to notify UMIP (through the mip6d.conf file) that an interface it is dealing with is a tunnel interface that will be configured externally. For those interfaces, UMIP will not try to send RS, received RA, etc. and will directly use the information configured by the external mechanism. The aim was to be able to support Teredo, 6to4, and PPP interfaces.

There is a thing you should be aware of about the use of UMIP with miredo: because miredo does not really support movement detection (switching from a network to another) and rely on external IPv4 address configuration (usually done using DHCP), do not expect to get some smooth migrations when moving from an IPv4 network to another. From my experience, after some time, miredo notices the address change and performs a new qualification procedure which results in the configuration of a new IPv6 address on the teredo interface. At this point, UMIP detects the new address and performs its handover. Nonetheless, miredo is perfectly suitable when you find yourself in a common IPv4 network.

Miredo configuration

Let's now start setting things up. First install the daemon. By default, miredo is started at boot (via /etc/init.d/miredo) because START_MIREDO is set to true in /etc/default/miredo.

# apt-get install miredo
$ cat /etc/default/miredo

If you do not want miredo to be started by default during boot but want to start it by yourself when you need the service it provides, you can simply use update-rc.d for that purpose (something like "update-rc.d -f miredo remove" should do the job).

Let's now configure miredo by modifying /etc/miredo.conf file. Here is a sample one:

$ cat /etc/miredo.conf 
InterfaceName    teredo
RelayType        client
BindPort         3545

If you make the comparison with the default file provided by the package, you will notice that ServerAddress parameter is no more provided a FQDN but an IPv4 address. This is to avoid a chicken and egg issue when you use a static DNS configuration involving an IPv6 DNS server that will only be available after the binding with the HA has occured.

Because miredo can be used on various platform and users might have some specific needs configure routing, the daemon uses a simple script for configuring the routes: /etc/miredo/client-hook. Here is a modified version intended for use with UMIP. It especially sets a higher MTU:

# Miredo client hook script for Linux/iproute2
# Copyright 2007 Rémi Denis-Courmont.
# Distributed under the terms of the GNU General Public License version 2.
# Modified by Arnaud Ebalard <> to work with UMIP
# towards a specific relay allowing a higher MTU (1400).


test "$OLD_ADDRESS" && \
"$IP" -6 rule del from "$OLD_ADDRESS" prio "$PRIO" table "$TABLE" 2>/dev/null

"$IP" -6 route flush table "$TABLE" 2>/dev/null
"$IP" -6 route flush dev "$IFACE" 2>/dev/null
"$IP" -6 address flush dev "$IFACE" 2>/dev/null

"$IP" -6 link set dev "$IFACE" "$STATE"

case "$STATE" in
                "$IP" -6 route add default dev "$IFACE" metric "$METRIC"
                "$IP" -6 address add "${LLADDRESS}/64" dev "$IFACE"
                "$IP" -6 address add "${ADDRESS}/128" dev "$IFACE"
                "$IP" link set dev "$IFACE" up mtu "$MTU"

"$IP" -6 route flush cache 2>/dev/null

exit 0

UMIP configuration

Let's now focus on the UMIP configuration. On the MN or MR on which you intend to use miredo, in your /usr/local/etc/mip6d.conf file, you should find a definition for the teredo interface:

Interface "eth0" {
    MnIfPreference 1;
Interface "wlan0" {
    MnIfPreference 2;
Interface "teredo" {
    MnIfPreference 3;
    Tunnel enabled;

As you can see, the teredo interface is the least preferred one. It is also marked as an externally configured tunnel interface (using Tunnel parameter). The Tunnel parameter is used to warn UMIP that the interface is a tunnel interface which handles on its own the address configuration steps (i.e. it does not require UMIP to perform RS/RA and DAD). In IPv4 only networks, if miredo has succeeded in its qualification procedure and has acquired an address, it is used by UMIP as CoA. You can have a look at the mip6d.conf man page for the documentation of "tunnel" keyword for more on the topic.

After starting miredo, you can then start UMIP as usual (e.g. as explained in the Mobile IPv6 testbed howto).

FAQ   Changelog