idnits 2.17.1 draft-laouiti-manet-olsr-address-autoconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 505 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 47 has weird spacing: '...r stone of th...' == Line 145 has weird spacing: '...ould be broad...' == Line 175 has weird spacing: '...message that ...' == Line 220 has weird spacing: '... in the netwo...' == Line 224 has weird spacing: '.... This guara...' -- 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 (14 February 2005) is 7004 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) ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Cedric Adjih 3 IETF MANET Working Group Saadi Boudjit 4 Expiration: 14 August 2005 Philippe Jacquet 5 Anis Laouiti 6 Paul Muhlethaler 8 INRIA Rocquencourt, France 9 14 February 2005 11 Address autoconfiguration in Optimized Link State Routing Protocol 13 draft-laouiti-manet-olsr-address-autoconf-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, the 19 authors certify that any applicable patent or other IPR claims of 20 which they are aware have been or will be disclosed, and any of which 21 they become aware will be disclosed, in accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright(C)The Internet Society (2005). 42 Abstract 44 One of the MANET protocols which have been recently promoted to 45 experimental RFC is the OLSR routing protocol[3]. This document aims 46 at complementing the OLSR routing protocol specifications to handle 47 autoconfiguration. The corner stone of this autoconfiguration 48 protocol is an advanced duplicate address detection algorithm. We 49 propose a comprehensive autoconfiguration scheme whose basic idea is 50 to avoid conflicts in the 2-hop neighborhood of each node. We have 51 designed two algorithms to perform this task. These algorithms are 52 shown to work in any case of multiple conflicts, especially during 53 network mergers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Duplicate address detection and MAD message description . . . . . 6 61 5. Duplicate Address Detection mechanism . . . . . . . . . . . . . . 7 62 5.1. First algorithm . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.1. First rule . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1.2. Second rule . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1.3. Full algorithm . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2. Second algorithm . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Address assignment . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. Pool of addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Resolution of a conflict . . . . . . . . . . . . . . . . . . . . 11 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Mobile Ad hoc NETworks (MANETs) are infrastructure-free, highly 77 dynamic wireless networks, where central administration or configura- 78 tion by the user is very difficult. In hardwired networks nodes usu- 79 ally rely on a centralized server and use a dynamic host configura- 80 tion protocol, like DHCP[1], to acquire an IP address. Such a solu- 81 tion cannot be deployed in MANETs due to the unavailability of any 82 centralized DHCP server. For small scale MANETs, it may be possible 83 to allocate free IP addresses manually. 85 However, the procedure becomes impractical for a large-scale or open 86 system where mobile nodes are free to join and leave. Most of the 87 autoconfiguration algorithms proposed for ad hoc networks are inde- 88 pendent of the routing protocols and therefore, generate a signifi- 89 cant overhead. Using the genuine optimization of the underlying 90 routing protocol can significantly reduce the autoconfiguration over- 91 head. 93 Research on automatic configuration of IP addresses for MANET is rel- 94 atively less frequent. The IPv6 and ZEROCONF working groups of the 95 IETF deal with autoconfiguration issues but with a focus on wired 96 networks. Automatic address allocation is more difficult in a MANET 97 environment than in wired networks due to instability of links, 98 mobility of the nodes, the open nature of the mobile ad hoc networks, 99 and lack of central administration in the general case. Thus per- 100 forming a DAD (Duplicate Address Detection) generates more complexity 101 and more overhead in ad hoc networks than in wired networks where 102 protocols such as DHCP[1] and SAA [2] can be used. 104 In this document we will describe an autoconfiguration solution for 105 the OLSR protocol. This solution is based on an efficient Duplicate 106 Address Detection (DAD) algorithm which takes advantage of the gen- 107 uine optimization of the OLSR protocol. We actually propose two 108 solutions to handle multiple address conflicts. They have the same 109 main basic idea which is to ensure the absence of conflicts in the 110 2-hop neighborhood of each node. 112 2. Terminology 114 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC2119 [5]. 118 For the OLSR description and terminology, the reader should refer to 119 the OLSR RFC [3]. 121 3. Overview 123 Our proposed autoconfiguration algorithm is based on two steps. In 124 the first step, an IP address is selected by the arriving node and 125 this latter can join the ad hoc network. Numerous schemes can be 126 used to select this IP address for instance the node can perform a 127 random selection; another technique is that a neighbor node selects 128 this IP address for the arriving node. 130 After this first step has been performed, the second step can take 131 place. The aim of this step is to detect potential address duplica- 132 tions on run. To perform this task a DAD algorithm is started on 133 this newly configured node. This DAD algorithm allows the newly con- 134 figured node to state whether the selected address is duplicated or 135 not in a proactive manner. If such a case occurs, a node can change 136 its address with respect to some specified criteria. 138 In such a case a new address can be chosen. The DAD algorithm uses a 139 special control packet called MAD for ``Multiple Address Declara- 140 tion''. This control packet includes the node address and a node 141 identifier. This packet is broadcast in the network, thus all the 142 network nodes must receive this packet. The duplicate detection uses 143 the node identifier. If a node receives an MAD message with a dif- 144 ferent identifier than its own, an address duplication is detected. 145 To spare the channel bandwidth the MAD packet should be broadcasted 146 using the MPR flooding. 148 On the other hand, duplicated addresses may be the origin of MPR 149 election and flooding corruption, which may induce errors in packet 150 delivery, particularly the MAD packets. Consequently, we need first 151 to ensure the MPR election from those conflictual situations. We 152 propose two algorithms to achieve this task: 154 1 In first algorithm, we suggest to ignore the MPR mechanism for 155 the first hop, and relay each originated MAD message by all 156 the neighbors to the 2-hop neighbors. In this manner possible 157 address conflict could be detected and resolved. The direct 158 consequence is that the MPR set will be fixed. 160 2 In the second one, we propose to modify the OLSR Hello mes- 161 sages and the MPR election algorithm. The calculation will be 162 based on the address and the node identifier to guarantee the 163 uniqueness of the direct neighbors and the 2-hop neighbors. 164 This leads to a correct MPR set, hence,we are sure that the 165 MAD messages reach all the nodes. 167 In the sequel we first present the MAD message used to detect the 168 address conflict. Then, we introduce the two proposed DAD algorithms 169 tailored for OLSR protocol. And, finally we give some address 170 assignment and conflict resolution issues. 172 4. Duplicate address detection and MAD message description 174 In order to detect address conflicts, each node diffuses periodically 175 a special message that we call a MAD for ``Multiple Address Declara- 176 tion'' to the entire network[5]. This control packet includes the 177 node addresses and the node identifier. The node identifier is a 178 sequence of bits of fixed length L which is randomly generated. 179 Hence we are using the standard idea that the probability of two 180 nodes having the same node identifier is low, and the probability of 181 at least one address collision with N nodes, which is the well known 182 ``birthday problem'', can be set arbitrarily low by choosing a large 183 enough value of L (eight bytes are enough to code the random identi- 184 fier if we consider a network with a maximum of 10000 nodes [4]). 185 The MAD message format is depicted in the following figure. 187 0 1 2 3 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | Originator node identifier | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | OLSR Interface Address | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | OLSR Interface Address | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | ... | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 A node detects an address conflict when it receives an MAD message 202 having the same address as its own, but with a different identifier. 203 These situations may happen during network mergers. Actually other 204 nodes will detect the conflict. These nodes could announce the con- 205 flict using a special control message. However this approach may 206 induce broadcast storm since many nodes may announce the conflict and 207 special care must be taken to avoid this effect. For that reason we 208 do not recommend this way. An efficient manner to notify the address 209 duplication to the nodes in conflict, consists in allowing the MAD 210 packets to reach all the nodes in the network. To save the channel 211 bandwidth the MAD packets should be broadcasted using the MPR 212 flooding. Actually, applying OLSR relaying optimization rules as 213 they are defined, may not be sufficient to ensure diffusion in some 214 conflictual cases. 216 5. Duplicate Address Detection mechanism 218 Duplicate addresses are detected by the periodic exchange of MAD mes- 219 sages. We propose two different algorithms to ensure the delivery of 220 these messages to the participants in the network in order to dis- 221 cover these conflicts. The first one suggests to modify the MPR 222 flooding rules for MAD messages diffusion. Where in the second one, 223 we propose to modify the OLSR MPR election, which is done on the 224 basis of the node identifier and address interface. This guarantee 225 correct MPR sets, that cover the 2-hop neighbors even in the presence 226 of duplicate addresses. 228 5.1. First algorithm 230 In this first approach we will add rules to the OLSR MPR flooding. 232 5.1.1. First rule 234 The property that we will add is actually extremely simple. We 235 weaken the relaying condition for nodes who are in the 2-hop neigh- 236 borhood of a node who is sending an MAD message. When these neighbor 237 nodes receive an MAD message, they must relay the MAD message irre- 238 spectively of the relaying conditions of the OLSR MPR flooding algo- 239 rithm. We call this first rule, rule 1. 241 5.1.2. Second rule 243 When a node receives an MAD message from a neighbor node with a given 244 IP address and a given Node-ID, and another MAD message with the same 245 address but with a different Node-ID, it must relay this latter MAD 246 message irrespectively of the MPR flooding rules. We call this sec- 247 ond rule, rule 2. 249 5.1.3. Full algorithm 250 Let us recall the assumptions here. 252 Each node A periodically sends a message M including: 254 1 The originator address of A, Orig_A, in the OLSR message 255 header. 257 2 The message sequence number, mssn, in the OLSR message header. 259 3 The node identifier ID_A (a string of bits) in the message 260 itself. 262 The message is propagated by MPR flooding to the other nodes ; but 263 for DAD-MPR Flooding, the duplicate table of OLSR is modified, so 264 that it also includes the node identifier list in the duplicate 265 tuple. That is, a duplicate tuple, includes the following informa- 266 tion: 268 1 The originator address (as in OLSR standard duplicate table). 270 2 The message sequence number (as in OLSR standard duplicate ta- 271 ble). 273 3 The list of node identifiers. 275 The detailed algorithm for DAD-MPR Flooding is the following: 277 1 When a node receives a message M from node B with originator 278 Orig_A, with message sequence number mssn, and with node iden- 279 tifier ID_A, it performs the following tasks: 281 1.1 If a duplicate tuple exists with the same originator 282 Orig_A, the same message sequence number, and ID_A is in 283 the list of node identifiers, Then, the message is 284 ignored (it has already been processed). The algorithm 285 stops here. 287 1.2 Else one of the following situations occurs : 289 1.2.1 290 A duplicate tuple exists with the same originator 291 Orig_A and the same message sequence number, but 292 ID_A is not in the list of node identifiers: then, a 293 conflict is detected (address Orig_A is duplicated). 294 ID_A is added to the list of node identifiers. 296 1.2.2 297 A duplicate tuple exists with the same originator 298 Orig_A, but with a different message sequence number 299 and ID_A is not in the list of node identifiers: 300 then, a conflict is detected (address Orig_A is 301 duplicated). A duplicate tuple is created with the 302 originator address, message sequence number and list 303 of node identifiers containing only ID_A. 305 1.2.3 306 No duplicate tuple exists. A new one is created 307 with the originator address, message sequence number 308 and list of node identifiers containing only ID_A. 310 1.3 The MAD messages should be relayed if one or more of the 311 following rules are met: 313 1.3.1 314 The node B is the source of the MAD message i.e. it 315 has the originator address Orig_A. 317 1.3.2 318 B had chosen this current receiving node as an MPR. 320 1.3.3 321 One of the conflicting nodes is a neighbor of the 322 node detecting the duplication. In such a case, the 323 TTL value of the MAD message showing the conflict is 324 set to one before its retransmission. This also 325 applies even if the current node has not been 326 selected as an MPR by the previous message sender. 328 5.2. Second algorithm 330 An issue with the previous approach is that the conflicts at 2-hop 331 neighbors must be resolved before one can be sure that the MAD mes- 332 sages are successfully transmitted within the entire network. An 333 ideal property would be that the MAD messages reach all the nodes in 334 the network irrespectively of potential address duplications. This 335 property can be achieved if the MPR flooding continues to work in 336 presence of address duplication. A solution is then to base the 337 selection of MPR not on addresses but on node identifiers. With the 338 assumption that node identifiers are globally unique in the network, 339 one can be sure that there will not be identifier duplications at two 340 hops of a given node and thus the selection of MPRs will be correct. 341 This solution can be simply implemented, the selection of the MPRs 342 must follow the principle defined in the OLSR protocol except that 343 the base for the selection must be the node identifiers i.e. the 344 2-hop coverage must be obtained not on the addresses but on the node 345 identifiers. 347 To be able to do so, hello packets must be modified such that the 348 following information will be given in the hello message : 350 1 the node identifier of the originator node of the hello mes- 351 sage, 353 2 the node identifier of the nodes (actually the node interface 354 addresses ) advertised in the hello messages. The modified 355 Hello message format is specified in the following figure. 357 0 1 2 3 358 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Reserved | Htime | Willingness | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | Originator node identifier | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Link Code | Reserved | Link Message Size | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Neighbor Interface Address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | Neighbor identifier | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 373 | Neighbor Interface Address | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 | Neighbor identifier | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 : . . . : 379 : : 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Link Code | Reserved | Link Message Size | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Neighbor Interface Address | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 | Neighbor identifier | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 388 | Neighbor Interface Address | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | Neighbor identifier | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 : : 394 : : 395 (etc.) 397 The drawback of this mechanism is that it introduces a significant extra 398 overhead. 400 6. Address assignment 402 We have two main ways to allocate an address to a newly arriving 403 node. The first way is to assign this node a random address in the 404 pool of addresses that can be allocated and then to rely on the DAD 405 algorithm to discover potential conflicts. The second way is to ask 406 for the help of a neighbor node. This neighbor will be able to pro- 407 pose to the newly arriving node a configuration address. Since a 408 neighbor node must in principle receive the MAD messages of all nodes 409 in the network, it can maintain a pool of non-affected addresses. A 410 newly arriving node can choose between these two approaches. 412 7. Pool of addresses 414 The pool of addresses could be for local use only. For example, it 415 could be reserved by the IANA authority for local MANET forwarding ( 416 i.e, those addresses must not be forwarded outside the MANET network, 417 nor reached from outside). A second possibility consists in relying 418 on some machines which will announce the prefix to use for address 419 autoconfiguration for this MANET network. These machines could be 420 connected to the internet, and act as gateways. In this case, the 421 addresses may be global addresses, and could be seen from outside. 423 8. Resolution of a conflict 425 When two nodes A1 and A2 are configured with the same IP address and 426 assuming that there is no packet loss, each of these two nodes will 427 receive the MAD message of the other node. Thus the nodes where the 428 conflict lies are bound to discover the conflict. A simple rule to 429 solve this conflict will be: the node in conflict with the smallest 430 identifier changes its address. Since this node knows via the recep- 431 tion of the MAD control messages the already assigned addresses, the 432 new address must be selected at random among the addresses that are 433 believed to be free. 435 9. Security Considerations 437 This memo does not specify any security considerations. 439 10. Authors' Addresses 441 The authors are listed in alphabetical order. 443 Cedric Adjih 444 Project HIPERCOM 445 INRIA Rocquencourt 446 BP 105 447 78153 Le Chesnay Cedex, France 448 Phone: +33 1 3963 5215 449 Email: Cedric.Adjih@inria.fr 451 Saadi Boudjit 452 Project HIPERCOM 453 INRIA Rocquencourt 454 BP 105 455 78153 Le Chesnay Cedex, France 456 Phone: +33 1 3963 5039 457 Email: Saadi.Boudjit@inria.fr 459 Philippe Jacquet 460 Project HIPERCOM 461 INRIA Rocquencourt 462 BP 105 463 78153 Le Chesnay Cedex, France 464 Phone: +33 1 3963 5263 465 Email: Philippe.Jacquet@inria.fr 467 Anis Laouiti 468 Project HIPERCOM 469 INRIA Rocquencourt 470 BP 105 471 78153 Le Chesnay Cedex, France 472 Phone: +33 1 3963 5088 473 Email: Anis.Laouiti@inria.fr 475 Paul Muhlethaler 476 Project HIPERCOM 477 INRIA Rocquencourt 478 BP 105 479 78153 Le Chesnay Cedex, France 480 Phone: +33 1 3963 5278 481 Email: Paul.Muhlethaler@inria.fr 483 11. References 485 [1] R. Droms, Ed.,J. Bound, B. Volz, T. Lemon, C. Perkins, M. Car- 486 ney, ``Dynamic Host Configuration Protocol for IPv6 (DHCPv6)'', 487 IETF RFC 3315, July 2003. 489 [2] S. Thomson, T. Narten, ``IPv6 Stateless Address Autoconfigura- 490 tion'', IETF RFC 2462, December 1998. 492 [3] T. Clausen, Ed., P. Jacquet, Ed., Optimized Link State Routing 493 Protocol. Request for Comments (Experimental) 3626, Internet Engi- 494 neering Task Force, October 2003. 496 [4] S.Boudjit, A. Laouiti, P. Muhlethaler, C. Adjih, "Duplicate 497 address detection and autoconfiguration in OLSR", INRIA Research 498 Report-5475, Jan 2005. 500 [5] A. Laouiti, S. Boudjit, P. Minet and C. Adjih, "OLSR for IPv6 501 networks", Proceedings of Med-Hoc-Net, June 2004,Bodrum, Turkey. 503 12. Full Copyright Statement 505 Copyright(C)The Internet Society (2005). This document is subject to 506 the rights, licenses and restrictions contained in BCP 78, and except 507 as set forth therein, the author retains all his rights. 509 This document and the information contained herein are provided on an 510 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS OR 511 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGI- 512 NEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 513 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 514 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 515 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.