A Comparison Between Mobile IPv4 and Mobile IPv6

25.5.2000

Sami Kivisaari
Department of Computer Science and Engineering
Helsinki University of Technology
skivisaa@cc.hut.fi

Abstract

Mobile networking is becoming increasingly popular but the underlying IP technology has built-in restrictions which impose barriers for mobility. There, however, exist technologies which can be used to overcome these problems. This paper gives a brief overview of mobile IPv4 standard and mobile IPv6 proposed standard which are strong and scalable solutions for the mobility problem. A comparison between the two protocols and a brief analysis of their suitability to mobile ad-hoc networking is also presented.


Contents

1 Introduction
1.1 Motivation for mobility
1.2 Mobility problem in IP networks
1.3 Mobility solutions
2 Mobile IPv4
2.1 Overview of mobile IPv4
2.2 Assumptions and requirements behind mobile IPv4
2.3 Movement detection and locating mobility agents
2.4 Registration procedures
2.5 Data Delivery
3. Extensions for mobile IPv4
3.1 Route optimization
3.2 Hierarchical tunneling
3.3 Reverse tunneling
4 New features in IPv6
4.1 Addressing architecture
4.2 Extension headers
4.3 Node configuration
4.4 Fragmentation and reassembly
5 Mobile IPv6
5.1 Overview of mobile IPv6
5.2 New destination options for IPv6
5.3 Registering and deregistering care-of addresses
5.4 Movement detection and new care-of address formation
5.5 Renumbering the home subnet
5.6 Dynamic home agent discovery
5.7 Modifications required for IPv6 specifications
6. Security in mobile IPv4 and mobile IPv6
6.1 Threats caused by mobile communications
6.2 Mobile IPv4 security
6.3 Mobile IPv6 security and IPSec
7. Performance aspects
7.1 Mobile IPv4
7.2 Mobile IPv6
8. Mobile ad-hoc networking considerations

9. Conclusions

References

Further information
 



 

 1 Introduction

1.1 Motivation for mobility

The number of hosts connected to the Internet is growing at increasing speed and in the future it is expected that increasing number of these devices will be wireless and hence mobile in nature.  The range of potentially mobile hosts may include laptop computers, digital cellular phones, personal digital assistants (PDAs) and many other classes of devices.

There are, however, problems with the IP protocol regarding to mobility.  The hosts cannot arbitrarily change their point of attachment in the Internet but can only move transparently, at the IP protocol level, within the subnet they are connected to.  Change between subnets will break any connections that were present in the previous subnet.  The problem gets worse if we consider the future high-speed cellular networks where the cell size is much smaller than in current cellular networks [1]. The decreased cell size is likely to result in increased amount of subnet switchings for the mobile host and thus increased amount of broken connections. For the IP to be feasible solution in such networks, the mobility must be somehow taken into account at the protocol level.

1.2 Mobility problem in IP networks

The IP address consists of two parts: the subnet identifier and the interface identifier.  The interface identifier identifies a single interface within an IP subnet and does not take part in routing process.  The subnet identifier, on the other hand,  identifies an individual subnet within the internetwork and is controlling the routing between different subnets.  All datagrams that share the same subnet identifier are routed to the same subnet.  From this property it follows that if a node changes its point of attachment to a foreign subnet, i.e. moves, the packets intended to it will be lost because they are routed to the wrong subnet.

There are basically two solutions for making the moved node able to receive packets again.  First is to simply change the IP address of the moved node to a valid address in the new subnet and the second is to propagate host specific routes throughout much of the Internet routing fabric.  From the mobility point of view, these are both bad ideas as the first one forces the transport level connections to be broken each time the node moves and the other has severe scalability problems [2].

In addition to the fact that a node that has moved to a foreign network is unable to receive any packets, there also exist some less fundamental problems. If the node in a foreign subnet tries to send packets using its home address, the packets will be automatically equipped with topologically incorrect source addresses. While the IP protocol does not explicitly forbid this, the intermediate routers will often discard such packets (ingress filtering [3]) and the node will not even be able to get all the sent packets through either.

The problems mentioned above make it practically impossible for a node to move in a bare IP network.  To overcome these problems, a mobility support protocol must be used.

1.3 Mobility solutions

The mobile IPv4 and mobile IPv6 are currently the most complete and extensive solutions to IP level mobility problem.  The mobile IPv4 and mobile IPv6 define mechanisms for the most important mobility related  procedures such as movement detection, data delivery and tunnel management.  There, however, also exist other kinds of protocols which address only smaller subset of these problems and can be used to achieve portability but not transparent mobility.  Two such protocols are layer two tunneling protocol (L2TP) [4] and point to point tunneling protocol (PPTP) [5].

The L2TP and PPTP are point to point protocol (PPP) variants which can be used to support mobility by creating tunnels from the home subnet of the mobile node to the current foreign subnet of the mobile node.  These protocols do not address movement detection nor tunnel management and hence their use is likely to require some amount of user intervention whenever movement takes place.

The mobile IP protocols do not address just data delivery but a wider range of issues.  It is possible to integrate the mobile IP and other tunneling protocols by extending the supported tunneling types of mobile IP.  Mobile IPv4 and mobile IPv6 usually use IP within IP [6,7] encapsulation for tunneling although for mobile IPv4, other tunneling types are defined [2].
 

2 Mobile IPv4

2.1 Overview of mobile IPv4

In mobile IPv4 the mobile node resolves the problem of being reachable in a foreign subnet by acquiring a new IP address, called a care-of address, each time it moves into a new foreign subnet.  The care-of address is an address from the current foreign subnet and is thus topologically correct.  Although changing to use such address generally would break the open transport level connections, the mobile IPv4 protocol is used to hide such details from higher protocol layers.  The mobile node still keeps its home address and could be thought of actually having two IP addresses bound to a single interface.

Mobile IPv4 involves two kinds of mobility agents that are used in order to achieve the transparent mobility.  These agents are the home agent and the foreign agent.  At least one home agent is required to be present in the home subnet of the mobile node.  Foreign agents are not necessary but usually one or more foreign agents are present in the foreign subnets.  The agents periodically advertise their presence by broadcasting agent advertisements in their local subnets.  Figure 2.1.1 shows the data delivery mechanism of the protocol.

The mobile IPv4 uses the well-known UDP port 434 for communications between protocol parties.  The protocol also uses ICMP router advertisement and ICMP router solicitation message format extensions for mobility agent advertisements.  The mobile IPv4 protocol specification is described in RFC 2002 [2].

Figure 2.1.1 Data delivery mechanism of mobile IPv4 protocol (with foreign agents)

2.1.1 Home agents

A home agent keeps a list of registered mobile nodes.  The registrations are called bindings and are defined as triplet (home address, care-of address, lifetime).  A binding holds an association between the permanent local home address and a temporary foreign address and is valid only for a given period of time.  The home agent intercepts the packets destined for home addresses that it has a binding for and tunnels them to their corresponding care-of addresses.  A mobile node may at any time update its associated binding and thus cause the packets to be tunneled into another foreign subnet.

To make the packet interception possible, the home agent performs proxy ARP [2] for each of the home addresses that it has a binding.  The proxy ARP is not, however, always necessary because home agents also act as routers and can hence receive, as a part of the normal routing function, the packets to be intercepted.
In the special case where correspondent node and mobile node are in the same foreign subnet, the home agent is not required to forward datagrams to mobile node.  The correspondent node can instead send the datagram directly to mobile node because no routing is involved.

2.1.2 Foreign agents

Presence of foreign agent is not a strict requirement of the protocol but having one simplifies address space allocation within foreign sites.  A foreign agent acts as a router for the mobile node while it is visiting a foreign subnet.  The foreign agent holds one or more care-of addresses that are used for all of its mobile nodes.  The foreign agent decapsulates the tunneled packets sent to the care-of address and forwards them to the mobile node in the foreign network.  The foreign agent is generally expected to have a common link with the mobile node, hence the foreign agent simply sends the decapsulated datagram to the mobile node although it contains a topologically incorrect source address.  This is possible because no routing is involved.   The foreign agent also acts as a proxy between the mobile node and the home agent in the registration process.

Alternatively, instead of using foreign agent care-of address, the mobile node may use a co-located care-of address that is usually obtained via some dynamic assignment protocol such as DHCP [15] in the foreign network.  When a mobile node is using a co-located care-of address, no foreign agents are involved.  The mobile node performs the decapsulation and communication between the home agent and itself.  The use of co-located care-of addresses improves the performance of the protocol but poses some problems concerning address allocation within the foreign network.  This is because the foreign site must hold a pool of free care-of addresses that are available for mobile nodes.

2.1.3 Mobile nodes

The circle encloses when we study the functioning of the mobile node.  A mobile node uses the received agent advertisements to determine whether it is on the home subnet or in a foreign subnet and to find out whether it has moved to a new subnet.  Each time the mobile node detects that it has moved to another subnet, it acquires a new care-of address and sends a message called registration request to its home agent.  The home agent then changes the binding it has for this mobile node and starts tunneling the packets to the new care-of address.

A special case is when the mobile node returns to its home subnet from a foreign network. The mobile node then sends a message to the home agent, asking to destroy its binding.  The home agent then removes the binding, stops tunneling the packets destined to mobile node and stops performing proxy ARP for the mobile node.  Since the mobile node is in its home network, it can itself answer to ARP requests and can normally receive the packets destined to its home address.

2.2 Assumptions and requirements behind mobile IPv4

According to mobile IPv4 specification [2], there are four more or less fundamental requirements for mobile IPv4.  The mobility must be transparent to users of transport and higher level protocol layers and the protocol must be secured against remote redirection attacks.  Further, no additional constraints on IP address assignment are allowed and mobile IPv4 must not require protocol enhancements on any hosts or routers that are not any of the mobile IPv4 functional entities, that is HA, MN or FA.  The first two requirements have to do with the usefulness of the protocol itself and the latter ones with the feasibility of widespread deployment of the protocol.

The mobile IPv4 specification [2] states two assumptions that have formed the basis for the design of mobile IPv4.  The first assumption places an upper bound for the rate that a mobile node may change its point of attachment in the Internet.  The rate is specified to be at most once per second.

The second assumption is that IP unicast datagrams are routed solely based on the destination address in the datagram header.  The assumption is not, however, entirely valid.  Many IP routers perform so called ingress filtering [3] to drop any packets that are emanating from topologically incorrect source addresses.  The purpose of ingress filtering is to thwart attacks based on forged source addresses in IP packets.  This, however, implies that if such filtering takes place, the mobile node is unable to send packets to its correspondent nodes.

2.3 Movement detection and locating mobility agents

2.3.1 Locating mobility agents

In mobile IPv4, the mobility agents periodically broadcast ICMP router advertisement messages which contain an agent advertisement extension.  The format for agent advertisement extension is shown in Figure 2.3.1.1.

Figure 2.3.1.1 Agent advertisement extension format

Each advertisement has a unique sequence number that identifies the advertisement sent. The bitfield within agent advertisement contains information of whether the advertising mobility agent is a home or a foreign agent or both, as well as information about the supported encapsulation mechanisms.  The most common encapsulation is IP within IP in which an envelope IP datagram contains another IP datagram as payload [6].

The registration lifetime tells the maximum time in seconds that the mobility agent is willing to grant registrations, 0xffff meaning infinity.  If the advertising agent is a foreign agent, the last field contains one or more care-of addresses.  These are the foreign agent care-of addresses that the mobile nodes within that foreign network can use to register bindings to their home agents.

2.3.2 Movement detection

The mobile nodes continuously listen for agent advertisements.  The mobile IPv4 specification [2] specifies two algorithms that a node may use to detect movement.  Both of the algorithms are based on listening agent advertisements.

In the first algorithm the mobile nodes record the lifetimes for each source that they get agent advertisements from.  The lifetimes are updated each time when new advertisements arrive.  If the mobile node notices that lifetime for its current mobility agent has expired, it must assume that it has lost contact with it.  In that case, the mobile node is free to try registering with any other agent that it has a valid lifetime for.

The second algorithm detects the movement from network prefixes carried in received agent advertisement messages.  The agent advertisements must contain prefix-length extension [2] for the necessary prefix information to be available.  Prefix-lengths extension describes the prefix length in bits for each of the care-of addresses contained in the agent advertisement.  When receiving agent advertisements, the mobile node compares whether it is getting the same network prefix as in the previous advertisements.  If it notices that the network prefixes received in the advertisements have changed, it may assume that it has moved.

The mobile node may assume that it has returned home when it receives an agent advertisement from its own home agent.  The mobile node should then update its routing tables for the home network and deregister with its home agent.

2.4 Registration procedures

Once a mobile node has detected that it has moved, it must inform its home agent about its new location.  Otherwise, the home agent is unable to tunnel the packets to the mobile node.  The registration process can be carried out in two ways depending on whether a foreign agent is used or not.

When the mobile decides to register its new binding, it sends a registration request message to its home agent.  If the mobile node is using a co-located care-of address and none of the received agent advertisements contained 'R'-bit (registration required), it can send the registration directly to the home agent.  Otherwise, if the mobile node is using a foreign agent care-of address it must instead send the registration to its foreign agent which shall process it and forward it to the home agent.  If the 'R'-bit in agent advertisement was set and the mobile node is using a co-located care-of address, it is recommended but not mandatory that the registration is sent via foreign agent.  Figure 2.4.1 illustrates the registration request message.

Figure 2.4.1 Registration request message format

The registration request contains fields for the home address, the care-of address, and the preferred lifetime of the binding.  These are the necessary values to form a valid binding triplet.  The lifetime has two special values.  The value of 0x0000 indicates a deregistration request and 0xffff infinite lifetime.  Additionally, the request contains the address of the home agent, various flags and the identification field.  Identification is used to distinguish different registration requests and to provide help in authentication.  The registration request can contain extensions after the actual message.  The most common of them being the authentication extension which is discussed in Section 6.2.

When a registration request is received, the home agent processes the request and sends back a registration reply.  The home agent can either accept or deny the registration.  If the registration request was sent via a foreign agent, the home agent sends the registration reply also via the foreign agent which, upon receipt, processes the reply and forwards it to the mobile node. Otherwise, the registration reply is sent directly back to the mobile node.  Figure 2.4.2 illustrates the registration reply message.

Figure 2.4.2 Registration reply message format

The registration reply contains a code field which tells whether the registration succeeded or failed.  Other fields are the lifetime field, the home address of the mobile node, the home agent address of the mobile node, and the identification field.  The lifetime is not necessarily the same as in the request and has the same special values as in registration request.  If the code field indicated a registration failure, the lifetime field is generally unspecified and should not be processed.  The semantics for the other fields are as in registration request.

2.5 Data delivery

In mobile IPv4, all packets destined to a mobile node pass through the mobile node's home agent unless the mobile node is at home.  The datagrams are routed from correspondent nodes to the mobile node's home network by the standard IPv4 routing mechanisms.  If the mobile node is at a foreign network, the mobile node's home agent intercepts the datagrams and tunnels them into the care-of address indicated by the mobile node's binding.

The care-of address can be a foreign agent care-of address or a co-located care-of address.  In the former case, the tunnel ends at the foreign agent which performs the decapsulation of the datagram.  As the mobile node is present in the same subnet as the foreign agent, the foreign agent just sends the decapsulated packet normally to the mobile node.  In case of a co-located care-of address, the mobile node itself does the decapsulation and loops back the decapsulated packet to itself.

The plain mobile IPv4 assumes that source address of IPv4 header does not affect routing.  If the mobile node sends a datagram, it does it exactly as if it were in its home subnet.  If the assumption is valid, the datagram gets routed to the destination address in the IPv4 header.
 

3 Extensions for mobile IPv4

3.1 Route optimization

Examination of the basic mobile IPv4 protocol reveals a serious drawback concerning the performance of the protocol.  All packets sent by the correspondent node are always routed first to the mobile node's home network where they are intercepted by the mobile node's home agent and subsequently tunneled to the foreign network that the mobile node currently resides in.  This condition is called "triangle routing".  Triangle routing generally introduces increased delay for the packets sent by the correspondent node and also places a heavy load on the home agent which has to forward all packets sent by a correspondent node to the corresponding mobile node.

Route optimization is an extension to mobile IPv4 rather than a fundamental part of it.  It calls for modifications to the correspondent nodes by equipping them with a binding cache.  Each time a mobile node detects that the correspondent node is unaware of its location, it sends the correspondent node a binding update.  The correspondent node then stores the binding update in its binding cache.  If a correspondent node has a binding for some mobile node's home address in its binding cache, it can send the datagram directly to the care-of address, thus circumventing the triangle routing problem.  The route optimization for mobile IPv4 is described in an Internet Draft [8].
 

3.2 Hierarchical tunneling

If the mobile node's home agent is geographically far away and the handoffs are frequent, it may become burdensome to have the home agent approve all registrations of new care-of addresses. Hierarchical tunneling is another extension to mobile IPv4 which allows the foreign agents to co-operate in hierarchical manner and relieve the problem described above.

In hierarchical tunneling, the foreign agents form a tree-like hierarchy within some area, call it a site.  A site is controlled by one foreign agent which has varying number of subordinate foreign agents, the subordinate foreign agents may have subordinates of their own.  If packets destined to the mobile node are coming outside the site, they are first routed to the main foreign agent, then to the subordinate in whose region the mobile node currently resides and so further.  If a mobile node moves within a site, from one subnet to a neighboring subnet, it is only be necessary to inform lower level foreign agents of this.  The higher level foreign agents and the home agent see no difference and hence need not know.

Establishment of these kind of hierarchies allows regionalized tunnel management and in some cases, increased performance and fault tolerance to the protocol. Proposals of hierarchical tunneling are described at least in Internet Drafts [9, 10].

3.3 Reverse tunneling

Increasing number of firewalls are being deployed within the Internet as a solution to an array of data security problems.  One of these problems being attackers who carry out attacks based on spoofed source addresses.  The ingress filtering approach causes the routers to drop all data packets that are equipped with a topologically incorrect source addresses.  This causes the basic assumption of routing being independent of source address to become obsolete.

Reverse tunneling involves tunneling all packets sent by the mobile node back to its home agent through its foreign agent rather than simply sending them from the foreign network and relying in standard internet routing mechanisms.  As the home agent decapsulates the tunneled datagrams in the mobile node's home subnet and sends them to their final recipient, the packets seem to emanate from the correct subnet and they are routed to their destination without hassle.

The reverse tunneling increases the load imposed on the home agent and the foreign agent as well as delay for the outgoing packets.  However, in some cases the use of reverse tunneling can become a necessity despite the increased overhead.  The reverse tunneling extension is described in RFC 2344 [11].
 

4 New features in IPv6

IPv6 [12, 13] introduces many new features and improvements over IPv4, the most obvious one of them being the larger address space.  There, however, also exists more profound improvements.

4.1 Addressing architecture

The addressing architecture in IPv6 is quite different from IPv4.  First of all, as IPv6 addresses are 128 bits long, the address space is 2^96 times larger than in IPv4.  The large address space makes it possible to even wastefully assign the addresses and allocate large blocks of address space for specific purposes.  This has positive implications on mobility since care-of addresses can be more easily obtained.

IPv6 recognizes the following address types: unicast, anycast, and multicast.  Unicast as a destination address specifies a single host in a given subnet to which the datagram is to be routed.  Anycast identifies a group of machines which reside in the same subnet but in such sense that only one of the members of the group gets the datagram.  The recipient of the datagram is unspecified and depends on the routing mechanism.  The last address type is multicast address which functions the same way as in IPv4.  Hosts can subscribe and unsubscribe to groups using the IGMP protocol and the packets will be routed to all subscribers.  The IPv6 does not support broadcasting as IPv4, however, multicast and broadcast can be both considered as special case of the other.

The unicast addresses are also given scope in the IPv6 addressing architecture [14].  The addresses can be any of the following scopes: link local, site local, or global.  Link local addresses are guaranteed to be unique within the link in which they are formed, they are used for communicating with neighbor machines and are not routed to foreign networks.  Site local addresses are unique within a given site whereas global addresses are globally unique.

4.2 Extension headers

IPv4 datagrams are extensible due to the variable length nature of the header.  The IPv4 header contains a header length field which allows an IPv4 header to be from 5 to 32  four-byte words long.  If the header is longer than 5 four-byte words, the rest of the datagram contains option data.  The scope of this kind of extensibility is, however, rather limited due to the fact that the slack in header size is very small.

IPv6 introduces a new mechanism for extending the protocol.  In IPv6, the header is of fixed length but contains a field called next header telling which extension header follows the IPv6 header.  The extension headers also have a similar field to indicate what extension header comes after them.  The mechanism is extremely flexible since new extensions to the protocol can be made by simply declaring new extension header types.  Currently, following extension headers are defined

The IPv6 supports IPv4-style options but allocates dedicated headers for them.  These are the hop-by-hop options header and the destination options header.  Hop-by-hop options are processed at each node the datagram passes through during routing.  The destination options are only processed at the ultimate recipient of the datagram.  The rationale behind including a separate destination option and hop-by-hop option headers to IPv6 was the conservation of extension header enumeration space and the fact that if a node would not understand a specific extension header it would have to discard the whole packet.  If a node does not understand a destination option it may, in some cases, just ignore it without dropping the whole packet.  The handling of unrecognized destination options is mandated by the two highest bits of the destination option code.

4.3 Node configuration

The IPv6 contains many plug'n'play style mechanisms for node configuration.  In IPv6 the nodes are automatically equipped with link-local addresses after they have been booted.  The link-local address enables the node to communicate with other nodes in the same link thus obsoleting the need for mechanisms such as RARP, BOOTP, or DHCP [15] for acquiring initial addresses.  Link-local addresses are acquired by a mechanism called stateless address autoconfiguration [16] which is equivalent to concatenating the media access control (MAC) address of the node's interface with some prefix information.

The IPv6 nodes may send ICMPv6 neighbor solicitation messages to the links they are attached. The recipient IPv6 nodes in the same link reply by ICMPv6 neighbor advertisement message.  The neighbor advertisement holds the link-local and MAC addresses for the neighbor node.  This mechanism is roughly equivalent to the ARP functionality of IPv4 and is a part of larger mechanism called IPv6 neighbor discovery [17].

The IPv6 routers periodically send ICMPv6 router advertisements.  The router advertisements allow nodes to obtain the MAC address of the advertising router so that they can become able to communicate with it.  The router advertisements also contain information of the link's network prefix which in turn provides the nodes with the capability to form site-local addresses.

4.4 Fragmentation and reassembly

IPv6 uses a different fragmentation policy than IPv4.  In IPv4 fragmentation occurs each time when the sending node or a forwarding node is unable to forward a datagram to a specific link due to too small maximum transfer unit (MTU) in that link.  The node then breaks the datagrams into fragments that do not exceed the MTU in that link and forward the individual fragments to be routed to the final destination.  The IPv4 header itself also contains flags and fields for controlling the fragmentation [15].

In IPv6 the routers do not perform fragmentation.  Instead, the sender should perform path-MTU-discovery [18] to find out the path-MTU (PMTU) of the route.  PMTU is the least MTU of all links along the route.  If the datagram to be sent exceeds the PMTU, the sender breaks the datagram into fragments not exceeding the PMTU and appends a fragmentation header into each of the fragments.  The fragmentation header contains the necessary fields to reassemble the fragments in the receiving end and distantly resembles the fragmentation control fields in IPv4 header.  If an IPv6 router, however, receives a datagram that exceeds the MTU of the next hop, it drops the datagram and sends an ICMP packet too big message back to the sender.

The fragmentation policy of IPv6 is not as flexible as IPv4's but it is rather optimized for performance.  It has been found out that fragmentation within IPv4 routers consumes a considerable amount of their processor power.  IPv6 aims to simplify the routers' job and hence increase throughput of the whole IPv6 network.  The practice will show how well this approach really works.
 

5 Mobile IPv6

5.1 Overview of mobile IPv6

The mobile IPv4 protocol is not straightforwardly implementable on IPv6 by merely changing the address length from four to sixteen octets.  Subtle differences between the IPv4 and IPv6 protocols require the mobile IPv4 specification to be adapted to suit the requirements of IPv6.  Experience has, however, shown that mobile IPv4 specification is sound and implementable and hence, the specification has gained diverse interest throughout Internet community [19].  These are the reasons why mobile IPv4 was taken as design basis for a new protocol called mobile IPv6 [20].  The mobile IPv6 is currently in Internet Draft stage [21].

Mobile IPv6 retains most of the concepts that were present in mobile IPv4.  The three fundamental functional units within the protocol are the correspondent node, the home agent, and the mobile node.  The semantics for these are virtually same as in mobile IPv4.  However, the mobile IPv6 does not involve foreign agents as mobile IPv4.  Furthermore, mobile IPv6 integrates some extension features of mobile IPv4 to itself as fundamental part of the protocol.

The mobile IPv6 extends the IPv6 protocol by introducing new destination options to IPv6 protocol.  The new options are binding update, binding acknowledgement, binding request, and home address option.  The destination options are roughly equivalent, except binding request and home address option, to the registration messages of mobile IPv4.  However, because the options are carried in the destination options extension header, the destination options can be piggybacked with any outgoing datagram with correct destination instead of having to send a separate UDP packet. Figure 5.1.2 illustrates the data delivery within mobile IPv6 protocol.

Figure 5.1.2 Mobile IPv6 data delivery

In mobile IPv6 route optimization is a mandatory part of the protocol.  Correspondent nodes have binding caches that contain the currently valid bindings that the node is aware of.  Each time when a correspondent node is about to send a datagram, it first checks if it has a binding for the destination.  If the binding exists, the node attaches a routing header with a single route segment to the datagram, sets the IPv6 destination address to the care-of address indicated by the binding and sets the original destination address to the route segment within the routing header.  When the datagram arrives at the receiving mobile node, the mobile node detects the routing header and sends the packet onward to the address indicated in the routing header.  Because the address is local to the mobile node, the packet is not actually sent but looped back to the mobile node, the destination address being the mobile node's home address.

By using source routing and binding caches, mobile IPv6 allows the correspondent nodes to communicate directly to the mobile nodes avoiding the triangle routing anomaly described earlier.  In mobile IPv4 it was not possible to use source routing because that would have broken one of the requirements of the protocol which dictated that changes to the nodes that do not explicitly participate to the protocol are forbidden.  In IPv6, mobility is specified to be an integral part of the protocol rather than separate entity.

As in mobile IPv4, a home agent is required to be present in the home network of a mobile node.  If a correspondent node does not have a binding for the mobile node, it simply sends the packet to the original destination address which causes the packet to be routed to the mobile node's home network.  Similarly as in mobile IPv4, a mobile node's home agent intercepts the packet intended to the mobile node and tunnels the packet to the mobile node's care-of address using IPv6-in-IPv6 encapsulation [7].  The home agent intercepts the packets using proxy neighbor discovery [17], a similar procedure to proxy ARP.

A mobile node uses a home address option in all datagrams it sends when it is visiting a foreign network.  Additionally, the home address option is included when a binding update option is also present.  It is used to hide the use of a care-of address so that for the receiving end's transport and higher level protocols, the packet seems to have emanated from the mobile node's home address.

5.2 New destination options for IPv6

This section describes the new destination options to IPv6 protocol, introduced by mobile IPv6.  These destination options are carried within IPv6 destination options extension header as explained in Section 4.2. The exact message formats and their usage are described in [21].

5.2.1 Binding update

A binding update destination option is used by a mobile node to announce that it has changed its point of attachment to the internet or to renew an existing binding about to expire.  The binding update is a mobile IPv6 equivalent to the registration request message in mobile IPv4.  A binding update can be sent to the home agent of the mobile node or to a correspondent node of the mobile node. The binding update option requires that also the home-address option is present in the same datagram.

5.2.2 Binding acknowledgement

A binding acknowledgement destination option is sent as a reply to a binding update if the "acknowledgement required"-flag in the binding update was set.  The binding acknowledgement contains status code which enables it to also function as a negative acknowledgement if necessary.  In addition, the binding acknowledgement holds a verification lifetime field which is usually the same as supplied with binding update but can be lower if the recipient does not want to guarantee such long lifetime.  The refresh field contains information on how long intervals the binding is recommended to be refreshed.

5.2.3 Binding request

A binding request offers the correspondent nodes a way to improve the performance of the protocol.  If the correspondent node's binding to a mobile node is about to expire, the correspondent node may ask the mobile node to renew that binding.  In case the mobile node agrees, it responds to binding request by sending a binding update, otherwise it does not respond at all.  If the communication between a mobile node and a correspondent node is intense, sending the binding request may reduce delays that would otherwise occur due to the temporary triangle routing that would take place upon binding expiry.

5.2.4 Home address

A home address destination option is used to fake the actual source address of the packet to the protocols above network-layer.  The home address destination option includes an alternative source address that will overwrite the source address in the IPv6 header when the packet is passed to higher protocol layers.  In mobile IPv6, the mobile node attaches the home address option to all packets that it sends while it is at a foreign network and to all packets containing a binding update.  The home address option holds the home address of the mobile node so that when a node receives a datagram equipped with home address option, the datagram seems to have originated from the mobile node's home address although the IPv6 header contained the mobile node's current care-of address in its source address field.

5.3 Registering and deregistering care-of addresses

As in mobile IPv4, the mobile node is in charge of the registration procedures.  The mobile node initiates a new registration procedure each time when it considers itself moved or when its home registration is expiring.  A home registration is a registration made to mobile node's home agent while other registrations can be made to correspondent nodes.  The home registration is mandatory because if it is not made, the mobile node sooner or later becomes completely unreachable.

A mobile node registers a care-of address by sending a binding update destination option to a home agent or a correspondent node.  The binding update causes the recipient to update the corresponding entry in its binding cache.  If the A-bit is set in the binding update, the recipient of the binding update is expected to send binding acknowledgement back to the mobile node.  The A-bit is normally used only with home registrations.

Since the home registrations are vital to protocol function, a resend strategy may be used.  If the mobile node fails to register its primary care-of address to its home agent, it may resend the binding update.  However, it may be possible that the home agent is unwilling to register the particular mobile node, is too congested at the moment, or simply is down.  In such cases, the mobile node may engage in dynamic home agent discovery mechanism to obtain a new home agent.

5.4 Movement detection and new care-of address formation

The mobile IPv6 specification presents wider range of methods to be used for movement detection than mobile IPv4.  The primary method of movement detection, however, resembles the subnet prefix algorithm of mobile IPv4.  The mobile nodes continuously listen to the router advertisements sent by the routers within IPv6 subnet.  The router advertisements carry prefix information for the subnet just as the agent advertisments do in mobile IPv4.  The mobile node keeps, as any other node, a list of default routers within the subnet it currently resides in.  A new default router is added when a router advertisement is received and validated, and deleted when it has exceeded the lifetime carried in the corresponding router advertisement.

The mobile node picks one default router and considers itself moved when the default router it has chosen expires.  The mobile node will then pick a new default router with a new subnet prefix and form new care-of address for subnet prefix advertised by the default router.

Particularly in wireless networks, it is possible for the link to be asymmetric.  That is, the node can be reachable from another but not vice versa.  Therefore the mobile IPv6 node should use the neighbour unreachability detection [17] of IPv6 to resolve whether the node is still reachable by the default router.  The neighbour unreachability detection involves sending a neighbour solicitations to default router and waiting for neighbour advertisements back.  If neighbour advertisement is received in reply, the link has bidirectional connectivity.  Since the neighbour unreachability detection consumes valuable network resources, the mobile nodes must not do it too frequently.  Instead they must consider any incoming IPv6 datagram from the default router as indication of connectivity.

The mobile IPv6 draft also explicitly specifies that link-level information such as signal strength or channel quality can be used for movement detection.  This is important since in wireless systems the concept of reachability is much more subtle than in fixed wiring systems.

Once the mobile node has detected movement, it should form a new care-of address for the new network prefix.  The mobile node may accomplish this by using either stateful or stateless address autoconfiguration.  Stateless address autoconfiguration involves merely concatenating the network prefix with the MAC address of the interface that the care-of address will be assigned to.  Stateful address autoconfiguration involves use of some address management protocol such as DHCPv6 [22].  The mobile node can also use some specific address that has been allocated for it to be used in some specific link without resorting to address autoconfiguration at all.  However, since in most cases it is possible to apply stateless address autoconfiguration instead, this last case should be rare.

5.5 Renumbering the home subnet

The process of changing the network prefix in mobile node's home link is called renumbering the subnet and might take place for example when a site switches to use a new network service provider.  IPv6's neighbour discovery [17] and address autoconfiguration [16] provide the actual means for renumbering the home subnet.  However, these mechanisms are designed to work only when all nodes bearing old addresses are connected to the link being renumbered.  Mobile IPv6 extends these features to work even if a node happens to be in a foreign subnet when the renumbering takes place.

The mobile IPv6 performs the extension by relaying router advertisements carrying important prefix information to the mobile node in a foreign network.  The conditions in which the home agent should forward a router advertisement to a mobile node are as follows

Because only certain router advertisements are forwarded, the home agent tries to ensure that the forwarded router advertisements get through by resending them until acknowledged.  Moreover, since there exist possible security hazards in forwarding router advertisements, the forwarded datagram must contain either Authentication Header (AH) [23] or Encapsulating Security Payload (ESP) [24] header.

The home agent does not actually forward the router advertisements but reconstructs them so that the resulting router advertisement will contain only the necessary information for the mobile node to update its state.  The home agent sends the constructed router advertisement to the mobile node using a routing header rather than tunneling the advertisement.  The home agent must add a destination options header containing binding request options to the outbound IPv6 datagram.  Further, the binding request must contain a unique identifier suboption [21].  The home agent periodically resends the datagram as long as it receives a binding update containing a matching unique identifier suboption from the mobile node.

If, during resending, the home agent receives another router advertisement that satisfies the beforementioned conditions, it must generate a new unique identifier and a new router advertisement to forward to the mobile node.

5.6 Dynamic home agent discovery

At some situations it is possible that a mobile node does not know any node that can serve as a home agent for it.  For example it is possible that the previous node that the mobile node used as its home agent has been reconfigured or the home agent service has been moved to another node in the same subnet.

The mobile IPv6 describes a dynamic home agent discovery mechanism that enables a mobile node to dynamically obtain a new home agent.  However, a mobile node is not allowed to engage in dynamic home agent discovery if it already has a valid binding which has not been expired with any home agent.

The dynamic home agent discovery mechanism is based on ICMP messages.  If the mobile node chooses to initiate the dynamic home agent discovery process, it sends an ICMP Home Agent Address Discovery Request message to "Mobile IPv6 Home Agents" anycast address using its home subnet prefix.  The mobile node must also include a home address option in the packet.  When a home agent in the mobile node's home subnet receives the ICMP Home Agent Address Discovery Request, it replies by using an ICMP Home Agent Address Discovery Reply.

The ICMP Home Agent Address Discovery Reply includes the global unicast addresses for the home agent issuing the reply and also for the other home agents in the home subnet.  The mobile node may try to register with each one of the home agents in turn until it finds one that it can complete a registration with.

At the time of writing, the dynamic home agent discovery has not been completely specified since the ICMP message codes are still to be assigned by IANA.

5.7 Modifications required for IPv6 specifications

The mobile IPv6 calls for changes to some IPv6 specifications.  The mobile IPv6 adds four new destination options to the list of IPv6 destination options.  These options are In addition to new destination options, the mobile IPv6 specifies two new ICMP messages that are used in dynamic home agent discovery, Section 5.6: The mobile IPv6 adds a H-flag (home agent) to the ICMP router advertisement message bitfield.  This bit is set if the advertising router is a home agent.  A R-flag (router address) is also added to bitfield in prefix information option of router advertisement.  The R flag facilitates advertising global addresses within router advertisements. Finally, the mobile IPv6 adds two new options to the router advertisement message The movement detection of mobile IPv6 relies on IPv6 neighbour discovery [17].  The neighbour discovery specification, however, sets bounds on how often certain neighbour discovery messages can be sent.  In order to provide more accurate movement detection, it is necessary to relax these bounds.  The mobile IPv6 specifies new time intervals for router advertisements and solicitations.
 

6. Security in mobile IPv4 and mobile IPv6

6.1 Threats caused by mobile communications

Mobility causes several kinds of threats that may have different implications to the security of the protocol.  The first one is related to the tunnel management within the protocols.  Since the tunnels are formed, redirected and destroyed using binding update or registration request messages, it would be possible for a third, malicious, party to attack the protocol using forged binding update messages.  In a simple case, the attacker could cause a denial of service for the mobile user by redirecting or removing the tunnel so that the mobile user would be unable to receive any packets.  Furthermore, the attacker could actually hijack the whole connection and start itself communicating with the correspondent node.

Encryption makes it harder for the attacker to hijack any useful connections but still, if redirection is possible, the attacker could carry out a man-in-the-middle attack by first redirecting the tunnel to itself and then acting as the home agent to the mobile node.  Many cryptographic key-exchange protocols are vulnerable to such attacks which in turn would render the encryption useless.  The logical consequence is that binding update messages must be properly authenticated so that the malicious third party cannot use the tunnel redirection mechanism for attacks.

Redirection is not, however, the only security hazard that the mobility imposes.  Mobility is usually associated with wireless links which make passive eavesdropping easy.  The mobility also causes the packets to be routed along different routes depending on where in the Internet the mobile user currently resides.  It is well possible that the communications are routed through adverse parts of the network that could be considered unsafe.  Such routing and the use of wireless links exposes the communications to risk of privacy loss unless proper encryption is used.

6.2 Mobile IPv4 security

6.2.1 Authentication extensions

The mobile IPv4 introduces three authentication extension headers that are used to authenticate the registration requests and replies between the following parties: mobile node-home agent, mobile node-foreign agent and home agent-foreign agent.  Although they all share common format which is shown in Figure 6.2.1.1, the headers have different type codes.

Figure 6.2.1.1 Authentication extension message format

The SPI field stands for Security Parameter Index.  The SPI is an integer which depends on the cryptographic algorithm and mode used, and a shared secret between authenticating parties.  SPIs are unique for each combination of the three parameters.  An SPI is used to index to what security context does the packet to be authenticated belong to.

The authenticator field includes the data that is used to actually authenticate the packet.  The authenticator value protects the following fields within the datagram:

In keyed-MD5 [25] in "prefix+suffix" mode, which is the default mobile IPv4 authentication algorithm, the authenticator data is constructed by computing an MD5 hash of the following stream of bytes:

6.2.2 Replay protection

To authenticate that the packet originated from the correct source is not enough to provide security.  The malicious third party can record legitimate messages sent by a mobile IPv4 participant and later on resend the same messages to achieve undesired effects.  The packets must hence be, not only authenticated, but protected against reuse.

The registration request and registration reply messages contain a 64-bit identification field which is used both to identify request-reply-pairs and to provide means for replay protection.  Mobile IPv4 specifies that either timestamps or nonces can be used for achieving that.  Timestamp approach is defined to be mandatory default algorithm in mobile IPv4.  Although the use of nonces has some advantages over timestamps it was not made the default algorithm because of patent issues.

In timestamp approach the identification field contains the current time of sending party.  Network Time Protocol (NTP) [26] is used for gaining the timestamp.  The downside of this is that the clocks between parties must be synchronized for this scheme to work and indeed it would be possible to attack against the NTP protocol instead of authentication algorithm itself.

Second possibility for providing replay protection is the use of nonces.  A nonce is a random number that a node includes in the identification field of registration message.  When a node receives next message from the party that the nonce was sent to, it expects the message to carry the same nonce that was previously sent to the party.  If this is not the case, the message is considered to be tampered with and is ignored.  Replayed messages cannot be used because the next nonce will virtually always be different from the previous.

6.3 Mobile IPv6 security and IPSec

Unlike in mobile IPv4, the low level security mechanisms are not part of the protocol specification in mobile IPv6.  Instead, the mobile IPv6 relies on Internet Protocol Security Architecture (IPSec) [27] to provide the necessary mechanisms for authentication and encryption.  The mobile IPv6 specification only specifies which kind of messages need to be authenticated.  An important difference to mobile IPv4 is that due to use of IPSec, the mobile IPv6 also supports data encryption in addition to authentication.

The mobile IPv6 protocol specifies that all packets carrying binding update or binding acknowledgement destination options must be authenticated using authentication header (AH) [23] or encapsulating security payload header (ESP) [24].  Both of the headers provide sender authentication, data integrity protection, and replay protection.  In addition, the ESP header provides encryption of the IPv6 packet payload which addresses the threats concerning communications privacy.  The functionality of AH closely matches the mobile IPv4 security mechanisms but reliance on standard security mechanism makes implementing mobile IPv6 easier and in a way mobile IPv6 less prone to implementation or specification errors.
 

7. Performance aspects

7.1 Mobile IPv4

7.1.1 Performance bottlenecks of baseline mobile IPv4

The major drawback in mobile IPv4 is that the triangle routing of packets always takes place unless the mobile node is at home or the correspondent node is at the same foreign subnet as the mobile node.  The triangle routing places a heavy burden to the home agent if it is serving many actively communicating mobile nodes and it also increases the delivery time of packets destined to mobile nodes.

Another drawback, although minor, is the larger signaling overhead as compared to the mobile IPv6.  This is because the mobile IPv4 registration request and replies must travel in separate UDP datagrams and cannot be piggybacked in datagrams otherwise traveling into the same target address.

7.1.2 Effect of mobile IPv4 extensions

The route optimization extension of mobile IPv4 removes the triangle routing problem but is impractical for large scale deployment because it calls for changes to all correspondent nodes which wish to use the feature.

The hierarchical tunneling is likely to improve the performance of mobile IPv4 protocol if handoffs are very frequent or the home agent is far away from the mobile node. This is because the delay experienced by the registration messages is likely to be smaller and because the registration messages are not likely to place heavy burden on home agent.

7.2 Mobile IPv6

7.2.1 Binding caching

The idea of correspondent nodes caching bindings is the same as in mobile IPv4 route optimization.  However, since IPv6 is still developing and is not widely deployed, the changes required for correspondent nodes can be carried out much more easily as for mobile IPv4.  The binding caching of correspondent nodes should considerably reduce the amount of home agent load if the communication between correspondent nodes and mobile nodes is intense.  Furthermore, when using route optimization, the packets are routed with no extra mobility overhead.

7.2.2 Piggybacking destination options

In mobile IPv6 the binding management is carried out using IPv6 destination options.  Since destination options can be piggybacked in any outgoing packet, it is not always necessary to send separate binding update messages to the intended recipient.  Instead, sending node can e.g. use TCP segments of established connection as carriers for the signaling information.  The more frequently binding registrations are made, the larger the potential for bandwidth savings is.
 

8. Mobile ad-hoc networking considerations

In the mobile ad-hoc networking (MANET) concept [28], mobility is taken to the extreme.  The hosts and routers which form the network are viewed as completely mobile and the concept of different subnetworks with relatively clear outlines is to a large extent lost in the MANET environment. A MANET is characterized by true ad-hoc mobility, dynamic and random network topology, asymmetric links, and limited computing resources on connected devices.

Mobile IP is, in essence, a mobility add-on to IP routing as it defines how to deliver datagrams to hosts that do not necessarily reside in their home subnets. The mobile IP home address associates the mobile node to a certain subnet as also do its care-of addresses.  However, since in mobile ad-hoc networking the routing infrastructure is constantly changing with time, these associations become artificial. The problem is, however, more profound than the mere design of mobile IP protocol.  Indeed, not any of the currently commonly used internet routing protocols is well suited to requirements of mobile ad-hoc networking and many of the routing protocols actually designed for mobile ad-hoc networking, drop the concept of different subnetworks.

The mobile IP solves the mobility problem by building on top of the existing internet routing architecture.  This, as such, renders the mobile IP as a non-optimal or even obsolete solution for MANET mobility.  However, the mobile IP concept should not be viewed as an attempt to provide full-scale MANET mobility but rather an attempt to make transparent mobility possible in limited form within an internetwork which is largely wired and static but which also includes mobile elements. Since deploying mobile IP does not require very dramatic changes in the network infrastructure, it might become a strong solution in near-future real-world applications while the research on MANET mobility goes on.
 

9. Conclusions

Both mobile IPv4 and mobile IPv6 are sound and implementable solutions for the IP mobility problem.  Unlike many other solutions, they both address the most important mobility related issues such as movement detection, care-of address formation and registration, data delivery, and security.

The design of mobile IPv6 is based on that of mobile IPv4, but is also influenced by IPv6 specifications and the experiences gained with mobile IPv4.  The mobile IPv6 takes advantage of IPv6 features such as autoconfiguration, destination options, and source routing.

The mobile IPv6 integrates the route optimization feature of the mobile IPv4 as integral part of the protocol thus overcoming the most important performance barrier of mobile IPv4.  Moreover, the mobile IPv6 is not affected by ingress filtering within intermediate routers due to the use of the home address option.  This obsoletes the need for reverse tunneling type extensions as in mobile IPv4.

Unlike mobile IPv4, the mobile IPv6 offers a possibility to dynamically locate home agents.  This feature makes the protocol more flexible and allows the mobile nodes to stay longer times in foreign networks since possible home agent reconfigurations can be dynamically adapted to.

Both mobile IPv4 and mobile IPv6 address security of the protocol.  The basic mobile IPv4 security mechanism is part of the mobile IPv4 specification and addresses only the threat of remote redirection attacks.  The mobile IPv6 uses standard IPSec AH- and ESP- headers to provide the security.  As a consequence, the mobile IPv6 also facilitates encryption of packets.

The mobile IPv4 has already been employed in small scale in different networks and the basic concept has found out to be good.  Since the mobility is specified as integral part of the IPv6 and because the number of portable devices offering IP connectivity is constantly increasing, it is expected that mobility in IPv6 networks will be much more common than in IPv4 networks.  Moreover, because the IPv6 is not yet deployed in large scale, deploying mobile IPv6 will also be easier.

The mobile IP is not especially well suited to mobile ad-hoc networking as it is heavily based on the wired routing architecture concepts.  In mobile ad-hoc networking environment the division of the network into foreign and home subnets becomes artificial due to the constant change in routing infrastructure. However, the mobile IP can be viewed as relatively elegant and easily deployable solution to the limited form of mobility problem.
 

References

[1] Perkins, C., Nomadicity: How Mobility Will Affect the Protocol Stack, 1997 [referred 16.2.2000] 
<http://computer.muni.cz/internet/v2n1/nomad.htm>
[2] Perkins, C., IP Mobility Support, RFC 2002, October 1996
<ftp://ftp.isi.edu/in-notes/rfc2002.txt>
[3] Ferguson, P., Network Ingress Filtering, RFC 2267, January 1998
<ftp://ftp.isi.edu/in-notes/rfc2267.txt>
[4] Townsley, W., et al., Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1998
<ftp://ftp.isi.edu/in-notes/rfc2661.txt>
[5] Pall, G., et al., Point-to-point tunneling protocol PPTP, Internet Draft, 1997 (work in progress) [referred 1.4.2000]
<http://www.kashpureff.org/nic/drafts/draft-ietf-pppext-pptp-02.txt.html>
[6] Perkins, C., IP Encapsulation within IP, RFC 2003, October 1996
<ftp://ftp.isi.edu/in-notes/rfc2003.txt>
[7] Conta, A. & Deering, S.,  Generic packet tunneling in IPv6 specification,  RFC 2473, December 1998.
<ftp://ftp.isi.edu/in-notes/rfc2473.txt>
[8] Perkins,C. & Johnson, D.B., Route Optimization in Mobile IP, Internet Draft, 15.2.2000 (work in progress) [referred 16.2.2000]
<ftp://ftp.nordu.net/internet-drafts/draft-ietf-mobileip-optim-09.txt>
[9] Perkins, C., Mobile-IP Local Registration with Hierarchical Foreign Agents, Internet Draft, 22.2.1996 (work in progress) [referred 16.2.2000]
<draft expired, reference unavailable>
[10] Foo, S. & Chua, K., Regional Aware Foreign Agent (RAFA) for Fast Local Handoffs, Internet Draft, November 1998 (work in progress)
[referred 24.4.2000]
<http://alternic.com/drafts/drafts-c-d/draft-chuafoo-mobileip-rafa-00.txt>
[11] Montenegro, G., Reverse Tunneling for Mobile IP, RFC 2344, May 1998
<ftp://ftp.isi.edu/in-notes/rfc2344.txt>
[12] Deering, S. & Hinden, R., Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998
<ftp://ftp.isi.edu/in-notes/rfc2460.txt>
[13] Huitema, C., IPv6 - The New Internet Protocol, Prentice Hall, 1998
[14] Hinden, R. & Deering, S., IP Version 6 addressing architecture, RFC 2373, July 1998
<ftp://ftp.isi.edu/in-notes/rfc2373.txt>
[15] Comer, D., Internetworking with TCP/IP Volume I: Principles, protocols, and architecture, Prentice Hall, 1995
[16] Thomson, S. & Narten, T., IPv6 stateless address autoconfiguration, RFC 2462, December 1998
<ftp://ftp.isi.edu/in-notes/rfc2462.txt>
[17] Narten, T., Nordmark, E., and Simpson, W.,  Neighbor discovery for IP version 6 (IPv6), RFC 2461, December 1998
<ftp://ftp.isi.edu/in-notes/rfc2461.txt>
[18] McCann, J., Mogul, J. and S. Deering, Path MTU discovery for IP version 6, RFC 1981, August 1996
<ftp://ftp.isi.edu/in-notes/rfc1981.txt>
[19] Perkins, C., Mobile Networking Through Mobile IP, 1997 [referred 16.2.2000]
<http://computer.muni.cz/internet/v2n1/perkins.htm>
[20] Perkins,C. & Johnson, D.B., Mobility Support in IPv6, Proceedings of MobiCom'96, November 1996
[21] Perkins,C. & Johnson, D.B., Mobility Support in IPv6, Internet Draft, 10.3.2000 (work in progress) [referred 1.4.2000]
<ftp://ftp.nordu.net/internet-drafts/draft-ietf-mobileip-ipv6-11.txt>
[22] Bound, J. & Perkins, C.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6), February 1999 (work in progress)
[23] Kent, S. & Atkinson, R., IP Authentication header, RFC 2402, November 1998
<ftp://ftp.isi.edu/in-notes/rfc2402.txt>
[24] Kent, S. & Atkinson, R., IP Encapsulating Security Payload (ESP),  RFC 2406, November 1998
<ftp://ftp.isi.edu/in-notes/rfc2406.txt>
[25] Rivest, R., The MD5 Message-Digest Algorithm, RFC 1321, April 1992
<ftp://ftp.isi.edu/in-notes/rfc1321.txt>
[26] Mills, D., Network Time Protocol (NTP), RFC 958, 1.9.1985
<ftp://ftp.isi.edu/in-notes/rfc958.txt>
[27] Kent, S. & Atkinson, R., Security architecture for the Internet Protocol, RFC 2401, November 1998
<ftp://ftp.isi.edu/in-notes/rfc2401.txt>
[28] Corson, S. & Macker, J., Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations,
RFC 2501, January 1999
<ftp://ftp.isi.edu/in-notes/rfc2501.txt>

Further Information

Mobile Networking Terminology
Glossary containing the basic mobile networking concepts with explanations.