Context
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:
-
Teredo: specified in RFC 4380, the protocol has been specifically designed to provide IPv6 access to end nodes from behind IPv4 NATed networks.
Simply put, the protocol integrates some smart mechanisms to detect the kind of NAT implemented by the network where the node is sitting (that step is called "Qualification procedure"). For that purpose it uses an external helper: a Teredo server. There are many Teredo servers deployed on the Internet that you can freely use. At the end of the qualification procedure, the node ends up with a single IPv6 address in the Teredo address space (2001::/32).
It is then able to communicate with native IPv6 peers and Teredo peers. When contacting a native IPv6 peer (or a 6to4 one), the node ends up sending IPv6 packets over UDP over IPv4 to a Teredo relay which then decapsulates the IPv6 packets and relays it on the IPv6 Internet. A reverse path is used for return traffic.
When used for carrying our IPsec-protected MIPv6 data traffic (TCP for instance), packets emitted and received by the node have the following format: IPv4 / UDP / IPv6 / ESP / IPv6 / TCP / Data
No matter what you might read about the protocol, it is an impressive piece of engineering. It is the proof to those who think the opposite that NAT is not a security mechanism.
In the context of the discussion, Teredo can be used to provide the Mobile Node access to its Home Agent when it is stuck in an IPv4-only network.
-
DS-MIPv6: Dual Stack MIPv6 is specified in RFC 5555. Instead of leaving NAT and IPv4 networks issues outside the scope of MIPv6 protocol, DS-MIPv6 defines extensions that can be implemented in MIPv6 entities (MN, HA and NEMO-enabled equivalents) to support MIPv6 operations from IPv4 networks.
Work on DS-MIPv6 was proposed more than 3 years ago by Vijay Devaparally, Ryuji Wakikawa and Carl Williams (see the slides presented at IETF 62 in March 2005). The issues associated with the reuse of existing tunneling mechanisms were among the arguments to work on a specific solution (see slide 3 in previous link).
Basically, DS-MIPv6 usually encapsulates IPv6 traffic over UDP over IPv4 but makes the IPv4 source address of the packet its CoA, which allows for the removal of a level of IPv6 encapsulation compared to the use of Teredo in MIPv6 context. Previous IPsec-protected MIPv6 data traffic is usually expected to take the following form when DS-MIPv6 is used: IPv4 / UDP / ESP / IPv6 / TCP / Data.
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:
- Cons of Teredo:
- Teredo qualification procedure creates an additional delay after the MIPv6 node has acquired an IPv4 address in a new foreign network (after a handover). The cost is basically the RTT between the Teredo server and the MN.
- For a use with MIPv6, official Teredo relays cannot (should not) be used because the MTU that must be configured for Teredo interfaces is 1280 bytes. If the Teredo relay enforces that value, the required tunneling with the HA will not work. For that reason, a relay allowing higher MTU (1400 for instance) must be deployed at the edge of the site were the Home Agents is hosted. This also has the direct performance advantage of having the traffic flowing directly from the MN to the site, without a possible bottleneck when using a public relay.
- MTU loss associated with Teredo is at least 28 bytes (IPv4 and UDP headers).
- Teredo adds an additional point of failure to the equation: the Teredo Server. In practice, this is usually not an issue but it's worth mentionning.
- Pros of Teredo:
- Teredo fully hides NAT and IPv4 existence (and issues) to MIPv6, IKE and IPsec. For that reason, no changes to those elements are required. IMHO, this is worth the MTU loss in most cases.
- A Teredo relay can easily be deployed at the edge of the network where the HA is hosted to make the path direct between the MMs and the HA.
- The link provided by Teredo is a tunnel link, which might creates issue for link detection functions.
- Teredo (when compared to DS-MIPv6) does not require the HA to be IPv4-enabled. Consider it.
- Teredo has implementation for all major platform: Windows (the protocol was developed by Microsoft), Linux and *BSD. Miredo, the implementation of Teredo protocol for Linux (and *BSD) works just great.
- Cons of DS-MIPv6
- DS-MIPv6 requires specific changes to MIPv6, IKE and possibly IPsec.
- DS-MIPv6 makes MIPv6 protocol aware of IPv4 and NAT.
- It requires the HA to support IPv4.
- Pros of DS-MIPv6:
- Lower MTU loss via removal of a level of encapsulation. In best cases, this
- Guaranteed best path between the MN and its HA. This requires the setup of a relay at the edge of the HA's network for Teredo to provide the same guarantee.
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.
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 START_MIREDO=true DAEMON_ARGS=""
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 ServerAddress 83.170.6.76 #teredo-debian.remlab.net 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:
#!/bin/sh
#
# 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 <arno@natisbad.org> to work with UMIP
# towards a specific relay allowing a higher MTU (1400).
IP=/sbin/ip
METRIC=1029
TABLE=teredo
PRIO=32765
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
up)
"$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"
;;
esac
"$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).
Changelog
- 2010/10/05: The tunnel support patch has been merged in umip.git tree.
- 2010/02/16: First version of this document.