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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Petros Koutoupis' RapidDisk
- ServersCheck's Thermal Imaging Camera Sensor
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide