by William Stallings

In response to the increasing popularity of palm-top and other mobile computers, Mobile IP was developed to enable computers to maintain Internet connectivity while moving from one Internet attachment point to another. Although Mobile IP can work with wired connections, in which a computer is unplugged from one physical attachment point and plugged into another, it is particularly suited to wireless connections.

The term "mobile" in this context implies that a user is connected to one or more applications across the Internet, that the user's point of attachment changes dynamically, and that all connections are automatically maintained despite the change. This scenario is in contrast to a user, such as a business traveler, with a portable computer of some sort who arrives at a destination and uses the computer notebook to dial into an Internet Service Provider (ISP).

In this latter case, the user's Internet connection is terminated each time the user moves, and a new connection is initiated when the user dials back in. Each time an Internet connection is established, software in the point of attachment (typically an ISP) is used to obtain a new, temporarily assigned IP address. For each application-level connection (for example, File Transfer Protocol [FTP], Web connection), this temporary IP address is used by the user's correspondent. A better term for this kind of use is "nomadic."

We begin with a general overview of Mobile IP and then look at some of the details.

Operation of Mobile IP
Routers make use of the IP address in an IP datagram to perform routing. In particular, the network portion of an IP address is used by routers to move a datagram from the source computer to the network to which the target computer is attached. Then the final router on the path, which is attached to the same network as the target computer, uses the host portion of the IP address to deliver the IP datagram to the destination. Further, this IP address is known to the next higher layer in the protocol architecture. In particular, most applications over the Internet are supported by Transmission Control Protocol (TCP) connections. When a TCP connection is set up, the TCP entity on each side of the connection knows the IP address of the correspondent host. When a TCP segment is handed down to the IP layer for delivery, TCP provides the IP address. IP creates an IP datagram with that IP address in the IP header and sends the datagram out for routing and delivery. However, with a mobile host, the IP address may change while one or more TCP connections are active.

Figure 1 shows in general terms how Mobile IP deals with the problem of dynamic IP addresses. A mobile node is assigned to a particular network, known as its home network. Its IP address on that network, known as its home address, is static. When the mobile node moves its attachment point to another network, that is considered a foreign network for this host. When the mobile node is reattached, it makes its presence known by registering with a network node, typically a router, on the foreign network known as a foreign agent. The mobile node then communicates with a similar agent on the user's home network, known as a home agent, giving the home agent the care-of address of the mobile node; the care-of address identifies the foreign agent's location. Typically, one or more routers on a network will implement the roles of both home and foreign agents.

Figure 1: Mobile IP Scenario



When IP datagrams are exchanged over a connection between the mobile node (A) and another host (server X in Figure 1), the following operations occur:

1.	Server X transmits an IP datagram destined for mobile node A, with A's home address in the IP header. The IP datagram is routed to A's home network.
2.	At the home network, the incoming IP datagram is intercepted by the home agent. The home agent encapsulates the entire datagram inside a new IP datagram, which has the A's care-of address in the header, and retransmits the datagram. The use of an outer IP datagram with a different destination IP address is known as tunneling.
3.	The foreign agent strips off the outer IP header, encapsulates the original IP datagram in a network-level Protocol Data Unit (PDU) (for example, a LAN Logical Link Control [LLC] frame), and delivers the original datagram to A across the foreign network.
4.	When A sends IP traffic to X, it uses X's IP address. In our example, this is a fixed address; that is, X is not a mobile node. Each IP datagram is sent by A to a router on the foreign network for routing to X. Typically, this router is also the foreign agent.
5.	The IP datagram from A to X travels directly across the Internet to X, using X's IP address.

To support the operations illustrated in Figure 1, Mobile IP includes three basic capabilities:

	Discovery: A mobile node uses a discovery procedure to identify prospective home agents and foreign agents.
	Registration: A mobile node uses an authenticated registration procedure to inform its home agent of its care-of address.
	Tunneling: Tunneling is used to forward IP datagrams from a home address to a care-of address.

Figure 2 indicates the underlying protocol support for the Mobile IP capability. The registration protocol communicates between an application on the mobile node and an application in the home agent, and hence uses a transport-level protocol. Because registration is a simple request/response transaction, the overhead of the connection-oriented TCP is not required, and, therefore, the User Datagram Protocol (UDP) is used as the transport protocol. Discovery makes use of the existing Internet Control Message Protocol (ICMP) by adding the appropriate extensions to the ICMP header. ICMP is a connectionless protocol well suited for the discovery operation. Finally, tunneling is performed at the IP level.

Figure 2: Protocol Support for Mobile IP



Discovery
The discovery process in Mobile IP is very similar to the router advertisement process defined in ICMP. Accordingly, agent discovery makes use of ICMP router advertisement messages, with one or more extensions specific to Mobile IP.

The mobile node is responsible for an ongoing discovery process. It must determine if it is attached to its home network, in which case IP datagrams may be received without forwarding, or if it is attached to a foreign network.

Because handoff from one network to another occurs at the physical layer, a transition from the home network to a foreign network can occur at any time without notification to the network layer (that is, the IP layer). Thus, discovery for a mobile node is a continuous process.

For the purpose of discovery, a router or other network node that can act as an agent periodically issues a router advertisement ICMP message with an advertisement extension. The router advertisement portion of the message includes the IP address of the router. The advertisement extension includes additional information about the role of the router as an agent, as discussed subsequently. A mobile node listens for these agent advertisement messages. Because a foreign agent could be on the home network of the mobile node (set up to serve visiting mobile nodes), the arrival of an agent advertisement does not necessarily tell the mobile node that it is on a foreign network. The mobile node must compare the network portion of the router IP address with the network portion of its own home address. If these network portions do not match, then the mobile node is on a foreign network.

The agent advertisement extension follows the ICMP router advertisement fields and consists of the following fields:

	Type: 16, indicates that this is an agent advertisement.
	Length: (6 + 4N ), where N is the number of care-of addresses advertised.
	Sequence number: The count of agent advertisement messages sent since the agent was initialized.
	Lifetime: The longest lifetime, in seconds, that this agent is willing to accept a registration request from a mobile node.
	R: Registration with this foreign agent is required (or another foreign agent on this network). Even those mobile nodes that have already acquired a care-of address from this foreign agent must reregister.
	B: Busy. The foreign agent will not accept registrations from additional mobile nodes.
	H: This agent offers services as a home agent on this network.
	F: This agent offers services as a foreign agent on this network.
	M : This agent can receive tunneled IP datagrams that use minimal encapsulation, explained subsequently.
	G: This agent can receive tunneled IP datagrams that use Generic Routing Encapsulation (GRE), explained subsequently.
	Y: This agent supports the use of Van Jacobson header compression, an algorithm defined in RFC 1144 for compressing fields in the TCP and IP headers.
	Care-of address: The care-of address or addresses supported by this agent on this network. There must be at least one such address if the F bit is set. There may be multiple addresses.

There may also be an optional prefix-length extension following the advertisement extension. This extension indicates the number of bits in the router address that define the network number. The mobile node uses this information to compare the network portion of its own IP address with the network portion of the router. The fields include the following:

	Type: 19, indicates that this is a prefix-length advertisement.
	Length: N, where N is the value of the Num Addrs field in the ICMP router advertisement portion of this ICMP message. In other words, this is the number of router addresses listed in this ICMP message.
	Prefix length: The number of leading bits that define the network number of the corresponding router address listed in the ICMP router advertisement portion of this message. The number of prefix length fields matches the number of router address fields (N).

Foreign agents are expected to periodically issue agent advertisement messages. If a mobile node needs agent information immediately, it can issue an ICMP router solicitation message. Any agent receiving this message will then issue an agent advertisement.

As was mentioned, a mobile node may move from one network to another because of some handoff mechanism, without the IP level being aware of it. The agent discovery process is intended to enable the agent to detect such a move. The agent may use one of two algorithms for this purpose:

Use of Lifetime field: When a mobile node receives an agent advertisement from a foreign agent that it is currently using or that it is now going to register with, it records the Lifetime field as a timer. If the timer expires before the agent receives another agent advertisement from the agent, then the node assumes that it has lost contact with that agent. If, in the meantime, the mobile node has received an agent advertisement from another agent and that advertisement has not yet expired, the mobile node can register with this new agent. Otherwise, the mobile node should use agent solicitation to find an agent.

Use of network prefix: The mobile node checks whether any newly received agent advertisement is on the same network as the current care-of address of the node. If it is not, the mobile node assumes that it has moved and may register with the agent whose advertisement the mobile node has just received.

The discussion so far has involved the use of a care-of address associated with a foreign agent; that is, the care-of address is an IP address for the foreign agent. This foreign agent will receive datagrams at this care-of address, intended for the mobile node, and then forward them across the foreign network to the mobile node. However, in some cases a mobile node may move to a network that has no foreign agents or on which all foreign agents are busy.

As an alternative, the mobile node may act as its own foreign agent by using a colocated care-of address . A colocated care-of address is an IP address obtained by the mobile node that is associated with the current interface to a network of that mobile node.

The means by which a mobile node acquires a colocated address is beyond the scope of Mobile IP. One means is to dynamically acquire a temporary IP address through an Internet service such as Dynamic Host Configuration Protocol (DHCP). Another alternative is that the colocated address may be owned by the mobile node as a longterm address for use only while visiting a given foreign network.

Registration
When a mobile node recognizes that it is on a foreign network and has acquired a care-of address, it needs to alert a home agent on its home network and request that the home agent forward its IP traffic. The registration process involves four steps:

1.	The mobile node requests the forwarding service by sending a registration request to the foreign agent that the mobile node wants to use.
2.	The foreign agent relays this request to the home agent of that mobile node.
3.	The home agent either accepts or denies the request and sends a registration reply to the foreign agent.
4.	The foreign agent relays this reply to the mobile node.

If the mobile node is using a colocated care-of address, then it registers directly with its home agent, rather than going through a foreign agent.

The registration operation uses two types of messages, carried in UDP segments. The registration request message consists of the following fields:

	Type: 1, indicates that this is a registration request.
	S : Simultaneous bindings. The mobile node is requesting that the home agent retain its prior mobility bindings. When simultaneous bindings are in effect, the home agent will forward multiple copies of the IP datagram, one to each care-of address currently registered for this mobile node. Multiple simultaneous bindings can be useful in wireless handoff situations to improve reliability.
	B: Broadcast datagrams. Indicates that the mobile node would like to receive copies of broadcast datagrams that it would have received if it were attached to its home network.
	D: Decapsulation by mobile node. The mobile node is using a colocated care-of address and will decapsulate its own tunneled IP datagrams.
	M: Indicates that the home agent should use minimal encapsulation, explained subsequently.
	V: Indicates that the home agent should use Van Jacobson header compression, an algorithm defined in RFC 1144 for compressing fields in the TCP and IP headers.
	G: Indicates that the home agent should use GRE encapsulation, explained subsequently.
	Lifetime : The number of seconds before the registration is considered expired. A value of zero is a request for deregistration.
	Home address: The home IP address of the mobile node. The home agent can expect to receive IP datagrams with this as a destination address, and must forward those to the care-of address.
	Home agent: The IP address of the mobile node home agent. This informs the foreign agent of the address to which this request should be relayed.
	Care-of address: The IP address at this end of the tunnel. The home agent should forward IP datagrams that it receives with the mobile node home address to this destination address.
	Identification: A 64-bit number generated by the mobile node, used for matching registration requests to registration replies and for security purposes, as explained subsequently.
	Extensions: The only extension so far defined is the authentication extension, explained subsequently.

The registration reply message consists of the following fields:

	Type: 3, indicates that this is a registration reply.
	Code: Indicates result of the registration request.
	Lifetime: If the code field indicates that the registration was accepted, the number of seconds before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered.
	Home address: The home IP address of the mobile node.
	Home agent : The IP address of the mobile node home agent.
	Identification: A 64-bit number used for matching registration requests to registration replies.

The only extension so far defined is the authentication extension, explained subsequently.

A key concern with the registration procedure is security. Mobile IP is designed to resist two types of attacks:

1.	A node may pretend to be a foreign agent and send a registration request to a home agent so as to divert traffic intended for a mobile node to itself.
2.	A malicious agent may replay old registration messages, effectively cutting the mobile node from the network.

The technique that is used to protect against such attacks involves the use of message authentication and the proper use of the identification field of the registration request and reply messages.

For purposes of message authentication, each registration request and reply contains an authentication extension with the following fields:

	Type: Used to designate the type of this authentication extension.
	Length: 4 plus the number of bytes in the authenticator.
	Security parameter index (SPI): An index that identifies a security context between a pair of nodes. This security context is configured so that the two nodes share a secret key and parameters relevant to this association (for example, authentication algorithm).
	Authenticator: A code used to authenticate the message. The sender inserts this code into the message using a shared secret key. The receiver uses the code to ensure that the message has not been altered or delayed. The authenticator protects the entire registration request or reply message, any extensions prior to this extension, and the type and length fields of this extension.

The default authentication algorithm uses keyed MD5 to produce a 128-bit message digest. For Mobile IP, a "prefix+suffix" mode of operation is used. The MD5 digest is computed over the shared secret key, followed by the protected fields from the registration message, followed by the shared secret key again. Three types of authentication extensions are defined:

	Mobile-home: This extension must be present and provides for authentication of the registration messages between the mobile node and the home agent.
	Mobile-foreign: The extension may be present when a security association exists between the mobile node and the foreign agent. The agent will strip this extension off before relaying a request message to the home agent and add this extension to a reply message coming from a home agent.
	Foreign-home: The extension may be present when a security association exists between the foreign agent and the home agent.

Note that the authenticator protects the identification field in the request and reply messages. As a result, the identification value can be used to thwart replay types of attacks. As was mentioned, the identification value enables the mobile node to match a reply to a request. Further, if the mobile node and the home agent maintain synchronization so that the home agent can distinguish a reasonable identification value from a suspicious one, then the home agent can reject suspicious messages. One way to do this is to use a timestamp value. As long as the mobile node and home agent have reasonably synchronized values of time, the timestamp will serve the purpose. Alternatively, the mobile node could generate values using a pseudorandom number generator. If the home agent knows the algorithm, then it knows what identification value to expect next.

Tunneling
When a mobile node is registered with a home agent, the home agent must be able to intercept IP datagrams sent to the mobile node home address so that these datagrams can be forwarded via tunneling. The standard does not mandate a specific technique for this purpose but references Address Resolution Protocol (ARP) as a possible mechanism. The home agent needs to inform other nodes on the same network (the home network) that IP datagrams with a destination address of the mobile node in question should be delivered (at the link level) to this agent. In effect, the home agent steals the identity of the mobile node in order to capture packets destined for that node that are transmitted across the home network.

Figure 3: A Simple Internetworking Example



For example, suppose that R3 in Figure 3 is acting as the home agent for a mobile node that is attached to a foreign network elsewhere on the Internet. That is, there is a host H whose home network is LAN Z that is now attached to some foreign network. If host D has traffic for H, it will generate an IP datagram with H's home address in the IP destination address field. The IP module in D recognizes that this destination address is on LAN Z and so passes the datagram down to the link layer with instructions to deliver it to a particular Media Access Control (MAC)-level address on Z. Prior to this time, R3 has informed the IP layer at D that datagrams destined for that particular address should be sent to R3. Thus, the MAC address of R3 is inserted by D in the destination MAC address field of the outgoing MAC frame. Similarly, if an IP datagram with the mobile node home address arrives at router R2, it recognizes that the destination address is on LAN Z and will attempt to deliver the datagram to a MAC-level address on Z. Again, R2 has previously been informed that the MAC-level address it needs corresponds to R3.

For traffic that is routed across the Internet and arrives at R3 from the Internet, R3 must simply recognize that for this destination address, the datagram is to be captured and forwarded.

To forward an IP datagram to a care-of address, the home agent puts the entire IP datagram into an outer IP datagram. This is a form of encapsulation, just as placing an IP header in front of a TCP segment encapsulates the TCP segment in an IP datagram. Three options for encapsulation are allowed for Mobile IP and we will review the first two of the following options:

	IP-within-IP encapsulation: This is the simplest approach, defined in RFC 2003.
	Minimal encapsulation: This approach involves fewer fields, defined in RFC 2004.
	Generic routing encapsulation (GRE): This is a generic encapsulation procedure, defined in RFC 1701, that was developed prior to the development of Mobile IP.

In the IP-within-IP encapsulation approach, the entire IP datagram becomes the payload in a new IP datagram (Figure 4a). The inner, original IP header is unchanged except to decrement Time To Live (TTL) by 1. The outer header is a full IP header. Two fields (indicated as unshaded in the figure) are copied from the inner header. The version number is 4, the protocol identifier for IPv4, and the type of service requested for the outer IP datagram is the same as that requested for the inner IP datagram.

Figure 4a: Mobile IP Encapsulation



Figure 4b: Mobile IP Encapsulation



In the inner IP header, the source address refers to the host that is sending the original datagram, and the destination address is the home address of the intended recipient. In the outer IP header, the source and destination addresses refer to the entry and exit points of the tunnel. Thus, the source address typically is the IP address of the home agent, and the destination address is the care-of address for the intended destination.

Example: Consider an IP datagram that originates at server X in Figure 1 and that is intended for mobile node A. The original IP datagram has a source address equal to the IP address of X and a destination address equal to the IP home address of A. The network portion of A's home address refers to A's home network, so the datagram is routed through the Internet to A's home network, where it is intercepted by the home agent. The home agent encapsulates the incoming datagram with an outer IP header, which includes a source address equal to the IP address of the home agent and a destination address equal to the IP address of the foreign agent on the foreign network to which A is currently attached. When this new datagram reaches the foreign agent, it strips off the outer IP header and delivers the original datagram to A.

Minimal encapsulation results in less overhead and can be used if the mobile node, home agent, and foreign agent all agree to do so. With minimal encapsulation, the new header is inserted between the original IP header and the original IP payload (Figure 4b). It includes the following fields:

	Protocol: Copied from the Destination Address field in the original IP header. This field identifies the protocol type of the original IP payload and thus identifies the type of header that begins the original IP payload.
	S: If 0, the original source address is not present, and the length of this header is 8 octets. If 1, the original source address is present, and the length of this header is 12 octets.
	Header checksum: Computed over all the fields of this header.
	Original destination address: Copied from the Destination Address field in the original IP header.
	Original source address: Copied from the Source Address field in the original IP header. This field is present only if the S bit is 1. The field is not present if the encapsulator is the source of the datagram (that is, the datagram originates at the home agent).

The following fields in the original IP header are modified to form the new outer IP header:

	Total length: Incremented by the size of the minimal forwarding header (8 or 12).
	Protocol : 55; this is the protocol number assigned to minimal IP encapsulation.
	Header checksum: Computed over all the fields of this header; because some of the fields have been modified, this value must be recomputed.
	Source address: The IP address of the encapsulator, typically the home agent.
	Destination address: The IP address of the exit point of the tunnel. This is the care-of address and may be either the IP address of the foreign agent or the IP address of the mobile node (in the case of a colocated care-of address).

The processing for minimal encapsulation is as follows. The encapsulator (home agent) prepares the encapsulated datagram with the format of Figure 4b. This datagram is now suitable for tunneling and is delivered across the Internet to the care-of address. At the care-of address, the fields in the minimal forwarding header are restored to the original IP header and the forwarding header is removed from the datagram. The total length field in the IP header is decremented by the size of the minimal forwarding header (8 or 12) and the header checksum field is recomputed.

References
Reference [1] is a good survey article on mobile IP; a somewhat less technical, more business-oriented description from the same author is [2]. For greater detail, see [3]. The August 2000 issue of IEEE Personal Communications contains numerous articles on enhancements to the current Mobile IP standard. The Web site of the IETF Working Group on Mobile IP, which contains current RFCs and Internet Drafts is at:

[1] Perkins, C., "Mobile IP," IEEE Communications Magazine, May 1997.

[2] Perkins, C., "Mobile Networking through Mobile IP," IEEE Internet Computing, January-February 1998.

[3] Perkins, C., Mobile IP: Design Principles and Practices, ISBN 0-201- 63469-4, Prentice Hall PTR, 1998.

[4] Solomon, J., Mobile IP: The Internet Unplugged, ISBN 0138562466, Prentice Hall PTR, 1998.

WILLIAM STALLINGS is a consultant, lecturer, and author of over a dozen books on data communications and computer networking. He also maintains a computer science resource site for CS students and professionals at http://www.WilliamStallings.com/StudentSupport.html. He has a PhD in computer science from M.I.T. His latest book is Wireless Communications and Networks (Prentice Hall, 2001). His home in cyber-space is http://www.WilliamStallings.com and he can be reached at ws@shore.net