Comparison of IP Mobility Solutions

Elina Mkinen
Helsinki University of Technology
Telecommunications Software and Multimedia Laboratory
May 28, 2003

Abstract
New mobile computing devices are increasing in popularity and wireless networks
have been deployed worldwide. Problems arise when a mobile host changes its location to another network. Mobility solutions are needed to ensure seamless roaming
between networks, so that existing connections will not be broken. Solutions have
been offered by Mobile IPv4 and IPv6, Host Identity Payload and The Migrate Internet Mobility Project. This paper introduces and compares these solutions.

1 Introduction
Wireless networks are becoming more and more common in computer networking. As
laptops, PDAs and other portable devices increase their popularity, the users also prefer a
wireless connection to the Internet. A typical user would be a business traveler who wants
to access his e-mail with a PDA at airports and hotels along the way. Another example is
an office where all employees have a laptop and are able to connect to the office wireless
LAN anywhere in the building.
While it has been possible to use a mobile device within one wireless domain for a long
time, problems arise when the user wants to change location to another network, i.e. roam.
Normally he would have to reconfigure the system before he can continue communication.
The current internet protocols have been designed and standardized before the age of mobile computing. This is why new functionalities need to be added to the TCP/IP protocol
stack to enable mobility. Different solutions that work on different layers have been proposed.
Mobile IP [1] was developed to enable mobility in IPv4 networks. In IPv6 [2] mobility is
built-in, but some modifications still need to be made. Host Identity Protocol (HIP) [13]
takes a new approach, introducing a new namespace and a new layer. Finally, TCP Migrate [21] introduces a new way of continuing disrupted TCP connections using a special
message.
The protocols differ from each other in terms of addressing, routing and security. Also
their stages of development vary.
1

HUT TML 2003

T-110.551 Seminar on Internetworking

2 IP mobility
IP addresses have traditionally been fixed and bound to a physical location. Every time a
host changes its location, the network settings have had to be reconfigured. One step forward towards mobility is DHCP (Dynamic Host Configuration Protocol) [3]. When DHCP
is in use, the terminal will dynamically be assigned an IP address wherever it connects to
a network. This IP address, however, is most likely a different one each time, even in the
same network. This makes it impossible for others to contact the host using its IP address.
A DNS (Domain Name System) [20] name cannot be used either, because they are usually
statically bound to IP addresses.
Another problem is that TCP connections will be torn apart if IP addresses change. Even
if a user with a mobile device is able to roam to another network and obtain an IP address
dynamically, all TCP connections will have to be re-established. New solutions are needed
so that users are able to roam between networks and continue their network communication
seamlessly.
A clear distinction should be made between mobile and wireless networking. For example
a device with a wireless LAN connection is not necessarily mobile - the connection is lost
if the user moves outside the coverage of a certain wireless domain. On the other hand a
node may be mobile without having a wireless connection, i.e. the terminal is plugged in a
new network and the communication can be continued as before.
One thing that needs to be considered is the dual nature of IP addresses. First of all IP
addresses are used to uniquely identify hosts or endpoints of a connection. Second, the
addresses depend on the network topology and all routing protocols depend on the hierarchical structure to deliver packets to the hosts.

3 Mobility in IPv4
3.1 Overview
In IPv4 addresses are associated with the physical network location of the host. When a
host changes its location, the address must change and TCP connections are broken.
Mobile IP introduces the use of two IP addresses: a fixed home address for other nodes to
use, and a dynamic care-of address that defines the current location of the host.
Mobile IP is a standard proposed by the Mobile IP working group of Internet Engineering
Task Force (IETF). It is documented in RFC 3344 [1]. Another good document is [5].
The following sections present the basic principles of Mobile IPv4 operation, network
elements and routing. Some problems are also discussed.

HUT TML 2003

T-110.551 Seminar on Internetworking

3.2 Network elements

To solve the problem caused by the dual nature of IP addresses, each mobile has host two
addresses. One is a static address on the hosts home network, called the home address.
Other hosts trying to contact the mobile host will always use this address. The other address, called the care-of address, is assigned to the host every time it is attached to another
network. This address reflects the hosts current location.
In the home network the host, called a mobile node (MN), has a home agent (HA). When
the mobile node changes its location and joins another network, called a foreign network,
it registers itself to a foreign agent (FA) and obtains a care-of address. The mobile node
will then register its care-of address to the home agent. This may happen either directly
to the home agent, or through the foreign agent. The host wanting to communicate with
the mobile node is called the correspondent node (CN), and it may be either mobile or
stationary.
The mobile node has to have a method for determining whether it is currently attached to its
home network or a foreign network. This method is called agent discovery. It has been built
on top of ICMP Router Discovery by including an extension to a Router Advertisement
message. Home agents and foreign agents periodically broadcast Agent Advertisements.
The mobile node will use these to determine its current location on the Internet. If a mobile
node does not want to wait for an Agent Advertisement or it stops receiving them from a
previous foreign agent, it may broadcast an Agent Solicitation. A foreign agent or the
home agent will then send an answer to the mobile node.

3.3 Routing
Routing in Mobile IP is based on tunneling. A correspondent node always sends all datagrams to the home address of the mobile node. While the mobile node is registered in
a foreign network, the home agent will receive all its datagrams and tunnel them to the
care-of address. For this the datagrams must be encapsulated so that the inner IP header
contains the home address and the original senders address, while the outer header contains the care-of address and the home agents address.
When the datagram reaches the foreign network, the foreign agent delivers it to the mobile
node. The foreign agent compares the destination address in the inner IP header to a list of
visitors that are currently located in the network. If the address is not found on the list, the
datagram is silently discarded. Otherwise it is delivered to the mobile node. The datagram
may be decapsulated either at the foreign agent or the mobile node.
When the mobile host wants to communicate with the correspondent node, it will send
the datagrams directly to it. The mobile node keeps using its home address as the source
address, so that every packet going from correspondent node to the mobile node will be
routed through the home agent. This is called triangle routing, and it is illustrated in
Figure 1. The figure shows how a correspondent node uses the home address to send a
datagram to the mobile node. The home agent receives it and tunnels it to the mobile
node through the foreign agent. The mobile node then sends its datagrams directly to the
correspondent node.

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 1: Triangular routing in Mobile IPv4 [12]

3.4 Problems
Even though Mobile IP does solve the mobility problem, there are several issues and problems that remain unsolved. Routing in Mobile IP is inefficient because of the tunneling.
The fact that the datagrams from the mobile node to the correspondent node are not tunneled also makes the routing asymmetric. It means that the delay for datagrams sent to
the mobile node experience a longer delay, which may cause problems for TCP congestion
control. Reverse tunneling, documented in RFC 3024 [6], offers a solution to the asymmetry problem. Route Optimization [7] has been proposed as a solution to inefficiencies
caused by tunneling, but it has not been deployed for Mobile IPv4.
Another challenge is security. There is no authentication between the foreign agent and the
mobile node or home agent. This way anyone could pretend to be a foreign agent. Also
firewalls cause security-related problems. Some firewalls, especially in companies, block
traffic coming from outside addresses. Thus a mobile node cannot communicate with the
home network when it is located in a foreign network. One solution to this problem is
presented in [8]. Sometimes firewalls block packets coming from the mobile node because
the source address does not match with the network the packets are coming from. Reverse
tunneling can be used to solve this problem.

HUT TML 2003

T-110.551 Seminar on Internetworking

4 Mobility in IPv6
4.1 Overview
As a new version of the IP standard has been developed, mobility issues have also been
addressed from the start. Mobility is an integral part of the IPv6 protocol [2], although
some further extensions are needed. Mobile IPv6 follows the same basic principles as
Mobile IPv4, including home and care-of addresses, home agent and encapsulation of
datagrams. The main differences are that a foreign agent no longer exists and the security
has been improved.
Mobile IPv6 development is still under work by the IETF Mobile IP Working Group. It
is documented in the Internet draft Mobility Support in IPv6 [4]. The following chapters
sum up the operation of Mobile IPv6.

4.2 Network elements

The basic procedures involved in host mobility remain mostly the same as in Mobile IPv4.
The mobile node has a home network, in which it has a home address. For discovering a
home agent, Mobile IPv6 defines the Dynamic Home Agent Address Discovery protocol.
The mobile node sends an ICMP Home Agent Address Discovery Request to a pre-defined
Home-Agents anycast address. When an anycast address is used as destination address,
the message will be delivered to one node from a pre-defined group. The home agent that
receives the message will answer with a reply message including a list of home agents.
The mobile node then registers to one of the home agents by sending a binding update.
When the node moves to another network, it is assigned a care-of address. The main
difference to Mobile IPv4 is how the care-of address is obtained. Instead of from a foreign
agent, the mobile node will acquire its address automatically by either stateless or stateful
Address Autoconfiguration [9, 10], which are standard IPv6 mechanisms. For movement
detection and choosing the default router the mobile node uses IPv6 Neighbor Discovery
[11]. After finding a new care-of address the mobile node registers to the home agent with
a binding update.

4.3 Routing
In Mobile IPv6 triangular routing is no longer used. There are two modes of routing, route
optimization and reverse tunneling. In route optimization only the first packet is tunneled
through the home agent. Then a binding update is made between the mobile node and
the correspondent node. The rest of the packets are delivered directly to the current careof address. The correspondent node adds to the packets a routing header with the home
address, while the mobile node uses the "Home Address" destination option for the home
address. Figure 2 illustrates routing with and without a binding cache entry.
The other mode, reverse tunneling, is useful when the correspondent node does not support
Mobile IPv6. The packets are tunneled through the home agent in both directions. The

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 2: Route optimization in Mobile IPv6 [12]

home agent intercepts all packets addressed to the mobile nodes home address using proxy
Neighbor Discovery. IPv6 encapsulation is used in the tunneling.

4.4 Problems
Many of the problems in Mobile IPv4 have been solved in Mobile IPv6. However, problematic issues still exist, some of them security-related. For example false binding updates
may result in DoS (Denial of Service) attacks. Interworking and transition between Mobile
IPv4 and IPv6 will most likely not be problem free either.

5 Host Identity Payload

5.1 Overview
Host Identity Payload (HIP) [13] with the HIP protocol is an lightweight solution to provide
mobility and security in the Internet. HIP introduces a whole new protocol layer between
the network and transport layers. A new namespace is introduced for host identifiers. The
host identifiers are unique ids and TCP uses them instead of IP addresses. The identifiers
are bound to the public keys of an asymmetric key pair. The deployment of HIP can be
started at the end-points and routers do not need to be updated.
There are three Internet drafts about HIP, written by Robert Moskowitz [13, 14, 15]. The
drafts are, however, already expired. They can be found at the HIP official homepage [16].

HUT TML 2003

T-110.551 Seminar on Internetworking

The basic architecture of HIP is presented in the following chapter, followed by discussion
of security issues.

5.2 Architecture
HIP introduces a new internet namespace to complement the two existing ones: IP addresses and DNS names. The namespace is called Host Identity (HI) namespace and it is
based on Public Key Cryptography. It means that every host has a Host Identity based on
a public key. The HI is not directly used in any protocol, but it is represented by a Host
Identity Tag (HIT), a hash over the HI in a 128 bit field. Another possibility is Local Scope
Identity (LSI), a 32 bit localized representation of a HI. The HI itself should be stored in a
directory, e.g. DNS.
The HIP approach also adds a new protocol layer, called Host Identity Layer, between the
transport and network layers of the TCP/IP protocol stack. The modified protocol stack
is illustrated in Figure 3. A TCP connection endpoint is normally identified by the pair
[IP address, port], but in HIP, the pair changes to [HI, port] [17]. The Host Identities are
dynamically bound to IP addresses, so that when a host moves and the IP address changes,
the connections will remain active.
APPLICATION
TCP
HIP
IP
LINK

Figure 3: HIP protocol stack

The two end-points of a connection are called initiator and responder. Either one of them
may be mobile. Initiator mobility is rather simple, since the responder receives the initiators IP address in the first packet. When the responder is mobile, a rendezvous server is
needed to keep track of the responders current IP address. The rendezvous server forwards
the first packet from the initiator to the responder and is not involved after that.

5.3 Security
Special attention has been paid to HIP security on various levels. First of all, host authentication is built-in, since Host Identities are based on public key cryptography. HIP is
also closely connected to IPsec ESP (Encapsulated Security Payload) [18]. The Security
Parameter Index (SPI) in ESP may be replaced by HIT when the connection is encrypted.
Host Identities may also be used in Internet Key Exchange (IKE) [19].

HUT TML 2003

T-110.551 Seminar on Internetworking

Because the connection establishment handshake includes four steps instead of the traditional three, HIP provides ways of preventing different types of DoS (Denial of Service)
attacks. HIP also provides support for anonymity. The Host Identities may be anonymous,
i.e. not stored in DNS. With tunneling and forwarding mechanisms the identity of both
end-points could be hidden from any outsiders. [17]

5.4 Problems
Deploying HIP cannot be considered very simple, since all hosts have to be modified. The
current specification of HIP does not support multicasting, so changes to the protocol need
to be made.

6 The Migrate Internet Mobility Project

6.1 Overview
The Migrate project [21, 22] is an end-to-end mobility approach that places the mobility services in communication end-points. The solution does not require changes to the
existing namespaces or addressing schemes. It provides a new way of resuming a TCP
connection after one of the end-points has changed its location and the connection has
been disrupted.
The Migrate project takes advantage of Dynamic DNS, an extension to the DNS service
that allows DNS data to be updated dynamically. Whenever a host changes its IP address,
it informs the DNS server about the change with an update message.
The Migrate Internet Mobility Project is a project of MITs Laboratory for Computer Science. Documentation [21, 22] can be found at the projects homepage [24]. A (now expired) draft [23] has also been written. Dynamic DNS is an IETF standard, documented in
RFC 2136 [26].
The two parts of Migrate, the Session layer and TCP connection migration are explained
in the following chapters.

6.2 The Session Layer

The Migrate project introduces a new layer, called the session layer. It is located between the transport and application layers of the TCP/IP stack. The session layer helps
the applications manage the changes that occur on the lower level, i.e. disconnections and
reconnections. [25] The modified protocol stack is illustrated in Figure 4.

HUT TML 2003

T-110.551 Seminar on Internetworking

APPLICATION
SESSION
TCP
IP
LINK

Figure 4: Migrate protocol stack

6.3 TCP Connection Migration

TCP connections are identified by the 4-tuple of source and destination IP addresses and
port numbers. According to the Migrate proposition, a connection would be identified by
the source address and port number together with a token, called Session ID. The token is
secured with a secret connection key to prevent connection hijacking.
When a host changes its location and thus its IP address, the connection is broken. But
with a special Migrate SYN packet the mobile host may continue the connection, rather
than starting a new one. The SYN segment contains a token identifying the previous connection. The same sequence number space is used after the migration, so that the migrate
message has the same number as the last transmitted segment of the original connection.
An example of transmitted segments is shown in Figure 5.
The role of dynamic DNS is emphasized when the mobile host is a server. When a client
wants to connect to a server, it uses its DNS name. The server must keep the DNS server
up to date about its current IP address with dynamic DNS updates. This is not relevant if
the mobile host is always a client and does not need to be reached by other hosts. [25]

6.4 Problems
One remarkable problem of the Migrate approach is that it does not work if both end-points
are mobile at the same time. Using Migrate also requires modifications to all applications.

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 5: TCP connection migration [22]

7 Comparison
The solutions presented in this paper differ from each other in many senses. Mobile IPv4
and IPv6 both work on the network layer (IP) of the TCP/IP stack. Mobile IPv4 adds some
extensions to the stack, while in IPv6 mobility is mostly built-in. HIP proposes a new layer
to be added between the transport and network layers. Also TCP Migrate introduces a
new layer, but one step higher: between the transport and application layers. The different
protocol stacks of the solutions are presented in Figure 6.
The addressing scheme is also different in all solutions. The Mobile IP solutions require
using two IP addresses for each host. HIP introduces a new namespace of Host Identities
to be used instead of IP addresses, which are dynamically bound to them. The Migrate
project, on the other hand, uses dynamic DNS to keep track of the changing IP addresses
and the protocol itself is able to handle changing addresses.
Since Migrate works on a higher layer, routing is not really an issue. The same applies for
HIP. Mobile IPv4 and IPv6 differ from each other in this sense. In Mobile IPv4 routing is
triangular, so that packets from the correspondent node to the mobile node are routed via
the home agent while in the other direction they are routed directly to the correspondent
10

HUT TML 2003

T-110.551 Seminar on Internetworking

APPLICATION

APPLICATION

APPLICATION

TCP

SESSION

TCP

HIP

TCP

IP

IP

IP

LINK
Mobile IPv4 and IPv6

LINK
HIP

LINK
Migrate

Figure 6: Protocol stacks of the solutions

node. This is asymmetrical and inefficient. In Mobile IPv6 there are two options after
the first packet: either all packets are routed via the home agent or directly between the
end-points.
In Mobile IPv4 there remain some open issues and problems regarding security, such as
foreign agent authentication. Mobility is built-in in IPv6 where security issues have been
paid attention to from the start. IPsec is used as the security mechanism. This does not,
however, mean that no problems exist. HIP was designed to be a security solution in
addition to mobility, so authentication and encryption are a part of the protocol. Since the
Migrate approach does not involve any third parties, security issues are somewhat simpler.
The connection ID can be secured with a connection key. IPsec may also be used.
Mobile IPv4 is the most mature solution of the four. Implementations exist and are in
use. Mobile IPv6 is on a more experimental level, and it has not been fully standardized
yet. Different vendors have their own implementations. HIP and Migrate are both at a
propositional stage, and have had experimental implementations.

8 Summary
Mobility solutions are required to enable roaming users to maintain their connections when
changing their locations. This paper presented and compared four of those solutions. Mobile IPv4 has been built on top of IPv4 stack and it works by maintaining two IP addresses
per host: a fixed home address and a dynamic care-of address. In IPv6 mobility is an integral part of the protocol and is mostly based on the same principles as Mobile IPv4. Host
Identity Payload adds a new layer above the IP layer and uses Host Identities instead of IP
addresses as connection end-point identifiers. The Migrate solution adds a new layer on
top of the transport layer. It provides a way of continuing TCP connections with a special
SYN packet after one of the end-points has changed its location.

11

HUT TML 2003

T-110.551 Seminar on Internetworking

References
[1] Charles Perkins. IP Mobility Support for IPv4. RFC 3344, IETF Network Working
Group, August 2002. http://www.ietf.org/rfc/rfc3344.txt
[2] S. Deering, R. Hinden.
Internet Protocol, Version 6 (IPv6) Specification.
RFC 2460, IETF IP Version 6 Working Group, December 1998.
http://www.ietf.org/rfc/rfc2460.txt
[3] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, IETF Dynamic Host
Configuration Working Group, March 1997. http://www.ietf.org/rfc/rfc1541.txt
[4] D. Johnson, C. Perkins, J. Arkko. IP Mobility Support for IPv6. Internet draft, version 21, IETF Mobile IP Working Group, February 2003. http://www.ietf.org/internetdrafts/draft-ietf-mobileip-ipv6-21.txt
[5] Charles Perkins. Mobile Networking Through Mobile IP. In IEEE Internet Computing,
pp. 58-69, January - February 1998.
[6] G. Montenegro. Reverse Tunneling for Mobile IP, revised. RFC 3024, IETF Network
Working Group, January 2001. http://www.ietf.org/rfc/rfc3024.txt
[7] Charles Perkins, David B. Johnson. Route Optimization in Mobile IP. Internet draft, version 11, IETF Mobile IP Working Group, September 2001.
http://www.ietf.org/proceedings/02mar/I-D/draft-ietf-mobileip-optim-11.txt
[8] G. Montenegro. Suns SKIP Firewall Traversal for Mobile IP. RFC 2356, IETF Network Working Group, June 1998. http://www.ietf.org/rfc/rfc2356.txt
[9] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, IETF
Network Working Group, December 1998. http://www.ietf.org/rfc/rfc2462.txt
[10] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. IPv6 Dynamic
Host Configuration Protocol for IPv6 (DHCPv6). Internet draft, version 28, IETF
Network Working Group, November 2002. http://www.ietf.org/internet-drafts/draftietf-dhc-dhcpv6-28.txt
[11] T. Narten, E. Nordmark, W. Simpson. IPv6 Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, IETF Network Working Group, December 1998.
http://www.ietf.org/rfc/rfc2461.txt
[12] Alan Halachimi, Eric Smiley.
IP Mobility:
An Investigative Comparison Between IPv4 and IPv6.
Duke University, Spring 2002.
http://www.disp.duke.edu/esmiley/ip_mobility_final_paper.htm
[13] R. Moskowitz. Host Identity Payload Architecture. Internet draft, version 2, February
2001. (expired) http://homebase.htt-consult.com/hip/draft-moskowitz-hip-arch-02.txt
[14] R. Moskowitz. Host Identity Payload And Protocol. Internet draft, version 5, October
2001. (expired) http://homebase.htt-consult.com/hip/draft-moskowitz-hip-05.txt
[15] R. Moskowitz. Host Identity Payload Implementation. Internet draft, version 1,
February 2001. (expired) http://homebase.htt-consult.com/hip/draft-moskowitz-hipimpl-01.txt
12

HUT TML 2003

T-110.551 Seminar on Internetworking

[16] The Host Identity Payload Homepage: http://homebase.htt-consult.com/hip/

[17] Miika Komu.
Host Identity Payload in Home Networks.
Residential
and Virtual Home Environments - Seminar on Internetworking, Helsinki
University of Technology, Spring 2002.
http://www.tml.hut.fi/Studies/T110.551/2002/papers/May/miika.komu.pdf
[18] S. Kent, R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, IETF
Network Working Group, November 1998. http://www.ietf.org/rfc/rfc2406.txt
[19] D. Harkins, D. Carrel. The Internet Key Exchange (IKE). RFC 2409, IETF Network
Working Group, November 1998. http://www.ietf.org/rfc/rfc2409.txt
[20] P. Mockapetris. Domain Names - Concepts and facilities. RFC 1034, IETF Network
Working Group, November 1987. http://www.ietf.org/rfc/rfc1034.txt
[21] Alex C. Snoeren, Hari Balakrishnan, M. Frans Kaashoek. Reconsidering Internet
Mobility. In Proc. of the 8th Workshop on Hot Topics in Operating Systems (HotOSVIII), May 2001. http://nms.lcs.mit.edu/papers/migrate-hotOS.pdf
[22] Alex C. Snoeren, Hari Balakrishnan.
An End-to-End Approach to Host
Mobility.
In Proc. of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking, pp. 155-166 August 2000.
http://nms.lcs.mit.edu/papers/e2emobility.pdf
[23] A. C. Snoeren, H. Balakrishnan. TCP Connection Migration. Internet draft, version
0, November 2000. (expired) http://nms.lcs.mit.edu/papers/draft-snoeren-tcp-migrate00.txt
[24] The
Migrate
Internet
http://nms.lcs.mit.edu/projects/migrate/

Mobility

Project

homepage:

[25] Olli Aalto. The Internet Mobility Project. Research Seminar on Middleware for Mobile Computing, University of Helsinki, Department of Computer Science, February
2002. http://www.cs.helsinki.fi/u/kraatika/Courses/sem02s/Migrate.pdf
[26] P. Vixie, S. Thomson, Y. Rekhter, J. Bound. Dynamic Updates in the Domain Name
System (DNS UPDATE). RFC 2136, IETF Network Working Group, April 1997.
http://www.ietf.org/rfc/rfc2136.txt

13