Mobile IPv6 with Linux
Free software is freedom, and so is mobility. In an age of embedded devices, nomadic users and omnipresent wireless connectivity, augmenting the venerable Internet Protocol (IP) with movement awareness and adaptability is due. IP's founding architects designed it with the assumption that the Internet node is static. This simplified the design by enabling a single field, the IP address, to signify both location and identity. A sending machine refers to a receiving one by the IP address (the identification role), and routers in the network use the IP address to direct traffic to the right path (the topological role). In this age of portability and nomadicity, this conflation of functions introduces a contradiction. For routing to do its job, the address needs to change according to the location; for the address to be used as an identifier, it must remain fixed.
Mobile IP (MIP), an extension of IP, provides a solution for that problem. The Internet Engineering Task Force (IETF) has been actively developing MIP for both IPv4 and IPv6 since the 1990s. The Mobile IPv6 (MIPv6) standard advanced from draft status to Proposed Standard (PS) status in 2004. Since then, optimizing and securing MIPv6 has become an active standardization and development area. A cost-effective, flexible and insightful vehicle for getting hands-on experience with MIPv6 is to experiment with the Mobile IPv6 for Linux (MIPL) package that the Helsinki University of Technology (HUT) has been developing since 1999.
The purpose of this article is to get you, the brave roamer, primed in MIPv6 by experimenting with MIPL. It assumes basic understanding of IPv6 and wireless LAN networking, and it consists of two parts: the first introduces MIPv6, and the second introduces MIPL.
IP mobility means the ability to handle movement gracefully. Movement, in the context of MIP, is an event or an operation that causes a machine to change its IP address. It is a movement from one IP subnet to another. Physical movement could cause it, but that isn't the only way a machine could “move” in the context of MIP. At the same time, physical movement doesn't necessarily translate to a network layer movement. Movement within a single wireless cell, for example, doesn't cause a subnet change and, thus, isn't movement from MIP's perspective. Movement is problematic for traditional IP. It forces a machine to change its IP address so as to belong to the new subnet to which it has just moved. Movement changes the machine's identification. It tears down TCP connections, such as Web-browsing sessions, because the IP address is one of the parameters that identifies a TCP connection. This makes for a rough roaming experience, as sessions have to be re-established each time a handover happens.
MIP deals with movement by decoupling identity from location. MIP provides each Mobile Node (MN) with two addresses: a permanent (long-term) address that embodies identity, called the Home Address (HoA), and a temporary (short-term) address that embodies location, called the Care-of Address (CoA). The HoA remains fixed, while the CoA freely changes according to the location of the node. MIP provides a mechanism to map between the two addresses dynamically. A moving machine (Mobile Node) changes its CoA each time it moves from one subnet to another, but it maintains its HoA and uses it to provide any node communicating with it, called a Correspondent Node (CN), with a stable destination address.
The mapping between the HoA and the CoA is called binding and is the central concept underlying MIP. The message that establishes the binding is called a Binding Update (BU). A table that tracks bindings is called a Binding Cache (BC). Sending Binding Updates and maintaining Binding Caches is the essence of MIP. All other aspects of the MIP protocol are to scale, secure, optimize and generally enhance the way bindings are established and used.
To provide a concrete description of MIP, let's look at the interactions between the participants in MIP in its most basic mode of operation (without Route Optimization). At its home network (home link), the MN uses its address (the HoA) in the standard fashion. MIPv6 kicks in upon movement detection. When the MN notices that its current default router has disappeared (it can no longer hear the router's advertisements) and that a new router is now chirping, it concludes that it has “moved” and uses the new prefix (subnet ID) to configure a new address (a new CoA) that belongs to the new subnet. It then sends a BU to a special router on the home link, called the Home Agent (HA), telling it that the HoA it “owns” is now bound to that new CoA. The HA records the mapping between the HoA and the CoA in its BC. Adding an entry to the BC is called registration. Traffic destined to the HoA, from any CN on the Internet, is routed to the home network because the HoA topologically belongs to it. There, the HA intercepts it and tunnels it to the MN's CoA address registered in the BC. Return traffic is reverse tunneled from the MN back to the HA and then sent from the HA to the CN. This way, the MN becomes always addressable by its HoA.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide