Case Study on
Mobile Routing
By
Mehul Doshi
doshim2@cs.rpi.edu
 Abstract:
The availability of powerful mobile computing devices, wireless networking products
and services is increasing dramatically. However internetworking protocols such as IP
used in the Internet do not currently support host movement. Mobile Internet Protocol is a
new recommended Internet Protocol designed to support the mobility of a user host. This
paper describes and summarizes the characteristics of the current Internet draft for
Mobile IP. In addition it also discusses alternative Mobile IP and it’s routing proposals so
that the reader may understand the different design issues associated with it. It also points
to some problems that may arise if the current draft were to be implemented and looks
and suggests at solutions, which may solve them.
 Introduction:
Mobility can be both with wireless and wired and conversely also. In all the four
combinations we notice that wired or wireless are Data Link Layer issues while Mobility
is a Network layer issue or in general a higher layer issue. Hence ‘mobility’ doesn’t
require wired or wireless hosts. Hence there is a need for introducing newer protocols
that can be used for internetworking with such mobile hosts. However this would require
a monumental task of upgrading and configuring a large number of routers and hosts.
Hence the designed protocols should be able to support incremental upgrades. This
means that it should be able to talk to both hosts that aren’t yet configured with it along
with the hosts, which are already upgraded. Mobile IP is most likely to be implemented
in some form or other in the future.
 Why Mobile IP?
IP version 4 (IPv4) assumes that a node’s IP address uniquely identifies the node’s point
of attachment to the internet. In order to provide a scalable routing support,
internetworking protocols use hierarchical addressing and routing schemes. Hence routers
within the internet need to know only how to route packets based on network number and
destination address in each packet and once the packet reaches that network, it is
delivered to the correct individual host on that network. Hence a node must be located on
the network indicated by its IP address in order to receive datagrams destined to it;
otherwise they would be lost. This sort of aggregation oat each level of hierarchy also
reduces the size of the routing tables that each of the routers maintain. However this
hierarchy in addressing and routing prevents packets from being routed correctly to the
mobile host when it is away from its home network. For a host to change its point of
attachment without losing its ability to communicate, currently one of the two following
mechanisms must typically be employed:
 Node must change its IP address whenever it changes its point of attachment.
 Host-specific routes must be propagated throughout the Internet routing
fabric.
We can see clearly that both of these alternatives are unacceptable. The first makes it
impossible for a node to maintain transport and higher-layer connections when the node
changes location. The second has obvious and severe scaling problems. Hence a new,
scalable, mechanism is required for accommodating node mobility within the Internet.
Mobile IP would have several features associated with it like:
 No geographical limitations: A user can take a palmtop or laptop computer
anywhere without losing the connection to the home network.
 No physical connection required: Mobile IP finds local IP routers and connects
automatically.
 Modifications to other routers and hosts are not required: Other than mobile
nodes/routers, the remaining routers and hosts will still use current IP. Mobile IP
leaves transport and higher protocols unaffected.
 No modifications to the current IP address and IP address format: The current IP
address and address format remains the same.
 Supports security: Authentication is performed to ensure that rights are being
protected.
 How does Mobile IP work?
Mobile IP is the cooperation of three separable mechanisms:
 Discovering the care-of address
 Registering the care-of address
 Tunneling to the care-of address

Discovering the Care of Address (COA)
Either Agent Advertising or Solicitation methods can find out the COA. Mobile IP
discovery does not modify the original fields of existing router advertisements but simply
extends them to associate mobility functions. Thus, router advertisements can carry
information about default routers, just as before, and in addition carry further information
about one or more care-of addresses. When the router advertisements are extended to also
contain the needed care-of address, they are known as agent advertisements. Home
agents (HA) and foreign agents (FA) typically broadcast agent advertisements at regular
intervals. If a mobile node needs to get a care-of address and does not wish to wait for the
periodic advertisement, the mobile node can broadcast or multicast a solicitation that will
be answered by any foreign agent or home agent that receives it. Home agents use agent
advertisements to make themselves known, even if they do not offer any care-of
addresses. However, it is not allowed to associate preferences to the various care-of
addresses in the router advertisement, as is the case with default routers. Thus, an agent
advertisement performs the following functions:
 Allows for the detection of mobility agents
 Lists one or more available care-of addresses
 Informs the mobile nodes bout special features provided by foreign agents, for
example, alternative encapsulation techniques.
 Lets mobile nodes determine the network number and status of their link to the
Internet and

Lets the mobile node know whether the agent is a home agent, a foreign agent, or
both, and therefore whether it is on its home network or a foreign network.
Mobile nodes use router solicitations to detect any change in the set of mobility agents
available at the current point of attachment. (In Mobile IP this is termed as agent
solicitation.) If advertisements are no longer detectable from a foreign agent that
previously had offered a care-of address to the mobile node, the mobile node should
presume that foreign agent is no longer within range of the mobile node’s network
interface. In this situation, the mobile node should begin to hunt for a new care-of
address, or possibly use a care-of address known from advertisements it is still receiving.
The mobile node may choose to wait for another advertisement if it has not received any
recently advertised care-of address, or it may send an agent solicitation.

Registering Care of Address
Once a mobile node has a care-of address, its home agent must find out about it. The
process begins when the mobile node, possibly with the assistance of a foreign agent,
sends a registration request with the care-of address information. When the home agent
receives this request, it adds the necessary information to its routing table, approves the
request, and sends a registration reply back to the mobile node. Registration requests
contain parameters and flags that characterize the tunnel through which the home agent
will deliver packets to the care-of address. When a home agent accepts the request, it
begins to associate the home address of the mobile node with the care-of address and
maintains this association until the registration lifetime expires. The triplet that contains
the home address, care-of address and registration lifetime is called a binding for the
mobile node. A registration request can be considered a binding update sent by the
mobile node.
The home agent must be certain registration was originated by the mobile node and not
by some other malicious node pretending to be the mobile node. A malicious node could
cause the home agent to alter its routing table with erroneous care-of address information,
and mobile node would be unreachable to all incoming communications from the
Internet. Hence there arose a need to authenticate registration information. To secure the
registration request, each request must contain unique data so that two different
registrations will in practical terms never have the same tokens. Otherwise, the protocol
would be susceptible to replay attacks, in which a malicious node could record valid
registrations for later replay, effectively disrupting the ability of the home agent to tunnel
to the current care-of address of the mobile node at that later time. To ensure this does not
happen, Mobile IP includes within the registration message a special identification field
that changes with every new registration. There are two main ways to make the
identification field unique.
One is to use a timestamp; then each new registration will have a later timestamp and
thus differ from previous registrations. The other is to cause the identification to be a
pseudorandom number; with enough bits of randomness, it is highly unlikely that two
independently chosen values for the identification field will be the same.
In Mobile IP foreign agents are mostly passive, relaying registration requests and replies
back and forth between the home agent and the mobile node, doing mostly what they are
told. The foreign agent also de-capsulate traffic from the home agent and forwards it to
the mobile node. It should be noted that the mobile node will have a layer 2 address and
not an IP address otherwise the foreign agent may again resend it to the home agent i.e.
the foreign would strip off the IP headers and then put it on say the Ethernet connected to
it and the mobile node would simply pick it up. It is quite possible for a bad foreign agent
to impersonate a real one and simply by following protocol and offering agent
advertisements to the mobile host. It could then refuse to de-capsulate the packets to the
mobile host after they are received. This is possible since foreign agents don’t have to
authenticate themselves to the mobile node.
Automatic home agent discovery – When the mobile node cannot contact its home agent,
Mobile IP has a mechanism that lets the mobile node try to register with another
unknown home agent on its home network. This method of automatic home agent
discovery works by using a broadcast IP address, instead of the home agents IP address as
the target for the registration request. When the broadcast packets gets to the home
network, other home agents on the network will send a rejection to the mobile node;
however, their rejection notice will contain their address for the mobile node to use in a
freshly attempted registration message. It is a directed broadcast that reaches only IP
nodes on the home network.

Tunneling to the Care of Address:
The default encapsulation mechanism that must be supported by all mobility agents using
Mobile IP is IP-within-IP. Using IP-within-IP, the home agent (tunnel source), inserts a
new IP header, or tunnel header, in front of the IP header of any datagram addressed to
the mobile node’s home address. The new tunnel header uses the mobile node’s care-of
address as the destination IP address, or tunnel destination. The tunnel source IP address
is the home agent, and the tunnel header uses 4 as the higher-level protocol number,
indicating that the next protocol header is again an IP header. In IP-within-IP the entire
original IP header is preserved as the first part of the payload of the tunnel header.
Therefore to recover the original packet, the foreign agent merely has to eliminate the
tunnel header and deliver the rest to the mobile node. Such routing tunnels need to be
implemented with care because advertising explicit host routes into the wide area routing
tables destroys routing scalability.
Sometimes the tunnel header uses protocol number 55 as the inner header. This happens
when the home agent uses minimal encapsulation instead of IP-within-IP. Processing for
the minimal encapsulation header is slightly more complicated than that for IP-within-IP,
because some of the information from the tunnel header is combined with the information
in the inner minimal encapsulation header to reconstitute the original IP header. On the
other hand, header overhead is reduced.
Mobile IP uses a home agent physically attached to the mobile host’s home network to
intercept and tunnel packets to the mobile host. Hence, packets undergo triangle routing,
which is often longer than the optimal unicast path. Moreover adding to this problem is
the widespread deployment of ingress filters (Border routers at the periphery of an administrative
domain carefully discarded datagrams that seem to emanate from an address external to the administrative
domain. This is known as Ingress Filtering) as a “Best Current Practice” to combat denial of
service attacks. With this mechanism, a router does not forward packets with a source
address foreign to the local network, which implies that a packet sent by a mobile host in
a foreign network with its source address set to its home address will not be forwarded.
The solution to this is to use reverse tunneling, which tunnels packets originating at the
mobile host first to the host’s home agent (using the host’s care of address as a source
address), then from there on to the destination using the home address as the source
address. Thus, routing anomalies occur in both directions.
 Enhancements and Proposals
Some recent and efficient proposals have suggested the design and implementation of an
end to end architecture for Internet host mobility using dynamic updates to the Domain
Name System (DNS) to track host location. In this the name updates are effected via the
secure DNS update protocol, while the TCP connection migration uses a novel set of
Migrate Options and provides a pure end system alternative to routing based approaches
such as Mobile IP.
We know that delivering data to a mobile host across a network address change without
disrupting existing connections can be tackled by introducing a level of indirection in the
routing system. This approach when taken deploys a home agent that intercepts packets
destined for a host currently away from its home network, and delivers it to the mobile
host via a foreign agent in the foreign network. It does not require any changes to the
fixed (correspondent) hosts in the Internet, but does require changing the underlying IP
substrate to affect this triangle routing, and an authentication protocol to ensure that a
malicious party does not hijack connections.
However there are many other applications wherein other hosts originate connections to a
mobile host and can benefit from both host location and hand-off support or where the
mobile host originates all connections which do not require host locations services but
can benefit from the handoff support and those where an application level retry suffices if
the network address changes unexpectedly during a short transaction, which need neither
to work well. In all of the above situations an end-to-end system can meet the goals,
Moreover in an end-to-end architecture the mobile host exercises explicit control over its
mobility node and hence the need for an additional third party viz. the home agent in the
packet routing is removed.
Some network layer mobility techniques attempt to handle host relocation in a completely
transparent fashion, hiding any changes in network structure from the end hosts while
many other approaches attempt to handle relocation at a higher level in the end host.
The current IETF standard (RFC 2002) for mobility support on the Internet provides
transparent support for host mobility by inserting a level of indirection into the routing
architecture.
An interesting approach to network layer mobility was proposed by Mysore and
Bharghavan wherein each mobile host is issued a permanent Class D IP multicast address
that can serve as a unique EID. If multicast were widely deployed, this is a promising
approach because a Class D EID has the benefit of being directly routable by the routing
infrastructure it removes the need for an explicit care of address. However, this scheme
requires a robust, scalable, and efficient multicast infrastructure for a large number of
sparse groups.
 Addressing:
The key to the scalability of the Internet architecture is that the IP address serves as a
routing locator, reflecting the addressee’s point of attachment in the network topology.
This enables aggregation based on address prefixes and allows routing to scale well.
Using Migrate TCP, the mobility architecture preserves this crucial property of Internet
addressing.
While IP addresses fundamentally denote a point of attachment in the Internet topology
and say nothing about the identity of the host that may be connected to that attachment
point, they have implicitly become associated with other properties as well. For example,
they are often used to specify security and access policies as in the case of ingress
filtering to alleviate denial of service attacks. The end-to-end architecture works without
violating this trust model and does not require any form of forward or reverse tunneling
to maintain seamless connectivity. In a foreign network, a mobile host uses a locally
obtained interface address valid in the foreign domain as its source address while
communicating with the other Internet hosts.
 TCP connection migration:
A new proposal is to have a Migrate TCP option, included in SYN segments, that
identifies a SYN packet as part of a previously established connection, rather than a
request for a new connection. This Migrate option contains a token that identifies a
previously established connection on the same destination address-port pair. The token is
negotiated during initial connection establishment through the use of Migrate Permitted
Option. After a successful token negotiation, TCP connections may be uniquely
identified by either their traditional source address, source port, destination address,
destination port tuple, or a new source address, token triple on each host.
A mobile host may restart a previously established TCP connection from a new address
by sending a special Migrate SYN packet that contains the token identifying the previous
connection. The fixed host will then resynchronize the connection with the mobile host at
the new end point. A migrated connection maintains the same control block and state
(with a different end point), including the sequence number space, so any necessary
retransmissions can be requested in the standard fashion. This also ensures that SACK
and any similar options continue to operate properly. Furthermore any options negotiated
on the initial SYN exchange remain in effect after connection migration, and need not be
resent in a Migrate SYN. Since SYN segments consume a byte in the TCP sequence
number in space, Migrate SYN’s are issued with the same sequence number as the last
transmitted byte of data. This results in two bytes of data in a migrated TCP connection
with the same sequence number (the new SYN and the previously transmitted actual
data), but this is not a problem since the Migrate SYN segment need never be explicitly
acknowledged. Any packet received from the fixed host by a migrating host at the mobile
host’s new address that has a sequence number in the appropriate window for the current
connection implicitly acknowledges the Migrate SYN. They can be needed in case it’s
useful to renegotiate a new maximum segment size (MSS) reflecting the properties of the
new path. All of the options negotiated on the initial SYN except the Migrate Permitted
Option need not be replicated in this or any subsequent migrations since they are always
in effect.
Securing the migration:: If an attacker can guess the sequence space being used by the
connection, it is possible to partially hijack TCP connections. With the Migrate options,
an attacker who can guess both the sequence space and the connection token can hijack
the connection completely. Furthermore, the ability to generate a Migrate SYN from
anywhere greatly increases the connection’s exposure. Hence care must be taken to
secure the connection token. The problem would be relatively easy to solve if IP security
(IPSec) were deployed. However it not being the case the authors suggests a non
guessable connection token that is secured with a secret connection key. Since any host
that obtains the connection key could fabricate the token and issue a Migrate request, the
authors [2] have proposed to select the key with an Elliptic Curve Diffie Hellman Key
exchange. Hosts using IPsec may choose to disable key negotiation to avoid excess
computation. ECDH is preferred over other methods because of its high security to bit
length ratio.
 Routing Issues:
Source Routing: As opposed to the way in which router optimization is specified in IPv4,
in IPv6 correspondent nodes do not tunnel packets to mobile nodes. Instead, they use
IPv6 routing headers, which implement a variation of IPv4’s source routing option. A
number of early proposals for supporting mobility in IPv4 specified a similar use of
source routing options, but two main problems precluded their use:
 IPv4 source routing options require the receiver of source-routed packets to
follow the reversed path to the sender back along the indicated intermediate
nodes. This means that malicious nodes using source routes from remote locations
within the Internet could impersonate other nodes, a problem exacerbated by the
lack of authentication protocols.
 Existing routers exhibit terrible performance when handling source routes.
Consequently, the results of deploying other protocols that use source routes have
not been favorable.
However the objections to the use of source routes do not apply to IPv6, because IPv6’s
specifications eliminate the need for source-route reversal and lets routers ignore options.
Consequently, correspondent nodes can use routing headers without penalty. This allows
the mobile node to easily determine when a correspondent node can use routing headers
without penalty. This allows the mobile node to easily determine when a correspondent
node does not have the right care-of address. Correspondent nodes that need to receive
binding updates from the mobile node must have sent packets delivered by encapsulation
instead of by source routes in a routing header. It is a further point of contrast to route
optimization in IPv4 that, in IPv6 mobility support, the mobile node delivers binding
updates to correspondent nodes instead of to the home agent. There is a distinct
possibility in IPv6 of the availability of key management between the mobile node and
correspondent node will be implemented. Other features supported by IPv6 mobility
include
 Coexistence with Internet Ingress filtering
 Smooth handoff, which in Mobile IPv4 is specified for foreign agents as part of
route optimization.
 Renumbering of home networks and
 Automatic home agent discovery.
Another way of routing for a mobile network that has been discussed is using a different
hierarchy, which can be dynamically configured as compared to the cluster hierarchy in
existence today. This is being termed as the ‘Landmark Hierarchy’. This has been shown
by the author to have similar path lengths and routing tables as compared to the
conventional area hierarchy. In this the routing known as ‘landmark routing’, a
distributed set of algorithms is used for the purpose. It has been shown to optimize
routing in very large networks as it dynamically configures the hierarchy on the fly
allowing for very large and highly dynamic networks. In this type of routing each router
has in its tables only those routers who are a certain number of hops away as compared to
a cluster hierarchy wherein all routers in one area have routing entries of all other routers.
This implies that each router has all information of local routes and information decreases
as we move away from it. A full description of the same is in [4].
Ad-Hoc Network Routing protocols are another way of routing. In this an ad-hoc
network, which is basically a collection of wireless mobile nodes, is formed dynamically
without use of any existing network infrastructure or centralized administration. It could
be particularly useful when used in areas where there is little or no communication
infrastructure. In such a network each mobile node not only acts as a host but also as a
router i.e. it forwards packets for other mobile nodes in the network that may not be in
direct wireless transmission of each other. Hence the packets would be ultimately
delivered via multiple hops.
 Security Issues:
As put in by Perkins and Johnson [2] “One of the most difficult aspects of Route
Optimization for Mobile IP in the Internet today is that of providing authentication for all
messages that affect the routing of datagrams to a mobile node.”
In IPv6 nodes are expected to implement strong authentication and encryption features to
improve Internet security. This affords a major simplification for IPv6 mobility support,
since all authentication procedures cane be assumed to exist when needed and do not
have to be specified in the Mobile IPv6 protocol. However the current draft on Mobile IP
yet specifies the use of authentication procedures as infrequently as possible on account
of two things. They are basically that performance is affected with a very reliable
authentication and hence it should be done infrequently and also the fact that questions
about the availability of Internet-wide key management are far from resolved as of now.
The issues are:
 Data Confidentiality: Is it possible for the attacker to monitor the confidential
traffic of other users of the system?
 Data Authenticity: Traffic/Identity hijacking: Is it possible for the attacker to
masquerade as a user? That is, to bypass the authentication and steal the identity
of another user.
 Service Availability: Denial of Service: Is it possible for the attacker to prevent
other users to use the services of the system?
 Signaling and Location Confidentiality: Is it possible for the attacker to monitor
the movements of the mobile host and/or collect user data about the behavior of
the user?
In each case the level of security depends on the algorithms and keys used for countering
the threat. The roles considered during the analysis were:
 Hostile mobile host or a host masquerading as a mobile host
 Hostile nodes in the serving network
 Hostile FA or a host masquerading as an FA.
 Hostile nodes in the home network
 Hostile HA or a host masquerading as an HA.
 Hostile nodes outside the home and serving networks.




Data Confidentiality: The likelihood that the confidentiality of the transmitted
packets will be compromised depends strongly on the route of the packets. Mobile IP
does not encrypt the packets, and thus the whole route of the packets has to be
trusted or IPSec should be used on these parts of the route. Another possibility as
discussed by authors would be to use token systems as shown in [2].
Inside visited network: It is very demanding to make IP based network secure at the
times of faulty TCP/IP protocols/applications. The need for additional encryption
depends on the level of trust the roaming user has for the visited network’s ability
and motivation to secure the network.
Between the visited and home network: The level of security on this part of the route
is very difficult to define. In practice IPSec tunneling should be used.
Inside the home network: In client-server applications and when the reverse
tunneling is used the route of the packets goes to the home network of the roaming
user.
In the scenario the mobile IP is an attractive target for a malicious host outside of
firewalls as it could allow connection hijacking. After successful registration Mobile IP
can be used to get around IP address based packet filters used in the firewalls. This
requires that the attackers can fool the mobility agents to accept the registration either
passing the mandatory authentication or finding a way to avoid it.
A malicious host might try to register to the HA as a roaming mobile host. This is
protected by the mandatory authentication of the register message (IPv4) and Binding
update (IPv6). The scenario where a HA in a secure network accepts mobile-IP
registrations originating outside the secure IP-network places very strict requirements on
the authentication algorithm and the key management. The authentication of the mobile
node by the FA is not mandatory in IPv4 Mobile-IP. A malicious host might try to
register to the FA as a roaming mobile host. This could allow traffic stealing if the real
host is roaming the same visited network. This could also be used for bypassing the
charging if the access is charged.
Malicious FA’s might try to attack the HA. Possible attack types against mobile-IP could
be replay attacks and attacks that lead to false authentication. The mobile-IP protocol
offers sufficient protection against these in the form of identification and authentication
extensions.
Reverse tunneling introduces additional threats: when using reverse tunneling the traffic
seems to originate from the safe side of the firewall i.e. from the home agent. The
legitimate use of Mobile IP can introduce problems with firewalls and IPSec Security
Gateways; reverse tunneling can be used to avoid these problems (with a price of unoptimized routing). Reverse tunneling can also be used for enforcing location
confidentiality.



Service availability: Service availability is difficult for both IP-based network and
wireless communications. The IP network can be flooded with techniques like SYNflooding with a non-existing source address, Domain Name Servers. TCP/IP stack of
the host can be crippled with an illegal IP packet received from the network. The
limited capacity of the system can be saturated.
Signaling and location confidentiality: Also the signaling information should be
tunneled when possible to prevent behavior information about the user to be
collected. The optimized routing can compromise location confidentiality.
The header information of the IP-packets can be used for tracking the mobile host,
unless IPSec is used in tunneling mode. This is another good reason for IPSec
tunneling all data through unsecured parts of the communication path.
 Other Changes in IPv6:
Features like Stateless Address Auto configuration and Neighbor discovery that are
missing in IPv4 are added in IPv6. It also attempts to simplify the process of
renumbering, which could be critical to the future routing ability of the Internet. Mobility
support in IPv6, as proposed by the Mobile IP working group, follows the design for
Mobile IPv4. It retains the ideas of a home network, home agent, and the use of
encapsulation to deliver packets from the home network to the mobile node’s current
point of attachment. While discovery of a care-of address is still required, a mobile node
can configure its care-of address by using Stateless Address Auto Configuration and
Neighbor Discovery. Thus, foreign agents are not required to support mobility in IPv6.
Moreover IPv6-within-IPv6 tunneling is also already specified.
 Complications and Possible Solutions:

Zigzag routing: If a mobile node happens to move to the same sub-network as its
correspondent node that wants to send it datagrams then what happens is that for the
datagram to be received by the mobile node, based on the Mobile IP protocol, the
correspondent node will send the datagram all the way to the mobile node’s home
agent which can be anywhere. Then its home agent will then forward the datagram to
its care-of address, which wastes time and network resources since the datagram
could have been sent directly from the correspondent node. This kind of “indirectrouting” is inefficient and undesirable.
A solution that can be done is to have some sort of binding between the mobile node
and the correspondent node wherein an effective way is maintained by the
correspondent node as to where the mobile node is. This would remove this indirect
routing as the correspondent node would then optimize the path and send it directly
to the foreign agent.

Frequent reporting incase mobile node moves very fast and frequently: If a mobile
host is in a moving vehicle and roaming around into neighboring communities, then,
the mobile IP will have to constantly report to the home agent to change it’s address.
This leads to degradation of the performance and delays the datagram transmission.
A solution maybe similar to what is being used in GSM wherein only when the cell
crosses cell boundaries and handoffs take place that it’s reported back to the home
agent. However for this to work in case of mobile hosts, it would require dividing the
whole area into a number of cell clusters. That would require quite a different
amount of routing protocols also.

Too many unwanted fields in “IP within IP”: We know that when the packets
(datagrams) are encapsulated the original datagram is put inside another IP datagram
where the whole packet is basically the IP header containing the care-of address and
the original datagram. The fields in the outer IP header add too much overhead to the
final datagram as several fields are duplicated from the inner IP header. This waste
of unnecessary space is uneconomical.
A solution proposed by IETF called the Minimal Encapsulation scheme is defined,
and becomes another way to encapsulate the datagram. The approach to the
encapsulation method is as follows: The original header is itself modified to point to
the care-of address rather than inserting another IP header. Now instead of decapsulating the datagram, the foreign agent will do a fair amount of computation
before it can be sent to the mobile host. This is the tradeoff with utilizing network
resources versus fast delivery of messages to the mobile host.

Ingress Filtering: Many border routers discard packets coming from within the
enterprise if the packets do not contain a source IP address configured for one of the
enterprise’s internal networks. Because mobile nodes would otherwise use their
home address as the source IP address of the packets they transmit, this presents
difficulty.
A solution to this problem in Mobile IPv4 would be tunnel outgoing packets from
the care-of address. However, then the difficulty is how to find a suitable target for
the tunneled packet from the mobile node. The only universally agreed routing
possibility is the home agent, but that target introduces yet another anomaly for
communications between the mobile node and the rest of the internet. The use of
reverse tunneling to the home agent to counter the restriction imposed by ingress
filtering can help. Mobile IPv6 also offers a solution in the home address destination
option.

Security Issues: Mobile IP has to co-exist with the security features that are in use
within the Internet like Firewalls. Firewalls cause difficulty for Mobile IP because
they block all incoming packets that do not meet specified criteria. Many firewalls
are typically configured to block packets from entering via the Internet, which appear
to emanate from internal computers. It presents difficulties for mobile nodes wishing
to communicate with other nodes within their home enterprise networks. Such
communications, originating from the mobile node, carry the mobile node’s home
address, and would thus be blocked by the firewall. A number of solutions are being
developed which could allow traversal of firewalls without lowering security.
 Conclusions:
Mobile IP is definitely going to be implemented sooner than later in spite of competing
tunneling protocols like the PPP based PPTP and L2TP. These protocols though offer
portability in operations and at best may be a short term solution to inter-network routing
of mobile hosts. However in the long run Mobile IP would be definitely required in some
form or the other with variety of solutions and fixes to the foreseen problems. It would in
all probability have to include incremental upgrades so as to allow time for the entire
protocol system to be upgraded. Moreover some sort of glitch less handoff from one
agent to the another should also be deployed so as to make sure that erroneous data is not
received or for that matter retransmissions don’t occur because of them since the amount
of mobile hosts is slated to increase exponentially creating an unprecedented situation of
number of retransmissions caused on account of handoffs. Ad-hoc routing schemes as
proposed can be implemented alongside so as to increase efficiency and scalability.
 Bibliography:
1. D. Johnson, Scalable Support for Transparent Mobile Host Internetworking, in
Mobile Computing, edited by T. Imielinski and H.Korth.
2. A.Snoeren and H. Balakrishnan, An End-to-End Approach to Host Mobility,
Proc. MOBICOM 2000.
3. J. Broch, D. Maltz, D. Johnson, Y-C. Hu, J. Jetcheva, A Performance Comparison
of Multi-Hop Wireless Ad Hoc Routing Protocols, Proc. ACM/IEEE MOBICOM,
Dallas, TX, August 1998.
4. P. Tsuchiya, The Landmark Hierarchy: A New Hierarchy for Routing in Very
Large Networks, Proc. SIGCOMM’88, pp. 35-42, Stanford, CA, August 1988.
5. RFC-2002 – IP Mobility Support.
6. C.E. Perkins, “Mobile IP: Design Principles and Practises.”
7. IETF Working Group on Mobile IP.