Mobile IP is set to be one of the great enablers of the 21st century. This ubiquitous deployment of Mobile IP means today's designers and engineers must be up to speed on its basics.|By Urban Lindegren

Glossary of acronyms
aFA — anchor Foreign Agent
ATM — Asynchronous Transfer Mode
BET — Bi-directional Edge Tunnel
DHCP — Dynamic Host Configuration Protocol
DoD — U.S. Department of Defense
FA — Foreign Agent
GFA — Gateway Foreign Agent
GSN — Gateway Support Node
HA — Home Agent
IETF — Internet Engineering Task Force
IP — Internet Protocol
IPNET — a brand name used by Interpeak for its TCP/IP stack
IPsec — IP security
IPv4 — Internet Protocol Version 4 (the "current" IP)
IPv6 — Internet Protocol Version 6 (the "next generation" IP, sometimes called IPng)
L2 — Layer 2
L3 — Layer3
MD5 — an algorithm for creating digital signatures
MN — Mobile Node
nFA — new Foreign Agent
oFA — old Foreign Agent
OSI — Open System Interconnection
PDA — Personal Data Assistant
RAN — Radio Access Node
TCP/IP — Transmission Control Protocol/Internet Protocol
VoIP — Voice over Internet Protocol
VPN — Virtual Private Network
WLAN — Wireless Local Access Network
The explosion of handheld embedded devices with Internet capabilities has heightened the demand for user mobility. Examples of mobility required by users of Internet-connected devices (communicating via IP) include: mobility in the home, in the enterprise, and among other networks (including airports, coffee shops, and cellular coverage areas). Devices that will take advantage of such mobility, using Mobile IP, include mobile phones (offering VoIP or other Internet services), PDAs, and portable computers.

Today, when someone moves between networks, his device is likely to use a DHCP address, a dynamic, automatically assigned address from which the user can browse the Internet or send email. Each network that the user visits newly assigns this address.

It would be convenient if users could maintain a single, static IP address when moving among networks. Suppose that the user is in a town where there are overlapping WLANs and he passes through these wireless networks quite quickly — perhaps in a car. Today, each new WLAN would change the user's IP address, making for a new and random IP address every minute or so. This creates problems for applications that use continuous session-based connections.

Home Agents and Foreign Agents
The concept behind Mobile IP is simple. It is presented in detail in RFC 3344 from IETF. Here's the idea: A mobile device continually sends out a message announcing itself and registers with host networks as it travels from one to the other. A host network that receives the signal from the mobile device will communicate with the mobile device's home network to announce, "The mobile device is here, you can send messages for it in care of me."

click the image to enlarge

Figure 1. The MN travels between networks, instantly communicating with the FA on each new network. The FA alerts the home agent of the MN's arrival and then acts as a "care-of" address for the MN.
Three primary components make this concept possible: the MN, HA, and FA. The MN is the device — or more precisely, software on the device — that travels from network to network and registers with each new network. The MN needs to have a permanent or long-term IP address and a home base where the HA resides. The HA is a router on the home network that keeps track of the MN's whereabouts and tunnels data for delivery to the MN. Between these two, the traveling MN and the HA, is the FA, which acts as an intermediary. The FA is a router that provides routing services to the MN as long as it's registered, and de-tunnels (acts as the end point of the tunnel) incoming data that has been tunneled by the MN's home agent.

The process, in simplified form, follows this logic: the MN broadcasts its presence wherever it goes and communicates the address of its HA. As it enters the boundary of a network, that network's FA contacts the MN's home agent to let it know that the MN is there and that it can receive data intended for the MN. The FA sets up a "care-of" address for the mobile node. The HA is then able to send packets of data to the appropriate FA as the MN travels from network to network.

click the image to enlarge

Figure 2. A simplified look at the seven layers of the OSI model. The pre- and post-registration models operate at layers 2 and 3.
An MN is charged with detecting whether it is in its home network or not. Additionally, it always uses its permanent (or long-term) IP address when sending data. This way, other devices are always sending to the same IP address, whether or not they are responding to the MN or initiating a communication. Using protocol tunneling, Mobile IP is able to hide an MN's home address from intervening routers between the home network and current location. In certain situations, reverse tunneling is implemented from the FA back to the home network.

Latency for Real-time Services
There are numerous considerations specific to the HA, FA, and MN. Types of networks and specific situations dictate a wide variety of ways in which the components will interact and how they will be able to transmit data. RFC 3344 describes the various IP-layer hand-offs. Among Mobile IP's more significant challenges, a critical one is ensuring that latency is low enough to provide a seamless experience for users of real-time applications, such as voice or video. In an IETF draft on "Low Latency Hand-offs in Mobile IPv4," the authors note:
"Mobile IPv4 describes how a Mobile Node can perform IP-layer hand-offs between subnets served by different Foreign Agents. In certain cases, the latency involved in these hand-offs can be above the threshold required for the support of delay-sensitive or real-time services."

The draft explains that the cause for potential delays is in part due to the wide applicability that was originally designed into Mobile IP. Mobile IP makes no assumptions about underlying link layers over which it operates, which can result in negative consequences, specific to delays.

click the image to enlarge

Figure 3. One example of the pre-registration hand-off method.
The IETF draft on low-latency hand-offs presents three methods for minimizing the time required for Mobile IP hand-offs from one FA to another. These are called pre-registration hand-off method, post-registration hand-off method, and combined hand-off method. Generally, there are two basic functions that these methods enable: first, they enable an MN to communicate with an nFA while still connected to an oFA. Second, they create a way for data delivery to the MN at the nFA before completion of the formal registration process.

Now we should look at the OSI model, which defines a networking framework for implementing protocols in seven layers. As noted, Mobile IP makes no assumptions about underlying link layers over which it operates, which can result in negative consequences.

click the image to enlarge

Figure 4. One example of the post-registration hand-off method.
In the pre-registration hand-off method, the MN performs an L3 hand-off before completing the hand-off on L2. The L3 hand-off can be initiated by either the network or the MN. In the post-registration hand-off method, the oFA and nFA are able to set up a bi-directional tunnel, which enables the MN to use the oFA while on the nFA's subnet. This continues until the MN can perform the appropriate registration with the nFA and switch to using the nFA for connectivity. The third way, called the combined method, ensures connectivity by using both options: should the pre-registration method fail to complete in time for the MN to interface completely with the nFA, then the post-registration method kicks in and directs the oFA to start routing traffic to the nFA as needed, using the aforementioned bi-directional tunnel.

Drawn from the IETF draft, the example of the pre-registration hand-off method in Figure 3 shows the MN moving from left to right, and going through the following steps:
1a. Router solicitation
1b. Agent advertisement
2a. Proxy router solicitation
2b. Proxy router advertisement
3. Registration request from MN to nFA
(routed through oFA)
4. Registration request
5. Registration reply

The use of a local GFA reduces the time required to complete the hand-off if the HA is a long delay distance (not necessarily geographical distance) from the nFA.

The post-registration method illustrated in Figure 4 requires no attachment from the MN because it uses BETs to perform a low-latency change in the L2 point of attachment. After the successful registration of the MN with the oFA, it becomes the aFA. When the MN moves on, instead of registering with the nFA, it can put off the registration and continue to use the aFA. If the MN moves to a third network before ever having the chance to register with the nFA, then the third FA signals the aFA to move the BET endpoint from the nFA to it.

It is often said that the devil is in the details, and in this case it couldn't be truer. The IETF draft document goes into great detail about a variety of circumstances, including: whether the hand-off is initiated by the network, the MN, or the FA; obtaining nFA advertisements; inter-FA solicitations; tunneled nFA advertisements; movement detection; address considerations; two- and three-party hand-offs; tunneling services; and more. The document is worth examining simply to understand the many considerations that go into creating a mechanism for seamless service as a mobile device moves from network to network.

Security Considerations
As an MN moves from one network to another, both the node and the temporary host networks need to remain secure. Whether operating in a secure network such as a corporate VPN or hopping from one foreign network to another, security issues can include breaches such as man-in-the-middle, hijacking, passive wiretapping, impersonation, and denial-of-service attacks.

Mobile IP — A Core Perspective

Mobile IP will overcome one of the most significant obstacles to mobile data - the lack of consistent and persistent IP addresses. This advance, combined with ever-increasing bandwidth speeds, will open a range of new applications. The growth in mobile data traffic is in its early stages, but is already prompting carriers to change the way data traffic is transmitted over mobile networks. Today’s voice-centric mobile networks typically use ATM backbones to carry both the majority voice and minority data traffic. As data traffic volumes exceed voice traffic, mobile operators are beginning to migrate to a native IP backbone for their data traffic. This offers several key advantages over continuing with an IP-over-ATM architecture. First, migrating to a native IP backbone positions carriers to more rapidly deploy advanced data services and applications and achieve greater fixed-mobile feature transparency for services such as VPNs. Second, mobile carriers can achieve cost savings by leveraging synergies with fixed-network IP infrastructure and services. Finally, migration to IP eliminates the scaling issues associated with ATM and positions the mobile carrier to eventually migrate the voice transport over IP as well.

Separating the transport architectural decision from the service control network elements can minimize the complexity and risk of migration. Most 2.5 and 3G mobile architectures require the use of a specialized router serving as a GSN to receive data traffic from the RAN and deliver it to their existing IP backbone. By migrating the mobile data component from ATM to IP, carriers can take an important but relatively simple step closer to IP mobile and fixed-mobile integration.
When building or purchasing a TCP/IP stack that provides mobility (whether on the MN or network router) it's essential that the stack provides integrated security features or is easily able to integrate them. This secret is never sent over the network, but is used with keyed MD5 in prefix + suffix mode to create a 128-bit message digest of the complete registration message. This not only serves to verify the sender but also protects the message from alteration. Replay protection is accomplished with timestamps. One can also build in optional reverse tunneling when firewalls are used. These are just some of the techniques implemented to ensure a secure Mobile IP capability.

Mobile IPv6
Building any IP technology into a new design should never happen without consideration for IPv6, the emerging Internet protocol that solves the problem of address space shortage in IPv4. IPv4's 16-bit addressing has allowed for roughly four billion unique IP addresses. This might be enough for many more years if the United States hadn't been assigned more than two-thirds of these addresses. IPv6, which the DoD has mandated in all its Internet-connected devices by 2008 and which China is presently mandating in new Internet-connected devices, uses 128-bit addressing. With such address space, there will be enough unique IP-addresses for several million devices per square inch of Earth's surface.

MNs and HAs will operate much the same way in IPv6 as they do in IPv4. FAs are not necessary in IPv6. Some believe that security considerations will be made easier because IPv6 requires the implementation of the IPsec protocol, which was only optional in IPv4. The IETF RFC 3776 (June 2004) addresses security concerns for Mobile IPv6 in detail. This is worth reading, because it's important to have in mind a path to IPv6, even when developing a device or service operating with IPv4. While both protocols will operate in parallel for many years, interoperability with IPv6 no longer can be ignored.

IPv6 encapsulation is another key difference with IPv4. The IETF's RFC 2473 (December 1998) offers a comprehensive description of IPv6 tunneling and encapsulation. It demonstrates how IPv6 uses extension headers (called tunnel headers) to encapsulate packets at the entry point node and subsequently tunnels the resulting packets toward the exit-point node. This is performed differently than the tunneling alluded to earlier in the discussion of Mobile IPv4.

While Mobile IP presents significant challenges for the developer, there's reassurance in the fact that the concept and resulting technological implementations have been around and operational for several years. Vendors specializing in routers, mobile devices, and networking software have already developed a variety of TCP/IP stacks that offer Mobile IP capability. These vary in footprint, performance, application compatibility, real-time operating system portability, feature integration, and scalability. Looking into such software stacks requires not only knowledge of the environment in which the stack will operate but also some understanding of how Mobile IP works.

Although this discussion offers a start, it is suggested that the reader explore some of the IETF RFCs on Mobile IP. Whether building or buying a Mobile IP enabled networking stack, an in-depth understanding will lead to a more effective and future-proof result for your application.


About the Author
Urban Lindegren has worked in the embedded market since 1985 and holds a B.Sc in electronic engineering. He spent four years as a hardware and software engineer at Ericsson, and spent 11 years managing sales and product marketing for Enea Embedded Technology. Urban now serves as Vice President of Product Marketing for Interpeak and joined the company in 2002.