idnits 2.17.00 (12 Aug 2021) /tmp/idnits43290/draft-bernardos-autoconf-evaluation-considerations-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. 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 ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) H. Moustafa 3 Internet-Draft France Telecom 4 Intended status: Informational C. Bernardos 5 Expires: May 6, 2009 M. Calderon 6 UC3M 7 November 2, 2008 9 Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs 10 draft-bernardos-autoconf-evaluation-considerations-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 6, 2009. 37 Abstract 39 This Internet Draft aims at providing general guidelines for the 40 AUTOCONF solution space, through providing a set of evaluation 41 considerations for IP autoconfiguration mechanisms in MANETs. These 42 evaluation considerations conform to the AUTOCONF problem statement 43 draft and the MANET architecture draft. The main objective of this 44 draft is to illustrate some key features and highlight some important 45 behaviours for the different autoconf mechanisms, and thus aiming to 46 help solution developers during mechanisms' design and to help 47 implementers in the choice of the autoconf mechanism that fits better 48 their particular requirements, taking into consideration a number of 49 important factors that are discussed in this draft. 51 Table of Contents 53 1. Introduction and motivation . . . . . . . . . . . . . . . . . 3 54 2. Evaluation Considerations . . . . . . . . . . . . . . . . . . 3 55 2.1. Node/Network Characteristics . . . . . . . . . . . . . . . 3 56 2.1.1. MANET Scenarios . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. Mobility type . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Functional Characteristics . . . . . . . . . . . . . . . . 5 59 2.2.1. Address Uniqueness . . . . . . . . . . . . . . . . . . 5 60 2.2.2. Merging support . . . . . . . . . . . . . . . . . . . 6 61 2.2.3. Partitioning support . . . . . . . . . . . . . . . . . 6 62 2.2.4. Prefix delegation support . . . . . . . . . . . . . . 6 63 2.3. Performance Characteristics . . . . . . . . . . . . . . . 7 64 2.3.1. Protocol overhead . . . . . . . . . . . . . . . . . . 7 65 2.3.2. Robustness . . . . . . . . . . . . . . . . . . . . . . 7 66 2.3.3. Convergence time . . . . . . . . . . . . . . . . . . . 8 67 2.3.4. Scalability . . . . . . . . . . . . . . . . . . . . . 8 68 2.3.5. Address space utilisation . . . . . . . . . . . . . . 9 69 2.4. Nodes' Behaviour Characteristics . . . . . . . . . . . . . 9 70 2.4.1. Distributed/Centralised approach . . . . . . . . . . . 9 71 2.4.2. Trust and Security . . . . . . . . . . . . . . . . . . 10 72 2.5. Architectural Characteristics . . . . . . . . . . . . . . 10 73 2.5.1. Integration with standard IPv6 nodes . . . . . . . . . 10 74 2.5.2. Gateway involvement . . . . . . . . . . . . . . . . . 11 75 2.6. Usability Characteristics . . . . . . . . . . . . . . . . 11 76 2.6.1. Routing Protocol Dependency . . . . . . . . . . . . . 11 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 Intellectual Property and Copyright Statements . . . . . . . . . . 15 87 1. Introduction and motivation 89 Ad hoc networks present particular characteristics that should be 90 taken into account when designing address auto-configuration 91 protocols. These unique characteristics make existing solutions for 92 IP infrastructure-based networks (e.g., RFCs 2461, 2462, 3315 etc.) 93 difficult to be applied, as is, in MANETs. Some limitations of these 94 existing solutions are stated in [1] and they mainly concern: the 95 lack of multi-hop support, the lack of dynamic topology support, the 96 lack of network merging support and the lack of network partitioning 97 support. 99 The AUTOCONF WG is working to develop and standardise IP 100 autoconfiguration mechanisms for MANETs. The dynamic and random 101 nature of MANETs together with the different environmental behaviour, 102 results in different autoconfiguration mechanisms functionalities and 103 characteristics. The problem statement draft [1] highlights the 104 importance of some solution considerations that should be taken in 105 mind, mainly focusing on low overhead, low delay, different link 106 type's applicability, interaction with the existing protocols and 107 security issues. In this context, this document discusses some 108 evaluation considerations for IP autoconfiguration mechanisms in 109 MANETs, giving a useful reference for the solutions' space as well as 110 guidelines for solution developers during mechanisms' design and 111 implementers in the choice of the autoconf mechanism. These 112 considerations will help to decide which of the available autoconf 113 mechanisms fits better a particular scenario. 115 The evaluation considerations developed in this draft refer to the 116 previous study, carried out in [3], in which an analysis of several 117 evaluation criteria for MANET autoconf mechanisms is done. The 118 evaluation considerations presented in this draft are generally 119 classified according to a number of characteristics, namely: node/ 120 network characteristics, nodes' behaviour characteristics, functional 121 characteristics, performance characteristics, and usability 122 characteristics. 124 2. Evaluation Considerations 126 2.1. Node/Network Characteristics 128 The node/network characteristics basically deal with the special 129 features and constraints that a MANET environment might have. This 130 includes the applicability scenarios as well as some nodes' 131 characteristics, like the type of mobility. 133 2.1.1. MANET Scenarios 135 This characteristic concerns the MANET environment. In this context, 136 two possible scenarios of MANET are identified in [1]: 137 1. Standalone MANETs, which are autonomous ad hoc networks that are 138 not connected to any external network. All traffic is generated 139 by MANET nodes and destined to nodes in the same MANET. Examples 140 of these networks are conference networks, battlefield networks, 141 surveillance networks, etc. In standalone MANET scenarios, nodes 142 may join or leave randomly. Most likely, there is neither pre- 143 established nor reliable address or prefix allocation agency is 144 present in such type of networks. 145 2. Connected MANETs, which are ad hoc networks having connectivity 146 to one or more external networks, typically the Internet, by 147 means of one or more gateways. It is noticed that these networks 148 may be connected to the Internet in a permanent fashion or an 149 intermittent fashion. 151 This characteristic is an important and basic one that should be 152 considered during the design phase of any autoconfiguration 153 mechanism. Different mechanisms functionalities will be required 154 according to the scenario type, where for example, solutions designed 155 for connected MANET scenarios have to deal with the issue of getting 156 global IPv6 addresses that allow nodes to get Internet connectivity. 157 In fact, contributions designated for connected MANETs can mostly be 158 general for both types of scenarios. Indeed, an autoconfiguration 159 mechanism should take into account the case of scenario transition, 160 where a connected MANET can converge to a standalone MANET if it 161 loses its attachment with the infrastructure, or a partially 162 standalone manner if sub-network(s) exist(s) due to partitioning. 164 2.1.2. Mobility type 166 This characteristic concerns the nodes behaviour in MANETs. In fact, 167 nodes' mobility type depends on the MANET application type. It is 168 also noticed that MANET nodes (or some of them) could be fixed or 169 present low mobility patterns in certain applications (e.g. mesh 170 networks). 172 This characteristic impacts the performance of autoconfiguration 173 mechanisms. Particularly, the transmission reliability of 174 autoconfiguration messages differs from low to high mobility 175 scenarios. It is noticed that this characteristic impacts the 176 autoconfiguration mechanisms performance, especially the convergence 177 time and the scalability. Indeed, high mobility can lead to frequent 178 subnet change by mobile nodes and hence requires a change in the 179 nodes' address. The design of any autoconfiguration mechanism should 180 take into account the nodes mobility type, where employing periodic 181 functionalities is more suitable for high nodes' mobility scenarios. 182 Furthermore, the size of messages' exchange should adapt to the 183 mobility types of nodes. A complex problem under this issue is the 184 co-existence of different mobility types within the same MANET, where 185 we can have different types of mobility ranging from low to high 186 among the communicating nodes in a given MANET. 188 An additional issue, related to network partitioning and merging, is 189 the movement detection, that is specially relevant in high mobility 190 scenarios. Additionally, movement detection can be hard to achieve 191 in MANET scenarios and therefore should also be taken into account 192 when analysing a particular autoconf solution. 194 2.2. Functional Characteristics 196 The functional characteristics describe the functionalities that a 197 mechanism must aim at featuring [3]. An autoconfiguration mechanism 198 can implement one or several of these functionalities. Such 199 functionalities can vary according to the MANET environment and the 200 autoconfiguration approach. There should be a trade-off between the 201 number of functionalities that an autoconfiguration mechanism 202 implements and the network performance. The increase in the number 203 of functionalities, provided that they are correctly designed, should 204 not harm the network performance. 206 2.2.1. Address Uniqueness 208 The Address Uniqueness characteristic concerns two points: i) 209 Duplicate Address Avoidance, and ii) Non-unique Address Detection. 210 Duplicate address avoidance is a mandatory characteristic in any 211 autoconfiguration mechanism. It consists in making all 212 autoconfiguration mechanisms' functionalities assign addresses only 213 after checking their uniqueness. Hence, this principle must be the 214 core of any design of an autoconfiguration mechanism [3]. On the 215 other hand, Non-unique Address Detection is the process used to 216 detect address collisions and resolve them. This might be a heavy 217 process in any MANET IP autoconfiguration mechanism, requiring a 218 considerable number of control messages. 220 The Duplicate Address Avoidance is the only mandatory functionality 221 in an autoconfiguration mechanism, as it reflects the assumption of 222 uniqueness upon which the routing protocol is based [1]. 224 As for Non-unique Address Detection, most of the existing 225 contributions employ such a procedure, whether through developing a 226 Non-unique Address Detection mechanism or through using an existing 227 one. Due to MANETs' merging and separation, this process should take 228 place in a continuous manner before the IP assignment (Pre-service) 229 as well as after the IP assignment (In-service) [2]. However, there 230 are some contributions that are Non-unique Address Detection-free, 231 which do not use any of such mechanisms while being capable of 232 assuring the IP address uniqueness. Employing a Non-unique Address 233 Detection mechanism adds overhead to the autoconfiguration mechanism 234 and has an impact on its scalability. 236 2.2.2. Merging support 238 The merging characteristic presents the ability of the 239 autoconfiguration mechanism to detect MANETs' merging and provide 240 functionalities to avoid IP address conflicts and connectivity 241 problems in such case. 243 Merging support is important in the case where two previously 244 disjoint ad hoc networks get connected, since there might be nodes 245 with duplicated address in the merged network, and therefore it is 246 needed to make some nodes change the IP addresses they are using to 247 avoid the conflict (this can be achieved for example by using in- 248 service Non-unique Address Detection mechanisms). 250 2.2.3. Partitioning support 252 The partitioning characteristic presents the ability of the 253 autoconfiguration mechanism to detect MANETs' partitioning and 254 provide functionalities to avoid IP address conflicts and 255 connectivity problems in such case. 257 Partitioning support is important, especially in connected scenarios, 258 in which as a result of a network split, some nodes of the ad hoc 259 network might lose the connectivity to the node that they were using 260 as gateway to the fixed infrastructure and to the Internet. 261 Additionally, it is also important to analyse how an autoconf 262 solution deal with the issue of re-use or re-claiming of resources 263 (such as IP addresses) once a node has left a particular network. 265 2.2.4. Prefix delegation support 267 The MANET architecture document [2] considers nodes of a MANET as 268 routers (MANET Routers) that can have attached "traditional" hosts, 269 and that therefore need to acquire IPv6 prefixes instead of just 270 single addresses. 272 It is important to analyse if a particular AUTOCONF solution supports 273 the delegation of IPv6 prefixes to nodes. 275 2.3. Performance Characteristics 277 Performance is always a critical issue in communication protocols. 278 In the case of autoconf, performance might be specially relevant in 279 certain scenarios (for example, in constrained devices). The 280 performance of an autoconfiguration mechanism can be evaluated 281 through a number of characteristics, as mentioned below. 283 2.3.1. Protocol overhead 285 This characteristic concerns the additional signalling required by 286 the autoconfiguration mechanism. Such signalling is considered as 287 protocol overhead that might have a significant performance impact. 289 Several cases may be are considered: 290 o The IP autoconfiguration mechanism (not the ad-hoc routing 291 protocol) requires additional message flooding. This message 292 flooding may be optimised using existing techniques. 293 o The IP address autoconfiguration mechanism requires some protocol 294 messages (besides the normal routing protocol messages) to be 295 exchanged locally or it modifies existing routing protocol 296 messages to add (piggybacking) some information (e.g., prefix or 297 GW information). The size of the added information and how often 298 this information is sent can vary depending on the particular 299 autoconf solution and the applicability scenario. 300 o The IP address autoconfiguration mechanism does not require any 301 special signalling to function (that is, it works in a passive 302 way). 304 This characteristic might have an impact on the convergence time and 305 thus the scalability of the autoconfiguration mechanism. 307 2.3.2. Robustness 309 One important characteristic/property of an autoconf mechanism is its 310 robustness. Given the particular multi-hop characteristics of MANET 311 scenarios, it might be important to analyse the underlying 312 assumptions that an autoconf mechanism might make. 314 For example, certain autoconf solutions may assume that the 315 underlying physical layer is reliable and messages are never lost, 316 while another autoconf mechanism may need to provide additional 317 mechanisms that deal with the reliability of the message 318 transmission. Obviously, in certain scenarios the former assumption 319 makes no sense, and therefore, autoconf solutions may need to 320 implement some procedures to ensure that a certain protocol message 321 -- needed for the correct operation of the autoconf mechanism -- has 322 actually reached its intended destination(s). Additionally, an 323 autoconf solution may be designed in such a way that certain message 324 loos are supported without disrupting the correct operation of the 325 autoconf mechanism. 327 The same kind of reasoning than above can be applied for solutions 328 that assume an ordered delivery of signalling messages or the 329 integrity of the received messages . 331 2.3.3. Convergence time 333 Another important characteristic, that can be related to the 334 robustness as well, is the convergence time of an autoconf solution. 335 Depending on the scenario and/or the application, we may define the 336 convergence time as the time required by a single node to get a 337 usable (and unique) IPv6 address or as the time required by the whole 338 network to have all its nodes configured with correct addresses. For 339 several scenarios, it might not be important for an autoconf solution 340 to take a long time to finish its operation (e.g., several minutes), 341 for example because the autoconf mechanism is only run once and then 342 the nodes remain stable. However, for other scenarios, it might be 343 required that the autoconf solution should take less to converge than 344 a given amount of time. 346 In relation to the convergence time, it might be also important for 347 an autoconf mechanism not to assume at any time an upper limit on the 348 time required for a certain message to reach any node of the MANET, 349 since this may have an impact on the global convergence time. 350 Besides, this kind of assumptions might lead to a solution not to 351 work properly in a particular scenario (where the time required for a 352 message sent from a node A to reach a node B is longer than the 353 assumed upper limit). 355 2.3.4. Scalability 357 An important issue to deal with during autoconfiguration mechanisms 358 design is the scalability of mechanisms to different networks sizes. 359 The MANET Architecture I-D [2] defines as Small a MANET composed of 360 2-30 peer MANET routers, Moderate a MANET composed of 30-100 peer 361 MANET routers, Large a MANET composed of 100-1000 peer MANET routers, 362 and Very Large those MANETs larger than 1000 peer MANET routers. 364 An autoconfiguration mechanism, in its own, generates signalling 365 overhead that may be high, thus impacting scalability. As mentioned 366 in [3], information diffusion also suffers from a large size as the 367 diffusion delay can increase such that information arrives at a node 368 from distant parts of the network with a long delay. 370 Scalability is a very important characteristic that deserves 371 consideration. An autoconfiguration mechanism is not scalable, if 372 its performance degrades significantly when the network size 373 increases. This characteristic would be highly dependant on the 374 particular usability scenario, since for example there might be an 375 autoconf solution designed for a specific moderate-MANET application 376 that works great for that particular MANET but this might not be the 377 case when the same solution is used for very large network. 379 2.3.5. Address space utilisation 381 This characteristic basically analyses how an autoconf solution makes 382 use of the available address space. For example, there are solutions 383 that split the address space into ranges delegated to different 384 nodes, that are responsible of the assignment of addresses from those 385 ranges, whereas there are other solutions that keep the available 386 address space common for all the MANET nodes. Obviously, the former 387 approach might be more inefficient in terms of address space 388 utilisation, compared to the latter. However, the first approach may 389 present additional advantages that may make it better for certain 390 scenarios. 392 This characteristic is important in networks that are assigned a 393 short range of addresses, as well as in large and dense networks. If 394 too many addresses are wasted by the autoconfiguration mechanism, 395 such that all idle and accessible addresses are in use, an incoming 396 node cannot be granted an address. This invalidates many of the 397 functionalities [3]. 399 2.4. Nodes' Behaviour Characteristics 401 The nodes' behaviour is an important point to be considered during 402 autoconfiguration mechanisms design. It describes how the 403 communicating nodes behave during the autoconfiguration process. 404 Actually, nodes may behave in a distributed or centralised manner 405 which affects the address assignment approach. In addition, trust is 406 a pre-requisite behaviour among nodes and has a great impact on the 407 correct functionalities of any autoconfiguration mechanism. 409 2.4.1. Distributed/Centralised approach 411 There are different possible approaches that an IP autoconfiguration 412 mechanism might follow to assign IP addresses to all the nodes of a 413 MANET. One possibility is to deploy a centralised server that is in 414 charge of the IP address assignment (e.g., DHCPv6). The opposite 415 approach is not to make use of any server, but to share the IP 416 address assignment task among all the participant nodes. Between 417 these two extreme cases, intermediate approaches can be found, for 418 example those that deploy several distributed servers within the 419 MANET and therefore can be considered as distributed solutions in one 420 sense, while they can also be considered as centralised in a certain 421 level, since they still make use of servers. 423 This characteristic has a direct impact on the performance of any 424 autoconfiguration mechanism and is somewhat related to the MANET 425 scenario, where, for example, a totally centralised approach is not 426 suitable in a standalone MANET. 428 2.4.2. Trust and Security 430 A very important issue concerns securing communication, or assuring 431 secure links existence, between the communicating nodes during the 432 autoconfiguration process. So far, this issue is not considered 433 within the ongoing mechanisms. To assure reliable messages' 434 transmission and hence correct mechanisms functionalities, secure 435 communication should exist between nodes. The main difficulty is 436 mainly concerning the multi-hop environment. 438 In the design of autoconfiguration mechanisms, attacks in ad hoc 439 multi-hop environments should be considered. Further, it is 440 important to have a trust relationship between each communicating 441 pair of nodes that are involved in the autoconfiguration process. 442 This could assure secure and hence correct functioning of 443 autoconfiguration mechanisms. Trust relationship can differ in 444 standalone MANET compared to connected MANET, where a central 445 authority can play the role of a trusted third party that could help 446 in trust provision among the participating nodes. Also, cooperation 447 between nodes is an important factor in order to assure the proper 448 message forwarding during the autoconfiguration process. In this 449 context, MANET nodes cooperation should be satisfied and also 450 gateways should be enough cooperative. 452 2.5. Architectural Characteristics 454 The architectural characteristics concern the nodes architecture 455 (especially, the interfaces architecture) as well as the topological 456 architecture and network deployment, concerning special elements/ 457 entities (such as gateways). 459 2.5.1. Integration with standard IPv6 nodes 461 One characteristic that can be considered important in certain 462 scenarios is the integration of the autoconf solution with standard 463 IPv6 nodes. For example, certain autoconf mechanisms may allow/be 464 compatible to support IPv6 nodes to get addresses using standard 465 mechanisms defined in IPv6, while others may be totally incompatible 466 with today's IPv6 nodes, therefore preventing these nodes to inter- 467 operate with these autoconf solutions, unless the IPv6 nodes are 468 properly modified to support them. 470 2.5.2. Gateway involvement 472 This characteristic concerns the role that Internet gateways could 473 have in the IP address autoconfiguration process for incoming nodes. 474 Indeed, in connected scenarios, Internet gateways are considered to 475 provide the MANET with connectivity to the fixed infrastructure. 476 However, these gateways might also have a role/involvement in the IP 477 address assignment procedure (e.g., in some solutions, the gateway 478 might only be responsible of forwarding packets to the 479 infrastructure, while in other solutions it may also be involved in 480 the task of providing nodes with addresses/prefixes). 482 This characteristic is interesting to be studied for each IP 483 autoconfiguration mechanism and need to be considered during the 484 mechanisms' design. Actually, gateway involvement depends somehow on 485 whether the used approach is centralised or distributed. It can be 486 also related to the address space usage. 488 2.6. Usability Characteristics 490 The usability characteristics describe how and under which 491 circumstances an autoconf mechanism is able to be used. This means 492 the adaptability to the whole environment including users and other 493 protocols [3]. 495 2.6.1. Routing Protocol Dependency 497 Typically, IP autoconfiguration mechanisms require special signalling 498 and thus control overhead in order to assign a unique IP address for 499 each MANET node and, in a many cases, to verify the uniqueness of 500 each assigned address. Consequently, some of the proposed IP 501 autoconfiguration mechanisms are routing protocols dependent; making 502 use of the ad hoc routing protocol in transmitting their own signals, 503 especially benefiting from the routing discovery phase in the ad hoc 504 routing protocol. 506 In this context, autoconfiguration mechanisms may be dependent on 507 routing protocols and could not function without them (e.g., 508 autoconfiguration mechanisms can be tailored for specific ad hoc 509 routing protocols, because the use of the signalling of the routing 510 protocol or because they make use of any kind of information provided 511 by the routing protocol). On the other hand, autoconfiguration 512 mechanisms can be routing protocols independent, not requiring the 513 existence of any particular routing protocol to function. In 514 between, autoconfiguration mechanisms may need a routing protocol, 515 where if a routing protocol exist this will optimise the mechanisms 516 operation and if no routing protocol exist, the mechanism could also 517 work. 519 3. Security Considerations 521 Due to the open wireless environment of ad hoc networks, IP 522 autoconfiguration mechanisms are susceptible to a number of attacks. 523 The autoconfiguration problem statement draft [1] states some 524 security issues that worth consideration. 526 4. IANA Considerations 528 This document has no actions for IANA. 530 5. Acknowledgements 532 The authors would like to thank Charles Perkins and Joe Macker for 533 their comments and suggestions during 69th IETF. We also like to 534 thank Shubhranshu Singh and Thomas Clausen for their very valuable 535 comments and suggestions on the content of this draft. 537 Authors also want to point out that some useful content of [3] has 538 been used in several ways in the present draft. 540 The work of Carlos J. Bernardos and Maria Calderon has been partially 541 supported by the Spanish Government under the POSEIDON (TSI2006- 542 12507-C03-01) project. 544 The work of Carlos J. Bernardos and Maria Calderon has also been 545 partially funded by the EU through the ICT FP7 European Project 546 CARMEN (INFSO-ICT-214994). Apart from this, the European Commission 547 has no responsibility for the content of this Internet-Draft. The 548 information in this document is provided as is and no guarantee or 549 warranty is given that the information is fit for any particular 550 purpose. The user thereof uses the information at its sole risk and 551 liability. 553 6. References 555 6.1. Normative References 557 [1] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 558 Autoconfiguration for MANET: Terminology and Problem Statement", 559 draft-ietf-autoconf-statement-04 (work in progress), 560 February 2008. 562 [2] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network 563 Architecture", draft-ietf-autoconf-manetarch-07 (work in 564 progress), November 2007. 566 6.2. Informative References 568 [3] Clausen, T., "Evaluation Criteria for MANET Autoconf 569 Mechanisms", draft-clausen-autoconf-criteria-00 (work in 570 progress), July 2005. 572 Appendix A. Change Log 574 Changes from -02 to -03: 575 o New release to keep the document alive. 577 Changes from -01 to -02: 578 o New release to keep the document alive. 579 o Update of some references. 581 Changes from -00 to -01: 582 o Mainly editorial changes. 584 Authors' Addresses 586 Hassnaa Moustafa 587 France Telecom 588 38-40 rue du General Leclerc 589 Issy Les Moulineaux 92794 Cedex 9 590 France 592 Phone: +33 145296389 593 Email: hassnaa.moustafa@orange-ftgroup.com 595 Carlos J. Bernardos 596 Universidad Carlos III de Madrid 597 Av. Universidad, 30 598 Leganes, Madrid 28911 599 Spain 601 Phone: +34 91624 6236 602 Email: cjbc@it.uc3m.es 603 Maria Calderon 604 Universidad Carlos III de Madrid 605 Av. Universidad, 30 606 Leganes, Madrid 28911 607 Spain 609 Phone: +34 91624 8780 610 Email: maria@it.uc3m.es 612 Full Copyright Statement 614 Copyright (C) The IETF Trust (2008). 616 This document is subject to the rights, licenses and restrictions 617 contained in BCP 78, and except as set forth therein, the authors 618 retain all their rights. 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 623 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 624 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 625 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org.