2011 Eighth Intel11ational Joint Conference on Computer Science and Software Engineering (JCSSE)

DAA: Distributed Address Auto-configuration for Mobile Ad Hoc Networks

Vas aka Visoottiviseth, Chaiwat Yanprasop Faculty of Information and Communication Technology

Mahidol University Bangkok, Thailand

itvvs@mahidol.ac.th, g5136898@student.mahidol.ac.th

Abstract- We implement a new IP address auto-configuration mechanism for MANET. The proposed mechanism lets any nodes in a MANET distribute address pools to a new node. The proposed algorithm can guarantee address uniqueness and achieve fast address assignment. The protocol is implemented on the Optimized Link State Routing protocol and supports both IPv4 and IPv6. This paper extends the previous work [6] by providing reliability, optimizing the codes and validating the protocol performance with more experiments and more nodes on the real wireless testbed. We also discuss concerns about security vulnerabilities of this proposed protocol.

Keywords-MANET; OLSR; Auto-configuration; Address Configuration

I. INTRODUCTION

A mobile ad hoc network (MANET) is a self-configuring network of mobile devices connected by wire or wireless links. MANET has a complex connection because its topology always changes. Connecting between MANET and infrastructure network takes time in a part of IP address configuration for each node in MANET, especially if the MANET has a lot of nodes. Manual IP address configuration cannot support dynamic operations of node merging and partitioning fast enough. For an automatic IP address configuration, nodes may rely on a centralized server and use a dynamic host configuration protocol like DHCP to acquire an IP address. However, this solution cannot be employed in MANETs due to the difficulty of maintaining a centralized DHCP server.

Other techniques for MANET address autoconfiguration use Duplicate Address Detection (DAD) mechanism, for example PDAD [1], MANETconf [2], DAD-OLSR [3], NOA­OLSR [4], and PAA [9]. In the basic work of DAD, any new node entering a MANET picks a temporary address. Then it broadcasts the temporary address and waits to check whether there is a conflict with any other nodes. The disadvantages of the DAD technique are the delay for conflict testing, and many data packets broadcasted to all nodes in the MANET to check address uniqueness.

In this paper, we implement a mechanism for MANET IP address auto-configuration without using DAD. Our mechanism is based on the concept of Rapid IPv6 Address Auto-configuration for Heterogeneous Mobile Technologies [5]. In this concept, authors proposed a 128-bit addressing

Panita Pongpaibool National Electronics and Computer Technology Center

Bangkok, Thailand panita@nectec.or.th

structure of IPv6 as in [5] to assign a unique IP address for nodes entering a MANET, a mobile IP, or an infrastructure network. The node will receive an address pool when it joins a new network, and it can use an old address when it comes back to the home network. When two networks merge together, nodes in both networks are still guaranteed to have unique addresses. While reference [5] provides proof of uniqueness, it does not describe implementation details nor provide performance results. Our work provides a real implementation on an OLSR testbed and extends [5] to support both IPv4 and IPv6. However, we focus on MANET only.

The concept of [5] uses the distributed address pool technique to distribute half of its current address pool to any new node until the pool runs out. Each node will assign itself the lowest address of the address pool. Fig. 1 shows an example of address distribution in a MANET using this technique, assuming the MNNI to MNN5 enter the network in order. As in Fig. 1, the 1Pv6 network delegated prefix is FCOO:O:A: :/64, which begins with the unique local address (ULA) prefix [7] as assumed in [5]. The n-bit subnet length in Fig. 1 is 48, and the subnet address of the IPv6 network is OxA. The host ID is 16 bits long.

Figure 1. Example of distributed address pool

The initial implementation of this work can be found in [6]. This paper extends the previous work by adding more messages to provide reliability, optimizing the codes and validating the protocol performance with more experiments and more nodes on the real wireless testbed. In addition, we discuss about security consideration regarding this proposed protocol.

978-1-4577-0687-51111$26.00 ©2011 IEEE 403

404

II. IMPLEMENTATION DESIGN OF DISTRIBUTED ADDRESS

AUTO-CONFIGURATION (DAA)

Since reference [5] does not provide real implementation, we design and implement the Distribute Address Auto­configuration (DAA) on the Linux for address auto­configuration of both IPv4 and IPv6 network by adopting its initial concept.

The implementation of DAA is based on the ad hoc routing protocol, OLSR [7], which is a proactive routing protocol. DAA consists of two components: DAA client, and DAA server; also defines two run-time states: client and server mode.

An unconfigured node or new node runs the DAA client in order to allocate a "free" address. In this context, "free" means an address is not used by any node in the MANET. The unconfigured node will communicate with one or more of already configured nodes. A configured node runs the DAA server with the routing daemon. All communication between unconfigured node (DAA client) and configured node (DAA server) is done via the link-local address space 169.254.0.0/16 (for 1Pv4) or FE80::/1O (for IPv6). DAA packets use the 64-bit header and all traffic is carried via UDP. When the DAA server receives an Address Request, it will halve an IP address pool and send the pool to DAA client.

In our previous implementation [6], we defined three new messages for DAA, which are ADDR_REQ for requesting an address pool, ADDR_RES for the address response, and ADDR_ACK for the client acknowledgement.

The problem can be occurred when two or more configured nodes offer an IP address pool to a new node. Therefore in this paper, we modify ADDR_ACK by adding the "Sender selected IP address". If the new node does not select an IP address pool offered, the configured node can reclaim IP address pool immediately. It will not wait for any timeout and ready to send the IP address pool to other unconfigured node. With this optimization, DAA can assign an IP address in faster manner.

In a congested network, the ADDR_ACK from the unconfigured node may not be delivered to the configured node. The situation could produce a duplicate address, as the configured node will reclaim the address and announce the same address pool to other new nodes, when it does not receive ADDR_ACK for NumRESRetran times. To solve this problem, in this paper we also add SERVER_ACK for the server acknowledgement in order to make sure that the server received the ADDR_ACK.

All four message structures for DAA are outlined in Fig. 2 to 8. In Fig. 5 and 6, the "Split subnet" is used instead of specifying the last address in the allocated IP address pool, as it can be used by a new node to calculate the assigned address block by itself. The benefit of this approach is that we can reduce the message size in IPv6 mode.

Bits: ����LL���LL�-r�-L�-L�-L�-L��

Figure 2. The generic DAA packet.

Figure 3. The Address Request and Server Acknowledge message (for 1Pv4).

Figure 4. The Address Request and Server Acknowledge message (for 1Pv6).

Figure 5. The Address Response message (for IPv4).

Begin set of IP addresses ( 128 bits)

Split subnet (32 bits)

Figure 6. The Address Response message (for IPv6).

Figure 7. The Address Acknowledge message (for 1Pv4).

Sender selected IP address (128 bits)

Reserved (32 bits)

Figure 8. The Address Acknowledge message (for 1Pv6).

A. DAA Client

For DAA client, we add new flow of process to support SERVER_ACK, and also add sleep time before resending a message to avoid message collision. When an unconfigured node or new node starts the DAA service, it starts in client mode. The DAA client performs the following tasks step-by­step in order to obtain an IP address.

• Configuring a virtual interface with a random link-local address.

• Generating an ID to use in DAA communication. • Querying neighbors via link-local broadcast to obtain a

set of IP addresses. To prevent packet loss from the packet collision, ADDR_RES message and ADDR_ACK are re-broadcasted for the maximum of 3 times. To avoid more packet collision, random time is added before re­broadcasting the message.

• Configuring the local node with the first IP address of the offered set of IP address. (A node may exit DAA client module if there is no offered set of IP address and it does not want to start new a MANET network).

• Starting the routing protocol. • Switching to DAA server mode.

A flow diagram describing the DAA-client operation is illustrated in Fig. 9. Note that, the DAA client must generate an identification that will be used to identify itself in DAA communication, since link-local address conflicts might occur. Therefore, we use the lower 32 bits of its MAC address.

Figure 9. Flow Diagram of the DAA client.

B. DAA Server

For DAA server, we add new flow of process to support SERVER_ACK. Also add sleep time before resend message for avoid message collision. The operation of DAA server is performed as follows:

• Keeping IP address pool. • Listening to Address Request messages (ADDR_REQ)

from DAA clients. • Processing ADDR_REQ by halving IP address pool. • Sending ADDR_RES with halved IP address pool. • Listening to Address Acknowledge messages

(ADDR_ACK). • Send SERVER_ACK to confirm halved IP address pool. After receiving an IP address pool, the DAA first changes

from the client mode to server mode. Moreover, the DAA server should forward messages in link-local only in order to communicate with unconfigured nodes in one hop away. To detect unconfigured nodes, the DAA server listens to their Address Request messages.

C. Example of configuration Session

A new node will use the DAA client module to broadcast (in IPv4) or multicast (in IPv6) the ADDR_REQ to a server node or configured node which runs the DAA server module. If it does not receive an ADDR_RES back from any nodes within a RES Timeout period, it will re-send the message again. If the time out occurs NumREQRetran times, it assumes there is no network in this area. Then, it sets up itself as the first node in the MANET by generating a network prefix from private address space (for IPv4) or from ULA space (for IPv6) and a random home subnet (according to rules in [5]) by itself.

When a server node receives an ADDR_REQ, its server module will halve its address pool then sends the address pool to the request node using the ADDR_RES message. The DAA client module on the request node then temporarily stores the received address pool, assigns the lowest IP address for itself, and sends an ADDR_ACK to confirm the server.

If the server did not receive the ADDR_ACK message back within ACKTimeout period, it will resend the ADDR_RES again for the maximum of NumRESRetran times. If it fails, the server will reclaim the halved address pool back to the DAA server module. On the other hand, if the server receives the ADDR_ACK message back within ACKTimeout period, it will send SERVER_ACK to confirm committing the halved address pool. After sending the ADDR_ACK, the new configured node will wait SERVER_ACK from the server. If the client did not receive the SERVER_ACK message back within SERVER_ACKTimeout period, it will resend the ADDR_ACK again for the maximum of NumACKRetran times. If it fails, the client will clear the received address pool then go to send ADDR_REQ loop again to request IP address pool within NumREQRetran times. After received the SERVER_ACK then the client starts the OLSR, and then change mode to DAA server. Fig. 10 illustrates the sequence diagram of DAA as described above.

Figure 10. DAA Sequence Diagram.

m. PRO-ACTIVE AUTO-CONFIGURATION (PAA )

Besides our DAA, Pro-Active Auto-configuration (PAA) [9][11][12] is another address auto-configuration scheme that has been implemented in the OLSR protocol. The P AA scheme requires DAD for both IPv4 and IPv6 networks.

The P AA defines five messages: Forward Request, Address Request, Address Response, Address Test, and Address Test Confirmation.

405

406

A requester (PAA client) will periodically broadcast a Forward Request message. This is to let already-configured nodes (PAA server) know that they should forward all PAA control messages.

An Address Request message is broadcasted next. Any neighbor that is already a configured member of the MANET will add an offered address in Address Response message then sends it back to the requester. If no messages are heard, the requester can configure its interface with a random address chosen from one of the private IP address spaces such as 10.0.0.0/8 and 192.168.0.0/16 and start the OLSR routing daemon, thus starting its own MANET.

If the requester receives the Address Response then it will generate an Address Test message and broadcast it to all neighbors. Any configured node that hears the Address Test message sends an Address Test Response to confirm the message so that the requester can be sure that the Address Test message is successfully received. If no Address Test Confirmation is heard a new Address Test is sent until at least one Address Test Confirmation arrives. Configure nodes or P AA servers must also forward the Address Test message via the OLSR routing daemon to other neighbors to perform DAD.

The requester then waits for a given interval PAA_REQ_TIMEOUT to receive conflicting Address Test messages sent by other nodes. If this interval times out without any conflicting Address Test messages received then Address Test message is broadcasted once again. If the second time interval of PAA_REQ_TIMEOUT passes without the node receiving any conflicting Address Test messages the address is considered valid and DAD is considered complete. After that the requester configures the interface with the offered address, and stops broadcasting the Forward Request message. Finally, the OLSR routing daemon will start.

The current PAA implementation [10] only supports IPv4. We compare performance of our DAA implementation for both IPv4 and IPv6 mode with P AA in IPv4 mode.

IV. IMPLEMENTATION DESIGN OF DISTRmUTED ADDRESS AUTO-CONFIGURATION (DAA)

For our experiments, we use 11 computers, with a wireless LAN device. The computers specifications are Intel Core2quad 8400 (2.66GHz) with 4 Gigabytes of RAM. The wireless LAN devices are D-link dwa-110 (supported IEEE 802.11g). For the operating system, we use Ubuntu, version 9.04. The MANET protocol is based on OLSR version 0.5.6. We use PAA implementation version 0.4.3 from [10]. However, this PAA implementation only runs on OLSR version 0.4.3. We have to modify the source code to make it work with OLSR version 0.5.6. For DAA implementation, we created a new independent module to work with OLSR using C language.

Performance metrics of interest are address configuration delay and message overhead. Address configuration delay is the time from an un-configured node joins a MANET until it receives a unique address. Message overhead is the number of messages and their total size transmitted to the network for address configuration.

The OLSR daemon can start when the interface has been configured with an IP address within a pre-defined address space. Note that, we use a prefix 10.0.0.0/8 for IPv4 experiments, and a prefix FCOO:0:0:A::/64 for 1Pv6 experiments.

A. Testing scenarios

For all scenarios, we measure the time since the new node sends the first message, i.e. Forward Request for P AA or ADDR_REQ for DAA, until the new node receives the last message which is Address Test Confirmation for P AA or SERVER_ACK for DAA, and can start the OLSR daemon. We setup six testing scenarios as shown in Table I.

TABLE!. TESTING SCENARIOS

Number of Node in MANET Scenario

Unconfigured node Configured node

Scenario 1 1 0

Scenario 2 1 1

Scenario 3 1 2-10 (only 1 receive

ADDR REQ)

Scenario 4 1 2-10 (every node receive

ADDR REQ)

Scenario 5 2-10 1

Scenario 6 2-8 2-8

Scenari03 is the case when a new node joins a group of MANET nodes. We assign one new node to run the DAAIP AA client to request IP address from more than one configured node. We assign two, four, six, eight and ten configured nodes in the same MANET. However, only one configured node can hear the new node, while all configured node can connect each other.

Contrarily to scenario 3, in scenario 4 more than one configured nodes can receive Address request messages from an unconfigured node.

Next, scenarioS is the case when N unconfigured nodes join the MANET and then broadcast Address request messages to a configured node. Finally, scenario 6 is the case when N unconfigured nodes join to the MANET and then broadcast Address request messages to M configured nodes.

The purpose of scenario 3-6 is to measure control message overhead by DAAlPAA. We count the total message size of all control messages injected into the network since the new node sends the first message until the new node already receives the IP address and starts the OLSR daemon. For DAA, we count the total size of ADDR_REQ, ADDR_RES, ADDR_ACK and SERVER_ACK, while for PAA we count the Forward Request, Address Request, Address Response, Address Test, Address Test Confirmation, and Address Test carried by routing protocol. Note that the Address Test messages carried by routing protocol are messages forwarded from other P AA servers to perform the DAD mechanism. The total message size includes IP header and MAC header of each message. We do not count the control messages of OLSR, such as Hello messages.

For every scenario in part of DAA (IPv6), we set the n-bit subnet length is 48, and the subnet address of the IPv6 network is OxA. The host ID is 16 bits long.

E. Results and analysis

For each scenario, we compute the average configuration time and message overhead over 20 tests. Table II compares the results of scenarios l and 2 under DAA and P AA implementations. For scenariol, PAA has the average configuration time of 10 seconds. Ten seconds composed of a waiting time after sending the Forward Request (about 3 seconds to give neighbors time to update their forwarding tables), and time to wait for Address Response message (about 7 seconds) which never arrives. Actually, as there is no configured node in the scenario l, the P AA client has to send the ADDR_REQ for 3 times. It set the ADDR_REQ retransmission timeout to 1 second for the 1st transmission, 2 seconds for the 2nd time and 4 seconds for the 3rd time, respectively. Therefore, the total waiting time for Address Response is 7 seconds.

TABLE II. CONFlGURATION TIME UNDER SCENARIOS 1 AND 2

Protocol Configuration time (seconds)

Scenario1 Scenario2

PAA (lPv4) 10.000890 9.426475

DAA (lPv4) 9.190572 0.009612

DAA (lPv6) 9.776433 0.009731

On the other hand, DAA (both IPv4 and IPv6) does not have to send Forward Request message but still has the same waiting time for the Address Response message and has some random hold time before sending next ADDR_REQ (between 0.1 to 2.0 seconds) so its minimum and maximum configuration times are 7.5 and 12 seconds and its average configuration time is about 9-10 seconds.

In scenari02, PAA client sends ADDR_REQ to the configured node or PAA server. Then, it receives the ARRD_RES. After that, it transmits the ADDR_TEST twice to perform DAD. Each time it transmits the ADDR_TEST, the PAA_REQTIMEOUT timer is set to 3 seconds to wait for a ADDR_TEST_RES. Therefore, PAA has the average configuration time about 9 seconds, which consists of the 3 seconds of waiting time after sending the Forward Request (similar to scenariol) and time to wait for Address Test Response (6 seconds. On the other hand, DAA does not have the Forward Request and the Address Test Confirmation messages. The DAA in both IPv4 and IPv6 mode has an average configuration time less than 1 second which is the time for exchanging ADDR_REQ, ADDR_RES, and ADDR_ACK between the new node and the configured node.

As a result, in the case of a new node forming a new MANET, the difference between DAA (both IPv4 and IPv6) and PAA is not significant. However, when a new node joins an exisitng MANET, the DAA (both IPv4 and IPv6) outperforms P AA in terms of configuration delay.

In the scenario 3, we assumed that the new node sends only one Request message to request the IP address. Both of P AA and DAA still send same control message and timer to wait

then the result of every number of configured nodes has same results with scenario 2. In this case, we found that number of configured node in the MANET does not affect the configuration time of DAA and P AA.

Figure 11. Total message overhead of PAA and DAA.

Fig. 11 illustrates the total message overhead in byte between PAA in IPv4 implementation and DAA in IPv4 and IPv6 implementations for scenario 1-3. Experimental results reveal that the total message overhead of P AA increases as the number of configured nodes increase.

We also found that the total number of control messages for DAA and P AA follows the same trends as those of the message size. For each size of control messages for P AA have two difference sizes, 58 byte for Forward Request message, Address Request message, Address Response message Address Test and Address Test Response, 62 byte for Address Test carried by routing protocol. For size of control messages for DAA have same size for each message, 58 byte for DAA IPv4 and 90 byte for DAA IPv6. Note that IPv6 address length is 128 bits, and IPv4 address length is 32 bits.

We have to omit the graphs of scenario 4 and 5, because of the limited space. In the scenario 4, we found that number of configured node that received Address request does not affect the configuration time only in the case of PAA as it remains about 10 seconds. However, the configuration time of DAA slightly increases and because sometimes DAA messages got crash and messages are retransmitted. However, DAA configuration time is still less than one second.

The total message size of DAA also increases as the number of configured nodes increases, because more than one configured node receive request IP address, and they all send control message back to the new node. However, the message overhead of DAA is still much lower than that of P AA because they do not broadcast Address Test message into the MANET.

For scenario 5 and 6, we cannot measure performance of P AA as it does not support the case that more than one new node request an IP address from the same configured node at the same time. The P AA protocol will allow only one new node that has the lowest ID request IP address. Other nodes will stop working. However, new node can request IP address

407

408

at the same time and request an IF address pool from different configured nodes.

Results of scenario 5 reveal that DAA configuration time is not proportional to the number of new nodes. We found that time for the first new node to obtain an IF address pool is a large portion of the total configuration time. During that time, other unconfigured nodes will wait and send a request message again. After that, when new nodes change to configured nodes, they will share their IF address pool with the remaining unconfigured nodes. Thus, the remaining nodes can rapidly obtain IF address pool from any configured nodes.

Figure 12. Configuration time of scenario 6.

Fig. 12 depicts the configuration time in scenario 6. We can see that there is another factor that affects the configuration time. If there are a few configured nodes at the beginning and a few new nodes join and request IF address pool, such as in the case of 2:2 and 2:4, the configuration time will not increase. On the other hand, if there are a few configured nodes at the beginning and many new nodes join the MANET, such as in the case of 2:6 and 2:8, the configuration time will increase. Moreover, if there are many configured nodes and many new at the beginning, such as in the case of 4:4 and 6:4, the configuration time will not highly increase. One factor that makes the configuration time increases is the message collision, as more configured nodes and more new nodes add more control messages in the network.

V. SECURITY CONSIDERATION

IP address pool may be useless if some new nodes successfully received an IF address pool and leave from MANET by accidents, such as loss of power or hardware failure, or a malicious node leaves the MANET with stolen IF

address pool. In both cases, we will lose many IF addresses and cannot prevent this problem.

Further, if a malicious node keeps requesting many address pools, the address pool will be depleted causing a denial-of­service (DoS).

Next problem that can be occurred is an attacker disguising as configured node and sending address conflict to new node or call "False Address Conflict Attack". To prevent above attacks, we recommend applying mutual authentication with cryptographic keys for DAA client and server.

Other problem is a malicious node can freely choose any configured node as a victim, spoof its IF address, and hijack its traffic or we call "Address Spoofing Attack".

Some researchers such as [13] study secure address auto­configuration, they also found that the authentication with cryptographic keys can prevent all major address auto­configuration attack, i.e. address spoofing attack, false address conflict attack, and denial of service attack.

VI. CONCLUSION

To provide a fast and unique address allocation to MANET, DAA is proposed for IF address auto-configuration. Our mechanism does not depend on the type of routing protocol we use to form a MANET network. In this paper, we have refined the implementation of DAA on Ubuntu nodes and performed performance measurement based on the real wireless testbed with OLSR routing protocol. Six testing scenarios are conducted in order to measure the configuration time and message overhead. Experimental results confirm that our implementation outperforms the preceding P AA protocol and can rapidly assign IF addresses to new coming nodes.

One problem that our protocol cannot solve is the situation when more than one MANETs are merged together. Two nodes probably have the same IP address. This address conflict problem will occur when two nodes come from the different MANETs but have the same home subnet.

REFERENCES

[1] K.Weniger, "Passive Duplicate Address Detection in Mobile Ad Hoc Network," Proc. of IEEE WCNC 2003, 2003.

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

[3] T. H. Clausen, E. Baccelli and J. Garnier, "Duplicate Address Detection in OLSR Networks," Proc. QfWPMC, Sep 2005.

[4] K. Mase and C. Adjih, ''No Overhead Autoconfiguration OLSR," Internet Draft, draft-mase-manet-autoconf-noaolsr-OI.txt, Feb 2006.

[5] P. Pongpaibool, K.Siriwong Na Ayutaya, K. Kanchanasut and H.Tazaki, "Rapid IPv6 Address Autoconfiguration for Heterogeneous Mobile

,h Technologies," Proc. of 8 rrST, Oct 2008.

[6] C. Yanprasop, V. Visoottiviseth, P. Pongpaibool, "Implementation of Fast IP Address Auto-configuration for Mobile Ad Hoc Networks", the 7th International Joint Conference on Computer Science and Software Engineering (JCSSE), May 12-14, 2010, Bangkok, Thailand

[7] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast Addresses," RFC4193, IETF, Oct 2005.

[8] T. Clausen and P. Jacquet, "Optimized link State Routing Protocol (OLSR)," RFC3626, IETF, Oct 2003.

[9] A. Tpnnesen, A.Hafslund and P. Engelstad,"IP address Autoconfiguration for Proactive Mobile Ad Hoc Networks,"Proc. Of IEEE-ICC, 2004.

[10] Pro-active Auto-configuration, http://sourceforge.net/projects/olsr-paal [11] A. Tpnnesen, "PAA Cient",

http://www.olsr.orgldocs/report_html/node184.html [12] A. Tpnnesen and R.B. Rotvik, "Thales Pro-Active Autoconfig

Implementation", http://www.acis.nl/mvceiklmanet/olsr/src/paa­OA.3IPAA-DOC

[13] Majid Taghiloo, Jamshid Taghiloo and Mehdi Dehghan, "A Survey of Secure Address Auto-Configuration in MANET," 10th IEEE Singapore International Conference on ICCS 2006, Oct 2006