Rapid IPv6 Address Autoconfiguration for Heterogeneous Mobile Technologies

Panita Pongpaibool1, Kannikar Siriwong Na Ayutaya1, Kanchana Kanchanasut2, Hajime Tazaki3

1 NECTEC, 112 Pahol Yothin Rd., Klong Luang, Pathumthani 12120 THAILAND {panita, kannikar.siriwong_na_ayutaya}@nectec.or.th

2 Asian Institute of Technology, Klong Luang, Pathumthani 12120 THAILAND kk@cs.ait.ac.th

3 Graduate School of Media and Governance, Keio University 5322 Endo, Fujisawa, Kanagawa 252-8520, JAPAN

tazaki@sfc.wide.ad.jp

Abstract—This paper proposes a novel IPv6 address

autoconfiguration that works with multiple types of mobile networks, such as MANET, NEMO, MANEMO, as well as regular IPv6 networks. Our proposed algorithm assigns unique addresses to mobile devices without performing duplicate address detection. As a result, an address autoconfiguration can be done rapidly. This is suitable for system that requires dynamic movement and quick handover such as a disaster relief system or car-car communication.

Keywords: MANET, NEMO, MANEMO, DAD, IPv6

I. INTRODUCTION

The next generation network is expected to be dominated by mobile devices. The Internet Engineering Task Force defines two types of mobility technologies: mobile ad-hoc networks (MANET) [1][2] and mobile IP [3]. A MANET is a self-configuring network of mobile nodes connected by wireless links. Topology of MANET can change rapidly and unpredictably due to movement of mobile nodes. Each mobile node in MANET also takes care of packet forwarding for neighbors. Mobile IP, on the other hand, refers to a protocol for handling session continuity during movement of mobile nodes. It allows a node to be identified by its static home address, regardless of its location in the Internet. Network Mobility (NEMO) [4] extends mobile IPv6 support by allowing mobile nodes to move as a group. It introduces a concept of mobile routers (MR), a device that provides transparent mobility support for all mobile nodes attached to it either by wired or wireless links.

This work is motivated by applications of these mobile Internet technologies. A combination of multiple mobility domains is necessary for applications like disaster relief or inter-vehicle communication. For example, a group of aid workers equipped with mobile devices may form a MANET on ground. Once they get on an ambulance, they may communicate with base using NEMO technology. Moreover two ambulances which are nearby can also communicate with one another directly using MANET. The term MANEMO [5][6] has recently been introduced to describe the combination of MANET and NEMO protocols similar to this scenario.

In this research, we assume that handover management follows standard Mobile IPv6, NEMO, and MANET protocols. We focus on address assignment during movement, which is still an open issue in heterogeneous mobile network environment. The goal of address autoconfiguration is to assign a unique address to each mobile device dynamically as it joins a new network. However, since NEMO assumes infrastructure, address autoconfiguration can follow a standard address assignment mechanism for IPv6. MANET, on the other hand, assumes no infrastructure, so new address configuration solutions are necessary. IETF AUTOCONF working group has been developing several MANET-specific autoconfiguration solutions. As far as we know, currently there is no formal proposal for address autoconfiguration that work with multiple mobile technologies.

This paper proposes a novel IPv6 address autoconfiguration that works with different mobile network domains, such as MANET, NEMO, MANEMO, as well as regular IPv6 networks. Our proposed algorithm assigns unique addresses to mobile devices rapidly, making it suitable for system that requires dynamic movement and quick handover. Our goal is to apply this solution to a car-car communication system or a disaster relief system like DUMBO [7], which has been deployed to help with the Myanmar Cyclone relief effort.

This paper is organized as follows: we survey existing techniques for address autoconfiguration in MANET and NEMO in Section II. In Section III we explain our system model and assumptions. Section IV presents our new solution to automate the address configuration process in heterogeneous mobile networks. Performance considerations are discussed in Section V. Section VI concludes the paper.

II. RELATED WORK

Existing address configuration techniques for MANET, Mobile IPv6, and NEMO can be divided into the following categories: duplicate-detection and duplicate-free assignment. This section reviews some existing IP autoconfiguration solutions. For a complete detailed description, please refer to [8].

978-1-4244-2858-8/08/$25.00 ©2008 IEEE

A. Duplicate-Detection Assignment For infrastructure-based mobile network such as Mobile

IPv6 and NEMO, a mobile node configures its IP address through IPv6 Stateless Autoconfiguration [9], a standard address assignment mechanism for IPv6 devices. IPv6 nodes configure their own IP addresses based on prefix information sent by IPv6 routers. To ensure the new address is unique within the network, a message is sent to all devices in the network asking if anyone is using this address. If there is no answer within a specified interval, the address is assumed unique. This test process is referred to as the duplicate address detection or DAD.

The standard IPv6 stateless autoconfiguration must wait for a timeout (1000 ms by default) to confirm address uniqueness. Such delay is interruptive and undesirable. There are other proposals aiming to reduce DAD delay for Mobile IPv6 networks, such as Optimistic DAD [10], Advanced DAD [11], Proactive DAD [12], and MLD-DAD [13]. However, all of these solutions require a centrally assigned prefix, thus not applicable to stand-alone MANETs.

IETF MANET working group also defines a stateless address autoconfiguration based on DAD for stand-alone MANETs. Nodes randomly choose an address within a special prefix 169.254/16 (for IPv4) and fec0:0:0:ffff::/96 (for IPv6) [14]. This solution does not provide a globally reachable address. Moreover, it cannot guarantee uniqueness when partitioned networks merge later.

MANETconf [15] develops this concept further to allow MANET partitioning and merging. A new node obtains configuration information from a configured neighbor (initiator). An initiator chooses an address and performs DAD on behalf of the new node. Each node keeps a list of all assigned addresses in its MANET. This solution manages merger and partitions with network identifier.

Another technique for MANET address autoconfiguration is passive DAD. Passive DAD [16], DAD-OLSR [17] and NOA-OLSR [17] passively detect address duplication by monitoring routing protocol messages. The disadvantage is that they depend heavily on routing protocols.

B. Duplicate-Free Address Assignment

Duplicate-free address assignment allocates an unused IP address to a new node. This is achieved by maintaining stateful address configuration. DHCPv6 is an example of stateful address configuration for IPv6 where a central server manages the address pool. Distributed DHCP lets multiple servers manage disjoint address pools. These solutions do not scale well in MANET scenarios. It is impractical to have a DHCP server in each MANET because MANETs are dynamic and infrastructure-less.

Dynamic Configuration and Distribution Protocol (DCDP) [19] automates distribution of IP address pools by allocating a disjoint block of IP addresses to each node. Each node recursively allocates IP addresses from its block to a new node. Therefore, each node maintains no state beyond its own configuration pool. DCDP is designed for hardwired networks. The Buddy system in [20] develops the DCDP idea to support MANET. Each node uses binary splits to give

half of its address block to new nodes. Nodes synchronize IP address list to detect leaks and claim unused addresses.

Other duplicate-free address allocation techniques are Prophet [21] and RSVconf [22]. Prophet partitions address range into disjoint subsets, and allocate a random subset to a new node. The address range is generated by a clever arithmetic function. Prophet does not guarantee a unique address sequence. However, each node will know its allocation sequence beforehand. Thus conflicts can be resolved in advance. RSVconf uses stateful address configuration. It keeps a list of addresses in use at distributed proxy servers. A new node selects a proxy to obtain an IP address. AddrReservation is broadcasted to all nodes. Each node can have a global view of the network.

One disadvantage of duplicate-free address assignment is state synchronization and maintenance. This might be costly in a mobile network with a large number of nodes. However, the benefit of quick assignment without DAD makes duplicate-free assignment attractive.

III. SYSTEM MODEL

The system scenario considered in this project consists of integration of NEMOs, MANETs, and normal IPv6 networks coexisting in one area as depicted in Figure 1. This scenario could represent communication of rescue workers both on ground and on rescue vehicles.

Figure 1 Our heterogeneous mobile network scenario

In this scenario, a cluster of mobile network nodes (MNNs) can move as a whole with access to Internet infrastructure via a mobile router (MR) using the NEMO protocol. Examples of NEMO are Personal Area Network (i.e., a rescue worker could carry many devices such as a video camera, a GPS device and a laptop) and vehicle-based networks (i.e., a team of rescue workers could travel in the same rescue vehicle). One mobile network can be nested inside another mobile network (i.e., workers with PANs travel on the same vehicle), in which case it is called nested NEMO. In addition, multiple NEMOs can also communicate among each other either through the Internet infrastructure, or directly using a MANET protocol (i.e., rescue workers of one vehicle can communicate with rescue workers of another vehicle). This combination of network technologies is an example of MANEMO. This type of network could describe a disaster relief system we intend to.

In addition, each MNN can form either a stand-alone MANET (e.g., MANET2), or a connected MANET (e.g., MANET1). Both types of MANETs could represent communication of rescue workers on ground. Although we model this scenario for a disaster relief situation, our model can be applied to other settings, such as battle field network, telecommuting, or inter-vehicle communication. The collaboration of these mobile technologies enables a variety of advanced network applications.

IV. PROPOSED TECHNIQUE

Our goal is to design a duplicate-free address assignment technique that works in a heterogeneous mobile environment described in the previous section. We choose a duplicate-free assignment technique over duplicate-detection technique mainly due to its fast configuration time. We assume handover management follows standard Mobile IPv6, NEMO, and MANET protocols.

A. Addressing Structure

The idea behind our address auto configuration algorithm is the observation that routing in NEMO is handled by MR based on hierarchical IP addressing (i.e., all MNNs share the same subnet prefix), while routing in MANET could be done with flat addressing. In fact, many existing MANET address autoconfiguration did not even consider hierarchical address structure. However since our scenario assumes MNN can roam freely between NEMOs and MANETs, it is necessary that we use the same addressing structure in both domains.

Figure 2 Proposed 128-bit addressing structure

In order to interoperate with standard IPv6 devices, we assume each MNN requires a 128-bit IPv6 address. A normal IPv6 address consists of 64-bit network prefix and 64-bit host address. We extend the normal IPv6 address structure by considering four parts: (64-n)-bit site prefix, n-bit current subnet, n-bit home subnet, and (64-n)-bit host ID, as shown in Figure 2. The site prefix and the current subnet together constitute a 64-bit IPv6 network prefix. This 64-bit combination indicates the current MNN network location. In our address structure, we take the first n bits of the host address to represent a home subnet, a subnet where a MNN originally belongs to, and the remained 64-n bits to be a host ID. This n-bit home subnet will never change as MNN moves. The reason for retaining the home subnet is to ensure the uniqueness of the last 64-bit host address. This is because host ID can be duplicated but any two nodes with the same host ID cannot be assigned to the same home subnet. Therefore, a host address of every node is guaranteed to be distinct in every network domain. Since a typical site prefix is 48 bits long, the default n value is 16. Network operators can adjust this value according to their network environment.

For NEMO, connected MANET and normal IPv6 networks, the 64-bit network prefix is obtained directly from MR or infrastructure gateways. For stand-alone MANET, however, there is no infrastructure-assigned prefix. We assume that all stand-alone MANETs adopt a self-assigned Unique Local Address (ULA) prefix (FC00::/8). Then each stand-alone MANET combines this prefix with another randomly selected 56 bits to form a network prefix. B. New Address Assignment

This section discusses procedure when a new MNN enters our scenario for the first time. A new MNN initializes its IP address by listening for IPv6 router advertisements. If it hears a router advertisement, it should adopt the advertised 64-bit prefix as its network prefix. It also takes the last n bits of the prefix as a home subnet.

Address initialization for new MNNs

If (hear prefix advertisement) then

//New MNN joins an infra-based network

myPool = K_arySplit(Gateway pool)

Addr[0:63]=AdvPrefix[0:63]

Addr[64:63+n]=Addr[64-n:63]

Addr[64+n:127]=lowest(myPool)

Else

//New MNN joins a stand-alone MANET

If (detect a nearby MNN (nb))

//New MNN joins an existing MANET

myPool = K_arySplit(nb pool)

Addr[0:63+n]= nbAddr[0:63+n]

Addr[64+n:127]=lowest(myPool)

Else

//New MNN forms a new stand-alone MANET

myPool = entire 64-n bits

Addr[0:7]=FC00

Addr[8:63]=Rand()

Addr[64:63+n]=Addr[64-n:63]

Addr[64+n:127]=lowest(myPool)

End

End

Figure 3 Pseudo code of initial address assignment If the MNN does not receive any prefix advertisement

after a certain period, it realizes that it is in a stand-alone MANET domain. If it detects presence of other MNNs in the vicinity, it will infer that it has entered an existing MANET. It should adopt the same network prefix and home subnet of the neighbor. Otherwise, the new MNN assumes that it is the only member in this stand-alone MANET. It must set the first 8 bits of the network prefix to FC00. Then it chooses the other 56 bits randomly. It also sets the home subnet to be the last n bits of the random 56 bits.

The assignment of the last (64-n)-bit host ID for the new MNN employs a duplicate-free address configuration similar to the Buddy system in [20]. The new MNN obtains a pool of addresses from a gateway, an MR or a neighbor MANET node depending on whether it enters an infrastructure-based network, a NEMO or a MANET. The new MNN should send an AddrReq message to an all-node multicast group to

0 63-n 63 64 63+n 127

Site prefix

(64-n bits)

Home subnet (n bits)

Host ID

(64-n bits)

Current subnet (n bits)

Network prefix (64 bits)

Host address (64 bits)

identify its need of an address pool. An MR or any neighboring MANET node that has address pools could allocate a half (or a third or a kth) of its pool to the new node via an AddrRep message. The MNN can pick one address from the assigned pool, a smallest one for example, to be its host ID. If the MNN is the only member in its MANET, its AddrReq message will be unacknowledged. In such case, it can take over the entire 264-n address set. MNNs will keep their host addresses with them throughout their movement. The 64-bit host address is guaranteed to be distinct for every MNN within the same network provider (i.e., the same site prefix) without performing duplicate address detection. Figure 3 illustrates address assignment steps for a new MNN.

C. Node Join and Network Merging

This section describes join and merge operations with the assumption that joining nodes already have addresses configured on their interfaces and already carry their own address pools. We handle these operations in two different ways based on the structure of a visited network. Figure 4 illustrates this operation.

1. Joining or merging to an infrastructure-based network

In this case, a joining MNN adopts an infrastructure-assigned prefix of a visited network as its network prefix. The 64-bit host address remains unchanged. Address uniqueness is guaranteed as long as movement is within the same network provider, i.e., the new network uses the same site prefix. This is because there could be no other nodes with the same 64-bit host address in this provider domain.

However, if the movement involves different site prefixes, the MNN’s 64-bit host address may not be unique since the two providers could set up the same subnet ID. To ensure host address uniqueness, the joining MNN must give up its current address and address pool. It must request a new address pool from the router of the new network. This way, it will obtain a non-duplicate 64-bit host address for future use within this site prefix. This includes the case of MNN moving from stand-alone MANET into infrastructure network as well. The MNN should follow the procedure of graceful departure described in the next section so that its previous address pool can be reassigned to other nodes.

2. Joining or merging to an infrastructure-less network

When a MNN joins a stand-alone MANET, it can continue using the current address without change. This is possible because MANET does not require hierarchical addressing. Nodes in the same MANET could have different network prefixes. Address uniqueness is preserved if a joining MNN comes from infrastructure network. If a joining MNN is from another MANET, it is possible to have a small chance of address duplication because there is no prefix coordination during initial MANET establishment.

The two cases above can be applied to a situation of multiple concurrent nodes joining or two networks merging. If a group of MNNs join an infrastructure-based network, they must adopt the prefix, and depending on their site prefix, obtain a new address pool. If they join a MANET, then their addresses stay the same. However, if one mobile

network is merging with another mobile network and forming either an attached or nested mobile network, only the merging MR’s egress interface address will change but its ingress address remains unchanged. As a result, all MNNs inside the merging mobile network do not need to change their addresses and can be totally unaware of this movement.

Join operation for existing MNNs

If (hear prefix advertisement) then

//MNN joins an infra-based network

If(AdvPrefix[0:63-n]=CurrentAddr[0:63-n])

//Still in the same network provider

CurrentAddr[0:63]=AdvPrefix[0:63]

Else

//Move to a different network provider

myPool=K_arySplit(Gateway pool)

Addr[0:63]= AdvPrefix[0:63]

Addr[64:63+n]=Addr[64-n:63]

Addr[64+n:127]=lowest(myPool)

End

Else

//MNN joins a stand-alone MANET

Do nothing

End

Figure 4 Pseudo code of join operation

D. Node Leave and Network Partitioning Node leave and network partition can be considered as

either graceful departure or disrupted departure. This proposed solution handles address leaking problem only in case of graceful departure. With graceful departure, leaving MNNs should return their allocated address pools to their routers or nearest neighbors before withdrawing from their networks so that the address pool can be reassigned to new MNNs. This step requires an extra message for address returning purpose from each departing MNN. With disrupted departure, crashed MNNs suddently leave a network. Their IP addresses are lost with them as they leave. This results in an issue of address leaking. The departed node or partitioned network may rejoin with another NEMO or another MANET. In this case, they follow the procedure outlined in Section IV-C.

E. Example Scenarios This section provides an example to illustrate our proposed technique of address autoconfiguration. Let us consider three network domains: one non-mobile IPv6 network, one NEMO network and one stand-alone MANET. NEMO A delegates prefix 2008:0:0:A::/64, and IPv6 network B delegates 2009:0:0:A::/64. Let us assume n is 16 in this example. Therefore, subnet address of NEMO A and IPv6 network B are both 0xA. When MNN1 first joins NEMO A, it is assigned the address pool from 1 to 247-1, and it takes 1 as the host ID. So MNN1’s initial address is 2008:0:0:A:A::1. Likewise for MNN2 in IPv6 network B, its initial address is 2009:0:0:A:A::1. MNN3, on the other hand, is the only device in its area. So it forms a stand-alone MANET with the prefix FC00:0:0:A::/64. Let us assume MNN3 also picks 1 as its host ID, making its initial address FC00:0:0:A:A::1.

Next let us consider MNN1 leaving NEMO A to join IPv6 network B. If it simply adopts the new 64-bit network prefix without recognizing that it has joined a totally different network (different site prefix), its address would be 2009:0:0:A:A::1, which duplicates that of MNN2. To avoid duplication, MNN1 requests a new address pool at the new network. Suppose MNN2 receives a pool from 247 to 247+246-1. MNN2’s new address becomes 2009:0:0:A:A:8000:0:1. MNN1 should then return its previous address block to MR of NEMO A. Next MNN1 leaves network B to join with MNN3. MNN1 address remains 2009:0:0:A:A:8000:0:1. It will not duplicate any node in this MANET because the original MANET nodes will use a prefix starting with FC00.

Figure 5 Example Scenarios Then if both MNN1 and MNN3 moves into network B,

MNN1 address still remains 2009:0:0:A:A:8000:0:1 because it already uses the correct prefix of network B. MNN3, however, adopts the new prefix and new address pool from 247+246 to 247+246+245-1. MNN3 address becomes 2009:0:0:A:C000:0:1. MNN3 cannot return its address pool because MANET C is not connected to the Internet.

This example shows address autoconfiguration during node movement can be done quickly. In many cases (e.g., joining a MANET), there is no configuration to be done at all. In other cases, configuration only involves replacing the first 64-bit network prefix. Uniqueness is guaranteed without duplication address detection procedure due to our special address initialization. Moreover, nodes are allowed to roam freely among different network providers.

V. DISCUSSIONS

We assess features of our proposed solution based on evaluation considerations introduced in [23].

A. Node Characteristics Scenario—The proposed mechanism works under stand-

alone MANET, connected-MANET, NEMO, and even normal IPv6 network environments. It takes into account the case of scenario transition where a connected MANET converges to a stand-alone MANET and vice versa.

Mobility type—Because the proposed mechanism offers a quick address configuration, it is appropriate for a mobile node of any mobility types ranging from low to high, for example, from people movement to vehicle movement.

B. Functional Characteristics Address uniqueness—The proposed mechanism

guarantees address uniqueness without performing duplicate address detection. In infrastructure-based network, address uniqueness is governed by infrastructure gateways. Although in infrastructure-less network, chances of network prefix collision is not zero, the likelihood is negligible. This is because as mobility increases, chances of MNNs originated in MANET moving into infrastructure network also increases. As a result, their addresses will eventually become infrastructure-assigned addresses.

Merging and partitioning support—The proposed algorithm supports network partitioning and merging. We consider merging and partitioning as cases of multiple join and leave operations.

Prefix delegation support—The proposed technique support IPv6 prefix delegation to nodes that are connected to NEMO, connected-MANET, and regular IPv6 networks.

C. Performance Characteristics Protocol overhead—The overhead in this solution are

during address assignment and graceful departure. During initialization and joining a new network provider, a MNN sends AddrReq and waits for AddrRep to obtain an address pool. During departure, a leaving MNN returns its address pool to its nearest neighbor, MR, or gateway.

Robustness—This solution does not handle message loss. However message loss will not affect operations of other nodes. If router advertisements are lost, a new node may assume it is in a MANET instead of a NEMO. It just establishes a stand-alone MANET with no connection to Internet. However, if a new node receives router advertisements but either AddrReq or AddrReq message is lost, the node will not be able to configure its address. Thus it cannot communicate with anyone else. Finally during graceful departure, if the address return is lost, it is as if the node has crashed.

Convergence time—The time for a single node to get a unique IPv6 address as it moves into different networks is quick. In many cases (e.g., joining a MANET), there is no configuration to be done at all. In other cases, configuration only involves replacing the first 64-bit network prefix. Thus, configuration delay depends on how quick nodes receive prefix announcements from routers (i.e., router advertisement interval). Moreover, configuration of multiple nodes can be done in parallel.

Scalability—This technique can accommodate a large number of MNNs, in the order of 264-n nodes per sub-network. It can accommodate as many networks as the IPv6 standard allows.

Address space utilization—Our solution allows address space reclamation for nodes that are gracefully leaving the network. However, address leaking remains an issue with disrupted departure. We also do not handle the case when a node runs out of addresses to assign to new nodes. In addition, a binary split could cause uneven allocation size where some nodes may end up with much larger address space than others. It is up to a network operator to choose an appropriate size of allocation.

Infra Network B 2009:0:0:A::/64

NEMO A 2008:0:0:A::/64

MNN2 2009:0:0:A:A::1

MNN3 FC00:0:0:A:A::1

MNN1 2008:0:0:A:A::1

MANET C FC00:0:0:A::/64

D. Nodes’ Behaviour Characteristics Distributed/centralized approach—Although the proposed

solution is based on address pool assignment and splitting, it is a distributed approach since all nodes manage their own address pools.

Trust and security—Every MNN is assumed to be trustworthy and security issues are not concerned in this method. Therefore, if any mobile device is compromised, our approach is subject to attacks, such as denial of address assignment service, address confliction, and address integrity. Moreover, by embedding the home subnet in the IPv6 address, this may allow third parties to track mobile users. This is a possible threat to privacy.

E. Architectural Characteristics Integration with standard IPv6—Our solution is designed

to be compatible with regular IPv6 networks, as well as NEMO which is a special case of moving IPv6 network. IPv6 router still performs normal prefix delegation and normal routing based on hierarchical addressing style. The only change to IPv6 nodes is that they no longer perform stateless address autoconfiguration and duplicate address detection.

Gateway involvement—Gateway involvement is required in case of connected MANETs, NEMOs, and normal IPv6 networks. Roles of gateways are prefix delegation and address pool assignment. In case of stand-alone MANET where there is no gateway, this solution still works.

F. Usability Characteristics Routing protocol dependency—This proposed solution is

routing protocol independent. It can work with any routing protocol. The solution can be adapted to any environment, both infrastructure-based and infrastructure-less IPv6 environments.

We summarize key features of our proposed algorithm and compare them with those of other duplicate-free address assignment algorithms in Table 1.

TABLE I CHARACTERISTIC COMPARISON OF ADDRESS ASSIGNMENT STRATEGIES

Considerations Buddy Prophet RSVconf Ours Address uniqueness ×

Partitioning and merging support

Distributed approach

IPv6 compatibility × × ×

Routing protocol independent

Support connected or stand-alone MANET

Stand alone

Stand alone

Stand alone

Both

Support NEMO × × ×

Prefix delegation × ×

Scalability <200MNNs

VI. CONCLUSIONS

This paper proposes a novel IPv6 address autoconfiguration that works with different mobile network domains, such as MANET, NEMO, MANEMO, as well as regular IPv6 networks. Our proposed algorithm assigns unique addresses to mobile devices without performing duplicate address detection. The algorithm has low overhead. As a result, an address autoconfiguration can be done

rapidly. This makes it suitable for system that requires dynamic movement and quick handover such as a disaster relief system. This approach is distributed and routing protocol independent. Therefore, it is scalable and can be applied to any existing routing protocol. It is also compatible with IPv6 networks. Thus, it can accommodate a large number of mobile devices and mobility domains. Mobility management is assumed to follow standard Mobile IPv6, NEMO, and MANET protocols.

In the future, we plan to take address leaking in case of device failure, as well as security and privacy issues into consideration. In addition, we plan to handle the case when a MNN runs out of addresses to assign to new nodes.

REFERENCES [1] M. Corson and J. Macker, “Mobile Ad hoc Networking (MANET):

Routing Protocol Performance Issues and Evaluation Consideration,” RFC 2501, Jan 1999.

[2] I. Chakeres, J. Macker and T. Clausen, “Mobile Ad hoc Network Architecture,” Internet Draft, draft-ietf-autoconf-manetarch-04.txt, Jul 2007.

[3] D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6”, RFC 3775, Jun 2004.

[4] V. Devarapalli et al., “Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, Jan 2005.

[5] B. McCarthy, C. Edwards and M. Dunmore, “The Integration of Ad-hoc (MANET) and Mobile Networking (NEMO): Principles to Support Rescue Team Communication,” Proc. of ICMU 2006, 2006.

[6] M. Tsukada and T. Ernst, “Vehicle Communication Experiment Environment With MANET and NEMO,” Proc. of the SAINTW, 2007.

[7] Interlab, Asian Institute of Technology, “Post-disaster Recovery Management and Coordination Program,” http://www.interlab.ait.ac.th/Myanmar/cyclone, Last accessed: Jun 9, 2008.

[8] C. Bernardos, M. Calderon and H. Moustafa, “Survey of IP address autoconfiguration mechanisms for MANETs,” Internet Draft, draft-bernardos-manet-autoconf-survey-03.txt, Apr 2008.

[9] S. Thomson and T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 2462, Dec 1998.

[10] N. Moore, “Optimistic Duplicate Address Detection for IPv6,” RFC 4429, Apr 2006.

[11] Y.-H. Han, S.-H. Hwang, “Care-of address provisioning for efficient IPv6 mobility support,” Computer Communications, 29(2006), pp.1422-1432.

[12] C.-C. Tseng, Y.-C. Wong, L.-H. Yen and K.-C. Hsu, “Proactive DAD: A Fast Address-Acquisition Strategy for Mobile IPv6 Networks,” IEEE Internet Computing, pp. 50-55, Nov-Dec 2006.

[13] G. Daley and R. Nelson, “Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery,” Internet Draft, Feb 2003.

[14] C. Perkins et al, “IP Address Autoconfiguration for Ad Hoc Networks, draft-ietf-manet-autoconf-01.txt,” IETF, MANET WG, Jul 2000.

[15] S. Nesargi and R. Prakash, “MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network,” Proc. of INFOCOM 2002, Jun 2002.

[16] K. Weniger, “Passive Duplicate Address Detection in Mobile Ad Hoc Neworks,” Proc. of IEEE WCNC 2003, 2003.

[17] T. H. Clausen, E. Baccelli and J. Garnier, “Duplicate Address Detection in OLSR Networks,” Proc. Of WPMC, Sep 2005.

[18] K. Mase and C. Adjih, “No Overhead Autoconfiguration OLSR,” Internet Draft, draft-mase-manet-autoconf-noaolsr-01.txt, Feb 2006.

[19] A. Misra, S. Das, A. McAuley and S. K. Das, “Autoconfiguration, Registration, and Mobility Management for Pervasive Computing,” IEEE Personal Communications, pp. 24-31, Aug 2001.

[20] M. Mohsin and R. Prakash, “IP Address Assignment in a Mobile Ad Hoc Network,” Proc. of MILCOM 2002, 2002.

[21] H. Zhou, L. M. Ni and M. W. Mutka, “Prophet Address Allocation for Large Scale MANETs,” Proc. of INFOCOM 2003, Apr 2003

[22] R. Bredy, T. Osafune and M. Lenardi, “RSVconf: Node Autoconfiguration for MANETs,” Proc. of 6th ITST, Jun 2006.

[23] H. Moustafa, C. Bernados and M. Calderon, “Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs,” Internet Draft, draft-bernardos-autoconf-evaluation-considerations-01, Oct 2007.