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. [2290]

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. [2005]

When you make an international call, you dial the country code, the
area code, the local telephone number and perhaps also the extension to
get your call through all the way from your phone to your friend's desktop.
There is a hierarchy in the numbering system, which gives one obvious advantage:
every telephone exchange knows to which direction your call should be forwarded,
but doesn't have to care which way the call will be forwarded from the
next exchange. No matter where you are calling from.

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.

Let's think about a service man, who carries his laptop - the host
- into another office and plugs it into the local network there. His address
will be different from what it usually is in his home network. This is
a degree of freedom we could call portable. To distinguish true
mobile IP from portable there is one condition which has to be met:

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
efficiently.
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.

In the IP addressing there is a logical mismatch for mobility: for
compatibility the IP address should be kept constant. In the IP world the
network part of an address contains location information. If the host is
mobile, the location is not fixed. Thus the address can not be fixed, but
it has to be fixed to be compatible with the old network.

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.

Sony MHP

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 MHP

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.

The mobile subnet routers form one virtual mobile subnet. When a
host migrates the closest mobile subnet router gets aware of the
presence of the host. This router informs all other mobile subnet routers
belonging to the same virtual subnet the new location of the host. Whenever
these routers get an IP packet going to the host, they encapsulate the
packet and send it to the router, which has registered the host.

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.

In priciple the proposed mobile IP standard, IMHP, Internet Mobile
Host Protocol, represents many of the ideas done in the past. As a major
difference to the ideas presented above IMHP has more effective procedure
to update location caches: it updates only those caches and entries which
are detected to be incorrect.

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 [2005].
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.

Figure 2.1. Mobile IP routing.

In a basic mobile IP operation, packets sent by the correspondent host
to the mobile host are always sent to the mobile host’s home network first,
and the forwarded by the home agent to the mobile host’s current care-of
address. Packet originating from the mobile host are sent directly to the
correspondent host, thus forming a triangular route. These packets use
the mobile host’s home address as their source address to preserve their
home identity. The packets forwarded by the home agent to the care-of address
are encapsulated in another IP packet.

If a mobile host is on its home network, is may operate as though it
had a fixed connection without any mobile IP specialities.

The proposed standard suggest that a normal IP in IP tunneling should
be supported [2002]. In addition to that, a minimal
encapsulation defined in [2003] may also be used.
Minimal encapsulation is an encapsulation method that is very efficient
in terms of overhead: adds only 8 or 12 bytes to each packet sent to a
mobile host. In the encapsulation process the header is rewritten. The
outer packet has a standard IP header, while the encapsulated packet has
a dedicated but small header. This is why it is said that the tunneling
header is inserted immediately after the original header of Figure 2.2.

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.

After creating the forwarding header the original (outer) header is changed
in a way that the Protocol number will indicate the encapsulation method.
The Destination Address will be set to the address of mobile host’s attachment
point, the care-of address, because that’s where the packet will be sent.
The Source Address is set to the IP address of the unit doing the encapsulation.
This is done - as we will see - to give the rest of the system an idea
of who did the encapsulation in the case that the care-of address is incorrect
or obsolete.

Finally Checksum and Length fields are adjusted to reflect the changes.

The home agent maintains a list known as a home list, which
identifies those mobile hosts it is configured to serve, along with the
current location of each of these mobile hosts. This location is the address
of the foreign agent, which has the connection to the mobile host.

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.
[2002]

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.

2.4 Updating
the location information

In contrary to the earlier approaches described, IMHP does not flood
the bindings throughout the network. Instead it is pinpointing the new
binding to only those nodes that have done a false encapsulation or are
otherwise likely to have an incorrect binding for a mobile host. As mentioned
earlier, the address of the encapsulating node was inserted to the tunneling
header to support this function.

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.

Mobile IP is designed to run over any type of media and any type of
data link-layer. The interaction between Mobile IP and PPP has been underspecified
and generally has resulted in an inappropriate application of Mobile IP
when mobile nodes connect to the Internet via PPP. A recent paper [2290]
fills this gap.

Every IPv6 router is defined to support encapsulation, so every router
may be serving as a home agent.

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
frequently.

Figure 2.5 illustrates the basic operation when a mobile host (MH1)
within range of a foreign agent FA1, having a home agent HA1, wants to
communicate with another mobile host (MH2) within range of a foreign agent
FA2, having a home agent HA2. The following operations are shown in Figure
2.5:

MH1 and MH2 both register with their foreign agents and notify their home
agents of their new bindings.

Suppose that MH1 wants to send a packet to MH2 and MH1 does not know the
care-of address of MH2. MH1 transmits the packet relying on existing routing
protocols, through FA1. The packet is received by MH2’s home agent, HA2,
which tunnels the packet to MH2’s foreign agent FA2. When FA2 receives
the tunneled packet, it decapsulates it and delivers it locally.

When HA2 receives and the tunnels the packet, it also sends to the source
(here, MH1) an IMHP Binding Notify packet containing MH2’s binding, as
MH1 seems not to have a binding cached for MH2.

MH1 can transmit future packets for MH2 by tunneling them directly to MH2’s
current foreign agent, FA2. A close to optimum route is thus established.

Figure 2.6 describes the same situation which was the case at the end
of the previous example. It describes what happens when MH2 migrates
to a new location. The following operations are shown in Figure 2.6:

MH2 detects that it is connected to a new network. It registers with a
new foreign agent, FA3, and notifies MH2’s home agent (HA2).

MH2’s previous foreign agent, FA2, is also notified of MH2’s new binding.

Suppose that MH1 wants to send a packet to where it believes MH2 to be
located (FA2). FA2 forwards the packet to FA3. FA3 decapsulates the packet
and delivers it locally to MH2.

FA2 recognizes that MH1 must have an old binding for MH2, since otherwise
MH1 would not have tunneled the packet to FA2. FA2 thus sends MH1 a Binding
Notify packet notifying it of MH2’s new binding at FA3.

It should be noted that all the binding notifies may need to be authenticated
for security reasons, as described in the following chapter.

3. Technical issues

3.1 Security
considerations

Mobile host is by nature more vulnerable as far as a information security
is concerned. There is for example a risk that a malicious host tries to
get an IP address which belongs to another host and thus get through firewalls
etc. IMHP is designed to support a range of security models, ranging from
no security to weak security to strong security.

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.

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.

When a mobile host is on its home network it may act as if it had a
fixed connection to the network. In this case mobile IP does not affect
IP multicast at all.

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.

Walkstation II was a Swedish project to examine future mobile data
systems for upcoming interactive services. It had an objective to provide
mobile users with seamless data communications, which is transparent for
users as well as the underlying multimedia applications and the supporting
fixed infrastructure. Basically these are the same ideas which exist in
mobile IP as well. It is not, however, a part of mobile IP development,
but an experiment with mobile hosts.

Walkstation II was based on Columbia MHP. The starting point of the
project was developing a mobile router, MINT. Studies on radio technology
played a significant role as well. A part of the project dealt with distributed
file systems and location dependent services. When studying radio communications,
aspects of VLSI design and power consumption were carefully investigated.

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.

4. Conclusion

The development of Mobile IP has been going on for over half a decade.
By today, the proposals have came to a point where there are no widely
known drawbacks. A quotation from [2005] gives the
same impression:

“...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. [2005]

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.