MOBILE IP explained
When IP routing was originally defined, mobility of hosts was not considered to be an issue. Routing methods were built for static networks, where the hosts were unlikely to move from one subnet to another. Routing takes advantage of a “network number“ contained in every IP address. Thus, the IP address encodes the computer’s physical location, and - by default - the location is fixed.
Mobile IP defines protocols and procedures by which packets can be routed to a mobile node, regardless of its current point-of-attachment to the Internet, and without changing its IP address. 
Packets destined to a mobile node are routed first to its home network
- a network identified by the network prefix of the mobile node's (permanent)
home address. At the home network, the mobile node's home agent
intercepts such packets and tunnels them to the mobile node's most recently
reported care-of address. At the endpoint of the tunnel, the inner
packets are decapsulated and delivered to the mobile node. In the reverse
direction, packets sourced by mobile nodes are routed to their destination
using standard IP routing mechanisms. 
2.2 Minimal encapsulation in IMHP tunneling
2.3 The location information
2.4 Updating the location information
2.5 Using PPP in mobile IP
2.6 Mobility support in IPv6
2.7 Packet transmission examples
1.1 IP routing [nag]
This is roughly what happens in IP networks as well. The procedure of forwarding an IP packet is called routing. The routers have the knowledge to which direction the packet should be forwarded, although they may not know the exact location where the packet is going to. The routing tables typically maintain only the next-hop information for each destination IP address.
The same kind of structure as in the telephone numbers exists in IP addresses. IP addresses are divided into a host and network part: if compared to telephone numbers the host address is about the same as the extension in the phone number while the networks address resembles the beginning of the phone number. In other words, the network number is derived from the IP address by masking off some of the low-order bits.
Internet is a collection of small autonomous networks. By default, the destination network is derived from the network part of the IP address. It means that the network part de facto tells the location. When mobility is concerned, there is no fixed location - the network address seems to be in contradiction to mobility.
If a host moves from one network to another - migrates - either
the host should change its address to fit the new network or the routing
mechanisms should be able to forward the messages into a network where
the recipients address is an alien. The internet routing scheme was originally
created at a time when the mobility of hosts was not considered to be an
issue, thus all routing mechanisms are more or less static and can not
handle misrouting of individual addresses.
1) Operational transparency, which means that a user does not have to perform any special actions, no configuration changes, no rebooting, nothing. The migration takes place in background while the computer is on. Operational transparency requires some sort of automatic migration detection and protocols to handle the actual migration.
By itself the operational transparency could be fairly straightforward to achieve. But taking into account that migration may happen at any time, even in the middle of data transfer, the host probably bouncing back and forth form one network to another, there is another obvious condition, which has to be taken into account:
2) Performance transparency. This means that the quality of the service
should not degrade and furthermore, the network resources should be used
These two requirements are pushing us to create more advanced arrangements. Now things are getting more complicated and while it does so, we have to pay special attention to other aspects as well:
3) Backward compatibility. From the service point of view there should not be any difference, whether the host is in mobile or in stationary network. It seems to be a must that the IP address should be kept constant during migration. Otherwise it would be inevitable to make changes to higher layers and lose some of the compatibility.
4) Infrastucture requirements should be minimized. The existing internet infrastructure should be utilized when creating a mobile networks, which cover large areas. We should not create any parallel networks. The old network can not be discarded for the sake of mobility.
5) Some alternatives may require more additional IP addresses than the others. These days it is a preferable property to cope with as small additional address space as possible.
6) Last but not least we should keep in mind the security issue.
This means that the actual location of the mobile host should be a separate piece of information somewhere else, not in the address. Wherever this location information is created or needed, it should be propagated through the internet network as required.
There has been four early attempts to solve the mobility problem. The major difference between these proposals is the way how this location information is defined and propagated.
In Sony Mobile Host Protocol, every host has an unique identifier. Every host has a home gateway, which should always know where the host is. When a Sony host connects to a new location it acquires a new address from the local address server. The mapping between the identifier and this address is then sent to the home gateway.
All the IP packets in this solution carry additional information, for example the identifier and some time stamps. This information is carried in a new IP option. Every Sony router in the system reads the mapping between and the address from the packets passing through. The routers have a small caching database which keeps on tracking which identifier has which address. If the packet has different address than what the router has in the cache, the router compares the time stamps. If the packet has a more recent time stamp, the router changes the hosts IP address on the fly. If the cache database has an older time stamp, then the cache is updated. After a small time out period of no traffic the entry is deleted from the cache. In the case no router in the path knows what the location is, the packet is routed to the home gateway, which then changes the IP address and forwards the packet to the correct location.
The problem with Sony MHP is that it relies on a high percentage of routers being Sony routers. Also it relies on all links being error free. As an compatibility point of view the IP option is likely to be dropped somewhere in the net by a non Sony compatible router or host. It does not support IP multicast, either. Furthermore the Sony MHP consumes a large number of IP addresses because every local address server must have as large address space reserved as the maximum number of hosts connected to it is.
Columbia Mobile Host Protocol is based on encapsulating an IP packet
going to the host into another IP packet. This method is called IP tunneling.
The outer packet has the address of the local network where the host is,
while the inner packet is the actual packet to be delivered. Thus there
is no need to change the host address during migration. In IP tunneling
an outer IP header is inserted before the datagram's existing IP header,
as in Figure 1.1. This is often referred as IP encapsulation.
Figure 1.1. IP encapsulation .
Columbia MHP is applicable for small networks and small number of mobile subnet routers and thus limits the mobility. Columbia overcomes this limitation by presenting a popup mode: In this mode there are several virtual networks which transfer data of mobile hosts roaming in a foreign network. All packets are originally addressed to the home network from where they are forwarded to the foreign network by using the same tunneling method. This makes the routing less optimal and is a drawback.
Other drawbacks in Columbia MHP are the extra payload which comes from the routers advertizing the migration of hosts and large address base needed in popup operation - every subnet must have a worst case number of addresses permanently reserved. In addition, there is no support for IP multicast.
IBM I MHP
IBM's first Mobile Host Protocol combines some of the ideas presented in Sony and Columbia approaches. It resembles Columbia MHP in the respect that the closest router - base station - registers the host the same way. The routing mechanism including the concept of home gateway resembles Sony MHP. The home gateway is renamed as home mobile router.
Instead of creating a new IP option IBM I is using existing loose source routing (LSSR) to propagate the mapping between location and the information through the network. By using LSSR, the existing hosts can take part in IBM I MHP without modification. LSSR is inserted be the base station and if defines the reverse route. If the host migrates and there are still packets addressed to the old base station, the base station sends the packet to the home mobile router, which in turn forwards it to the present base station. This means that only those packets which are on their way when migrating have to be redirected.
The problem with LSSR is that it has not usually been properly implemented. This means that most of the packets would be sent via the home mobile router. UDP/IP packets are always passing through the home mobile router. The LSSR should be modified and widely implemented before the IBM I MHP could be taken into use widely. In addition, the system relies heavily on the reliability of the base stations. Fail safe arrangements are difficult to implement. IP multicast does not work, either.
IBM II MHP
IBM's second Mobile Host Protocol specifies merely the architecture of a mobile IP system. It has some fundamental ideas similar to IBM I, but it is using IP tunneling instead of implementing LSSR.
All the packets directed to the mobile host are encapslulated and sent directly to the closest base station in the case the sender is able to detect that the base station understands IBM II encapsulation. Otherwise the packets are sent to the home mobile router which does the encapsulation and redirecting.
IBM II MHP could be a long term solution, requiring significant numbers of existing hosts all over the network understanding the IBM II encapsulation procedure. Meanwhile all packets would be routed less optimally. And just like the other approaches, IBM II MHP does not support IP multicast.
2. Proposed standard [mntmi]
In IMHP every mobile host has two addresses: the fixed home address and a care-of address. The home address is static and identifies the connection. The home address points to the home network, where every host has a home agent. The home agent has the same function as the mobile home router in IBM I and home gateway in Sony MHP - it is the destination where the packets go if a host is not known or the rest of the system does not understand the mobile protocol. Just as in Sony and IBM solutions, the home agent has a most up-to-date database which is able to tell where the host actually is, what is the care-of address of the mobile host.
This care-of address can be the address of a foreign agent, which has the same function as the base station in IBM I and mobile subnet router in Columbia MHP’s. The foreign agent is the router which is closest to the host. This is also referred as the point of attachment. The care-of address may also be an unique local address (co-located care-of address), which makes it possible to process the necessary functions inside the mobile host, without any foreign agent. This is especially useful in networks, which have not deployed a foreign agent . For clarity this presentation assumes that a foreign agent is available. Technically the care-of address is just the end point of a tunnel described below.
When a mobile host migrates, the care-of address changes while the home address remains static. All the traffic to the roaming mobile host comes to the care-of address as encapsulated IP packets: IMHP is taking advance of IP tunneling. In Figure 2.1 the correspondent host is any host in the net, with which the mobile host exchanges information. In this case the correspondent host is not aware of the exact location of the mobile host and the packets are sent via the home agent.
If a mobile host is on its home network, is may operate as though it
had a fixed connection without any mobile IP specialities.
Figure 2.2. Minimal encapsulation .
The home address of the mobile host (Destination address) and Protocol
number in the IP header are moved from the original header into the forwarding
header. This piece of information with Protocol, a ‘S’ bit and Checksum
occupies two first blocks of the forwarding header. If the encapsulation
is not done in the correspondent host, the Original Source Address is also
moved into the forwarding header, which gives the forwarding header a third
block. Thus the length of the forwarding header is either 8 or 12 bytes,
depending on who does the encapsulation. The structure of the minimal forwarding
header is shown in Figure 2.3. The ‘S’ bit tells the receiver whether the
third byte is present or not.
Figure 2.3. Minimal forwarding header .
Finally Checksum and Length fields are adjusted to reflect the changes.
Each foreign agent maintains a list known as a visitor list, which identifies those mobile hosts that are currently registered with it. An entry in this list is the mobile host’s home address and mobile host’s current location. This combination is known as a binding. The binding between a mobile host and a foreign agent is tagged by a logical timestamp, which is generated by the mobile host by incrementing its previous timestamp value each time it attempt to register with a foreign agent. The timestamp is always included with any binding stored or passed through the network.
Mobility agents (for example home agents and foreign agents) advertise their presence via Agent Advertisement messages. When a mobile host receives an Agent Advertisement it determines whether it is on its home network or a foreign network. This provides also the automatic migration detection and gives the mobile host an indication to initiate a registration process during which the host sends a registration request to the home agent and a deregistration to the possible previous foreign agent. 
The location information, wherever it is, may be updated by special packets defined in the IMHP management protocol. According to this management protocol any node in the network may send a Binding Notify packet to a node, which is detected to have an obsolete or incorrect binding for a mobile host. If the node keeps track on the bindings, is able to encapsulate a packet for mobile IP and is neither a home agent nor a foreign agent, it is called as a cache agent. The list of bindings it has is known as a location cache. A typical cache agent could be not only an IMHP compatible router, which is able to do the encapsulation, but also a IMHP compatible correspondent host, which encapsulates the packet right away.
Whenever a cache agent discovers that it has the destination address in its cache, it encapsulates the packet. From now on the packet is technically a normal IP packet redirected to go directly to the care-of address.
According to the IMHP management protocol, any node in the network may
ask the home agent about the current location of a mobile host.
Every time a Binding Notify is received, the time stamps are compared to judge, which one of the care-of addresses is correct and which one is obsolete. If there is an older time stamp in the cache, the entry is corrected, if a more recent one was found form the cache, a Binding Notify is sent back.
Usually all the binding updates are done by other nodes. There are two exceptions (Figure 2.4) [pmj]:
1) when roaming, the mobile host always notifies its home agent by itself
2) when roaming, the mobile host attempts to notify its previous foreign agents by itself
When a packet gets to the home agent from the network, the home agent
does the encapsulation and sends it to the foreign agent. But, in addition
to that, the home agent also sends a Binding Notify to the sender of the
packet. When this Binding Notify passes through any cache agent, it will
update its location cache. Next time when a packet is going the same way,
the first cache agent in the route is able to do the encapsulation and
the route becomes optimal.
When a mobile host has migrated and an encapsulated packet is mis-routed to the previous foreign agent, this agent makes a new encapsulation to the correct address and sends a Binding Notify to the sender. If this old agent has already forgotten the correct address, the packet is encapsulated again and sent to the home agent. The home agent then sends a Binding Notify to the old foreign agent, which in turn is able to send a proper Binding Notify when the next incorrect packet with the same home address comes in.
The location caches have typically a time-out value for every binding.
When it has expired, the binding is deleted.
Correspondent nodes are also expected to send the packets directly
to the care-of address. This will lead into more robust communication,
because the home agent - a single point of failure - has to be used less
3. Technical issues
3.1 Security considerations
Security models [pmj]
If IMHP operates with no security, a malicious host may intercept a packet stream to a mobile host very simply by sending a false Binding Notify to re-route the packets to another address. This risk is totally unacceptable in an open environment like the Internet.
Under the strong security, IMHP authenticates any Binding Notify messages or other information they receive about a mobile host. Public and private keys and trusted servers are used, but as an drawback it slows down the operation.
To gain a level of security available in the rest of the Internet, a weak security model can be utilized. In this model there are two main cases which have been protected against malicious attempts. First, the home agent must have confidence that the care-of address of a mobile host is correct. Second, other IMHP compatible nodes in the network need to authenticate bindings which are received in Binding Notify packets.
When a host is migrating, it sends the home agent a Registration Request with password in the weak security model. The password gives the same degree of security as available in the stationary Internet.
In the weak security model, when someone asks the home agent about a mobile host’s current binding, it sends also a random number. The home agent replies with the binding and the same random number. Afterwards this random number is no longer valid. By doing this no one can repeat the reply with incorrect data.
When a mobile host migrates, the new foreign agent receives a random number from the host. When the host migrates again, it sends it a Binding Request with the same random number.
Use of IPsec [zc]
The aim of using Ipsec ESP protocol in the mobile IP is to protect the redirected packets against both passive and active attacks launched. It should also aid these packets to go through firewalls. The security models do not protect mobile IP traffic too well against deliberate attacks.
By not going into details, the IPSec encryption would be used on mobile IP tunnels. Furthermore, these tunnels would be established by using an automatic key and a security association management protocol.
However, the Mobile IPSec draft is over one year old and it has not
received any RFC status. It is uncertain if this Internet-draft ever gets
into the standardization process as it is.
A mobile node can join a multicast group in one of two ways: Either it joins the group via a multicast router on the visited subnet or in the home network.
If a mobile host is using the multicast router on the visited subnet and the host has a co-located care-of address (the end point of an IP tunnel is the host itself), it should use the care-of address as a source address when sending IGMP (Internet Group Management Protocol) messages. Otherwise it has no other identity in the visited network than the home address, and should use it, because the foreign agent is able to take care of it.
If the host is using the multicast router on its home network and the
host has once again a co-located care-of address, the home agent will tunnel
the packets directly to the host. If the care-of address belongs to the
foreign agent, a recursive tunneling is needed: The home agent has
to encapsulate the multicast packet into an unicast datagram and send this
unicast packet to the home address, back to itself! From this point on
the data which used to be multicast data will be taken care of as if it
would be a normal unicast packet. All this requires that the home agent
is capable of taking care of multicast traffic.
Starting as early as 1992, one could thus say that this project had a definite merit of bringing together experts from different areas in order to accomplish an operational network for mobile hosts.
“...the technical specification document is stable, a MIB has been written, the security architecture has been set forth in accordance with IAB principles, and several independent implementations have been demonstrated to be interoperable.“
Mobile IP is at its best in a large network. Roaming in an area where the transceivers cover only a very small geographic area, the mobility can be achieved by a simpler manner. 
A wide use of Mobile IP requires that a considerably high number of routers support it, otherwise the routing will be less optimal. Keeping in mind the benefits of compatibility, this can be considered as a minor - and temporary - inconvenience.