Mobile IPv6 for Linux Guide (with USAGI patch)

[Japanese version]


This article provides a tutorial on how to setup Mobile IPv6 (MIPv6) with UMIP 0.4 on Linux.

Basic kernel configuration, IPv6 networking operation, configuration experience and basic MIPv6 knowledge are needed. If you use IPsec, basic IPsec knowledge and IPv6 tunnel gateway configuration experience is also required.

Please check first the Known Issues.

Information about older version of UMIP are moved here for umip-0.3 and here for umip-0.1.


For all nodes (HA, MN and CN)

For HA

  • radvd

For HA and MN

  • IPsec-Tools (If you use IPsec with MIPv6, as explained in RFC3776)

Building kernel and mip6d

  • Kernel
    • Follow the instructions to build the kernel as explained in the INSTALL.kernel file included in the mip6d source tree.
  • mip6d
    • Follow the instructions as explained in the INSTALL file included in the mip6d source tree. Be sure to compile it with debugging option using --enable-vt at configure time. Note that you may need to specify additional include path such as -isystem /path/to/kernel/arch/x86/include (at configure time too).


After mip6d is installed, you can check the mip6d.conf(5) manpage which has useful information about configuration.

HA specific configuration

  • router: HA should be configured as an IPv6 router with forwarding=1.
  • proxy ND: HA should be enabled proxy ND with proxy_ndp=1 (required to support returning-home).
  • IPsec: See IPsec configuration.
  • mip6d: See the mip6d.conf(5) manpage. An example is mip6d-ha.conf.
  • RD: Send RA on the Home Link with the HA-related options set (e.g. the "HA flag"), the HA address as network prefix and the "router address flag" on prefix information. See also the radvd.conf(5) manpage for more details if you use radvd. An example is radvd.conf.
    • (optional): It is recommended to use small router advertisement intervals. This can also apply on the access router on the foreign links where the MN moves.

MN specific configuration

CN specific configuration

  • See the mip6d.conf(5) manpage for mip6d. An example is mip6d-cn.conf.

IPsec configuration

  • [HA,MN] See the README.IPsec file included in the mip6d source tree. An example is setkey.conf.

Boot sequence

HA boot sequence

  1. Before starting mip6d, the following conditions should be satisfied:
    • Be ready as a router
    • Be ready for proxying ND (when using returning-home)
    • Having a global unicast address assigned on the Home Link interface (the HA address)
    • Having the IPsec SA configured (when using IPsec with static keying)
  2. Run mip6d
  3. After mip6d is started:
    • Start RD

An easy example boot script to do the above is given in

MN boot sequence

  1. Before starting mip6d, the following conditions should be satisfied:
    • The interface connected to the access network is brought up before you run mip6d.
    • Having the IPsec SA configured (while using IPsec with static keying).
  2. After you have met these conditions, you can run mip6d.

An easy example boot script is

CN boot sequence

  1. Run mip6d

An easy example boot script is

Another examples

  • Experimental mip6d init script using LSB (for Debian Distribution)



  • mip6d writes start or stop messages to syslog and you can check it.
  • [HA] Try the virtual terminal to see mip6d information like below:
      $ telnet localhost 7777 
      Trying ::1... 
      Connected to ip6-localhost. 
      Escape character is '^]'. 
      mip6d> pl
      eth1 3ffe:501:ffff:100:200:ff:fe00:a0a0/64
       valid 2591997 / 2592000 preferred 604800 flags OAR 

If you could get home prefix valid lifetime with positive value there, the HA is ready to serve. Otherwise, you should check the RA configuration.

Binding cache

  • Try the virtual terminal to see mip6d information like below:
      $ telnet localhost 7777 
      Trying ::1... 
      Connected to ip6-localhost. 
      Escape character is '^]'. 
      mip6d> bc 
      hoa 3ffe:501:ffff:100::1 status registered 
       coa 3ffe:501:ffff:102::1 flags AH-- 
       local 3ffe:501:ffff:100:200:ff:fe00:a0a0 
       lifetime 998 / 1000 seq 58722 unreach 0 mpa - / 0 retry 0 

If the node has binding cache correctly, you will get entries there with registered [HA], cached [CN] at "status" for each MN's HoA respectively.

Binding update list

  • [MN] Try the virtual terminal to see mip6d information like below:
      $ telnet localhost 7777 
      Trying ::1... 
      Connected to localhost. 
      Escape character is '^]'. 
      mip6d> bul 
      == BUL_ENTRY == 
      Home address 3ffe:501:ffff:100::1 
      Care-of address 3ffe:501:ffff:102::1 
      CN address 3ffe:501:ffff:100:200:ff:fe00:a0a0 
       lifetime = 262140, delay = 249033000 
       flags: IP6_MH_BU_HOME IP6_MH_BU_ACK 
       ack ready 
       lifetime 262124 / 262140 seq 26633 resend 0 delay 249033(after 249017s) 
       mps 214747931 / 214747947 

If the MN sent BUs, you can find entries there for HA/CN respectively. To confirm home registration is completed, check the HA entry whose "ack" value is ready.

Route optimization

We don't have an easy and good route optimization test for both-direction (other than using TAHI test or dumping packet). On the other hand, with the ping6 command from USAGI git iputils-mip6 tree, you can check whether inbound echo reply is route-optimized or not.

  • Prepare ping6 from iputils-mip6 git tree.
  • Try ping6 with "-H" option to see extension headers carried by echo reply.


  • [HA,CN] Receiving a route-optimized echo reply from MN:
      $ ping6 -H -I HACN_ADDR MN_ADDR 
      64 bytes from MN_ADDR[HAO]: icmp_seq=1 ttl=61 time=1.04 ms
  • [MN] Receiving a route-optimized echo reply from HA, CN:
      $ ping6 -H HACN_ADDR 
      64 bytes from HACN_ADDR[RT2]: icmp_seq=1 ttl=61 time=1.04 ms

Known issues

Kernel support status

Here is the mainline kernel support status (as of 2.6.23).

nodebasicIPsec transportIPsec tunnel
HAOK *1OK *1OK *3
MNOK *2OK *4OK *4,*3
CNOK *1- *5,*1-
  • *1: 2.6.19 or later
  • *2: 2.6.22 or later (Support combination action between source address specific rule and source address selection)
  • *3: 2.6.21 or later (PFKEY_MIGRATE support)
  • *4: 2.6.22 or later (Fix IPsec combination; Restrict upper layer information by bundle)
  • *5: It works about RO over transport mode IPsec

Known issues

  • [MN] MN incorrectly sends bidirectional RO before both BCEs are ready on Inter-MN RO. This issue can be reproduced with the following steps:
  1. Two MNs are on (each) foreign link and both MNs bind each other i.e. bidirectional RO (IPv6-RH2-HAO) communication has been successful.
  2. One MN(a) goes to another foreign link.
  3. The other MN(b) sends unidirectional RO (IPv6-IPv6-HAO) echo request before MN(a) completes binding to MN(b).
  4. MN(a) receives the echo request and sends echo reply back over bidirectional RO incorrectly.
  • [HA,MN,CN] TCP over RO issue (fixed with USAGI kernel patch or 2.6.24): if the node starts TCP connection without RO, the node incorrectly continues the connection without RO even after RO is ready on kernel. This issue occurs for TCP over IPsec, too.
  • [HA] HA sends wrong Redirect for IPsec tunneled packet (fixed with USAGI kernel patch or 2.6.24): IPsec tunnel gateway incorrectly sends redirect to router or sender when the network device from which the IPsec tunneled packet arrived is the same as the one the de-capsulated packet is sent.
  • [MN] IPsec tunnel configuration "TunnelMh" and "TunnelPayload" do not work: this is because the daemon does not support yet to deal with kernel change to use XFRM selector without specified if-index.
  • [MN] MN sends RO packet to default router's MAC address (fixed with USAGI git (linux-2.6.24-mip6 branch or later) or scheduled for 2.6.26): when MN is on the link where CN is located, the MN sends RO packet to the CN with not the CN's but default router's MAC address of the link without sending any NS (The packet may be forwarded to the CN by the router).
  • [MN] MN does not learn from Redirect targeted for CN: when MN and CN are on the same link and the MN created a BCE on the CN, the MN does not make neighbor cache for the CN even when the MN has received Redirect targeted the CN from a router on the link.
  • [MN] MN internally blocks to send BU to HA for the first boot time: (the detailed condition is not determined but) this occurs when IPsec is disabled or IPsec is enabled with "HomeRegBinding" and "MobPfxDisc". This can be fixed if the daemon restarts.