Mobile IPv6 with Linux
Now the scene is complete, and we can start experimenting with mobility. Before we start, remember the following about MIP: movement detection is the trigger; binding updating (registration) is the action. We'll start by letting the MN move, then check whether movement was detected. Upon witnessing movement detection, we'll check whether a BU was established successfully. Figure 2 shows the network's state before moving. To simulate movement, we use iwconfig to switch the MN's wireless interface from one ESS (wireless cell) to another:
[raven]# iwconfig wlan0 essid "remote"
Upon moving, the wireless interface should acquire a new address, and a new default gateway should appear (Listing 3).
Listing 3. Moving
... Before Moving (At the Home Network) ... [raven]# iwconfig wlan0 | grep ESSID wlan0 IEEE 802.11b ESSID:"home" [raven]# ifconfig wlan0 | grep inet6 inet6 addr: 2001:db8::beef/64 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link inet6 addr: 2001:db8::205:5dff:fef2:db2b/64 Scope:Global [raven]# ifconfig ip6tnl1 | grep inet6 inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# route -A inet6 | grep ::/0 ::/0 fe80::202:6fff:fe06:bcf UGDA 1024 0 0 wlan0 ... Triggering Movement ... [raven]# iwconfig wlan0 essid remote ... After Moving (At the Foreign Network) ... [raven]# iwconfig wlan0 | grep ESSID wlan0 IEEE 802.11b ESSID:"remote" [raven]# ifconfig wlan0 | grep inet6 inet6 addr: 2001:db8:1:0:205:5dff:fef2:db2b/64 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# ifconfig ip6tnl1 | grep inet6 inet6 addr: 2001:db8::beef/128 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# route -A inet6 | grep ::/0 ::/0 :: U 128 0 0 ip6tnl1 ::/0 fe80::202:6fff:fe06:4610 UGDA 1024 4 2 wlan0 [raven]#
Using a packet capturing tool (sniffer), such as tcpdump, we should see a different router appearing on the link. The Mobility Dæmon log messages should indicate movement detection (md in the logs stands for movement detection). Now that the MN has detected movement and acquired a new CoA address, it should send a BU to its HA. A sniffer should be able to display the BU message as:
IP6 2001:db8:1:0:205:5dff:fef2:db2b > 2001:db8::: ↪DSTOPT mobility: BU seq#=54814 AH lifetime=262140 IP6 2001:db8:: > 2001:db8:1:0:205:5dff:fef2:db2b: srcrt ↪(len=2, type=2, segleft=1, 2001:db8::beef) ↪mobility: BA status=0 seq#=54814 lifetime=262140
In addition, the Mobility Dæmon should have a BU List Entry (BULE) that shows the HoA, CoA and HA addresses:
[raven]# telnet localhost 7777 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. mip6d> bul mip6d> bul == BUL_ENTRY == Home address 2001:db8:0:0:0:0:0:beef Care-of address 2001:db8:1:0:205:5dff:fef2:db2b CN address 2001:db8:0:0:0:0:0:0 lifetime = 262140, delay = 249033000 flags: IP6_MH_BU_HOME IP6_MH_BU_ACK ack ready dev wlan0 last_coa 2001:db8:1:0:205:5dff:fef2:db2b lifetime 262136 / 262140 seq 19428 resend 0 delay 249033(after 249030s) expires 262136 mps 2 / 3 mip6d>
We can see whether the BU was received and accepted by looking at the HA's Mobility Dæmon log messages and by displaying the HA's BC:
[denali]# telnet localhost 7777 mip6d> bc mip6d> bc hoa 2001:db8:0:0:0:0:0:beef status registered coa 2001:db8:1:0:205:5dff:fef2:db2b flags AH-- local 2001:db8:0:0:0:0:0:0 lifetime 262068 / 262140 seq 19429 unreach 0 ↪mpa 13133 / 13221 retry 0 mip6d>
As shown above, the Mobility Dæmon provides a virtual terminal interface to its internal data structures that you can access by a establishing a Telnet session to port 7777. Figure 3 shows the network's state after moving.
We can't conclude a networking experiment without some action from our old crony ping. From the MN, we'll start by sending ping requests to the HA interface, while the MN is on the home link. We'll then move and see what happens. This exercise is shown as follows:
[raven]# ping6 2001:db8:: 64 bytes from 2001:db8::: icmp_seq=7 ttl=64 time=3.72 ms 64 bytes from 2001:db8::: icmp_seq=8 ttl=64 time=3.70 ms ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Operation not permitted 64 bytes from 2001:db8::: icmp_seq=13 ttl=63 time=142 ms 64 bytes from 2001:db8::: icmp_seq=14 ttl=63 time=122 ms
Note that in responding to ping requests, the HA interface is actually acting as a CN. Note how, upon the handover, the MN loses connectivity for some time, called the handover latency, and then re-establishes it. Note also how the delay increases tremendously as the MN moves.
A more interesting test is to use a program that sends video like VLC or GnomeMeeting and visually assess how smooth the handover is. Although the ultimate goal of MIPv6 is to achieve smooth and lossless handover, in reality, there is a blackout period during which packets are lost or delayed. Much of the effort put into developing and standardizing MIPv6 is to enhance the smoothness of the handover and ultimately achieve seamless handover. As with any other technology, realizing the limitations is as crucial as recognizing the value.
- Nice coding on the cake. I
2 hours 38 min ago
- Baker's identity
7 hours 28 min ago
- Uber jealous
12 hours 25 min ago
- Reality is disapointing
22 hours 57 min ago
- Máy sấy quần áo
1 day 1 hour ago
- Services on GlusterFS
1 day 1 hour ago
- Reply to comment | Linux Journal
1 day 3 hours ago
- Definitely cool stuff here
1 day 4 hours ago
- thanks for the information
1 day 5 hours ago
- nice information thanks
1 day 6 hours ago