idnits 2.17.1 draft-bernardos-manet-autoconf-survey-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 960. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 846 has weird spacing: '...ultiple gatew...' -- 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 (July 11, 2005) is 6863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 227, but not defined == Missing Reference: '2047' is mentioned on line 227, but not defined == Unused Reference: '10' is defined on line 863, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 867, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 872, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 876, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 915, but no explicit reference was found in the text -- No information found for draft-ietf-manet-autoconf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-jeong-adhoc-ip-addr-autoconf-04 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-03) exists of draft-ruffino-manet-autoconf-multigw-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-laouiti-manet-olsr-address-autoconf-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-01) exists of draft-ruffino-conn-scenarios-00 -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-02) exists of draft-wakikawa-manet-ipv6-support-00 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 autoconf C. Bernardos 3 Internet-Draft M. Calderon 4 Expires: January 12, 2006 UC3M 5 July 11, 2005 7 Survey of IP address autoconfiguration mechanisms for MANETs 8 draft-bernardos-manet-autoconf-survey-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This Internet Draft aims at describing some of the already proposed 42 mechanisms for the autoconfiguration of IP addresses in MANET 43 networks, trying to provide a useful reference in the standardisation 44 process. Solutions proposed in research papers and submitted as I-Ds 45 are presented and classified by a simple criteria. The analysis of 46 the solutions includes a brief description of the mechanism and also 47 a summary of the key characteristics. 49 Table of Contents 51 1. Introduction and problem statement . . . . . . . . . . . . . . 4 52 2. IP address auto-configuration protocols . . . . . . . . . . . 6 53 2.1 Conflict-detection allocation mechanisms . . . . . . . . . 6 54 2.1.1 IP address Autoconfiguration for Ad Hoc Networks 55 (Perkins et al.) . . . . . . . . . . . . . . . . . . . 7 56 2.1.2 IPv6 Autoconfiguration in Large Scale Mobile 57 Ad-Hoc Networks (Weniger et al.) . . . . . . . . . . . 8 58 2.1.3 Weak Duplicate Address Detection in Mobile Ad Hoc 59 Networks (Vaidya) . . . . . . . . . . . . . . . . . . 9 60 2.1.4 Global connectivity for IPv6 Mobile Ad Hoc 61 Networks (Wakikawa et al.) . . . . . . . . . . . . . . 10 62 2.1.5 Ad Hoc IP Address Autoconfiguration (Jeong et al.) . . 10 63 2.1.6 Automatic configuration of IPv6 addresses for 64 nodes in a MANET with multiple gateways (Ruffino 65 et al.) . . . . . . . . . . . . . . . . . . . . . . . 11 66 2.1.7 Address autoconfiguration in Optimized Link State 67 Routing Protocol (Adjih et al.) . . . . . . . . . . . 12 68 2.1.8 MANETconf: Configuration of Hosts in a Mobile Ad 69 Hoc Network (Nesargi et al.) . . . . . . . . . . . . . 12 70 2.1.9 Extended Support for Global Connectivity for IPv6 71 Mobile Ad Hoc Networks (Cha et al.) . . . . . . . . . 13 72 2.2 Conflict-free allocation mechanisms . . . . . . . . . . . 14 73 2.2.1 Prophet Address Allocation for Large Scale MANETs 74 (Zhou et al.) . . . . . . . . . . . . . . . . . . . . 15 75 2.2.2 Self-Configuring Networks. DRCP and DAAP (McAuley 76 et al.) . . . . . . . . . . . . . . . . . . . . . . . 15 77 2.2.2.1 DRCP . . . . . . . . . . . . . . . . . . . . . . . 16 78 2.2.2.2 DAAP . . . . . . . . . . . . . . . . . . . . . . . 16 79 2.2.3 Autoconfiguration, Registration, and Mobility 80 Management for Pervasive Computing. DDCP (Misra et 81 al.) . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 2.2.4 IP Address Assignment in a Mobile Ad Hoc Network 83 (Mohsin et al.) . . . . . . . . . . . . . . . . . . . 17 84 2.2.5 An address assignment for the automatic 85 configuration of mobile ad hoc networks (Tayal et 86 al.) . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 2.2.6 Simple MANET Address Autoconfiguration (Clausen et 88 al.) . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 2.2.7 Gateway and address autoconfiguration for IPv6 90 adhoc networks (Jelger et al.) . . . . . . . . . . . . 19 91 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 5.1 Normative References . . . . . . . . . . . . . . . . . . . 22 95 5.2 Informative References . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 97 Intellectual Property and Copyright Statements . . . . . . . . 25 99 1. Introduction and problem statement 101 A group of mobile wireless nodes capable of spontaneously forming a 102 network and support multi-hop communications constitutes a Mobile Ad 103 Hoc Network (MANET). This kind of multi-hop network presents some 104 interesting advantages, such as not requiring any infrastructure to 105 work, e.g., allowing the extension of coverage areas or providing 106 connectivity to nodes that not have the suitable access technologies. 107 Several manet routing protocol specifications have been developed by 108 the IETF MANET WG. In order to enable these networks to support IP 109 services, address configuration of the nodes is a requirement. 110 However, currently there is no standard specification that can be 111 used by manet nodes to autoconfigure their IP addresses. 113 Existing solutions for IP infrastructure-based networks (e.g., RFCs 114 2461, 2462, 3315 etc.) cannot be directly used by nodes constituting 115 an ad hoc network. These protocols assume the availability of a 116 multicast capable link for signalling, but there is not such a link 117 in ad-hoc multi-hop networks. 119 The main goal of the AUTOCONF group is to develop solutions for IPv4 120 and IPv6 address auto-configuration (both manet-local and global 121 scoped). The group has identified three possible scenarios of MANET 122 where IP address auto-configuration is required: 124 o Stand-alone ad hoc network: ad hoc networks not connected to any 125 external network, such as conference networks, battlefield 126 networks, surveillance networks, etc. In this scenario, nodes may 127 be added or removed randomly. Besides, most likely no pre- 128 established nor reliable address or prefix allocation agency will 129 be present in the network. 131 o Ad hoc network at the edge of an infra-structure network: Stand- 132 alone network connected to the Internet via one or more Internet 133 gateways (i.e., nodes that have connectivity to both an 134 infrastructure access network and the ad hoc network, providing 135 connectivity to the nodes attached to the latter). These Internet 136 gateways may be used in the auto-configuration address mechanisms, 137 e.g., by providing prefix information to the MANET nodes. 139 o Hybrid networks: ad hoc network that may be stand-alone for most 140 of the time but temporarily connected to the infrastructure 141 network (e.g., a car network connected while parked and 142 disconnected otherwise). 144 Ad hoc networks present a particular characteristic that should be 145 taken into account when designing address auto-configuration 146 protocols: two or more ad hoc network may get merged (the problem of 147 having two or more nodes with the same IP address may arise) or 148 single ad hoc network may get partitioned into two or more separate 149 networks, at any moment of time. 151 This Internet Draft aims at describing some of the already proposed 152 mechanisms for the autoconfiguration of IP addresses in MANET 153 networks, trying to provide a useful reference in the standardisation 154 process. Solutions proposed in research papers and submitted as I-Ds 155 are presented and classified by a simple criteria. The analysis of 156 the solutions includes a brief description of the mechanism and also 157 a summary of the key characteristics. 159 2. IP address auto-configuration protocols 161 In this section we briefly describe some of the existing proposals 162 for IP address autoconfiguration, classifying them into two different 163 categories: conflict-detection and conflict-free allocation. Some of 164 the mechanisms included in this document are not complete 165 autoconfiguration protocols, but just pieces (e.g., Duplicate Address 166 Detection in the MANET) required in a more general autoconfiguration 167 protocol. We also include them for completeness. 169 2.1 Conflict-detection allocation mechanisms 171 ----------------------------- 172 | | 173 | Pool of | 174 | addresses | 175 | | 176 | | 177 | addrX | 178 | A | 179 -----+----------------------- ----- 180 | | | 181 (1) | Node x picks an ----->| z | 182 | address (addrX) / | | 183 V / ----- 184 ----- ----- / (2) is addrX OK? 185 | | (2) | |/ 186 Node x | x |----------------->| y |\ 187 (3) waits | | is addrX OK? | | \ (2) is addrX OK? 188 for an ----- ----- \ ----- 189 answer \ A \ | | 190 \ | ----->| t | 191 (2) is addrX OK? \ _/ | | 192 | __/ ----- 193 V __/ 194 ----- __/ 195 | | __/ (2) is addrX OK? 196 | w |_/ 197 | | 198 ----- 200 Figure 1: Conflict-detection allocation scheme 202 These methods are based on picking an IP address from a pool of 203 available addresses, configuring it as tentative address and asking 204 the rest of the nodes of the network, checking the address uniqueness 205 and requesting for approval from all the nodes of the network. In 206 case of conflict (e.g., the address has been already configured by 207 another node), the node should pick a new address and repeat the 208 procedure (sort-of "trial and error" method). An example of 209 conflict-detection allocation general mechanism is shown in Figure 1. 211 2.1.1 IP address Autoconfiguration for Ad Hoc Networks (Perkins et al.) 213 This ad hoc address autoconfiguration mechanism, proposed in [1] and 214 [14], basically consists in choosing an address randomly belonging to 215 a network prefix available to the MANET and performing a Duplicate 216 Address Detection procedure within the MANET (that we can called 217 MANET-DAD to avoid confusing it with the DAD performed in IPv6 218 single-hop networks). The mechanism is defined both for IPv4 ([14], 219 [1]) and IPv6 ([1]). 221 This mechanism works (for IPv4) as follows: when a node requires a 222 unique IP address, it first selects a random host ID from the range 223 [2048, (2^(32-n)-1)], where n is the number of significant bits in 224 the network prefix available for the MANET. The node then appends 225 that host ID to the prefix, thus forming the tentative IP address for 226 which it performs MANET-DAD. The node also selects a random host ID 227 in the range [0, 2047] and appends this value to the available 228 network prefix, forming an address that is used as a temporary source 229 IP address for the short period while the node performs MANET-DAD. 230 The MANET-DAD is performed by creating an Address Request (AREQ) 231 message, including its tentative IP address, which is broadcasted to 232 its neighbours (using the randomly selected source address). When a 233 node receives an AREQ message, it creates a reverse route entry for 234 the node indicated by the random originator IP address. If the 235 tentative address contained in the AREQ message does not match the 236 address of the receiving node, it rebroadcasts the message to its 237 neighbours. If the IP address of the receiving node matches the 238 tentative address contained in the AREQ message it sends an Address 239 Reply (AREP) message to the sender, indicating that the address is 240 already in use. The route created by the AREQ messages is used to 241 route the message back to the source node. 243 A requesting node sends an AREQ message, waits for the reception of 244 an AREP message during a timer and retries the process several times. 245 If no AREP is received, it assumes that the tentative address 246 included in the AREQ messages is not in use and takes it for its own. 247 If an AREP message is received, then it picks up a different host ID 248 and begins the MANET-DAD process again. 250 For IPv6, the mechanism is similar. The tentative address belongs to 251 a non-link-local prefix (a prefix obtained by other means or a 252 default MANET_PREFIX reserved for MANET autoconfiguration). The 253 source address belongs to a different non-overlapping prefix (or part 254 of the prefix, if the same prefix is used for both tentative and 255 source addresses). The protocol is basically the same, but using 256 different message formats. For IPv4, ICMP messages are used, whereas 257 in IPv6 modified Neighbour Solicitation and Advertisement messages 258 are used. 260 In [15] some limitations of this solution are presented. 262 Summary of some other characteristics: 264 o Suitable for IPv4 and IPv6. 266 o Not restricted to any particular ad hoc routing solution, but it 267 is best suited for reactive routing protocols such as AODV. 269 o It does not support partition/merging. 271 2.1.2 IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks 272 (Weniger et al.) 274 The solution described in [16] extends the Neighbour Discovery and 275 IPv6 Stateless Address Autoconfiguration mechanisms to work in multi- 276 hop wireless networks. To do so, some modifications are needed: 278 o The Neighbour Solicitation message is modified to allow it to be 279 broadcasted to a bounded area of radius r_s hops (instead of only 280 a single hop). In addition, a new option for Neighbour Discovery 281 is 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 (note: this is 288 not described in the paper, but this method could be also used to 289 configure global addresses) addresses, a hierarchy is established 290 by special nodes (called leader nodes) that configure a group of 291 nodes by issuing Router Advertisements (RA) within their scope, 292 containing the subnet ID (i.e., network prefix) and its link-local 293 address as source address. The subnet ID has to be unique for 294 each leader node, so MANET-DAD has to be performed between the 295 leader nodes within the entire Ad hoc network. An algorithm is 296 provided for the election of leader nodes. 298 It should be noted that because of the nature of the solution, it 299 would be possible to have multihomed nodes (if a node is within the 300 scope of more than one leader node). 302 Summary of some other characteristics: 304 o Intended to IPv6. 306 o Not restricted to any particular ad hoc routing solution, but it 307 may be advantageous if it follows an hierarchical structure. 308 Besides, it is also preferable that nodes move in logical groups. 310 o It supports partition/merging. 312 2.1.3 Weak Duplicate Address Detection in Mobile Ad Hoc Networks 313 (Vaidya) 315 The mechanism described in [17] is not by itself an IP address 316 autoconfiguration protocol, but a mechanism to ensure that packets 317 ``meant for'' one node are not routed to another node, even if the 318 two nodes have chosen the same address. 320 The authors follow an approach to solve the IP address 321 autoconfiguration problem in ad Hoc networks, that is pretty common. 322 The node just picks a tentative address randomly and performs a 323 MANET-DAD procedure to detect if that address is already in use. 324 Typically, these MANET-DAD mechanisms make use of timeouts and the 325 author of [17] says that message delays cannot be bounded in an ad 326 hoc network (or if possible, determining the delays is non-trivial). 327 Therefore, he proposes a 'weak' DAD, that prevents a packet to be 328 delivered to a ``wrong'' destination node (even if two nodes have the 329 same IP address). To do that, it is assumed that each node is pre- 330 assigned a unique ``key'' (MAC addresses can be used as keys if they 331 are guaranteed to be unique). Information about {IP address, key} 332 pairs is included in the routing protocols (they assume that it is 333 not possible to embed the key in the IP address), so address 334 duplication can be detected. The authors describe how to do that 335 with Link State Routing (proactive routing protocol) and Dynamic 336 Source Routing (reactive routing protocol). The weak DAD cannot be 337 used when flooding is used as the routing protocol. 339 Summary of some other characteristics: 341 o Intended to IPv4. It would be also possible to use this mechanism 342 in IPv6. 344 o Restricted to particular ad hoc routing solutions. It is 345 described how the mechanism works with LSR and DSR. 347 o It supports partition/merging. 349 2.1.4 Global connectivity for IPv6 Mobile Ad Hoc Networks (Wakikawa et 350 al.) 352 This mechanism [2] is similar to [3] from the point of view of how 353 IPv6 addresses are configured. Global prefix information is obtained 354 from Internet gateways. They propose two methods for the Internet 355 gateway discovery: one method periodically disseminates gateway 356 advertisements to all nodes in the MANET; the other method utilises 357 solicitation and advertisement signalling between a MANET node and 358 the gateway. Extended router solicitation and advertisements of the 359 Neighbour Discovery Protocol (NDP) or extended control message of 360 each MANET routing protocol can be used for this signalling. The 361 proposed methods target all MANET protocols regardless of whether 362 they are reactive and proactive. Internet gateways supply their own 363 global prefix information and IPv6 global address to MANET nodes 364 somehow, either proactively or reactively. In this way, the reactive 365 and proactive route discovery features of each MANET routing protocol 366 are not disturbed. 368 Once the MANET node has obtained the prefix information from the 369 Internet gateway, it uses the 64-bit interface ID in order to 370 construct a valid address with the acquired prefix. It is assumed 371 than before configuring a global IPv6 address, the node has 372 configured a link local address, and MANET-DAD has been performed for 373 that link-local address (using the mechanism defined in [1] and 374 [14]), so it is assumed that the global address would be also unique. 375 If not, the node may perform another MANET-DAD for this global 376 address. 378 Summary of some other characteristics: 380 o Intended to IPv6. 382 o Not restricted to any particular ad hoc routing solution. 384 2.1.5 Ad Hoc IP Address Autoconfiguration (Jeong et al.) 386 The IP address autoconfiguration mechanism described in [4] is 387 comprised of three steps: 389 1. Selection of a random address. 391 2. Verification of the address uniqueness. 393 3. Assignment of the address to the network interface. 395 The MANET-DAD procedure follows an hybrid approach, consisting of two 396 phases: 398 o Strong DAD: based on [1]. Strong DAD is done in the 399 initialisation in order to check if there is an address 400 duplication or not. [4] describes the message format for IPv4 and 401 IPv6, using ICMP messages (new types are defined). [5] describes 402 the message format for AODV. 404 o Weak DAD: based on [17]. During ad hoc routing, weak DAD is used 405 to find out whether address duplication, due to merging, has 406 occurred or not. The concept of ``Virtual IP address'', which is 407 the combination of ''IP address'' and ``Key'', is used. 409 Summary of some other characteristics: 411 o Suitable for IPv4 and IPv6. 413 o Not restricted to any particular ad hoc routing solution. 415 o It supports partition/merging. 417 2.1.6 Automatic configuration of IPv6 addresses for nodes in a MANET 418 with multiple gateways (Ruffino et al.) 420 This mechanism [6] describes a mechanism to enable nodes of a MANET 421 connected to the infrastructure - by means of one or more gateways - 422 to configure IP addresses. 424 Each of the gateways available at the MANET has a global IPv6 prefix 425 that is announced using a new OSLR message type, called Prefix 426 Advertisement (PA). The nodes of the MANET can configure addresses 427 belonging to each of the prefixes received (a generic MANET DAD 428 procedure, such as [1], has to performed in order to verify 429 uniqueness of MANET-local and global addresses). 431 The mechanism basically works as follows: at boostrap, a node 432 configures a Primary Address (PADD) that is MANET-scoped and is used 433 as main address in OLSR messages. The node then is able to start 434 participating to OLSR and receiving topology information. With the 435 prefix information received in the PA messages, the node is able to 436 build a set of global IPv6 addresses (called Secondary Addresses: 437 SADDs). Among them, the node chooses the "best" prefix and starts 438 using the address formed from this prefix (called, Designated 439 Secondary Address: DSADD). The node introduces all (or a subset) of 440 the SADDs (including the DSADD) in OLSR messages and starts 441 broadcasting them, enabling these addresses to be routable and 442 reachable within the MANET. 444 Summary of some other characteristics: 446 o Intended for IPv6. 448 o Restricted to OLSR. 450 o It supports partition/merging. 452 2.1.7 Address autoconfiguration in Optimized Link State Routing 453 Protocol (Adjih et al.) 455 This draft [7] describes a mechanism to perform MANET-DAD by 456 extending the OLSR routing protocol. Basically, the MANET-DAD 457 algorithm uses an special control packet called ``Multiple Address 458 Declaration'' (MAD), that includes the node address and a node 459 identifier (that must be globally unique). This packet is broadcast 460 in the network, so all the nodes receive this packet. If a node 461 receives a MAD message containing an address that matches its own 462 address and a node identifier that does not, this implies that the 463 address is duplicated. To spare the channel bandwidth, it is 464 proposed to send MAD packets using the MPR (Multi-Point Relay) 465 flooding. 467 Summary of some other characteristics: 469 o Intended to IPv6. 471 o The mechanism is specified as an extension to OLSR. 473 2.1.8 MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network 474 (Nesargi et al.) 476 Nesargi et al. propose in [15] a Distributed Dynamic Host 477 Configuration Protocol (DDHCP) designed to configure nodes in a 478 MANET. 480 It basically operates as follows: a node proposes a candidate IP 481 address for assignment to a newly arriving node. If the proposal is 482 accepted by all the nodes that are part of the MANET, the proposed 483 address is assigned to the newly arrived node. Otherwise, another 484 candidate IP address is chosen and the process is repeated. 486 When a node (called requester) joins the MANET it broadcasts a 487 request message to all its neighbours, waiting for a reply from a 488 node willing to act as the initiator for the assignment of an IP 489 address to the requester. If it is the first node of the MANET (no 490 replies are received) it configures itself an IP address and the 491 MANET its initialised. If the requester receives a reply message (or 492 more than one), it then selects one of the reachable nodes that 493 answered as the initiator, which will be the one that performs the 494 address allocation on its behalf. All other nodes know a route to 495 the initiator and can forward their responses to it. Ultimately, the 496 initiator conveys the result of the address allocation operations to 497 the requester. 499 The proposed protocol has some other interesting features, such as 500 releasing unused IP addresses, soft state maintenance, concurrent IP 501 address allocation and partition/merging support. 503 Summary of some other characteristics: 505 o Intended to IPv4. 507 o It assumes (for simplicity) that the IP address block from which 508 nodes are to be assigned their IP address is known in advance. 510 o Not restricted to any particular ad hoc routing solution. 512 o Intended for standalone MANETs. Nevertheless, it seems that it 513 could be used for connected MANETs. 515 2.1.9 Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc 516 Networks (Cha et al.) 518 [8] describes how to provide enhanced Internet connectivity to mobile 519 ad-hoc networks. The protocol is devised as an extension to AODV, 520 but the concept may be applicable to other proactive routing 521 protocols. 523 The protocol basically consists in nodes requesting global addresses 524 to a gateway (GW), which assigns a non-used address to the requesting 525 node. More details can be found in [8]. 527 Summary of some other characteristics: 529 o Intended to IPv6. 531 o Although the protocol is devised as an extension to AODV, it could 532 be applicable to any proactive routing protocol. 534 2.2 Conflict-free allocation mechanisms 536 These methods assume that the addresses that are delegated are not 537 being used by any node in the network. This can be achieved, for 538 example, by ensuring that the nodes that participate in the 539 delegation have disjoint address pools. In this way, there is no 540 need of performing MANET-DAD. An example of a conflict-free 541 allocation general mechanism is shown in Figure 2. 543 ------------------------------ 544 | | 545 | Pool of | 546 | addresses | 547 | | 548 -----+------------------------ 549 | 550 (1) | Node x (first node) picks the 551 | pool and configures its interfaces 552 | 553 -+--- ----- 554 | | (3) Node y requests | | (2) Node y joins 555 | x |<--------------------| y | the network 556 | | some addresses | | 557 -+--- ---+- 558 | \ ^ | 559 | \___________________/ | 560 | | 561 | (4) Node x gives half | 562 | its pool of | 563 | addresses | 564 | | 565 -------+------- ------------+-- 566 | | | | 567 | Pool of | | Pool of | 568 | Node x | | Node y | 569 | | | | 570 --------------- --------------- 572 (5) Both Node x and Node y ? 573 can give addresses to --+-- 574 new arriving nodes that | | 575 request IP addresses | z | 576 | | 577 ----- 579 Figure 2: Conflict-free allocation scheme 581 2.2.1 Prophet Address Allocation for Large Scale MANETs (Zhou et al.) 583 The mechanism defined in [18] is based on using an stateful function 584 f(n) (where the initial state of f(n) is the seed) that produces as 585 output an integer sequence of numbers. Different seeds lead to 586 different sequences, and the state of f(n) is updated. This function 587 can be used to derive IP addresses if it satisfies certain 588 properties: 590 o The interval between two occurrences of the same number in a 591 sequence is extremely long. 593 o The probability of more than one occurrence of the same number in 594 a limited number of different sequences initiated by different 595 seeds during some interval is extremely low. 597 This properties may be satisfied if the space of available addresses 598 is large, so it is easier to achieve in IPv6 than in IPv4. 600 The mechanism basically work as follows: the first node chooses a 601 random number as its IP address and uses a random or default state 602 value as the seed for its f(n). When a different node approaches, 603 the first node uses its f(n) to obtain a different number and state. 604 This number is used by the second node as its IP address, and the 605 state is used as the seed for its f(n). After that both nodes are 606 able to assign IP addresses to other nodes. 608 Summary of some other characteristics: 610 o Suitable for IPv4 and IPv6. 612 o Not restricted to any particular ad hoc routing solution. 614 o It supports partition/merging. 616 2.2.2 Self-Configuring Networks. DRCP and DAAP (McAuley et al.) 618 In [19] the Dynamic Registration and Configuration Protocol (DRCP) 619 and Dynamic Address Allocation Protocol (DAAP) are described. These 620 two protocols together may provide autoconfiguration to entire 621 networks. The authors state that their proposal is concerned with 622 registration and autoconfiguration in 'quasi-dynamic networks'. They 623 define quasi-dynamic networks as those that require rapid deployment, 624 but are relatively stable except for some incremental deployment and 625 losses. 627 Their goal is to allow all hosts and routers in the quasi-dynamic 628 domain to be plug and play, being the only restriction on the number 629 of nodes the size of the address space (paper focused in IPv4, but 630 solution would be also applicable to IPv6). 632 2.2.2.1 DRCP 634 The Dynamic Registration and Configuration Protocol (DRCP) is heavily 635 based on DHCP, but aims at being faster and more suited to the quasi- 636 dynamic network scenario (e.g., by using efficiently the scarce 637 wireless bandwidth). 639 DRCP adds some new messages to DHCP. It uses a client-server model. 640 The server sends periodic ADVERTISEMENT messages. The client 641 transmits DISCOVER (or REQUEST) messages - requesting an IP address - 642 until it gets an OFFER message - that carries a configuration message 643 - (or ACK). The server keeps retransmitting the OFFER (or ACK) 644 message until it gets an ACCEPT or DECLINE message. 646 2.2.2.2 DAAP 648 The Dynamic Address Allocation Protocol (DAAP) is a new protocol that 649 basically distributes address-pools among nodes in a domain. This 650 allows any node to act as a new DRCP server, using a part of the 651 addresses of the pool for allocation to new arriving nodes. The 652 protocol is very simple and defines only two messages: one to request 653 an address pool (POOL_REQUEST) and one to convey the response 654 (POOL_RESPONSE). 656 The combination of DRCP and DAAP allows a rapid configuration of IP 657 addresses in a network. Basically the first node has configured, by 658 some other means (e.g., statically), an address pool. It then 659 configures its interfaces using DRCP. After that, it starts sending 660 DRCP ADVERTISEMENT messages. When a new node arrives, and discover 661 the server, it configures an IP address in the interface that 662 connects to that server, using DRCP. Then, it requests an address 663 pool using DAAP. The initial node sends to the new node half of its 664 address pool. The new node configures then the rest of its 665 interfaces using DRCP and may start acting as a new DRCP server on 666 the network. 668 Summary of some other characteristics: 670 o Intended to IPv4, but it could be applicable to IPv6. 672 o Aimed for quasi-dynamic networks, so it is not a general MANET IP 673 address autoconfiguration solution. 675 o Not restricted to any particular ad hoc routing solution, as it is 676 not even restricted to ad hoc. 678 2.2.3 Autoconfiguration, Registration, and Mobility Management for 679 Pervasive Computing. DDCP (Misra et al.) 681 The Dynamic Configuration Distribution Protocol (DDCP) proposed in 682 [20] is quite similar to the DAAP proposal [19]. Actually DDCP just 683 automates the distribution of address pools to other nodes, that can 684 then run any link configuration protocol (LCP), like DHCP or DRCP to 685 configure addresses of incoming nodes. The main difference with DAAP 686 is that DDCP provides also autoconfiguration of additional IP-related 687 parameters and capabilities, such as the location of DNS and SIP 688 servers. Another difference is that DDCP explicitly states that 689 nodes, when requested, split their address pools into two parts, 690 forwarding the second part to the requester node (in DAAP, there is 691 not such detail about how the address pool has to be split, although 692 in the examples, the pool is halved in two as well). 694 Summary of some other characteristics: 696 o Intended to IPv4. 698 o Not restricted to any particular ad hoc routing solution, as it is 699 not even restricted to ad hoc. 701 2.2.4 IP Address Assignment in a Mobile Ad Hoc Network (Mohsin et al.) 703 The solution described in [21] is based on the concept of binary 704 split, but address also the issue of partitioning, merging and abrupt 705 departure of nodes from the MANET. This is done by associating a 706 Partition ID, which should be universally unique, to every partition. 707 If a MANET gets partitioned into two, as long as they do not run out 708 of IP addresses, they do not generate new Partition IDs, so if they 709 merge later there is no duplicated address. If one of the portions 710 runs out of addresses, it generates a new Partition ID and acquires 711 the IP address block that belongs to the other portion. If this 712 portions merge later (the case of two MANETs that had not been 713 previously part of the same MANET is analogous), one of the portions 714 has to give up its IP address block. In this mechanism, the one with 715 the larger address block is the one that gives up it addresses and 716 has to acquire a new one. 718 Summary of some other characteristics: 720 o Suitable for IPv4 and IPv6. 722 o Not restricted to any particular ad hoc routing solution. 724 o It supports partition/merging. 726 2.2.5 An address assignment for the automatic configuration of mobile 727 ad hoc networks (Tayal et al.) 729 The solution described in [22] is very similar to the previous one 730 ([21]), sharing the idea (also used by others) of having nodes 731 assigning half of their address pools to newly arrived nodes that 732 request IP addresses. 734 Summary of some other characteristics: 736 o Suitable for IPv4 and IPv6. 738 o Not restricted to any particular ad-hoc routing solution. 740 o It supports partition/merging. 742 2.2.6 Simple MANET Address Autoconfiguration (Clausen et al.) 744 This draft [9] defines a simple autoconfiguration mechanism, based on 745 partitioning a local scoped address space among the nodes of the 746 MANET. This address space is used for assigning ``temporary 747 addresses'' (also called ``local''). The nodes periodically signals 748 their address space in ADDR_BEACON messages, in order to detect and 749 solve conflicts. 751 When a new arriving node wants to configure a global IPv6 address, it 752 first has to acquire a temporary address. To do this, it first 753 listens to ADDR_BEACON messages sent by those nodes that may act as 754 'configuring nodes'. The new node selects a node as its configuring 755 node and sends to it an ADDR_CONFIG message in order to request a 756 local address. The configuring node, upon the reception of this 757 request, assigns a local address to the new node and signals this 758 assignment trough another ADDR_CONFIG message (additionally, this 759 address is marked as ``used'' in the ADDR_BEACON messages it sends 760 afterwards). Once the new node has configured a local address it can 761 start participating in the routing protocol and it can start 762 acquiring a global IP address. The configuring node is in charge of 763 acting on behalf of the new node, and different mechanisms may be 764 used, as acting as a proxy DHCP server and transmitting a request to 765 an existing DHCP server or consulting the topology table (in case of 766 proactive routing protocols as OLSR) and picking an non-used address. 768 Summary of some other characteristics: 770 o Intended to IPv6. 772 o The mechanism is specified as an extension to OLSR, but nothing 773 prevents the mechanism to work with other routing protocols. 775 2.2.7 Gateway and address autoconfiguration for IPv6 adhoc networks 776 (Jelger et al.) 778 This solution [3], combines the problem of IP address configuration 779 and gateway discovery (needed to obtain global connectivity). 781 Basically, each gateway (it could be more than one in the same MANET) 782 sends periodically GW_INFO messages to its one-hop neighbours. This 783 information includes its IPv6 global address and prefix length. If a 784 receiving node decides to use this information, it has to forward 785 this message (updating some fields) to its neighbours (this leads to 786 the so-called 'prefix continuity': any node A that selected a given 787 prefix P has at least one neighbour on its path to the selected 788 gateway G). The prefix information obtained from these GW_INFO 789 messages is used in the creation of the global IPv6 address of the 790 node, by adding the EUI64 of the interface from which the GW_INFO 791 message has been received (padding with zeros if needed). [3] states 792 that the MANET-DAD procedure must not be performed. 794 Summary of some other characteristics: 796 o Intended to IPv6. 798 o Not restricted to any particular ad hoc routing solution. 800 3. Conclusions 802 This draft has presented some of the solutions for the problem of the 803 autoconfiguration of IP addresses in Mobile Ad Hoc Networks that have 804 been proposed so far. This document tries to provide a reference 805 that could help in the discussions of the AUTOCONF group, just 806 presenting the already available mechanisms that tackle the 807 autoconfiguration problem. 809 A detailed analysis of the characteristics (i.e., complexity, 810 communication overhead, latency, scalability, network requirements, 811 etc.) of each proposal, as well as a more extensive problem 812 statement, are not included yet. 814 4. Security Considerations 816 This documents does not raise any security issue. The possible 817 security considerations of the described proposals have not been 818 addressed in this I-D. 820 5. References 822 5.1 Normative References 824 [1] Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and 825 Y. Suan, "IP Address Autoconfiguration for Ad Hoc Networks", 826 draft-ietf-manet-autoconf-01.txt (work in progress), 827 November 2001. 829 [2] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc 830 Networks", draft-wakikawa-manet-globalv6-03 (work in progress), 831 October 2003. 833 [3] Jelger, C., "Gateway and address autoconfiguration for IPv6 834 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02 835 (work in progress), April 2004. 837 [4] Jeong, J., "Ad Hoc IP Address Autoconfiguration", 838 draft-jeong-adhoc-ip-addr-autoconf-04 (work in progress), 839 February 2005. 841 [5] Jeong, J., "Ad Hoc IP Address Autoconfiguration for AODV", 842 draft-jeong-manet-aodv-addr-autoconf-01 (work in progress), 843 July 2004. 845 [6] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6 846 addresses for nodes in a MANET with multiple gateways", 847 draft-ruffino-manet-autoconf-multigw-00 (work in progress), 848 June 2005. 850 [7] Laouiti, A., "Address autoconfiguration in Optimized Link State 851 Routing Protocol", draft-laouiti-manet-olsr-address-autoconf-00 852 (work in progress), February 2005. 854 [8] Cha, H., Park, J., and H. Kim, "Extended Support for Global 855 Connectivity for IPv6 Mobile Ad Hoc Networks", 856 draft-cha-manet-extended-support-globalv6-00 (work in 857 progress), October 2003. 859 [9] Clausen, T. and E. Baccelli, "Simple MANET Address 860 Autoconfiguration", draft-clausen-manet-address-autoconf-00 861 (work in progress), February 2005. 863 [10] Jeong, J., "Requirements for Ad Hoc IP Address 864 Autoconfiguration", draft-jeong-manet-addr-autoconf-reqts-04 865 (work in progress), February 2005. 867 [11] Ruffino, S., Stupar, P., and T. Clausen, "Autoconfiguration in 868 a MANET: connectivity scenarios and technical issues", 869 draft-ruffino-manet-autoconf-scenarios-00 (work in progress), 870 October 2004. 872 [12] Ruffino, S., "Connectivity Scenarios for MANET", 873 draft-ruffino-conn-scenarios-00 (work in progress), 874 February 2005. 876 [13] Wakikawa, R., "IPv6 Support on Mobile Ad-hoc Network", 877 draft-wakikawa-manet-ipv6-support-00 (work in progress), 878 February 2005. 880 5.2 Informative References 882 [14] Suan, Y., Belding-Royer, E., and C. Perkins, "Internet 883 Connectivity for Ad hoc Mobile Networks", International Journal 884 of Wireless Information Networks special issue on 'Mobile Ad 885 Hoc Networks (MANETs): Standards, Research, Applications' , 886 2002. 888 [15] Nesargi, S. and R. Prakash, "MANETconf: Configuration of Hosts 889 in a Mobile Ad Hoc Network", IEEE INFOCOM 2002 , 2002. 891 [16] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large 892 Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002. 894 [17] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc 895 Networks", MOBIHOC'02 , 2002. 897 [18] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for 898 Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003. 900 [19] McAuley, A. and K. Manousakis, "Self-Configuring Networks", 901 21st Century Military Communications Conference Proceedings , 902 2000. 904 [20] Misra, A., Das, S., McAuley, A., and S. Das, 905 "Autoconfiguration, Registration, and Mobility Management for 906 Pervasive Computing", IEEE Personal Communications , 2001. 908 [21] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile 909 Ad Hoc Network", MILCOM 2002 , 2002. 911 [22] Tayal, A. and L. Patnaik, "An address assignment for the 912 automatic configuration of mobile ad hoc networks", Personal 913 Ubiquitous Computing , 2004. 915 [23] Zhou, Z. and A. Seneviratne, "A Survey of Zero and Auto 916 Configurations for Wireless Networks", ATNAC 2003 , 2003. 918 Authors' Addresses 920 Carlos J. Bernardos 921 Universidad Carlos III de Madrid 922 Av. Universidad, 30 923 Leganes, Madrid 28911 924 Spain 926 Phone: +34 91624 8859 927 Email: cjbc@it.uc3m.es 929 Maria Calderon 930 Universidad Carlos III de Madrid 931 Av. Universidad, 30 932 Leganes, Madrid 28911 933 Spain 935 Phone: +34 91624 8780 936 Email: maria@it.uc3m.es 938 Intellectual Property Statement 940 The IETF takes no position regarding the validity or scope of any 941 Intellectual Property Rights or other rights that might be claimed to 942 pertain to the implementation or use of the technology described in 943 this document or the extent to which any license under such rights 944 might or might not be available; nor does it represent that it has 945 made any independent effort to identify any such rights. Information 946 on the procedures with respect to rights in RFC documents can be 947 found in BCP 78 and BCP 79. 949 Copies of IPR disclosures made to the IETF Secretariat and any 950 assurances of licenses to be made available, or the result of an 951 attempt made to obtain a general license or permission for the use of 952 such proprietary rights by implementers or users of this 953 specification can be obtained from the IETF on-line IPR repository at 954 http://www.ietf.org/ipr. 956 The IETF invites any interested party to bring to its attention any 957 copyrights, patents or patent applications, or other proprietary 958 rights that may cover technology that may be required to implement 959 this standard. Please address the information to the IETF at 960 ietf-ipr@ietf.org. 962 Disclaimer of Validity 964 This document and the information contained herein are provided on an 965 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 966 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 967 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 968 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 969 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 970 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 972 Copyright Statement 974 Copyright (C) The Internet Society (2005). This document is subject 975 to the rights, licenses and restrictions contained in BCP 78, and 976 except as set forth therein, the authors retain all their rights. 978 Acknowledgment 980 Funding for the RFC Editor function is currently provided by the 981 Internet Society.