idnits 2.17.1 draft-clausen-manet-address-autoconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (31 January 2005) is 7024 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) == Unused Reference: '2' is defined on line 482, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 487, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 491, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 510, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-03 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-02 -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Clausen 3 IETF MANET Working Group Emmanuel Baccelli 4 Expiration: 31 July 2005 LIX, Ecole Polytechnique, France 5 31 January 2005 7 Simple MANET Address Autoconfiguration 8 draft-clausen-manet-address-autoconf-00.txt 10 Status of this Memo 12 This document is a submission to the Network Mobility Working Group 13 of the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the nemo@ietf.org mailing list. 16 Distribution of this memo is unlimited. 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 or will be disclosed, and any of which I become aware will be 21 disclosed, in accordance with RFC 3668. 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC 2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 In this draft, a simple autoconfiguration mechanism for MANETs is 44 developed. The mechanism aims at solving the simple, but common, 45 problem of one or more new nodes emerging in an existing network. A 46 solution is proposed, which allows these new nodes to acquire an 47 address and participate in the network. The method is simple, both 48 algorithmically and in the requirements to the network. While this is 49 a partial solution to the general autoconfiguration problem, the 50 mechanism described in this draft can satisfy the requirements for a 51 great number of real-world situations. Though examples are given with 52 OLSR [1] [11] being the routing protocol in use, nothing prevents the 53 described mechanisms to work along with other routing protocols. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Simple Address Autoconfiguration Solution Overview . . . . . . . 6 62 4. Local Beaconing . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Aquireing a Local Address . . . . . . . . . . . . . . . . . . . . 9 64 6. Global Address Assignment . . . . . . . . . . . . . . . . . . . . 10 65 7. Overhead Estimation . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 72 14. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are 76 able to connect on a wireless medium forming an arbitrary and dynamic 77 network, routing traffic through multi-hop-paths in order to ensure 78 connectivity between any two nodes in the network. Implicitly herein 79 is the ability for the network topology to change over time as links 80 in the network appear and disappear. 82 In order to enable communication between any two nodes in such a 83 MANET, a routing protocol is employed. The abstract task of the rout- 84 ing protocol is to discover the topology (and, as the the network is 85 dynamic, continuing changes to the topology) to ensure that each node 86 is able to acquire a recent image of the network topology for con- 87 structing routes. 89 An issue, complementary to that of routing, emerges with respect to 90 bootstrapping of the network. Routing protocols accomplish the task 91 of discovering paths in a MANET, however a prerequisite to the cor- 92 rect functioning of routing protocols is that all nodes are identifi- 93 able by an unique IP-address. Subsequently, a mechanism for assigning 94 (unique) addresses to MANET nodes is required. 96 A particularity of MANETs is, that the roles of ``terminal'' and 97 ``network forming node'' (router) are not clearly separate. In prin- 98 ciple, all nodes may act in both capacities simultaneously. An addi- 99 tional constraint is, that no assumptions with respect to a preexist- 100 ing infrastructure can be made. Traditional mechanisms for host auto- 101 configuration, such as DHCP [7] or ZeroConf [10] or similar mecha- 102 nisms all assume the presence of a ``server'', which can coordinate 103 and assign addresses. Further, these mechanisms work on the assump- 104 tion that direct communication between the ``server'' and all hosts 105 in the local network is possible. Due to the multi-hop nature of 106 MANETs, direct communication between an arbitrary host in the network 107 and (any) server cannot be assumed. 109 In order to ensure the true autonomy of MANETs, a specific mechanism 110 -- or adaptation of mechanism -- for address autoconfiguration of 111 MANETs is required. Such a mechanism is described in the following. 113 1.1. Terminology 115 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC2119 [5]. 119 Several references are made to the OLSR terminology as described and 120 employed in [1]. This document uses the following terminology: 122 - Node: a device capable of participating in a MANET. 124 - Neighbor Node: A node X is a neighbor node of node Y if node 125 Y can hear node X. 127 - Multipoint Relay (MPR): A node which is selected by its 128 neighbor, node X, to "re-transmit" all the broadcast messages 129 that it receives from X, provided that the message is not a 130 duplicate, and that the time to live field of the message is 131 greater than one. 133 - Hello Messages: An OLSR node periodically broadcasts a Hello 134 Message listing its neighbors. These messages are not for- 135 warded, and serve the purpose of local neighborhood discovery 136 and maintenance, as well as setting up Multipoint Relays. 138 - TC Messages: An OLSR node periodically broadcasts a TC Mes- 139 sage listing its neighborhood link status. These messages are 140 forwarded throughout the MANET, using MPR flooding, and serve 141 the purpose of MANET topology discovery and maintenance. 143 1.2. Applicability 145 This document describes a simple address autoconfiguration mechanism 146 aiming at solving a number of real-world situations with one or more 147 new nodes emerging in an existing network. It is assumed that either 148 at least one node in the network (typically, this might be a node 149 providing Internet connectivity) is already configured or that, 150 absent a previously configured node, an election can be undertaken to 151 allow one node to self-configure and thereby initiate a network-wide 152 autoconfiguration as described in this specification. 154 Even though examples are given with OSLR [1] [11] being the routing 155 protocol in use, nothing prevents the described mechanism to work 156 along with other routing protocols. 158 2. Problem Statement 160 The issue of autoconfiguration in MANETs is complex since, for a com- 161 plete solution, issues such as ensuring uniqueness of addresses in 162 independent MANETs which later merge, must be addressed: independent 163 MANET must somehow select non-overlapping address-spaces, duplicate 164 address detection, conflict resolution -- and the issue of how to 165 deal with ongoing data streams without loosing data or the require- 166 ment of specific application behavior. 168 In this draft, we aim for a simple solution to a simple problem: the 169 connected case. A common situation occurs, in which an efficient and 170 simple address autoconfiguration mechanism is desirable and suffi- 171 cient. This situation is, where a MANET acts as an edge-extension to 172 the Internet. I.e., nodes are interested in maintaining connection to 173 each other and to the Internet. The implication is also, that nodes 174 join or leave the MANET, but do not migrate (alone or in groups) 175 between different MANETs with the expectation of maintaining connec- 176 tivity. The topic of nodes migrating between different MANETs may 177 better be addressed through mechanisms such as NEMO [6]. 179 The mechanism, developed in this draft, is therefore targeted explic- 180 itly at the connected case described above. While this is a particu- 181 lar solution to a particular problem, there is indeed a need to 182 develop a simple and light-weight mechanism efficient for these 183 stated scenarios. 185 The address autoconfiguration mechanism in this draft is specified as 186 an extension to OLSR [1]. However, nothing prevents the mechanism to 187 be work with other routing protocols as well. 189 3. Simple Address Autoconfiguration Solution Overview 191 This section will outline the functioning of the address autoconfigu- 192 ration mechanism. 194 The following two terms will be used for the remainder of this draft: 195 a "new node" is a node which is not yet assigned an address, and thus 196 not is part of a MANET. An "MANET node" is a node which is assigned 197 an address and which is part of the network. A "configurating node" 198 is an MANET node, which is currently assisting a new node in acquire- 199 ing an address. 201 - MANET nodes behave as specified by the routing protocol in 202 use, say OLSR [1]. Additionally, they emit ADDR_BEACON mes- 203 sages, to signal to new nodes that they may act as configurat- 204 ing nodes. This is detailed in the following section. 206 - New nodes do not participate with the routing protocol in use: 207 for example with OLSR, they do not emit HELLO and TC messages. 208 However they listen for ADDR_BEACON messages. 210 - From among the MANET nodes emitting ADDR_BEACON messages, one 211 configurating node is selected, and a request for address con- 212 figuration is issued through an ADDR_CONFIG message. The goal 213 is for the configurating node to provide the new node with 214 first a temporary local address, then a permanent global 215 address. 217 This process of acquiring a local, temporary address, and the task of 218 acquiring a global address are detailed in the following sections. 219 Packet formats are proposed in the case of OLSR. 221 4. Local Beaconing 223 Each MANET node, must ensure that it has the ability to provide tem- 224 porary addresses from a private address space to new nodes. It is 225 important that, within a region, these temporary addresses are 226 unique, i.e. that no two new nodes within the same neighborhood are 227 assigned the same temporary address. In order to ensure this, a pre- 228 defined address space is allocated to use for ``temporary 229 addresses''. The task is to ensure that this address space is 230 divided, without overlap, between nodes in a region of the network: 232 - Each MANET node will, independently, select a continuous 233 address sequence from the address space allocated for ``tempo- 234 rary addresses''. 236 - Each MANET node will signal, with periodic ADDR_BEACON mes- 237 sages, this selected sequence. ADDR_BEACON messages are trans- 238 mitted to neighbor nodes only, i.e. are not forwarded. 240 - Each node will record the address sequences, selected by all 241 its neighbor nodes. 243 If, upon receiving an ADDR_BEACON message, a node detects that there is 244 a conflicting address sequence selection, arbitration must happen. In 245 this case: 247 - If no nodes in the conflict are acting as configurating nodes, 248 arbitration is carried out simply by having the conflicting 249 node with the lowest ID (IP-address) select a new, unused 250 address-sequence. 252 - If one or more conflicting nodes are acting as configurating 253 node(s), arbitration must aim at allowing ongoing configura- 254 tion sessions to complete. 256 In order to accommodate this, all configuration nodes ``narrow'' their 257 selected address-sequence to contain only the address(es) which are cur- 258 rently assigned to new nodes. This is included in the next ADDR_BEACON. 259 Nodes which are not currently acting as configuration nodes, select non- 260 conflicting address sequences. If a conflict between two configurating 261 nodes remains, the node which has the lowest ID (IP address) must yield. 263 If OLSR is the routing protocol in use, the ADDR_BEACON message can use 264 the format specified in the following figure. [1] specifies the values 265 of Message Size, Originator Address, Message Sequence Number and Vtime. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | ADDR_BEACON | Vtime | Message Size | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Originator Address | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | 1 | 0 | Message Sequence Number | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Address Sequence Start | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Address Sequence Stop | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 : Currently Used Addresses : 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 In case of ``narrowing down'' the address-sequence to only currently 286 used addresses, the ``Address Sequence Start'' and ``Address Sequence 287 Stop'' are both set to zero. 289 Each node will periodically send ADDR_BEACON messages, listing both its 290 address sequence and the addresses which are currently in use. In case 291 of a conflict, a recipient node can detect if the node with which it is 292 conflicting is active as configurating node. If both nodes are active as 293 configurating nodes, the nodes can detect a conflict in the addresses 294 actually selected. 296 If OLSR is the routing protocol in use, ADDR_BEACON messages are trans- 297 mitted piggybacked in the same OLSR packet as OLSR HELLO messages. 299 5. Aquireing a Local Address 301 The first task of a new node is to associate itself with a MANET 302 node. Thus, the new node listens for ADDR_BEACON messages and selects 303 one ``configurating node''. An ADDR_CONFIG message is then created 304 and transmitted, in order to request address configuration from the 305 selected configurating node. Absent an IP address, the MAC address of 306 the new node must be included, in order to uniquely identify the new 307 node. 309 Upon receiving an ADDR_CONFIG message, the configurating node assigns 310 a local address to the new node, and signals this assignment through 311 another ADDR_CONFIG message. Additionally, the configurating node 312 marks the assigned address as ``used'' in its ADDR_BEACON messages. 314 Upon receiving a local address through an ADDR_CONFIG message, the 315 new node can slowly start participating locally with the routing pro- 316 tocol in use. For example, if OLSR is used, it can start sending 317 HELLO messages, including only the configurating node as neighbor. 318 The goal is to allow the new and configurating node to track each 319 other (i.e. it allows both nodes to ``reset'', should the link disap- 320 pear before a global address was assigned to the new node), while not 321 causing the new node to be advertised to the network. Advertising a 322 node with a non-unique address might lead to data loss, routing loops 323 etc. 325 If a new node does not receive an ADDR_CONFIG reply, it may either 326 (i) retransmit the ADDR_CONFIG to the same configurating node, or 327 (ii) give up and select an alternative configuration node. Absent the 328 local participation of the new node in the routing protocol (i.e. 329 with OLSR, the HELLO message exchange described above) the configu- 330 rating node may (i) retransmit its ADDR_CONFIG reply, or (ii) give 331 up, in which case any temporarilly assigned addresses will be 332 reclaimed. 334 If OLSR is the routing protocol in use, the ADDR_CONFIG message can 335 use the format specified in following figure. [1] specifies the val- 336 ues of Message Size, Originator Address, Message Sequence Number and 337 Vtime. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | ADDR_CONFIG | Vtime | Message Size | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Originator Address | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | 1 | 0 | Message Sequence Number | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Configurating Node Address | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 : MAC Addresses : 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Assigned Local Address | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Assigned Global Address | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 If the ``Assigned Local Address'', ``Assigned Global Address'' and 360 ``Originator Address'' fields are all set to zero, the ADDR_CONFIG 361 message is a request to the ``Configurating Node'' to perform local 362 address assignment. 364 If the ``Assigned Local Address'' is non-zero (i.e. contains an 365 actual address) and ``Originator Address'' is non-zero, but the 366 ``Assigned Global Address'' field is set to zero, the ADDR_CONFIG 367 message is an assignment of a temporary local address. I.e. this is 368 the reply to a new node, generated by a configurating node. 370 The ``Assigned Global Address'' field is discussed in the next sec- 371 tion. 373 6. Global Address Assignment 375 When local participation of the new node in the routing protocol has 376 started (i.e. with OLSR, the HELLO message exchange commences between 377 the new and configurating node), local address assignment is com- 378 pleted, and the task of acquireing a global address can commence. The 379 configurating node is in charge of acting on behalf of the new node, 380 with respect to acquireing this global address. Since the configurat- 381 ing node is already part of the MANET, a multitude of different mech- 382 anisms can be employed. One such mechanism for acquiring a global 383 address would be for the configurating node to act as a modified DHCP 384 proxy [8] and transmit a request to an existing DHCP server in the 385 network. 387 Another option would be to consult the nodes' topology table. This 388 table (in a relatively stable state) contains all destinations (thus 389 addresses) of the network. The configurating node can thus pick a 390 non-used address and assign to the new node. In that case, in order 391 to prevent duplicate address assignment, the configurating node 392 advertises the selected address to the MANET. If a node detects that 393 its address is being re-used, it can signal the conflict to the orig- 394 inator of the ``offending'' advertisement. 396 If OLSR is the routing protocol in use, the configurating node 397 includes the selected address in a few TCs. If a node receives a TC 398 containing its own address (or an address, which the node has claimed 399 for a new node) AND if the originator of the message is not the node 400 itself nor an MPR of the node, a duplicate address assignment is 401 detected. The detecting node can then communicate this to the origi- 402 nator of the offending TC, with the purpose of resolving the con- 403 flict. 405 Once the configurating node has acquired a globally unique address, 406 it is assigned to the new node through an ADDR_CONFIG message, con- 407 taining the same ``Assigned Local Address'' and ``Originator 408 Address'' as before, but with a non-zero address in the ``Assigned 409 Global Address'' field. This is then the ticket for the new node to 410 participate fully in the MANET. 412 The configurating node will continue to transmit this ADDR_CONFIG 413 message periodically until it detects that the new node has taken it 414 into account. With OLSR, thw configurating node can detect this 415 either when the HELLO messages from the new node's assigned local 416 address cease, or when an ADDR_CONFIG message from the new node is 417 received, listing the new nodes global address in both the originator 418 field and the ``Assigned Global Address'' field, the ``Assigned Local 419 Address'' and the ``MAC address'' fields. 421 7. Overhead Estimation 423 The overhead incurring from the mechanism specified in this draft 424 comes from primarily three sources: (i) periodic beaconing of 425 ADDR_BEACON messages, (ii) address request/replies through ADDRmes- 426 sages, and (iii) discovery of a globally unique address. 428 ADDR_BEACON messages and ADDR_CONFIG messages are local, i.e. no 429 flooding operations incur. ADDR_CONFIG messages are furthermore only 430 transmitted while nodes are being configured, and are of limited size 431 (24 bytes + size of MAC address). Each configuration cycle incurs 4 432 messages. The overall overhead, incurred through this procedure, is 433 therfore negligible. 435 With OLSR, ADDR_BEACON messages are transmitted in the same OLSR 436 packets as OLSR HELLO messages (MTU permitting), thus the number of 437 transmissions required remains constant as compared to OLSR. Except 438 when an node configuration is ongoing, the additional overhead 439 incurred from ADDR_BEACON amounts to 20 bytes. 441 on the other hand, the discovery of a globally unique message depends 442 on the mechanism employed. Assuming a decentralized mechanism, where 443 an unused address is picked from the topology table and is probed 444 through including this address in a TC emission, the additional over- 445 head per TC message for that node is 4 bytes. This is offset by the 446 fact that if an address is assigned to the new node, topological 447 information is already present in the network, allowing the node 448 immediate participation. 450 8. Acknowledgements 452 The authors would like to thank Hitachi Labs Europe for their support. 454 9. Authors' Addresses 456 Thomas Heide Clausen, 457 Project PCRI 458 Pole Commun de Recherche en Informatique du plateau de Saclay, 459 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 460 Ecole polytechnique, 461 Laboratoire d'informatique, 462 91128 Palaiseau Cedex, France 463 Phone: +33 1 69 33 40 73, 464 Email: T.Clausen@computer.org 466 Emmanuel Baccelli 467 HITACHI Labs Europe/ Project PCRI, 468 Pole Commun de Recherche en Informatique du plateau de Saclay, 469 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 470 Ecole polytechnique, 471 Laboratoire d'informatique, 472 91128 Palaiseau Cedex, France 473 Phone: +33 1 69 33 40 73, 474 Email: Emmanuel.Baccelli@inria.fr 476 10. References 478 [1] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol. 479 Request for Comments (Experimental) 3626, Internet Engineering Task 480 Force, October 2003. 482 [2] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized 483 Link State Routing Protocol - Evaluation Through Experiments and 484 Simulation. Proceedings of the Fourth Wireless Personal Multimedia 485 Communications, September 2001. 487 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev- 488 els. Request for Comments (Best Current Practice) 2119, Internet 489 Engineering Task Force, March 1997. 491 [4] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net- 492 works (work in progress). Internet Draft (draft-wakikawa-manet- 493 globalv6-03.txt), Internet Engineering Task Force, October 2003. 495 [5] T. Clausen, P. Jacquet, L. Viennot, Comparative study of routing 496 protocols for mobile ad-hoc networks. Proceedings of IFIP Med-Hoc- 497 Net 2002, September 2002. 499 [6] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo 500 Basic Support Protocol (work in progress). Internet Draft (draft- 501 ietf-nemo-basic-support-02), Internet Engineering Task Force, 502 December 2003. 504 [7] R. Droms, Dynamic host configuration protocol, RFC 2131, Internet 505 Engineering Task Force, March 1997. 507 [8] M. Patrick, Dhcp Relay Agent Information Option, RFC 3046, Internet 508 Engineering Task Force, January 2001. 510 [9] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Efficient 511 Technique for Flooding in Mobile 512 Wireless Networks. INRIA Research Report RR-3898, Project Hiper- 513 com, March 2000. 515 [10] A. Williams, Requirements for Automatic Configuration of IP Hosts. 516 Internet Draft, draft-ietf-zeroconf-reqts-12.txt, September 2002, 517 Work in progress. 519 [11] E. Baccelli, T. Clausen, A Simple Address Autoconfiguration Mecha- 520 nism for OLSR, IEEE International Symposium on Circuits and Sys- 521 tems, ISCAS 2005. 523 11. Changes 525 This is the initial version of this specification. 527 12. IANA Considerations 529 This document does currently not specify IANA considerations. 531 13. Security Considerations 533 This document does not specify any security considerations. 535 14. Copyright 536 Copyright (C) The Internet Society (2004). This document is subject 537 to the rights, licenses and restrictions contained in BCP 78, and 538 except as set forth therein, the authors retain all their rights. 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 545 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 546 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.