idnits 2.17.00 (12 Aug 2021) /tmp/idnits48186/draft-bernardos-autoconf-solution-space-02.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 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 990. 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 (November 2, 2008) is 4941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-bernardos-manet-autoconf-survey-04 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '16') (Obsoleted by RFC 8415) == Outdated reference: draft-templin-autoconf-dhcp has been published as RFC 5558 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: May 6, 2009 H. Moustafa 6 France Telecom 7 November 2, 2008 9 Ad-Hoc IP Autoconfiguration Solution Space Analysis 10 draft-bernardos-autoconf-solution-space-02 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 May 6, 2009. 37 Abstract 39 This draft aims at analysing the solution space for the ad hoc IP 40 autoconfiguration problem, based on the problem statement draft and 41 the MANET architecture draft. Some evaluation considerations, are 42 also taken into account. This draft classifies, at a generic level, 43 the solution space of the possible approaches that could be followed 44 to solve the IPv6 autoconfiguration for MANETs problem. The various 45 approaches of IPv6 autoconfiguration for MANETs are illustrated, and 46 the benefits and tradeoffs in different aspects of IPv6 47 autoconfiguration are explored. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Issues of IP autoconfiguration in MANETs . . . . . . . . . . . 4 54 3.1. Additional signalling overhead . . . . . . . . . . . . . . 4 55 3.2. Increased protocol complexity and processing load . . . . 5 56 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.4. Security considerations . . . . . . . . . . . . . . . . . 5 58 3.5. Convergence time . . . . . . . . . . . . . . . . . . . . . 5 59 3.6. Routing protocol dependency . . . . . . . . . . . . . . . 6 60 3.7. IP address space assignment efficiency . . . . . . . . . . 7 61 4. IP autoconfiguration solution space analysis . . . . . . . . . 7 62 4.1. Which entities are involved? . . . . . . . . . . . . . . . 8 63 4.1.1. MANET Routers (distributed approach) . . . . . . . . . 8 64 4.1.2. MANET Routers and Border Routers . . . . . . . . . . . 9 65 4.1.3. MANET Routers and distributed servers . . . . . . . . 9 66 4.1.4. MANET Routers and centralised server(s) 67 (centralised approach) . . . . . . . . . . . . . . . . 10 68 4.2. What type of IP delegation: addresses or prefixes? . . . . 10 69 4.3. How are IP addresses obtained? . . . . . . . . . . . . . . 11 70 4.4. How is IP address uniqueness guaranteed? . . . . . . . . . 12 71 4.4.1. How is address uniqueness detection performed? . . . . 12 72 4.4.2. When address uniqueness detection is performed: 73 pre-service and/or in-service? . . . . . . . . . . . . 14 74 4.4.3. How are address conflicts resolved? . . . . . . . . . 15 75 4.5. How is signalling performed? . . . . . . . . . . . . . . . 15 76 4.6. Are existing protocols modified? . . . . . . . . . . . . . 16 77 4.7. What are the security considerations? . . . . . . . . . . 17 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 86 Intellectual Property and Copyright Statements . . . . . . . . . . 22 88 1. Introduction 90 Due to the spontaneous nature of mobile ad hoc networks, there is a 91 need to automatically provide IP configuration for MANET Routers, 92 allowing them to establish communications. Each MANET Router needs a 93 local address that can be used for intra-MANET connectivity, and an 94 external address allowing for Internet connectivity. An IP 95 autoconfiguration solution should be able to satisfy the self- 96 deployment requirements of ad hoc networks and should be flexible to 97 accommodate special features for different ad hoc environments. 98 However, the dynamic and random characteristics of MANETs, the type 99 of scenario, and the type of application make it difficult to have 100 one single standard IP autoconfiguration solution. 102 Based on the MANET architectural concepts presented in [1], the 103 autoconf problem statement draft [2] describes the issues that should 104 be addressed during the development of IP autoconfiguration 105 solutions. Some evaluation considerations for IP autoconfiguration 106 solutions are also presented in [3] highlighting some important 107 behaviours for the different autoconfiguration solutions to help 108 solution developers during design and to help implementers during the 109 choice of autoconfiguration mechanisms. A number of proposed 110 solutions has been made; however, there is no existing classification 111 or standard for these different proposed solutions. The present 112 draft aims at providing an analysis of the solutions space for the 113 current IP autoconfiguration proposed solutions. The draft discusses 114 the different approaches that an IP autoconfiguration solution could 115 take, giving a generic level classification for the solution space. 116 Also, the main key features, benefits and scope for the different IP 117 autoconfiguration approaches are illustrated. 119 2. Scenarios 121 The ad-hoc term is highly overloaded nowadays and it usually 122 comprises many different network architectures, with disparate 123 characteristics and requirements. As an example, today we can find 124 several instances of ad-hoc networks: Mobile Ad-hoc Networks 125 (MANETs), sensor networks, Vehicular Ad-hoc Networks (VANETs), 126 Wireless Mesh Networks (WMNs), etc. All of them share their multi- 127 hop, unmanaged and decentralised nature, but also present very 128 important differences. 130 As described in [3], there are many evaluation considerations and 131 characteristics that a particular IP autoconfiguration mechanism 132 might present. The requirements that an IP autoconfiguration 133 solution should meet will greatly depend on the application scenarios 134 that are considered. Some representative examples of scenario's 135 characteristics that may have an impact on the adopted IP 136 autoconfiguration solution include, but are not limited to, the 137 following: 138 o Connected vs Standalone MANET. The technical requirements that a 139 connected MANET scenario imposes on the solution (such as 140 delegation of global IPv6 addresses/prefixes, MANET Border Router 141 -- also known as Internet Gateway -- discovery, etc.) differ from 142 the ones posed by a standalone MANET scenario (only local IPv6 143 addressing is required). It should also be noticed that a 144 transition can take place in the connected scenarios, where they 145 may become standalone scenarios from time to time. 146 o Node mobility. The mobility of MANET Routers has also a big 147 impact on the requirements of an IP autoconfiguration solution. 148 For example, in high dynamic environments, solutions should 149 present low convergence time values and should not require a high 150 signalling load in order to deal with MANET topology changes 151 (e.g., a node joining/leaving the network, partitioning and 152 merging), since this would limit the applicability or at least the 153 overall performance of the network. 154 o Power consumption. An IP autoconfiguration solution for network 155 deployments composed of battery-limited devices should pay special 156 attention to energy-related issues, such as signalling and 157 processing load. 158 o Network size. Solutions that aimed at supporting the IP 159 autoconfiguration of large MANETs in terms of number of 160 participant nodes, should carefully look at issues related to 161 convergence time, signalling load and scalability. 163 3. Issues of IP autoconfiguration in MANETs 165 Although IP autoconfiguration is a necessary step to enable ad-hoc 166 networks to benefit from IP and Internet connectivity, there are some 167 tradeoffs -- posed by the different possible approaches that can be 168 used -- that are worth looking at. This section explores some 169 general issues that may impact -- e.g., in terms of applicability or 170 performance -- an IP autoconfiguration mechanism. 172 3.1. Additional signalling overhead 174 The nodes involved in performing IP autoconfiguration could require 175 to exchange additional signalling messages in order to achieve its 176 goal. The required amount of signalling depends on the particular 177 solution, but it could range from no overhead at all (e.g., passive 178 autoconfiguration), local message exchange/piggybacking, to 179 additional message flooding (that could be limited in scope and/or 180 optimised). The amount of signalling is likely to increase with the 181 number of ad-hoc nodes participating in the autoconfiguration 182 process. Special care should be taken in order to avoid these 183 overhead scale to unacceptable heights, specially to resource-limited 184 devices with low power and/or processing capacity. 186 3.2. Increased protocol complexity and processing load 188 Due to the multi-hop, unmanaged and decentralised nature that usually 189 characterise ad-hoc networks, it is expected that IP 190 autoconfiguration in MANETs will be more complicated than in 191 infrastructure-based networks using standard IPv6 autoconfiguration 192 protocols (e.g., RFCs 4861 [4], RFC 4862 [5]). Therefore, nodes 193 participating in an IP autoconfiguration mechanism would be more 194 complex than current legacy IPv6 hosts. In addition to this 195 additional complexity, MANET Routers will likely have to bear an 196 increased processing load. Again, this increased protocol complexity 197 and processing load may be overwhelming for certain types of MANET 198 Routers (e.g., limited devices in terms of power and processing 199 capacity). 201 3.3. Scalability 203 IP autoconfiguration solutions will likely make use of additional 204 signalling and/or require to keep track of the IP prefixes/address 205 that are currently being used within the MANET. This may lead to 206 scalability issues, especially in the case of centralised solutions, 207 in which a single node (or a reduced set) play a special role in the 208 IP autoconfiguration process. 210 3.4. Security considerations 212 Depending on the particular scenario, it might be possible that MANET 213 Routers do not belong to the same administrative domain, and 214 therefore it is not possible to assume the existence of security 215 associations between participants. For this reason, the security 216 protection of IP autoconfiguration mechanisms could be harder than 217 that of standard IPv6 autoconfiguration mechanisms (based for example 218 on SeND [6]) or it could be accepted that a "weaker" protection is 219 provided in these environments. 221 3.5. Convergence time 223 The convergence time of a MANET Router is the time required to have a 224 unique IPv6 address since it joins the MANET or a address conflict is 225 detected (e.g., a duplicated), while the convergence time of the 226 whole MANET is the time required to have all its nodes configured 227 with the correct addresses. The convergence time of an IP 228 autoconfiguration mechanism depends on the MANET scenario and the 229 application type, and hence can greatly impact the mechanism's 230 efficiency. Long convergence times may be expected when there is a 231 sudden large scale change in the structure of the network. On the 232 other hand, as the density of the network increases and the mobility 233 decreases, the convergence time may become shorter. 235 The convergence time can also differ according to the type of the IP 236 autoconfiguration mechanism. For example, in IP autoconfiguration 237 mechanisms based on signalling flooding or employing periodic 238 procedures, the convergence time can highly impact the mechanisms' 239 scalability, especially for high mobility scenarios. In IP 240 autoconfiguration mechanisms, in which MANET Routers request IP 241 addresses firstly for joining the MANET and then whenever needed, the 242 convergence time has lesser impact on the mechanisms' scalability. 244 3.6. Routing protocol dependency 246 IP autoconfiguration mechanisms require special signalling in order 247 to allow each node to be assigned a usable and unique IP address. 248 Such signalling constitutes additional overhead, as mentioned in 249 Section 3.1. Depending on the amount of signalling, which itself 250 depends on the MANET scenario, the convergence time of IP 251 autoconfiguration mechanisms and hence their scalability can be 252 impacted. 254 Consequently, one approach is to encapsulate the IP autoconfiguration 255 signalling into the routing protocol messages, where in this case IP 256 autoconfiguration mechanisms can be either routing protocol dependent 257 or routing protocol partially dependent. The former necessitates the 258 existence of a particular routing protocol in order to function, 259 where the IP autoconfiguration mechanism in this case is considered 260 to be tailored to a specific routing protocol (for instance, 261 extending an existing routing protocol to support IP 262 autoconfiguration). In the latter, the IP autoconfiguration 263 mechanism needs the routing protocol messages in order to transfer 264 its signalling, but is adaptive to any existing routing protocol 265 (especially when there are no special constraints in the IP 266 autoconfiguration mechanism, for instance, periodic messages 267 exchange, proactive approach, reactive approach). 269 On the other hand, IP autoconfiguration mechanisms can be routing 270 protocol independent, where in such case they do not consider at all 271 the existence of any particular routing protocol, however they 272 function in a complete independent manner. Although the 273 autoconfiguration mechanisms function in an independent manner of the 274 routing protocol in this case, it may happen that the routing 275 protocol messages can be used (if a routing protocol is found) for 276 optimised functioning of autoconfiguration mechanisms. 278 3.7. IP address space assignment efficiency 280 IP autoconfiguration mechanisms have different approaches for the IP 281 address space assignment, which in turn leads to different IP 282 assignment techniques. One approach is to keep the existing address 283 space centralised for all MANET Routers. Another approach is to 284 split the existing IP address space among the MANET Routers. The 285 first approach can suffer from IP address waste if the information 286 about addresses' release is not updated frequently by MANET Routers. 287 Even the process of IP address release synchronisation in this case 288 can require considerable exchange of messages between MANET Routers 289 and thus scalability can be impacted, especially for large scale 290 MANETs scenarios. The second approach is useful in the sense of 291 being fully distributed; however it can be less efficient in some 292 MANET scenarios especially those having frequent topology changes, 293 where some nodes may suffer from address space leak while others may 294 have address space waste. Consequently, this may impact the 295 convergence time and hence the scalability of IP autoconfiguration 296 mechanisms. 298 A third approach appears to be independent of any address space 299 assignment, where each node derives its IP address, for instance 300 using special stateful functions or using its subnet prefix and the 301 EUI-64 interface address. This approach seems interesting in the 302 sense of not taking care of any address space assignment process, 303 however, address uniqueness should be assured and the process of 304 subnet prefix assignment should not cause much signalling. 306 4. IP autoconfiguration solution space analysis 308 There are various different approaches to enable IP autoconfiguration 309 in ad-hoc networks [7]. In this section, we attempt to analyse the 310 vast solution space of MANET IP autoconfiguration by asking the 311 following questions: 313 1. Which entities are involved? 315 2. What type of IP delegation: addresses or prefixes? 317 3. How are IP addresses obtained? 319 4. How is IP address uniqueness guaranteed? 321 5. How is signalling performed? 323 6. What are the security considerations? 324 7. Are existing protocols modified? 326 4.1. Which entities are involved? 328 There are several combinations of entities involved in IP 329 autoconfiguration process. Below is a list of combinations to be 330 discussed in the following sub-sections: 332 o MANET Routers (distributed approach). 334 o MANET Routers and Border Routers. 336 o MANET Routers and distributed servers. 338 o MANET Routers and centralised server(s) (centralised approach). 340 4.1.1. MANET Routers (distributed approach) 342 A MANET can be IP autoconfigured in a fully distributed way, without 343 any nodes having special responsibilities in the IP autoconfiguration 344 process. In this scenario, the responsibility of the task is shared 345 among all the participant nodes. 347 A possible approach is that each MANET Router chooses randomly an IP 348 address and then checks that there is no address conflict, by asking 349 the other nodes in the MANET (e.g., [8] follows this approach). 350 Additionally, the responsibility of detecting conflicts may be 351 distributed, having all the nodes have the potential to detect 352 conflicts. This can be done, for example, by analysing incoming 353 routing protocol messages and looking for inconsistencies [9], [10], 354 [11]. 356 Some solution assign an IP address pool to every new node that enters 357 into the MANET and as of that moment, this node has the potential to 358 split their own IP pool and assign it to another new node [12] [13] 359 (e.g., all nodes collectively perform the functionality of a DHCP 360 server). 362 The main advantage of this distributed approach is that the existence 363 of a single point of failure is avoided and, therefore, in general 364 this kind of solution would be more robust and scalable than a 365 centralised approach. On the other hand, the main concern with this 366 approach is that the probability of an address conflict to happen is 367 higher, since there is no server that can assure that two nodes are 368 not assigned the same address. 370 4.1.2. MANET Routers and Border Routers 372 Some solution may involve Border Router(s) (also known as Internet 373 Gateways) playing an active role in the IP autoconfiguration process 374 (besides its role of gateways bounding the MANET and providing 375 connectivity to other routing domains). The most common approach is 376 that Border Routers (BRs) announce within the MANET the global IPv6 377 prefixes that can be used by MANET Routers in the configuration of 378 their IPv6 addresses [14]. MANET Routers would still play an 379 important role in the IP autoconfiguration process, and may for 380 example be responsible for the detection and resolution of address 381 conflicts. 383 The main concern with this approach is the need for BRs to be 384 deployed within the MANET. Basically, there are two possibilities: 385 o BRs are fixed routers in the infrastructure (they do not present 386 any kind of mobility) that support the attachment of MANET 387 Routers. There could be several application scenarios in which 388 assuming such an existence might be difficult or even impossible. 389 o BRs are special MANET Routers with the ability to connect to a 390 different routing domain (e.g., an infrastructure-based network 391 such as the Internet). Due to the node mobility of the MANET, it 392 could be possible that the network gets partitioned with no BR 393 available in one or more partitions, making then impossible for 394 MANET Routers belonging to that partition neither to communicate 395 to the other routing domain (in case of connected MANETs) nor to 396 provide with IP autoconfiguration support to new nodes that may 397 arrive and join the partition (that is, these new nodes will not 398 be able to configure a valid IP address while there is no BR 399 reachable within the network). In case of all BRs of a particular 400 MANET managing the same global IP prefixes, a partition of the 401 network might result in topologically incorrect configurations 402 and/or invalid routes towards MANET Routers. 404 4.1.3. MANET Routers and distributed servers 406 Alternatively, it may be considered the existence of some special 407 nodes within the MANET that participate in the IP autoconfiguration 408 process playing a predominant/special role (leader nodes). These 409 nodes are responsible for parts of the IP autoconfiguration of some 410 other MANET Routers [15] (e.g., by issuing Router Advertisements to 411 nodes within their scope). In some solutions, a hierarchy is 412 established by these special nodes. 414 The advantage of this approach is that may be easier to avoid address 415 conflicts than in a completely distributed approach, because there 416 exist a set of servers in charge of assigning IP addresses. 417 Furthermore, the reliability of the solution -- when compared to a 418 completely centralised solution (described next) -- is improved, 419 since there is no single point of failure. The main concern with 420 this approach is the need for a mechanism to elect these leader nodes 421 and to coordinate/synchronise them (in case this is required). If 422 the leader node role cannot be played by every node (when requested 423 to behave as leader node), then only specific ones can do it. In 424 this case, the same issues pointed out about Border Routers also 425 apply here. 427 4.1.4. MANET Routers and centralised server(s) (centralised approach) 429 In this case, a centralised server is in charge of the whole IP 430 autoconfiguration process. 432 Centralised approaches may make use of DHCPv6 [16], for example by 433 deploying a DHCPv6 server (within the infrastructure -- e.g., in case 434 of connected MANETS -- or within the MANET itself) and configuring 435 all MANET Routers as DHCP relays to get to the server when a new node 436 joins the network [17]. 438 Due to the centralised nature of these solutions (i.e. all the IP 439 autoconfiguration information is managed and kept in one single 440 entity), it becomes easier to ensure a correct IP configuration 441 across the MANET (e.g., no duplicate addresses configured). The main 442 concerns with this kind of approach are related to scalability and 443 reliability (the server is a single point of failure). Besides, 444 support of partitioning and merging becomes more complicated and the 445 mobility management in general is not easy. 447 4.2. What type of IP delegation: addresses or prefixes? 449 One important aspect of an IP autoconfiguration mechanism, that 450 usually has a very important impact on the mechanism operation, is 451 the type of IP addressing resources that are delegated to MANET 452 Routers: addresses or prefixes. 454 Current MANET architecture model [1] basically defines MANET 455 participant nodes as MANET Routers. These MANET Routers, besides 456 having one or more MANET interfaces, may also have non-MANET 457 interfaces, enabling legacy/non-MANET enabled IPv6 hosts (i.e. hosts 458 not running a MANET routing protocol) to attach to and obtain 459 connectivity from a MANET Router. In this particular scenario, 460 allocating IPv6 prefixes to MANET Routers appears as an important 461 feature to be provided. Most of the first proposals for IP 462 autoconfiguration mechanisms only tackled the address delegation 463 problem, whereas it has been lately when some proposals support also 464 prefix delegation. 466 It is usually harder to check prefix uniqueness within a MANET than 467 address uniqueness. Because of that, the most straightforward 468 approach to provide prefix allocation is to do it in such a way that 469 it is not needed to perform a prefix duplication check. Some ways of 470 doing that is by using a centralised mechanism (for example, based on 471 DHCPv6 [17]) or by using a generation/delegation approach that 472 guarantees the prefix uniqueness before-hand. 474 4.3. How are IP addresses obtained? 476 This is an important question, since the way an IP address/prefix is 477 obtained may also have an impact on other questions, for example 478 those related to the uniqueness of this address/prefix within the 479 MANET. 481 One of the goals that IP autoconfiguration mechanisms try to achieve 482 is the efficient provision of valid IP addresses to nodes, requiring 483 as less time as possible. In IPv6, there are several mechanisms 484 currently defined for infrastructure-based networks, and they can be 485 classified basically into two main groups, depending on how the IP 486 address is obtained: a) the IP address is locally selected by the 487 node (stateless autoconfiguration [5]), or b) the IP address is 488 assigned by a DHCPv6 [16] server (stateful autoconfiguration). 489 Additionally, the node is responsible for checking that the obtained 490 candidate IP address is not being used in the subnet. To do that, a 491 mechanism, called Duplicate Address Detection (DAD), has been also 492 standardised [5]. 494 Some of the autoconfiguration mechanisms used by non-MANET IPv6 nodes 495 to choose/generate an IP address can also be considered for the MANET 496 scenario. For example, a MANET Router may generate its addresses 497 based on the EUI-64 mechanism [5]. This approach has two main 498 advantages: by re-using the same solution that has been defined for 499 IPv6 infrastructure-based networks, the implementation of the 500 mechanism becomes easier. Additionally, the EUI-64 procedure 501 provides certain guarantees on the global uniqueness of the generated 502 IPv6 address (basically, if the IEEE MAC addresses were globally 503 unique -- which is almost true in most cases -- the EUI-64 generated 504 IPv6 addresses would be globally unique). 506 An alternative approach, used by several ad-hoc IP autoconfiguration 507 mechanisms (e.g., [8]), consists in generating a random IPv6 address 508 out of a known prefix. This solution has the advantage of being 509 quite simple, but special care should be taken in the implementation 510 of the random generator, since a bad/limited one may lead to 511 different nodes choosing the same IPv6 addresses. This could be an 512 issue in resource-limited devices, where the implementation of a good 513 random number generator could be hard/difficult. 515 Other solutions may make use of address pools, from which nodes may 516 take IP addresses from. These pools can also be distributed within 517 the ad-hoc network -- for example, hierarchically, by using a binary 518 split approach [12] -- providing also certain address uniqueness 519 guarantees. On the other hand, the management of these address pools 520 may be complicated, especially in environments that present high 521 mobility patterns. 523 Alternative ways of IP address generation can also be considered, for 524 example those that embed certain information on the IP address. This 525 is the case for example of the Cryptographic Generated Address (CGAs) 526 [18], for which the interface identifier is generated by computing a 527 cryptographic one-way hash function from the node's public key and 528 the IPv6 prefix (among other additional information). 530 An additional aspect that might be also worthwhile being tackled is 531 the address space distribution within the MANET (already briefly 532 discussed when we described the address pool distribution). 533 Basically, in IPv6 infrastructure-based networks, nodes are attached 534 to subnets, where all the attached nodes share the same prefix(es). 535 In ad-hoc networks, given its multi-hop nature, this is not the only 536 model that can be considered (that is, all the MANET Routers within a 537 MANET configuring their IPv6 addresses from the same prefix). We may 538 consider for example the distribution of different IPv6 prefixes 539 within the MANET, so different MANET Routers may configure addresses 540 from disjoint IPv6 prefixes. How these prefixes are distributed may 541 be based on different aspects, such as the geographic location of the 542 node, its relative position and distance from a MANET Border Router, 543 its position within a particular hierarchy, etc. The extreme case of 544 this prefix distribution approach is the delegation of a different 545 IPv6 prefix per MANET Router. 547 4.4. How is IP address uniqueness guaranteed? 549 This question actually encompasses the three different important 550 ones, to be discussed in the following sub-sections: 552 o How is address uniqueness detection performed? 554 o When address uniqueness detection is performed: pre-service and/or 555 in-service? 557 o How are address conflicts resolved? 559 4.4.1. How is address uniqueness detection performed? 561 It should be noted that a Non-unique Address Detection mechanism is 562 not always needed, since some methods of obtaining/generating 563 addresses (see section Section 4.3) ensure the uniqueness of the 564 assigned addresses/prefixes. This is the case when a centralised 565 approach is followed (e.g., a DHCPv6 server) which keeps an up-to- 566 date list of assigned/available addresses, or when a set of 567 coordinated servers is deployed -- collectively perform the DHCP 568 functionality --. For example, a new MANET Router may take IP 569 addresses from a set of address pools (a disjoint set of available IP 570 addresses) distributed within the ad-hoc network -- for example, 571 hierarchically, by using a binary split approach [13] -- and nodes 572 owning a pool which collectively perform the DHCP functionality, are 573 somehow coordinated to assure the pools are collision-free. 574 Additionally, there exist some methods of address generation which 575 ensure the uniqueness of assigned addresses (e.g., a special type of 576 function is used to generate a series of random numbers -- IPv6 577 addresses -- [19]). 579 On the other hand, some methods of obtaining/generating addresses do 580 not ensure the uniqueness of the assigned addresses/prefixes (e.g., 581 each MANET Router generates a random IPv6 address out of a known 582 prefix [8]). In these cases, mechanisms to detect and resolve 583 address conflicts are needed. 585 A first approach to detect address conflicts is to check that the 586 tentative address (e.g., randomly chosen) is not being used by 587 another node in the network. A first possibility is that each MANET 588 Router, before using a tentative address, floods an Address Request 589 message [8] in the network to query for the usage of this address. 590 The node waits for a while after sending this query for the reception 591 of a reply. The process is repeated if no answer is received, and if 592 after a number of attempts no reply has been received, the node 593 assumes that the tentatively chosen IPv6 address is unique and starts 594 using it. A main concern with this approach is its scalability which 595 is strongly correlated with the organisation of the network, i.e. a 596 flat structure, or a hierarchical one. If the former case, every 597 address acquisition results in extra traffic throughout the whole 598 network; however, only group leaders/representatives need to take 599 action in the latter case [15]. Additionally, this approach is not 600 applicable in networks where message delays cannot be bounded (e.g., 601 the use of timeouts cannot reliably detect absence of a message). 603 Another possibility is that before choosing a tentative address a 604 positive acknowledgement (ACK) is required from all known nodes in 605 the network [20]. This approach requires each MANET Router to 606 maintain an up-to-date list of all the nodes in the network. This 607 list can additionally be used to detect partitions in the network 608 (e.g., if a set of nodes do not reply, it could be due to a 609 partition). This approach has several significant drawbacks: its 610 scalability, the cost of updating this list of participants in highly 611 dynamic scenarios, and it is not applicable in networks where message 612 delays cannot be bounded -- which is a likely occurrence in dynamic 613 ad hoc networks -- because of its use of timeouts (e.g., the absence 614 of a message could be misinterpreted as a partition). 616 Another plausible approach is to relax the requirement of avoiding 617 duplicate addresses and focus on preventing a packet from being 618 routed to a wrong destination even if an address conflict exists 619 [21]. For example, a unique per MANET Router key is included in the 620 routing control packets and in the routing table entries. So, every 621 node is identified by a unique tuple (e.g., virtual IP 622 address). Following this approach, even if two nodes happen to have 623 chosen the same IP address, they can still be identified by the use 624 of their unique keys. The main concern with this approach is that it 625 implies to modify current routing protocols. 627 Another way of addressing the detection of duplicate addresses events 628 is looking for the consequences/results of a potential address 629 conflict. This can be accomplished passively by continuously 630 monitoring routing protocol traffic (e.g., looking for 631 inconsistencies) [9]. The basic idea of this approach is to exploit 632 the fact that some protocol events occur in case of duplicate 633 address, but (almost) never in case of a unique address. Most of the 634 existing solutions following this approach work with proactive 635 routing protocols (i.e. OLSR) but it can also be applied to on- 636 demand routing protocols [10]. The main advantages of this approach 637 are that it can work with current routing protocols (e.g., without 638 any modifications) and it does not introduce any extra overhead to 639 perform address uniqueness detection. On the other hand, the time 640 needed to detect conflicts may be high and during this time a MANET 641 Router may be experiencing deficiencies in their communications. 643 4.4.2. When address uniqueness detection is performed: pre-service 644 and/or in-service? 646 Address uniqueness detection may be needed at different times of the 647 communication. A first situation is when a MANET Router has just 648 chosen a tentative address and, before assigning it to the interface 649 and using it, it is checked that there is not an address conflict 650 (i.e. pre-service detection). 652 Additionally address conflicts may occur at any time, mainly caused 653 by mergers and partitions in the MANET. It may happen that nodes in 654 different networks/partitions may independently obtain the same 655 address, and duplicate addresses result if these networks merge 656 later. Thus, the address uniqueness detection may be needed to take 657 place in a continuous manner during the whole life of the MANET (in- 658 service detection) [2]. 660 Generally speaking, address uniqueness detection approaches commented 661 above could be used both as pre-service and as in-service mechanisms 662 [15] [21] [22]. Nevertheless, some of them seem to be more 663 appropriate for just one of the situations (pre-service or in- 664 service). For instance, querying the rest of MANET Routers to check 665 whether an IP address is available or not, seems to be more 666 acceptable in the case of pre-service detection (e.g., flooding is 667 not repeated periodically over the time). In general the overhead 668 introduced by the mechanism is going to be a more critical issue in 669 the case of in-service than in the case of pre-service detection. 670 So, approaches that analyse routing protocol messages looking for 671 inconsistencies (e.g., [21]) or uniquely identify nodes in routing 672 protocol messages (e.g., [19]) without adding extra messages seem to 673 be more suitable for the case of in-service detection. 675 4.4.3. How are address conflicts resolved? 677 Whenever an address conflict is detected the most common approach is 678 to use a heuristic to decide which MANET Router keeps on using the 679 duplicated address and which one has to look for a new IP address. 680 In the case of pre-service detection the solution is quite 681 straightforward the newcomer (e.g., trying to use an already-assigned 682 address) has to look for a new address. However if the conflict has 683 been caused by a merging (in-service detection) different heuristic 684 can be used (e.g., the node that detects the conflict keeps on using 685 the duplicated address [22]). 687 An interesting issue to be addressed is what happens in the event of 688 an address conflict while the node has an ongoing session. Session 689 continuity should be guaranteed after an address duplication episode. 690 One possible way of ensuring session continuity is IP tunnelling data 691 packets to the new assigned address (e.g., The MANET Router, keeping 692 on using the duplicated address, tunnels packets to the other MANET 693 Router [22]). 695 4.5. How is signalling performed? 697 In general, the IP configuration mechanism requires some extra 698 signalling -- additional to the signalling introduced by the ad-hoc 699 routing -- in order to reach its goal. The ways signalling is 700 performed may have an impact on the scalability and convergence time 701 of the IP autoconfiguration mechanism. 703 This extra signalling may be sent as separate messages or may be 704 added/piggybacked to existing routing protocol messages (e.g., prefix 705 or Border Router Information). The size of this added overhead and 706 its periodicity may vary on the different solutions. The main 707 concern of adding/piggybacking signalling information to the existing 708 routing protocol messages is that the IP autoconfiguration mechanism 709 is routing protocol dependant (see Section 4.6). On the other hand, 710 the main advantages of this approach are that the IP 711 autoconfiguration mechanism may somehow take advantage of the routing 712 discovery phase of the ad-hoc routing protocol (e.g., discovering of 713 available prefix and border routers) and do not introduce extra 714 messages (e.g., MANET Routers have to process less messages). 716 Flooding the MANET with signalling messages is required by some 717 mechanisms, for example asking for the approval of the rest of the 718 nodes with each new address acquisition. There exist different ways 719 of decreasing the effects of flooding such as limiting the scope, for 720 example organisging the network in a hierarchical structure, where 721 only group leaders need to take action with each new address 722 acquisition. 724 An alternative approach consists on relying -- partially or totally 725 -- on ad-hoc routing signalling to perform IP autoconfiguration. An 726 example of this approach is passive address uniqueness detection [15] 727 where conflicts are identified by analysing received routing protocol 728 messages and detecting inconsistencies. The main advantage of this 729 approach is that no extra signalling is introduced in the network and 730 the routing protocol is used as-is (e.g., without modifications), on 731 the other hand this kind of mechanism are routing protocol dependant 732 (e.g., the mechanism may be quite different for each particular 733 routing protocol). 735 4.6. Are existing protocols modified? 737 IP autoconfiguration mechanisms should function in a compatible 738 manner to the other underlying protocols; however some of these 739 protocols can be modified or extended in order to allow the proper IP 740 autoconfiguration mechanisms' functioning and signalling transfer. 741 Autoconfiguration mechanisms can extend the IPv6 Neighbour Discovery 742 Protocol (NDP) to work in multi-hop wireless networks (for instance 743 extending the NDP router solicitation and advertisement messages), or 744 employ ICMPv6 messages in a modified manner. Also, some mechanisms 745 can modify DHCP protocol, allowing MANET Routers to act as modified 746 DHCP proxies. 748 As discussed in Section Section 3.6, IP autoconfiguration mechanisms 749 can use the routing protocol messages to transfer the IP 750 autoconfiguration signalling. This takes place whether by simply 751 encapsulating such signalling in routing protocols control messages 752 with no routing protocols modification, or through adding new control 753 messages to the routing protocol ones. In the former, IP 754 autoconfiguration mechanisms are mostly open to any existing routing 755 protocol, proactive or reactive according to their functioning mode. 757 While in the latter, IP autoconfiguration mechanisms extend the 758 functioning of a given routing protocol to support IP 759 autoconfiguration, which in turn limits their application scope. 761 4.7. What are the security considerations? 763 The wireless ad hoc environment attacks can lead to improper 764 functioning of autoconfiguration mechanisms. Nevertheless, the IP 765 autoconfiguration mechanisms proposed so far do not propose special 766 mechanisms to secure the address autoconfiguration process. 768 Assuring reliable IP autoconfiguration mechanisms' signalling (i.e. 769 secure transfer) is critical for the proper functionality of any IP 770 autoconfiguration mechanism. In this sense secure communication 771 should be assured between MANET Routers, where this problem can be 772 differently treated according to the approach used by the IP 773 autoconfiguration mechanism. For IP autoconfiguration mechanisms 774 depending on the routing protocol, this can be done through securing 775 the routing protocol (especially, the control messages' transfer). 776 However, IP autoconfiguration mechanisms that are routing protocol 777 independent needs special security mechanisms. In spite of the type 778 of IP autoconfiguration mechanism (routing protocol dependent or 779 not), cooperation between nodes is an important factor in order to 780 assure the proper messages' (signalling) forwarding during the 781 autoconfiguration process. 783 Generally, security considerations can differ depending on different 784 MANET scenarios, where connected MANETs allows to have a central 785 authority that can play the role of a trusted third party to 786 authenticate MANET Routers for example or provide cryptographic keys. 788 5. Security Considerations 790 This draft highlights the security considerations issue during the 791 analysis of the solution space of MANET IP autoconfiguration; however 792 no special security mechanisms are given. The autoconfiguration 793 problem statement draft [2] states some important security issues 794 that worth considerations. Also, the IP evaluation considerations 795 draft [3] discusses the issue of trust and security in order to 796 assure the proper functioning of IP autoconfiguration solutions. 798 6. IANA Considerations 800 This document has no actions for IANA. 802 7. Acknowledgements 804 The structure and rationale of this I-D has been greatly inspired by 805 RFC 4889 [23]. 807 The work of Carlos J. Bernardos and Maria Calderon has been partially 808 supported by the Spanish Government under the POSEIDON (TSI2006- 809 12507-C03-01) project. 811 The work of Carlos J. Bernardos and Maria Calderon has also been 812 partially supported by the EU through the ICT FP7 European Project 813 CARMEN (INFSO-ICT-214994). Apart from this, the European Commission 814 has no responsibility for the content of this Internet-Draft. The 815 information in this document is provided as is and no guarantee or 816 warranty is given that the information is fit for any particular 817 purpose. The user thereof uses the information at its sole risk and 818 liability. 820 8. References 822 8.1. Normative References 824 [1] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 825 Network Architecture", draft-ietf-autoconf-manetarch-07 (work 826 in progress), November 2007. 828 [2] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 829 Autoconfiguration for MANET: Terminology and Problem 830 Statement", draft-ietf-autoconf-statement-04 (work in 831 progress), February 2008. 833 8.2. Informative References 835 [3] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation 836 Considerations for IP Autoconfiguration Mechanisms in MANETs", 837 draft-bernardos-autoconf-evaluation-considerations-03 (work in 838 progress), November 2008. 840 [4] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 841 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 842 September 2007. 844 [5] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 845 Autoconfiguration", RFC 4862, September 2007. 847 [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 848 Neighbor Discovery (SEND)", RFC 3971, March 2005. 850 [7] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP 851 address autoconfiguration mechanisms for MANETs", 852 draft-bernardos-manet-autoconf-survey-04 (work in progress), 853 November 2008. 855 [8] Perkins, C., "IP Address Autoconfiguration for Ad Hoc 856 Networks", draft-perkins-manet-autoconf-01 (work in progress), 857 November 2001. 859 [9] Weniger, K., "PACMAN: Passive autoconfiguration for mobile ad 860 hoc networks", IEEE Journal on Selected Areas in 861 Communications, vol. 23, no. 3, Mar 2005 pp. 507-519 , 2005. 863 [10] Jeong, H., "Passive Duplicate Address Detection for On-demand 864 Routing Protocols", draft-jeong-autoconf-pdad-on-demand-01 865 (work in progress), April 2007. 867 [11] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR", 868 draft-mase-manet-autoconf-noaolsr-01 (work in progress), 869 April 2006. 871 [12] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile 872 Ad Hoc Network", MILCOM 2002 , 2002. 874 [13] Tayal, A. and L. Patnaik, "An address assignment for the 875 automatic configuration of mobile ad hoc networks", Personal 876 Ubiquitous Computing , 2004. 878 [14] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6 879 addresses for MANET with multiple gateways (AMG)", 880 draft-ruffino-manet-autoconf-multigw-03 (work in progress), 881 June 2006. 883 [15] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large 884 Scale Mobile Ad-Hoc Networks", European Wireless 2002 , 2002. 886 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 887 Carney, "Dynamic Host Configuration Protocol for IPv6 888 (DHCPv6)", RFC 3315, July 2003. 890 [17] Templin, F., "Virtual Enterprise Traversal (VET)", 891 draft-templin-autoconf-dhcp-20 (work in progress), 892 October 2008. 894 [18] Aura, T., "Cryptographically Generated Addresses (CGA)", 895 RFC 3972, March 2005. 897 [19] Zhou, H., Ni, L., and M. Mutka, "Prophet Address Allocation for 898 Large Scale MANETs", Proceedings of INFOCOM 2003 , 2003. 900 [20] Nesargi, S. and R. Prakash, "MANETconf: Configuration of hosts 901 in a mobile ad hoc network", INFOCOM 2002 , 2002. 903 [21] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc 904 Networks", MOBIHOC'02 , 2002. 906 [22] Jeong, J., "Ad Hoc IP Address Autoconfiguration", 907 draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress), 908 January 2006. 910 [23] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 911 Route Optimization Solution Space Analysis", RFC 4889, 912 July 2007. 914 Appendix A. Change Log 916 Changes from -01 to -02: 917 o New release to keep the document alive. 918 o Update of some references. 920 Changes from -00 to -01: 921 o New release to keep the document alive. 922 o Update of some references. 924 Authors' Addresses 926 Carlos J. Bernardos 927 Universidad Carlos III de Madrid 928 Av. Universidad, 30 929 Leganes, Madrid 28911 930 Spain 932 Phone: +34 91624 6236 933 Email: cjbc@it.uc3m.es 934 Maria Calderon 935 Universidad Carlos III de Madrid 936 Av. Universidad, 30 937 Leganes, Madrid 28911 938 Spain 940 Phone: +34 91624 8780 941 Email: maria@it.uc3m.es 943 Hassnaa Moustafa 944 France Telecom 945 38-40 rue du General Leclerc 946 Issy Les Moulineaux 92794 Cedex 9 947 France 949 Phone: +33 145296389 950 Email: hassnaa.moustafa@orange-ftgroup.com 952 Full Copyright Statement 954 Copyright (C) The IETF Trust (2008). 956 This document is subject to the rights, licenses and restrictions 957 contained in BCP 78, and except as set forth therein, the authors 958 retain all their rights. 960 This document and the information contained herein are provided on an 961 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 962 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 963 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 964 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 965 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 966 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 968 Intellectual Property 970 The IETF takes no position regarding the validity or scope of any 971 Intellectual Property Rights or other rights that might be claimed to 972 pertain to the implementation or use of the technology described in 973 this document or the extent to which any license under such rights 974 might or might not be available; nor does it represent that it has 975 made any independent effort to identify any such rights. Information 976 on the procedures with respect to rights in RFC documents can be 977 found in BCP 78 and BCP 79. 979 Copies of IPR disclosures made to the IETF Secretariat and any 980 assurances of licenses to be made available, or the result of an 981 attempt made to obtain a general license or permission for the use of 982 such proprietary rights by implementers or users of this 983 specification can be obtained from the IETF on-line IPR repository at 984 http://www.ietf.org/ipr. 986 The IETF invites any interested party to bring to its attention any 987 copyrights, patents or patent applications, or other proprietary 988 rights that may cover technology that may be required to implement 989 this standard. Please address the information to the IETF at 990 ietf-ipr@ietf.org.