Sami Kivisaari
Department of Computer Science and Engineering
Helsinki University of Technology
skivisaa@cc.hut.fi
1.1 Motivation for mobility2 Mobile IPv4
1.2 Mobility problem in IP networks
1.3 Mobility solutions
2.1 Overview of mobile IPv43. Extensions for 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.1 Route optimization4 New features in IPv6
3.2 Hierarchical tunneling
3.3 Reverse tunneling
4.1 Addressing architecture5 Mobile IPv6
4.2 Extension headers
4.3 Node configuration
4.4 Fragmentation and reassembly
5.1 Overview of mobile IPv66. Security in mobile IPv4 and 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.1 Threats caused by mobile communications7. Performance aspects
6.2 Mobile IPv4 security
6.3 Mobile IPv6 security and IPSec
7.1 Mobile IPv48. Mobile ad-hoc networking considerations
7.2 Mobile IPv6
9. Conclusions
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.
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.
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].
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)
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.
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.
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.
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.
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.
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.
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.
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.
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].
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].
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].
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.
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
[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> |