|
 |
This document aims at helping the reader to build step-by-step a NEMO test network on Linux. We first introduce the basic concepts of IPv6, host and network mobility. We also briefly present NEPL (NEMO Platform for Linux). We then explain how to properly configure a simple test network, with a NEMO-enabled Home Agent and Mobile Router using NEPL.
|
In today's Internet, most communications between end-to-end nodes are using the IP protocol. This protocol assigns an unique address to all nodes connected to the Internet, and provides the mechanisms to transport data between two nodes.
IP version 4 (known as IPv4) is the current version of this protocol and was the first widely deployed IP protocol. It was standardized 25 years ago. It is now suffering from several design problems and will certainly restrain the creation of new usages of the Internet. The most debated problem with IPv4 is the lack of addresses, but it is not the only important one.
The need for addresses will increase in the near future. With the voice-over-IP becoming more and more popular, we can guess than billions of people will use an IP phone. Each vehicle will embed tens of IP sensors and some multimedia devices. Obviously, all of those equipments need an IP address. The lack of addresses that can be assigned with IPv4 was solved with the Network Address Translation (NAT) system. However, many peer-to-peer applications (such as video-conference or voice-over-IP softwares) suffer from this mechanism: with NAT, the real address of the host is not directly reachable from its correspondent. The communication cannot be directly established and sometimes need a third part.
We expect more and more equipments will be connected to the Internet, but the IPv4 protocol is not appropriate anymore to distribute and manage the IP addresses. The IPv4 scheme to allocate addresses is not based on any hierarchical scheme and the high fragmentation of address space will lead to an heavy load on backbone equipments (the routers). This is one of the most critical problems with the current IP protocol as it might cause the core routers of the Internet to stop working without prior notice.
Eventually, the IPv4 protocol has a monolithic design that makes it difficult to extend, and contains some mechanisms that prevent new protocols like mobile IP to work flawlessly.
As IPv4 cannot meet the demand anymore, the IPv6 protocol (RFC 2460) has been standardized in 1998. It can allocate much more addresses and allows to interconnect undecillions (10e36) of nodes at the same time. Nodes that connect to the Internet can automatically acquire an address thanks to the auto-configuration mechanism (RFC2462 "IPv6 Stateless Address Autoconfiguration"). IPv6 also simplifies the use of multicast, that allows many to many (including one to many) communications without wasting the bandwidth.
Besides those core features, IPv6 also allows the integration of new features such as improved security, quality of service where IPv4 only provides best effort, and mobility mechanisms with Mobile IPv6 and NEMO Basic Support.
The scalability offered by IPv6 will thus allow to interconnect any equipment and to design new services (such as connecting each car to the Internet) and new usages of the Internet (for instance use the vehicle connectivity for monitoring purposes) that we could not imagine with IPv4.
When a node using an Internet wireless access physically moves, it can be at some point of time out of the coverage area of its access network and needs to move to another one. In addition, because distinct operators may operate or the public target is different (pedestrians, cars etc.), usually no single access technology can cover one big area (such as a city). The node thus has to select the best access technology available.
When a node moves from one access network to another or switches between its access technologies, it acquires a new IPv6 address and is not reachable to its previous one anymore. It implies that all current communications (for example streaming video from the Internet) are stopped and later restarted by the user or the application.
The Mobile IPv6 protocol (RFC 3775) has been defined to address those issues and allow the node to be always reachable at the same IPv6 address whatever the access network it uses. It allows the host to move transparently for the applications and the users, without the need to reset all the current connections each time the host moves to another access network.
With Mobile IPv6, a host has two addresses while moving in the Internet topology: one permanent address that identifies the host, and the other representing the location in the Internet topology. The Mobile IPv6 protocol takes care of the binding between these two addresses (thanks to a Home Agent), and ensures that the host is always reachable at its permanent address even if it moves in the Internet topology.
On one side Mobile IPv6 manages mobility for only one host, on the other side NEMO Basic Support (RFC 3963) manages mobility for one whole network. Such a network can be for instance a PAN (Personal Area Network, a small network made of IPv6 sensors and PDAs), or an access network deployed in cars, buses or trains. Thanks to NEMO Basic Support, the only computer that needs to have mobility functionnalities when the whole network moves is the one that connects the network to the Internet (this computer is called a Mobile Router), whereas with the Mobile IPv6 approach each host in the network would have to handle mobility.
Running Mobile IPv6 on each node can be expensive, especially for little devices such as sensors. NEMO Basic Support only requires changes on the router, all others hosts in the moving network do not need any new feature. Thus all movement in the Internet topology will be handled by the router, transparently to the hosts.
With NEMO, we can imagine lots of senarii where mobility can play an important role. Using Network Mobility in a train would allow the customers to stay connected to the Internet without disruption during all their trip. Network Mobility in cars can allow to set up a PAN (Personal Area Network) made of tiny IPv6 sensors that can be queried from outside, and PDAs that can have permanent access to the Internet.
RFC3963 "Network Mobility (NEMO) Basic Support Protocol"
RFC3775 "Mobility Support in IPv6"
Real-life demonstrations using IPv6 and mobility support mechanisms
Kuntz, Romain and Lorchat, Jean and Ernst, Thierry (Keio University)
JSF, Tokyo, Japan, November 2005
A Live Light-Weight IPv6 Demonstration Platform for ITS Usages
Ernst, Thierry and Kuntz, Romain and Leiber, Francois (Keio University)
5th International Conference on ITS Telecommunications (ITST), Brest, France, 27-29 June 2005
IPv6 Network Mobility, Usage and Demonstration
Kuntz, Romain (Keio University)
JSF, Tokyo, Japan, November 2004
NEPL (NEMO Platform for Linux) is a freely available NEMO implementation for Linux on 2.6 kernel. The original NEPL release was based on MIPL2 (Mobile IPv6 for Linux) and has been developed and tested in cooperation between the Go-Core Project (Helsinki Univestity of Technology) and the Nautilus6 Project (WIDE). NEPL is now maintained on UMIP, which is an effort from the USAGI people to maintain MIPL2 to the current kernel releases.
NEPL currently supports Home Agent and Mobile Router, Implicit and Explicit registration modes and DHAAD. Extensions to NEPL, such as Multiple Care-of Addresses registration, are available in Section 6.
Interoperability tests with the SHISA implementation and an experimental CISCO image have been performed in January 2005 at the 6th TAHI interoperability event. We have successfully confirmed the interoperability for the following scenario:
NEMO Basic Support implementation interoperability tests
Kuntz, Romain (Keio University)
6th IPv6 TAHI Interoperability Test Event, Tokyo, Japan, February 2005
Performance Evaluation of NEMO Basic Support Implementations
Kuntz, Romain and Mitsuya, Koshiro and Wakikawa, Ryuji (Keio University)
WONEMO Workshop, Sendai, Japan, January 2006
NOTE: If you are interested in setting up a virtual platform, you may have a look at uml_clownix_net which provides the necessary tools and documentation to setup a topology modifiable virtual network with UMIP.
The UMIP test network is composed of:
MNN MNN Mobile Network Nodes (MNN)
| |
------------------------- Mobile Network (NEMO-Link) [2001:a:b:1::/64]
|::1
MR Mobile Router MR
|::1
------------------------- Home Link (HL) [2001:a:b:0::/64]
|::1000
HA Home Agent HA
|::1000
------------------------- Foreign Link 1 (FL1) [2001:a:c:1::/64]
|::1
R Router R
|::1
------------------------- Foreign Link 2 (FL2) [2001:a:d:1::/64]
The router R can be a Linux box with two network interfaces. You have to configure both interfaces of the router, enable the forwarding between the interfaces and install the routes to the networks. The following sample script should help you. Replace the interface's name according to your configuration:
#!/bin/sh # Router R - Startup script # Interface definition IF1=eth0 IF2=eth1 # Do not accept Router Advertisements, and enable forwarding echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra echo 1 > /proc/sys/net/ipv6/conf/all/forwarding # Configure the interfaces ifconfig $IF1 up ifconfig $IF1 inet6 add 2001:a:c:1::1/64 ifconfig $IF2 up ifconfig $IF2 inet6 add 2001:a:d:1::1/64 # Add a route via the Home Agent to the Home Link and the MNPs route add -A inet6 2001:a:b:0::/60 gw 2001:a:c:1::1000 $IF1 # EOF
The Router R must advertise Router Advertisements on both FL1 and FL2. You can use the radvd software configured as followed:
# Router R - /etc/radvd.conf
# Replace eth0 with the interface connected to FL1
interface eth0
{
AdvSendAdvert on;
MaxRtrAdvInterval 4;
MinRtrAdvInterval 3;
AdvIntervalOpt on;
prefix 2001:a:c:1::1/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
};
};
# Replace eth1 with the interface connected to FL2
interface eth1
{
AdvSendAdvert on;
MaxRtrAdvInterval 4;
MinRtrAdvInterval 3;
AdvIntervalOpt on;
prefix 2001:a:d:1::1/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
};
};
# EOF
You can tune the advertisement interval with the MinRtrAdvInterval and MaxRtrAdvInterval options. Check the radvd.conf manpage for more information. You can then execute rtadv specifying the location of your configuration file:
radvd -C /etc/radvd.conf
You need to recompile a kernel from scratch for your system, here is the procedure for a 2.6.29 kernel. First, Download the kernel sources. Note that your don't need to patch the kernel anymore (support for IPv6 mobility has been integrated since version 2.6.26).
# cd /usr/src/ # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.5.tar.gz
Local copies of these softwares are also available here. Uncompress the kernel sources:
# tar zxf linux-2.6.29.5.tar.gz
For conveniency, we create a symbolic link to the kernel sources:
# ln -s /usr/src/linux-2.6.29.5/include /usr/src/linux
You then need to edit the kernel configuration file to turn on the mobility options:
# cd linux-2.6.29.5/ # make menuconfig
Adjust the kernel options according to your hardware configuration. If you are not familiar with kernel compilation, take a look at this Kernel Rebuild Guide. To enable the mobility features, you also need to turn on the following options in the kernel (for both Home Agent and Mobile Router):
Code maturity level options
--> Prompt for development and/or incomplete code/drivers [CONFIG_EXPERIMENTAL]
General setup
--> System V IPC [CONFIG_SYSVIPC]
Networking
--> Networking support [CONFIG_NET]
--> Networking options
--> Transformation user configuration interface [CONFIG_XFRM_USER]
--> Transformation sub policy support [CONFIG_XFRM_SUB_POLICY]
--> Transformation migrate database [CONFIG_XFRM_MIGRATE]
--> PF_KEY sockets [CONFIG_NET_KEY]
--> PF_KEY MIGRATE [CONFIG_NET_KEY_MIGRATE]
--> TCP/IP networking [CONFIG_INET]
--> The IPv6 protocol [CONFIG_IPV6]
--> IPv6: AH transformation [CONFIG_INET6_AH]
--> IPv6: ESP transformation [CONFIG_INET6_ESP]
--> IPv6: IPComp transformation [CONFIG_INET6_IPCOMP]
--> IPv6: Mobility [CONFIG_IPV6_MIP6]
--> IPv6: IPsec transport mode [CONFIG_INET6_XFRM_MODE_TRANSPORT]
--> IPv6: IPsec tunnel mode [CONFIG_INET6_XFRM_MODE_TUNNEL]
--> IPv6: MIPv6 route optimization mode [CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION]
--> IPv6: IPv6-in-IPv6 tunnel [CONFIG_IPV6_TUNNEL]
--> IPv6: Multiple Routing Tables [CONFIG_IPV6_MULTIPLE_TABLES]
--> IPv6: source address based routing [CONFIG_IPV6_SUBTREES]
File systems
--> Pseudo filesystems
--> /proc file system support [CONFIG_PROC_FS]
If you want to use Multiple Care-of Addresses (MCoA) registration on the Mobile Router, please refer to section 6.b in order to activate some more needed options.
You can now proceed to the kernel compilation:
# make # make install # make modules_install
Verify your bootloader (LILO or GRUB)'s configuration and reboot on your new kernel.
NEPL is an extension to UMIP provided as a patch. UMIP is an effort from the USAGI people to maintain MIPL2 to the current kernel releases. By applying the NEPL patch on UMIP, you will get the NEMO Basic Support extension.
You need to get the original UMIP sources and to patch them with the NEPL patch. First, You may need additional packages to be able to compile UMIP. Be sure to have the following packages: autoconf, automake, bison, flex, libssl-dev, indent on your system. On a Debian operating system, you can install them with:
# apt-get install autoconf automake bison flex libssl-dev indent
Then, download the UMIP userland and the NEPL patch for UMIP:
# cd /usr/src/ # wget ftp://ftp.linux-ipv6.org/pub/usagi/patch/mipv6/umip-0.4/daemon/tarball/mipv6-daemon-umip-0.4.tar.gz # wget http://www.nautilus6.org/doc/nepl-howto/umip-nepl/mipv6-daemon-umip-0.4-nepl-20090624.patch # tar zxf mipv6-daemon-umip-0.4.tar.gz
Apply the NEPL patch for UMIP to add the NEMO Basic Support extension:
# cd /usr/src/ # mv mipv6-daemon-umip-0.4-nepl-20090624.patch mipv6-daemon-umip-0.4/ # cd mipv6-daemon-umip-0.4/ # patch -p1 < mipv6-daemon-umip-0.4-nepl-20090624.patch
Compile UMIP:
# autoreconf -i # CPPFLAGS='-isystem /usr/src/linux/include/' ./configure --enable-vt # make # make install
The --enable-vt option will enable the virtual terminal, which can be useful to retrieve the binding cache or binding update list information on the Home Agent or the Mobile Router. See section 5 for more information.
The Home Agent configuration file will be stored in /etc/mip6d.conf. Here is a sample file for our test network. Read carefully the mip6d.conf manpage to have more information on each keyword.
# This is an example of mip6d NEMO enabled Home Agent configuration file NodeConfig HA; # Set DebugLevel to 0 if you do not want debug messages DebugLevel 10; # Replace eth1 with the interface connected to the HOME LINK Interface "eth1"; HaAcceptMobRtr enabled; # MNP configuration HaServedPrefix 2001:a:b:0::/64; BindingAclPolicy 2001:a:b:0::1 (2001:a:b:1::/64) allow; DefaultBindingAclPolicy deny; # IPsec configuration - NO IPSEC AT THE MOMENT UseMnHaIPsec disabled; KeyMngMobCapability disabled; # EOF
The Home Agent also needs to advertise Router Advertisements on the Home Link, with some specific options to Mobile IPv6 and NEMO. You can use the radvd software for this purpose. On a Debian system, you can install it with:
# apt-get install radvd
Be careful, only version 0.9 and later supports the NEMO Basic support options. Check your version before using it. Configure the daemon as followed, in the /etc/radvd.conf file:
# Home Agent HA - radvd.conf
# Replace eth1 with the interface connected to the Home Link
interface eth1
{
AdvSendAdvert on;
MaxRtrAdvInterval 3;
MinRtrAdvInterval 1;
AdvIntervalOpt on;
AdvHomeAgentFlag on;
AdvHomeAgentInfo on;
HomeAgentLifetime 1800;
HomeAgentPreference 10;
AdvMobRtrSupportFlag on;
prefix 2001:a:b:0::1000/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
};
};
# EOF
NOTE: even though you do not plan to use the Home Link (e.g. in a Virtual Home Link configuration), you still have to advertise RA with the home link prefix: mip6d needs it to configure its Home Agent list. In that case you can use dummy interfaces to advertise the home link RA. See the FAQ entry for more information on how to configure a virtual Home Link.
You can now use a startup script to properly configure the Home Agent after boot and execute the NEMO and RADVD daemons. Here is a sample script for our test network. Replace the interface's name and the MR's Link Local address according to your configuration:
#!/bin/bash # Home Agent HA - Startup script # Interface definition IF1=eth0 IF2=eth1 # Put here your MR's Link Local address on the egress interface MRLLADDR=fe80::200:24ff:fecc:6868 # Put here the path to your radvd binary RADVD=/usr/local/sbin/radvd # Put here the path to your mip6d binary NEMOD=/usr/local/sbin/mip6d # Deny RA and setup forwarding echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra echo 1 > /proc/sys/net/ipv6/conf/all/forwarding # Enable Proxy NDP (to support returning home) echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp # Configure the interface connected to the Home Link ifconfig $IF2 up ifconfig $IF2 inet6 add 2001:a:b:0::1000/64 # Configure the interface connected to FL1 ifconfig $IF1 up ifconfig $IF1 inet6 add 2001:a:c:1::1000/64 # Route configuration # In order to route the packets to the Mobile Router when it is in the # Home Link. route -A inet6 add 2001:a:b:1::/64 gw $MRLLADDR $IF2 # Route the packets to the Foreign Link 2 via the Router R route -A inet6 add 2001:a:d:1::/64 gw 2001:a:c:1::1 $IF1 # Execute the router advertisement daemon $RADVD -C /etc/radvd.conf # Execute the NEMO daemon $NEMOD -c /etc/mip6d.conf # EOF
Once the script is executed, the Home Agent should be operational and ready to register your Mobile Router.
The Mobile Router configuration file will be stored in /etc/mip6d.conf. Here is a sample file for our test network. Read carefully the mip6d.conf manpage to have more information on each keyword.
# This is an example of mip6d NEMO enabled Mobile Router configuration file
NodeConfig MN;
DebugLevel 10;
DoRouteOptimizationCN disabled;
DoRouteOptimizationMN disabled;
UseCnBuAck disabled;
# We use Explicit Mode
MobRtrUseExplicitMode enabled;
# Enable Optimistic Handovers
OptimisticHandoff enabled;
# The Binding Lifetime, for example 60 seconds
MnMaxHaBindingLife 60;
# Replace eth0 with your egress interface
# (the one connected to the Home Link or Foreign Link)
Interface "eth0" {
MnIfPreference 1;
}
# Replace eth0 with your egress interface
MnHomeLink "eth0" {
IsMobRtr enabled;
HomeAgentAddress 2001:a:b:0::1000;
HomeAddress 2001:a:b:0::1/64 (2001:a:b:1::/64);
}
# IPsec configuration - NO IPSEC AT THE MOMENT
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;
# EOF
The Mobile Router also needs to advertise Router Advertisements on its NEMO-Link, inside the Mobile Network. You can use the radvd software for this purpose. Configure the daemon as followed, in the /etc/radvd.conf file:
# Mobile Router MR - radvd.conf
# Replace eth1 with the interface connected to the NEMO-Link.
interface eth1
{
AdvSendAdvert on;
MaxRtrAdvInterval 3;
MinRtrAdvInterval 1;
AdvIntervalOpt on;
prefix 2001:a:b:1::1/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
AdvPreferredLifetime 60;
AdvValidLifetime 120;
};
};
# EOF
You can now use a startup script to properly configure the Mobile Router after boot and execute the NEMO and RADVD daemons. Here is a sample script for our test network. Replace the interface's name according to your configuration:
#!/bin/bash # Mobile Router MR - Startup script # Interface definition IF1=eth0 IF2=eth1 # Put here the path to your radvd binary RADVD=/usr/local/sbin/radvd # Put here the path to your mip6d binary NEMOD=/usr/local/sbin/mip6d # Deny RA and setup forwarding echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra echo 1 > /proc/sys/net/ipv6/conf/all/forwarding # IF1 is the egress interface. Do not configure any address on it. ifconfig $IF1 up # IF2 is the ingress interface, connected to the NEMO-Link ifconfig $IF2 up ifconfig $IF2 inet6 add 2001:a:b:1::1/64 # Execute the router advertisement daemon $RADVD -C /etc/radvd.conf # Execute the NEMO daemon $NEMOD -c /etc/mip6d.conf # EOF
Once the script is executed, the Mobile Router should be operational and ready to register to the Home Agent when moving in foreign networks.
You can specify a preference for each egress interface you would like to use on your Mobile Router, in the mip6d.conf file of the MR. Let's imagine that eth0 is a ethernet egress interface, and you would also like to use eth2, a wireless interface, as another egress interface when you disconnect eth0 from its link. You will then configure your MR as followed:
# This is an example of mip6d NEMO enabled Mobile Router configuration file
[...]
Interface "eth0" {
# The lower the preference is, the prefered is the interface.
MnIfPreference 1;
}
Interface "eth2" {
MnIfPreference 2;
}
[...]
# EOF
In the present case, eth0 will be used when available to send and receive traffic to and from the Mobile Network. If eth0 is disconnected from its link, eth2 will be used instead for the communications.
Don't forget to also update your startup script to use the eth2 interface:
#!/bin/bash # Mobile Router MR - Startup script # Interface definition IF1=eth0 IF2=eth1 IF3=eth2 [...] # IF1 is the egress interface. Do not configure any address on it. ifconfig $IF1 up # IF2 is the ingress interface, connected to the NEMO-Link ifconfig $IF2 up ifconfig $IF2 inet6 add 2001:a:b:1::1/64 # IF3 is the second egress interface ifconfig $IF3 up [...] # EOF
NOTE1: in order to get good performances in vertical handovers between your egress interfaces, be sure that the access routers on your foreign links send frequently Router Advertisements or always reply to Router Solicitations.
NOTE2: if you wish to use a cellular interface (GPRS, UMTS, etc.) as one of your network interface, please check the FAQ section.
An excellent HowTo to configure IPsec with dynamic keying on UMIP (using racoon2) is available here. This document has been contributed by Sebastien DECUGIS.
Once your Home Agent is operational, you can boot the Mobile Router. Once the NEMO dameon is running, be sure that the Mobile Router and the MNNs inside the Mobile Network are reachable (using ping6 for example) when the MR is in the Home Link. If they are not reachable, you certainly have a configuration problem.
If all your test network is setup and all nodes are reachable from each network, then you can try to move your Mobile Network from the Home Link to Foreign Link 1, by connecting the Mobile Router's egress interface to FL1. The MR will then register to the Home Agent, and each node (MR and MNNs) will still be reacheable at the same address as if they were in the Home Link.
You can check that the registration to the Home Agent was successful by checking the Binding Update List on the Mobile Router and the Binding Cache on the Home Agent. You can check them through the Virtual Terminal. For example, you can execute on the MR:
# telnet localhost 7777
mip6d> verbose yes
yes
mip6d> bul
== BUL_ENTRY ==
Home address 2001:a:b:0:0:0:0:1
Care-of address 2001:a:c:1:208:dff:feed:beef
CN address 2001:a:b:0:0:0:0:1000
lifetime = 8, delay = 7000
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK
ack ready
dev eth0 last_coa 2001:660:4701:f03f:230:5ff:fe1a:7ffb
lifetime 4 / 8 seq 51006 resend 0 delay 7(after 3s) expires 4
mps 2332741 / 2332798
We can see that the CoA 2001:a:c:1:208:dff:feed:beef wich is bound to the HoA 2001:a:b:0:0:0:0:1 is registered to the CN (here, the Home Agent) whose address is 2001:a:b:0:0:0:0:1000.
On the Home Agent, you can get similar information with the bc command of the Virtual Terminal, which displays all the Binding Cache Entries:
mip6d> verbose yes
yes
mip6d> bc
hoa 2001:a:b:0:0:0:0:1 nonce 0 status registered
coa 2001:a:c:1:208:dff:feed:beef nonce 0 flags AH--
local 2001:a:b:0:0:0:0:1000 tunnel ip6tnl1 link eth1
lifetime 1 / 8 seq 51018 unreach 0 mpa 2023 / 2167 retry 0
You can now move your Mobile Network from the Home Link to FL1 and FL2, transparently for all the MNNs in your Mobile Network.
Multiple Care-of Addresses Registration (MCoA) allows a Mobile Node (Mobile Host or Mobile Router) to register simulteanously multiple Care-of Addresses to its Home Agent. Main benefits, amongst others, are policy routing and fault tolerance for the Mobile Router.
The current implementation is based on draft-ietf-monami6-multiplecoa-01.txt. It is shipped as a patch for the UMIP userland that must be applied AFTER the NEPL patch from section 4.b. It runs on a 2.6.29.5 kernel patched with the UMIP kernel patch, and is based on the NEPL for UMIP code.
Note that MCoA allows to use multiple interfaces at the same time, whereas the interface preference mechanism explained in section 4.e1 only allows to use multiple interfaces sequentially.
MCoA for UMIP is still under development and thus contains some bugs and limitations. Please read carefully the README.MCOA which will appear once the MCoA patch have been applied. The most important limitations are:
Besides this, there are still some bugs, so any bug report is welcome!
First, download and activate the UMIP kernel options for the 2.6.29.5 kernel as explained in section 4.b. You also need to activate at least the following options:
Networking
--> Networking options
--> Network packet filtering framework (Netfilter) [CONFIG_NETFILTER]
--> Core Netfilter Configuration
--> Netfilter Xtables support (required for ip_tables)a [CONFIG_NETFILTER_XTABLES]
--> "MARK" target support [CONFIG_NETFILTER_XT_TARGET_MARK]
--> "mark" match support [CONFIG_NETFILTER_XT_MATCH_MARK]
--> IPv6: Netfilter Configuration (EXPERIMENTAL)
--> IP6 tables support (required for filtering) [CONFIG_IP6_NF_IPTABLES]
--> Packet mangling [CONFIG_IP6_NF_MANGLE]
In order to fix a problem with the BU that could be sent through a disconnected interface, you need to patch the kernel with this patch (more explanation on the problem here).
Compile and reboot on your new kernel, as explained in section 4.b.
You may need additional packages to be able to compile UMIP. Be sure to have the following packages: autoconf, automake1.8, bison, flex, libssl-dev, indent. On a Debian operating system, you can install them with:
# apt-get install autoconf automake1.8 bison flex libssl-dev indent
Download all the necessary softwares and patch: the UMIP userland, the NEPL patch for UMIP, the MCoA patch for UMIP, and an extra patch to solve an issue regarding the interface chosen to send the BU.
# cd /usr/src/ # wget ftp://ftp.linux-ipv6.org/pub/usagi/patch/mipv6/umip-0.4/daemon/tarball/mipv6-daemon-umip-0.4.tar.gz # wget http://www.nautilus6.org/doc/nepl-howto/umip-nepl/mipv6-daemon-umip-0.4-nepl-20090624.patch # wget http://www.nautilus6.org/doc/nepl-howto/umip-nepl/mipv6-daemon-umip-0.4-nepl-mcoa-20090624.patch # wget http://www.nautilus6.org/doc/nepl-howto/extra/mcoa_bu_mip6d.diff # tar zxf mipv6-daemon-umip-0.4.tar.gz
First, apply the NEPL patch for UMIP (to add the NEMO Basic Support extension) and then the MCoA patch:
# cd /usr/src/ # mv mipv6-daemon-umip-0.4-nepl-20090624.patch mipv6-daemon-umip-0.4/ # mv mipv6-daemon-umip-0.4-nepl-mcoa-20090624.patch mipv6-daemon-umip-0.4/ # mv mcoa_bu_mip6d.diff mipv6-daemon-umip-0.4/ # cd mipv6-daemon-umip-0.4/ # patch -p1 < mipv6-daemon-umip-0.4-nepl-20090624.patch # patch -p1 < mipv6-daemon-umip-0.4-nepl-mcoa-20090624.patch # patch -p0 < mcoa_bu_mip6d.diff
Compile UMIP:
# autoreconf -i # CPPFLAGS='-isystem /usr/src/linux/include/' ./configure --enable-vt # make # make install
The --enable-vt option will enable the virtual terminal, which can be useful to retrieve the binding cache or binding update list information on the Home Agent or the Mobile Router.
The Home Agent configuration file supports new items to enable MCoA registrations. Please also refer to the mip6d.conf manpage for more information.
# Add support for MCoA
# enabled: will accept MCoA registration from MN
# disabled: will not accept MCoA registration from MN
# Default: disabled
HaAcceptMCoAReg {enabled|disabled};
# Each entry for MN/MR can be configured to accept MCoA or not
# Default: NoMCoAReg
BindingAclPolicy HoA (MNP1, MNP2) {MCoAReg|NoMCoAReg} allow;
You should also set UseMnHaIPsec to disabled;
As an example, the mip6d.conf for the Home Agent available in section 4.d would become:
# This is an example of mip6d NEMO and MCoA enabled Home Agent configuration file NodeConfig HA; DebugLevel 10; Interface "eth1"; HaAcceptMobRtr enabled; HaAcceptMCoAReg enabled; # Disable MPS/MPA SendMobPfxAdvs enabled; SendUnsolMobPfxAdvs enabled; # MNP configuration HaServedPrefix 2001:a:b:0::/64; BindingAclPolicy 2001:a:b:0::1 (2001:a:b:1::/64) MCoAReg allow; DefaultBindingAclPolicy deny; # IPsec configuration - NO IPSEC AT THE MOMENT UseMnHaIPsec disabled; KeyMngMobCapability disabled; # EOF
The radvd.conf and the startup script remains the same as in section 4.d.
The Mobile Router configuration file supports new items to enable MCoA registrations. Please also refer to the mip6d.conf manpage for more information.
# Put an "Interface" item for each interface you wish to tuse
# for MCoA registration
Interface "eth0" {
# BID for this interface
# BID MUST be choosed between 1 and 251, and MUST be UNIQUE
Bid 100;
# Binding priority (the higher the better)
# When MCoA is used, this is the priority of the binding
# and MnIfPreference is ignored.
# If no external policies are used, the higher is preferred.
BidPriority 10;
# Setting the Reliable flag to false allows to use the BU as
# a heartbeat. Check the manpage for more details.
Reliable {true|false};
}
MnHomeLink "eth0" {
[...]
# Add support for MCoA
# enabled: will try to register Multiple CoA to the HA
# disabled: will only register one interface
# Default: disabled
RegMultipleCoA {enabled|disabled};
# Interfaces to use for MCoA Registration
IfMultipleCoA "eth0", "eth1";
}
You should also set DoRouteOptimizationCN, DoRouteOptimizationMN and UseMnHaIPsec to disabled;. MnMaxHaBindingLife should also be set to a small value (thus the HA can quickly delete useless bindings if needed). Using Optimistic Handovers may also give you better results in case the Mobile router redirects flows from one tunnel to another. If one MR-HA path is not very reliable, you can also set the Reliable option to false; in the corresponding Interface entry. Please check the manpage for more information about that.
Supposing that you wish to use both eth0 and eth2 as egress interfaces, and to register two care-of addresses to your Home Agent, the mip6d.conf for the Mobile Router available in section 4.e would become:
# This is an example of mip6d NEMO and MCoA enabled Mobile Router configuration file
NodeConfig MN;
DebugLevel 10;
DoRouteOptimizationCN disabled;
DoRouteOptimizationMN disabled;
SendMobPfxSols enabled;
UseCnBuAck disabled;
# We use Explicit Mode
MobRtrUseExplicitMode enabled;
OptimisticHandoff enabled;
# The Binding Lifetime, for example 20 seconds
MnMaxHaBindingLife 20;
Interface "eth0" {
Bid 200;
BidPriority 10;
Reliable true;
}
Interface "eth2" {
Bid 100;
BidPriority 20;
Reliable true;
}
# Replace eth0 with your egress interface
MnHomeLink "eth0" {
IsMobRtr enabled;
HomeAgentAddress 2001:a:b:0::1000;
HomeAddress 2001:a:b:0::1/64 (2001:a:b:1::/64);
RegMultipleCoA enabled;
IfMultipleCoA "eth0", "eth2";
}
# IPsec configuration - NO IPSEC AT THE MOMENT
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;
# EOF
Don't forget to also update your startup script to use the eth2 interface:
#!/bin/bash # Mobile Router MR - Startup script # Interface definition IF1=eth0 IF2=eth1 IF3=eth2 [...] # IF3 is the second egress interface ifconfig $IF3 up [...] # EOF
NOTE: if you wish to use a cellular interface (GPRs, UMTS, etc.) as one of your network interface, please check the following howto that will explain you how to setup an IPv6 connectivity over it using OpenVPN: Setup OpenVPN with an UMTS interface on Debian GNU/Linux to get IPv6 connectivity.
Once your MN has registered multiple Care-of Addresses to your Home Agent, it can use its multiple MN-HA tunnels for policy routing. The policy routing part is managed with the ip6tables tool. Be sure to install this tool (included in the iptables tool suite) on both your HA and MN. If it is not available as package for your Linux distribution, you can get it on the netfilter.org webpage.
You will use the BID that you assigned to each interface to mark the packets. Packets marked with BID X will be routed through the interface whose BID is X. If this interface is not available (because it is down), then the packet will be routed through the most prefered interface (the one with the highest BidPriority).
NOTE: At the moment, ONLY PACKETS FORWARDED BY THE MR (ie packets sent by MNN via the MR) can benefit from the policy routing. Packets generated by the MR itself will not be routed according to your rules. We are currently working to improve the current situation to also allow the MR to benefit from the policy routing.
Use the ip6tables tool and the MARK target to mark your packets with the BID. Ip6tables rules must be done in the PREROUTING chain, in the mangle table.
For example, on the MR, to mark as 100 all icmpv6 packets whose destination is 2001:a:d:1::1, you can do:
ip6tables -A PREROUTING -t mangle
-p icmpv6 --destination 2001:a:d:1::1
-j MARK --set-mark 100
Those packets will be sent through the interface whose BID is 100. You will also need to create the "symetric" rule on the Home Agent:
ip6tables -A PREROUTING -t mangle
-p icmpv6 --source 2001:a:d:1::1
-j MARK --set-mark 100
As you see, one current limitation is that each rules created on the MR must be also created on the Home Agent. We plan to support in the future some policy exchange mechanism between the MR and the HA in order to configure automatically the HA.
Read carefully the ip6tables manpage. You will be able to create rules based on many parameters, and thus create a very subtle policy routing on your MR.
Some enhancements for NEPL are available on http://software.nautilus6.org/NEPL. This includes Mobile Network Prefix Delegation to delegate automatically the Mobile Network Prefixes to your Mobile Router, and some interfaces preference mechanism.
Please note that those features were implemented on a quite old version of NEPL. It is now considered as obsolete, and you should prefer the latest version of NEPL (NEPL for UMIP) available in section 4.b. Note that at the moment there is no plan to port those features to the latest version of NEPL.
For any questions or bug report regarding those features, please send a mail on our support mailing list. As those features are not supported by the MIPL2 developers, please do not complain on the MIPL2 mailing list.
The Mobile Network Prefix Delegation mechanism, as defined in draft-ietf-nemo-prefix-delegation-00, extends NEMO Basic Support for a Mobile Router to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically.
NOTE1: with this prefix delegation mechanism, it is not possible for the Mobile Router to boot on Home Link, as the Prefix is delegated only when a Binding Update is sent. Such a mechanism is thus designed for Mobile Router that are never at home.
NOTE2: this work is based on a different version of NEPL, which is older than the NEPL version used previously in this document. Prefix Delegation is currently based on NEPL-SE-1.0 which works on a 2.6.11 kernel.
You first need to compile a 2.6.11 kernel with the mobility features enabled. Download the kernel sources and the Mobile IPv6 kernel patch for this kernel:
# cd /usr/src/ # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.gz # wget http://www.nautilus6.org/doc/nepl-howto/patch/mipv6-2.0-rc3-linux-2.6.11.patch.gz
Uncompress all downloaded files:
# tar zxf linux-2.6.11.tar.gz # gunzip mipv6-2.0-rc3-linux-2.6.11.patch.gz
Patch the kernel sources with the Mobile IPv6 patch:
# mv mipv6-2.0-rc3-linux-2.6.11.patch linux-2.6.11/ # cd linux-2.6.11/ # patch -p1 < mipv6-2.0-rc3-linux-2.6.11.patch
Now edit the kernel configuration file, compile the kernel and boot on it as explained in section 4.b.
Mobile Network Prefix Delegation can be added to NEPL thanks to this package. Download it, and apply it against NEPL-SE-1.0:
# cd /usr/src # wget http://software.nautilus6.org/packages/NEPL/NEPL-SE-PrefixDelegation-20051202.tar.bz2 # wget http://software.nautilus6.org/packages/NEPL/NEPL-SE-1.0.tar.bz2 # tar jxf NEPL-SE-1.0.tar.bz2 # tar jxf NEPL-SE-PrefixDelegation-20051202.tar.bz2 # mv NEPL-SE-PrefixDelegation-20051202/patch-NEPL-SE-1.1-ifpref-pdel.patch NEPL-SE-1.0/ # cd NEPL-SE-1.0/ # patch -p1 < patch-NEPL-SE-1.1-ifpref-pdel.patch
Then compile NEPL as explained in section 4.c. NOTE: the patch in this package also includes some basic interface preference mechanism described in section 7.b
This work is experimental. We invite the reader to check the README.txt file included in the package. It provides useful instructions and information about what is supported and what is not.
For our test network, we would like that the Mobile Router obtains automatically a prefix from its Home Agent, and advertise it in its Mobile Network. First, the Home Agent has to specify in its nemod.conf file which prefixes can be delegated to the Mobile Router. We configure the Home Agent to delegate a Persistent Prefix to our Mobile Router:
# This is an example of nemod NEMO enabled Home Agent configuration file
[...]
# Enable Prefix Delegation
UsePrefixDel enabled;
# Do NOT use the 'BindingAclPolicy' option but use instead the 'PrefixDel' option
#BindingAclPolicy 2001:a:b:0::1 (2001:a:b:1::/64) allow;
PrefixDel 2001:a:b:0::1 {
2001:a:b:1::/64 Persistent Global;
}
[...]
# EOF
We now configure the Mobile Router to ask for one prefix that could be advertised in its Mobile Network:
# This is an example of nemod NEMO enabled Mobile Router configuration file
[...]
# Enable Prefix Delegation
UsePrefixDel enabled;
MnHomeLink "eth0" {
IsMobRtr enabled;
HomeAgentAddress 2001:a:b:0::1000;
# Do NOT specify the MNP with the 'HomeAddress' option
# HomeAddress 2001:a:b:0::1/64 (2001:a:b:1::/64);
HomeAddress 2001:a:b:0::1/64;
# Specify which ingress interface should be configured to advertise a prefix
PrefixDel "eth1" Persistent 64 Global;
}
[...]
# EOF
With this configuration, the Mobile Router will ask the Home Agent to delegate it a /64 persistent prefix, that will be assigned to the eth1 interface. The eth1 interface will automatically configure an MNP::100/64 address (in our example, 2001:a:b:1::100/64). Of course, several prefixes can be asked and assigned to different ingress interfaces. Read the documentation to check how to configure the Home Agent and the Mobile Router in that case.
Once the Mobile Router got its MNP and configured its ingress interface, it needs to advertise the MNP in the Mobile Network with Router Advertisments. To automatically advertise the prefixes related to the new addresses configured on an interface, you can use the modified RTADV daemon for the Quagga Routing Software: Dynamic prefix advertisement for Quagga/rtadv. This is a patch that applies to Quagga 0.99.2. The following instructions explain how to patch and compile Quagga on your Mobile Router:
# cd /usr/src # wget http://www.quagga.net/download/quagga-0.99.2.tar.gz # wget http://software.nautilus6.org/packages/quagga/quagga-0.99.2-netlink-rtadv.tar.bz2 # tar zxf quagga-0.99.2.tar.gz # tar jxf quagga-0.99.2-netlink-rtadv.tar.bz2 # cp quagga-0.99.2-netlink-rtadv/quagga-0.99.2-rtadv-netlink.patch quagga-0.99.2/ # cd quagga-0.99.2/ # patch -p1 < quagga-0.99.2-rtadv-netlink.patch # autoreconf -i # ./configure --enable-rtadv --enable-netlink-rtadv \ --disable-ripd --disable-ripngd --disable-ospfd \ --disable-ospf6d --disable-bgpd # make # make install
You now have to configure Quagga, via telnet or a configuration file. This patch adds one new Interface Command to enable the new Dynamic Prefix Advertisement feature:
"ipv6 nd netlink"
Enable netlink support for dynamic prefix advertisement
"no ipv6 nd netlink"
Disable netlink support for dynamic prefix advertisement,
This is the default
Other usual commands are available on Quagga's documentation webpage. A sample configuration file for our test network will look like the following:
! # This is an example of /etc/quagga.conf for the Mobile Router
hostname Router
password zebra
enable password zebra
!
! eth1 dynamically advertises new prefixes
!
interface eth1
no ipv6 nd suppress-ra
ipv6 nd ra-interval 4
ipv6 nd netlink
!
log stdout
! # EOF
You can now execute Quagga with the following command, where 'user' and 'group' are the user and group you want to use to execute Quagga. See the zebra manpage for more information:
# zebra --daemon --config_file=/etc/quagga.conf --user='user' --group='group'
Please read also carefully the README.txt file included in the package for more information.
We can use dummy interfaces to avoid the use of a real network interface. Use the dummy kernel module:
# modprobe dummy
This will create a dummy0 interface. Bring it up and configure it with the Home Agent address:
# ifconfig dummy0 up # ifconfig dummy0 inet6 add 2001:a:b:0::1000/64
You can now use the dummy0 interface as the Home Link interface. In particular, you have to modify the /etc/radvd.conf, /etc/mip6d.conf and the startup script of the Home Agent to set the Home Link interface to dummy0.
It is possible to use cellular interfaces (GPRS, UMTS, etc.) with UMIP, but you need to have an IPv6 connectivity on this interface. One way is to use OpenVPN to provide the IPv6 connectivity over the point-to-point link, and to use a bridge interface as the one to use with UMIP. An excellent documentation contributed by Guillaume SCHREINER is available here: Setup OpenVPN with an UMTS interface on Debian GNU/Linux to get IPv6 connectivity.
Another way to get IPv6 connectivity is L2TP. A documentation to setup L2TP is available here: Setup L2TP on GNU/Linux to get IPv6 connectivity. However, there are some known problems when using the L2TP ppp interface with UMIP. You should then apply the following patches to have the correct behaviour: first, apply feat_is_dad_necessary.patch (this avoids to run DAD on PPP links), and then feat_wait_for_lladdr.patch (this allows UMIP to wait for a link-local address to be assigned by the kernel when no hardware address is available on the interface - contributed by Jozsef KOVACS). You will then have to recompile UMIP.
This is not really related to UMIP, but you may find what you need in this
tarball: Configure an UMTS/GPRS card on GNU/Linux OS.
References
[Back to ToC]
Request For Comments (RFC):
Mobile IPv6 and NEMO Basic Support implementations:
Misc. Softwares:
Technical Reports and papers:
Many thanks to the MIPL and UMIP developers who provides support on the MIPL Mailing Lists, people at Strasbourg University (Networks and Protocols team, LSIIT, Strasbourg, France), and people at Telecom-BretagneT (Rennes, France).
You can get support by subscribing to the following Mailing Lists:
Any comments to improve this document are welcome!
Romain KUNTZ
http://www.rkuntz.org
Strasbourg University, France