Do every configuration as shown above; it's especially important to have a different ESSID on the home net and visited network.
When you start mobile-IPv6 on MN, you will see multicasting router solicitations messages:
# tcpdump -i eth0 -vv ip6 or proto ipv6
...
13:32:54.681763 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
13:32:55.681763 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
13:32:57.681765 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
...
Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link).
To easily see whats going on, you should have one xterm window for each of these commands:
# watch ifconfig eth0
# watch route -A inet6
# tcpdump -i eth0 -vv ip6 or proto ipv6
To “travel” to another net, you can issue the command on MN:
# iwconfig eth1 essid visitnet
The MN is then on the other wireless network, and since it is sending out “router solicitation” (multicast), our AR will respond with it's prefix. MN will then configure itself with at new IPv6 address with the received prefix and it's own MAC address. If you type ifconfig eth0 you will see the new IPv6 address:
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:90:7D:F3:03:1A
inet6 addr: fec0:106:1100:0:290:7dff:fef3:31a/64 Scope:Site 
inet6 addr: fec0:106:2700:0:290:7dff:fef3:31a/64 Scope:Site 
inet6 addr: fec0:106:2700::4/64 Scope:Site 
inet6 addr: fe80::290:7dff:fef3:31a/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:854 errors:154 dropped:154 overruns:0 frame:148
TX packets:293 errors:58 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:96536 (94.2 Kb) TX bytes:44664 (43.6 Kb)
Interrupt:3 Base address:0x100
| The new “foreign” address, generated by combining AR's prefix and MAC-address |
| The superfluous home network address (because of HA radvd messages and MN autoconf set to “true”). |
| The “original” (home) address |
| The link-local address generated at boot |
Almost at the same time, the MN will perform a binding update to HA. In your tcpdump window, you will see several packets destined to HA. To verify that the binding update has been sent and acknowledged from MN:
# mipdiag -s
Mobile IPv6 Statistics
NEncapsulations : 0
NDecapsulations : 0
NBindUpdatesRcvd : 0
NBindAcksRcvd : 1
NBindNAcksRcvd : 0
NBindRqsRcvd : 0
NBindUpdatesSent : 1
NBindAcksSent : 0
NBindNAcksSent : 0
NBindRqsSent : 0
NBindUpdatesDropAuth : 0
NBindUpdatesDropInvalid : 0
NBindUpdatesDropMisc : 0
NBindAcksDropAuth : 0
NBindAcksDropInvalid : 0
NBindAcksDropMisc : 0
NBindRqsDropAuth : 0
NBindRqsDropInvalid : 0
NBindRqsDropMisc : 0
| One binding ACK received. |
| One binding UPDATE sent. |
You can also verify the binding with the following command (on MN):
# mipdiag -l
Mobile IPv6 Binding update list
Recipient CN: fec0:106:2700::2
BINDING home address: fec0:106:2700::4 care-of address: fec0:106:1100:0:290:7dff:fef3:31a
expires: 936 sequence: 0 state: 1
delay: 3 max delay 32 callback time: 736
You can also verify it on HA with the statistics option (-s) and with the “binding cache” (-c) option:
# mipdiag -c
Mobile IPv6 Binding cache
Home Address Care-of Address Lifetime Type
fec0:106:2700::4 fec0:106:1100:0:290:7dff:fef3:31a 971 2
From the MN, you can try to ping AR's eth1 (fec0:106:1100::1):
# ping6 fec0:106:1100::1
PING fec0:106:1100::1(fec0:106:1100::1) from fec0:106:2700::4 : 56 data bytes
64 bytes from fec0:106:1100::1: icmp_seq=1 ttl=62 time=8.01 ms
64 bytes from fec0:106:1100::1: icmp_seq=2 ttl=62 time=8.02 ms
...
By using tcpdump, you can see how the packets travel:
12:13:51.789688 fec0:106:1100:0:202:a5ff:fe6f:a08a > fec0:106:2700::2: \
fec0:106:2700::4 > fec0:106:1100::1: icmp6: echo request \
(len 64, hlim 64) (len 104, hlim 255)
12:13:51.797675 fec0:106:2700::2 > fec0:106:1100:0:202:a5ff:fe6f:a08a: \
fec0:106:1100::1 > fec0:106:2700::4: icmp6: echo reply \
(len 64, hlim 62) (len 104, hlim 253)
| The packet first goes from MN to the HA using MN new IPv6 address. |
| Then from HA to AR. |
| The AR then responds to HA and tunnels the packets to MN. |
You can now see the statistics have been updated (on MN):
# mipdiag -s
Mobile IPv6 Statistics
NEncapsulations : 56
NDecapsulations : 25
...
One interesting thing MIPv6 does is change the default route to a tunnel. The new default route becomes:
# route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 :: UD 64 0 0 ip6tnl1
....
If it doesn't add a default route, you may add it manually:
# ip route ::/0 via dev ip6tnl
To travel to several visited networks, is no different than travel to one network. The only thing you must have in mind is that you will generate a new address for each visited network.
MN first visits 'visitnet', as we have been through above.
MN is then travelling from 'visitnet' to 'visitnet2'.
When at 'visitnet2', MN generates a new IPv6 address and do a new binding update to HA.
MN then travels back home. (Se next section.)
The AR at “visitnet2”, is configured exactly
as the other AR (at “visitnet”), except using address
fec0:106:1000::/64 instead of
fec0:106:1100::/64.
To make the mobile node travel from 'visitnet' to 'visitnet2', issue the command (on MN):
# iwconfig eth0 essid visitnet2
You will then see the MN configures itself to the new network:
# ifconfig eth0
eth1 Link encap:Ethernet HWaddr 00:90:7D:F3:03:1A
inet6 addr: fec0:106:1000:0:290:7dff:fef3:31a/64 Scope:Site
inet6 addr: fec0:106:1100:0:290:7dff:fef3:31a/64 Scope:Site
inet6 addr: fec0:106:2700:0:290:7dff:fef3:31a/64 Scope:Site
inet6 addr: fec0:106:2700::4/64 Scope:Site
inet6 addr: fe80::290:7dff:fef3:31a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1073 errors:212 dropped:212 overruns:0 frame:204
TX packets:371 errors:72 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:120340 (117.5 Kb) TX bytes:56912 (55.5 Kb)
Interrupt:3 Base address:0x100
| The new autoconfigured address at 'visitnet2'. |
Note! You may have to restart mobile-ipv6 on MN when coming to a new network!
# /etc/init.d/mobile-ip6 restart
Stopping Mobile IPv6: OK
Starting Mobile IPv6: OK
The MN will then perform a new binding update to HA. Notice the new “care-of address”:
# mipdiag -l
Mobile IPv6 Binding update list
Recipient CN: fec0:106:2700::2
BINDING home address: fec0:106:2700::4 care-of address: fec0:106:1000:0:290:7dff:fef3:31a
expires: 973 sequence: 14 state: 1
delay: 3 max delay 32 callback time: 773
You can also see the “binding cache” on HA has been updated:
# mipdiag -c
Mobile IPv6 Binding cache
Home Address Care-of Address Lifetime Type
fec0:106:2700::4 fec0:106:1000:0:290:7dff:fef3:31a 943 2
To make the MN return home, you can just issue the command:
# iwconfig eth0 essid homenet
The MN will know it is back home, since HA is sending out radvd messages with the HA-bit set (AdvHomeAgentFlag), see Section 4.2.4, “Configuring radvd on HA”
You can see the MN “is back home”, since the binding cache information at HA is flushed (empty):
Mobile IPv6 Binding cache
Home Address Care-of Address Lifetime Type
To really get the feel on how mobile IP works, fire up GnomeMeeting (See the figure GnomeMeeting and start a netmeeting. Note! You must use the latest GnomeMeeting to get support for IPv6! Then do a “travel” and you can see an almost smooth handover.
