Mobile IP is a proposed standard protocol that builds on the Internet Protocol by making mobility transparent to applications and higher level protocols like TCP. Mobile IP (RFC 2002) is a standard proposed by a working group within the Internet Engineering Task Force; it allows the mobile node to use two IP addresses: a fixed home address and a care-of address that changes at each new point of attachment. The study describes how Mobile IP will change with IP version 6, the product of a major effort within the IETF to engineer an eventual replacement for the current version of IP. Although IPv6 will support mobility to a greater degree than IPv4, it will still need Mobile IP to make mobility transparent to applications and higher level protocols such as TCP. There is a great deal of interest in mobile computing and apparently in Mobile IP as a way to provide for it. Mobile IP forms the basis either directly or indirectly of many current research efforts and products. The Cellular Digital Packet Data (CDPD), for example, has created a widely deployed communications infrastructure based on a previous draft specification of the protocol. In addition, most major router vendors have developed implementations for Mobile IP.
IP version 4 assumes that a nodeâ„¢s IP address uniquely identifies its physical attachment to the Internet. Therefore, when a corespondent host (CH) tries to send a packet to a mobile node (MN), that packet is routed to the MNâ„¢s home network, independently of the current attachment of that MN (this is because CHs do not have any knowledge of mobility).
When the MN is on its home network, and a CH sends packets to the mobile node, the Mobile Node obtains those packets and answers them as a normal host (this is one important requirement in Mobile IP), but if the MN is away from its home network, it needs an agent to work on behalf of it. That agent is called Home Agent (HA). This agent must be able to communicate with the MN all the time that it is on-line, independently of the current position of the MN. So, HA must know where the physical location of the MN is.
In order to do that, when the MN is away from home, it must get a temporary address (which is called care-of address), which will be communicated to the HA to tell its current point of attachment. This care-of address can be obtained by several ways, but the most typical one is that the MN gets that address from an agent. In this case, this agent is called Foreign Agent (FA).
Therefore, when a MN is away from home, and itâ„¢s connected to a foreign network, it detects is on a different network and sends a registration request through the FA to the HA requesting mobile capabilities for a period of time. The HA sends a registration reply back to the MN (through the FA) allowing or denying that registration. This is true when the Mobile Node is using a Foreign Agent for the registration. If the Mobile Node obtains the care-of address by other meanings, that step (registration through the FA) is not necessary.
If the HA allows that registration, it will work as a proxy of the MN. When MNâ„¢s home network receives packets addressed to the MN, HA intercepts those packets (using Proxy ARP), encapsulates them, and sends them to the care-of address, which is one of the addresses of the FA. The FA will decapsulate those packets, and it will forward them to the MN (because it knows exactly, where the MN is).
Encapsulation is the method used by the HA to deliver information to the MN putting an extra IP header on top of the packet and tunnelling that packet to the MN (when itâ„¢s on a foreign network). Tunneling and encapsulation are defined in IP in IP tunneling and IP encapsulation within IP.
So, when the MN is on a foreign network, it uses its home agent to tunnel encapsulated packets to itself via FA. This occurs until the lifetime expires (or the MN moves away). When this happens (time out) MN must register again with its HA through the FA (if the MN obtains its care-of address for other meanings, it acts as its own FA).
When the MN moves to another network and it detects so, it sends a new registration request through (one more time) the new FA. In this case, HA will change MNâ„¢s care-of address and it will forward encapsulated packets to that new care-of address (which, usually, belongs to the FA). Some extensions of Mobile IP allows to a MN to have several care-of addresses. Then, HA will send the same information to all the care-of addresses. This is particularly useful when the MN is at the edges of cells on a wireless environment, and it is moving constantly.
MN bases its movement detection basically looking at periodic adverts of the FA (and HA), which sends to its localnet. Those messages are one extension of the ICMP router discovery messages and they are called Agent Advertisement (because they advertises a valid agent for Mobile Nodes).
There are two different methods to detect network movement:
a) The first method is based on network prefixes. For further information look at Mobile IP RFC 2002 (section 126.96.36.199, page 22). This method is not included in our current implementation.
b) The second method is based upon the Lifetime field within the main body of the ICMP Router Advertisement portion of the Agent Advertisement. Mobile nodes keep track of that Lifetime and if it expires, it sends an Agent Solicitation (asking for a new Agent Advertisement) and it presumes that it has been moved.
When the MN returns to its home network, it does not require mobility capabilities, so it sends a deregistration request to the HA, telling it that itâ„¢s at home (just to deactivate tunneling and to remove previous care-of address(es)).
At this point, MN does not have to (de)register again, until it moves away from its network. The detection of the movement is based on the same method explained before.
How Mobile IP works
In brief, Mobile IP works as follows. A mobile node can have two addresses - a permanent home address and a care of address (CoA), which is associated with the network the mobile node is visiting. There are two kinds of entities in Mobile IP:
A home agent stores information about mobile nodes whose permanent home address is in the home agentâ„¢s network.
A foreign agent stores information about mobile nodes visiting its network. Foreign agents also advertise care-of addresses, which are used by Mobile IP.
A node wanting to communicate with the mobile node uses the permanent home address of the mobile node as the destination address for sent packets. Because the home address logically belongs to the network associated with the home agent, normal IP routing mechanisms forward these packets to the home agent. Instead of forwarding these packets to a destination that is physically in the same network as the home agent, the home agent redirects these packets towards the foreign agent. The home agent looks for the care-of address (CoA) in a special table known as a binding table, and then tunnels the packets to the mobile nodeâ„¢s care-of address by appending a new IP header to the original IP packet, which preserves the original IP header. The packets are decapsulated at the end of the tunnel to remove the IP header added by the home agent, and are delivered to the mobile node.
When acting as receiver, mobile node simply sends packets directly to the other communicating node through the foreign agent, without sending the packets through the home agent, using its permanent home address as the source address for the IP packets. This is known as triangular routing. If needed, the foreign agent could employ reverse tunneling by tunneling the mobile nodeâ„¢s packets to the home agent, which in turn forwards them to the communicating node. This is needed in networks whose gateway routers have ingress filtering enabled and hence the source IP address of the mobile host would need to belong to the subnet of the foreign network else the packets will be discarded by the router.
The Mobile IP protocol defines the following:
an authenticated registration procedure by which a mobile node informs its home agent(s) of its care-of-address(es);
an extension to ICMP Router Discovery, which allows mobile nodes to discover prospective home agents and foreign agents; and
the rules for routing packets to and from mobile nodes, including the specification of one mandatory tunneling mechanism and several optional tunneling mechanisms.
Internet Protocol version 4 (IPv4) is the fourth revision in the development of the Internet Protocol (IP) and it is the first version of the protocol to be widely deployed. Together with IPv6, it is at the core of standards-based internetworking methods of the Internet, and is still by far the most widely deployed Internet Layer protocol.
It is described in IETF publication RFC 791 (September 1981) which rendered obsolete RFC 760 (January 1980). The United States Department of Defense also standardized it as MIL-STD-1777.
IPv4 is a data-oriented protocol to be used on a packet switched internetwork (e.g., Ethernet). It is a best effort delivery protocol in that it does not guarantee delivery, nor does it assure proper sequencing, or avoid duplicate delivery. These aspects are addressed by an upper layer protocol (e.g. TCP, and partly by UDP). IPv4 does, however, provide data integrity protection through the use of packet checksums
IPv4 uses 32-bit (four-byte) addresses, which limits the address space to 4,294,967,296 (232) possible unique addresses. However, some are reserved for special purposes such as private networks (~18 million addresses) or multicast addresses (~16 million addresses). This reduces the number of addresses that can be allocated as public Internet addresses. As the number of addresses available are consumed, an IPv4 address shortage appears to be inevitable, however network address translation (NAT) has significantly delayed this inevitability.
This limitation has helped stimulate the push towards IPv6, which is currently in the early stages of deployment and the only contender to replace IPv4.
IPv4 addresses are usually written in dot-decimal notation, which consists of the four octets of the address expressed in decimal and separated by periods
Main article: IP address exhaustion
Since the 1980s it has been apparent that the number of available IPv4 addresses is being exhausted at a rate that was not initially anticipated in the design of the network. This was the driving factor for the introduction of classful networks, for the creation of CIDR addressing, and finally for the redesign of the Internet Protocol, based on a larger address format (IPv6).
Today, there are several driving forces for the acceleration of IPv4 address exhaustion:
Mobile devices â€ laptop computers, PDAs, mobile phones
Always-on devices â€ ADSL modems, cable modems
Rapidly growing number of Internet users
The accepted and standardized solution is the migration to IPv6. The address size jumps dramatically from 32 bits to 128 bits, providing a vastly increased address space that allows improved route aggregation across the Internet and offers large subnet allocations of a minimum of 264 host addresses to end-users. Migration to IPv6 is in progress but is expected to take considerable time.
Methods to mitigate the IPv4 address exhaustion are:
Network address translation (NAT)
Use of private networks
Dynamic Host Configuration Protocol (DHCP)
Name-based virtual hosting
Tighter control by Regional Internet Registries on the allocation of addresses to Local Internet Registries
Network renumbering to reclaim large blocks of address space allocated in the early days of the Internet
Internet Protocol version 6 (IPv6) is the next-generation Internet Layer protocol for packet-switched internetworks and the Internet. IPv4 is currently the dominant Internet Protocol version, and was the first to receive widespread use. In December 1998, the Internet Engineering Task Force (IETF) designated IPv6 as the successor to version 4 by the publication of a Standards Track specification, RFC 2460
IPv6 has a much larger address space than IPv4. This results from the use of a 128-bit address, where IPv4 uses only 32 bits. The new address space thus supports 2128 (about 3.4Ãƒâ€”1038) addresses. This expansion provides flexibility in allocating addresses and routing traffic and eliminates the need for network address translation (NAT). NAT gained widespread deployment as an effort to alleviate IPv4 address exhaustion.
IPv6 also implements new features that simplify aspects of address assignment (stateless address autoconfiguration) and network renumbering (prefix and router announcements) when changing Internet connectivity providers. The IPv6 subnet size has been standardized by fixing the size of the host identifier portion of an address to 64 bits to facilitate an automatic mechanism for forming the host identifier from Link Layer media addressing information (MAC address).
Network security is integrated into the design of the IPv6 architecture. Internet Protocol Security (IPsec) was originally developed for IPv6, but found widespread optional deployment first in IPv4 (into which it was back-engineered). The IPv6 specifications mandate IPsec implementation as a fundamental interoperability requirement
Features and differences from IPv4
In most regards, IPv6 is a conservative extension of IPv4. Most transport- and application-layer protocols need little or no change to operate over IPv6; exceptions are application protocols that embed network-layer addresses, such as FTP or NTPv3.
IPv6 specifies a new packet format, designed to minimize packet-header processing. Since the headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable.
Larger address space
The most important feature of IPv6 is a much larger address space than that of IPv4: addresses in IPv6 are 128 bits long; this compares with 32 bit addresses in IPv4.
The very large IPv6 address space supports a total of 2128 (about 3.4Ãƒâ€”1038) addressesâ€or approximately 5Ãƒâ€”1028 (roughly 295) addresses for each of the roughly 6.5 billion (6.5Ãƒâ€”109) people alive in 2006. In a different perspective, this is 252 addresses for every observable star in the known universe.
While these numbers are impressive, it was not the intent of the designers of the IPv6 address space to assure geographical saturation with usable addresses. Rather, the longer addresses allow a better, systematic, hierarchical allocation of addresses and efficient route aggregation. With IPv4, complex Classless Inter-Domain Routing (CIDR) techniques were developed to make the best use of the small address space. Renumbering an existing network for a new connectivity provider with different routing prefixes is a major effort with IPv4, as discussed in RFC 2071 and RFC 2072. With IPv6, however, changing the prefix in a few routers can renumber an entire network ad hoc, because the host identifiers (the least-significant 64 bits of an address) are decoupled from the subnet identifiers and the network providerâ„¢s routing prefix.
The size of a subnet in IPv6 is 264 addresses (64-bit subnet mask); the square of the size of the entire IPv4 Internet. Thus, actual address space utilization rates will likely be small in IPv6, but network management and routing will be more efficient.
Stateless address autoconfiguration
IPv6 hosts can configure themselves automatically when connected to a routed IPv6 network using ICMPv6 router discovery messages. When first connected to a network, a host sends a link-local multicast router solicitation request for its configuration parameters; if configured suitably, routers respond to such a request with a router advertisement packet that contains network-layer configuration parameters.
If IPv6 stateless address autoconfiguration (SLAAC) is unsuitable for an application, a host can use stateful configuration (DHCPv6) or be configured manually. Stateless autoconfiguration is not used by routers.
Multicast, the ability to send a single packet to multiple destinations, is part of the base specification in IPv6. This is unlike IPv4, where it is optional (although usually implemented).
IPv6 does not implement broadcast, the ability to send a packet to all hosts on the attached link. The same effect can be achieved by sending a packet to the link-local all hosts multicast group.
Most environments, however, do not currently have their network infrastructures configured to route multicast packets; multicasting on single subnet will work, but global multicasting might not.
Mandatory network layer security
Internet Protocol Security (IPsec), the protocol for IP encryption and authentication, forms an integral part of the base protocol suite in IPv6. IPSec support is mandatory in IPv6; this is unlike IPv4, where it is optional (but usually implemented). IPsec, however, is not widely used at present except for securing traffic between IPv6 Border Gateway Protocol routers.
Simplified processing by routers
A number of simplifications have been made to the packet header, and the process of packet forwarding has been simplified, in order to make packet processing by routers simpler and hence more efficient. Concretely,
The packet header in IPv6 is simpler than that used in IPv4, with many rarely used fields moved to separate options; in effect, although the addresses in IPv6 are four times larger, the (option-less) IPv6 header is only twice the size of the (option-less) IPv4 header.
IPv6 routers do not perform fragmentation. IPv6 hosts are required to either perform PMTU discovery, perform end-to-end fragmentation, or to send packets smaller than the IPv6 minimum maximum transmission unit size of 1280 bytes.
The IPv6 header is not protected by a checksum; integrity protection is assumed to be assured by a transport layer checksum. In effect, IPv6 routers do not need to recompute a checksum when header fields (such as the TTL or Hop Count) change. This improvement may have been made unnecessary by the development of routers that perform checksum computation at link speed using dedicated hardware.
The Time-to-Live field of IPv4 has been renamed to Hop Limit, reflecting the fact that routers are no longer expected to compute the time a packet has spent in a queue.
Unlike mobile IPv4, Mobile IPv6 (MIPv6) avoids triangular routing and is therefore as efficient as normal IPv6. However, since neither MIPv6 nor MIPv4 are widely deployed today, this advantage is mostly theoretical.
IPv4 has a fixed size (40 bytes) of option parameters. In IPv6, options are implemented as additional extension headers after the IPv6 header, which limits their size only by the size of an entire packet.
IPv4 limits packets to 64 KB of payload. IPv6 has optional support for packets over this limit, referred to as jumbograms, which can be as large as 4 GiB. The use of jumbograms may improve performance over high-MTU networks. The presence of jumbograms is indicated by the Jumbo Payload Option header.
The length of network addresses emphasize a most important change when moving from IPv4 to IPv6. IPv6 addresses are 128 bits long (as defined by RFC 4291), whereas IPv4 addresses are 32 bits; where the IPv4 address space contains roughly 4 billion addresses, IPv6 has enough room for 3.4Ãƒâ€”1038 unique addresses.
IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix, and a 64-bit host part, which is either automatically generated from the interfaceâ„¢s MAC address or assigned sequentially. Because the globally unique MAC addresses offer an opportunity to track user equipment, and so users, across time and IPv6 address changes, RFC 3041 was developed to reduce the prospect of user identity being permanently tied to an IPv6 address, thus restoring some of the possibilities of anonymity existing at IPv4. RFC 3041 specifies a mechanism by which time-varying random bit strings can be used as interface circuit identifiers, replacing unchanging and traceable MAC addresses
In the basic Mobile IP protocol, IP packets destined to a mobile node that is outside its home network are routed through the home agent. However packets from the mobile node to the correspondent nodes are routed directly. This is known as triangle routing. Figure 5 illustrates triangle routing.
Figure 5: Triangle Routing
This method may be inefficient in many cases. Consider the case when the correspondent host and the mobile host are in the same network, but not in the home network of the mobile host. In this case the messages will experience unnecessary delay since they have to be first routed to the home agent that resides in the home network. One way to improve this is Route Optimization.
Route Optimization is an extension proposed to the basic Mobile IP protocol . Here messages from the correspondent node are routed directly to the mobile nodeâ„¢s care-of address without having to go through the home agent. Route Optimization provides four main operations. These are:
Updating binding caches,
Managing smooth handoffs between foreign agents,
Acquiring registration keys for smooth handoffs,
Using special tunnels.
1. Updating binding caches: Binding caches are maintained by correspondent nodes for associating the home address of a mobile node with its care-of address. A binding cache entry also has an associated lifetime after which the entry has to be deleted from the cache. If the correspondent node has no binding cache entry for a mobile node, it sends the message addressed to the mobile nodeâ„¢s home address. When the home agent intercepts this message, it encapsulates it and sends it to the mobile nodeâ„¢s care-of address. It then sends a Binding Update message to the correspondent node informing it of the current mobility binding.
2. Managing smooth handoffs between foreign agents: When a mobile node registers with a new foreign agent, the basic Mobile IP does not specify a method to inform the previous foreign agent. Thus the datagrams in flight which had already tunneled to the old care-of address of the mobile node are lost. This problem is solved in Route Optimization by introducing smooth handoffs. Smooth handoff provides a way to notify the previous foreign agent of the mobile nodeâ„¢s new mobility binding.
If a foreign agent supports smooth handoffs, it indicates this in its Agent Advertisement message. When the mobile node moves to a new location, it requests the new foreign agent to inform its previous foreign agent about the new location as part of the registration procedure. The new foreign agent then constructs a Binding Update message and sends it to the previous foreign agent of the mobile node. Thus if the previous foreign agent receives packets from a correspondent node having an out-of-date binding, it forwards the packet to the mobile nodeâ„¢s care-of address. It then sends a Binding Warning message to the mobile nodeâ„¢s home agent. The home agent in turn sends a Binding Update message to the correspondent node. This notification also allows datagrams sent by correspondent nodes having out-of-date binding cache entries to be forwarded to the current care-of address. Finally this notification allows any resources consumed by the mobile node at the previous foreign agent to be released immediately, instead of waiting for the registration lifetime to expire.
3. Acquiring registration keys for smooth handoffs: For managing smooth handoffs, mobile nodes need to communicate with the previous foreign agent. This communication needs to be done securely as any careful foreign agent should require assurance that it is getting authentic handoff information and not arranging to forward in-flight datagrams to a bogus destination. For this purpose a registration key is established between a foreign agent and a mobile node during the registration process. The following methods for establishing registration keys have been proposed in the order of declining preference:
If the home agent and the foreign agent share a security association, the home agent can choose the registration key.
If the foreign agent has a public key, it can again use the home agent to supply the registration key.
If the mobile node includes its public key in its Registration Request, the foreign agent can choose the new registration key.
The mobile node and its foreign agent can execute the Diffie-Hellman key exchange protocol as part of the registration protocol.
This registration key is used to form a security association between the mobile node and the foreign agent.
4.Using special tunnels: When a foreign agent receives a tunneled datagram for which it has no visitor list entry, it concludes that the node sending the tunneled datagram has an out-of-date binding cache entry for the mobile node. If the foreign age nt has a binding cache entry for the mobile node, it should re-tunnel the datagram to the care-of address indicated in its binding cache entry. On the other hand, when a foreign agent receives a datagram for a mobile node for which it has no visitor list or binding cache entry, it constructs a special tunnel datagram . The special tunnel datagram is constructed by encapsulating the datagram and making the outer destination address equal to the inner destination address. This allows the home agent to see the address of the node that tunneled the datagram and prevent sending it to the same node. This avoids a possible routing loop that might have occured if the foreign agent crashed and lost its state information.
Enhancements to the Mobile IP technique, such as Mobile IPv6 and Hierarchical Mobile IPv6 (HMIPv6), are being developed to improve mobile communications in certain circumstances by making the processes more secure and more efficient.
Researche create support for mobile networking without requiring any pre-deployed infrastructure as required by MIP. One such example is Interactive Protocol for Mobile Networking (IPMN) which promises supporting mobility on a regular IP network just from the network edges by intelligent signaling between IP at end-points and application layer module with improved quality of service.
Researchers are also working to create support for mobile networkingentire subnets with support from Mobile IPv6. One such example is Network Mobility (NEMO) Network Mobility Basic Support Protocol by the IETF Network Mobility Working Group which supports mobility for entire Mobile Networks that move and to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and session continuity for every node in the Mobile Network as the network moves.
Mobile IP is most often found in wired and wireless environments where users need to carry their mobile devices across multiple LAN subnets with different IP addresses. It may for example be used in roaming between overlapping wireless systems, for example IP over DVB, WLAN, WiMAX and BWA. Currently, Mobile IP is not required within cellular systems such as 3G, to provide transparency when internet users migrate between cellular towers, since these systems provide their own data link layer handover and roaming mechanisms. However, it is often used in 3G systems to allow seamless IP mobility between different Packet Data Serving Node (PDSN) domains. For Release 8, MIP and different variations like PMIP will be supported by the EPS (Evolved Packet System), at least for non-3GPP accesses.
In many applications (VPN and VoIP, to name a few), sudden changes in network and IP-address can cause problems.
In this article we have explored most of the details of mobile IP,an extension to IP that allows mobile nodes to roam transparently from place to place within the internet, usually with no discernable disruption of services. Mobile IP affects the routing of datagrams within the internet by effectively allowing the home agent to create a tunnel,using encapsulation, between the mobile nodeâ„¢s home network and whatever care-of address happens to identify its current point of attachment.
Mobile IP and route optimization, both must be subjected to rigid requirements for authentication of the claimed care-of addresses, because otherwise malicious hosts could disrupt or completely lose communication with other mobile node.The possible future benefits of simultaneous registrations are briefly explained.
 J. D. Solomon. Mobile IP - The Internet Unplugged. Prentice-Hall, 1997.
 S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998.
 S. Kent and R. Atkinson. IP Authentication Header. RFC 2402, November 1998.
 S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998.
 R. Thayer et all. IP Security Document Roadmap. RFC 2411, November 1998.
 D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409, November 1998.
 C. Madson and R. Glenn. The Use of HMAC-MD5-96 within ESP and AH. RFC 2403, November
 C. Madson and N. Doraswamy. The ESP DES-CBC Cipher Algorithm With Explicit IV. RFC 2405,
 G. Montenegro and V. Gupta. Sunâ„¢s SKIP Firewall Traversal for Mobile IP. RFC 2356, June 1998.