idnits 2.17.00 (12 Aug 2021) /tmp/idnits20182/draft-bernardos-manet-autoconf-survey-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2110. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2117. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2123. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2008) is 5156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-bernardos-autoconf-evaluation-considerations-01 == Outdated reference: draft-templin-autoconf-dhcp has been published as RFC 5558 -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '32') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) C. Bernardos 3 Internet-Draft M. Calderon 4 Intended status: Informational UC3M 5 Expires: October 10, 2008 H. Moustafa 6 France Telecom 7 April 8, 2008 9 Survey of IP address autoconfiguration mechanisms for MANETs 10 draft-bernardos-manet-autoconf-survey-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 10, 2008. 37 Abstract 39 This Internet Draft provides a detailed description of most of the 40 existing IP autoconfiguration solutions proposed so far. The main 41 aim of this document is to serve as a general reference for the 42 AUTOCONF solution space. We present most of the previously proposed 43 IP AUTOCONF mechanisms in MANETs, showing their key characteristics, 44 conforming to the AUTOCONF problem statement draft and the MANET 45 architecture draft. Furthermore, each solution is analysed based on 46 a number of evaluation considerations. 48 Table of Contents 50 1. Introduction and motivation . . . . . . . . . . . . . . . . . 5 51 2. IP address auto-configuration protocols . . . . . . . . . . . 7 52 2.1. Solutions for Standalone MANET scenarios . . . . . . . . . 7 53 2.1.1. No merging support . . . . . . . . . . . . . . . . . . 7 54 2.1.1.1. IP address Autoconfiguration for Ad Hoc 55 Networks (Perkins et al.) . . . . . . . . . . . . 7 56 2.1.2. Merging support . . . . . . . . . . . . . . . . . . . 9 57 2.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile 58 Ad-Hoc Networks (Weniger et al.) . . . . . . . . . 9 59 2.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et 60 al.) . . . . . . . . . . . . . . . . . . . . . . . 10 61 2.1.2.3. IP Address Assignment in a Mobile Ad Hoc 62 Network (Mohsin et al.) . . . . . . . . . . . . . 12 63 2.1.2.4. An Address Assignment for the Automatic 64 Configuration of Mobile Ad Hoc Networks (Tayal 65 et al.) . . . . . . . . . . . . . . . . . . . . . 14 66 2.1.2.5. No Overhead Autoconfiguration OLSR (Mase et 67 al.) . . . . . . . . . . . . . . . . . . . . . . . 15 68 2.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection 69 for OLSR (Weniger et al.) . . . . . . . . . . . . 17 70 2.1.2.7. Passive Duplicate Address Detection for 71 On-demand Routing Protocols (Jeong et al.) . . . . 19 72 2.1.2.8. Prophet Address Allocation for Large Scale 73 MANETs (Zhou et al.) . . . . . . . . . . . . . . . 21 74 2.2. Solutions for Connected MANET scenarios . . . . . . . . . 23 75 2.2.1. No merging support . . . . . . . . . . . . . . . . . . 23 76 2.2.1.1. Automatic Configuration of IPv6 Addresses for 77 Nodes in a MANET with Multiple Gateways 78 (Ruffino et al.) . . . . . . . . . . . . . . . . . 23 79 2.2.1.2. Simple MANET Address Autoconfiguration 80 (Clausen et al.) . . . . . . . . . . . . . . . . . 24 81 2.2.1.3. Extensible MANET Auto-configuration Protocol 82 (EMAP) (Ros et al.) . . . . . . . . . . . . . . . 26 83 2.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc 84 Networks (Wakikawa et al.) . . . . . . . . . . . . 28 85 2.2.1.5. Multihop Radio Access Network (MRAN) Protocol 86 Specification (Hofmann) . . . . . . . . . . . . . 30 87 2.2.1.6. Automatic IP Address Configuration in VANETs 88 (Fazio et al.) . . . . . . . . . . . . . . . . . . 32 89 2.2.2. Merging support . . . . . . . . . . . . . . . . . . . 34 90 2.2.2.1. Address Autoconfiguration in Optimized Link 91 State Routing Protocol (Adjih et al.) . . . . . . 34 92 2.2.2.2. Extended Support for Global Connectivity for 93 IPv6 Mobile Ad Hoc Networks (Cha et al.) . . . . . 36 94 2.2.2.3. Gateway and Address Autoconfiguration for IPv6 95 Adhoc Networks (Jelger et al.) . . . . . . . . . . 38 97 2.2.2.4. MANET Autoconfiguration using DHCP (Templin et 98 al.) . . . . . . . . . . . . . . . . . . . . . . . 39 99 3. Security Considerations . . . . . . . . . . . . . . . . . . . 43 100 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 101 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 102 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 103 6.1. Normative References . . . . . . . . . . . . . . . . . . . 46 104 6.2. Informative References . . . . . . . . . . . . . . . . . . 46 105 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 49 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 107 Intellectual Property and Copyright Statements . . . . . . . . . . 51 109 1. Introduction and motivation 111 Multi-hop communication in ad hoc networks presents some interesting 112 advantages, where no permanent infrastructure is required. Also, the 113 coverage area of an existing infrastructure can be extended through 114 multi-hop ad hoc communication. Several MANET routing protocol 115 specifications have been developed by the IETF MANET WG. In order to 116 allow wide deployment of ad hoc networks, in which IP routing is the 117 most candidate approach, IP configuration of nodes is a strong 118 requirement that need to be satisfied. In this context, the AUTOCONF 119 WG is working towards standard specifications and solutions for IP 120 address autoconfiguration within different MANET environments. 122 Ad hoc networks present particular characteristics that should be 123 taken into account when designing address auto-configuration 124 protocols. Since existing solutions for IP infrastructure-based 125 networks (e.g., RFCs 4861, 4862, 3315 etc.) were designed for a 126 different scope that MANETs [1], there are several issues that need 127 to be tackled, mainly (but not only) the following: the lack of 128 multi-hop support, the lack of dynamic topology support, the lack of 129 network merging support and the lack of network partitioning support. 131 The main goal of the AUTOCONF WG is to develop solutions for IPv6 132 address auto-configuration (both MANET-local and global scoped). The 133 group has identified two possible scenarios of MANET where IP address 134 auto-configuration is required [1]: 136 o Standalone MANETs: these networks are not connected to any 137 external network. All traffic is generated by MANET nodes and 138 destined to nodes in the same MANET. Examples of these networks 139 are conference networks, battlefield networks, surveillance 140 networks, etc. In this scenario, nodes may join or leave 141 randomly. Besides, most likely no pre-established nor reliable 142 address or prefix allocation agency will be present in the 143 network. 145 o Connected MANETs. These networks have connectivity to one or more 146 external networks, typically the Internet, by means of one or more 147 gateways that are also known as MBRs (MANET Border Routers). 148 These networks may be connected to the Internet in permanent 149 fashion or in intermittent fashion. 151 This draft aims at providing a survey on most of the previously 152 proposed IP autoconfiguration solutions, trying to serve as a useful 153 reference for the AUTOCONF WG during the problem space analysis and 154 solution design phases. 156 In the following section, we provide a description of several 157 existing AUTOCONF solution proposals, analysing them based on some 158 evaluation considerations proposed in [2]. In order to present the 159 analysed solutions in a structured way, two major classification 160 levels are used: i) standalone/connected, and ii) partitioning/ 161 merging support. 163 The given analysis conforms to the AUTOCONF problem statement draft 164 [1] and the MANET architecture draft [3]. 166 2. IP address auto-configuration protocols 168 In this section we briefly describe some of the existing proposals 169 for IP address autoconfiguration, classifying them according to some 170 of the evaluation considerations introduced in [2]. 172 2.1. Solutions for Standalone MANET scenarios 174 2.1.1. No merging support 176 2.1.1.1. IP address Autoconfiguration for Ad Hoc Networks (Perkins et 177 al.) 179 This address autoconfiguration mechanism -- proposed in [4] -- 180 basically consists in choosing an address randomly from an address 181 pool (i.e., a network prefix) available to the MANET and then 182 performing a Duplicate Address Detection procedure within the MANET. 184 Assumptions: It is assumed that nodes performing this 185 autoconfiguration protocol obtain a non-link-local prefix (it cannot 186 be link-local, since the addresses have to be valid over a multiple- 187 hop distance) from which to configure an address. The method to 188 obtain a globally routable prefix is not specified in the solution 189 and, in case it is not possible to obtain any suitable one, a 190 reserved IPv6 prefix, called MANET_PREFIX, is used: fec0:0:0: 191 ffff::/64. 193 Approach description: This solution basically works as follows: a 194 node first selects a random address from the non-link-local prefix 195 that is deployed in the MANET and then performs a Non-unique Address 196 Detection procedure to check for its uniqueness across the MANET. To 197 perform this uniqueness check, the node sends an Address Request 198 (AREQ) message, including the randomly chosen tentative non-link- 199 local IP address. This message is broadcast to its neighbours, by 200 sending the message using the all-nodes multicast IPv6 address as 201 destination of the packet. The source address used by the node to 202 send the AREQ message is another temporary IP address, acquired only 203 for the purpose of sending these messages. This temporary IPv6 204 address belongs to a different non-overlapping prefix -- called 205 MANET_INITIAL_PREFIX -- so the probability of this address to be 206 duplicated in the network is very low, given its short lifetime (this 207 address is only used in this message exchange and discarded 208 thereafter). When a node receives an AREQ message, it creates a 209 reverse route entry for the temporary IPv6 address of the node. If 210 the tentative address contained in the AREQ message does not match 211 the address of the receiving node, it rebroadcasts the message to its 212 neighbours. If the IP address of the receiving node matches the 213 tentative address contained in the AREQ message it sends an Address 214 Reply (AREP) message to the sender, indicating that the address is 215 already in use. The route created by the AREQ messages is used to 216 route the message back to the source node. 218 A node waits for a certain amount of time after sending an AREQ 219 message, for the reception of an AREP message. The process is 220 repeated if no answer is received, and if after a number of attempts 221 no AREP has been received, the node assumes that the tentatively 222 chosen IPv6 address is unique and starts using it. The values 223 configured for the involved timers and retry parameters have an 224 impact on the maximum size of the MANET where the solution would 225 properly work. Additionally, since the Non-unique Address Detection 226 procedure is performed only when the node initially chooses the 227 tentative IPv6 address to use, this mechanism does not support 228 merging of MANETs. 230 AREQ and AREP are a modification of the standard ICMPv6 Neighbour 231 Advertisement and Neighbour Solicitation messages, respectively. 233 Based on [2], this solution has the following key features: 235 o MANET scenario: the solution targets standalone MANETs, although 236 it considers the possibility of being applied to connected 237 scenarios in those cases in which nodes are provided with the non- 238 link-local prefix to be used in the MANET. 240 o Routing protocols' dependency: the solution is routing protocol 241 independent. 243 o Address uniqueness: the proposed solution makes use of Non-unique 244 Address Detection in the initial address assignment phase. 246 o Distributed/centralised approach: the solution does not make use 247 of any centralised server. 249 o Merging support: the solution does not support merging. 251 o Prefix assignment support: the solution does not support the 252 assignment of IPv6 prefixes to nodes. 254 o Protocol overhead: the solution requires additional message 255 flooding (AREQ messages) to verify if an IP address is being used 256 in the MANET. 258 2.1.2. Merging support 260 2.1.2.1. IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks 261 (Weniger et al.) 263 The solution described in [5] extends the Neighbour Discovery and 264 IPv6 Stateless Address Autoconfiguration mechanisms to work in multi- 265 hop wireless networks. 267 Assumptions: The solution assumes a hierarchical approach, where 268 there are two different types of participating nodes: those that 269 obtain IPv6 addresses by using a modified version of IPv6 Neighbour 270 Discovery, and special nodes -- called leader nodes --, that are 271 responsible for parts of the address configuration of other nodes. 273 Approach description: The solution basically extends IPv6 Neighbour 274 Discovery to provide nodes within a multi-hop environment with IPv6 275 address autoconfiguration capabilities. To do so, the following 276 modifications to the IPv6 Neighbour Discovery protocol are proposed: 278 o The Neighbour Solicitation message is modified to allow it to be 279 broadcast to a bounded area of radius r_s hops (instead of only a 280 single hop). In addition, a new option for Neighbour Discovery is 281 defined (called MANET option) which contains a Random Source ID 282 (RS-ID) field, that is used to distinguish different nodes. Nodes 283 use the all-nodes multicast address instead of the solicited-node 284 multicast address. This mechanism guarantees link-local addresses 285 to be unique within the scope (limited by r_s) of each node. 287 o To enable the configuration of unique site-local addresses, a 288 hierarchy is established by special nodes (called leader nodes) 289 that configure a group of nodes by issuing Router Advertisements 290 (RA) within their scope, containing the subnet ID (i.e., network 291 prefix) and its link-local address as source address. The subnet 292 ID has to be unique for each leader node, so Non-unique Address 293 Detection has to be performed between the leader nodes within the 294 entire Ad hoc network. An algorithm is provided for the election 295 of leader nodes. 297 It should be noted that because of the nature of the solution, it 298 would be possible to have multihomed nodes -- that is, nodes with 299 more than one IPv6 address -- if a node is within the scope of more 300 than one leader node. 302 Based on [2], this solution has the following key features: 304 o MANET scenario: the solution targets standalone MANETs, although 305 it could be possible to extend it to support the assignment of 306 global IPv6 addresses. 308 o Routing protocols' dependency: the solution does not depend on any 309 particular ad-hoc routing protocol, but it may be advantageous the 310 routing protocol it follows a hierarchical structure. Besides, it 311 is also preferable that nodes move in logical groups. Otherwise, 312 the cost of maintaining the hierarchical structure may be 313 considerable. 315 o Address uniqueness: the proposed solution makes use of a periodic 316 Non-unique Address Detection for ensuring the address uniqueness 317 within the scope of the leader node. Since each leader node makes 318 use of a different Subnet ID, the uniqueness of the assigned 319 address within the entire MANET is ensured. 321 o Distributed/centralised approach: the solution does not make use 322 of any centralised server, but considers the existence of special 323 nodes (leader nodes) that participate in the mechanism in a 324 distributed fashion. 326 o Merging support: the solution support merging, by leader nodes 327 performing periodic Non-unique Address Detection that ensures the 328 uniqueness of Subnet IDs. 330 o Prefix assignment support: the solution does not support the 331 assignment of IPv6 prefixes to nodes. 333 o Protocol overhead: the solution requires additional message 334 flooding within a bounded area of radius r_s hops. 336 2.1.2.2. Ad Hoc IP Address Autoconfiguration (Jeong et al.) 338 The solution described in [6] proposes two Non-unique Address 339 Detection mechanisms. The first one -- called "strong DAD" -- is 340 done in the initial phase when the ad hoc node does not have an IP 341 address configured yet, it relates to the fact that before a randomly 342 generated address is assigned and used, it should be verified that it 343 will not create an address conflict. On the other hand the second 344 Non-unique Address Detection mechanism -- called "weak DAD" -- is 345 always executed by nodes taking part in ad hoc routing in order to 346 prevent any address conflicts due to mergers. 348 Assumptions: The solution assumes that initially a random address is 349 selected by ad hoc nodes using the reserved IPv6 prefix MANET_PREFIX. 351 Approach description: This approach includes two different Non-unique 352 Address Detection mechanisms: 354 o Strong DAD: based on [4]. Strong DAD is done initially after an 355 ad hoc node has chosen randomly an IP address and it is trying to 356 find out whether there is a duplication conflict or not. AREQ 357 message for Strong DAD is broadcast in site-local scoped all node 358 multicast address, IPV6_MANET_BROADCAST_ADDRESS. The ad hoc node 359 waits for an AREP message -- indicating the selected address has 360 already been utilised -- until the timer for Strong DAD expires. 361 In the case an AREP message arrives it chooses a new address and 362 executes Strong DAD mechanism again. [6] describes the message 363 format, using ICMPv6 messages (new types are defined). [7] 364 describes the message format for AODV. 366 o Weak DAD: based on [8]. During ad hoc routing, weak DAD is used 367 to find out whether address duplication, due to merging has 368 occurred or not. The concept of ``Virtual IP address'', which is 369 the combination of an ''IP address'' and an ``Key'', is used, 370 which is selected to be unique by each mobile ad hoc node. This 371 ''key'' is appended to control packets of ad hoc routing protocol, 372 such as route discovery messages or hello messages. Intermediate 373 routing points must store the ''key'' value for each address in 374 its routing table. Using these ''keys'', duplication conflicts 375 can be found out during ad hoc routing process. An AERR message 376 is sent during Weak DAD for the purpose of indicating that an 377 address duplication happened. The ad hoc node that receives an 378 AERR message should autoconfigure a new IPv6 address through 379 Strong DAD. The same AERR message is used to inform each peer 380 node that its address has been changed. In order to keep ongoing 381 sessions after an address duplication episode, data packets are 382 sent to the new address through IP tunnelling. The destination 383 address in outer IP header is the new IP address of the node that 384 announced duplicate address and the inner IP header contains the 385 duplicate IP address of the node, i.e. the old address of the 386 node. The match duplicate address and new address is done in an 387 Address Mapping Cache. 389 Based on [2], this solution has the following key features: 391 o MANET scenario: the solution targets standalone MANETs. 393 o Routing protocols' dependency: the solution does not depend on any 394 particular ad-hoc routing protocol. 396 o Address uniqueness: the proposed solution makes use of two 397 different Non-unique Address Detection mechanisms. 399 o Distributed/centralised approach: the solution is distributed. It 400 does not make use of either any centralised servers or special 401 nodes. 403 o Merging support: the solution supports merging by looking for 404 duplicate addresses on an ongoing basis. 406 o Prefix assignment support: the solution does not support the 407 assignment of IPv6 prefixes to nodes. 409 o Protocol overhead: The Strong DAD mechanism requires additional 410 message flooding (AREQ messages) to find out whether there is a 411 duplication conflict or not. The Weak DAD mechanism introduces 412 also some protocol overhead since the Key extension (20 bytes) is 413 appended to each control packet of the ad hoc routing protocol. 415 2.1.2.3. IP Address Assignment in a Mobile Ad Hoc Network (Mohsin et 416 al.) 418 This proposed solution [9] is based on a dynamic allocation of IP 419 addresses in MANETs using the concept of binary split. A proactive 420 approach is used, in the sense that each node can independently 421 assign a new IP address without consulting any other node in the 422 network. Partitioning and merging as well as nodes abrupt departures 423 are supported in this solution. 425 Assumptions: It is assumed that all nodes collectively perform the 426 DHCP functionality; where each node is capable of configuring a new 427 node and providing it with a new IP address. It is also assumed that 428 one MANET node have the entire pool of IP addresses at the beginning. 430 Approach description: In this proposed solution the concept of Buddy 431 Systems is used. This is a type of segregated lists used in memory 432 allocation and supports efficient splitting and coalescing. In the 433 context of the proposed solution, binary buddies are used, where all 434 buddy sizes are a power of two, and each size is divided into two 435 equal parts. Thus, every node has a disjoint set of IP addresses 436 that it can assign to a new node without consulting any other node in 437 the network. When a new unconfigured mobile node (B) joins the 438 network, it requests the nearest neighbour (A) an IP address. Node 439 (A) divides its IP address set into two, giving one half to the 440 requesting node (B). The new node assigns itself an IP address from 441 the acquired pool of addresses, storing the rest of addresses to 442 configure other nodes afterwards. The new node (B) is now configured 443 and is considered as the Buddy of node (A). The scheme of the IP 444 address assignment can be seen as a handshaking protocol between the 445 server and the client, where the node requesting the IP address is 446 considered as the client node and the node that actually assigns the 447 IP address is considered as the server node. 449 Nodes synchronise the IP blocks which they store to keep track of the 450 assigned IP addresses and detect any IP leakage, where every node 451 keeps a record of all the IP address blocks in the network by 452 maintaining a corresponding table. Each node sends its IP address 453 pool to all other nodes in the network, and each node receiving an IP 454 pool from another node records the received information in its IP 455 address table. Through this approach, the network has among its 456 nodes the available IP addresses organised in the form of a binary 457 tree with a division of two identical blocks (Buddies) per level. 459 Two mechanisms are proposed for releasing the node's IP address pool 460 when the node leaves the network: i) graceful leave, in which the 461 leaving node gives its IP address pool to any nearby node. This 462 nearby node may keep the IP address pool for itself or may search in 463 its IP address table the Buddy of the leaving node and forward to it 464 the IP pool. ii) abrupt leave, in which the node leaves with its IP 465 address pool that leads to IP leakage. In such a case, a pool of IP 466 addresses that is not assigned to any node is not available. IP 467 leakage is detected from the IP address table stored at each node. 468 Each node scans from time to time its IP address table for the IP 469 pool of its Buddy node, if it does not find it, it concludes that the 470 node has left and it merges this missing IP block to itself. 472 Based on [2], this solution has the following key features: 474 o MANET scenario: This proposed solution targets standalone MANETs. 476 o Routing protocols' dependency: This proposed solution is 477 independent of the underlying routing protocol. 479 o Address uniqueness: The proposed solution does not use any Non- 480 unique Address Detection mechanism. 482 o Distributed/Centralised approach: Although this solution is based 483 on IP address pools assignment and splitting, it has a distributed 484 approach, where all nodes collectively perform the functionality 485 of a DHCP server. 487 o Merging support: Thanks to employing the buddy systems, the 488 proposed solution supports merging. In case of merging, the 489 process of buddies splitting allows the merging node to be 490 assigned an IP address and an IP pool. 492 o Prefix assignment support: the solution does not support the 493 assignment of IPv6 prefixes to nodes. 495 o Protocol overhead: the solution requires a kind of flooding so 496 that each node sends its IP address block to all other nodes in 497 the network. Furthermore, other control messages are required in 498 the form of request-reply messages to enable a new joining node to 499 be assigned an IP address, or in the form of announcement in the 500 case of IP release. 502 2.1.2.4. An Address Assignment for the Automatic Configuration of 503 Mobile Ad Hoc Networks (Tayal et al.) 505 The solution described in [10] is very similar to the previous one 506 ([9]), sharing the idea (also used by others) of nodes assignment of 507 half of their address pools to newly arrived nodes that request IP 508 addresses. 510 Assumptions: It is assumed that initially there is one node that 511 configures itself as initiator node (when there is no other node in 512 the network), configuring itself with a default IP address and 513 starting to manage a default address pool. 515 Approach description: The solution basically works as follows: when a 516 new node i (called requester node) is willing to join the MANET, it 517 has to contact an existing node j in the network. If node j has the 518 address pool, it divides it into two parts and allocates one part to 519 node i. The starting address of the allocated pool is the address of 520 node i. In case node j does not have the address pool, j starts 521 searching for nodes that might have an address pool, by broadcasting 522 a message (called SEARCH_ADDR). The search message is forwarded by 523 all the nodes which do not have an address pool. A node receiving 524 the search message, either replies with the address pool or with 525 negative ACK. If a node replies with its address pool, it marks half 526 of its addresses as under allocation and wait for a POOL_ACCEPTED 527 message from node j. Node j replies with POOL_ACCEPTED message to 528 the node whose address pool it received first, and allocates the 529 received address pool to node i. 531 This solution defines mechanisms to handle different scenarios, such 532 as network partitioning and merging, message loss, etc. More details 533 can be found in [10]. 535 Based on [2], this solution has the following key features: 537 o MANET scenario: This proposed solution targets standalone 538 scenarios. 540 o Routing protocols' dependency: This proposed solution is 541 independent of the underlying routing protocol. 543 o Address uniqueness: The proposed solution does not use any Non- 544 unique Address Detection mechanism, since the uniqueness of the 545 solution is based on the split of the initially available IP 546 address pool. 548 o Distributed/Centralised approach: the solution is based on IP 549 address pools assignment and splitting, where all nodes 550 collectively perform the functionality of assigning addresses to 551 newcomers. 553 o Merging support: the solution defines a mechanism to detect 554 merging, through redistributing information about assigned 555 addresses and pools. If an address collision is detected, then 556 the solution defines a mechanism to solve that, based on giving 557 up/shrinking the address pool used by one of the nodes detecting 558 the conflict. 560 o Prefix assignment support: Since the solution supports the 561 assignment of address pools, it can be possible to use it to 562 assign prefixes to nodes, although it is not explicitly covered by 563 the mechanism. 565 o Protocol overhead: the solution requires some message flooding to 566 search nodes that have an address pool available. 568 2.1.2.5. No Overhead Autoconfiguration OLSR (Mase et al.) 570 This solution [11] proposes some passive Non-unique Address Detection 571 techniques to be used in MANETs running the OLSR protocol. It 572 utilises the Passive Duplicate Address Detection concept [12], [13], 573 which enables nodes to passively detect duplicate addresses in the 574 network (e.g., occurring after network merging) by analysing received 575 routing protocol messages. The basic idea of PDAD is to exploit the 576 fact that some protocol events occur in case of duplicate address, 577 but (almost) never in case of a unique address. The proposed 578 techniques may be used to ensure uniqueness of an address when it is 579 initially generated before being assigned to an interface and the 580 solution also performs to ensure uniqueness of addresses which have 581 been assigned and used, and then a network merger happens. 583 This is one of the multiple drafts proposing the use of PDAD for OLSR 584 [14], [15]. 586 Assumptions: The protocol assumes the existence of a Non-unique 587 Address Detection-based IP address generation mechanism. 589 Approach description: The solution proposes an ongoing duplicate 590 address detection mechanism, checking for inconsistencies in the 591 routing protocol messages to diagnose duplicate address detection. 592 The first kind of inconsistency is based on information included in 593 OLSR messages (such as HELLO messages and TC messages) and the second 594 kind of inconsistency is based on sequence numbers (when two nodes -- 595 which selected the same IP address -- are present in a network, they 596 would send control messages that will be inconsistent). 598 Different Non-unique Address Detection rules -- twelve in total -- 599 are proposed to handle the cases where the distance between 600 conflicting nodes is one hop, two hops and, three hops or more. In 601 the two first cases the detection is done by means of HELLO messages 602 and in the last case -- three hops or more -- the detection is 603 fulfilled by using information inside TC messages. Also, an 604 additional case is taken into account: this is a specific multihop 605 address conflict case, where the address conflict results in 606 deficiencies in the MPR selection. 608 Each node has an "autoconfiguration state". This state is an 609 indicator of how long the node has been in the network. The central 610 idea, is that each time a node generates a tentative address, it 611 should enter the network gradually, running a restrained version of 612 the OLSR protocol. In this way, the node can detect which addresses 613 are being used, checking for duplicates of its own address, while 614 avoiding to disrupt the routing tables of the other nodes, in the 615 event that its address is actually found to be in conflict. 617 Based on [2], this solution has the following key features: 619 o MANET scenario: This Non-unique Address Detection technique is to 620 be used in standalone MANETs. 622 o Routing protocols' dependency: this mechanism depends on OLSR, 623 since the Non-unique Address Detection technique is designed for 624 MANETs running the OLSR protocol. 626 o Address uniqueness: The proposed mechanism assumes the existence 627 of a Non-unique Address Detection-based address assignment 628 mechanism. 630 o Distributed/centralised approach: the proposed solution follows a 631 distributed approach given that all nodes have the same 632 responsibility detecting address conflicts. 634 o Merging support: The proposed solution supports merging, enabling 635 nodes to continuously detect duplicate addresses by analysing 636 received routing protocol messages. 638 o Prefix assignment support: the solution does not support the 639 assignment of IPv6 prefixes to nodes. 641 o Protocol overhead: the proposed mechanism does not add any 642 additional messages but it checks for inconsistencies in the 643 routing protocol messages to diagnose duplicate address detection. 645 2.1.2.6. PDAD-OLSR: Passive Duplicate Address Detection for OLSR 646 (Weniger et al.) 648 This solution [14] proposes a passive Non-unique Address Detection 649 mechanism for configured address uniqueness maintenance in MANETs 650 running the OLSR protocol. 652 Assumptions: The protocol assumes the existence of a Non-unique 653 Address Detection-based address generation mechanism. 655 Approach description: The proposed solution is made up of a set of 656 algorithms which specify how to detect duplicate addresses based on 657 incoming routing protocol messages. The algorithms utilise different 658 parameters in TC and HELLO messages such as link states (i.e., 659 neighbour interface addresses), link codes, (message) sequence 660 numbers, and addresses in OLSR routing protocol messages as well as 661 addresses in the IP header. PDAD-OLSR allows the detection of 662 conflicts by intermediate nodes that have unique addresses. 664 Each node conceptually maintains two tables for PDAD: a Last received 665 Protocol Messages (LRM) table and a Neighbour History (NH) table. 666 LRM table contains information about the last TC and HELLO protocol 667 message received from a specific originator address (e.g., originator 668 address, message type, sequence number, neighbour interface 669 addresses, receive time). NH table contains the history of 670 neighbouring node addresses and is built from received HELLO messages 671 (e.g., neighbour interface address, last time the receiver has 672 selected this neighbour interface address as MPR, Last time the 673 receiver has been selected as MPR by this neighbour interface 674 address, reception time). 676 The solution proposes eight different algorithms for conflict 677 detection: 679 o PDAD-Source Address (SA). Whenever a node receives a TC or HELLO 680 message, it compares the source address in the IP header to its 681 own address (the IP source address is always the address of the 682 last forwarder). This mechanism (e.g., Both addresses coincide) 683 allows nodes to detect conflicts with its neighbouring nodes. 685 o PDAD-Sequence Numbers (SN): If a node receives a TC or HELLO 686 message, it compares the originator address with its own address. 687 If they are equal and the sequence number in the message is higher 688 than the receiver's sequence number, a conflict of the originator 689 address is detected. This mechanism allows to detect conflicts 690 between nodes that are any number of hops away from each other. 692 o PDAD-Sequence Number Difference (SND): If a node receives a TC or 693 HELLO message, it compares the sequence number in the message with 694 the sequence number in the previously received message from the 695 same originator address and with the same message type (there is a 696 relation between the time a node has originated two TC messages 697 and the sequence number in those TC messages). This mechanism 698 allows to detect conflicts between nodes that are any number of 699 hops away from each other. 701 o PDAD-Sequence Numbers Equal (SNE): If an intermediate node 702 receives a TC or HELLO message, it searches its LRM table for a 703 message with the same type value and the same tuple < sequence 704 number, originator address > (the tuple < sequence number, 705 originator address > uniquely identifies messages originated by a 706 specific node. This mechanism allows to detect conflicts between 707 nodes that are any number of hops away from each other. 709 o PDAD-SNs Always Increment (SNI): If a node receives a HELLO 710 message, it compares the sequence number in the message with the 711 sequence number in the previous HELLO message from the same 712 originator address (HELLO messages sent by a specific node are 713 received in the order they are sent). This mechanism only allows 714 to detect conflicts between nodes that are at most two hops away 715 from each other. 717 o PDAD-Neighbourhood History (NH): If a node receives a TC message, 718 it checks whether its own address is part of the neighbour 719 interface addresses in the TC message. If this is the case and 720 the link code indicates a bi-directional link, the node searches 721 the originator address in its NH table (a TC message only contains 722 neighbours that have selected the originator address as MPRs and 723 that requires a bi-directional link). This mechanism allows to 724 detect conflicts between nodes that are any number of hops away 725 from each other. 727 o PDAD-Link States (LS): If a node receives a TC message with its 728 own address as originator address, it searches in its NH table for 729 each of the neighbour interface addresses (if the message has been 730 originated by the receiver, it must only contain addresses of 731 recent neighbour interfaces). This mechanism allows to conflicts 732 between nodes that are any number of hops away from each other. 734 o PDAD-extended Neighbourhood History (eNH): If a node receives a TC 735 message, it checks for each neighbour interface address in the 736 message if it is a neighbour. This algorithm is basically the 737 PAD-NH algorithm executed on behalf of a neighbouring node. 738 Minimal additional signalling is needed. This mechanism allows to 739 detect conflicts between nodes that are any number of hops away 740 from each other. 742 For some of the above mechanisms it is crucial to detect a possible 743 sequence number wrap-around, so a mechanism to detect this kind of 744 events is proposed. 746 Based on [2], this solution has the following key features: 748 o MANET scenario: The solution targets standalone MANETs. Although 749 it proposes a Non-unique Address Detection mechanism suitable for 750 any kind of addresses exchanged in routing protocol messages, be 751 it MANET-local or globally routable addresses, the solution does 752 not address the issue of how to obtain global IPv6 addresses. 754 o Routing protocols' dependency: this solution requires OLSR, since 755 the set of proposed techniques are applicable to MANETs running 756 the OLSR protocol. 758 o Address uniqueness: The proposed mechanism assume the existence of 759 an address assignment mechanism which may assign duplicate 760 addresses. 762 o Distributed/centralised approach: The solution follows a 763 completely distributed approach, every node has the same 764 responsibility in detecting duplicate addresses and does the same 765 processing. 767 o Merging support: The proposed solution supports merging given that 768 it enables nodes to continuously detect duplicate addresses in the 769 network by analysing received routing protocol messages. 771 o Prefix assignment support: the solution does not support the 772 assignment of IPv6 prefixes to nodes. 774 o Protocol overhead: the solution enables nodes to passively detect 775 duplicate addresses in the network by analysing received routing 776 protocol messages and thus does not cause any overhead. 778 2.1.2.7. Passive Duplicate Address Detection for On-demand Routing 779 Protocols (Jeong et al.) 781 This solution [16] proposes a set of Non-unique Address Detection 782 techniques to be used jointly with an on-demand routing protocol. In 783 this proposal passive duplicate address detection is performed by 784 analysing incoming on-demand routing protocol packets. 786 Assumptions: The protocol assumes the existence of an on-demand 787 routing protocol and a Non-unique Address Detection-based IP address 788 configuration mechanism. 790 Approach description: In this proposal passive duplicate address 791 detection is performed by analysing incoming on-demand routing 792 protocol packets. Additional information included in routing 793 protocol packets allows end-points of a communication -- source or 794 destination -- to detect that the other end-point is using an address 795 which is duplicated in the MANET. 797 This additional information is included into routing control packets 798 exchanged for route discovery and it may be: the node location when 799 it configured its IP address, the node's neighbour list when it 800 configured its IP address, or a sequence number in RREP packets 801 (increased whenever a destination node sends a new RREP packet). 803 The authors propose different mechanisms for detecting address 804 conflicts: 806 o PDAD-RREQ-with-Location-information Technique (RQL): This 807 technique includes location information in RREQ packets to 808 differentiate between RREQ packets which contain the same source 809 address but are generated by different nodes. 811 o PDAD-RREQ-with-Neighbour-knowledge Technique (RQN): This technique 812 includes a list of neighbour nodes (this list is captured and 813 recorded when the node's IP address is configured) in RREQ packets 814 to differentiate between RREQ packets which contain the same 815 source address but are generated by different nodes. 817 o PDAD-RREP-with-SEQ Technique (RPS) : This technique requires an 818 incremental PDAD-sequence number to be included in each RREP 819 packet transmitted by a destination node. Therefore, when a 820 source node receives more than one RREP packet with the same PDAD- 821 sequence number and the same destination address, the source node 822 can detect the address conflict of destination nodes. 824 o PDAD-RREP-with-Location-information Technique (RPL): This 825 technique includes location information into RREP packets to 826 differentiate between RREP packets which contain the same source 827 address (the source address of RREP packets is the destination 828 address of RREQ packets) but are generated by different nodes. 830 o PDAD-RREP-with-Neighbour-knowledge Technique (RPN): When a 831 destination node replies with an RREP packet, a list of neighbour 832 nodes of the destination node (this list is captured and recorded 833 when the node's IP address is configured) is included in the RREP 834 packet. 836 The document does not include how to perform address conflict 837 resolution. 839 Based on [2], this solution has the following key features: 841 o MANET scenario: The solution targets standalone MANETs. Although 842 the proposed Non-unique Address Detection mechanism is suitable 843 for any kind of addresses exchanged in routing protocol messages, 844 be it MANET-local or globally routable addresses, it does not 845 define any mechanism to obtain global IPv6 addresses. 847 o Routing protocols' dependency: The set of proposed techniques 848 supposes the existence of an on-demand ad-hoc routing protocol. 850 o Address uniqueness: The proposed mechanism assumes the existence 851 of a Non-unique Address Detection-based address assignment 852 mechanism. 854 o Distributed/centralised approach: The solution follows a 855 completely distributed approach, every node has the same 856 responsibility in detecting duplicate addresses and does the same 857 processing. 859 o Merging support: The proposed solution supports merging given that 860 it enables nodes to continuously detect duplicate addresses in the 861 network by analysing received routing protocol messages. 863 o Prefix assignment support: the solution does not support the 864 assignment of IPv6 prefixes to nodes. 866 o Protocol overhead: the solution enables nodes to passively detect 867 duplicate addresses in the network by analysing received routing 868 protocol messages and thus does not cause any overhead. 870 2.1.2.8. Prophet Address Allocation for Large Scale MANETs (Zhou et 871 al.) 873 The mechanism defined in [17] is based on the use of a special type 874 of function to derive the IPv6 addresses of nodes, so the probability 875 of address duplication is very low, and therefore the use of a Non- 876 unique Address Detection mechanism can be avoided. 878 Assumptions: This solution is based on the use of a stateful function 879 f(n) (where the initial state of f(n) is the seed) that produces as 880 output an integer sequence of numbers. Different seeds lead to 881 different sequences, and the state of f(n) is updated. This function 882 can be used to generate IP addresses, since it satisfies the 883 following properties: 885 o The interval between two occurrences of the same number in a 886 sequence is extremely long. 888 o The probability of more than one occurrence of the same number in 889 a limited number of different sequences initiated by different 890 seeds during some interval is extremely low. 892 These properties may be satisfied if the space of available addresses 893 is large, so it is relatively easy to achieve in IPv6. 895 Approach description: The mechanism basically work as follows: the 896 first node in the MANET chooses a random number as its IP address and 897 uses a random or default state value as the seed for its f(n). When 898 a different node approaches, the first node uses its f(n) to obtain a 899 different number and state. This number is used by the second node 900 as its IP address, and the state is used as the seed for its f(n). 901 After that both nodes are able to assign IP addresses to other nodes. 903 Authors of the mechanism propose different mechanisms to support 904 partitioning/merging, such as for example including the seed used in 905 the MANET in the messages of the routing protocol. By doing that, 906 nodes of different merging MANETs can easily detect the merge (if 907 different seeds are received, that would mean that a merge has 908 happened) and start checking if there are potential IP address 909 conflicts. Given the characteristics of the function f(n) if a MANET 910 gets partitioned and later merges, IP address conflicts are very 911 unlikely to occur. 913 Based on [2], this solution has the following key features: 915 o MANET scenario: the solution targets standalone MANETs. 917 o Routing protocols' dependency: the solution is routing protocol 918 independent. 920 o Address uniqueness: the proposed solution does not define any Non- 921 unique Address Detection mechanism. The address uniqueness is 922 ensured by using a "prophet" allocation with a very low 923 probability of collision. 925 o Distributed/centralised approach: the solution does not make use 926 of any centralised server. 928 o Merging support: the solution proposes different mechanisms to 929 support merging. 931 o Prefix assignment support: the solution supports the assignment of 932 IPv6 prefixes to nodes, by using the DHCP prefix delegation. 934 o Protocol overhead: only few additional messages are required to 935 assign addresses to new nodes. 937 2.2. Solutions for Connected MANET scenarios 939 2.2.1. No merging support 941 2.2.1.1. Automatic Configuration of IPv6 Addresses for Nodes in a MANET 942 with Multiple Gateways (Ruffino et al.) 944 This proposed solution [18] describes a mechanism enabling nodes 945 belonging to a MANET connected to the infrastructure -- by means of 946 one or more gateways -- to obtain global IPv6 addresses that could be 947 used to communicate with external nodes. 949 Assumptions: This mechanism assumes the existence of one or more 950 gateways that provide MANET nodes with connectivity to external 951 networks (e.g., the Internet). It is also assumed that nodes running 952 this solution obtain at the bootstrapping phase a MANET local IPv6 953 address (which is the address that the node uses when it participates 954 in the routing protocol, which is assumed to be OLSR). The 955 uniqueness of the obtained address should be ensured by means of a 956 Non-unique Address Detection method. Neither the procedure followed 957 to obtain this address, nor the Non-unique Address Detection method 958 used to check its uniqueness, are defined in this solution. 960 Approach description: The mechanism basically works as follows: at 961 bootstrap, a node configures a Primary Address (PADD) that is MANET- 962 scoped and is used as main address in OLSR messages. The node then 963 is able to start participating to OLSR and receiving topology 964 information. Each of the gateways available at the MANET has a 965 global IPv6 prefix that is announced using a new OLSR message type, 966 called Prefix Advertisement (PA). 968 With the prefix information received in the PA messages, a node is 969 able to build a set of global IPv6 addresses (called Secondary 970 Addresses: SADDs). Among them, the node chooses the "best" prefix 971 and starts using the address formed from this prefix (called, 972 Designated Secondary Address: DSADD). The node introduces all (or a 973 subset) of the SADDs (including the DSADD) in OLSR messages and 974 starts broadcasting them, enabling these addresses to be routable and 975 reachable within the MANET. It should be noted, that this solution 976 does not define any new Non-unique Address Detection mechanism, while 977 it is suggested to use a generic MANET Non-unique Address Detection 978 procedure, such as [4], to verify the uniqueness of MANET-local and 979 global addresses. 981 Based on [2], this solution has the following key features: 983 o MANET scenario: the solution targets connected MANETs. 985 o Routing protocols' dependency: the solution requires OLSR to be 986 run in the network. 988 o Address uniqueness: the proposed solution does not define any Non- 989 unique Address Detection mechanism, although requires some generic 990 one to be used to ensure the uniqueness of MANET-local and global 991 addresses. 993 o Distributed/centralised approach: the solution does not make use 994 of any centralised server, but requires gateways to announce the 995 global IPv6 prefixes that can be used by MANET nodes in the 996 configuration of their IPv6 addresses. 998 o Merging support: the solution partially supports merging, since 999 the scenario in which new gateways join the network as a result of 1000 a merger is considered. However, since no Non-unique Address 1001 Detection mechanism is defined, the solution does not describe how 1002 to deal with IPv6 address duplication after merging of different 1003 MANETs. 1005 o Prefix assignment support: the solution does not support the 1006 assignment of IPv6 prefixes to nodes. 1008 o Protocol overhead: the solution adds some overhead. since Gateways 1009 broadcast prefix information. 1011 2.2.1.2. Simple MANET Address Autoconfiguration (Clausen et al.) 1013 This proposed solution [19] aims to provide a simple IP 1014 autoconfiguration mechanism for mobile nodes joining an existing 1015 MANET. This mechanism is designed for MANETs that act as an edge- 1016 extension to the Internet, where mobile nodes need to maintain the 1017 connections with each other and with the Internet. 1019 Assumptions: It is assumed that at least one node in the network is 1020 already configured with a permanent address. In the absence of a 1021 configured node, it is assumed that an election mechanism is 1022 undertaken allowing a selected node to be self-configured. 1024 Approach description: In this proposed solution, only configured 1025 nodes can participate in the MANET and are considered as MANET nodes. 1026 These nodes are also considered as "configuring nodes" aiding the new 1027 joining nodes to acquire an IP address. Actually, each new joining 1028 node is firstly assigned a temporary local address then a permanent 1029 global address. The configuring nodes emit periodical ADDR_BEACON 1030 messages to their neighbours in order to signal their existence to 1031 new nodes. A new node joining the network selects a configuring node 1032 from its neighbours, then sends an Address Request (AREQ) to this 1033 selected configuring node and waits for a reply. The process of 1034 sending AREQ may be repeated for a number of trials until either 1035 receiving a reply or selecting a new configuring node. The 1036 configuring node replies by an Addr-Config message, containing a 1037 local temporary address, and keeps track of the link existence with 1038 the new joining node through local routing messages exchange on this 1039 link. If this link disappears then the configuring node gives up, 1040 otherwise the configuring node assigns a global address to the new 1041 joining node. 1043 The process of obtaining a temporary address consists of having an 1044 address space, where each MANET node independently selects an address 1045 sequence from this space and signals it to its neighbours (through 1046 beacons). Each MANET node records the address sequence received from 1047 is neighbours to avoid conflicts in the chosen addresses. If a 1048 conflict is detected between two nodes, the node with the lowest ID 1049 should select a new sequence if both nodes are not configuring nodes 1050 (MANET nodes that are not yet engaged in configuring a new node). 1051 Otherwise, if one or more configuring nodes are involved in the 1052 conflict, each configuring node should narrow its sequence of 1053 addresses to contain only the address that is currently assigned (in 1054 order to keep on the configuring session). On the other hand two 1055 options exist for global addresses allocation. One option is that 1056 the configuring node acts as a modified DHCP proxy and transmits a 1057 request to a DHCP server to acquire a global address for each new 1058 node it configures. Another option is that the configuring node 1059 consults the nodes' topology tables (containing destinations and thus 1060 network addresses), and then picks up an unused address. It then 1061 sends an advertisement to all MANET nodes to be sure that this 1062 address is not used. If a node detects that its address is being 1063 used, it can signal the conflict to the originator of the 1064 advertisement. 1066 Based on [2], this solution has the following key features: 1068 o MANET scenario: This proposed solution targets connected MANET 1069 scenarios. 1071 o Routing protocols' dependency: This proposed solution uses OLSR, 1072 typically extending OLSR messages, however it is not dependent on 1073 the routing protocol. Although the proposed solution is open to 1074 any routing protocol, the fact that periodical beacons are used 1075 requires a proactive routing protocol. 1077 o Address uniqueness: The proposed solution uses a Non-unique 1078 Address Detection mechanism to avoid conflicts in IP address 1079 assignment. In global address allocation, using a Non-unique 1080 Address Detection mechanism is an option but the proposed solution 1081 can function without a Non-unique Address Detection mechanism if 1082 the modified DHCP proxy approach is followed. While in temporary 1083 address allocation, a limited Non-unique Address Detection 1084 mechanism is used with the neighbourhood to resolve any conflict 1085 when assigning temporary addresses sequences to MANET nodes. 1087 o Distributed/Centralised approach: The proposed solution is 1088 distributed in the sense that it can employ a decentralised DHCP 1089 server using the concept of proxy DHCP to reach the server. 1091 o Merging support: This proposed solution has no merging support. 1093 o Prefix assignment support: The proposed solution allows prefix 1094 assignment through using DHCP. 1096 o Protocol overhead: the solution requires a considerable number of 1097 signalling. This is mainly during the advertisement messages for 1098 global addresses flooded to all nodes in the network for verifying 1099 the global address uniqueness, the periodical ADDR_BEACON messages 1100 that are transmitted by each configuring nodes to its neighbours, 1101 and the Beacon messages signalling the selected address space by 1102 each configuring node during the process of temporary address 1103 assignment. Furthermore, AREQ messages are used by each new 1104 joining node while communicating a neighbour configuring node, 1105 which in turn replies by an Addr-config message. 1107 2.2.1.3. Extensible MANET Auto-configuration Protocol (EMAP) (Ros et 1108 al.) 1110 The Extensible MANET Auto-configuration Protocol (EMAP) [20] provides 1111 an autoconfiguration solution for isolated as well as hybrid MANETs. 1112 EMAP is envisioned to be integrated within unicast routing protocols 1113 as DYMO or OLSRv2. The notion of intermediate proxies is used in the 1114 autoconfiguration process. The general EMAP framework may be used as 1115 a service discovery protocol for MANETs, however the approach is 1116 extensible to other services. An optional feature in EMAP includes 1117 DNS discovery, where nodes can discover DNS servers reachable from 1118 the MANET, and this feature can be extended to services like SIP, 1119 proxies, and authentication entities. 1121 Assumptions: It is assumed that at least one element must act as a 1122 gateway between the MANET and the fixed network. This element is 1123 called an Internet Gateway (IGW). 1125 Approach description: EMAP allows MANET nodes to configure unique IP 1126 local addresses and globally routable IP addresses. The local 1127 configuration allows a MANET node to communicate with other nodes in 1128 the same MANET. To configure a local address, the MANET node picks 1129 an IP address and asks the network if it is already being used, thus 1130 avoiding address duplication. In this process, a node generates a 1131 pair of IP addresses: temporary and tentative ones. The temporary 1132 address is used as the originator-address, where it can be a mobile 1133 IP home address or another sort of highly likely unique address. 1134 While the tentative address is the one which is being requested and 1135 is used as the requested address in the DAD_REQ messages and the 1136 originator-address in DAD_REP messages. Thanks to the proxy 1137 functionality, intermediate nodes can also answer with a DAD_REP 1138 message if they do not own the requested address but they do know 1139 that it is being used by another node. If the MANET node sending the 1140 DAD_REQ receives no DAD_REP messages, then it understands that there 1141 is no address conflict and it considers that the tentative address is 1142 its local address. 1144 On the other hand, global configuration takes place through using the 1145 Internet Gateway (IGW), which may be a fixed element belonging to 1146 each network, or a mobile one which detects the presence of an 1147 attachment point to the Internet (e.g. a wireless router). The 1148 mobile node requesting a global address either waits for 1149 advertisements sent by the IGW (mainly advertising its prefix) to 1150 configure its global address or floods a global configuration request 1151 (GC_REQ) message. When an IGW receives a GC_REQ message, it sends a 1152 global configuration reply message (GC_REP) to the originator-address 1153 through unicast. Thus, the originating node is able to auto- 1154 configure a global address by substituting the first bits of the 1155 requested local address by the prefix advertised by the IGW. When 1156 there are multiple IGWs announcing their own information, the MANET 1157 node selects one, and the selection rules are implementation- 1158 dependent. 1160 A given option in EMAP allows a MANET node to issue a query to find 1161 DNS Server Advertisers, which provide IP addresses of available DNS 1162 servers. This feature may be quite useful in situations where a high 1163 degree of auto-configuration is desired. 1165 Based on [2], this solution has the following key features: 1167 o MANET scenario: This proposed solution is designed for standalone 1168 MANETs and connected MANETs. 1170 o Routing protocols' dependency: Although EMAP is envisioned to be 1171 integrated with unicast routing protocols like DYMO or OLSRv2, it 1172 may be implemented as a standalone daemon. 1174 o Address uniqueness: The proposed solution uses a Non-unique 1175 Address Detection mechanism during the autoconfiguration of MANET 1176 local addresses. 1178 o Distributed/Centralised approach: The proposed solution is a 1179 distributed solution in the sense of not being based on any DHCP 1180 servers. 1182 o Merging support: No special merging mechanisms are explained in 1183 this solution. However, no in-service Non-unique Address 1184 Detection is used which makes the merging support not feasible. 1186 o Prefix assignment support: This solution employs IPv6 prefixes, 1187 where gateway nodes are responsible for advertising their 1188 prefixes. 1190 o Protocol overhead: the solution adds certain overhead, depending 1191 on the network size, the number of IGWs, and the applied option in 1192 global address configuration. The resulting overhead in this 1193 solution mainly concerns: flooding of the local address selected 1194 by each joining node to verify its uniqueness through the DAD_REQ 1195 messages, prefix advertisement by IGWs during global address 1196 configuration (this has more impact on the overhead when the 1197 number of IGWs increases), and flooding of GC_REQ messages by the 1198 node requesting a global address (in case that no prefix 1199 advertisement is taking place by the IGWs) where in this case 1200 GC_REP messages are sent by IGWs through unicast. Furthermore, 1201 DAD_REPLY messages could take place in case of address conflicts 1202 detection. 1204 2.2.1.4. Global Connectivity for IPv6 Mobile Ad Hoc Networks (Wakikawa 1205 et al.) 1207 The solution described in [21] proposes how to provide Internet 1208 connectivity with mobile ad hoc networks. It describes how to obtain 1209 a globally routable IPv6 address from an Internet gateway. The 1210 Internet access method is not dependent on a particular MANET routing 1211 protocol, however there is still a need to a protocol. 1213 Assumptions: The solution assumes that before configuring a global 1214 IPv6 address, the node has configured a routable address (i.e. 1215 MANET-local address or a Mobile IPv6 home address). The routable 1216 address is used for initial configuration when a node boots up and 1217 joins the MANET. 1219 Approach description: This mechanism [21] is similar to [22] from the 1220 point of view of how IPv6 addresses are configured. Global prefix 1221 information is obtained from Internet gateways. Two methods are 1222 proposed for the Internet gateway discovery: one method periodically 1223 disseminates gateway advertisements to all nodes in the MANET; the 1224 other method utilises solicitation and advertisement signalling 1225 between a MANET node and the gateway. Extended router solicitation 1226 and advertisements of the Neighbour Discovery Protocol (NDP) or 1227 extended control message of each MANET routing protocol can be used 1228 for this signalling. The proposed methods target all MANET protocols 1229 regardless of whether they are reactive or proactive. Internet 1230 gateways supply their own global prefix information and IPv6 global 1231 address to MANET nodes somehow, either proactively or reactively. In 1232 this way, the reactive and proactive route discovery features of each 1233 MANET routing protocol are not disturbed. An advertisement from the 1234 Internet gateway provides prefix information -- IP routing prefix and 1235 prefix length -- and lifetime. 1237 After accepting an advertisement from the Internet gateway inserts 1238 the Internet gateway address as an Internet route and the MANET node 1239 configures a global address from the prefix of the Internet gateway. 1240 It uses the 64-bit interface ID in order to construct a valid address 1241 with the acquired prefix. It is assumed that before configuring a 1242 global IPv6 address, the node has configured a routable local address 1243 (i.e. MANET-local address), and a Non-unique Address Detection 1244 mechanism has been performed for that routable local address (e.g. 1245 using the mechanism defined in [4] and [23]), so it is assumed that 1246 the global address would be also unique. If not, the node may 1247 perform another Non-unique Address Detection mechanism for this 1248 global address. 1250 If the destination of a packet is inside the MANET even though a 1251 global routable address is used as destination address, the gateway 1252 prevents this packet from being forwarded to the Internet. It 1253 returns the packet back to the MANET if it has a MANET route for the 1254 destination. The source node receives an ICMP Redirect message from 1255 the Internet Gateway warning that it should use a host route (MANET- 1256 local address) instead of a default route (Internet route). To do 1257 so, each Internet gateway may manage a list of IP addresses of all 1258 the associated MANET nodes (mainly if a reactive ad hoc routing 1259 protocol is being used). So, each MANET node must contact the 1260 Internet gateway at least once it establishes an Internet route 1261 through the Internet Gateway in order to communicate its global 1262 routable address to the Internet Gateway. 1264 Based on [2], this solution has the following key features: 1266 o MANET scenario: the solution targets connected MANETs. 1268 o Routing protocols' dependency: Not restricted to any particular ad 1269 hoc routing solution, and it is designed to work properly with 1270 both proactive and reactive protocols. 1272 o Address uniqueness: It is assumed that the global address would be 1273 also unique. If not, the node may perform a Non-unique Address 1274 Detection mechanism for this global address. In any case the Non- 1275 unique Address Detection mechanism is considered out of scope. 1277 o Distributed/centralised approach: The proposed solution uses a 1278 distributed approach where nodes do not solicit any centralised 1279 server for IP address assignment. 1281 o Merging support: No special merging mechanisms are discussed in 1282 this solution. Also, no in-service Non-unique Address Detection 1283 is used which makes the merging support not feasible. 1285 o Prefix assignment support: the solution does not support the 1286 assignment of IPv6 prefixes to nodes. 1288 o Protocol overhead: depends on the approach utilised. If extended 1289 control messages of the MANET routing protocol -- including global 1290 prefix information -_ are used the solution introduces low 1291 overhead, but if gateway advertisement messages are periodically 1292 flooded (with the hop limit field set to an appropriate value in 1293 the MANET) then the solution introduces high overhead. 1295 2.2.1.5. Multihop Radio Access Network (MRAN) Protocol Specification 1296 (Hofmann) 1298 This proposed solution [24] presents the Multihop Radio Access 1299 Network (MRAN) protocol, which is an IPv6-based protocol for the 1300 interconnection of ad hoc networks and the Internet. MRAN proposes 1301 an approach that enables mobile ad hoc nodes to communicate with 1302 correspondent nodes on the Internet. The application scenario of 1303 this protocol is mainly when multiple gateways are available and 1304 mobile nodes are frequently changing these gateways. The gateways 1305 are supposed to be fixed and advertising different prefixes. MRAN 1306 treats the gateways discovery and selection, the autoconfiguration of 1307 global addresses, and the packet forwarding to/from the fixed 1308 network. 1310 Assumptions: It is assumed that mobile nodes (MNs) and Gateways (GWs) 1311 use local addresses for communication within the MANET and that 1312 routing is performed by a MANET routing protocol. It is also assumed 1313 that a flooding protocol is used for broadcasting certain MRAN 1314 control messages, where the flooding functionality may be provided by 1315 the routing protocol. 1317 Approach description: The operation of MRAN involves several 1318 functions: GW discovery, GW selection, address autoconfiguration, 1319 registration with the GW, packet forwarding and multi-hop handovers. 1320 Three modes of GW discovery are proposed and the choice between them 1321 depends on the application scenario. In proactive GW discovery, all 1322 GWs periodically broadcast advertisement messages "GW_ADV", where MNs 1323 in proactive mode requiring Internet access waits until they receive 1324 such a message. The reactive mode discovery allows MNs to discover 1325 the available GWs when needed through broadcasting a GW solicitation 1326 message. A GW receiving such a message replies by unicast solicited 1327 GW advertisement message "sol_GW_ADV" to the MN. Hybrid GW discovery 1328 mode is a combination of both proactive and reactive discovery, where 1329 the GW is in proactive mode and the MN is in reactive one. All GW 1330 advertisement messages contain the GW globally valid prefix of 64 1331 bits length. The GW selection process allows each MN to select the 1332 closet GW with respect to the number of hops. Other additional 1333 metrics may be included in the selection process. After the GW 1334 selection, the MN uses the selected GW's prefix and its own EUI-64 to 1335 autoconfigure the global address. It may subsequently perform a Non- 1336 unique Address Detection. Registration with the selected GW should 1337 take place, where the MN sends a registration request message 1338 "MN_REG" to the selected GW. A GW receiving this message replies by 1339 a registration acknowledgement message "MN_REG_ACK" indicating the 1340 successful registration. The MN then periodically repeats the 1341 registration process and the registration may be used for other 1342 purposes as well (for instance the AAA). To assure appropriate 1343 packet forwarding between each MN and its selected GW, payload 1344 packets are tunnelled between MNs and GWs in both directions. The 1345 tunnelling approach uses IP-in-IP encapsulation thus allowing using 1346 local addresses for intra-MANET communication. In the tunnel from 1347 the GW to the MN, the destination address of the inner IP header is 1348 the MN global address and the destination address of the outer header 1349 is the local address of the MN. On the other hand, in the tunnel 1350 from the MN to the GW, the destination address of the inner IP header 1351 is the CN global address, whereas the destination address of the 1352 outer header is the local address of the GW. In the case of MN's 1353 disconnection from its current GW while communicating with a CN in 1354 the Internet, multihop handover takes place. Thus, the MN has to 1355 discover, select and register with another GW. This is called a 1356 "forced multihop handover". For optimisation reasons, the MN may 1357 also select a new GW that could be more close than the current GW. 1358 In this case, the MN performs the registration with the new GW while 1359 it is connected to the current one. This is known as "optimised 1360 multihop handover", and is much faster than the forced one. 1362 Maintenance takes place through creating two tables: i) GW table, and 1363 ii) MN table. MNs maintain a GW table storing information about the 1364 available GWs (local address, prefix, expiration time, registration 1365 expiration). A table entry is created when the MN receives a GW_ADV 1366 or Sol_GW_ADV messages. On the other hand, GWs maintain MN tables 1367 storing information about mobile nodes having a valid registration, 1368 where each entry in this table stores the following information on 1369 MNs (local address, global address, registration expiration time). 1371 Based on [2], this solution has the following key features: 1373 o MANET scenario: This proposed solution targets connected MANET 1374 scenarios enabling mobile nodes to communicate with correspondent 1375 nodes in the Internet. 1377 o Routing protocols' dependency: This proposed solution works 1378 independent of the MANET routing protocol. 1380 o Address uniqueness: The proposed solution may use a Non-unique 1381 Address Detection mechanism. 1383 o Distributed/Centralised approach: The proposed solution uses a 1384 distributed approach, where it does not solicit any centralised 1385 server for IP address assignment. 1387 o Merging support: No special merging mechanisms are discussed in 1388 this solution. Also, no in-service Non-unique Address Detection 1389 is used which makes the merging support not feasible. 1391 o Prefix assignment support: This proposed solution supports 1392 prefixes assignment, where the different gateways are responsible 1393 for IPv6 prefixes advertisements. 1395 o Protocol overhead: the solution integrates several mechanisms and 1396 there is a number of flooding used to achieve the proper 1397 mechanisms' functioning. The overhead in this solution mainly 1398 lies in the assumption of an existing flooding protocol for 1399 broadcasting certain MRAN control messages, and GWs periodical 1400 broadcast of GW_ADV messages (containing the GW prefix) when 1401 proactive GW discovery is applied. Also, GW_Solicitation messages 1402 are broadcast on-demand when reactive GWs discovery is applied, 1403 and periodical MN_REG messages are sent to the selected GWs by 1404 each node requesting an IP address which is acknowledged by a 1405 MN_REG_ACK by the selected GW. Furthermore, additional messages 1406 are used for maintenance. 1408 2.2.1.6. Automatic IP Address Configuration in VANETs (Fazio et al.) 1410 Automatic IP address configuration is a challenging and still 1411 unexplored issue in vehicular ad hoc networks (VANETs) environments, 1412 where the vehicles' high mobility and variant density impede the 1413 direct utilisation of traditional networking techniques and 1414 protocols. Aiming at integrating VANETs within the Internet and 1415 providing passengers with any kind of Internet applications, the IP 1416 address represents the natural identifier in the system. This work 1417 [25] proposes an IP autoconfiguration solution in VANETs environment, 1418 exploiting the VANETs topology and an enhanced DHCP service with 1419 dynamically elected leaders to provide a fast and reliable IP address 1420 configuration. 1422 Assumptions: It is assumed that the network topology is linear and 1423 that a group of nodes move following a track with an internal 1424 mobility with respect to each other. It is also assumed that the 1425 relative speed between nodes is low. 1427 Approach description: This work proposes a novel automatic IP address 1428 configuration protocol named Vehicular Address Autoconfiguration 1429 (VAC), that is characterised by a low configuration time. VAC 1430 represents the first protocol for IP address configuration in VANETs. 1431 It exploits the VANET topology and a distributed dynamic host 1432 configuration protocol (DHCP) runs by dynamically elected leader 1433 vehicles to quickly provide unique identifiers and reduce the 1434 frequency of IP address re-configurations due to mobility. VAC 1435 organises leaders in a connected chain such that every node (vehicle) 1436 lies in the communication range of at least one leader. This 1437 hierarchical organisation allows limiting the signal overhead for the 1438 address management tasks. Only leaders communicate with each others 1439 to maintain updated information on configured addresses in the 1440 network. Leaders act as servers of a distributed DHCP protocol and 1441 normal nodes ask leaders for a valid IP address whenever they need to 1442 be configured. 1444 VAC guarantees unique IP addresses within a defined SCOPE around the 1445 leader, where the SCOPE of the leader A is the set of leaders whose 1446 distance from A is less or equal to SCOPE hops. Considering the 1447 normal node Y that received the IPy address from A, IPy will be 1448 unique as long as Y moves within the SCOPE of A. If Y goes out of the 1449 SCOPE of A, in order to still ensure the address uniqueness, Y has to 1450 ask the new leader for another address. Considering that the 1451 relative speed between the nodes is low, changes in the address 1452 configuration due to having left the own leader's SCOPE are not 1453 frequent. 1455 Based on [2], this solution has the following key features: 1457 o MANET scenario: The proposed solution targets connected MANET 1458 scenarios, enabling mobile nodes (vehicles) to communicate with 1459 correspondent nodes on the Internet. 1461 o Routing protocols' dependency: Apparently VAC does not depend on a 1462 special routing protocol. However no clear definition is given on 1463 how and what control messages are exchanged in order to configure 1464 each node requiring an IP address. 1466 o Address uniqueness: The proposed solution does not employ any Non- 1467 unique Address Detection mechanisms, however it guarantees address 1468 uniqueness for each configured node. 1470 o Distributed/Centralised approach: The proposed solution employs a 1471 partially distributed approach, where distributed DHCP run by some 1472 mobile nodes (vehicles)that are elected in a dynamic manner to 1473 assign IP addresses to the requesting nodes. 1475 o Merging support: No special merging mechanisms are explained in 1476 this proposed solution, however it could support merging. The 1477 SCOPE principle together with the distributed DHCP permit the 1478 nodes to join/leave different SCOPES while acquiring a new address 1479 from the SCOPE leader. 1481 o Prefix assignment support: This proposed solution does not employ 1482 any IPv6 prefix assignment to nodes. 1484 o Protocol overhead: the hierarchical organisation in this solution 1485 limits the signalling overhead and avoids flooding. The overhead 1486 in this solution mainly concerns: the signalling messages for 1487 communication between leaders nodes, the request messages sent by 1488 mobile nodes requesting an IP address from their leaders (this 1489 takes place in a limited scope), and the reply messages from the 1490 leaders to the requesting mobile nodes for assigning IP addresses 1491 (this also takes place in a limited scope). It is noticed that 1492 this solution does not use Non-unique Address Detection mechanisms 1493 due to the distributed DHCP functionality among leader nodes, 1494 which helps in limiting the signalling overhead. 1496 2.2.2. Merging support 1498 2.2.2.1. Address Autoconfiguration in Optimized Link State Routing 1499 Protocol (Adjih et al.) 1501 This proposed solution [26] is based on the concept of conflict 1502 detection. Each node periodically sends its address and an 1503 identifier. The node identifier is a sequence of bits, of fixed 1504 length (L), that is randomly generated. An address conflict is 1505 detected when the identifier mismatches. This proposed solution is 1506 suitable for OLSR routing protocol with a light increase of control 1507 message overhead, however, it might be used with any MANET protocol. 1508 Two issues are addressed in this solution, an IPv6 stateless 1509 autoconfiguration mechanism and a mechanism promoting address 1510 uniqueness in the situation where different ad hoc networks merge. 1512 Assumptions: Two assumptions are mainly considered in this proposed 1513 solution. Firstly, it is assumed that the identifier of each node is 1514 globally unique in the network. Secondly, it is assumed that a MANET 1515 may be isolated. 1517 Approach description: In this proposed solution, a new mobile node 1518 joining the network is assigned an IP address then it carries out a 1519 conflict detection procedure through running a Non-unique Address 1520 Detection mechanism. If another node is detected to have the same 1521 address, the new joining node selects a new address. The address 1522 assignment process takes place as follows: i)consulting a neighbour 1523 node that should configure an address for the new node. The 1524 neighbour node then selects an IP address and sends it to the new 1525 node. This takes place by control messages exchange. ii) picking up 1526 a random address inside a given subnet with MANET_prefix either from 1527 a pool of allocated addresses or through a set of addresses 1528 advertised by each MANET node and are believed not used. In case of 1529 address pool existence, this pool could be reserved by the IANA for 1530 local use only (i.e. not forwarded outside MANET). In addition, in 1531 case of MANETs connected to the Internet, nodes acting as gateways 1532 diffuse IPv6 router advertisement messages. In this case each 1533 address in the pool would be a global address that can be seen from 1534 the outside. 1536 The Non-unique Address Detection algorithm uses a single special 1537 control message to perform conflict detection. Each node 1538 periodically diffuses to the entire network a special message called 1539 MAD (Multiple Address Declaration). This message contains the node 1540 address and a unique identifier for the node. Several mechanisms are 1541 proposed for MAD messages propagation. When using OLSR, propagation 1542 of MAD messages mainly relies on the MPR flooding, where a number of 1543 MPR selection rules are explained, presenting different options. If 1544 another routing protocol is used, default pure flooding is used for 1545 MAD messages propagation. In case of IP conflict discovery, this is 1546 resolved by the node with the smaller identifier in each conflicting 1547 pair. This node should change its IP, selecting a new IP at random 1548 (that is believed to be free) following the same approach of IP 1549 address assignment. 1551 When OLSR routing protocol is used, an additional proposed option is 1552 using Passive Duplicate Detection. In this case, the topological 1553 information diffused by the OLSR routing protocol is sufficient to 1554 detect address conflict. However, some MPR selection mechanisms are 1555 used to ensure that the control messages are properly propagated. 1557 Based on [2], this solution has the following key features: 1559 o MANET scenario: This proposed solution targets both standalone and 1560 connected MANETs scenarios. 1562 o Routing protocols' dependency: This proposed solution depends on 1563 the underlying routing protocol. 1565 o Address uniqueness: the proposed solution comprises a Non-unique 1566 Address Detection mechanism. The notion of passive duplicate 1567 detection is also used, where the solution makes use of the 1568 routing protocol messages propagation to detect the address 1569 conflicts. 1571 o Distributed/Centralised approach: The proposed solution uses a 1572 distributed approach in the sense of not communicating with a 1573 centralised DHCP server to acquire IP addresses. 1575 o Merging support: This proposed solution has a merging support, 1576 since the conflict detection process is periodically carried out 1577 by mobile nodes. Thus, this solution assures address uniqueness 1578 in case of ad hoc networks merge. 1580 o Prefix assignment support: This solution does not support IPv6 1581 prefix assignment to nodes. 1583 o Protocol overhead: the solution adds low protocol overhead, since 1584 this solution benefits from the OLSR routing protocol signalling 1585 and MPRs concept to verify the address conflicts. The signalling 1586 in this solution is limited to a single control message (MAD 1587 message) to perform conflicts detection. If passive duplicate 1588 detection option is applied with OLSR, the overhead is almost 1589 none, as the topological information diffused by OLSR is 1590 sufficient to detect address conflict. However, if another 1591 routing protocol is used (which is an option), the MAD messages 1592 have to be flooded resulting in a 'medium' overhead since the 1593 flooding is limited to only one message in this case. 1595 2.2.2.2. Extended Support for Global Connectivity for IPv6 Mobile Ad 1596 Hoc Networks (Cha et al.) 1598 The solution described in [27] proposes a stateful global IP 1599 autoconfiguration for MANETs with the goal of providing enhanced 1600 Internet connectivity to mobile ad-hoc networks. This stateful 1601 autoconfiguration is performed through the exchange of extended 1602 control messages of MANET routing protocols. The protocol is devised 1603 as an extension to AODV, but the concept may be applicable to 1604 proactive routing protocols. 1606 Assumptions: The solution assumes that each node has a 1607 local_IP_address configured. 1609 Approach description: The protocol basically consists in nodes 1610 requesting global addresses to a gateway, which assigns a non-used 1611 address to the requesting node. When an ad hoc node needs a global 1612 IP address it sends an Internet-gateway solicitation message (GW_SOL 1613 message). The Gateway uses an Internet-gateway advertisement(GW_ADV 1614 message)to assign the solicited global IP address to the ad hoc node. 1616 Given the event that an ad hoc node which has a Global IP address 1617 (e.g., G-A1) assigned by a gateway (e.g., GW1) cannot reach GW1 1618 anymore due to a partition in the MANET but this ad hoc node has 1619 Internet connectivity through a different gateway (e.g.. GW2), the 1620 ad hoc node gets another global IP address from GW2 (e.g., G-A2) and 1621 it performs a Locator Registration Procedure with GW1. This locator 1622 registration procedure is similar to Binding Updates in Mobile IPv6. 1623 Using this procedure the ad hoc node registers G-A2 as CoA -- Care of 1624 Address in Mobile IPv6 terminology -- of G-A1, so that ongoing 1625 communications are kept. 1627 More details can be found in [27]. 1629 Based on [2], this solution has the following key features: 1631 o MANET scenario: the solution targets connected MANETs. 1633 o Routing protocols' dependency: although the protocol is devised as 1634 an extension to AODV, it could be applicable to proactive routing 1635 protocols. 1637 o Address uniqueness: since non-duplicate addresses are assigned to 1638 ad hoc nodes, the proposed solution is Non-unique Address 1639 Detection-free. 1641 o Distributed/centralised approach: the solution makes use of 1642 centralised servers (gateways) in order to assign IP global 1643 addresses. 1645 o Merging support: given that the proposed solution assigns global 1646 IP addresses avoiding duplicates, merging is supported. On the 1647 other hand it supports partitions through the Locator Registration 1648 Procedure. 1650 o Prefix assignment support: the solution does not support the 1651 assignment of IPv6 prefixes to nodes. 1653 o Protocol overhead: the solution adds certain protocol overhead, 1654 since the mechanism appends some fields to AODV routing protocol 1655 (RREQ message) to ask for a global IP address and gateway 1656 information, and the replay (GW-ADV message) is unicast to the 1657 originator MANET node. The solution includes the possibility of 1658 gratuitous GW_ADV broadcast periodically. 1660 2.2.2.3. Gateway and Address Autoconfiguration for IPv6 Adhoc Networks 1661 (Jelger et al.) 1663 This proposed solution [22] allows nodes in an ad hoc network to 1664 proactively discover a gateway/prefix pair to be used in building an 1665 IPv6 global address and to maintain a default route towards the 1666 Internet. The core element of this proposed solution is the concept 1667 of "Prefix Continuity". With prefix continuity, any node A that 1668 selected a given prefix P has at least one neighbour with prefix P on 1669 its path to the selected gateway G, thus assuring that each node on 1670 the path between node A and the Gateway G uses the same prefix P. 1672 Assumptions: It is assumed that each node can find a Gateway to 1673 connect with and that each node can be assigned a global address 1674 through this gateway. It is also assumed that one (or possibly more) 1675 nodes of the ad hoc network should provide connectivity to the 1676 Internet, thus acting as Gateways to other nodes. 1678 Approach description: In this proposed solution, each Gateway (GW) 1679 periodically sends a GW_INFO message notifying nodes in the ad hoc 1680 network about its existence as well as the prefix it uses. Some 1681 information in the GW_INFO message allows nodes to select the more 1682 appropriate GW when more than one GW exist. Other information 1683 contained in this message concerns: the GW global address, the length 1684 of the prefix part of the address, and the distance to the gateway as 1685 perceived by the node sending the message. The node receiving the 1686 GW_INFO message forwards it to its 1-hop neighbourhood, where the 1687 forwarder node is considered as the upstream node for each node that 1688 receives the message. Among the transmitted GW-Info messages, each 1689 mobile node selects (through a selection algorithm) only one 1690 neighbour as its upstream neighbour and receives the GW_INFO messages 1691 from this neighbour (i.e. consider this upstream as an intermediate 1692 node to the gateway), then it forwards the message. A node must not 1693 forward a GW_INFO message sent by a node that is not its upstream 1694 neighbour. The destination address of the IPv6 header of the packet 1695 containing the GW_INFO message must be FF02::1 (all nodes), while the 1696 source address of such a packet must be the link local address of the 1697 sender. Thanks to the prefix continuity, the routing via the GW can 1698 be achieved without the need of an IPv6 routing header. Each mobile 1699 node creates its IPv6 global address as follows: {Extended Unique 1700 Identifier (EUI) of the interface from which the GW_INFO message is 1701 received + prefix contained in the message}. No Non-unique Address 1702 Detection mechanism is needed in this approach, as there is a very 1703 little probability of address duplication when EUI is used. 1705 Based on [2], this solution has the following key features: 1707 o MANET scenario: This proposed solution targets connected MANETs 1708 scenarios. 1710 o Routing protocols' dependency: This proposed solution is 1711 independent (in terms of message semantics) of the underlying 1712 routing protocol. Thus, it can be integrated in the operation of 1713 the routing protocol or it can run as standalone daemon. 1715 o Address uniqueness: The proposed solution does not depend on a 1716 Non-unique Address Detection procedure or mechanism. 1718 o Distributed/Centralised approach: The proposed solution is 1719 distributed in the sense of not employing any centralised DHCP 1720 server. 1722 o Merging support: Although no Non-unique Address Detection 1723 mechanism is used, this proposed solution supports networking 1724 partitioning and merging as it is based on generating an IPv6 1725 address for each node based on the prefix advertisements. 1727 o Prefix assignment support: This proposed solution is based on the 1728 prefix continuity and is thus supporting prefix assignment. Each 1729 gateway advertises the IPv6 prefix that it uses. 1731 o Protocol overhead: depends on the network size and the number of 1732 GWs. The main signalling in this solution mainly concerns the 1733 GW_INFO messages that are periodically sent by each GW notifying 1734 its existence as well as its prefix. Since no Non-unique Address 1735 Detection mechanism is needed in this solution, this helps in 1736 limiting the signalling and hence the overhead. 1738 2.2.2.4. MANET Autoconfiguration using DHCP (Templin et al.) 1740 This draft [28] discusses about possible solution architectures to 1741 provide MANET nodes with IP address autoconfiguration capabilities. 1742 Basically, the solution proposes to connect nodes within a MANET by 1743 means of virtual ethernets, which are imaginary shared links that 1744 connects the MANET nodes. The nodes attach to the virtual ethernet 1745 via an interface configured over underlying MANET interface(s). 1746 Using this virtual ethernet, MANET nodes can configure global IPv6 1747 addresses using for example DHCPv6. 1749 Assumptions: It is assumed that a MANET Router (MR) embodies a router 1750 entity linked to one or more host entities by virtual point-to-point 1751 interfaces. It is also assumed that the router entity also connects 1752 to an imaginary shared link (i.e., a "virtual ethernet") that 1753 connects all MRs in the MANET. 1755 MANETs are connected to other networks by means of MANET Border 1756 Routers (MBRs). MBRs are assumed to have configured a DHCP relay 1757 and/or a DHCP server. 1759 Approach description: The proposed solution considers that MANET 1760 Routers are attached to an imaginary shared link (called "virtual 1761 ethernet") that connects all the MRs in the MANET. Two different 1762 types of "virtual ethernets" are defined: 1764 o An "enhanced" view of this virtual ethernet sees the MANET as a 1765 fully-connected shared link that connects all MRs. With this 1766 approach, the MR encapsulates each IP packet in an outer IP header 1767 and then sends it on an underlying MANET interface such that the 1768 HOP Limit in the inner IP header is not decremented as the packet 1769 traverses the MANET. Therefore, with this view, all MRs are 1770 neighbours and standard Neighbour Discovery works as-normal. In 1771 [29], this particular approach is separately documented. 1773 o An "unenhanced" view sees the MANET as a multilink site. With 1774 this approach, the MR sends each IP packet on an underlying MANET 1775 interface without further encapsulation, and therefore the Hop 1776 Limit may be decremented as the packet traverses the MANET. With 1777 this view, since there are multiple hops between MRs, a "site- 1778 scoped" equivalent of ND is defined (called Extended Neighbour 1779 Discovery, END). In [30], this particular approach is separately 1780 documented. 1782 The MANET Router autoconfiguration procedure works as follows: first, 1783 each MR configures MANET Local Addresses (MLAs) on each MANET 1784 interface. These MLAs should be unique within the MANET and are used 1785 as an identifier for operating the routing protocol (can also be used 1786 as a locator for packets forwarded within the scope of the MANET). 1787 In IPv6, MLAs are typically generated using Unique Local Addresses 1788 with interface identifiers that are either managed for uniqueness or 1789 self-generated using a suitable random interface identifier 1790 generation mechanism that is compatible with EUI-64 format. 1792 In a second step, the MR engages in the routing protocol over its 1793 MANET interfaces and discovers the list(s) of MBRs that identify the 1794 MANET(s). There are multiple approaches that can be used to perform 1795 this MBR discovery, such as the use of information contained in the 1796 routing protocol, a DHCP option, etc. 1798 For each MANET to which the MR attaches, it also configures a virtual 1799 ethernet interface over the underlying MANET interfaces connected to 1800 the MANET. After the MR configures the virtual ethernet interface, 1801 it can verify the reachability of MBRs and discover prefixes 1802 associated with the MANET's virtual ethernet. This is done by using 1803 Router Solicitation/Router Advertisement exchanges, either using 1804 normal IPv6 Neighbour Discovery -- in the case of "enhanced" view -- 1805 or Extended Neighbour Discovery -- for the "unenhanced" view. It is 1806 also possible to use information conveyed in the routing protocol 1807 itself, or through some other means associated with the particular 1808 link technology. 1810 After the MR discovers MBRs, it can configure addresses/prefixes 1811 according to either DHCPv6 or IPv6 Stateless Address 1812 AutoConfiguration (SLAAC). When the former method is used, the MR 1813 sends a DHCPv6 request to the MBR(s) to get global address/prefix 1814 delegations and then assigns addresses/prefixes to internal virtual 1815 interfaces and/or downstream- attached physical interfaces. Once the 1816 MR has obtained a global IPv6 address/prefix, it can send packets 1817 with global source addresses using RFC4191 [31] router selection. 1819 It should be noted that for the global addresses/prefixes [32] 1820 obtained through DHCPv6, a Non-unique Address Detection mechanism is 1821 not needed, since DHCPv6 ensures the uniqueness of the delegated 1822 addresses/prefixes. However, the MLAs assigned to MANET interfaces 1823 should be statistically unique so MANET-wide pre-service Non-unique 1824 Address Detection mechanism is not needed. Alternatively, passive 1825 in-service Non-unique Address Detection mechanisms can be used to 1826 detect other MRs potentially using the same MLA. 1828 Based on [2], this solution has the following key features: 1830 o MANET scenario: the solution targets connected MANETs. 1832 o Routing protocols' dependency: the solution is routing protocol 1833 independent. 1835 o Address uniqueness: the proposed solution does not define any Non- 1836 unique Address Detection mechanism. the uniqueness of MANET Local 1837 Addresses assigned to MANET interfaces should be statistically 1838 ensured so MANET-wide pre-service Non-unique Address Detection is 1839 not needed. If this cannot be achieved, passive in-service Non- 1840 unique Address Detection mechanisms can be used to detect other 1841 MRs potentially using the same MLA. The uniqueness of the global 1842 IPv6 assigned addresses/prefixes is ensured by DHCPv6. 1844 o Distributed/centralised approach: the solution makes use of the 1845 available DHCPv6 servers to assign global IPv6 addresses/prefixes, 1846 although some hints about the use of IPv6 StateLess Address 1847 AutoConfiguration (SLAAC) are also provided in Appendix B of [28]. 1849 o Merging support: the solution supports merging. Different 1850 mechanisms are proposed to deal with different defined 1851 partitioning/merging scenarios. 1853 o Prefix assignment support: the solution supports the assignment of 1854 IPv6 prefixes to nodes. 1856 o Protocol overhead: depending on the virtual ethernet approach 1857 followed, it can add overhead -- for the 'enhanced' view, where 1858 normal IPv6 SLAAC or DHCPv6 can be used --, or medium overhead -- 1859 for the 'unenhanced' view, where an Extended Neighbour Discovery 1860 mechanism (that makes use of site-scoped message flooding) is 1861 required. 1863 3. Security Considerations 1865 Due to the open wireless environment of ad hoc networks, IP 1866 autoconfiguration mechanisms are susceptible to a number of attacks. 1867 The autoconfiguration problem statement draft [1] states some 1868 security issues that worth consideration. 1870 4. IANA Considerations 1872 This document has no actions for IANA. 1874 5. Acknowledgements 1876 We would like to thank all the AUTOCONF ML people that provided 1877 comments to the previous version of the I-D. We would also like to 1878 thank Kilian Weniger for his useful review of this draft, and Thomas 1879 Clausen for his review and support on the continuity of this draft in 1880 another shape. 1882 The work of Carlos J. Bernardos and Maria Calderon has been partly 1883 supported by the Spanish Government under the POSEIDON (TSI2006- 1884 12507-C03-01) project. 1886 6. References 1888 6.1. Normative References 1890 [1] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 1891 Autoconfiguration for MANET: Terminology and Problem 1892 Statement", draft-ietf-autoconf-statement-04 (work in 1893 progress), February 2008. 1895 [2] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation 1896 Considerations for IP Autoconfiguration Mechanisms in MANETs", 1897 draft-bernardos-autoconf-evaluation-considerations-01 (work in 1898 progress), October 2007. 1900 [3] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 1901 Network Architecture", draft-ietf-autoconf-manetarch-07 (work 1902 in progress), November 2007. 1904 6.2. Informative References 1906 [4] Perkins, C., "IP Address Autoconfiguration for Ad Hoc 1907 Networks", draft-perkins-manet-autoconf-01 (work in progress), 1908 November 2001. 1910 [5] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large 1911 Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002. 1913 [6] Jeong, J., "Ad Hoc IP Address Autoconfiguration", 1914 draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress), 1915 January 2006. 1917 [7] Jeong, J., "Ad Hoc IP Address Autoconfiguration for AODV", 1918 draft-jeong-manet-aodv-addr-autoconf-01 (work in progress), 1919 July 2004. 1921 [8] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc 1922 Networks", MOBIHOC'02 , 2002. 1924 [9] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile 1925 Ad Hoc Network", MILCOM 2002 , 2002. 1927 [10] Tayal, A. and L. Patnaik, "An address assignment for the 1928 automatic configuration of mobile ad hoc networks", Personal 1929 Ubiquitous Computing , 2004. 1931 [11] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR", 1932 draft-mase-manet-autoconf-noaolsr-01 (work in progress), 1933 April 2006. 1935 [12] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad 1936 hoc Networks", IEEE Wireless Communications and Networking 1937 Conference (WCNC) , 2003. 1939 [13] Weniger, K., "PACMAN: Passive autoconfiguration for mobile ad 1940 hoc networks", IEEE Journal on Selected Areas in 1941 Communications, vol. 23, no. 3, Mar 2005 pp. 507-519 , 2005. 1943 [14] Mase, K. and K. Weniger, "PDAD-OLSR: Passive Duplicate Address 1944 Detection for OLSR", draft-weniger-autoconf-pdad-olsr-01 (work 1945 in progress), June 2006. 1947 [15] Baccelli, E., "OLSR Passive Duplicate Address Detection", 1948 draft-clausen-olsr-passive-dad-00 (work in progress), 1949 July 2005. 1951 [16] Jeong, H., "Passive Duplicate Address Detection for On-demand 1952 Routing Protocols", draft-jeong-autoconf-pdad-on-demand-01 1953 (work in progress), April 2007. 1955 [17] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for 1956 Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003. 1958 [18] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6 1959 addresses for MANET with multiple gateways (AMG)", 1960 draft-ruffino-manet-autoconf-multigw-03 (work in progress), 1961 June 2006. 1963 [19] Clausen, T. and E. Baccelli, "Simple MANET Address 1964 Autoconfiguration", draft-clausen-manet-address-autoconf-00 1965 (work in progress), February 2005. 1967 [20] Ruiz, P. and F. Ros, "Extensible MANET Auto-configuration 1968 Protocol (EMAP)", draft-ros-autoconf-emap-02 (work in 1969 progress), March 2006. 1971 [21] Wakikawa, R., "Global connectivity for IPv6 Mobile Ad Hoc 1972 Networks", draft-wakikawa-manet-globalv6-05 (work in progress), 1973 March 2006. 1975 [22] Jelger, C., "Gateway and address autoconfiguration for IPv6 1976 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02 1977 (work in progress), April 2004. 1979 [23] Suan, Y., Belding-Royer, E., and C. Perkins, "Internet 1980 Connectivity for Ad hoc Mobile Networks", International Journal 1981 of Wireless Information Networks special issue on 'Mobile Ad 1982 Hoc Networks (MANETs): Standards, Research, Applications' , 1983 2002. 1985 [24] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol 1986 Specification", draft-hofmann-autoconf-mran-00 (work in 1987 progress), March 2006. 1989 [25] Fazio, F., Palazzi, C., Das, S., and M. Gerla, "Automatic IP 1990 Address Configuration in VANETs", ACM VANET 2006 Workshop co- 1991 located with Mobicom 2006 , 2006. 1993 [26] Laouiti, A., "Address autoconfiguration in Optimized Link State 1994 Routing Protocol", draft-laouiti-manet-olsr-address-autoconf-01 1995 (work in progress), July 2005. 1997 [27] Cha, H., Park, J., and H. Kim, "Extended Support for Global 1998 Connectivity for IPv6 Mobile Ad Hoc Networks", 1999 draft-cha-manet-extended-support-globalv6-00 (work in 2000 progress), October 2003. 2002 [28] Templin, F., Russert, S., and S. Yi, "The MANET Virtual 2003 Ethernet (VET) Abstraction", draft-templin-autoconf-dhcp-14 2004 (work in progress), April 2008. 2006 [29] Templin, F., "MANET Autoconfiguration over Virtual Ethernets", 2007 draft-templin-autoconf-virtual-00 (work in progress), 2008 February 2007. 2010 [30] Templin, F., "MANET Autoconfiguration over Multilink Sites", 2011 draft-templin-autoconf-multilink-00 (work in progress), 2012 February 2007. 2014 [31] Draves, R. and D. Thaler, "Default Router Preferences and More- 2015 Specific Routes", RFC 4191, November 2005. 2017 [32] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 2018 Configuration Protocol (DHCP) version 6", RFC 3633, 2019 December 2003. 2021 Appendix A. Change Log 2023 Changes from -02 to -03: 2025 o New release to keep the document alive. 2027 o Update of some references. 2029 Changes from -01 to -02: 2031 o The classification criteria section has been removed, since it is 2032 now part of the evaluation considerations in [2]. Solutions are 2033 now analysed conforming to some of these evaluation considerations 2034 in [2]. 2036 o The Conclusions section has been removed. 2038 o The Terminology section has been removed. 2040 o The term "DAD" has been removed in the document (when possible), 2041 using Non-unique Address Detection instead. 2043 o Many editorial changes. 2045 Changes from -00 to -01: 2047 o The structure of the I-D has modified, classifying the analysed 2048 solutions according to a number of useful criteria, conforming to 2049 the AUTOCONF problem statement draft and the MANET architecture 2050 draft. 2052 o More solutions have been added to the I-D. 2054 o Adding of a security consideration section. 2056 Authors' Addresses 2058 Carlos J. Bernardos 2059 Universidad Carlos III de Madrid 2060 Av. Universidad, 30 2061 Leganes, Madrid 28911 2062 Spain 2064 Phone: +34 91624 6236 2065 Email: cjbc@it.uc3m.es 2067 Maria Calderon 2068 Universidad Carlos III de Madrid 2069 Av. Universidad, 30 2070 Leganes, Madrid 28911 2071 Spain 2073 Phone: +34 91624 8780 2074 Email: maria@it.uc3m.es 2076 Hassnaa Moustafa 2077 France Telecom 2078 38-40 rue du General Leclerc 2079 Issy Les Moulineaux 92794 Cedex 9 2080 France 2082 Phone: +33 145296389 2083 Email: hassnaa.moustafa@orange-ftgroup.com 2085 Full Copyright Statement 2087 Copyright (C) The IETF Trust (2008). 2089 This document is subject to the rights, licenses and restrictions 2090 contained in BCP 78, and except as set forth therein, the authors 2091 retain all their rights. 2093 This document and the information contained herein are provided on an 2094 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2095 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2096 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2097 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2098 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2099 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2101 Intellectual Property 2103 The IETF takes no position regarding the validity or scope of any 2104 Intellectual Property Rights or other rights that might be claimed to 2105 pertain to the implementation or use of the technology described in 2106 this document or the extent to which any license under such rights 2107 might or might not be available; nor does it represent that it has 2108 made any independent effort to identify any such rights. Information 2109 on the procedures with respect to rights in RFC documents can be 2110 found in BCP 78 and BCP 79. 2112 Copies of IPR disclosures made to the IETF Secretariat and any 2113 assurances of licenses to be made available, or the result of an 2114 attempt made to obtain a general license or permission for the use of 2115 such proprietary rights by implementers or users of this 2116 specification can be obtained from the IETF on-line IPR repository at 2117 http://www.ietf.org/ipr. 2119 The IETF invites any interested party to bring to its attention any 2120 copyrights, patents or patent applications, or other proprietary 2121 rights that may cover technology that may be required to implement 2122 this standard. Please address the information to the IETF at 2123 ietf-ipr@ietf.org.