Romain KUNTZ http://www.rkuntz.org
Nautilus6 Working Group http://www.nautilus6.org
Created on 2005-11-10 Version 2.8 (Last modified on 2010-02-08)
[http://www.nautilus6.org]



NEPL (NEMO Platform for Linux) HOWTO


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.



Latest News


February 8th, 2010: Added patches for MCoA (contributed by Vilmos Nebehaj) that fixes the fact the BU may be sent through a disconnected interface. More information here and here

Patches and Documentation update on June 24th, 2009:
  • Updated the NEPL patch (version 20090624). It fixes routing problems when returning home.
  • Updated the MCoA patch (version 20090624). It does not include new features, but can be applied above the updated NEPL patch.
  • Updated documentation to use a 2.6.29 kernel. As a result, no patches are needed for the kernel anymore.

  • Note: Older patch and software releases are available here. A complete changelog is available at the end of this page.


    Table of Contents


    1. IPv6, Mobile IPv6 and NEMO Basic Support
    2. Overview of the NEPL implementation
    3. The NEPL test network
    4. Setup and configuration
    5. Operation
    6. Multiple Care-of Addresses registration
    7. NEPL enhancements
    FAQ
    References
    Acknowledgement
    Support
    Changelog
    Contact


    1. IPv6, Mobile IPv6 and NEMO Basic Support
    [Back to ToC]



    a. The IPv6 protocol
    [Back to ToC]


    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.


    b. Mobile IPv6
    [Back to ToC]


    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.


    c. NEMO Basic support
    [Back to ToC]


    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.


    d. Useful References
    [Back to ToC]


    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


    2. Overview of the NEPL implementation
    [Back to ToC]


    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:

  • Mobile Router registration and deregistration to the Home Agent, using explicit mode and implicit mode, and using DHAAD to discover the Home Agent,
  • Communications between two Mobile Networks, with the same or a different Home Agent for each Mobile Router,
  • Up to two levels of Nested mobility, including Nested Mobile Networks and Visiting Mobile Node in a Nested Mobile Network.


  • Useful References
    [Back to ToC]


    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


    3. The NEPL test network
    [Back to ToC]


    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:

  • A Home Link HL where the Home Agent HA is located. The Home Agent is the gateway of the Home Link and interconnects HL and the Foreign Link 1 (FL1). It can delegate /64 Mobile Network Prefixes (MNPs) to the Mobile Routers. The prefix 2001:a:b:0::/60 will be used for the Home Link Prefix and the Mobile Network Prefixes as followed:
  • Two Foreign Links FL1 and FL2 interconnected by a Router R.
  • A Mobile Network connected to the Internet via a Mobile Router MR. The MR can move between the Home Link (HL), FL1 and FL2.
  • Some Mobile Network Nodes (MNNs).
  • 
                      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]
                
    

    4. Setup and configuration
    [Back to ToC]


    a. The Router R
    [Back to ToC]


    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
    

    b. Kernel setup for HA and MR
    [Back to ToC]


    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.


    c. Userland for the Mobile Router and the Home Agent
    [Back to ToC]


    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.


    d. Home Agent configuration
    [Back to ToC]


    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.


    e. Mobile Router configuration
    [Back to ToC]


    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.


      e1. Configure the MR with the interface preference mechanism

    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.


    f. IPsec configuration
    [Back to ToC]


    An excellent HowTo to configure IPsec with dynamic keying on UMIP (using racoon2) is available here. This document has been contributed by Sebastien DECUGIS.


    5. Operation
    [Back to ToC]


    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.


    6. Multiple Care-of Addresses registration
    [Back to ToC]


    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.


    a. Limitations
    [Back to ToC]


    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!


    b. Kernel Options
    [Back to ToC]


    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.


    c. Userland Compilation
    [Back to ToC]


    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.


    d. Home Agent Configuration
    [Back to ToC]


    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.


    e. Mobile Router Configuration
    [Back to ToC]


    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.


    f. Policy Routing
    [Back to ToC]


    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.


    7. NEPL enhancements
    [Back to ToC]


    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.


    a. Mobile Network Prefix Delegation
    [Back to ToC]


    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.


      a1. Compile a 2.6.11 kernel with Mobility Options

    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.


      a2. Compile NEPL with Prefix Delegation support

    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.


      a3. Configure the Home Agent

    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
    

      a4. Configure the Mobile Router

    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.


      a5. Setup Quagga/rtadv for Dynamic Prefix Advertisement

    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.


    FAQ: Frequently Asked Questions
    [Back to ToC]


  • How to configure a Virtual Home Link on the Home Agent?
  • 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.


  • How to use point-to-point interfaces with UMIP?
  • 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.


  • How to get my GPRS/UMTS card working on Linux?
  • 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):

  • RFC3963 "Network Mobility (NEMO) Basic Support Protocol"
  • RFC3775 "Mobility Support in IPv6"
  • RFC2460 "Internet Protocol, Version 6 (IPv6) Specification"
  • RFC2462 "IPv6 Stateless Address Autoconfiguration"
  • Mobile IPv6 and NEMO Basic Support implementations:

  • UMIP: a patch set for the MIPL2 software
  • MIPL2: Mobile IPv6 for Linux
  • Multiple Care-of Addresses registration for NEPL
  • NEPL-SE: Enhancement for NEPL (Obsolete)
  • KAME/SHISA: Mobile IPv6 and NEMO Basic Support for *BSD
  • Misc. Softwares:

  • Uml_clownix_net, a topology modifiable virtual network to be used with UMIP
  • QUAGGA Routing Software
  • Technical Reports and papers:

  • HowTo: Dynamic keying for Mobile IPv6 using racoon2 and mip6d
  • Setup OpenVPN with an UMTS interface on Debian GNU/Linux to get IPv6 connectivity
  • Setup a CF card with a GNU/Linux OS including NEMO support.
  • NEMO interoperability tests at the 6th IPv6 TAHI Event
  • NEMO-related research and technical papers and posters

  • Acknowledgement


    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).


    Support


    You can get support by subscribing to the following Mailing Lists:

  • support(at)ml.nautilus6.org: You can get or provide support for our softwares and documents on this mailing list. Feel free to describe your problems, report bugs, send patches etc. on this mailing list. You can check the archives of this ML here.
  • announce(at)ml.nautilus6.org: All demonstrations, events and softwares in which Nautilus6 is involved are announced on this mailing list. Members of this ML cannot post on it. You can check the archives of this ML here.
  • Any comments to improve this document are welcome!


    Changelog


    Patches and Documentation update on June 24th, 2009:
  • Updated the NEPL patch (version 20090624), which fixes routing problems when in the home network.
  • Updated the MCoA patch (version 20090624). It does not include new features, but can be applied above the updated NEPL patch.
  • Updated documentation to use a 2.6.29 kernel. As a result, no patches are needed for the kernel anymore.

  • Patch and Documentation update on June 24th, 2009:
  • Added a FAQ entry on how to configure a virtual Home Link with a dummy interface for the Home Agent.

  • Documentation update on February 05th, 2009:
  • Added a FAQ entry on how to configure a virtual Home Link with a dummy interface for the Home Agent.

  • Documentation update on July 19th:
  • Added a FAQ section with some tips for people having troubles using UMIP over PPP interfaces.

  • Patches and documentation update on January 8th.
  • Released new NEPL and MCoA patch (version 20080108). The NEPL patch fixes a registration issue on the HA and improves the IPsec code to protect the traffic from and to the MNP (contributed by Arnaud EBALARD). The MCoA patch is an update to be able to use it on top of the new NEPL patch.
  • Added a link to an IPsec documentation for UMIP and NEPL (see the new section 4.f, contributed by Sebastien DECUGIS)
  • Added a link to Uml_clownix_net, a virtual platform to be used with UMIP (see in References)

  • Patches update on November 5th.
  • Released new NEPL and MCoA patch (version 20071105). The MCoA patch fixes a bug in MCoA preventing the MR to correctly bind with its Home Agent. The NEPL patch fixes a bug on Big Endian computers and add some NEMO-related debug messages (contributed by Arnaud EBALARD).

  • Small update on October 26th.
  • Released new NEPL and MCoA patch (version 20071026) fixing a bug in the NEMO IPsec code.

  • Version 2.3 released on October 22nd.
  • Updated to newer userland (UMIP 0.4) and newer kernel (2.6.23)
  • Updated the NEMO patch to UMIP 0.4. It now supports IPsec Tunnel Payload protection for the traffic from and to the MNNs (Contributed by Sebastien DECUGIS).
  • Updated the MCoA patch to UMIP 0.4.
  • Pre-compiled kernels and userland with NEMO support are now available: see section 4.b and 4.c

  • Version 2.2 released on July 16th 2007.
  • Updated the MCoA patch for UMIP (version 20070716) (section 6),

  • Version 2.1 released on June 15th 2007.
  • Patch for UMIP 0.3 that fixes UMIP bugs (section 4.c),
  • Updated UMIP kernel patch to 2.6.21.3 kernel (section 4.b),
  • Updated the NEPL patch for UMIP (section 4.c),
  • Released a MCoA patch for UMIP (section 6),

  • Version 2.0 released on May 8th 2007.
  • Updated to newer userland (UMIP) and newer kernel (2.6.21). See section 4.b and 4.c
  • More information about UMIP can be found in section 4.b

  • Version 1.9 released on January 18th 2007.
  • Updated section 6 to latest MCoA release (beta3)

  • Version 1.8 released on January 9th 2007.
  • Solved the problem preventing the MR to work correctly when in the Home Network.

  • Version 1.7 released on June 30th 2006.
  • Updated section 6 to latest MCoA release (beta2)
  • There is still the problem preventing the MR to work correctly when in the Home Network

  • Version 1.6 released on June 1st 2006.
  • Added some instruction for Multiple CoA registration. See section 6
  • There is still the problem preventing the MR to work correctly when in the Home Network

  • Version 1.5 released on February 28th 2006.
  • Updated to newer userland and kernel (nemo-0.2 and kernel 2.6.15).
  • There is a problem preventing the MR to work correctly when in the Home Network

  • Version 1.4 released on February 22th 2006.
  • Updated the interface preference section.

  • Version 1.3 released on February 20th 2006.
  • Updated to newer userland (nemo-20060220).
  • This solves serious thread management problem on the HA.
  • Added a link to the Linux CF HowTo (see References).

  • Version 1.2 released on February 17th 2006.
  • Updated testbed to Linux kernel 2.6.14 and newer userland (nemo-20060217)

  • Version 1.1 released on February 9th 2006.
    Version 1.0 created on November 10th 2005.

    Contact


    Romain KUNTZ
    http://www.rkuntz.org
    Strasbourg University, France




    Created on 2005-11-10
    v.2.8 last modified 2010-02-08