Inside Mobile IP

Narendra Venkataraman is a senior developer at Hewlett-Packard Telecom division and can be reached at narendra.venkataraman@hp.com.

Mobile IP is a standard that lets mobile-device users whose IP addresses are associated with one network, stay connected when moving to a network with a different IP address. When users leave the network with which their device is associated (that is, the "home network") and enter the domain of a foreign network, the foreign network uses the Mobile IP protocol to inform the home network of a "care-of" address to which all packets for the user's device should be sent.

Mobile IP is most often found in wireless WAN environments where users need to carry their mobile devices across multiple LANs with different IP addresses. A common analogy to explain Mobile IP is when someone moves his residence from one location to another; say, from Boston to New York. The person drops off the new mailing address at the New York post office, which notifies the Boston post office of the new mailing address. When the Boston post office receives mail for a person, it knows to forward the mail to that person's New York address.

Some of the key drivers for embracing Mobile IP are: large-scale deployments of wireless networks, be it public WLAN hotspots or All-IP 3G networks such as UMTS; less expensive wireless Internet access; and powerful laptops and PDAs with built-in WLAN and GPRS/UMTS radio interfaces.

Telecommunications companies that have both WLAN and WWAN infrastructure (GPRS/UMTS/CDMA1x) are providing seamless roaming as a value-added service to subscribers. Among the various roaming solutions in the market, Mobile IP (being an IETF Standard) scores very high.

Mobile IP comes with two versionsMobile IPv4 and Mobile IPv6. Though conceptually similar to IPv4, IPv6 supports more enhanced security and optimized routing features. Because of the slow transition toward IPv6 infrastructure, Mobile IP solutions for existing IPv4 networks are already being deployed. In this article, I focus mainly on Mobile IPv4, highlighting the key concepts and issues faced during integration with wireless LAN and GPRS/UMTS networks. In this article, I will explain the core concepts of roaming and highlight the insights gained during the integration of Mobile IP with WLAN and GPRS/UMTS networks. Though the article is focused on wireless networks, Mobile IP is applicable to wireline networks as well.

Layer 2 Mobility

For instance, Figure 1 shows two access pointsAP1 and AP2within the same subnet 15.76.222. The WLAN client is initially associated with AP1 and assigned the IP address 15.76.222.11. The user issues a huge HTTP download and walks out of the coverage area of AP1 and is now associated to the new access point AP2. Because both the access points are serving the same subnet, the client's IP address is retained. The download continues without any hiccups. In this case, the roaming occurs at Layer 2. Layer 2 roaming is very fast and reliable across similar network media within the same subnet or network topology. Even the latest GPRS/UMTS combo adapters handle roaming at the link layer, provided GPRS and UMTS networks interface with the same IP backbone.

Layer 3 Mobility

Take a case where AP1 is in subnet 15.76.222/24 and AP2 is in subnet 16.138.52/24. As illustrated in Figure 2, the client is assigned 15.76.222.11 when connected to AP1. Later, when it associates with AP2, it cannot retain the same address; hence, it gets a new address 16.138.52.112 from the 16.138.52 subnet's DHCP server. The HTTP download is a TCP session identified by a tuple (source ip:port and destination ip:port). In this case, the TCP session breaks because the source address changed from 15.76.222.11 to 16.138.52.112. The question is how to retain the address 15.76.222.11 even while you move to the new subnet 16.138.52 so that the existing application sessions are not disrupted. Mobile IP solves this problem by introducing a host entity called "mobile node" and two new network entities called "Home Agent" (HA) and "Foreign Agent" (FA).

The mobile node is any host running the Mobile IP client. The mobile node is always assigned one permanent IP address; in this case, 15.76.222.11. In Mobile IP terminology, the permanent address is known as the "home address" and the subnet 15.76.222 is the "home network." The mobile node implements a virtual network adapter that is assigned to the home address. All application layer packets are routed via this adapter. These packets are then sent over the physical WLAN interface, which is assigned 16.138.52.112. The WLAN adapter's address changes depending on the network it is connected to and this temporary address is called the "care-of" address.

Say that the mobile node was downloading a file from a web server hosted on 161.114.22.105. The second piece of puzzle is to determine how the mobile node receives IP packets at its new location. Applying the standard routing principles, packets destined for 15.76.222.11 are forwarded to the subnet default gateway 15.76.222.1 and eventually dropped. Figure 3 explains the basic concept of Mobile IP:

In a mobile IP scenario, the default gateway acts as the HA. The mobile node notifies its new care-of address by sending a Mobile IP registration packet. The registration packet is sent over UDP at port 434 of the HA.

The HA sends back the reply after updating its registration table. The registration table consists of home address and care-of address mapping. It also has other parameters such as registration lifetime. (It is not shown for simplicity.)

The packets sent by the host running the web server known as the "correspondent node" (CN) are intercepted by the HA. These packets are then sent to the care-of address 16.138.52.112.

The HA encapsulates the original IP packet sent by the CN in another IP packet with the destination address as the care-of address 16.138.52.112 and the source address as the HA address 15.76.222.1. The process is known as IP-in-IP "tunneling" (see RFC 2003; http://www.faqs.org/rfcs/rfc2003.html).

The mobile node's WLAN adapter receives the tunneled packets, extracts the original packets, and passes them to the virtual adapter. Because the host application interfaces only with the virtual adapter, it is transparent to changes in the care-of address.

When the mobile node goes back to the 15.76.222 network, it deregisters by sending a registration packet with a lifetime equal to 0. If it moves to another subnet, it registers its new care-of address and deregisters the previous one.

The mobile node (after extracting the original packet) knows the CN's IP address. The mobile node can send the packets directly to the CN without tunneling as shown in Figure 4. This is known as "triangular routing" and optimizes the return path.

However, currently deployed routers and firewalls enable "ingress filtering," in which the outgoing packets are blocked if the source address is not part of the network. In this case, 15.76.222.11 is not part of subnet 16.138.52; hence, it is blocked. Mobile IP solves the ingress filtering issue by introducing reverse tunneling (see RFC 3024; http://www.faqs.org/rfcs/rfc3024.html). The mobile node uses IP-in-IP tunneling with the care-of address 16.138.52.112 in the source and the HA address 15.76.222.1 in the destination; see (3) of Figure 4. The HA extracts the original packet and forwards it to the CN. This is shown in (4) of Figure 4.

Optional Foreign Agent

If a large number of mobile nodes move to subnet 16.138.52, the DHCP runs out of IP addresses. Mobile IP resolves this address scarcity problem by introducing another network entity called "Foreign Agent" (FA). Figure 5 shows how the packets flow in the presence of an FA.

The NAT Problem

In the presence of an FA, each mobile node is not assigned a care-of address. Instead, the FA's address is used as the care-of address in the registration table and the mobile node registers with the HA via an FA. The packets sent from the CN are tunneled via the HA and sent to the FA. The FA decapsulates them and sends the original packets directly to the mobile node's WLAN adapter MAC address. The FA maintains a routing table with the mobile node's home address and the WLAN adapter's MAC address as in Figure 5. The mobile node detects an FA by listening to agent advertisements broadcast by the FA. These agent advertisements are an extension of ICMP router advertisement messages (see RFC 1256; http://www.faqs.org/rfcs/rfc1256.html).

In short, there are two types of care-of addresses: an FA care-of address, when an FA is present in the visited network; and a colocated care-of address, when the mobile node obtains the care-of address from DHCP or PPP or some other means.

IP-in-IP tunneling assumes that the endpoints are the HA and MN in colocated mode or the HA and FA in the presence of an FA. If the mobile node is behind a Network Address Port Translation (NAPT) enabled wireless router, IP-in-IP tunneling breaks because the care-of address (192.168.1.110) is not reachable from outside the local subnet. IP-in-UDP tunneling (see RFC 3519; http://www.faqs.org/rfcs/rfc3519.html) solves this problem by tunneling the IP packets in a UDP packet. The UDP packet contains a Mobile IP tunnel message header and the original IP packet. Figure 6 shows how IP-in-UDP tunneling traverses through a mobile node behind NAPT.

The mobile node requests for IP-in-UDP tunneling when it sends the registration packet. The registration packet contains the tuple {192.168.1.110:2001, 15.76.222.1:434}.

The router uses port address translation to map many internal addresses and TCP/UDP ports in the subnet 192.168.1 to a single external address 15.76.222.100. For the registration UDP packet, the router is mapped from 192.168.1.110:2001 to 15.76.222.100:1656.

The HA receives the registration request with source IP 15.76.222.100 and a UDP port 1656. The HA maintains the registration table mapping home address 15.76.222.11 to the care-of address and UDP port 15.76.222.100:1656.

When a packet addressed to the mobile node reaches the HA, it encapsulates the packet in another UDP packet and sends it to the port 1656 that was used for registration.

Once the packet reaches the NAPT-enabled wireless router, it is forwarded to 192.168.1.110:2001.

The mobile node decapsulates and extracts the original packet.

The IP-in-UDP tunneling is not bandwidth efficient because the packet overhead for the tunneling is 32 bytes compared to 20 bytes for IP-in-IP tunneling.

Combining Different Wireless Technologies

Figure 7 shows a high-level deployment architecture for public hotspots and UMTS networks. The public WLAN and UMTS networks are connected to the common IP backbone, enabling users to seamlessly roam across these networks.

Deploying a Mobile IP infrastructure requires installation of HAs and FAs. The routers can be upgraded to serve as an HA or FA. If the existing routers cannot be upgraded, you can run FA and HA software on standard Linux or UNIX servers. On the host side, you can install any third-party Mobile IP client available on the market. Currently, Windows XP has no built-in support for Mobile IP.

While switching from WLAN to UMTS, the latency is in the order of 2-5 seconds. This is not acceptable for real-time streaming applications. It is better to be always connected to the ubiquitous GPRS/UMTS network and switch to a cheaper and faster WLAN whenever available. This is a good strategy because most service providers use packet-based billing; hence, you are not charged extra for an always-on UMTS connection. The mobile node should implement low-latency handoff logic to ensure smooth switch over. The handoff logic chooses the right network interface at the right time in the right location. Handoff across similar network technology (for instance, WLAN to WLAN) is simply based on signal strength. Whereas handoff across WLAN and UMTS is a complex function with many parameters such as speed of interface, signal strength, power consumption, bandwidth, cost of network usage, location of user, user preferences, time of the day, and so on. The best approach is to study and anticipate user behavior and utilize it for switching to a new network before losing the existing connection.

Instead of using a static home address, configure Network Access Identifier (NAI) (see RFC 2794; http://www.faqs.org/rfcs/rfc2794.html). NAI is a text identifier that is primarily used as a user ID during registration. If the mobile node is configured with an NAI, then it does not need a static home address. The mobile node sends a registration request with an NAI. The HA sends a registration reply including the mobile node's home address. You can set, for instance, an e-mail ID, such as "Narendra.venkataraman@hp.com" as an NAI.

In a public hotspot, users associate with an AP and are assigned an IP address. They need to authenticate using some application layer authentication in order to obtain access to the Internet. The most common authentication mechanism is web login, where the user is presented with a login page and the user's credentials are sent over a secure socket layer (SSL). It is important to note that before the authentication phase, all the packets are blocked including Mobile IP registration packets. Therefore, ensure that Mobile IP registration packets are sent after the hotspot login. Upon successful authentication, if there is no network activity for a predefined interval, most of the hotspots log you out. Therefore, make sure that you send ping or keep-alive packets at regular intervals.

Home agents installed within an intranet offer roaming across LAN and WLAN networks. Unlike public WLANs, enterprise WLANs use link-layer authentication called "802.1x authentication." Because authentication is already done before obtaining an IP address, Mobile IP registration happens smoothly. Apart from roaming between various LAN and WLAN subnets within an intranet, we can also roam across the intranet and Internet while retaining the corporate network connection. Some enterprises partner with GPRS service providers to provide access to intranet resources. This is optimal because there is no extra overhead from a VPN tunnel. But this is not always feasible, and therefore, the most generic and popular way to connect to the enterprise is using IPSec-based VPNs. The VPN provides secure access based on user credentials, whereas Mobile IP provides terminal mobility. The commercially available IPSec-based VPN gateways are not interoperable and standardizing the integration of HA functionality into a VPN gateway is not an easy task. Various approaches are being evaluated and are available in draft form (see http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-statement-03.txt).

Conclusion

Mobile IP is an important step toward ubiquitous networking. However, it does not address all the issues of mobility. For instance, if a bandwidth-hogging application running on a high-speed WLAN network switches to a low-bandwidth GPRS network, TCP connections cannot survive the high latency of the GPRS network. This can be solved if the application is designed to cater to the differences in quality-of-service of various wireless media. True mobility can only be achieved if all layers in the TCP/IP stack collaborate.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!