International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014

ISSN: 2231-2803 http://www.ijcttjournal.org Page331

IPv4 Mobility Support

Vattumilli Venkata Rajesh, MannamSai Vinod

Department of CSE, K.L.E.F (K.L.U),
Green Fields, Vaddeswaram.


Abstract: Mobile computing offers mobile users anytime,
anywhere bi-directional reliable access to the Internet.
Mobile IP as a network layer routing protocol has been
designed by the IETF (Internet Engineering Task Force) to
provide solutions to the requirements of mobile computing.
However, there are still many technical obstacles that must
be overcome before Mobile IP can be widely deployed.
Moreover, since mobility performance is the outcome of
the cooperation of different layers, merely focusing on the
network layer performance is not sufficient. In other
words, the operation of Mobile IP depends heavily on
lower layer mechanisms, and has direct implications on
upper layer performance.

Keywords---- home agent, foreign agent, mobile node,
dynamic host configuration protocol (DHCP), tunnelling,
home address.

I.INTRODUCTION

This chapter describes the Mobile IPv4 (MIPv4) protocol
mechanism, outlines its main problems and existing
enhancements, compares major Mobile IP handover
optimization algorithms, proposes two fast handover schemes,
and analyzes various factors that affect IP layer handover
performance by extensive simulations.

II. MOBILE IPv4 OVERVIEW
Mobility Support for IPv4 (RFC 3344 [1]), or MIPv4, is a
routing protocol standardized by the IETF (Internet
Engineering Task Force) to offer Internet mobility functions
for mobile hosts. It is designed based on the top of the current
IPv4 (Internet Protocol version 4) infrastructure, and no
modifications are required in existing fixed hosts and routers
that do not understand the protocol.

A. Protocol Design Requirements

To provide mobility solutions to the existing Internet
infrastructure is not simple. An IP address is usually associated
with a fixed network location, while mobile hosts must be
allowed to change their access location anytime in mobility
conditions. Moreover, an ongoing higher layer connection
does not allow changes of either the source or destination IP
address. In addition, many other issues (e.g. security and QoS)
arise as well to challenge the design of the Internet mobility
management protocol. Therefore, the following five baselines
are considered as the design requirements of the MIPv4
protocol according to [1]:

1. A mobile host must be able to continue its communications
with other Internet nodes after its access network changes,
without changing its original IP address.

2. Since it is impossible to require all the Internet nodes to
implement MIPv4, a mobile host must be able to communicate
with nodes that do not understand MIPv4.
3. In many cases, the link to which a mobile host directly
connects is a wireless link, which potentially is more
vulnerable to attacks by malicious hosts. MIPv4 is required not
to introduce new and more security menaces to the existing
IPv4 infrastructure.

4. Wireless links usually have a substantially lower bandwidth
than wired links, and therefore, the number of signaling
messages sent over wireless links should be minimized, and
the size of these messages should be kept as small as possible.

5. Due to the existence and development of various wired and
wireless access technologies, MIPv4 should be designed
completely independent of access link types.

B. Protocol Mechanism

In order to fulfill the design requirements mentioned in section
A, MIPv4 introduces two new network nodes called Home
Agent (HA) and Foreign Agent (FA), defines two types of IP
address called home address (HoA) and care-of address
(CoA), as well as clarifies the concepts of home network and
foreign network. HoA refers to a relatively long term IP
address assigned to a Mobile Node (MN), which remains
unchanged while the MN is moving. CoA refers to a second IP
address other than the HoA of an MN, which is associated
with the location of the current attachment point to the
Internet. The network with a network prefix matching that of
an MNs HoA is considered as the MNs home network, while
any networks other than a certain MNs home network are
considered as foreign networks. Specially, an HA is a router
on an MNs home network that delivers datagrams to the MN
when it is away fromhome, and maintains current location
information for the MN, while an FA is a router on an MNs
foreign network that provides routing services to the registered
MN. In addition, either an HA or an FA can be called a
Mobility Agent (MA).In general, MIPv4 combines three
relatively separate functions: agent discovery, registration, and
tunneling.

1) Agent Discovery: Agent discovery is the process of an
MN detecting an MA either on the home network or a foreign
network, which is quite similar to the ICMP Router Discovery
protocol [6] that is used by Internet nodes to detect routers.
An MN utilizes the agent discovery process to decide whether
International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page332

it is in the home network or a foreign network, check whether
a handover occurs, and obtain a new CoA if it decides to
register to a new foreign network. The basic operation of agent
discovery involves two types of messages: Agent
Advertisement and Agent Solicitation. The Agent
Advertisement message is sent by MAs periodically
announcing their presence on a link. On the other hand, the
Agent Solicitation message is sent by MNs to actively solicit
an MAs advertisement in the absence of periodic Agent
Advertisements expected. These two messages help MNs to
find an MA initially on startup and perform movement
detections in the case of handovers. On receipt of an Agent
Advertisement, an MN determines whether it is in its home
network or a foreign network. If the MN is in its home
network, it operates as normal without using any mobility
support functions. If it detects that it is located in a foreign
network or it has just returned home froma foreign network, a
registration process is needed.

2) Registration: Registration is the process by which an MN
notifies its HA of its current location of attachment to the
Internet. The registration process involves two messages,
Registration Request and Registration Reply. In a foreign
network, the MN first acquires a CoA from an FA or through
other address allocation mechanisms, such as DHCP (Dynamic
Host Configuration Protocol),1 and then it composes a
Registration Request message containing the obtained CoA
and sends it to the HA. After processing the Registration
Request, the HA returns a Registration Reply message to the
MN indicating the registration status. If the registration is
successful, the HA keeps a binding2 entry in its binding table
to associate the MNs current CoA with its HoA. In a special
case when the MN returns to its home network froma foreign
network, it sends a special Registration Request message (with
the CoA set to its HoA) to notify its HA of its return home.
This process is called de-registration, in which the HA also
returns a Registration Reply to indicate the de-registration
status, and deletes the binding entry for the MN.

3) Tunneling: Tunneling is a special routing strategy that
enables datagrams to reach an MN even when it is away from
home. In MIPv4, an MN is always recognized by its HoA.
When it is away fromhome and has successfully registered
with its HA, the HA is responsible for capturing all datagrams
destined for the MN and redirecting themto the MNs current
CoA. The tunneling techniques enable this datagram
redirection without changing the original IP datagrams. IP-in-
IP encapsulation [7] is the default tunneling scheme used by
MIPv4. The tunnel end point could be the MNs FA or the MN
itself, depending on the type of CoA the MN is using.1A CoA
obtained from an FA is called an FA CoA, while a CoA
obtained through a local address configuration mechanismis
called co-located CoA. 2A binding, or mobility binding, refers
to the association between an MNs home address and care-of
address.

C. Protocol Security Considerations

In MIPv4, registration messages must be authenticated in order
to prevent malicious nodes fromspuriously generating these
messages to embezzle mobility services or disorder the normal
routing of MIPv4. Three registration authentication extensions
are defined in MIPv4 for security considerations. They are:

Mobile-home authentication extension

Mobile-foreign authentication extension

Foreign-home authentication extension

In order to compose and verify these authentication extensions,
three mobility Security
Associations (SAs) are required:

Mobile-home (MN-HA) mobility SA

Mobile-foreign (MN-FA) mobility SA

Foreign-home (FA-HA) mobility SA

An SA is the combination containing both the necessary
cryptographic key information and a way to identify the
cryptographic transform. According to [8], these mobility SAs
are derived from the basic AAA (Authentication,
Authorization, and Accounting) SA shared between an MN
and its HA or home AAA server (AAAH).

D. Protocol Running Example

After the description of each individual mechanism, this
section gives a general review of the operations of MIPv4.
Suppose an MN originally stays in its home network, and then
moves to a foreign network, and finally returns to its home
network again:

1. MAs advertise their existence periodically on their
local network.

2. On receipt of an Agent Advertisement fromits HA,
the MN determines that it is in its
home network and operates like a fixed host.

3. When the MN moves to a foreign network, it
actively solicits Agent Advertisements by
sending Agent Solicitations or waits for a periodical
Agent Advertisement. The MN obtains an FA CoA
on receipt of an FA advertisement or a co-located
CoA through other address configuration
mechanisms such as DHCP.

4. The MN sends a Registration Request message with
its current CoA and the necessary authentication
extensions to its HA directly or via an FA.

5. On the assumption that the HA accepts the
Registration Request, it generates a Registration
Reply message to the MN as well as updating its
binding table for the MN.

6. When the MN receives the successful Registration
Reply, the registration process finishes.

International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page333

7. The HA starts to announce the availability of the
MN to other routers to intercept datagrams destined
for the MN.

8. The HA tunnels the intercepted datagrams to the MN
according to its binding table.

9. Encapsulated (tunneled) datagrams are decapsulated
(de-tunneled) by the FA or the MN itself, and finally
reach the MNs upper layers.
10. In normal cases, the MN sends datagrams directly to
its communicating nodes, or Correspondent Nodes
(CNs) without tunneling.
11. When the MN detects that it has returned home, it
de-registers with its HA and announces its
availability on its own.
12. The HA deletes the binding entry for the MN, and
stops tunneling datagrams destined for the MN.
13. Fromthen on, the MN acts as a normal host without
mobility support again.

In this way, MIPv4 completely hides the MNs mobility from
upper layer applications.


III. MAJOR PROBLEMS and ENHANCEMENTS of
MOBILE IPv4

Before MIPv4 can be widely deployed, there are still some
technical obstacles. This section discusses the main problems
facing MIPv4 and related enhancements.

A. Handover Problems and Enhancements

MIPv4 handovers may incur upper layer service disruptions,
and add to network traffic loads. Analyzing Mobile IP
handover and enhancing handover performance are among the
main objectives of this thesis. First, an outline of handover
problems and enhancements is given.

1) Handover Latency: In standard MIPv4, MNs are
required to register with their HA every time they change their
access subnet to the Internet in order for their future datagrams
to be routed properly. As a result, if an MNs current access
point is far fromits HA, or the links between themhave a long
delay, the registration process can be very slow because of the
long round trip time (RTT) for transmitting the registration
messages. In this case, a large number of packets are still
routed to the MNs previous access point before the HA
becomes aware of the new CoA and thus could be lost. The
packet losses could cause intolerable disruptions for real-time
services and severe performance deteriorations of upper layer
protocols, for example, TCP (Transport Control Protocol).

2) Handover Signaling: In wireless environments, frequent
changes of point of attachment could be inevitable, since MNs
may move fast, travelling across cells and subnets very
quickly. Even if an MN stays in the same location, overlapping
and shape changing of cells could also cause frequent
handovers between cells or subnets, for example, the cell
breathing[9] phenomenon or feature exists in CDMA (Code
Division Multiple Access) systems. Since registration
messages have to be relayed to the HA every time an MN
changes its access subnet, these frequent registrations could
easily become a burden for the network. Although MIPv4
provides a simultaneous binding[1] function for the HA to
simultaneously hold more than one binding entry for an MN to
reduce registration times when frequent handovers happen,
this scheme causes a copy of datagrams to be sent to each CoA
of the MN in the binding table, which also adds to the traffic
load of the network.

3) Macro-Mobility and Micro-Mobility: To address the
problems of the long handover latency and the large amount of
signaling traffic possibly caused by Mobile IP, many
hierarchical models have been proposed that the Internet is
separated into different administrative domains, and each
domain has at least one gateway router with special mobility
support functions connecting every node inside the domain
with the global network, for example, [10][11]. MNs moving
inside each administrative domain is called micro-mobility,
while MNs moving between different administrative domains
is called macro-mobility (Figure 1). The model can also be
extended to a multi-level hierarchy.

Generally, the domain where a certain MNs home network is
located is called the home domain, while a domain other than
the MNs home domain is called a foreign domain. When the
MN is in a foreign domain, this architecture provides the
possibility that in most cases the MNs movements are totally
transparent to its HA. That is, the location updates messages
caused by the MNs movements inside a domain are handled
by the gateway router of the domain without notifying the HA.
As a result, signaling messages are processed locally and do
not need to travel all the way back to the HA. Therefore the
handover latency is reduced and signaling traffic load is
limited inside the domain.


International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page334



Figure 1: Macro-Mobility and Micro-Mobility


4) Mobile IP Regional Registration: The partition of
macro-mobility and micro-mobility automatically brings
different types of mobility management. A number of micro-
mobility management protocols for IPv4 have arisen, among
which Mobile IP Regional Registration[10], which is also
called Hierarchical Mobile IPv4 (HMIPv4), is the most
promising one to be standardized by the IETF. In [10], a few
extensions are added to the original MIPv4 protocol to provide
regional registration functions. Specifically, two regional
registration messages are proposed (Regional Registration
Request and Regional Registration Reply) and two new
mobility entities are introduced: the Gateway Foreign Agent
(GFA) and Regional Foreign Agent (RFA). A GFA is a special
FA usually placed at the edge of an administrative domain
with a globally routable IP address. It is able to generate a
reply message in response to a request message for a regional
registration. An RFA is an FA with the capability of a GFA
located in a multi-level hierarchical system, which may be the
target of a request message for a regional registration. The
below figure 2 shows a typical network model for the Mobile
IP Regional Registration protocol.



Figure 2: Mobile IP Regional Registration protocol

When an MN first enters a foreign domain, it performs a
registration with its HA(home registration). The HA registers
the CoA of the MN. If the foreign domain supports regional
registrations, the CoA should be a globally routable address of
a GFA. When the MN changes its access FA under the same
GFA or RFA, it may performa regional registration addressed
to the GFA or RFA, which is transparent to the HA. Note that
if the regional registration destination is an RFA, the MNs
movement may even be transparent to the GFA and any higher
International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page335

level RFAs. Outside the domain, the GFAs address is still
thought of as the MNs CoA.


Datagrams destined for the MN are tunneled to the GFA first
by the HA. The GFA reroutes (de-capsulates and re-
encapsulates) themto the next level of the hierarchy towards
the MN, and thus repeat by each RFA in the hierarchy, until
the datagrams reach the MN. Datagrams fromthe MN are sent
directly to its CNs in normal cases.

5) Smooth Handover and Fast Handover: As mentioned
in Section 1, Mobile IP handovers incur a period of packet
misrouting to the previous CoA. In basic MIPv4, the misrouted
packets can only be retrieved by the higher layers re-
transmission mechanisms (if retransmissions are needed). The
number of the misrouted packets largely depends on the total
time required to complete a handover. Efforts have been made
by researchers to minimize the Mobile IP handover disruption.
In general, there are two categories of methods: smooth
handover and fast handover. Smooth handover and fast
handover are two different concepts. Smooth means the
number of packets lost caused by a handover should be none
or negligible. Fast means the period of performing a
handover should be as short as possible. However, these two
different concepts are linked. For example, a smooth handover
should be fast enough for any packet delays not to trigger
higher layers retransmissions or cause too much disruption for
delay sensitive services; a fast handover in turn makes the
handover smoother, and a fast handover scheme is usually
combined with a smooth handover scheme since some packet
loss can be inevitable under any fast handover scheme.

A great number of proposals have been brought forward with
regard to the Mobile IP fast and smooth handover issue. They
can be summarized into three basic approaches: tunnel-based
handover, multicast-based handover, and link layer assisted
handover. The link layer assisted handover solutions will be
introduced in chapter 5; only the IP layer solutions are
discussed in this section.

6) Tunnel-Based Handover : Tunnel-based handover
belongs to the smooth handover category. The basic operation
is to redirect misrouted packets fromthe previous MA to the
current MA of an MN. The Internet draft Route Optimization
in Mobile IP[12] provides a basic way to realize packet
redirections, in which the MN utilizes the Previous FA
Notification Extension (PFANE) in a Registration Request
message to guide its current FA to set up a tunnel with its
previous FA after a handover. Thus, the misrouted packets can
be retrieved fromthe previous FA.

Nevertheless, merely redirecting packets does not recover all
the lost packets in many cases. According to [12], the old FA
will only begin to redirect packets after it gets the defined
Binding Update message fromthe new FA. Therefore, those
misrouted packets coming before the Binding Update message
would never be retrieved.

A number of researchers proposed to use an FIFO (First In
First Out) buffer at each FA to save the most recent packets
destined for an MN(e.g.,[13]). FAs not only de-capsulate
tunneled packets and deliver themto the specific MN, but also
buffer these packets. When it receives a Binding Update
message for the MN from another FA, it re-tunnels the
buffered packets as well as any future packets destined for the
MN to the new FA. By this means, packet loss during a
handover can be completely eliminated if the buffer size is
large enough to accommodate all the incoming packets during
the period fromthe moment when the MN loses contact with
the old FA to the moment when the old FA gets a Binding
Update message for the MN. However, since this period can
be variable, there is a tradeoff when determining the optimal
buffer size. If the buffer size is made large enough to
guarantee that there is no packet loss during a handover, in
many cases some of the redirected buffered packets could have
already been received by the MN. As a result, a major side
effect of handing over buffered packets is packet duplication.
Duplicated packets area waste of the bandwidth resource
especially on wireless links, and they caused duplicated packet
acknowledgments so that the retransmission mechanisms of
upper layers (e.g. TCP) could be invoked.

7) Multicast-Based Handover: Multicast-based handover
belongs to the fast handover category. In fact, basic MIPv4
already offers an option to use the concept of multicast-based
handover. That is, an MN can set the S bit in its Registration
Request message to require its HA to provide the simultaneous
binding function[1] .The HA then copies the datagrams and
tunnels themto all the mobility bindings of the MN. In this
way, when the MN moves back to one of its previous FAs, it
will get its datagrams immediately. However, this is not quite
feasible, since the global network traffic load would
significantly increase if there were many MNs requesting the
simultaneous binding service. However, benefiting fromthe
partition of macro-mobility and micro-mobility, multicast-
based handover could work much better inside a domain,
because in this case all duplicated datagrams are kept inside
the domain without affecting other parts of the Internet. Since
usually an MN is not able to predict its next FA, merely using
simultaneous binding function can never guarantee fast
handovers. Consequently, a number of multicast-based
schemes have been proposed (for example, [14] and [15]), and
all of themmore or less rely on a certain mechanismof the
local network to provide multicast position information, so that
it can be guaranteed that the next FA of the MN has got the
multicast datagrams before the MN moves to its area. Note
that most of the multicast-based handover schemes also deploy
a buffer at each FA to smooth handovers. This is because an
MN needs time to switch its link layer connectivity fromthe
old FA to the new FA. During this time the incoming packets
can be stored in the new FAs buffer. The new FA then
forwards the buffered packets to the MN after the MN
connects to it. The deployment of buffers has the same side
effect as that in the tunnel-based approach. A comparison
between the tunnel-based approach and the multicast-based
approach is made in section 2.4 by showing the simulation
results on handover performance.

B. Triangle Routing and Route Optimization
As mentioned in section B of I, in standard MIPv4, datagrams
destined for an MN are always intercepted by its HA, and then
International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page336

tunneled to the current access location of the MN. However,
datagrams sent by the MN are forwarded directly to its CNs in
normal cases [1] . As a result, the triangle routing problem
arises (Figure 3). In this case, datagrams to the MN could be
routed along paths that are significantly longer than optimal,
especially when the MN is near its CNs but far fromits HA.

MIPv4 route optimization [12] has been proposed by Perkins
to address the triangle routing problem. The proposal provides
a means for CNs to maintain a binding cache for MNs for use
in tunneling datagrams directly to them, bypassing their HA.
In [12] four messages are defined to manage the binding cache
in CNs: Binding Warning, Binding Request, Binding Update
and Binding Acknowledgement. A Binding Warning message
is used to send a suggestion that a Binding Update is needed
by certain CNs or Fas. A Binding Request message is used to
send a request for the current mobility binding of an MN from
the MN or its HA. A Binding Update message is used to send
a notification of an MNs current mobility binding. A Binding
Acknowledge message is used to send a response to a Binding
Update message. Any node may utilize these four messages to
maintain a binding cache in order to optimize the routing of its
datagrams destined for an MN. The protocol details can be
referred to [12].

Obviously, in order to support the basic MIPv4 route
optimization scheme, CNs must be modified to understand the
protocol. Moreover, since the Binding Update message needs
to be authenticated to prevent it from introducing extra
security vulnerability, a preconfigured SA is needed between
an MNs HA and a CN. These cause great difficulties for this
scheme to be widely deployed.


Fig 3: Mobile IPv4 Triangle Routing

More recently, Vadali et al. designed an agent-based MIPv4
Optimization scheme [16], whose key idea is to introduce
Correspondent Agents (CAs) in networks to maintain binding
caches, and tunnel datagrams to MNs on behalf of each
individual CN (Figure 4). In this way, the route optimization
function is transparent to end nodes, and hence no
modifications are required in CNs. When multiple CNs in the
same subnet are communicating with an MN, only one
Binding Update message is required to be sent to the CA,
which reduces signaling traffics. Therefore, the agent-based
scheme is more easily deployable than the basic route
optimization extension for MIPv4. However, the security
challenge still exists since it is hard to guarantee that an MNs
HA shares an SA with any CA that the MN will communicate
with.


Figure 4: Mobile IPv4 Agent based Route Optimization

A new route optimization solution for MIPv4 is proposed,
which adapts the default Mobile IPv6 route optimization
scheme for MIPv4 based on the agent-based architecture.

C. Security Issues

The mobile computing environment is potentially more
vulnerable to attacks including passive eavesdropping, active


replay attacks, and Denial of Service (DoS) attacks, since in
most cases MNs are connected to the Internet via wireless
links and their movement results in changes of a datagrams
routing. As a result, security becomes one of the most
important problems facing Mobile IP.

In MIPv4, messages (e.g. Registration Request and Binding
Update) that affect the routing of IP datagrams must be
authenticated in order to prevent malicious nodes from
spuriously generating these messages to embezzle mobility
International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page337

services or disorder the normal routing of MIPv4.
Authentication extensions are defined to be carried by these
messages in order for the receiving nodes to performsecurity
checks on these messages [1] [2]. However, mobility SAs must
first be established before these authentication extensions can
be composed. Secure key distribution is the prerequisite to set
up an SA between two nodes, since a key is a secret number
shared only between authorized nodes, and is the basis of
deriving an SA. However, in basic MIPv4, only the manual
mobility SA configuration method is mandatory to be
supported by mobility entities [1], which brings difficulties for
MIPv4 to be widely deployed. Therefore, a more flexible SA
configuration method or key distribution method is necessary.

Fortunately, [17] standardized a dynamic key distribution
solution for MIPv4 registrations very recently, which is based
on the AAA infrastructures for MIPv4 defined in [8].
According to [8] the basic MIPv4 AAA infrastructure model is
shown in below figure 5.

Figure 5: Basic MIPv4 AAA Infrastructure Model


The model can be summarized as follows:

Each administrative domain has at least one AAA
server. The AAA server in a certain MNs home
domain is usually recognized as AAAH, while AAA
servers in the MNs foreign domain is usually
recognized as AAAF or AAAL.

Each MN shares an AAA SA (SA1) with its AAAH.
This is usually pre-configured and is approximately
what it means for the MN to belong to its home
network domain.

AAA servers in two different domains share a pre-
configured AAA SA (SA3).


All MAs share a pre-configured AAA SA (SA2 and
SA4) with their own AAA server(s).

With this AAA infrastructure, when an MN first enters into a
foreign domain, the following procedures are performed to
establish the required SAs: the MN-HA mobility SA, the MN-
FA mobility SA, and the FA-HA mobility SA, discussed in
section C.



1. The MN sends a Registration Request with its
identity6 to the FA.

2. The FA contacts with its local AAA authority
(AAAL or AAAF) to query the authorization to the
MN.


3. The AAAL invokes the used AAA protocol with the
MNs AAAH and waits for the approval by the
AAAH.

4. The AAAH checks the MNs credentials and
generates three keys: K1 (for the MN-FA mobility
SA), K2 (for the MN-HA mobility SA), and K3 (for
the FA-HA mobility SA).


5. The AAAH encrypts K1 and K2 using the AAA
SA1, K1 and K3 using the AAA SA3, and K2 and
K3 using the AAA SA2.

6. The AAAH relays the MNs registration
information, K2 and K3 to the HA.


International Journal of Computer Trends and Technology (IJCTT) volume 9 number 7 Mar 2014
ISSN: 2231-2803 http://www.ijcttjournal.org Page338

7. The HA decrypts K2 and K3 using the AAA SA2,
generates a Registration Reply and sends it back to
the AAAH.

8. The AAAH relays the Registration Reply, K1 and
K3 to the AAAL, and K1 and K2 to the MN.

9. The AAAL decrypts K1 and K3 using the AAA
SA3, re-encrypts themusing the AAA SA4, and
relays themand the Registration Reply to the FA.

10. The FA decrypts K1 and K3 using the AAA SA4,
checks the Registration Reply, and relays it to the
MN.

11. The MN decrypts K1 and K2 using the AAA SA1,
and checks the Registration Reply.

In this general way, the keys used to establish the required
mobility SAs can be distributed to the related mobility
entities securely. The detailed protocol for transferring key
materials fromthe home domain to the MN is described
[17], while the detailed methods for transferring key
materials from AAA servers to MAs depend on the specific
AAA infrastructure deployment. Moreover, whether to
combine or separate the MIPv4 registration messages with
the key distribution AAA messages should be
implementation dependent [8].

Note that the lifetime of the mobility SAs should be great
enough to be reused on subsequent registrations. This is to
decrease the frequency of contacting AAA servers for key
distributions, which may bring extra delays for registrations.
Obviously, combining MAs with AAA servers may reduce
registration latency when key distributions are involved.
Normally, AAA servers only need to be contacted when the
MN enters into a new administrative domain, or previous
mobility SAs are about to expire.


CONCLUSION
The larger the overlap area is, the smoother a
handover could be, however in reality, the
more severe the signal interference could be.

The larger the effective overlap area is, the
higher the speed of the MN can be
accommodated.
The shorter the Agent Advertisement interval
is, the smoother a handover could be,
however in practice, the more wireless
bandwidth is consumed, which may in turn
cause performance degradation.

The longer the data packet interval, the fewer
the packets lost during a handover.

REFERENCES
[1] C. Perkins, IP Mobility Support for I Pv4, RFC 3344, August
2002.
[2] D. J ohnson, C. Perkins, and J . Arkko, Mobility Support in
IPv6, RFC 3775,J une2004.
[3] ANSI/IEEE Std 802.11 1999 Edition, Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, 1999.
[4] M. Liebsch, A. Singh, H. Chaskar, D. Funato, and E. Shim,
CandidateAccess Router Discovery, RFC 4066, J uly 2005.
[5] K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168,
September 2001.
[6] S. Deering, ICMP Router Discovery Messages, RFC 1256,
September 1991.
[7] C. Perkins, IP Encapsulation within IP, RFC 2003, October
1996.
[8] S. Glass, T. Hiller, S. J acobs, and C. Perkins, Mobile IP
Authentication, Authorization, and Accounting Requirements,
RFC 2977, October 2000.
[9] A. J alali, On cell breathing in CDMA networks, in
Proceedings of IEEE ICC,J une1998.
[10] E. Gustafson, A. J onson, and C. Perkins, Mobile IPv4
Regional Registration, draft-ietf-mobileip-reg-tunnel-09.txt, J une
2004.
[11] T. Campbell, Gomez. J ., S. Kim, A. Valko, C. Wan, and R.
Turanyi, Design, implementation, and evaluation of cellular I P,
IEEE Personal Communications, August 2000.
[12] C. Perkins and D. J ohnson, RouteOptimization in MobileI P,
draft-ietfmobileip-optim-11.txt, September 2001.
[13] M. Khalil, H. Akhtar, E. Qaddoura, C. Perkins, and A. Cerpa,
Buffer Management for MobileI P, draft-mkhalil-mobileip-buffer-
00.txt, October 1999.
[14] M. Ergen, S. Coleri, B. Dundar, A. Puri, J . Walrand, and P.
Varaiya, Position Leverage Smooth Handover Algorithm for
Mobile IP, in Proceedings of IEEE ICN, August 2002.
[15] C. Tan, S. Pink, and K. Lye, A Fast Handoff Scheme for
Wireless Networks, in Proceedings of ACM/IEEE WoW-MoM,
August 1999.
[16] R. Vadali, J . Li, Y. Wu, and G. Cao, Agent-Based Route
Optimization for MobileIP, in Proceedings of IEEE VTC, October
2001, pp. 27312735.
[17] C. Perkins and P. Calhoun, Authentication, Authorization, and
Accounting (AAA) Registration Keys for MobileIPv4, RFC 3957,
March 2005.