idnits 2.17.1 draft-clausen-olsr-passive-dad-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. ** 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. 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 Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 182 has weird spacing: '... the next H...' -- 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 (1 July 2005) is 6874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 95, but not defined == Unused Reference: '2' is defined on line 339, 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' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Emmanuel Baccelli 3 IETF MANET Working Group Thomas Clausen 4 Expiration: 11 January 2006 Julien Garnier 5 LIX, Ecole Polytechnique, France 6 1 July 2005 8 OLSR Passive Duplicate Address Detection 9 draft-clausen-olsr-passive-dad-00.txt 11 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 38 Abstract 40 This draft discusses ways to perform duplicate address detection with 41 OLSR. Methods using passive detection through OLSR messages 42 monitoring are described and briefly evaluated. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Duplicate Address Detection with OLSR . . . . . . . . . . . . . . 4 50 2.1. Mismatching Neighborhood in a HELLO Message . . . . . . . . . . 5 51 2.2. MPR Selection Abnormality in a HELLO Message . . . . . . . . . 5 52 2.3. Link-State Mismatch in a TC Message . . . . . . . . . . . . . . 5 53 2.4. TC Sequence Number Mismatch . . . . . . . . . . . . . . . . . . 6 54 2.5. Interface Mismatch in an MID Message . . . . . . . . . . . . . 6 55 3. Scope of Passive Mechanisms . . . . . . . . . . . . . . . . . . . 6 56 4. Resolving Duplicate Address Conflicts . . . . . . . . . . . . . . 7 57 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 Usually, duplicate address detection is performed when configuring 66 network interfaces in order to ensure that unique addresses are 67 assigned to each interface in the network. Such mechanisms commonly 68 operate with the premises that a node "intelligently" selects an 69 address which it supposes to be unique, followed by a duplicate 70 address detection cycle, through which it verifies that no other 71 active interfaces on the same network has been or is in the process 72 of being configured with the same address. Even assuming that such a 73 mechanism is present in a MANET, allowing MANET nodes to initially 74 configure their interfaces with addresses unique within the network, 75 additional complications arise: two or more MANETs may merge to form 76 a single network, and a formerly connected MANET may partition. Thus, 77 unless it is ensured that all MANET interfaces are assigned globally 78 unique addresses, addressing conflicts may at any point -- not just 79 during initial network configuration. 81 In this draft, we investigate the task of performing duplicate 82 address detection when otherwise independent OLSR networks merge. We 83 benefit from the information already exchanged by OLSR, and identify 84 a number of mechanisms through which a node may detect a conflict 85 between the address assigned to one of its interfaces, and an address 86 assigned to an interface on another node. The mechanisms proposed 87 are, thus, entirely passive, creating no additional information 88 exchange on the network. 90 1.1. Terminology 92 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [5]. 96 Several references are made to the OLSR terminology -- that was first 97 described and employed in [1]. Among others, this document uses the 98 following terminology: 100 - Node: a device capable of participating in a MANET. 102 - Neighbor Node: A node X is a neighbor node of node Y if node 103 Y can hear node X. 105 - Multipoint Relay (MPR): A node which is selected by its 106 neighbor, node X, to "re-transmit" all the broadcast messages 107 it emits. 109 - HELLO messages: A node performs link sensing (the discovery 110 of its neighborhood) via the periodic exchange of HELLO 111 messages with its neighbors. 113 - TC messages: A node shares link state information with 114 the whole network through sending and receiving TC messsages. 116 - MID messages: In case a node features several OLSR interfaces, 117 it announces this fact to the other nodes in the network with 118 an MID message. 120 1.2. Applicability 122 This draft describes and discusses ways to perform passive duplicate 123 address detection with OLSR. 125 2. Duplicate Address Detection with OLSR 127 In this section, we present different mechanisms through which an 128 OLSR node can detect if an address currently assigned to one of its 129 interfaces is concurrently being used by an interface on another 130 node. We note that none of the mechanisms presented here impose any 131 additional information exchange between nodes beyond what is already 132 performed by OLSR. 134 The duplicate address detection mechanisms are based on inspecting 135 received OLSR control messages, as well as the receiving nodes state, 136 to determine if an address on the receiving node is duplicated else- 137 where in the network. More precisely, a node can inspect a received 138 message to detect (i) if the message appears to have been sent from 139 an interface the receiving node or (ii) if the message contains 140 information about interfaces of the receiving node. In either of 141 these cases, the information contained in the received OLSR message 142 is compared to the state recorded in the receiving node, allowing the 143 receiving node to detect a potential duplicate of one of its 144 addresses. 146 With this in mind, the following subsections will inspect the three 147 main OLSR message types: HELLO, TC and MID-messages. 149 2.1. Mismatching Neighborhood in a HELLO Message 151 With HELLO messages, an OLSR node declares its presence to its neigh- 152 borhood and its view of this neighborhood. Therefore, if a node 153 receives a HELLO message on one of its interfaces, where the HELLO 154 message appears to come from the node itself, a potential address 155 duplication may incur. Since HELLO messages are never forwarded in 156 OLSR, an OLSR node should not receive a copy of a HELLO message with 157 any of its own interface addresses as originator (note that this 158 ignores the situation where a node has two radio interfaces running 159 OLSR on the same channel). Therefore, should a node receive a HELLO 160 message with one of its own interface addresses listed as originator, 161 there's a likely collision: two adjacent nodes may have interfaces 162 configured with the same address. This can be confirmed by inspecting 163 the neighborhood being advertised in the supected HELLO message: this 164 HELLO message will include a neighborhood that is different from the 165 node receiving the HELLO. 167 2.2. MPR Selection Abnormality in a HELLO Message 169 With HELLO messages, a node also announces which neighbors it selects 170 as MPR. Therfore, another intuitive diagnostic on HELLO messages is 171 to consider MPR selection: an MPR node must be selected from among 172 neighbors with which a symmetric link exist. Thus, if a node A has a 173 recorded asymmetric link with node B, and receives a HELLO from node 174 B declaring its selection as MPR, then a conflict exists as indi- 175 cated: a second node A', adjacent to B, has the same address as A. 177 This could, however, be a false conclusion. On establishment of the 178 link between A and B, node A receives a HELLO from B, bringing node A 179 to see the link to B as ASYM. In the next HELLO from node A, node B 180 will see its own address listed and conclude that the link is symmet- 181 ric. Node B may, then, select A as MPR and include this selection in 182 the next HELLO message. In this way, node A will receive an MPR 183 selection from a node with which it has only an asymmetric link, 184 without this being an indication of address conflicts in the network. 186 2.3. Link-State Mismatch in a TC Message 188 With TC Messages, an OLSR node announces local link state to the 189 whole MANET. Thus, if a node A receives a TC message, declaring the 190 address of one of node A's interfaces as MPR selector, the originator 191 of that TC-message must be a direct neighbor of node A. If it is not 192 the case, it may be an indication that the address of node A's inter- 193 face is dupliucated somewhere in the network. 195 2.4. TC Sequence Number Mismatch 197 TC messages feature a sequence number in order indicate how recent 198 the link state information is, and detect duplicates. Therefore if a 199 node A receives a TC message with the address of one of its own 200 interfaces listed as originator address address and with a sequence 201 number very different from the sequence number that node A currently 202 is using, it can be an indication that the address of this interface 203 of node A is concurrently being assigned to another interface in the 204 OLSR network. 206 2.5. Interface Mismatch in an MID Message 208 With an MID message, an OLSR node with multiple interfaces declares 209 its interface configuration to the other nodes in the network. If a 210 node A receives a MID messages, in which the address of one of its 211 own interfaces is listed, the remaining addresses listed in the MID 212 must also belong to node A. Alternatively, if node A, receives an 213 MID-message containing one or more addresses belonging to node A but 214 also listing addresses which do not belong to node A, then at least 215 one address is assigned to more than one node. 217 3. Scope of Passive Mechanisms 219 Passive mechanisms, such as those described in this draft, are based 220 on the monitoring of the control messages of the routing protocol. 221 These aim at detecting anomalies in this traffic, that can hint to 222 possible address collisions. However, this approach has a few short- 223 comings, both in terms of false alarms and in terms undetected dupli- 224 cations. 226 In the rare case of a totally symmetric "mirrored" MANET (A-B-C-D- 227 C'-B'-A'), routing message monitoring may not be sufficient to detect 228 the duplicate addresses. In this case, the duplicate nodes cannot 229 detect the collision with each other since the routing messages pro- 230 duced by the left side of the network are identical to the routing 231 messages produced by the right side of the network (because the 232 topology is symmetric). Sequence number mismatch monitoring may help 233 in this case, but it may also crash the network further, as such mis- 234 matches may invalidate the link state information with each TC trans- 235 mission, alternatively from the right side and the left side of the 236 network. 238 Another example is with the sequence number mechanism. This technique 239 is not completely reliable in order to detect duplicate addresses, as 240 delayed delivery can cause an outdated control message that is 241 received to be possibly wrongly interpreted as a case of address 242 duplication. This category of false alarm is more likely to be caused 243 by TC or MID messages rather than HELLO messages, as they feature 244 only one hop scope, suppressing delays due to forwarding. 246 Such cases challenge the passive approach to DAD. Therefore other 247 techniques maybe employed in addition to passive mechanisms in order 248 to increase the reliability of the DAD. These techniques can be 249 called active, or semi-passive, depending on how much additional 250 overhead is produced by the mechanism. 252 Semi-passive techniques involve deeper analysis of the link state 253 information traffic, such as tracking and processing the history of 254 such traffic, in order to prevent errors. However, these techniques 255 come with much more processing and memory needs, a fact that must be 256 carefully evaluated. 258 Active techniques involve sending specific DAD information or mes- 259 sages, in addition to the routing control overhead. For instance, 260 flooding a neighbor solicitation message is part of such a technique. 261 These can be more efficient than passive waiting, but they neverthe- 262 less come with greater overhead, a fact that must also be carefully 263 evaluated. 265 4. Resolving Duplicate Address Conflicts 267 The purpose of the mechanisms, described in this paper, is to detect 268 when two or more interfaces in the network have been configured with 269 the same address -- that a duplicate address conflict exists in the 270 network. The logical next-step to having detected this situation is 271 to resolve it -- to reconfigure nodes such that each interface par- 272 ticipating in the OLSR network has a network-wide unique address. 274 Resolving a duplicate address conflict is, functionally, orthogonal 275 to detecting a duplicate address conflict and, depending on the 276 specificities of the network, different mechanisms can be employed. 277 In this section, we briefly outline a few general approaches to 278 resolving duplicate address conflict. The objective, however, 279 remains to remove conflicting interfaces from the OLSR network, while 280 disrupting the network operation as little as possible. 282 The simplest solution, once a duplicate address conflict is detected, 283 is for a node to simply disable the local interface(s) which are 284 conflicting. If these interfaces then wish to enter the network 285 again, a new initial autoconfiguration cycle must be initiated. The 286 advantage of this method is its simplicity and fact that no lengthy 287 election procedure must be completed before duplicate address con- 288 flicts are resolved. The disadvantage is, that when a conflict 289 arises, all conflicting interfaces are potentially disabled without 290 consideration to traffic (or even necessity: when two interfaces are 291 conflicting, it suffices to disable one of them, not both). 293 A more elegant class of solutions to resolving a duplicate address 294 conflict would be for the node(s) which detect a conflict to "negoti- 295 ate" which interface should yield -- possibly based on metrics such 296 as active traffic flows for a given interface etc. This negotiation 297 would take form of a broadcast of information (a "CONFLICT" message), 298 containing necessary information for a recipient to decide if it 299 should yield and disable a given interface, or not. 301 5. Authors' Addresses 303 Thomas Heide Clausen, 304 Project PCRI 305 Pole Commun de Recherche en Informatique du plateau de Saclay, 306 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 307 Ecole polytechnique, 308 Laboratoire d'informatique, 309 91128 Palaiseau Cedex, France 310 Phone: +33 1 69 33 40 73, 311 Email: T.Clausen@computer.org 313 Emmanuel Baccelli 314 HITACHI Labs Europe/ Project PCRI, 315 Pole Commun de Recherche en Informatique du plateau de Saclay, 316 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 317 Ecole polytechnique, 318 Laboratoire d'informatique, 319 91128 Palaiseau Cedex, France 320 Phone: +33 1 69 33 40 73, 321 Email: Emmanuel.Baccelli@inria.fr 323 Julien Garnier, 324 Project PCRI 325 Pole Commun de Recherche en Informatique du plateau de Saclay, 326 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 327 Ecole polytechnique, 328 Laboratoire d'informatique, 329 91128 Palaiseau Cedex, France 330 Phone: +33 1 69 33 40 73, 331 Email: Julien.Garnier@polytechnique.fr 333 6. References 335 [1] T. Clausen, P. Jacquet, ``RFC 3626: Optimized Link State Routing 336 Protocol," Request for Comments (Experimental), Internet Engineer- 337 ing Task Force, October 2003. 339 [2] E. Baccelli, T. Clausen, J. Garnier, ``Duplicate Address Detection 340 in OLSR Networks," WPMC Proceedings, September 2005. 342 7. Changes 344 This is the initial version of this specification. 346 8. IANA Considerations 348 This document does currently not specify IANA considerations. 350 9. Security Considerations 352 This document does not specify any security considerations. 354 10. Copyright 356 Copyright (C) The Internet Society (2004). This document is subject 357 to the rights, licenses and restrictions contained in BCP 78, and 358 except as set forth therein, the authors retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 365 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 366 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.