idnits 2.17.1 draft-bernardos-manet-autoconf-survey-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2381 has weird spacing: '...uration in IP...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 18, 2010) is 5060 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ahn-autoconf-addresspool-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Adh-Hoc Network Autoconfiguration CJ. Bernardos 3 (AUTOCONF) M. Calderon 4 Internet-Draft UC3M 5 Intended status: Informational H. Moustafa 6 Expires: December 20, 2010 France Telecom 7 June 18, 2010 9 Survey of IP address autoconfiguration mechanisms for MANETs 10 draft-bernardos-manet-autoconf-survey-05 12 Abstract 14 This Internet Draft provides a detailed description of most of the 15 existing IP autoconfiguration solutions proposed so far. The main 16 aim of this document is to serve as a general reference for the 17 AUTOCONF solution space. We present most of the previously proposed 18 IP AUTOCONF mechanisms in MANETs, showing their key characteristics. 19 Furthermore, each solution is analysed based on a number of 20 evaluation considerations. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 20, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction and motivation . . . . . . . . . . . . . . . . . 5 69 2. IP address auto-configuration protocols . . . . . . . . . . . 7 70 2.1. Solutions for Standalone MANET scenarios . . . . . . . . . 7 71 2.1.1. No merging support . . . . . . . . . . . . . . . . . . 7 72 2.1.1.1. IP address Autoconfiguration for Ad Hoc 73 Networks (Perkins et al.) . . . . . . . . . . . . 7 74 2.1.2. Merging support . . . . . . . . . . . . . . . . . . . 9 75 2.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile 76 Ad-Hoc Networks (Weniger et al.) . . . . . . . . . 9 77 2.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et 78 al.) . . . . . . . . . . . . . . . . . . . . . . . 10 79 2.1.2.3. IP Address Assignment in a Mobile Ad Hoc 80 Network (Mohsin et al.) . . . . . . . . . . . . . 12 81 2.1.2.4. An Address Assignment for the Automatic 82 Configuration of Mobile Ad Hoc Networks (Tayal 83 et al.) . . . . . . . . . . . . . . . . . . . . . 14 84 2.1.2.5. No Overhead Autoconfiguration OLSR (Mase et 85 al.) . . . . . . . . . . . . . . . . . . . . . . . 15 86 2.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection 87 for OLSR (Weniger et al.) . . . . . . . . . . . . 17 88 2.1.2.7. Passive Duplicate Address Detection for 89 On-demand Routing Protocols (Jeong et al.) . . . . 20 90 2.1.2.8. Prophet Address Allocation for Large Scale 91 MANETs (Zhou et al.) . . . . . . . . . . . . . . . 22 92 2.1.2.9. MANETconf: Configuration of Hosts in a Mobile 93 Ad Hoc Network (Nesargi et al.) . . . . . . . . . 23 94 2.2. Solutions for Connected MANET scenarios . . . . . . . . . 25 95 2.2.1. No merging support . . . . . . . . . . . . . . . . . . 25 96 2.2.1.1. Automatic Configuration of IPv6 Addresses for 97 Nodes in a MANET with Multiple Gateways 98 (Ruffino et al.) . . . . . . . . . . . . . . . . . 25 99 2.2.1.2. Simple MANET Address Autoconfiguration 100 (Clausen et al.) . . . . . . . . . . . . . . . . . 26 101 2.2.1.3. Extensible MANET Auto-configuration Protocol 102 (EMAP) (Ros et al.) . . . . . . . . . . . . . . . 28 103 2.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc 104 Networks (Wakikawa et al.) . . . . . . . . . . . . 30 105 2.2.1.5. Multihop Radio Access Network (MRAN) Protocol 106 Specification (Hofmann) . . . . . . . . . . . . . 32 107 2.2.1.6. Automatic IP Address Configuration in VANETs 108 (Fazio et al.) . . . . . . . . . . . . . . . . . . 34 109 2.2.1.7. Address Configuration Using Address Pool (Ahn 110 et al.) . . . . . . . . . . . . . . . . . . . . . 36 111 2.2.1.8. Address Autoconfiguration for MANET with 112 Multiple MBRs (Lee et al.) . . . . . . . . . . . . 38 113 2.2.1.9. Border Router Discovery Protocol (BRDP) based 114 Address Autoconfiguration (Boot et al.) . . . . . 39 115 2.2.2. Merging support . . . . . . . . . . . . . . . . . . . 41 116 2.2.2.1. Address Autoconfiguration in Optimized Link 117 State Routing Protocol (Adjih et al.) . . . . . . 41 118 2.2.2.2. Extended Support for Global Connectivity for 119 IPv6 Mobile Ad Hoc Networks (Cha et al.) . . . . . 43 120 2.2.2.3. Gateway and Address Autoconfiguration for IPv6 121 Adhoc Networks (Jelger et al.) . . . . . . . . . . 44 122 2.2.2.4. VET, SEAL, RANGER (Templin et al.) . . . . . . . . 46 123 2.2.2.5. A DHCP-based IP address autoconfiguration for 124 MANETs (Bernardos et al.) . . . . . . . . . . . . 47 125 3. Security Considerations . . . . . . . . . . . . . . . . . . . 49 126 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 127 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 128 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 129 6.1. Normative References . . . . . . . . . . . . . . . . . . . 52 130 6.2. Informative References . . . . . . . . . . . . . . . . . . 52 131 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 56 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 134 1. Introduction and motivation 136 Multi-hop communication in ad hoc networks presents some interesting 137 advantages, where no permanent infrastructure is required. Also, the 138 coverage area of an existing infrastructure can be extended through 139 multi-hop ad hoc communication. Several MANET routing protocol 140 specifications have been developed by the IETF MANET WG. In order to 141 allow wide deployment of ad hoc networks, in which IP routing is the 142 most candidate approach, IP configuration of nodes is a strong 143 requirement that need to be satisfied. In this context, the AUTOCONF 144 WG is working towards standard specifications and solutions for IP 145 address autoconfiguration within different MANET environments. 147 Ad hoc networks present particular characteristics that should be 148 taken into account when designing address auto-configuration 149 protocols. Since existing solutions for IP infrastructure-based 150 networks (e.g., RFCs 4861, 4862, 3315 etc.) were designed for a 151 different scope that MANETs, there are several issues that need to be 152 tackled, mainly (but not only) the following: the lack of multi-hop 153 support, the lack of dynamic topology support, the lack of network 154 merging support and the lack of network partitioning support. 156 The first (and so far unique) goal of the AUTOCONF WG has been to 157 describe a practical addressing model for ad hoc networks and how 158 nodes in these networks configure their IP addresses [2]. Now it is 159 the time to start working on solutions (the WG is currently 160 considering to re-charter to work on actual solutions). In previous 161 discussions, the group has identified two possible scenarios of MANET 162 where IP address auto-configuration is required: 164 o Standalone MANETs: these networks are not connected to any 165 external network. All traffic is generated by MANET nodes and 166 destined to nodes in the same MANET. Examples of these networks 167 are conference networks, battlefield networks, surveillance 168 networks, etc. In this scenario, nodes may join or leave 169 randomly. Besides, most likely no pre-established nor reliable 170 address or prefix allocation agency will be present in the 171 network. 173 o Connected MANETs. These networks have connectivity to one or more 174 external networks, typically the Internet, by means of one or more 175 gateways that are also known as MBRs (MANET Border Routers). 176 These networks may be connected to the Internet in permanent 177 fashion or in intermittent fashion. 179 This draft aims at providing a survey on most of the previously 180 proposed IP autoconfiguration solutions, trying to serve as a useful 181 reference for the AUTOCONF WG during the problem space analysis and 182 solution design phases. 184 In the following section, we provide a description of several 185 existing AUTOCONF solution proposals. In order to present the 186 analysed solutions in a structured way, two major classification 187 levels are used: i) standalone/connected, and ii) partitioning/ 188 merging support. Note that this is just one of the many possible 189 solution classifications that could have been followed. In order to 190 provide additional information, we evaluate each of the analysed 191 solutions against some of the evaluation considerations proposed in 192 [1]. 194 2. IP address auto-configuration protocols 196 In this section we briefly describe some of the existing proposals 197 for IP address autoconfiguration, classifying them according to some 198 of the evaluation considerations introduced in [1]. 200 2.1. Solutions for Standalone MANET scenarios 202 2.1.1. No merging support 204 2.1.1.1. IP address Autoconfiguration for Ad Hoc Networks (Perkins et 205 al.) 207 This address autoconfiguration mechanism -- proposed in [3] -- 208 basically consists in choosing an address randomly from an address 209 pool (i.e., a network prefix) available to the MANET and then 210 performing a Duplicate Address Detection procedure within the MANET. 212 Assumptions: It is assumed that nodes performing this 213 autoconfiguration protocol obtain a non-link-local prefix (it cannot 214 be link-local, since the addresses have to be valid over a multiple- 215 hop distance) from which to configure an address. The method to 216 obtain a globally routable prefix is not specified in the solution 217 and, in case it is not possible to obtain any suitable one, a 218 reserved IPv6 prefix, called MANET_PREFIX, is used: fec0:0:0: 219 ffff::/64. 221 Approach description: This solution basically works as follows: a 222 node first selects a random address from the non-link-local prefix 223 that is deployed in the MANET and then performs a Non-unique Address 224 Detection procedure to check for its uniqueness across the MANET. To 225 perform this uniqueness check, the node sends an Address Request 226 (AREQ) message, including the randomly chosen tentative non-link- 227 local IP address. This message is broadcast to its neighbours, by 228 sending the message using the all-nodes multicast IPv6 address as 229 destination of the packet. The source address used by the node to 230 send the AREQ message is another temporary IP address, acquired only 231 for the purpose of sending these messages. This temporary IPv6 232 address belongs to a different non-overlapping prefix -- called 233 MANET_INITIAL_PREFIX -- so the probability of this address to be 234 duplicated in the network is very low, given its short lifetime (this 235 address is only used in this message exchange and discarded 236 thereafter). When a node receives an AREQ message, it creates a 237 reverse route entry for the temporary IPv6 address of the node. If 238 the tentative address contained in the AREQ message does not match 239 the address of the receiving node, it rebroadcasts the message to its 240 neighbours. If the IP address of the receiving node matches the 241 tentative address contained in the AREQ message it sends an Address 242 Reply (AREP) message to the sender, indicating that the address is 243 already in use. The route created by the AREQ messages is used to 244 route the message back to the source node. 246 A node waits for a certain amount of time after sending an AREQ 247 message, for the reception of an AREP message. The process is 248 repeated if no answer is received, and if after a number of attempts 249 no AREP has been received, the node assumes that the tentatively 250 chosen IPv6 address is unique and starts using it. The values 251 configured for the involved timers and retry parameters have an 252 impact on the maximum size of the MANET where the solution would 253 properly work. Additionally, since the Non-unique Address Detection 254 procedure is performed only when the node initially chooses the 255 tentative IPv6 address to use, this mechanism does not support 256 merging of MANETs. 258 AREQ and AREP are a modification of the standard ICMPv6 Neighbour 259 Advertisement and Neighbour Solicitation messages, respectively. 261 Based on [1], this solution has the following key features: 263 o MANET scenario: the solution targets standalone MANETs, although 264 it considers the possibility of being applied to connected 265 scenarios in those cases in which nodes are provided with the non- 266 link-local prefix to be used in the MANET. 268 o Routing protocols' dependency: the solution is routing protocol 269 independent. 271 o Address uniqueness: the proposed solution makes use of Non-unique 272 Address Detection in the initial address assignment phase. 274 o Distributed/centralised approach: the solution does not make use 275 of any centralised server. 277 o Merging support: the solution does not support merging. 279 o Prefix assignment support: the solution does not support the 280 assignment of IPv6 prefixes to nodes. 282 o Protocol overhead: the solution requires additional message 283 flooding (AREQ messages) to verify if an IP address is being used 284 in the MANET. 286 2.1.2. Merging support 288 2.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks 289 (Weniger et al.) 291 The solution described in [4] extends the Neighbour Discovery and 292 IPv6 Stateless Address Autoconfiguration mechanisms to work in multi- 293 hop wireless networks. 295 Assumptions: The solution assumes a hierarchical approach, where 296 there are two different types of participating nodes: those that 297 obtain IPv6 addresses by using a modified version of IPv6 Neighbour 298 Discovery, and special nodes -- called leader nodes --, that are 299 responsible for parts of the address configuration of other nodes. 301 Approach description: The solution basically extends IPv6 Neighbour 302 Discovery to provide nodes within a multi-hop environment with IPv6 303 address autoconfiguration capabilities. To do so, the following 304 modifications to the IPv6 Neighbour Discovery protocol are proposed: 306 o The Neighbour Solicitation message is modified to allow it to be 307 broadcast to a bounded area of radius r_s hops (instead of only a 308 single hop). In addition, a new option for Neighbour Discovery is 309 defined (called MANET option) which contains a Random Source ID 310 (RS-ID) field, that is used to distinguish different nodes. Nodes 311 use the all-nodes multicast address instead of the solicited-node 312 multicast address. This mechanism guarantees link-local addresses 313 to be unique within the scope (limited by r_s) of each node. 315 o To enable the configuration of unique site-local addresses, a 316 hierarchy is established by special nodes (called leader nodes) 317 that configure a group of nodes by issuing Router Advertisements 318 (RA) within their scope, containing the subnet ID (i.e., network 319 prefix) and its link-local address as source address. The subnet 320 ID has to be unique for each leader node, so Non-unique Address 321 Detection has to be performed between the leader nodes within the 322 entire Ad hoc network. An algorithm is provided for the election 323 of leader nodes. 325 It should be noted that because of the nature of the solution, it 326 would be possible to have multihomed nodes -- that is, nodes with 327 more than one IPv6 address -- if a node is within the scope of more 328 than one leader node. 330 Based on [1], this solution has the following key features: 332 o MANET scenario: the solution targets standalone MANETs, although 333 it could be possible to extend it to support the assignment of 334 global IPv6 addresses. 336 o Routing protocols' dependency: the solution does not depend on any 337 particular ad-hoc routing protocol, but it may be advantageous the 338 routing protocol follows a hierarchical structure. Besides, it is 339 also preferable that nodes move in logical groups. Otherwise, the 340 cost of maintaining the hierarchical structure may be 341 considerable. 343 o Address uniqueness: the proposed solution makes use of a periodic 344 Non-unique Address Detection for ensuring the address uniqueness 345 within the scope of the leader node. Since each leader node makes 346 use of a different Subnet ID, the uniqueness of the assigned 347 address within the entire MANET is ensured. 349 o Distributed/centralised approach: the solution does not make use 350 of any centralised server, but considers the existence of special 351 nodes (leader nodes) that participate in the mechanism in a 352 distributed fashion. 354 o Merging support: the solution support merging, by leader nodes 355 performing periodic Non-unique Address Detection that ensures the 356 uniqueness of Subnet IDs. 358 o Prefix assignment support: the solution does not support the 359 assignment of IPv6 prefixes to nodes. 361 o Protocol overhead: the solution requires additional message 362 flooding within a bounded area of radius r_s hops. 364 2.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et al.) 366 The solution described in [5] proposes two Non-unique Address 367 Detection mechanisms. The first one -- called "strong DAD" -- is 368 done in the initial phase when the ad hoc node does not have an IP 369 address configured yet, it relates to the fact that before a randomly 370 generated address is assigned and used, it should be verified that it 371 will not create an address conflict. On the other hand the second 372 Non-unique Address Detection mechanism -- called "weak DAD" -- is 373 always executed by nodes taking part in ad hoc routing in order to 374 prevent any address conflicts due to mergers. 376 Assumptions: The solution assumes that initially a random address is 377 selected by ad hoc nodes using the reserved IPv6 prefix MANET_PREFIX. 379 Approach description: This approach includes two different Non-unique 380 Address Detection mechanisms: 382 o Strong DAD: based on [3]. Strong DAD is done initially after an 383 ad hoc node has chosen randomly an IP address and it is trying to 384 find out whether there is a duplication conflict or not. AREQ 385 message for Strong DAD is broadcast in site-local scoped all node 386 multicast address, IPV6_MANET_BROADCAST_ADDRESS. The ad hoc node 387 waits for an AREP message -- indicating the selected address has 388 already been utilised -- until the timer for Strong DAD expires. 389 In the case an AREP message arrives it chooses a new address and 390 executes Strong DAD mechanism again. [5] describes the message 391 format, using ICMPv6 messages (new types are defined). [6] 392 describes the message format for AODV. 394 o Weak DAD: based on [7]. During ad hoc routing, weak DAD is used 395 to find out whether address duplication, due to merging has 396 occurred or not. The concept of ``Virtual IP address'', which is 397 the combination of an ''IP address'' and an ``Key'', is used, 398 which is selected to be unique by each mobile ad hoc node. This 399 ''key'' is appended to control packets of ad hoc routing protocol, 400 such as route discovery messages or hello messages. Intermediate 401 routing points must store the ''key'' value for each address in 402 its routing table. Using these ''keys'', duplication conflicts 403 can be found out during ad hoc routing process. An AERR message 404 is sent during Weak DAD for the purpose of indicating that an 405 address duplication happened. The ad hoc node that receives an 406 AERR message should autoconfigure a new IPv6 address through 407 Strong DAD. The same AERR message is used to inform each peer 408 node that its address has been changed. In order to keep ongoing 409 sessions after an address duplication episode, data packets are 410 sent to the new address through IP tunnelling. The destination 411 address in outer IP header is the new IP address of the node that 412 announced duplicate address and the inner IP header contains the 413 duplicate IP address of the node, i.e. the old address of the 414 node. The match duplicate address and new address is done in an 415 Address Mapping Cache. 417 Based on [1], this solution has the following key features: 419 o MANET scenario: the solution targets standalone MANETs. 421 o Routing protocols' dependency: the solution does not depend on any 422 particular ad-hoc routing protocol. 424 o Address uniqueness: the proposed solution makes use of two 425 different Non-unique Address Detection mechanisms. 427 o Distributed/centralised approach: the solution is distributed. It 428 does not make use of either any centralised servers or special 429 nodes. 431 o Merging support: the solution supports merging by looking for 432 duplicate addresses on an ongoing basis. 434 o Prefix assignment support: the solution does not support the 435 assignment of IPv6 prefixes to nodes. 437 o Protocol overhead: The Strong DAD mechanism requires additional 438 message flooding (AREQ messages) to find out whether there is a 439 duplication conflict or not. The Weak DAD mechanism introduces 440 also some protocol overhead since the Key extension (20 bytes) is 441 appended to each control packet of the ad hoc routing protocol. 443 2.1.2.3. IP Address Assignment in a Mobile Ad Hoc Network (Mohsin et 444 al.) 446 This proposed solution [8] is based on a dynamic allocation of IP 447 addresses in MANETs using the concept of binary split. A proactive 448 approach is used, in the sense that each node can independently 449 assign a new IP address without consulting any other node in the 450 network. Partitioning and merging as well as nodes abrupt departures 451 are supported in this solution. 453 Assumptions: It is assumed that all nodes collectively perform the 454 DHCP functionality; where each node is capable of configuring a new 455 node and providing it with a new IP address. It is also assumed that 456 one MANET node have the entire pool of IP addresses at the beginning. 458 Approach description: In this proposed solution the concept of Buddy 459 Systems is used. This is a type of segregated lists used in memory 460 allocation and supports efficient splitting and coalescing. In the 461 context of the proposed solution, binary buddies are used, where all 462 buddy sizes are a power of two, and each size is divided into two 463 equal parts. Thus, every node has a disjoint set of IP addresses 464 that it can assign to a new node without consulting any other node in 465 the network. When a new unconfigured mobile node (B) joins the 466 network, it requests the nearest neighbour (A) an IP address. Node 467 (A) divides its IP address set into two, giving one half to the 468 requesting node (B). The new node assigns itself an IP address from 469 the acquired pool of addresses, storing the rest of addresses to 470 configure other nodes afterwards. The new node (B) is now configured 471 and is considered as the Buddy of node (A). The scheme of the IP 472 address assignment can be seen as a handshaking protocol between the 473 server and the client, where the node requesting the IP address is 474 considered as the client node and the node that actually assigns the 475 IP address is considered as the server node. 477 Nodes synchronise the IP blocks which they store to keep track of the 478 assigned IP addresses and detect any IP leakage, where every node 479 keeps a record of all the IP address blocks in the network by 480 maintaining a corresponding table. Each node sends its IP address 481 pool to all other nodes in the network, and each node receiving an IP 482 pool from another node records the received information in its IP 483 address table. Through this approach, the network has among its 484 nodes the available IP addresses organised in the form of a binary 485 tree with a division of two identical blocks (Buddies) per level. 487 Two mechanisms are proposed for releasing the node's IP address pool 488 when the node leaves the network: i) graceful leave, in which the 489 leaving node gives its IP address pool to any nearby node. This 490 nearby node may keep the IP address pool for itself or may search in 491 its IP address table the Buddy of the leaving node and forward to it 492 the IP pool. ii) abrupt leave, in which the node leaves with its IP 493 address pool that leads to IP leakage. In such a case, a pool of IP 494 addresses that is not assigned to any node is not available. IP 495 leakage is detected from the IP address table stored at each node. 496 Each node scans from time to time its IP address table for the IP 497 pool of its Buddy node, if it does not find it, it concludes that the 498 node has left and it merges this missing IP block to itself. 500 Based on [1], this solution has the following key features: 502 o MANET scenario: This proposed solution targets standalone MANETs. 504 o Routing protocols' dependency: This proposed solution is 505 independent of the underlying routing protocol. 507 o Address uniqueness: The proposed solution does not use any Non- 508 unique Address Detection mechanism. 510 o Distributed/Centralised approach: Although this solution is based 511 on IP address pools assignment and splitting, it has a distributed 512 approach, where all nodes collectively perform the functionality 513 of a DHCP server. 515 o Merging support: Thanks to employing the buddy systems, the 516 proposed solution supports merging. In case of merging, the 517 process of buddies splitting allows the merging node to be 518 assigned an IP address and an IP pool. 520 o Prefix assignment support: the solution does not support the 521 assignment of IPv6 prefixes to nodes. 523 o Protocol overhead: the solution requires a kind of flooding so 524 that each node sends its IP address block to all other nodes in 525 the network. Furthermore, other control messages are required in 526 the form of request-reply messages to enable a new joining node to 527 be assigned an IP address, or in the form of announcement in the 528 case of IP release. 530 2.1.2.4. An Address Assignment for the Automatic Configuration of 531 Mobile Ad Hoc Networks (Tayal et al.) 533 The solution described in [9] is very similar to the previous one 534 ([8]), sharing the idea (also used by others) of nodes assignment of 535 half of their address pools to newly arrived nodes that request IP 536 addresses. 538 In a more recent work [10] it has been proposed a different way of 539 managing the address pool. The authors propose to take advantage of 540 node mobility and make the system achieve roughly even distribution 541 of the free addresses amongs all nodes in the MANET. In order to 542 achieve this goal a redistribution is performed everytime there is a 543 process of address allocation, the new joining node redistributes 544 evenly among its neighbors and itself the free addresses that were 545 previously held by its neighbors. 547 Assumptions: It is assumed that initially there is one node that 548 configures itself as initiator node (when there is no other node in 549 the network), configuring itself with a default IP address and 550 starting to manage a default address pool. 552 Approach description: The solution basically works as follows: when a 553 new node i (called requester node) is willing to join the MANET, it 554 has to contact an existing node j in the network. If node j has the 555 address pool, it divides it into two parts and allocates one part to 556 node i. The starting address of the allocated pool is the address of 557 node i. In case node j does not have the address pool, j starts 558 searching for nodes that might have an address pool, by broadcasting 559 a message (called SEARCH_ADDR). The search message is forwarded by 560 all the nodes which do not have an address pool. A node receiving 561 the search message, either replies with the address pool or with 562 negative ACK. If a node replies with its address pool, it marks half 563 of its addresses as under allocation and wait for a POOL_ACCEPTED 564 message from node j. Node j replies with POOL_ACCEPTED message to 565 the node whose address pool it received first, and allocates the 566 received address pool to node i. 568 This solution defines mechanisms to handle different scenarios, such 569 as network partitioning and merging, message loss, etc. More details 570 can be found in [9]. 572 Based on [1], this solution has the following key features: 574 o MANET scenario: This proposed solution targets standalone 575 scenarios. 577 o Routing protocols' dependency: This proposed solution is 578 independent of the underlying routing protocol. 580 o Address uniqueness: The proposed solution does not use any Non- 581 unique Address Detection mechanism, since the uniqueness of the 582 solution is based on the split of the initially available IP 583 address pool. 585 o Distributed/Centralised approach: the solution is based on IP 586 address pools assignment and splitting, where all nodes 587 collectively perform the functionality of assigning addresses to 588 newcomers. 590 o Merging support: the solution defines a mechanism to detect 591 merging, through redistributing information about assigned 592 addresses and pools. If an address collision is detected, then 593 the solution defines a mechanism to solve that, based on giving 594 up/shrinking the address pool used by one of the nodes detecting 595 the conflict. 597 o Prefix assignment support: Since the solution supports the 598 assignment of address pools, it can be possible to use it to 599 assign prefixes to nodes, although it is not explicitly covered by 600 the mechanism. 602 o Protocol overhead: the solution requires some message flooding to 603 search nodes that have an address pool available. 605 2.1.2.5. No Overhead Autoconfiguration OLSR (Mase et al.) 607 This solution [11] proposes some passive Non-unique Address Detection 608 techniques to be used in MANETs running the OLSR protocol. It 609 utilises the Passive Duplicate Address Detection concept [12], [13], 610 which enables nodes to passively detect duplicate addresses in the 611 network (e.g., occurring after network merging) by analysing received 612 routing protocol messages. The basic idea of PDAD is to exploit the 613 fact that some protocol events occur in case of duplicate address, 614 but (almost) never in case of a unique address. The proposed 615 techniques may be used to ensure uniqueness of an address when it is 616 initially generated before being assigned to an interface and the 617 solution also performs to ensure uniqueness of addresses which have 618 been assigned and used, and then a network merger happens. 620 This is one of the multiple drafts proposing the use of PDAD for OLSR 621 [14], [15]. 623 Assumptions: The protocol assumes the existence of a Non-unique 624 Address Detection-based IP address generation mechanism. 626 Approach description: The solution proposes an ongoing duplicate 627 address detection mechanism, checking for inconsistencies in the 628 routing protocol messages to diagnose duplicate address detection. 629 The first kind of inconsistency is based on information included in 630 OLSR messages (such as HELLO messages and TC messages) and the second 631 kind of inconsistency is based on sequence numbers (when two nodes -- 632 which selected the same IP address -- are present in a network, they 633 would send control messages that will be inconsistent). 635 Different Non-unique Address Detection rules -- twelve in total -- 636 are proposed to handle the cases where the distance between 637 conflicting nodes is one hop, two hops and, three hops or more. In 638 the two first cases the detection is done by means of HELLO messages 639 and in the last case -- three hops or more -- the detection is 640 fulfilled by using information inside TC messages. Also, an 641 additional case is taken into account: this is a specific multihop 642 address conflict case, where the address conflict results in 643 deficiencies in the MPR selection. 645 Each node has an "autoconfiguration state". This state is an 646 indicator of how long the node has been in the network. The central 647 idea, is that each time a node generates a tentative address, it 648 should enter the network gradually, running a restrained version of 649 the OLSR protocol. In this way, the node can detect which addresses 650 are being used, checking for duplicates of its own address, while 651 avoiding to disrupt the routing tables of the other nodes, in the 652 event that its address is actually found to be in conflict. 654 Based on [1], this solution has the following key features: 656 o MANET scenario: This Non-unique Address Detection technique is to 657 be used in standalone MANETs. 659 o Routing protocols' dependency: this mechanism depends on OLSR, 660 since the Non-unique Address Detection technique is designed for 661 MANETs running the OLSR protocol. 663 o Address uniqueness: The proposed mechanism assumes the existence 664 of a Non-unique Address Detection-based address assignment 665 mechanism. 667 o Distributed/centralised approach: the proposed solution follows a 668 distributed approach given that all nodes have the same 669 responsibility detecting address conflicts. 671 o Merging support: The proposed solution supports merging, enabling 672 nodes to continuously detect duplicate addresses by analysing 673 received routing protocol messages. 675 o Prefix assignment support: the solution does not support the 676 assignment of IPv6 prefixes to nodes. 678 o Protocol overhead: the proposed mechanism does not add any 679 additional messages but it checks for inconsistencies in the 680 routing protocol messages to diagnose duplicate address detection. 682 2.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection for OLSR 683 (Weniger et al.) 685 This solution [14] proposes a passive Non-unique Address Detection 686 mechanism for configured address uniqueness maintenance in MANETs 687 running the OLSR protocol. 689 Assumptions: The protocol assumes the existence of a Non-unique 690 Address Detection-based address generation mechanism. 692 Approach description: The proposed solution is made up of a set of 693 algorithms which specify how to detect duplicate addresses based on 694 incoming routing protocol messages. The algorithms utilise different 695 parameters in TC and HELLO messages such as link states (i.e., 696 neighbour interface addresses), link codes, (message) sequence 697 numbers, and addresses in OLSR routing protocol messages as well as 698 addresses in the IP header. PDAD-OLSR allows the detection of 699 conflicts by intermediate nodes that have unique addresses. 701 Each node conceptually maintains two tables for PDAD: a Last received 702 Protocol Messages (LRM) table and a Neighbour History (NH) table. 703 LRM table contains information about the last TC and HELLO protocol 704 message received from a specific originator address (e.g., originator 705 address, message type, sequence number, neighbour interface 706 addresses, receive time). NH table contains the history of 707 neighbouring node addresses and is built from received HELLO messages 708 (e.g., neighbour interface address, last time the receiver has 709 selected this neighbour interface address as MPR, Last time the 710 receiver has been selected as MPR by this neighbour interface 711 address, reception time). 713 The solution proposes eight different algorithms for conflict 714 detection: 716 o PDAD-Source Address (SA). Whenever a node receives a TC or HELLO 717 message, it compares the source address in the IP header to its 718 own address (the IP source address is always the address of the 719 last forwarder). This mechanism (e.g., Both addresses coincide) 720 allows nodes to detect conflicts with its neighbouring nodes. 722 o PDAD-Sequence Numbers (SN): If a node receives a TC or HELLO 723 message, it compares the originator address with its own address. 724 If they are equal and the sequence number in the message is higher 725 than the receiver's sequence number, a conflict of the originator 726 address is detected. This mechanism allows to detect conflicts 727 between nodes that are any number of hops away from each other. 729 o PDAD-Sequence Number Difference (SND): If a node receives a TC or 730 HELLO message, it compares the sequence number in the message with 731 the sequence number in the previously received message from the 732 same originator address and with the same message type (there is a 733 relation between the time a node has originated two TC messages 734 and the sequence number in those TC messages). This mechanism 735 allows to detect conflicts between nodes that are any number of 736 hops away from each other. 738 o PDAD-Sequence Numbers Equal (SNE): If an intermediate node 739 receives a TC or HELLO message, it searches its LRM table for a 740 message with the same type value and the same tuple < sequence 741 number, originator address > (the tuple < sequence number, 742 originator address > uniquely identifies messages originated by a 743 specific node. This mechanism allows to detect conflicts between 744 nodes that are any number of hops away from each other. 746 o PDAD-SNs Always Increment (SNI): If a node receives a HELLO 747 message, it compares the sequence number in the message with the 748 sequence number in the previous HELLO message from the same 749 originator address (HELLO messages sent by a specific node are 750 received in the order they are sent). This mechanism only allows 751 to detect conflicts between nodes that are at most two hops away 752 from each other. 754 o PDAD-Neighbourhood History (NH): If a node receives a TC message, 755 it checks whether its own address is part of the neighbour 756 interface addresses in the TC message. If this is the case and 757 the link code indicates a bi-directional link, the node searches 758 the originator address in its NH table (a TC message only contains 759 neighbours that have selected the originator address as MPRs and 760 that requires a bi-directional link). This mechanism allows to 761 detect conflicts between nodes that are any number of hops away 762 from each other. 764 o PDAD-Link States (LS): If a node receives a TC message with its 765 own address as originator address, it searches in its NH table for 766 each of the neighbour interface addresses (if the message has been 767 originated by the receiver, it must only contain addresses of 768 recent neighbour interfaces). This mechanism allows to conflicts 769 between nodes that are any number of hops away from each other. 771 o PDAD-extended Neighbourhood History (eNH): If a node receives a TC 772 message, it checks for each neighbour interface address in the 773 message if it is a neighbour. This algorithm is basically the 774 PAD-NH algorithm executed on behalf of a neighbouring node. 775 Minimal additional signalling is needed. This mechanism allows to 776 detect conflicts between nodes that are any number of hops away 777 from each other. 779 For some of the above mechanisms it is crucial to detect a possible 780 sequence number wrap-around, so a mechanism to detect this kind of 781 events is proposed. 783 Based on [1], this solution has the following key features: 785 o MANET scenario: The solution targets standalone MANETs. Although 786 it proposes a Non-unique Address Detection mechanism suitable for 787 any kind of addresses exchanged in routing protocol messages, be 788 it MANET-local or globally routable addresses, the solution does 789 not address the issue of how to obtain global IPv6 addresses. 791 o Routing protocols' dependency: this solution requires OLSR, since 792 the set of proposed techniques are applicable to MANETs running 793 the OLSR protocol. 795 o Address uniqueness: The proposed mechanism assume the existence of 796 an address assignment mechanism which may assign duplicate 797 addresses. 799 o Distributed/centralised approach: The solution follows a 800 completely distributed approach, every node has the same 801 responsibility in detecting duplicate addresses and does the same 802 processing. 804 o Merging support: The proposed solution supports merging given that 805 it enables nodes to continuously detect duplicate addresses in the 806 network by analysing received routing protocol messages. 808 o Prefix assignment support: the solution does not support the 809 assignment of IPv6 prefixes to nodes. 811 o Protocol overhead: the solution enables nodes to passively detect 812 duplicate addresses in the network by analysing received routing 813 protocol messages and thus does not cause any overhead. 815 2.1.2.7. Passive Duplicate Address Detection for On-demand Routing 816 Protocols (Jeong et al.) 818 This solution [16] proposes a set of Non-unique Address Detection 819 techniques to be used jointly with an on-demand routing protocol. In 820 this proposal passive duplicate address detection is performed by 821 analysing incoming on-demand routing protocol packets. 823 Assumptions: The protocol assumes the existence of an on-demand 824 routing protocol and a Non-unique Address Detection-based IP address 825 configuration mechanism. 827 Approach description: In this proposal passive duplicate address 828 detection is performed by analysing incoming on-demand routing 829 protocol packets. Additional information included in routing 830 protocol packets allows end-points of a communication -- source or 831 destination -- to detect that the other end-point is using an address 832 which is duplicated in the MANET. 834 This additional information is included into routing control packets 835 exchanged for route discovery and it may be: the node location when 836 it configured its IP address, the node's neighbour list when it 837 configured its IP address, or a sequence number in RREP packets 838 (increased whenever a destination node sends a new RREP packet). 840 The authors propose different mechanisms for detecting address 841 conflicts: 843 o PDAD-RREQ-with-Location-information Technique (RQL): This 844 technique includes location information in RREQ packets to 845 differentiate between RREQ packets which contain the same source 846 address but are generated by different nodes. 848 o PDAD-RREQ-with-Neighbour-knowledge Technique (RQN): This technique 849 includes a list of neighbour nodes (this list is captured and 850 recorded when the node's IP address is configured) in RREQ packets 851 to differentiate between RREQ packets which contain the same 852 source address but are generated by different nodes. 854 o PDAD-RREP-with-SEQ Technique (RPS) : This technique requires an 855 incremental PDAD-sequence number to be included in each RREP 856 packet transmitted by a destination node. Therefore, when a 857 source node receives more than one RREP packet with the same PDAD- 858 sequence number and the same destination address, the source node 859 can detect the address conflict of destination nodes. 861 o PDAD-RREP-with-Location-information Technique (RPL): This 862 technique includes location information into RREP packets to 863 differentiate between RREP packets which contain the same source 864 address (the source address of RREP packets is the destination 865 address of RREQ packets) but are generated by different nodes. 867 o PDAD-RREP-with-Neighbour-knowledge Technique (RPN): When a 868 destination node replies with an RREP packet, a list of neighbour 869 nodes of the destination node (this list is captured and recorded 870 when the node's IP address is configured) is included in the RREP 871 packet. 873 The document does not include how to perform address conflict 874 resolution. 876 Based on [1], this solution has the following key features: 878 o MANET scenario: The solution targets standalone MANETs. Although 879 the proposed Non-unique Address Detection mechanism is suitable 880 for any kind of addresses exchanged in routing protocol messages, 881 be it MANET-local or globally routable addresses, it does not 882 define any mechanism to obtain global IPv6 addresses. 884 o Routing protocols' dependency: The set of proposed techniques 885 supposes the existence of an on-demand ad-hoc routing protocol. 887 o Address uniqueness: The proposed mechanism assumes the existence 888 of a Non-unique Address Detection-based address assignment 889 mechanism. 891 o Distributed/centralised approach: The solution follows a 892 completely distributed approach, every node has the same 893 responsibility in detecting duplicate addresses and does the same 894 processing. 896 o Merging support: The proposed solution supports merging given that 897 it enables nodes to continuously detect duplicate addresses in the 898 network by analysing received routing protocol messages. 900 o Prefix assignment support: the solution does not support the 901 assignment of IPv6 prefixes to nodes. 903 o Protocol overhead: the solution enables nodes to passively detect 904 duplicate addresses in the network by analysing received routing 905 protocol messages and thus does not cause any overhead. 907 2.1.2.8. Prophet Address Allocation for Large Scale MANETs (Zhou et 908 al.) 910 The mechanism defined in [17] is based on the use of a special type 911 of function to derive the IPv6 addresses of nodes, so the probability 912 of address duplication is very low, and therefore the use of a Non- 913 unique Address Detection mechanism can be avoided. 915 Another proposal sharing the idea of avoiding duplication is 916 presented in [18] where to avoid address duplication it is assumed 917 that the IPv6 address of a node includes its Home Subnet identifier 918 (i.e., a subnet where the node originally belongs to) as part of the 919 64-bit Host identifier. This is because "at home administration" 920 guarantees that nodes belonging to the same home subnet have 921 different Host identifier. 923 Assumptions: This solution is based on the use of a stateful function 924 f(n) (where the initial state of f(n) is the seed) that produces as 925 output an integer sequence of numbers. Different seeds lead to 926 different sequences, and the state of f(n) is updated. This function 927 can be used to generate IP addresses, since it satisfies the 928 following properties: 930 o The interval between two occurrences of the same number in a 931 sequence is extremely long. 933 o The probability of more than one occurrence of the same number in 934 a limited number of different sequences initiated by different 935 seeds during some interval is extremely low. 937 These properties may be satisfied if the space of available addresses 938 is large, so it is relatively easy to achieve in IPv6. 940 Approach description: The mechanism basically work as follows: the 941 first node in the MANET chooses a random number as its IP address and 942 uses a random or default state value as the seed for its f(n). When 943 a different node approaches, the first node uses its f(n) to obtain a 944 different number and state. This number is used by the second node 945 as its IP address, and the state is used as the seed for its f(n). 946 After that both nodes are able to assign IP addresses to other nodes. 948 Authors of the mechanism propose different mechanisms to support 949 partitioning/merging, such as for example including the seed used in 950 the MANET in the messages of the routing protocol. By doing that, 951 nodes of different merging MANETs can easily detect the merge (if 952 different seeds are received, that would mean that a merge has 953 happened) and start checking if there are potential IP address 954 conflicts. Given the characteristics of the function f(n) if a MANET 955 gets partitioned and later merges, IP address conflicts are very 956 unlikely to occur. 958 Based on [1], this solution has the following key features: 960 o MANET scenario: the solution targets standalone MANETs. 962 o Routing protocols' dependency: the solution is routing protocol 963 independent. 965 o Address uniqueness: the proposed solution does not define any Non- 966 unique Address Detection mechanism. The address uniqueness is 967 ensured by using a "prophet" allocation with a very low 968 probability of collision. 970 o Distributed/centralised approach: the solution does not make use 971 of any centralised server. 973 o Merging support: the solution proposes different mechanisms to 974 support merging. 976 o Prefix assignment support: the solution supports the assignment of 977 IPv6 prefixes to nodes, by using the DHCP prefix delegation. 979 o Protocol overhead: only few additional messages are required to 980 assign addresses to new nodes. 982 2.1.2.9. MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network 983 (Nesargi et al.) 985 In this autoconfiguration mechanism -- proposed in [19] -- each node 986 maintains a list of all IP addresses in use in the network and a new 987 node (i.e., requester) obtains a candidate IP address through an 988 existing node in the network (i.e., initiator). If the proposal is 989 accepted by all the nodes that are part of the MANET, the proposed 990 address is assigned to the newly arrived node. Otherwise, another 991 candidate IP address is chosen and the process is repeated (for a 992 finite number of times). 994 Assumptions: It assumes that the MANET starts with a single node 995 initiating the configuration process. 997 Approach description: This solution basically works as follows: Each 998 node maintains a list of all the addresses in use in the network. 999 When a node joins the system, it requests an address through one of 1000 its neighbours that have joined the system. This neighbour (i.e., 1001 the initiator) chooses an address that is free according to its 1002 address list and query through the network for the permission to 1003 assign the chosen address. If at least one response is negative, 1004 another address is selected and another query is distributed. The 1005 assignment is granted only if a positive ack is received from all 1006 known nodes. The initiator makes this allocation permanent by 1007 flooding a second message sent once it has received confirmation from 1008 all known nodes. So, IP address allocation is similar to a two-phase 1009 commit. 1011 In order to detect partitions and merges every node remember its 1012 address and its MANET (i.e., partition) identifier. A network 1013 partition is detected when a initiator fails to obtain permission for 1014 an address assignment for a new node from all the other nodes in the 1015 network (i.e., one or more nodes do not answer). After the 1016 detection, every node in each partition cleans up the addresses in 1017 other partitions. The nodes then agree on a new partition 1018 identifier. 1020 This partition identifier is used to detect merges when two 1021 previously distant nodes come within communication range of each 1022 other and exchanger their partition identities. When partitions 1023 merge, nodes in different partitions are required to exchange their 1024 set of allocated addresses so that duplicates can be detected. 1026 Based on [1], this solution has the following key features: 1028 o MANET scenario: the solution targets standalone MANETs. 1030 o Routing protocols' dependency: the solution assume the existence 1031 of a proactive routing protocol to handle network partitions and 1032 merges. 1034 o Address uniqueness: the proposed solution makes use of Non-unique 1035 Address Detection every time a new address is assigned to a node. 1037 o Distributed/centralised approach: the solution does not make use 1038 of any centralised server. 1040 o Merging support: nodes detect merges by receiving messages from 1041 nodes with a different partition identifier. 1043 o Prefix assignment support: the solution does not support the 1044 assignment of IPv6 prefixes to nodes. 1046 o Protocol overhead: the solution requires at least flooding two 1047 messages along the address assignment process. One asking if a 1048 candidate address is perceived as unallocated by the rest of the 1049 nodes, and a second one making the assignation permanent. 1051 2.2. Solutions for Connected MANET scenarios 1053 2.2.1. No merging support 1055 2.2.1.1. Automatic Configuration of IPv6 Addresses for Nodes in a MANET 1056 with Multiple Gateways (Ruffino et al.) 1058 This proposed solution [20] describes a mechanism enabling nodes 1059 belonging to a MANET connected to the infrastructure -- by means of 1060 one or more gateways -- to obtain global IPv6 addresses that could be 1061 used to communicate with external nodes. 1063 Assumptions: This mechanism assumes the existence of one or more 1064 gateways that provide MANET nodes with connectivity to external 1065 networks (e.g., the Internet). It is also assumed that nodes running 1066 this solution obtain at the bootstrapping phase a MANET local IPv6 1067 address (which is the address that the node uses when it participates 1068 in the routing protocol, which is assumed to be OLSR). The 1069 uniqueness of the obtained address should be ensured by means of a 1070 Non-unique Address Detection method. Neither the procedure followed 1071 to obtain this address, nor the Non-unique Address Detection method 1072 used to check its uniqueness, are defined in this solution. 1074 Approach description: The mechanism basically works as follows: at 1075 bootstrap, a node configures a Primary Address (PADD) that is MANET- 1076 scoped and is used as main address in OLSR messages. The node then 1077 is able to start participating to OLSR and receiving topology 1078 information. Each of the gateways available at the MANET has a 1079 global IPv6 prefix that is announced using a new OLSR message type, 1080 called Prefix Advertisement (PA). 1082 With the prefix information received in the PA messages, a node is 1083 able to build a set of global IPv6 addresses (called Secondary 1084 Addresses: SADDs). Among them, the node chooses the "best" prefix 1085 and starts using the address formed from this prefix (called, 1086 Designated Secondary Address: DSADD). The node introduces all (or a 1087 subset) of the SADDs (including the DSADD) in OLSR messages and 1088 starts broadcasting them, enabling these addresses to be routable and 1089 reachable within the MANET. It should be noted, that this solution 1090 does not define any new Non-unique Address Detection mechanism, while 1091 it is suggested to use a generic MANET Non-unique Address Detection 1092 procedure, such as [3], to verify the uniqueness of MANET-local and 1093 global addresses. 1095 Based on [1], this solution has the following key features: 1097 o MANET scenario: the solution targets connected MANETs. 1099 o Routing protocols' dependency: the solution requires OLSR to be 1100 run in the network. 1102 o Address uniqueness: the proposed solution does not define any Non- 1103 unique Address Detection mechanism, although requires some generic 1104 one to be used to ensure the uniqueness of MANET-local and global 1105 addresses. 1107 o Distributed/centralised approach: the solution does not make use 1108 of any centralised server, but requires gateways to announce the 1109 global IPv6 prefixes that can be used by MANET nodes in the 1110 configuration of their IPv6 addresses. 1112 o Merging support: the solution partially supports merging, since 1113 the scenario in which new gateways join the network as a result of 1114 a merger is considered. However, since no Non-unique Address 1115 Detection mechanism is defined, the solution does not describe how 1116 to deal with IPv6 address duplication after merging of different 1117 MANETs. 1119 o Prefix assignment support: the solution does not support the 1120 assignment of IPv6 prefixes to nodes. 1122 o Protocol overhead: the solution adds some overhead. Since 1123 Gateways broadcast prefix information. 1125 2.2.1.2. Simple MANET Address Autoconfiguration (Clausen et al.) 1127 This proposed solution [21] aims to provide a simple IP 1128 autoconfiguration mechanism for mobile nodes joining an existing 1129 MANET. This mechanism is designed for MANETs that act as an edge- 1130 extension to the Internet, where mobile nodes need to maintain the 1131 connections with each other and with the Internet. 1133 Assumptions: It is assumed that at least one node in the network is 1134 already configured with a permanent address. In the absence of a 1135 configured node, it is assumed that an election mechanism is 1136 undertaken allowing a selected node to be self-configured. 1138 Approach description: In this proposed solution, only configured 1139 nodes can participate in the MANET and are considered as MANET nodes. 1140 These nodes are also considered as "configuring nodes" aiding the new 1141 joining nodes to acquire an IP address. Actually, each new joining 1142 node is firstly assigned a temporary local address then a permanent 1143 global address. The configuring nodes emit periodical ADDR_BEACON 1144 messages to their neighbours in order to signal their existence to 1145 new nodes. A new node joining the network selects a configuring node 1146 from its neighbours, then sends an Address Request (AREQ) to this 1147 selected configuring node and waits for a reply. The process of 1148 sending AREQ may be repeated for a number of trials until either 1149 receiving a reply or selecting a new configuring node. The 1150 configuring node replies by an Addr-Config message, containing a 1151 local temporary address, and keeps track of the link existence with 1152 the new joining node through local routing messages exchange on this 1153 link. If this link disappears then the configuring node gives up, 1154 otherwise the configuring node assigns a global address to the new 1155 joining node. 1157 The process of obtaining a temporary address consists of having an 1158 address space, where each MANET node independently selects an address 1159 sequence from this space and signals it to its neighbours (through 1160 beacons). Each MANET node records the address sequence received from 1161 is neighbours to avoid conflicts in the chosen addresses. If a 1162 conflict is detected between two nodes, the node with the lowest ID 1163 should select a new sequence if both nodes are not configuring nodes 1164 (MANET nodes that are not yet engaged in configuring a new node). 1165 Otherwise, if one or more configuring nodes are involved in the 1166 conflict, each configuring node should narrow its sequence of 1167 addresses to contain only the address that is currently assigned (in 1168 order to keep on the configuring session). On the other hand two 1169 options exist for global addresses allocation. One option is that 1170 the configuring node acts as a modified DHCP proxy and transmits a 1171 request to a DHCP server to acquire a global address for each new 1172 node it configures. Another option is that the configuring node 1173 consults the nodes' topology tables (containing destinations and thus 1174 network addresses), and then picks up an unused address. It then 1175 sends an advertisement to all MANET nodes to be sure that this 1176 address is not used. If a node detects that its address is being 1177 used, it can signal the conflict to the originator of the 1178 advertisement. 1180 Based on [1], this solution has the following key features: 1182 o MANET scenario: This proposed solution targets connected MANET 1183 scenarios. 1185 o Routing protocols' dependency: This proposed solution uses OLSR, 1186 typically extending OLSR messages, however it is not dependent on 1187 the routing protocol. Although the proposed solution is open to 1188 any routing protocol, the fact that periodical beacons are used 1189 requires a proactive routing protocol. 1191 o Address uniqueness: The proposed solution uses a Non-unique 1192 Address Detection mechanism to avoid conflicts in IP address 1193 assignment. In global address allocation, using a Non-unique 1194 Address Detection mechanism is an option but the proposed solution 1195 can function without a Non-unique Address Detection mechanism if 1196 the modified DHCP proxy approach is followed. While in temporary 1197 address allocation, a limited Non-unique Address Detection 1198 mechanism is used with the neighbourhood to resolve any conflict 1199 when assigning temporary addresses sequences to MANET nodes. 1201 o Distributed/Centralised approach: The proposed solution is 1202 distributed in the sense that it can employ a decentralised DHCP 1203 server using the concept of proxy DHCP to reach the server. 1205 o Merging support: This proposed solution has no merging support. 1207 o Prefix assignment support: The proposed solution allows prefix 1208 assignment through using DHCP. 1210 o Protocol overhead: the solution requires a considerable number of 1211 signalling. This is mainly during the advertisement messages for 1212 global addresses flooded to all nodes in the network for verifying 1213 the global address uniqueness, the periodical ADDR_BEACON messages 1214 that are transmitted by each configuring nodes to its neighbours, 1215 and the Beacon messages signalling the selected address space by 1216 each configuring node during the process of temporary address 1217 assignment. Furthermore, AREQ messages are used by each new 1218 joining node while communicating a neighbour configuring node, 1219 which in turn replies by an Addr-config message. 1221 2.2.1.3. Extensible MANET Auto-configuration Protocol (EMAP) (Ros et 1222 al.) 1224 The Extensible MANET Auto-configuration Protocol (EMAP) [22] provides 1225 an autoconfiguration solution for isolated as well as hybrid MANETs. 1226 EMAP is envisioned to be integrated within unicast routing protocols 1227 as DYMO or OLSRv2. The notion of intermediate proxies is used in the 1228 autoconfiguration process. The general EMAP framework may be used as 1229 a service discovery protocol for MANETs, however the approach is 1230 extensible to other services. An optional feature in EMAP includes 1231 DNS discovery, where nodes can discover DNS servers reachable from 1232 the MANET, and this feature can be extended to services like SIP, 1233 proxies, and authentication entities. 1235 Assumptions: It is assumed that at least one element must act as a 1236 gateway between the MANET and the fixed network. This element is 1237 called an Internet Gateway (IGW). 1239 Approach description: EMAP allows MANET nodes to configure unique IP 1240 local addresses and globally routable IP addresses. The local 1241 configuration allows a MANET node to communicate with other nodes in 1242 the same MANET. To configure a local address, the MANET node picks 1243 an IP address and asks the network if it is already being used, thus 1244 avoiding address duplication. In this process, a node generates a 1245 pair of IP addresses: temporary and tentative ones. The temporary 1246 address is used as the originator-address, where it can be a mobile 1247 IP home address or another sort of highly likely unique address. 1248 While the tentative address is the one which is being requested and 1249 is used as the requested address in the DAD_REQ messages and the 1250 originator-address in DAD_REP messages. Thanks to the proxy 1251 functionality, intermediate nodes can also answer with a DAD_REP 1252 message if they do not own the requested address but they do know 1253 that it is being used by another node. If the MANET node sending the 1254 DAD_REQ receives no DAD_REP messages, then it understands that there 1255 is no address conflict and it considers that the tentative address is 1256 its local address. 1258 On the other hand, global configuration takes place through using the 1259 Internet Gateway (IGW), which may be a fixed element belonging to 1260 each network, or a mobile one which detects the presence of an 1261 attachment point to the Internet (e.g. a wireless router). The 1262 mobile node requesting a global address either waits for 1263 advertisements sent by the IGW (mainly advertising its prefix) to 1264 configure its global address or floods a global configuration request 1265 (GC_REQ) message. When an IGW receives a GC_REQ message, it sends a 1266 global configuration reply message (GC_REP) to the originator-address 1267 through unicast. Thus, the originating node is able to auto- 1268 configure a global address by substituting the first bits of the 1269 requested local address by the prefix advertised by the IGW. When 1270 there are multiple IGWs announcing their own information, the MANET 1271 node selects one, and the selection rules are implementation- 1272 dependent. 1274 A given option in EMAP allows a MANET node to issue a query to find 1275 DNS Server Advertisers, which provide IP addresses of available DNS 1276 servers. This feature may be quite useful in situations where a high 1277 degree of auto-configuration is desired. 1279 Based on [1], this solution has the following key features: 1281 o MANET scenario: This proposed solution is designed for standalone 1282 MANETs and connected MANETs. 1284 o Routing protocols' dependency: Although EMAP is envisioned to be 1285 integrated with unicast routing protocols like DYMO or OLSRv2, it 1286 may be implemented as a standalone daemon. 1288 o Address uniqueness: The proposed solution uses a Non-unique 1289 Address Detection mechanism during the autoconfiguration of MANET 1290 local addresses. 1292 o Distributed/Centralised approach: The proposed solution is a 1293 distributed solution in the sense of not being based on any DHCP 1294 servers. 1296 o Merging support: No special merging mechanisms are explained in 1297 this solution. However, no in-service Non-unique Address 1298 Detection is used which makes the merging support not feasible. 1300 o Prefix assignment support: This solution employs IPv6 prefixes, 1301 where gateway nodes are responsible for advertising their 1302 prefixes. 1304 o Protocol overhead: the solution adds certain overhead, depending 1305 on the network size, the number of IGWs, and the applied option in 1306 global address configuration. The resulting overhead in this 1307 solution mainly concerns: flooding of the local address selected 1308 by each joining node to verify its uniqueness through the DAD_REQ 1309 messages, prefix advertisement by IGWs during global address 1310 configuration (this has more impact on the overhead when the 1311 number of IGWs increases), and flooding of GC_REQ messages by the 1312 node requesting a global address (in case that no prefix 1313 advertisement is taking place by the IGWs) where in this case 1314 GC_REP messages are sent by IGWs through unicast. Furthermore, 1315 DAD_REPLY messages could take place in case of address conflicts 1316 detection. 1318 2.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc Networks (Wakikawa 1319 et al.) 1321 The solution described in [23] proposes how to provide Internet 1322 connectivity with mobile ad hoc networks. It describes how to obtain 1323 a globally routable IPv6 address from an Internet gateway. The 1324 Internet access method is not dependent on a particular MANET routing 1325 protocol. 1327 Assumptions: The solution assumes that before configuring a global 1328 IPv6 address, the node has configured a routable address (i.e. 1329 MANET-local address or a Mobile IPv6 home address). The routable 1330 address is used for initial configuration when a node boots up and 1331 joins the MANET. 1333 Approach description: This mechanism [23] is similar to [24] from the 1334 point of view of how IPv6 addresses are configured. Global prefix 1335 information is obtained from Internet gateways. Two methods are 1336 proposed for the Internet gateway discovery: one method periodically 1337 disseminates gateway advertisements to all nodes in the MANET; the 1338 other method utilises solicitation and advertisement signalling 1339 between a MANET node and the gateway. Extended router solicitation 1340 and advertisements of the Neighbour Discovery Protocol (NDP) or 1341 extended control message of each MANET routing protocol can be used 1342 for this signalling. The proposed methods target all MANET protocols 1343 regardless of whether they are reactive or proactive. Internet 1344 gateways supply their own global prefix information and IPv6 global 1345 address to MANET nodes somehow, either proactively or reactively. In 1346 this way, the reactive and proactive route discovery features of each 1347 MANET routing protocol are not disturbed. An advertisement from the 1348 Internet gateway provides prefix information -- IP routing prefix and 1349 prefix length -- and lifetime. 1351 After accepting an advertisement from the Internet gateway inserts 1352 the Internet gateway address as an Internet route and the MANET node 1353 configures a global address from the prefix of the Internet gateway. 1354 It uses the 64-bit interface ID in order to construct a valid address 1355 with the acquired prefix. It is assumed that before configuring a 1356 global IPv6 address, the node has configured a routable local address 1357 (i.e. MANET-local address), and a Non-unique Address Detection 1358 mechanism has been performed for that routable local address (e.g. 1359 using the mechanism defined in [3] and [25]), so it is assumed that 1360 the global address would be also unique. If not, the node may 1361 perform another Non-unique Address Detection mechanism for this 1362 global address. 1364 If the destination of a packet is inside the MANET even though a 1365 global routable address is used as destination address, the gateway 1366 prevents this packet from being forwarded to the Internet. It 1367 returns the packet back to the MANET if it has a MANET route for the 1368 destination. The source node receives an ICMP Redirect message from 1369 the Internet Gateway warning that it should use a host route (MANET- 1370 local address) instead of a default route (Internet route). To do 1371 so, each Internet gateway may manage a list of IP addresses of all 1372 the associated MANET nodes (mainly if a reactive ad hoc routing 1373 protocol is being used). So, each MANET node must contact the 1374 Internet gateway at least once it establishes an Internet route 1375 through the Internet Gateway in order to communicate its global 1376 routable address to the Internet Gateway. 1378 Based on [1], this solution has the following key features: 1380 o MANET scenario: the solution targets connected MANETs. 1382 o Routing protocols' dependency: Not restricted to any particular ad 1383 hoc routing solution, and it is designed to work properly with 1384 both proactive and reactive protocols. 1386 o Address uniqueness: It is assumed that the global address would be 1387 also unique. If not, the node may perform a Non-unique Address 1388 Detection mechanism for this global address. In any case the Non- 1389 unique Address Detection mechanism is considered out of scope. 1391 o Distributed/centralised approach: The proposed solution uses a 1392 distributed approach where nodes do not solicit any centralised 1393 server for IP address assignment. 1395 o Merging support: No special merging mechanisms are discussed in 1396 this solution. Also, no in-service Non-unique Address Detection 1397 is used which makes the merging support not feasible. 1399 o Prefix assignment support: the solution does not support the 1400 assignment of IPv6 prefixes to nodes. 1402 o Protocol overhead: depends on the approach utilised. If extended 1403 control messages of the MANET routing protocol -- including global 1404 prefix information -_ are used the solution introduces low 1405 overhead, but if gateway advertisement messages are periodically 1406 flooded (with the hop limit field set to an appropriate value in 1407 the MANET) then the solution introduces high overhead. 1409 2.2.1.5. Multihop Radio Access Network (MRAN) Protocol Specification 1410 (Hofmann) 1412 This proposed solution [26] presents the Multihop Radio Access 1413 Network (MRAN) protocol, which is an IPv6-based protocol for the 1414 interconnection of ad hoc networks and the Internet. MRAN proposes 1415 an approach that enables mobile ad hoc nodes to communicate with 1416 correspondent nodes on the Internet. The application scenario of 1417 this protocol is mainly when multiple gateways are available and 1418 mobile nodes are frequently changing these gateways. The gateways 1419 are supposed to be fixed and advertising different prefixes. MRAN 1420 treats the gateways discovery and selection, the autoconfiguration of 1421 global addresses, and the packet forwarding to/from the fixed 1422 network. 1424 Assumptions: It is assumed that mobile nodes (MNs) and Gateways (GWs) 1425 use local addresses for communication within the MANET and that 1426 routing is performed by a MANET routing protocol. It is also assumed 1427 that a flooding protocol is used for broadcasting certain MRAN 1428 control messages, where the flooding functionality may be provided by 1429 the routing protocol. 1431 Approach description: The operation of MRAN involves several 1432 functions: GW discovery, GW selection, address autoconfiguration, 1433 registration with the GW, packet forwarding and multi-hop handovers. 1434 Three modes of GW discovery are proposed and the choice between them 1435 depends on the application scenario. In proactive GW discovery, all 1436 GWs periodically broadcast advertisement messages "GW_ADV", where MNs 1437 in proactive mode requiring Internet access waits until they receive 1438 such a message. The reactive mode discovery allows MNs to discover 1439 the available GWs when needed through broadcasting a GW solicitation 1440 message. A GW receiving such a message replies by unicast solicited 1441 GW advertisement message "sol_GW_ADV" to the MN. Hybrid GW discovery 1442 mode is a combination of both proactive and reactive discovery, where 1443 the GW is in proactive mode and the MN is in reactive one. All GW 1444 advertisement messages contain the GW globally valid prefix of 64 1445 bits length. The GW selection process allows each MN to select the 1446 closet GW with respect to the number of hops. Other additional 1447 metrics may be included in the selection process. After the GW 1448 selection, the MN uses the selected GW's prefix and its own EUI-64 to 1449 autoconfigure the global address. It may subsequently perform a Non- 1450 unique Address Detection. Registration with the selected GW should 1451 take place, where the MN sends a registration request message 1452 "MN_REG" to the selected GW. A GW receiving this message replies by 1453 a registration acknowledgement message "MN_REG_ACK" indicating the 1454 successful registration. The MN then periodically repeats the 1455 registration process and the registration may be used for other 1456 purposes as well (for instance the AAA). To assure appropriate 1457 packet forwarding between each MN and its selected GW, payload 1458 packets are tunnelled between MNs and GWs in both directions. The 1459 tunnelling approach uses IP-in-IP encapsulation thus allowing using 1460 local addresses for intra-MANET communication. In the tunnel from 1461 the GW to the MN, the destination address of the inner IP header is 1462 the MN global address and the destination address of the outer header 1463 is the local address of the MN. On the other hand, in the tunnel 1464 from the MN to the GW, the destination address of the inner IP header 1465 is the CN global address, whereas the destination address of the 1466 outer header is the local address of the GW. In the case of MN's 1467 disconnection from its current GW while communicating with a CN in 1468 the Internet, multihop handover takes place. Thus, the MN has to 1469 discover, select and register with another GW. This is called a 1470 "forced multihop handover". For optimisation reasons, the MN may 1471 also select a new GW that could be more close than the current GW. 1472 In this case, the MN performs the registration with the new GW while 1473 it is connected to the current one. This is known as "optimised 1474 multihop handover", and is much faster than the forced one. 1476 Maintenance takes place through creating two tables: i) GW table, and 1477 ii) MN table. MNs maintain a GW table storing information about the 1478 available GWs (local address, prefix, expiration time, registration 1479 expiration). A table entry is created when the MN receives a GW_ADV 1480 or Sol_GW_ADV messages. On the other hand, GWs maintain MN tables 1481 storing information about mobile nodes having a valid registration, 1482 where each entry in this table stores the following information on 1483 MNs (local address, global address, registration expiration time). 1485 Based on [1], this solution has the following key features: 1487 o MANET scenario: This proposed solution targets connected MANET 1488 scenarios enabling mobile nodes to communicate with correspondent 1489 nodes in the Internet. 1491 o Routing protocols' dependency: This proposed solution works 1492 independent of the MANET routing protocol. 1494 o Address uniqueness: The proposed solution may use a Non-unique 1495 Address Detection mechanism. 1497 o Distributed/Centralised approach: The proposed solution uses a 1498 distributed approach, where it does not solicit any centralised 1499 server for IP address assignment. 1501 o Merging support: No special merging mechanisms are discussed in 1502 this solution. Also, no in-service Non-unique Address Detection 1503 is used which makes the merging support not feasible. 1505 o Prefix assignment support: This proposed solution supports 1506 prefixes assignment, where the different gateways are responsible 1507 for IPv6 prefixes advertisements. 1509 o Protocol overhead: the solution integrates several mechanisms and 1510 there is a number of flooding used to achieve the proper 1511 mechanisms' functioning. The overhead in this solution mainly 1512 lies in the assumption of an existing flooding protocol for 1513 broadcasting certain MRAN control messages, and GWs periodical 1514 broadcast of GW_ADV messages (containing the GW prefix) when 1515 proactive GW discovery is applied. Also, GW_Solicitation messages 1516 are broadcast on-demand when reactive GWs discovery is applied, 1517 and periodical MN_REG messages are sent to the selected GWs by 1518 each node requesting an IP address which is acknowledged by a 1519 MN_REG_ACK by the selected GW. Furthermore, additional messages 1520 are used for maintenance. 1522 2.2.1.6. Automatic IP Address Configuration in VANETs (Fazio et al.) 1524 Automatic IP address configuration is a challenging and still 1525 unexplored issue in vehicular ad hoc networks (VANETs) environments, 1526 where the vehicles' high mobility and variant density impede the 1527 direct utilisation of traditional networking techniques and 1528 protocols. Aiming at integrating VANETs within the Internet and 1529 providing passengers with any kind of Internet applications, the IP 1530 address represents the natural identifier in the system. This work 1531 [27] proposes an IP autoconfiguration solution in VANETs environment, 1532 exploiting the VANETs topology and an enhanced DHCP service with 1533 dynamically elected leaders to provide a fast and reliable IP address 1534 configuration. 1536 Assumptions: It is assumed that the network topology is linear and 1537 that a group of nodes move following a track with an internal 1538 mobility with respect to each other. It is also assumed that the 1539 relative speed between nodes is low. 1541 Approach description: This work proposes a novel automatic IP address 1542 configuration protocol named Vehicular Address Autoconfiguration 1543 (VAC), that is characterised by a low configuration time. VAC 1544 represents the first protocol for IP address configuration in VANETs. 1545 It exploits the VANET topology and a distributed dynamic host 1546 configuration protocol (DHCP) runs by dynamically elected leader 1547 vehicles to quickly provide unique identifiers and reduce the 1548 frequency of IP address re-configurations due to mobility. VAC 1549 organises leaders in a connected chain such that every node (vehicle) 1550 lies in the communication range of at least one leader. This 1551 hierarchical organisation allows limiting the signal overhead for the 1552 address management tasks. Only leaders communicate with each others 1553 to maintain updated information on configured addresses in the 1554 network. Leaders act as servers of a distributed DHCP protocol and 1555 normal nodes ask leaders for a valid IP address whenever they need to 1556 be configured. 1558 VAC guarantees unique IP addresses within a defined SCOPE around the 1559 leader, where the SCOPE of the leader A is the set of leaders whose 1560 distance from A is less or equal to SCOPE hops. Considering the 1561 normal node Y that received the IPy address from A, IPy will be 1562 unique as long as Y moves within the SCOPE of A. If Y goes out of the 1563 SCOPE of A, in order to still ensure the address uniqueness, Y has to 1564 ask the new leader for another address. Considering that the 1565 relative speed between the nodes is low, changes in the address 1566 configuration due to having left the own leader's SCOPE are not 1567 frequent. 1569 Based on [1], this solution has the following key features: 1571 o MANET scenario: The proposed solution targets connected MANET 1572 scenarios, enabling mobile nodes (vehicles) to communicate with 1573 correspondent nodes on the Internet. 1575 o Routing protocols' dependency: Apparently VAC does not depend on a 1576 special routing protocol. However no clear definition is given on 1577 how and what control messages are exchanged in order to configure 1578 each node requiring an IP address. 1580 o Address uniqueness: The proposed solution does not employ any Non- 1581 unique Address Detection mechanisms, however it guarantees address 1582 uniqueness for each configured node. 1584 o Distributed/Centralised approach: The proposed solution employs a 1585 partially distributed approach, where distributed DHCP run by some 1586 mobile nodes (vehicles)that are elected in a dynamic manner to 1587 assign IP addresses to the requesting nodes. 1589 o Merging support: No special merging mechanisms are explained in 1590 this proposed solution, however it could support merging. The 1591 SCOPE principle together with the distributed DHCP permit the 1592 nodes to join/leave different SCOPES while acquiring a new address 1593 from the SCOPE leader. 1595 o Prefix assignment support: This proposed solution does not employ 1596 any IPv6 prefix assignment to nodes. 1598 o Protocol overhead: the hierarchical organisation in this solution 1599 limits the signalling overhead and avoids flooding. The overhead 1600 in this solution mainly concerns: the signalling messages for 1601 communication between leaders nodes, the request messages sent by 1602 mobile nodes requesting an IP address from their leaders (this 1603 takes place in a limited scope), and the reply messages from the 1604 leaders to the requesting mobile nodes for assigning IP addresses 1605 (this also takes place in a limited scope). It is noticed that 1606 this solution does not use Non-unique Address Detection mechanisms 1607 due to the distributed DHCP functionality among leader nodes, 1608 which helps in limiting the signalling overhead. 1610 2.2.1.7. Address Configuration Using Address Pool (Ahn et al.) 1612 This address autoconfiguration mechanism -- proposed in [28] -- is 1613 based on the concept of address pool allocation in connected MANETs 1614 scenarios. This mechanism allows stable and fast global IP address 1615 configuration based on the DHCP. 1617 Assumptions: It is assumed that the Internet gateway acts a DHCP 1618 server having the pool of IP addresses and assigning a part of this 1619 IP address pool to each node requesting an IP address. It is also 1620 assumed that each node having an address pool could assign a part of 1621 this address pool to other IP address requesting nodes. Each node 1622 then plays the role of a DHCP server. The lifetime of the address 1623 pool is assumed to be infinite. 1625 Approach description: This solution basically works as follows: the 1626 Internet gateway periodically broadcasts Router Advertisement (RA) 1627 messages to the entire MANET and each MANET node receiving the RA 1628 message can request for IP addresses through sending a unicast 1629 DHCP_Request message to the Internet gateway. When the Internet 1630 gateway received the DHCP_Request message, it allocates a part of its 1631 address pool and sends it to the address requesting node in a 1632 DHCP_Reply message. At the same time, any intermediate node 1633 receiving the DHCP_Request message and having a big address pool 1634 intercepts the message and allocates a part of its address pool 1635 instead of the Internet gateway and sends it to the address 1636 requesting node in a DHCP_Reply message. Each node with the 1637 allocated address pool assigns one address to its interface and keeps 1638 the rest of the address pool for later allocation to other MANET 1639 nodes requesting addresses. 1641 No renewal takes place for the allocated address pool, as the valid- 1642 lifetime field in the DHCP_Reply message is set to an infinite value 1643 reflecting an infinite use of the address pool. However, the 1644 Internet gateway broadcasts to the entire MANET an Address Pool 1645 Release Request (APRR) message when the size of its address pool 1646 arrives below a pre-defined threshold. Each node receiving the APRR 1647 message replies by an Address Pool Release Reply (APRP) message 1648 allowing the Internet gateway to know which addresses are being used 1649 or assigned. 1651 Based on [1], this solution has the following key features: 1653 o MANET scenario: the solution targets connected MANETs, however, it 1654 could be applied to standalone MANETs if some dedicated nodes are 1655 previously allocated address pools in order to allocate part of 1656 these pools to other IP requesting nodes in a standalone MANET. 1658 o Routing protocols' dependency: the solution is routing protocol 1659 independent. 1661 o Address uniqueness: the proposed solution guarantees address 1662 uniqueness since each node is assigned an address from an address 1663 pool allocated from a global address pool. 1665 o Distributed/Centralised approach: the solution is partially 1666 distributed, where it relies on a centralised DHCP server and at 1667 the same time each node plays the role of a DHCP server. 1669 o Merging support: the solution does not support merging. 1671 o Prefix assignment support: the solution does not support the 1672 assignment of IPv6 prefixes. 1674 o Protocol overhead: the solution requires additional messages 1675 flooding by the Internet gateway for announcing its address pool 1676 and to get information on the different address pools assignment. 1678 2.2.1.8. Address Autoconfiguration for MANET with Multiple MBRs (Lee et 1679 al.) 1681 This address autoconfiguration mechanism -- proposed in [29] -- is 1682 based on PMIPv6 (Proxy Mobile IPv6) mechanism in which a Local 1683 Mobility Anchor (LMA) is located and acts as a Home Agent (HA) while 1684 multiple MBRs (MANET Border Router) are used for scalable and 1685 reliable communication between each MANET node and the external 1686 network. The proposed solution prevents against the session 1687 termination or the non-optimal paths use during packet transmission 1688 when the MANET node changes the MBR. 1690 Assumptions: It is assumed that all MBRs advertise the same network 1691 prefix in the connected MANET, and that each node configures its IP 1692 address using the stateless address autoconfiguration mechanism 1693 making use of the advertised network prefix. 1695 Approach description: This solution basically works as follows: since 1696 all MBRs advertise the same network prefix, when a node moves it can 1697 still use its pre-configured address. This allows for maintaining 1698 the existing sessions even with node movement and allows for finding 1699 an optimised path by the node without changing the IP address. Each 1700 MBR periodically advertises Scope-Extended Router Advertisement 1701 (SERA) messages to the entire MANET. This message includes the 1702 network prefix assigned to the MANET and the address of the MBR 1703 originating the message. A MANET node connecting for the first time 1704 receives the SERA message and configures the IPv6 address of its 1705 MANET interface using the stateless address autoconfiguration 1706 mechanism based on the node MAC address, the obtained network prefix 1707 and the network prefix length. Then the node sets the originating 1708 MBR as its default gateway and stores in its routing table the 1709 distance from this MBR as well as the next-hop to this MBR (which is 1710 extracted from the source IP address field of the received message). 1711 The node then sends a Registration Request (RR) message to this MBR, 1712 where this latter sends a Proxy Binding Update (PBU) message with the 1713 MANET node to the LMA. After that, a tunnel between the LMA and MBR 1714 is established for the MANET node. 1716 Since SERA messages are periodically advertised by each MBR, a node 1717 can receive multiple SERA messages advertised by the same MBR but 1718 through more optimal paths or advertised by new MBR than the default 1719 one. In the former case, the node could update the next-hop to its 1720 default MBR with no need to change the node address. In the latter 1721 case, the node can update its default MBR without changing its IP 1722 address since all MBRs advertise the same network prefix. The node 1723 only needs to send an RR message to the new MBR for the binding with 1724 this it following the same binding process explained above. 1726 Based on [1], this solution has the following key features: 1728 o MANET scenario: the solution targets connected MANETs. 1730 o Routing protocols' dependency: the solution is routing protocol 1731 independent, however the routing table is used to store 1732 information about the default gateway, the distance from it and 1733 the next hop to it. 1735 o Address uniqueness: the proposed solution guarantees address 1736 uniqueness since each node constitutes its IP address using the 1737 stateless IP autoconfiguration approach, employing its MAC 1738 address, the network prefix, and the prefix length. 1740 o Distributed/Centralised approach: the solution does not make use 1741 of any centralised server, however distributed gateways are 1742 involved. 1744 o Merging support: the solution does not support merging. 1746 o Prefix assignment support: the solution allows the assignment of 1747 IPv6 prefixes, where the same IPv6 prefix is broadcast by the 1748 different gateway nodes (MBRs). 1750 o Protocol overhead: the solution requires additional messages 1751 flooding by MBRs nodes (Scope Extended Router Advertisement 'SERA' 1752 message). 1754 2.2.1.9. Border Router Discovery Protocol (BRDP) based Address 1755 Autoconfiguration (Boot et al.) 1757 This address autoconfiguration mechanism -- proposed in [30] -- 1758 describes a solution for configuring valid global IPv6 addresses for 1759 ad hoc nodes. It is based on the discovery of MANET Border Routers 1760 (MBRs), which are responsible of advertising topologically valid IPv6 1761 prefixes, which can then be used by the ad hoc nodes. 1763 Assumptions: It is assumed that there is at least one MBR advertising 1764 a valid global IPv6 address. The Border Router Discovery Protocol 1765 (BRDP) is defined for Border Router discovery. For standalone 1766 MANETs, the solution derives in the use of Unique Local Addresses 1767 (ULAs) generated by the individual MANET routers. 1769 Approach description: This solution basically uses two phases: a) the 1770 initial discovery of one or more Border Routers, and b) the selection 1771 of a Border Router and address autoconfiguration of globally routable 1772 IPv6 addresses to be used in conjunction with that Border Router. 1773 The BRDP is a simple distance vector protocol that distributes Border 1774 Router information, where each MANET router selects one or more 1775 Border Routers and forwards the Border Router information in the 1776 MANET. It basically extends the IPv6 Neighbor Discovery Protocol 1777 (NDP) to make it carry the required information (e.g., prefix 1778 information). 1780 BRDP is a derivative of Tree Discovery [31]. BRDP uses ICMP Router 1781 Advertisement (RA) messages in NDP to distribute Border Router 1782 information by extending it with the Border Router Information Option 1783 (BRIO). BRDP allows MANET Routers to advertise Border Router 1784 reachability, including information for selecting a preferred Border 1785 Router. A MANET Router selects at least one BRIO from its cache, for 1786 dissemination in the MANET. 1788 The address generated has a /128 prefix. It is constructed from a 1789 64-bit Interface Identifier -- which is assumed to be unique (it is 1790 not specified how the MANET router generates this identifier, 1791 although several alternative approaches are proposed) -- and a 64-bit 1792 prefix (advertise in the BRIO). The generated 128-bit address is 1793 advertised in the MANET routing system. 1795 Based on [1], this solution has the following key features: 1797 o MANET scenario: the solution targets connected MANETs. 1799 o Routing protocols' dependency: the solution is routing protocol 1800 independent. A companion document [32] can be used in a multi- 1801 homed scenario (i.e. multiple MBRs available) to replace the 1802 default route mechanism. 1804 o Address uniqueness: address uniqueness is assured by the IPv6 1805 address generation mechanisms used. However, details on how to 1806 handle a duplicate address condition are stated as out-of-scope 1807 for the document describing this solution. 1809 o Distributed/Centralised approach: the solution does not make use 1810 of any centralised server, however distributed gateways are 1811 involved. 1813 o Merging support: the solution does not support merging (as it is 1814 not specified how to handle duplicate addresses). 1816 o Prefix assignment support: the solution does not allow the 1817 assignment of IPv6 prefixes. 1819 o Protocol overhead: the solution requires additional messages 1820 flooding by MBRs nodes (BRIOs). 1822 2.2.2. Merging support 1824 2.2.2.1. Address Autoconfiguration in Optimized Link State Routing 1825 Protocol (Adjih et al.) 1827 This proposed solution [33] is based on the concept of conflict 1828 detection. Each node periodically sends its address and an 1829 identifier. The node identifier is a sequence of bits, of fixed 1830 length (L), that is randomly generated. An address conflict is 1831 detected when the identifier mismatches. This proposed solution is 1832 suitable for OLSR routing protocol with a light increase of control 1833 message overhead, however, it might be used with any MANET protocol. 1834 Two issues are addressed in this solution, an IPv6 stateless 1835 autoconfiguration mechanism and a mechanism promoting address 1836 uniqueness in the situation where different ad hoc networks merge. 1838 Assumptions: Two assumptions are mainly considered in this proposed 1839 solution. Firstly, it is assumed that the identifier of each node is 1840 globally unique in the network. Secondly, it is assumed that a MANET 1841 may be isolated. 1843 Approach description: In this proposed solution, a new mobile node 1844 joining the network is assigned an IP address then it carries out a 1845 conflict detection procedure through running a Non-unique Address 1846 Detection mechanism. If another node is detected to have the same 1847 address, the new joining node selects a new address. The address 1848 assignment process takes place as follows: i)consulting a neighbour 1849 node that should configure an address for the new node. The 1850 neighbour node then selects an IP address and sends it to the new 1851 node. This takes place by control messages exchange. ii) picking up 1852 a random address inside a given subnet with MANET_prefix either from 1853 a pool of allocated addresses or through a set of addresses 1854 advertised by each MANET node and are believed not used. In case of 1855 address pool existence, this pool could be reserved by the IANA for 1856 local use only (i.e. not forwarded outside MANET). In addition, in 1857 case of MANETs connected to the Internet, nodes acting as gateways 1858 diffuse IPv6 router advertisement messages. In this case each 1859 address in the pool would be a global address that can be seen from 1860 the outside. 1862 The Non-unique Address Detection algorithm uses a single special 1863 control message to perform conflict detection. Each node 1864 periodically diffuses to the entire network a special message called 1865 MAD (Multiple Address Declaration). This message contains the node 1866 address and a unique identifier for the node. Several mechanisms are 1867 proposed for MAD messages propagation. When using OLSR, propagation 1868 of MAD messages mainly relies on the MPR flooding, where a number of 1869 MPR selection rules are explained, presenting different options. If 1870 another routing protocol is used, default pure flooding is used for 1871 MAD messages propagation. In case of IP conflict discovery, this is 1872 resolved by the node with the smaller identifier in each conflicting 1873 pair. This node should change its IP, selecting a new IP at random 1874 (that is believed to be free) following the same approach of IP 1875 address assignment. 1877 When OLSR routing protocol is used, an additional proposed option is 1878 using Passive Duplicate Detection. In this case, the topological 1879 information diffused by the OLSR routing protocol is sufficient to 1880 detect address conflict. However, some MPR selection mechanisms are 1881 used to ensure that the control messages are properly propagated. 1883 Based on [1], this solution has the following key features: 1885 o MANET scenario: This proposed solution targets both standalone and 1886 connected MANETs scenarios. 1888 o Routing protocols' dependency: This proposed solution depends on 1889 the underlying routing protocol. 1891 o Address uniqueness: the proposed solution comprises a Non-unique 1892 Address Detection mechanism. The notion of passive duplicate 1893 detection is also used, where the solution makes use of the 1894 routing protocol messages propagation to detect the address 1895 conflicts. 1897 o Distributed/Centralised approach: The proposed solution uses a 1898 distributed approach in the sense of not communicating with a 1899 centralised DHCP server to acquire IP addresses. 1901 o Merging support: This proposed solution has a merging support, 1902 since the conflict detection process is periodically carried out 1903 by mobile nodes. Thus, this solution assures address uniqueness 1904 in case of ad hoc networks merge. 1906 o Prefix assignment support: This solution does not support IPv6 1907 prefix assignment to nodes. 1909 o Protocol overhead: the solution adds low protocol overhead, since 1910 this solution benefits from the OLSR routing protocol signalling 1911 and MPRs concept to verify the address conflicts. The signalling 1912 in this solution is limited to a single control message (MAD 1913 message) to perform conflicts detection. If passive duplicate 1914 detection option is applied with OLSR, the overhead is almost 1915 none, as the topological information diffused by OLSR is 1916 sufficient to detect address conflict. However, if another 1917 routing protocol is used (which is an option), the MAD messages 1918 have to be flooded resulting in a 'medium' overhead since the 1919 flooding is limited to only one message in this case. 1921 2.2.2.2. Extended Support for Global Connectivity for IPv6 Mobile Ad 1922 Hoc Networks (Cha et al.) 1924 The solution described in [34] proposes a stateful global IP 1925 autoconfiguration for MANETs with the goal of providing enhanced 1926 Internet connectivity to mobile ad-hoc networks. This stateful 1927 autoconfiguration is performed through the exchange of extended 1928 control messages of MANET routing protocols. The protocol is devised 1929 as an extension to AODV, but the concept may be applicable to 1930 proactive routing protocols. 1932 Assumptions: The solution assumes that each node has a 1933 local_IP_address configured. 1935 Approach description: The protocol basically consists in nodes 1936 requesting global addresses to a gateway, which assigns a non-used 1937 address to the requesting node. When an ad hoc node needs a global 1938 IP address it sends an Internet-gateway solicitation message (GW_SOL 1939 message). The Gateway uses an Internet-gateway advertisement(GW_ADV 1940 message)to assign the solicited global IP address to the ad hoc node. 1942 Given the event that an ad hoc node which has a Global IP address 1943 (e.g., G-A1) assigned by a gateway (e.g., GW1) cannot reach GW1 1944 anymore due to a partition in the MANET but this ad hoc node has 1945 Internet connectivity through a different gateway (e.g.. GW2), the 1946 ad hoc node gets another global IP address from GW2 (e.g., G-A2) and 1947 it performs a Locator Registration Procedure with GW1. This locator 1948 registration procedure is similar to Binding Updates in Mobile IPv6. 1949 Using this procedure the ad hoc node registers G-A2 as CoA -- Care of 1950 Address in Mobile IPv6 terminology -- of G-A1, so that ongoing 1951 communications are kept. 1953 More details can be found in [34]. 1955 Based on [1], this solution has the following key features: 1957 o MANET scenario: the solution targets connected MANETs. 1959 o Routing protocols' dependency: although the protocol is devised as 1960 an extension to AODV, it could be applicable to proactive routing 1961 protocols. 1963 o Address uniqueness: since non-duplicate addresses are assigned to 1964 ad hoc nodes, the proposed solution is Non-unique Address 1965 Detection-free. 1967 o Distributed/centralised approach: the solution makes use of 1968 centralised servers (gateways) in order to assign IP global 1969 addresses. 1971 o Merging support: given that the proposed solution assigns global 1972 IP addresses avoiding duplicates, merging is supported. On the 1973 other hand it supports partitions through the Locator Registration 1974 Procedure. 1976 o Prefix assignment support: the solution does not support the 1977 assignment of IPv6 prefixes to nodes. 1979 o Protocol overhead: the solution adds certain protocol overhead, 1980 since the mechanism appends some fields to AODV routing protocol 1981 (RREQ message) to ask for a global IP address and gateway 1982 information, and the replay (GW-ADV message) is unicast to the 1983 originator MANET node. The solution includes the possibility of 1984 gratuitous GW_ADV broadcast periodically. 1986 2.2.2.3. Gateway and Address Autoconfiguration for IPv6 Adhoc Networks 1987 (Jelger et al.) 1989 This proposed solution [24] allows nodes in an ad hoc network to 1990 proactively discover a gateway/prefix pair to be used in building an 1991 IPv6 global address and to maintain a default route towards the 1992 Internet. The core element of this proposed solution is the concept 1993 of "Prefix Continuity". With prefix continuity, any node A that 1994 selected a given prefix P has at least one neighbour with prefix P on 1995 its path to the selected gateway G, thus assuring that each node on 1996 the path between node A and the Gateway G uses the same prefix P. 1998 Assumptions: It is assumed that each node can find a Gateway to 1999 connect with and that each node can be assigned a global address 2000 through this gateway. It is also assumed that one (or possibly more) 2001 nodes of the ad hoc network should provide connectivity to the 2002 Internet, thus acting as Gateways to other nodes. 2004 Approach description: In this proposed solution, each Gateway (GW) 2005 periodically sends a GW_INFO message notifying nodes in the ad hoc 2006 network about its existence as well as the prefix it uses. Some 2007 information in the GW_INFO message allows nodes to select the more 2008 appropriate GW when more than one GW exist. Other information 2009 contained in this message concerns: the GW global address, the length 2010 of the prefix part of the address, and the distance to the gateway as 2011 perceived by the node sending the message. The node receiving the 2012 GW_INFO message forwards it to its 1-hop neighbourhood, where the 2013 forwarder node is considered as the upstream node for each node that 2014 receives the message. Among the transmitted GW-Info messages, each 2015 mobile node selects (through a selection algorithm) only one 2016 neighbour as its upstream neighbour and receives the GW_INFO messages 2017 from this neighbour (i.e. consider this upstream as an intermediate 2018 node to the gateway), then it forwards the message. A node must not 2019 forward a GW_INFO message sent by a node that is not its upstream 2020 neighbour. The destination address of the IPv6 header of the packet 2021 containing the GW_INFO message must be FF02::1 (all nodes), while the 2022 source address of such a packet must be the link local address of the 2023 sender. Thanks to the prefix continuity, the routing via the GW can 2024 be achieved without the need of an IPv6 routing header. Each mobile 2025 node creates its IPv6 global address as follows: {Extended Unique 2026 Identifier (EUI) of the interface from which the GW_INFO message is 2027 received + prefix contained in the message}. No Non-unique Address 2028 Detection mechanism is needed in this approach, as there is a very 2029 little probability of address duplication when EUI is used. 2031 More details can be found in [35]. 2033 Based on [1], this solution has the following key features: 2035 o MANET scenario: This proposed solution targets connected MANETs 2036 scenarios. 2038 o Routing protocols' dependency: This proposed solution is 2039 independent (in terms of message semantics) of the underlying 2040 routing protocol. Thus, it can be integrated in the operation of 2041 the routing protocol or it can run as standalone daemon. 2043 o Address uniqueness: The proposed solution does not depend on a 2044 Non-unique Address Detection procedure or mechanism. 2046 o Distributed/Centralised approach: The proposed solution is 2047 distributed in the sense of not employing any centralised DHCP 2048 server. 2050 o Merging support: Although no Non-unique Address Detection 2051 mechanism is used, this proposed solution supports networking 2052 partitioning and merging as it is based on generating an IPv6 2053 address for each node based on the prefix advertisements. 2055 o Prefix assignment support: This proposed solution is based on the 2056 prefix continuity and is thus supporting prefix assignment. Each 2057 gateway advertises the IPv6 prefix that it uses. 2059 o Protocol overhead: depends on the network size and the number of 2060 GWs. The main signalling in this solution mainly concerns the 2061 GW_INFO messages that are periodically sent by each GW notifying 2062 its existence as well as its prefix. Since no Non-unique Address 2063 Detection mechanism is needed in this solution, this helps in 2064 limiting the signalling and hence the overhead. 2066 2.2.2.4. VET, SEAL, RANGER (Templin et al.) 2068 NOTE from authors: this section needs further revision to catch up 2069 with all the updates of Templin proposals. 2071 Here we refer to a set of different documents that provide 2072 functionalities that can be used to enable IPv6 address 2073 autoconfiguration in MANETs. RFC5558 [36] specifies a Virtual 2074 Enterprise Traversal (VET) abstraction for autoconfiguration and 2075 operation of routers in enterprise networks. Enterprise networks 2076 connect routers over various link types. Since certain MANETs can be 2077 considered as a challenging example of an enterprise network, the 2078 mechanisms described in this document can be applied to provide 2079 MANETs with IP address autoconfiguration capabilities. This document 2080 has evolved a lot from its previous versions (and companion 2081 documents, such as [37] and [38], in which the author started to 2082 define an architecture in which MANET Routers were attached to an 2083 imaginary shared link (called "virtual ethernet") that connected all 2084 the MRs in the MANET. Other documents that complement VET are SEAL 2085 [39] and RANGER [40]. 2087 Assumptions: It is assumed the existence of Enterprise Border 2088 Gateways (EBRs), that are routers that connect the enterprise network 2089 to provider networks and can delegate addresses/prefixes to other 2090 EBRs within the enterprise. 2092 Approach description: Regarding the applicability of the document to 2093 MANETs, it defines the Virtual Enterprise Traversal (VET), which is 2094 an abstraction that uses IP-in-IP encapsulation to span a multi-link 2095 enterprise in a single (inner) IP hop. VET interfaces are Non- 2096 Broadcast, Multiple Access interface used for VET, which encapsulate 2097 each inner IP packet in any mid-layer headers plus an outer IP header 2098 then forwards it on an underlying interface such that the TTL/Hop 2099 Limit in the inner header is not decremented as the packet traverses 2100 the enterprise network. In this way, the VET interface presents an 2101 automatic tunnelling abstraction that represents the enterprise as a 2102 single IP hop. 2104 In order to autoconfigure a VET interface, the interface is first 2105 initialised (a link-local address is configured on the interface), 2106 then border routers (Enterprise Border Gateways, EBGs) are 2107 discovered, and last, IPv6 SLAAC is run on top of the VET. EBGs 2108 plays the role of access routers (i.e., send Router Advertisements), 2109 so standard IPv6 SLAAC mechanisms can be used to configure VET 2110 interfaces. DHCPv6 prefix delegation can also be used to configure a 2111 VET interface. 2113 Based on [1], this solution has the following key features: 2115 o MANET scenario: the solution targets connected MANETs. 2117 o Routing protocols' dependency: the solution is routing protocol 2118 independent. 2120 o Address uniqueness: the proposed solution reuses SLAAC and DHCP 2121 mechanisms, by providing an abstraction that represents the 2122 enterprise network as a single IP hop. 2124 o Distributed/centralised approach: the solution makes use of border 2125 routers (EBRs) in a similar way that routers sending Router 2126 Advertisements are used by SLAAC, or DHCPv6 servers are used when 2127 DHCPv6 prefix delegation is used. 2129 o Merging support: the solution supports merging. 2131 o Prefix assignment support: the solution supports the assignment of 2132 IPv6 prefixes to nodes. 2134 o Protocol overhead: it does not add much overhead compared with 2135 SLAAC and DHCPv6. It adds some overhead in terms of tunneling 2136 headers due to the VET approach. 2138 2.2.2.5. A DHCP-based IP address autoconfiguration for MANETs 2139 (Bernardos et al.) 2141 In this autoconfiguration mechanism -- proposed in [41] -- the first 2142 node that falls into the radio coverage of an access network uses 2143 DHCPv6 to get a global IPv6 prefix to be shared in the MANET. 2145 Assumptions: It assumes the existence of a DHCP server in the access 2146 router giving access to the Internet. 2148 Approach description: This solution basically works as follows: The 2149 first step is obtaining a global IPv6 prefix to be shared in the 2150 MANET (i.e., the MANET prefix). This task is done by the first node 2151 in the coverage of an access network (i.e., the initiator), using 2152 DHCPv6. The initiator node gets from this MANET prefix a /64 for 2153 itself and starts sending routers advertisements through its ad hoc 2154 interface. Each RA contains a new option (MANET DHCP Prefix 2155 Delegation Information) that indicates to the receivers that the 2156 sender of the RA is able to delegate prefixes using DHCPv6. 2158 Receivers of these RAs, that is, new arriving nodes, may then 2159 configure an IPv6 address from the prefix contained in the RA (i.e., 2160 performing normal IPv6 stateless address auto-configuration). These 2161 nodes may then request an IPv6 prefix for themselves using, using 2162 DHCPv6. The initiator node delegates each of them a /64 prefix, 2163 keeping track of how many /64 prefixes from the MANET preix are still 2164 available for distribution. 2166 These MANET nodes configure their interfaces with addresses from the 2167 prefix they have just obtained and start sending RAs containing this 2168 prefix. This enables other nodes that are within the radio coverage 2169 of these MANET nodes to obtain IPv6 addresses and request IPv6 2170 prefixes. When a MANET node, other than the initiator node, receives 2171 a DHCPv6 prefix request, it generates a new request and sends it to 2172 one node capable of delegating prefixes. In this way requests are 2173 recursively generated until they reach the initiator node, which then 2174 generates a DHCPv6 reply with the delegated prefix. Again, replies 2175 are recursively sent backwards until they reach the unconfigured 2176 nodes that requested the prefixes. 2178 Based on [1], this solution has the following key features: 2180 o MANET scenario: the solution targets connected MANETs. 2182 o Routing protocols' dependency: the solution is routing 2183 independent. 2185 o Address uniqueness: The solution reuses SLAAC and DHCP mechanisms. 2187 o Distributed/centralised approach: the MANET does not make use of 2188 any centralised server, but all the nodes have the potential to 2189 ask for a prefix to the DHCP server on the infrastructure, and 2190 becomes a router sending Router Advertisements are used by SLAAC. 2192 o Merging support: given that the proposed solution assigns global 2193 IP addresses avoiding duplicates, merging is supported. 2195 o Prefix assignment support: the solution support the assignment of 2196 IPv6 prefixes to nodes. 2198 o Protocol overhead: it does not add much overhead compared with 2199 SLAAC and DHCPv6. RAs include a new option that indicates to 2200 receivers that the sender of the RA is able to delegate prefixes 2201 using DHCPv6. 2203 3. Security Considerations 2205 Due to the open wireless environment of ad hoc networks, IP 2206 autoconfiguration mechanisms are susceptible to a number of attacks. 2208 4. IANA Considerations 2210 This document has no actions for IANA. 2212 5. Acknowledgements 2214 We would like to thank all the AUTOCONF ML people that provided 2215 comments to the previous version of the I-D. We would also like to 2216 thank Kilian Weniger for his useful review of this draft, and Thomas 2217 Clausen for his review and support on the continuity of this draft in 2218 another shape. 2220 The work of Carlos J. Bernardos and Maria Calderon has been partially 2221 supported by the Ministry of Science and Innovation of Spain under 2222 the QUARTET project (TIN2009-13992-C02-01). 2224 The work of Carlos J. Bernardos has also been partially supported by 2225 the EU through the ICT FP7 European Project CARMEN (INFSO-ICT- 2226 214994). Apart from this, the European Commission has no 2227 responsibility for the content of this Internet-Draft. The 2228 information in this document is provided as is and no guarantee or 2229 warranty is given that the information is fit for any particular 2230 purpose. The user thereof uses the information at its sole risk and 2231 liability. 2233 6. References 2235 6.1. Normative References 2237 [1] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation 2238 Considerations for IP Autoconfiguration Mechanisms in MANETs", 2239 draft-bernardos-autoconf-evaluation-considerations-03 (work in 2240 progress), November 2008. 2242 6.2. Informative References 2244 [2] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc 2245 Networks", draft-ietf-autoconf-adhoc-addr-model-03 (work in 2246 progress), March 2010. 2248 [3] Perkins, C., "IP Address Autoconfiguration for Ad Hoc 2249 Networks", draft-perkins-manet-autoconf-01 (work in progress), 2250 November 2001. 2252 [4] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large 2253 Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002. 2255 [5] Jeong, J., "Ad Hoc IP Address Autoconfiguration", 2256 draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress), 2257 January 2006. 2259 [6] Jeong, J., "Ad Hoc IP Address Autoconfiguration for AODV", 2260 draft-jeong-manet-aodv-addr-autoconf-01 (work in progress), 2261 July 2004. 2263 [7] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc 2264 Networks", MOBIHOC'02 , 2002. 2266 [8] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile 2267 Ad Hoc Network", MILCOM 2002 , 2002. 2269 [9] Tayal, A. and L. Patnaik, "An address assignment for the 2270 automatic configuration of mobile ad hoc networks", Personal 2271 Ubiquitous Computing , 2004. 2273 [10] Chen, Y., Fleury, E., and T. Razanfindralambo, "Scalable 2274 Address Allocation Protocol for Mobile Ad Hoc Networks", Fifth 2275 International Conference on Mobile Ad-hoc and Sensor Networks , 2276 2009. 2278 [11] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR", 2279 draft-mase-manet-autoconf-noaolsr-01 (work in progress), 2280 April 2006. 2282 [12] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad 2283 hoc Networks", IEEE Wireless Communications and Networking 2284 Conference (WCNC) , 2003. 2286 [13] Weniger, K., "PACMAN: Passive autoconfiguration for mobile ad 2287 hoc networks", IEEE Journal on Selected Areas in 2288 Communications, vol. 23, no. 3, Mar 2005 pp. 507-519 , 2005. 2290 [14] Mase, K. and K. Weniger, "PDAD-OLSR: Passive Duplicate Address 2291 Detection for OLSR", draft-weniger-autoconf-pdad-olsr-01 (work 2292 in progress), June 2006. 2294 [15] Baccelli, E., "OLSR Passive Duplicate Address Detection", 2295 draft-clausen-olsr-passive-dad-00 (work in progress), 2296 July 2005. 2298 [16] Jeong, H., "Passive Duplicate Address Detection for On-demand 2299 Routing Protocols", draft-jeong-autoconf-pdad-on-demand-01 2300 (work in progress), April 2007. 2302 [17] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for 2303 Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003. 2305 [18] Pongpaibool, P., Siriwong Na Ayutaya, K., Kanchanasut, K., and 2306 H. Tazaki, "Rapid IPv6 Address Autoconfiguration for 2307 Heterogeneous Mobile Technologies", Proceedings of the 8th 2308 International Conference of ITS Telecommunications (ITST 2008), 2309 Phuket, Thailand , 2008. 2311 [19] Nesargi, S. and R. Prakash, "MANETconf: configuration of hosts 2312 in a mobile ad hoc network", INFOCOM 2002. Twenty-First Annual 2313 Joint Conference of the IEEE Computer and Communications 2314 Societies. Proceedings. IEEE, Volume: 2 Page(s): 1059 - 1068 2315 vol.2. 2002 , 2002. 2317 [20] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6 2318 addresses for MANET with multiple gateways (AMG)", 2319 draft-ruffino-manet-autoconf-multigw-03 (work in progress), 2320 June 2006. 2322 [21] Clausen, T. and E. Baccelli, "Simple MANET Address 2323 Autoconfiguration", draft-clausen-manet-address-autoconf-00 2324 (work in progress), February 2005. 2326 [22] Ruiz, P. and F. Ros, "Extensible MANET Auto-configuration 2327 Protocol (EMAP)", draft-ros-autoconf-emap-02 (work in 2328 progress), March 2006. 2330 [23] Wakikawa, R., "Global connectivity for IPv6 Mobile Ad Hoc 2331 Networks", draft-wakikawa-manet-globalv6-05 (work in progress), 2332 March 2006. 2334 [24] Jelger, C., "Gateway and address autoconfiguration for IPv6 2335 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02 2336 (work in progress), April 2004. 2338 [25] Sun, Y., Belding-Royer, E., and C. Perkins, "Internet 2339 Connectivity for Ad hoc Mobile Networks", International Journal 2340 of Wireless Information Networks special issue on 'Mobile Ad 2341 Hoc Networks (MANETs): Standards, Research, Applications' , 2342 2002. 2344 [26] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol 2345 Specification", draft-hofmann-autoconf-mran-00 (work in 2346 progress), March 2006. 2348 [27] Fazio, F., Palazzi, C., Das, S., and M. Gerla, "Automatic IP 2349 Address Configuration in VANETs", ACM VANET 2006 Workshop co- 2350 located with Mobicom 2006 , 2006. 2352 [28] Ahn, S. and Y. Lim, "MANET Address Configuration using Address 2353 Pool", draft-ahn-autoconf-addresspool-00 (work in progress), 2354 December 2009. 2356 [29] Lee, J., Ahn, S., and Y. Kim, "Address Autoconfiguration for 2357 MANET with Multiple MBRs", draft-jaehwoon-autoconf-mmbr-02 2358 (work in progress), February 2010. 2360 [30] Boot, T. and A. Holtzer, "Border Router Discovery Protocol 2361 (BRDP) based Address Autoconfiguration", 2362 draft-boot-autoconf-brdp-02 (work in progress), July 2009. 2364 [31] Thubert, P., "Nested Nemo Tree Discovery", 2365 draft-thubert-tree-discovery-08 (work in progress), June 2009. 2367 [32] Boot, T., "Border Router Discovery Protocol (BRDP) Based 2368 Routing", draft-boot-brdp-based-routing-00 (work in progress), 2369 November 2008. 2371 [33] Laouiti, A., "Address autoconfiguration in Optimized Link State 2372 Routing Protocol", draft-laouiti-manet-olsr-address-autoconf-01 2373 (work in progress), July 2005. 2375 [34] Cha, H., Park, J., and H. Kim, "Extended Support for Global 2376 Connectivity for IPv6 Mobile Ad Hoc Networks", 2377 draft-cha-manet-extended-support-globalv6-00 (work in 2378 progress), October 2003. 2380 [35] Jelger, C. and T. Noel, "Prefix Continuity and Global Address 2381 Autoconfiguration in IPv6 Ad Hoc Networks", Proceedings of the 2382 4th Mediterranean Ad Hoc Networking Workshop (MedHocNet'05), 2383 June 2005, Porquerolles, France , 2005. 2385 [36] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, 2386 February 2010. 2388 [37] Templin, F., "MANET Autoconfiguration over Multilink Sites", 2389 draft-templin-autoconf-multilink-00 (work in progress), 2390 February 2007. 2392 [38] Templin, F., "MANET Autoconfiguration over Virtual Ethernets", 2393 draft-templin-autoconf-virtual-00 (work in progress), 2394 February 2007. 2396 [39] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer 2397 (SEAL)", RFC 5320, February 2010. 2399 [40] Templin, F., "Routing and Addressing in Networks with Global 2400 Enterprise Recursion (RANGER)", RFC 5720, February 2010. 2402 [41] Bernardos, C. and M. Calderon, "A DHCP-based IP address 2403 autoconfiguration for MANETs", I International Conference on 2404 Ubiquitous Computing: Applications, Technology and Social 2405 Issues (ICUC 2006), Alcala de Henares, Spain , 2006. 2407 Appendix A. Change Log 2409 Changes from -04 to -05: 2411 o Removal of references to old autoconf problem statement draft and 2412 MANET architecture drafts. 2414 o Update of the document, adding new solutions. 2416 Changes from -03 to -04: 2418 o New release to keep the document alive. 2420 o Update of some references and the associated solution description. 2422 Changes from -02 to -03: 2424 o New release to keep the document alive. 2426 o Update of some references. 2428 Changes from -01 to -02: 2430 o The classification criteria section has been removed, since it is 2431 now part of the evaluation considerations in [1]. Solutions are 2432 now analysed conforming to some of these evaluation considerations 2433 in [1]. 2435 o The Conclusions section has been removed. 2437 o The Terminology section has been removed. 2439 o The term "DAD" has been removed in the document (when possible), 2440 using Non-unique Address Detection instead. 2442 o Many editorial changes. 2444 Changes from -00 to -01: 2446 o The structure of the I-D has modified, classifying the analysed 2447 solutions according to a number of useful criteria, conforming to 2448 the AUTOCONF problem statement draft and the MANET architecture 2449 draft. 2451 o More solutions have been added to the I-D. 2453 o Adding of a security consideration section. 2455 Authors' Addresses 2457 Carlos J. Bernardos 2458 Universidad Carlos III de Madrid 2459 Av. Universidad, 30 2460 Leganes, Madrid 28911 2461 Spain 2463 Phone: +34 91624 6236 2464 Email: cjbc@it.uc3m.es 2465 URI: http://www.it.uc3m.es/cjbc/ 2467 Maria Caldern 2468 Universidad Carlos III de Madrid 2469 Av. Universidad, 30 2470 Leganes, Madrid 28911 2471 Spain 2473 Phone: +34 91624 8780 2474 Email: maria@it.uc3m.es 2476 Hassnaa Moustafa 2477 France Telecom 2478 38-40 rue du General Leclerc 2479 Issy Les Moulineaux 92794 Cedex 9 2480 France 2482 Phone: +33 145296389 2483 Email: hassnaa.moustafa@orange-ftgroup.com