idnits 2.17.1 draft-ietf-manet-aodvv2-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Replaying of RREQ or RREP messages would be of less use to an attacker, since they would be dropped immediately due to their stale sequence number. RERR messages MAY or MAY NOT include sequence numbers and are therefore susceptible to replay attacks. RREP_Ack messages do not include sequence numbers and are therefore susceptible to replay attacks. -- The document date (April 20, 2016) is 2922 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Address' is mentioned on line 407, but not defined == Missing Reference: 'MetricType' is mentioned on line 2914, but not defined == Missing Reference: 'OrigAddr' is mentioned on line 2160, but not defined == Missing Reference: 'TargAddr' is mentioned on line 2143, but not defined == Missing Reference: 'TBD' is mentioned on line 2937, but not defined == Missing Reference: 'HopCount' is mentioned on line 2889, but not defined == Unused Reference: 'RFC4291' is defined on line 3472, but no explicit reference was found in the text == Unused Reference: 'RFC5082' is defined on line 3476, but no explicit reference was found in the text == Unused Reference: 'RFC6551' is defined on line 3495, but no explicit reference was found in the text == Unused Reference: 'I-D.perkins-irrep' is defined on line 3508, but no explicit reference was found in the text == Unused Reference: 'Perkins99' is defined on line 3526, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 3547, but no explicit reference was found in the text == Unused Reference: 'RFC5148' is defined on line 3552, but no explicit reference was found in the text == Unused Reference: 'Sholander02' is defined on line 3562, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Experimental S. Ratliff 5 Expires: October 22, 2016 Idirect 6 J. Dowdell 7 Airbus Defence and Space 8 L. Steenbrink 9 HAW Hamburg, Dept. Informatik 10 V. Mercieca 11 Airbus Defence and Space 12 April 20, 2016 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-ietf-manet-aodvv2-15 17 Abstract 19 The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing 20 protocol is intended for use by mobile routers in wireless, multihop 21 networks. AODVv2 determines unicast routes among AODVv2 routers 22 within the network in an on-demand fashion. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 61 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. InterfaceSet . . . . . . . . . . . . . . . . . . . . . . 10 63 4.2. Router Client Set . . . . . . . . . . . . . . . . . . . . 11 64 4.3. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 12 66 4.5. Local Route Set . . . . . . . . . . . . . . . . . . . . . 13 67 4.6. Multicast Route Message Set . . . . . . . . . . . . . . . 15 68 4.7. Route Error (RERR) Set . . . . . . . . . . . . . . . . . 17 69 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 6. AODVv2 Protocol Operations . . . . . . . . . . . . . . . . . 19 71 6.1. Initialization . . . . . . . . . . . . . . . . . . . . . 19 72 6.2. Next Hop Monitoring . . . . . . . . . . . . . . . . . . . 20 73 6.3. Neighbor Set Update . . . . . . . . . . . . . . . . . . . 21 74 6.4. Interaction with the Forwarding Plane . . . . . . . . . . 23 75 6.5. Message Transmission . . . . . . . . . . . . . . . . . . 24 76 6.6. Route Discovery, Retries and Buffering . . . . . . . . . 25 77 6.7. Processing Received Route Information . . . . . . . . . . 26 78 6.7.1. Evaluating Route Information . . . . . . . . . . . . 27 79 6.7.2. Applying Route Updates . . . . . . . . . . . . . . . 29 80 6.8. Suppressing Redundant Messages Using the Multicast Route 81 Message Set . . . . . . . . . . . . . . . . . . . . . . . 31 82 6.9. Suppressing Redundant Route Error Messages using the 83 Route Error Set . . . . . . . . . . . . . . . . . . . . . 33 84 6.10. Local Route Set Maintenance . . . . . . . . . . . . . . . 34 85 6.10.1. LocalRoute State Changes . . . . . . . . . . . . . . 34 86 6.10.2. Reporting Invalid Routes . . . . . . . . . . . . . . 36 87 7. AODVv2 Protocol Messages . . . . . . . . . . . . . . . . . . 36 88 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . 37 89 7.1.1. RREQ Generation . . . . . . . . . . . . . . . . . . . 38 90 7.1.2. RREQ Reception . . . . . . . . . . . . . . . . . . . 39 91 7.1.3. RREQ Regeneration . . . . . . . . . . . . . . . . . . 40 92 7.2. Route Reply (RREP) Message . . . . . . . . . . . . . . . 41 93 7.2.1. RREP Generation . . . . . . . . . . . . . . . . . . . 42 94 7.2.2. RREP Reception . . . . . . . . . . . . . . . . . . . 44 95 7.2.3. RREP Regeneration . . . . . . . . . . . . . . . . . . 45 96 7.3. Route Reply Acknowledgement (RREP_Ack) Message . . . . . 46 97 7.3.1. RREP_Ack Generation . . . . . . . . . . . . . . . . . 46 98 7.3.2. RREP_Ack Reception . . . . . . . . . . . . . . . . . 46 99 7.4. Route Error (RERR) Message . . . . . . . . . . . . . . . 47 100 7.4.1. RERR Generation . . . . . . . . . . . . . . . . . . . 48 101 7.4.2. RERR Reception . . . . . . . . . . . . . . . . . . . 49 102 7.4.3. RERR Regeneration . . . . . . . . . . . . . . . . . . 51 103 8. RFC 5444 Representation . . . . . . . . . . . . . . . . . . . 51 104 8.1. Route Request Message Representation . . . . . . . . . . 53 105 8.1.1. Message Header . . . . . . . . . . . . . . . . . . . 53 106 8.1.2. Message TLV Block . . . . . . . . . . . . . . . . . . 53 107 8.1.3. Address Block . . . . . . . . . . . . . . . . . . . . 53 108 8.1.4. Address Block TLV Block . . . . . . . . . . . . . . . 53 109 8.2. Route Reply Message Representation . . . . . . . . . . . 54 110 8.2.1. Message Header . . . . . . . . . . . . . . . . . . . 54 111 8.2.2. Message TLV Block . . . . . . . . . . . . . . . . . . 54 112 8.2.3. Address Block . . . . . . . . . . . . . . . . . . . . 55 113 8.2.4. Address Block TLV Block . . . . . . . . . . . . . . . 55 114 8.3. Route Reply Acknowledgement Message Representation . . . 56 115 8.3.1. Message Header . . . . . . . . . . . . . . . . . . . 56 116 8.3.2. Message TLV Block . . . . . . . . . . . . . . . . . . 56 117 8.3.3. Address Block . . . . . . . . . . . . . . . . . . . . 56 118 8.3.4. Address Block TLV Block . . . . . . . . . . . . . . . 57 119 8.4. Route Error Message Representation . . . . . . . . . . . 57 120 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 57 121 8.4.2. Message TLV Block . . . . . . . . . . . . . . . . . . 57 122 8.4.3. Address Block . . . . . . . . . . . . . . . . . . . . 57 123 8.4.4. Address Block TLV Block . . . . . . . . . . . . . . . 58 124 9. Simple External Network Attachment . . . . . . . . . . . . . 58 125 10. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 59 126 10.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 60 127 10.2. Protocol Constants . . . . . . . . . . . . . . . . . . . 62 128 10.3. Local Settings . . . . . . . . . . . . . . . . . . . . . 63 129 10.4. Network-Wide Settings . . . . . . . . . . . . . . . . . 63 130 10.5. MetricType Allocation . . . . . . . . . . . . . . . . . 63 131 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 132 11.1. RFC 5444 Message Types . . . . . . . . . . . . . . . . . 64 133 11.2. RFC 5444 Address Block TLV Types . . . . . . . . . . . . 64 134 11.3. ADDRESS_TYPE TLV Values . . . . . . . . . . . . . . . . 65 135 12. Security Considerations . . . . . . . . . . . . . . . . . . . 65 136 12.1. Availability . . . . . . . . . . . . . . . . . . . . . . 66 137 12.1.1. Denial of Service . . . . . . . . . . . . . . . . . 66 138 12.1.2. Malicious RERR messages . . . . . . . . . . . . . . 67 139 12.1.3. False Confirmation of Link Bidirectionality . . . . 68 140 12.1.4. Message Deletion . . . . . . . . . . . . . . . . . . 68 141 12.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 69 142 12.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . 69 143 12.3.1. Message Insertion . . . . . . . . . . . . . . . . . 69 144 12.3.2. Message Modification - Man in the Middle . . . . . . 70 145 12.3.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 70 146 12.4. Protection Mechanisms . . . . . . . . . . . . . . . . . 71 147 12.4.1. Confidentiality and Authentication . . . . . . . . . 71 148 12.4.2. Integrity and Trust using ICVs . . . . . . . . . . . 71 149 12.4.3. Replay Protection using Timestamps . . . . . . . . . 71 150 12.4.4. Application to AODVv2 . . . . . . . . . . . . . . . 71 151 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 152 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 153 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 154 14.2. Informative References . . . . . . . . . . . . . . . . . 75 155 Appendix A. AODVv2 Draft Updates . . . . . . . . . . . . . . . . 77 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 158 1. Overview 160 The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol 161 enables dynamic, self-starting, multihop routing between 162 participating mobile nodes wishing to establish and maintain an ad 163 hoc network. The basic operations of the AODVv2 protocol are route 164 discovery and route maintenance. AODVv2 does not require nodes to 165 maintain routes to destinations that are not in active communication. 166 AODVv2 allows mobile nodes to respond to link breakages and changes 167 in network topology in a timely manner. The operation of AODVv2 is 168 loop-free, and by avoiding the Bellman-Ford "counting to infinity" 169 problem offers quick convergence when the ad hoc network topology 170 changes (typically, when a node moves in the network). When links 171 break, AODVv2 causes the affected set of nodes to be notified so that 172 they are able to invalidate the routes using the lost link. 174 One distinguishing feature of AODVv2 is its use of a destination 175 sequence number for each route entry. The destination sequence 176 number is created by the destination to be included along with any 177 route information it sends to requesting nodes. Using destination 178 sequence numbers ensures loop freedom and is simple to program. 179 Given the choice between two routes to a destination, a requesting 180 node is required to select the one with the greatest sequence number. 182 Compared to AODV [RFC3561], AODVv2 has moved some features out of the 183 scope of the document, notably intermediate route replies, expanding 184 ring search, and precursor lists. However, the document has been 185 designed to allow their specification in a separate document. Hello 186 messages and local repair have been removed. AODVv2 provides a 187 mechanism for the use of multiple metric types. Message formats have 188 been updated and made compliant with [RFC5444]. AODVv2 control 189 messages are defined as sets of data, which are mapped to message 190 elements using the Generalized MANET Packet/Message Format defined in 191 [RFC5444] and sent using the parameters in [RFC5498]. Verification 192 of link bidirectionality has been substantially improved, and 193 additional refinements made for route timeouts and state management. 195 AODVv2 is an Experimental protocol. The purpose of the experiment 196 with AODVv2 is to gain information on the behavior of the protocol in 197 real-world deployments, furthering the knowledge base of both 198 reactive protocols in general, and with AODVv2 in particular. 199 Another goal of the experiment is to determine if sufficient demand 200 exists for the AODVv2 protocol to prompt an effort to bring the 201 protocol to Standards Track. 203 The basic operations of the AODVv2 protocol are route discovery and 204 route maintenance. 206 An AODVv2 router is configured to perform route discovery on behalf 207 of a configured set of IP addresses known as Router Clients. Route 208 discovery is performed when an AODVv2 router needs to forward an IP 209 packet from one of its Router Clients, but does not have a valid 210 route to the packet's destination. AODVv2 routers use Route Request 211 (RREQ) and Route Reply (RREP) messages to carry route information 212 between the originator of the route discovery and the router 213 responsible for the target, establishing a route to both endpoints on 214 all intermediate routers. A metric value is included to represent 215 the cost of the route contained within the message. AODVv2 uses 216 sequence numbers to identify stale routing information, and compares 217 route metric values to determine if advertised routes could form 218 loops. 220 Route maintenance includes confirming bidirectionality of links to 221 next hop AODVv2 routers, issuing Route Error (RERR) messages, 222 reacting to received Route Error messages, and extending and 223 enforcing route timeouts. 225 The on-demand nature of AODVv2 requires signals to be exchanged 226 between AODVv2 and the forwarding plane. These signals indicate 227 when: a packet is to be forwarded, in order to initiate route 228 discovery; packet forwarding fails, in order to initiate route error 229 reporting; a packet is successfully forwarded, for route maintenance. 231 Security for authentication of AODVv2 routers and encryption of 232 control messages is accomplished using the TIMESTAMP and ICV TLVs 233 defined in [RFC7182]. 235 2. Terminology 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in 241 [RFC2119]. In addition, this document uses terminology from 242 [RFC5444], and defines the following terms: 244 AddressList 245 A list of IP addresses as used in AODVv2 messages. 247 AckReq 248 Used in a Route Reply message to indicate the IP address of the 249 router from which a Route Reply Acknowledgement is expected. 251 AdvRte 252 A route advertised in an incoming route message. 254 AODVv2 Router 255 An IP addressable device in the ad hoc network that performs the 256 AODVv2 protocol operations specified in this document. 258 CurrentTime 259 The current time as maintained by the AODVv2 router. 261 ENAR (External Network Access Router) 262 An AODVv2 router with an interface to an external, non-AODVv2 263 network. 265 InterfaceSet 266 The set of all network interfaces supporting AODVv2. 268 Invalid route 269 A route that cannot be used for forwarding but still contains 270 useful sequence number information. 272 LocalRoute 273 An entry in the Local Route Set as defined in Section 4.5. 275 MANET 276 A Mobile Ad Hoc Network as defined in [RFC2501]. 278 MetricType 279 The metric type for a metric value included in a message. 281 MetricTypeList 282 A list of metric types associated with the addresses in the 283 AddressList of a Route Error message. 285 Neighbor 286 An AODVv2 router from which an RREQ or RREP message has been 287 received. Neighbors exchange routing information and verify 288 bidirectionality of the link to a neighbor before installing a 289 route via that neighbor into the Local Route Set. 291 OrigAddr 292 The source IP address of the IP packet triggering route discovery. 294 OrigMetric 295 The metric value associated with the route to OrigAddr (and any 296 other addresses included in the given prefix length). 298 OrigPrefixLen 299 The prefix length, in bits, configured in the Router Client entry 300 which includes OrigAddr. 302 OrigSeqNum 303 The sequence number of the AODVv2 router which originated the 304 Route Request on behalf of OrigAddr. 306 PktSource 307 The source address of the IP packet which triggered a Route Error 308 message. 310 PrefixLengthList 311 A list of routing prefix lengths associated with the addresses in 312 the AddressList of a message. 314 Reactive 315 Performed only in reaction to specific events. In AODVv2, routes 316 are requested only when data packets need to be forwarded. In 317 this document, "reactive" is synonymous with "on-demand". 319 RERR (Route Error) 320 The AODVv2 message type used to indicate that an AODVv2 router 321 does not have a valid LocalRoute toward one or more particular 322 destinations. 324 RERR_Gen (RERR Generating Router) 325 The AODVv2 router generating a Route Error message. 327 RerrMsg (RERR Message) 328 A Route Error (RERR) message. 330 Routable Unicast IP Address 331 A routable unicast IP address is a unicast IP address that is 332 scoped sufficiently to be forwarded by a router. Globally-scoped 333 unicast IP addresses and Unique Local Addresses (ULAs) [RFC4193] 334 are examples of routable unicast IP addresses. 336 Router Client 337 An address or address range configured on an AODVv2 router, on 338 behalf of which that router will initiate and respond to route 339 discoveries. These addresses may be used by the AODVv2 router 340 itself or by non-routing devices that are reachable without 341 traversing another AODVv2 router. 343 RREP (Route Reply) 344 The AODVv2 message type used to reply to a Route Request message. 346 RREP_Gen (RREP Generating Router) 347 The AODVv2 router that generates the Route Reply message, i.e., 348 the router configured with TargAddr as a Router Client. 350 RREQ (Route Request) 351 The AODVv2 message type used to discover a route to TargAddr and 352 distribute information about a route to OrigAddr. 354 RREQ_Gen (RREQ Generating Router) 355 The AODVv2 router that generates the Route Request message, i.e., 356 the router configured with OrigAddr as a Router Client. 358 RteMsg (Route Message) 359 A Route Request (RREQ) or Route Reply (RREP) message. 361 SeqNum 362 The sequence number maintained by an AODVv2 router to indicate 363 freshness of route information. 365 SeqNumList 366 A list of sequence numbers associated with the addresses in the 367 AddressList of a message. 369 TargAddr 370 The target address of a route request, i.e., the destination 371 address of the IP packet triggering route discovery. 373 TargMetric 374 The metric value associated with the route to TargAddr (and any 375 other addresses included in the given prefix length). 377 TargPrefixLen 378 The prefix length, in bits, configured in the Router Client entry 379 which includes TargAddr. 381 TargSeqNum 382 The sequence number of the AODVv2 router which originated the 383 Route Reply on behalf of TargAddr. 385 Unreachable Address 386 An address reported in a Route Error message, as described in 387 Section 7.4.1. 389 Upstream 390 In the direction from destination to source (from TargAddr to 391 OrigAddr). 393 ValidityTime 394 The length of time the route described by the message is offered. 396 Valid route 397 A route that can be used for forwarding, as described in 398 Section 7.4.1. 400 This document uses the notational conventions in Table 1 to simplify 401 the text. 403 +-----------------------+------------------------------------+ 404 | Notation | Meaning | 405 +-----------------------+------------------------------------+ 406 | Route[Address] | A route toward Address | 407 | Route[Address].Field | A field in a route toward Address | 408 | RteMsg.Field | A field in either RREQ or RREP | 409 +-----------------------+------------------------------------+ 411 Table 1: Notational Conventions 413 3. Applicability Statement 415 The AODVv2 routing protocol is a reactive routing protocol intended 416 for use in mobile ad hoc wireless networks. A reactive protocol only 417 sends messages to discover a route when there is data to send on that 418 route. Therefore, a reactive routing protocol requires certain 419 interactions with the forwarding plane (for example, to indicate when 420 a packet is to be forwarded, in order to initiate route discovery). 421 The set of signals exchanged between AODVv2 and the forwarding plane 422 are discussed in Section 6.4. 424 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 425 i.e., non-transit networks or those not connected to the internet. 426 AODVv2 can, however, be configured to perform gateway functions when 427 attached to external networks, as discussed in Section 9. 429 AODVv2 handles a wide variety of mobility and traffic patterns by 430 determining routes on-demand. In networks with a large number of 431 routers, AODVv2 is best suited for relatively sparse traffic 432 scenarios where each router forwards IP packets to a small percentage 433 of other AODVv2 routers in the network. In this case fewer routes 434 are needed, and therefore less control traffic is produced. Data 435 packets may be buffered until a route to their destination is 436 available, as described in Section 6.6. 438 AODVv2 provides for message integrity and security against replay 439 attacks by using integrity check values, timestamps and sequence 440 numbers, as described in Section 12. If security associations can be 441 established, encryption can be used for AODVv2 messages to ensure 442 that only trusted routers participate in routing operations. 444 Since the route discovery process aims for a route to be established 445 in both directions along the same path, uni-directional links are not 446 suitable. AODVv2 will detect and exclude those links from route 447 discovery. The route discovered is optimised for the requesting 448 router, and the return path may not be the optimal route. 450 AODVv2 is applicable to memory constrained devices, since only a 451 little routing state is maintained in each AODVv2 router. AODVv2 452 routes that are not needed for forwarding data do not need to be 453 maintained. On routers unable to store persistent AODVv2 state, 454 recovery can impose a performance penalty (e.g., in case of AODVv2 455 router reboot), since if a router loses its sequence number, there is 456 a delay before the router can resume full operations. This is 457 described in Section 6.1. 459 AODVv2 supports routers with multiple interfaces and multiple IP 460 addresses per interface. A router may also use the same IP address 461 on multiple interfaces. AODVv2 requires only that each interface 462 configured for AODVv2 has at least one unicast IP address. Address 463 assignment procedures are out of scope for AODVv2. 465 AODVv2 supports Router Clients with multiple interfaces, as long as 466 each interface is configured with its own unicast IP address. Multi- 467 homing of a Router Client IP address is not supported by AODVv2, and 468 therefore an IP address SHOULD NOT be configured as a Router Client 469 on more than one AODVv2 router at any one time. 471 The routing algorithm in AODVv2 MAY be operated at layers other than 472 the network layer, using layer-appropriate addresses. 474 4. Data Structures 476 4.1. InterfaceSet 478 The InterfaceSet is a conceptual data structure which contains 479 information about all interfaces available to AODVv2. Each element 480 in the InterfaceSet MUST contain the following: 482 Interface.Id 483 An identifier that is unique in node-local scope and that allows 484 the AODVv2 implementation to identify exactly one local network 485 interface. 487 If multiple interfaces of the AODVv2 router are configured for use by 488 AODVv2, they MUST be configured in the InterfaceSet. 490 Otherwise the InterfaceSet MAY be empty. 492 4.2. Router Client Set 494 An AODVv2 router provides route discovery services for its own local 495 applications and for other non-routing devices that are reachable 496 without traversing another AODVv2 router. The addresses used by 497 these devices, and the AODVv2 router itself, are configured in the 498 Router Client Set. An AODVv2 router will only originate Route Request 499 and Route Reply messages on behalf of configured Router Client 500 addresses. 502 Router Client Set entries MUST contain: 504 RouterClient.IPAddress 505 An IP address or the start of an address range that requires route 506 discovery services from the AODVv2 router. 508 RouterClient.PrefixLength 509 The length, in bits, of the routing prefix associated with the 510 RouterClient.IPAddress. If a prefix length is included, the 511 AODVv2 router MUST provide connectivity for all addresses within 512 that prefix. 514 RouterClient.Cost 515 The cost associated with reaching this address or address range. 517 A Router Client address MUST NOT be served by more than one AODVv2 518 router at any one time. To shift responsibility for a Router Client 519 to a different AODVv2 router, correct AODVv2 routing behavior MUST be 520 observed; The AODVv2 router adding the Router Client MUST wait for 521 any existing routing information about this Router Client to be 522 purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the 523 last SeqNum update on the router which is removing this Router 524 Client. 526 4.3. Neighbor Set 528 A Neighbor Set MUST be maintained with information about neighboring 529 AODVv2 routers. Neighbor Set entries are stored when AODVv2 messages 530 are received. If the Neighbor is chosen as a next hop on an 531 installed route, the link to the Neighbor MUST be tested for 532 bidirectionality and the result stored in this set. A route will 533 only be considered valid when the link is confirmed to be 534 bidirectional. 536 Neighbor Set entries MUST contain: 538 Neighbor.IPAddress 539 An IP address of the neighboring router, learned from the source 540 IP address of a received route message. 542 Neighbor.State 543 Indicates whether the link to the neighbor is bidirectional. 544 There are three possible states: Confirmed, Unknown, and 545 Blacklisted. Unknown is the initial state. Confirmed indicates 546 that the link to the neighbor has been confirmed as bidirectional. 547 Blacklisted indicates that the link to the neighbor is uni- 548 directional. Section 6.2 discusses how to monitor link 549 bidirectionality. 551 Neighbor.ResetTime 552 When the value of Neighbor.State is Blacklisted, this indicates 553 the time at which the value of Neighbor.State will revert to 554 Unknown. By default this value is calculated at the time the 555 router is blacklisted and is equal to CurrentTime + 556 MAX_BLACKLIST_TIME. When the value of Neighbor.State is not 557 Blacklisted, this time is set to INFINITY_TIME. 559 Neighbor.Interface 560 The interface on which the link to the neighbor was established. 562 4.4. Sequence Numbers 564 Sequence numbers enable AODVv2 routers to determine the temporal 565 order of route discovery messages, identifying stale routing 566 information so that it can be discarded. The sequence number 567 fulfills the same roles as the "Destination Sequence Number" of DSDV 568 [Perkins94], and the AODV Sequence Number in [RFC3561]. 570 Each AODVv2 router in the network MUST maintain its own sequence 571 number. All RREQ and RREP messages created by an AODVv2 router 572 include the router's sequence number, reported as a 16-bit unsigned 573 integer. Each AODVv2 router MUST ensure that its sequence number is 574 strictly increasing, and that it is incremented by one (1) whenever 575 an RREQ or RREP is created, except when the sequence number is 65,535 576 (the maximum value of a 16-bit unsigned integer), in which case it 577 MUST be reset to one (1). The value zero (0) is reserved to indicate 578 that the sequence number is unknown. 580 An AODVv2 router MUST only attach its own sequence number to 581 information about a route to one of its configured Router Clients, 582 all route messages regenerated by other routers retain the 583 originator's sequence number. Tod determine staleness, the 584 previously stored sequence number associated with the originator, is 585 subtracted from the incoming sequence number. The result of the 586 subtraction is to be interpreted as a signed 16-bit integer, and if 587 less than zero, the information in the new AODVv2 message is stale 588 and MUST be discarded. 590 This, along with the processes in Section 6.7.1, ensures loop 591 freedom. 593 An AODVv2 router SHOULD maintain its sequence number in persistent 594 storage. If the sequence number is lost, the router MUST follow the 595 procedure in Section 6.1 to safely resume routing operations with a 596 new sequence number. 598 4.5. Local Route Set 600 All AODVv2 routers MUST maintain a Local Route Set, containing 601 information about routes learned from AODVv2 route messages. The 602 Local Route Set is stored separately from the forwarding plane's 603 routing table (referred to as Routing Information Base (RIB)), which 604 may be updated by other routing protocols operating on the AODVv2 605 router as well. The Routing Information Base is updated using 606 information from the Local Route Set. Alternatively, implementations 607 MAY choose to modify the Routing Information Base directly. 609 Routes learned from AODVv2 route messages are referred to in this 610 document as LocalRoutes, and MUST contain the following information: 612 LocalRoute.Address 613 An address, which, when combined with LocalRoute.PrefixLength, 614 describes the set of destination addresses this route includes. 616 LocalRoute.PrefixLength 617 The prefix length, in bits, associated with LocalRoute.Address. 619 LocalRoute.SeqNum 620 The sequence number associated with LocalRoute.Address, obtained 621 from the last route message that successfully updated this entry. 623 LocalRoute.NextHop 624 The source IP address of the IP packet containing the AODVv2 625 message advertising the route to LocalRoute.Address, i.e. an IP 626 address of the AODVv2 router used for the next hop on the path 627 toward LocalRoute.Address. 629 LocalRoute.NextHopInterface 630 The interface used to send IP packets toward LocalRoute.Address. 632 LocalRoute.LastUsed 633 If this route is installed in the Routing Information Base, the 634 time it was last used to forward an IP packet. 636 LocalRoute.LastSeqNumUpdate 637 The time LocalRoute.SeqNum was last updated. 639 LocalRoute.ExpirationTime 640 The time at which this LocalRoute MUST be marked as Invalid. An 641 AODVv2 router MAY be offered a route for a limited time. In this 642 case, the route is referred to as a timed route. If a route is 643 not timed, LocalRoute.ExpirationTime is INFINITY_TIME. 645 LocalRoute.MetricType 646 The type of metric associated with this route. 648 LocalRoute.Metric 649 The cost of the route toward LocalRoute.Address expressed in units 650 consistent with LocalRoute.MetricType. 652 LocalRoute.State 653 The last known state (Unconfirmed, Idle, Active, or Invalid) of 654 the route. 656 There are four possible states for a LocalRoute: 658 Unconfirmed 659 A route learned from a Route Request message, which has not yet 660 been confirmed as bidirectional. It MUST NOT be used for 661 forwarding IP packets, and therefore it is not referred to as a 662 valid route. This state only applies to routes learned through 663 RREQ messages. 665 Idle 666 A route which has been learned from a route message, and has also 667 been confirmed, but has not been used in the last ACTIVE_INTERVAL. 668 It is able to be used for forwarding IP packets, and therefore it 669 is referred to as a valid route. 671 Active 672 A route which has been learned from a route message, and has also 673 been confirmed, and has been used in the last ACTIVE_INTERVAL. It 674 is able to be used for forwarding IP packets, and therefore it is 675 referred to as a valid route. 677 Invalid 678 A route which has expired or been lost. It MUST NOT be used for 679 forwarding IP packets, and therefore it is not referred to as a 680 valid route. Invalid routes contain sequence number information 681 which allows incoming information to be assessed for freshness. 683 When the Local Route Set is stored separately from the Routing 684 Information Base, routes are added to the Routing Information Base 685 when LocalRoute.State is valid (set to Active or Idle), and removed 686 from the Routing Information Base when LocalRoute.State becomes 687 Invalid. 689 Changes to LocalRoute state are detailed in Section 6.10.1. 691 Multiple valid routes for the same address and prefix length but for 692 different metric types may exist in the Local Route Set, but the 693 decision of which of these routes to install in the Routing 694 Information Base to use for forwarding is outside the scope of 695 AODVv2. 697 4.6. Multicast Route Message Set 699 A route message (RteMsg) is either a Route Request or Route Reply 700 message. RREQ messages are multicast by default and regenerated 701 multiple times, and RREP messages will be multicast when the link to 702 the next router is not known to be bidirectional. Multiple similar 703 route messages might be received by any one router during one route 704 discovery attempt. The AODVv2 router does not need to regenerate or 705 respond to every one of these messages. 707 The Multicast Route Message Set is a conceptual set which contains 708 information about previously received multicast route messages, so 709 that incoming route messages can be compared with previously received 710 messages to determine if the incoming information is redundant or 711 stale, and the router can avoid sending redundant control traffic. 713 Multicast Route Message Set entries MUST contain the following 714 information: 716 RteMsg.MessageType 717 Either RREQ or RREP. 719 RteMsg.OrigAddr 720 The source address of the IP packet triggering the route request. 722 RteMsg.OrigPrefixLen 723 The prefix length associated with RteMsg.OrigAddr, originally from 724 the Router Client entry on RREQ_Gen which includes 725 RteMsg.OrigAddr. 727 RteMsg.TargAddr 728 The destination address of the IP packet triggering the route 729 request. 731 RteMsg.TargPrefixLen 732 The prefix length associated with RteMsg.TargAddr, originally from 733 the Router Client entry on RREP_Gen which includes 734 RteMsg.TargAddr. If RteMsg is a RREQ, RteMsg.TargPrefixLen MUST 735 equal address length. 737 RteMsg.OrigSeqNum 738 The sequence number associated with the route to OrigAddr, if 739 RteMsg is an RREQ. 741 RteMsg.TargSeqNum 742 The sequence number associated with the route to TargAddr, if 743 RteMsg is an RREP. 745 RteMsg.MetricType 746 The metric type of the route requested. 748 RteMsg.Metric 749 The metric value received in the RteMsg. 751 RteMsg.Timestamp 752 The last time this Multicast Route Message Set entry was updated. 754 RteMsg.RemoveTime 755 The time at which this entry MUST be removed from the Multicast 756 Route Message Set. This is set to CurrentTime + 757 MAX_SEQNUM_LIFETIME, whenever the sequence number of this entry 758 (RteMsg.OrigSeqNum for an RREQ, or RteMsg.TargSeqNum for an RREP) 759 is updated. 761 RteMsg.AckReqAddr 762 The address from which a RREP_Ack is expected, if RteMsg is a RREP 763 that contains an AckReq. 765 RteMsg.Interface 766 The interface on which the message was received. 768 The Multicast Route Message Set is maintained so that no two entries 769 have the same MessageType, OrigAddr, TargAddr, and MetricType. See 770 Section 6.8 for details about updating this set. 772 4.7. Route Error (RERR) Set 774 Each sent RERR message SHOULD be recorded in a conceptual set called 775 the Route Error (RERR) Set. Each entry contains the following 776 information: 778 RerrMsg.Timeout 779 The time after which the entry SHOULD be deleted. 781 RerrMsg.AddressList 782 The AddressList of the RERR to be recorded. 784 RerrMsg.PktSource: 785 The PktSource of the RERR to be recorded, if any. 787 See section Section 6.9 for instructions on how to update the set. 789 5. Metrics 791 Metrics measure a cost or quality associated with a route or a link, 792 e.g., latency, delay, financial cost, energy, etc. Metric values are 793 reported in Route Request and Route Reply messages. 795 In Route Request messages, the metric describes the cost of the route 796 from OrigAddr (and any other addresses included in the prefix length 797 of RREQ_Gen's Router Client entry for OrigAddr) to the router sending 798 the Route Request. For RREQ_Gen, this is the cost associated with 799 the Router Client entry which includes OrigAddr. For routers which 800 regenerate the RREQ, this is the cost from OrigAddr to the 801 regenerating router, combining the metric value from the received 802 RREQ message with knowledge of the link cost from the sender to the 803 receiver, i.e., the incoming link cost. This updated route cost is 804 included when regenerating the Route Request message, and used to 805 install a route back toward OrigAddr. 807 Similarly, in Route Reply messages, the metric reflects the cost of 808 the route from TargAddr (and any other addresses included in the 809 prefix length of RREP_Gen's Router Client entry for TargAddr) to the 810 router sending the Route Reply. For RREP_Gen, this is the cost 811 associated with the Router Client entry which includes TargAddr. For 812 routers which regenerate the RREP, this is the cost from TargAddr to 813 the regenerating router, combining the metric value from the received 814 RREP message with knowledge of the link cost from the sender to the 815 receiver, i.e., the incoming link cost. This updated route cost is 816 included when regenerating the Route Reply message, and used to 817 install a route back toward TargAddr. 819 Assuming link metrics are symmetric, the cost of the routes installed 820 in the Local Route Set at each router will be correct. While this 821 assumption is not always correct, calculating incoming/outgoing 822 metric data is outside of scope of this document. The route 823 discovered is optimised for the requesting router, and the return 824 path may not be the optimal route. 826 AODVv2 enables the use of multiple metric types. Each route 827 discovery attempt indicates the metric type which is requested for 828 the route. Only one metric type MUST be used in each route discovery 829 attempt. 831 For each MetricType, AODVv2 requires: 833 o A MetricType number, to indicate the metric type of a route. 834 MetricType numbers allocated are detailed in Section 10.5. 836 o A maximum value, denoted MAX_METRIC[MetricType]. This MUST always 837 be the maximum expressible metric value of type MetricType. Field 838 lengths associated with metric values are found in Section 10.5. 839 If the cost of a route exceeds MAX_METRIC[MetricType], the route 840 is ignored. 842 o A function for incoming link cost, denoted Cost(L). Using 843 incoming link costs means that the route learned has a path 844 optimized for the direction from OrigAddr to TargAddr. 846 o A function for route cost, denoted Cost(R). 848 o A function to analyze routes for potential loops based on metric 849 information, denoted LoopFree(R1, R2). LoopFree verifies that a 850 route R2 is not a sub-section of another route R1. An AODVv2 851 router invokes LoopFree() as part of the process in Section 6.7.1, 852 when an advertised route (R1) and an existing LocalRoute (R2) have 853 the same destination address, metric type, and sequence number. 854 LoopFree returns FALSE to indicate that an advertised route is not 855 to be used to update a stored LocalRoute, as it may cause a 856 routing loop. In the case where the existing LocalRoute is 857 Invalid, it is possible that the advertised route includes the 858 existing LocalRoute and came from a router which did not yet 859 receive notification of the route becoming Invalid, so the 860 advertised route should not be used to update the Local Route Set, 861 in case it forms a loop to a broken route. 863 AODVv2 currently supports cost metrics where Cost(R) is strictly 864 increasing, by defining: 866 o Cost(R) := Sum of Cost(L) of each link in the route 868 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 870 Implementers MAY consider other metric types, but the definitions of 871 Cost and LoopFree functions for such types are undefined, and 872 interoperability issues need to be considered. 874 6. AODVv2 Protocol Operations 876 The AODVv2 protocol's operations include managing sequence numbers, 877 monitoring next hop AODVv2 routers on discovered routes and updating 878 the Neighbor Set, performing route discovery and dealing with 879 requests from other routers, processing incoming route information 880 and updating the Local Route Set, updating the Multicast Route 881 Message Set and suppressing redundant messages, and reporting broken 882 routes. These processes are discussed in detail in the following 883 sections. 885 6.1. Initialization 887 During initialization where an AODVv2 router does not have 888 information about its previous sequence number, or if its sequence 889 number is lost at any point, the router resets its sequence number to 890 one (1). However, other AODVv2 routers may still hold sequence 891 number information that this router previously issued. Since 892 sequence number information is removed if there has been no update to 893 the sequence number in MAX_SEQNUM_LIFETIME, the initializing router 894 MUST wait for MAX_SEQNUM_LIFETIME before it creates any messages 895 containing its new sequence number. It can then be sure that the 896 information it sends will not be considered stale. 898 During this wait period, the router is permitted to do the following: 900 o Process information in a received RREQ or RREP message to learn a 901 route to the originator or target of that route discovery 903 o Regenerate a received RREQ or RREP 905 o Send an RREP_Ack 907 o Maintain valid routes in the Local Route Set 909 o Create, process and regenerate RERR messages 911 6.2. Next Hop Monitoring 913 To ensure AODVv2 routers Routers do not establish routes over uni- 914 directional links, AODVv2 routers MUST verify that the link to the 915 next hop router is bidirectional before marking a route as valid in 916 the Local Route Set. 918 AODVv2 provides a mechanism for testing bidirectional connectivity 919 during route discovery, and blacklisting routers where bidirectional 920 connectivity is not available. If a route discovery is retried by 921 RREQ_Gen, the blacklisted routers can be excluded from the process, 922 and a different route can be discovered. Further, a route is not to 923 be used for forwarding until the bidirectionality of the link to the 924 next hop is confirmed. AODVv2 routers do not need to monitor 925 bidirectionality for links to neighboring routers which are not used 926 as next hops on routes in the Local Route Set. 928 o Bidirectional connectivity to upstream routers is tested by 929 requesting acknowledgement of RREP messages by including an 930 AckReq, which MUST be answered by sending an RREP_Ack. Receipt of 931 an RREP_Ack within RREP_Ack_SENT_TIMEOUT proves that bidirectional 932 connectivity exists. Otherwise, a link is determined to be 933 unidirectional. All AODVv2 routers MUST support this process, 934 which is explained in Section 7.2 and Section 7.3. 936 o For the downstream router, receipt of an RREP message containing 937 the route to TargAddr is confirmation of bidirectionality , since 938 an RREP message is a reply to a RREQ message which previously 939 crossed the link in the opposite direction. 941 To assist with next hop monitoring, a Neighbor Set (Section 4.3) is 942 maintained. When an RREQ or RREP is received, search for an entry in 943 the Neighbor Set where all of the following conditions are met: 945 o Neighbor.IPAddress == IP address from which the RREQ or RREP was 946 received 948 o Neighbor.Interface == Interface on which the RREQ or RREP was 949 received. 951 If such an entry does not exist, a new entry is created as described 952 in Section 6.3. While the value of Neighbor.State is Unknown, 953 acknowledgement of RREP messages sent to that neighbor MUST be 954 requested. If an acknowledgement is not received within the timeout 955 period, the neighbor MUST have Neighbor.State set to Blacklisted. If 956 an acknowledgement is received within the timeout period, 957 Neighbor.State is set to Confirmed. While the value of 958 Neighbor.State is Confirmed, the request for an acknowledgement of 959 any other RREP message is unnecessary. 961 When routers perform other operations such as those from the list 962 below, these MAY be used as additional indications of connectivity: 964 o NHDP HELLO Messages [RFC6130] 966 o Route timeout 968 o Lower layer triggers, e.g. message reception or link status 969 notifications 971 o TCP timeouts 973 o Promiscuous listening 975 o Other monitoring mechanisms or heuristics 977 If such an external process signals that the link to a neighbor is 978 bidirectional, the AODVv2 router MAY update the matching Neighbor Set 979 entry by changing the value of Neighbor.State to Confirmed, e.g. 980 receipt of a Neighborhood Discovery Protocol HELLO message with the 981 receiving router listed as a neighbor. If an external process 982 signals that a link is not bidirectional, the the value of 983 Neighbor.State MAY be changed to Blacklisted, e.g. notification of a 984 TCP timeout. 986 6.3. Neighbor Set Update 988 On receipt of an RREQ or RREP message, the Neighbor Set MUST be 989 checked for an entry with Neighbor.IPAddress which matches the source 990 IP address of a packet containing the AODVv2 message. If no matching 991 entry is found, a new entry is created. 993 A new Neighbor Set entry is created as follows: 995 o Neighbor.IPAddress := Source IP address of the received route 996 message 998 o Neighbor.State := Unknown 1000 o Neighbor.ResetTime := INFINITY_TIME 1002 o Neighbor.Interface := Interface on which the RREQ or RREP was 1003 received. MUST equal Interface.Id of one of the entries in the 1004 InterfaceSet (see Section 4.1). 1006 If the message is one of the following: 1008 o an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the 1009 same interface as Neighbor.Interface 1011 o an RREP_Ack which answers a RREP sent within RREP_Ack_SENT_TIMEOUT 1012 over the same interface as Neighbor.Interface 1014 the link to the neighbor is bidirectional and the Neighbor Set entry 1015 is updated as follows: 1017 o Neighbor.State := Confirmed 1019 o Neighbor.ResetTime := INFINITY_TIME 1021 If the Multicast Route Message Set contains an entry where: 1023 o RteMsg.MessageType == RREP 1025 o RteMsg.AckReqAddr == Neighbor.IPAddress 1027 o RteMsg.Interface == Neighbor.Interface 1029 o RteMsg.Timestamp + RREP_Ack_SENT_TIMEOUT < CurrentTime 1031 the link is considered to be uni-directional and the Neighbor Set 1032 entry is updated as follows: 1034 o Neighbor.State := Blacklisted 1036 o Neighbor.ResetTime := CurrentTime + MAX_BLACKLIST_TIME 1038 When the Neighbor.ResetTime is reached, the Neighbor Set entry is 1039 updated as follows: 1041 o Neighbor.State := Unknown 1043 If an external mechanism reports a link as broken, the Neighbor Set 1044 entry SHOULD be removed. 1046 Route requests from neighbors with Neighbor.State set to Blacklisted 1047 are ignored to avoid persistent IP packet loss or protocol failures. 1048 Neighbor.ResetTime allows the neighbor to again be allowed to 1049 participate in route discoveries after MAX_BLACKLIST_TIME, in case 1050 the link between the routers has become bidirectional. 1052 6.4. Interaction with the Forwarding Plane 1054 The signals descried in the following are conceptual signals, and can 1055 be implemented in various ways. Conformant implementations of AODVv2 1056 are not mandated to implement the forwarding plane separately from 1057 the control plane or data plane; these signals and interactions are 1058 identified simply as assistance for implementers who may find them 1059 useful. 1061 AODVv2 requires signals from the forwarding plane: 1063 o A packet cannot be forwarded because a route is unavailable: 1064 AODVv2 needs to know the source and destination IP addresses of 1065 the packet. If the source of the packet is configured as a Router 1066 Client, the router should initiate route discovery to the 1067 destination. If it is not a Router Client, the router should 1068 create a Route Error message. 1070 o A packet is to be forwarded: AODVv2 needs to check the state of 1071 the route to ensure it is still valid. 1073 o Packet forwarding succeeds: AODVv2 needs to update the record of 1074 when a route was last used to forward a packet. 1076 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1077 Error message. 1079 AODVv2 needs to send signals to the forwarding plane: 1081 o A route discovery is in progress: buffering might be configured 1082 for packets requiring a route, while route discovery is attempted. 1084 o A route discovery failed: any buffered packets requiring that 1085 route should be discarded, and the source of the packet should be 1086 notified that the destination is unreachable (using an ICMP 1087 Destination Unreachable message). Route discovery fails if an 1088 RREQ cannot be generated because the control message generation 1089 limit has been reached, or if an RREP is not received within 1090 RREQ_WAIT_TIME (see Section 6.6). 1092 o A route discovery is not permitted: any buffered packets requiring 1093 that route should be discarded. A route discovery will not be 1094 attempted if the source address of the packet needing a route is 1095 not configured as a Router Client. 1097 o A route discovery succeeded: install a corresponding route into 1098 the Routing Information Base and begin transmitting any buffered 1099 packets. 1101 o A route has been made invalid: remove the corresponding route from 1102 the Routing Information Base. 1104 o A route has been updated: update the corresponding route in the 1105 Routing Information Base. 1107 6.5. Message Transmission 1109 AODVv2 sends [RFC5444] formatted messages using the parameters for 1110 port number and IP protocol specified in [RFC5498]. Mapping of 1111 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1112 multicast messages are sent to the link-local multicast address LL- 1113 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1114 MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2 1115 messages. Note that multicast messages MAY be sent via unicast. For 1116 example, this may occur for certain link-types (non-broadcast media), 1117 for manually configured router adjacencies, or in order to improve 1118 robustness. 1120 When multiple interfaces are available, an AODVv2 router transmitting 1121 a multicast message to LL-MANET-Routers MUST send the message on all 1122 interfaces that have been configured for AODVv2 operation, as given 1123 in the InterfaceSet (Section 4.1). 1125 To avoid congestion, each AODVv2 router's rate of message generation 1126 SHOULD be limited (CONTROL_TRAFFIC_LIMIT) and administratively 1127 configurable. Messages SHOULD NOT be sent more frequently than one 1128 message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If this 1129 threshold is reached, messages MUST be sent based on their priority: 1131 o Highest priority SHOULD be given to RREP_Ack messages. This 1132 allows links between routers to be confirmed as bidirectional and 1133 avoids undesired blacklisting of next hop routers. 1135 o Second priority SHOULD be given to RERR messages for undeliverable 1136 IP packets. This avoids repeated forwarding of packets over 1137 broken routes that are still in use by other routers. 1139 o Third priority SHOULD be given to RREP messages in order that 1140 RREQs do not time out. 1142 o Fourth priority SHOULD be given to RREQ messages. 1144 o Fifth priority SHOULD be given to RERR messages for newly 1145 invalidated routes. 1147 o Lowest priority SHOULD be given to RERR messages generated in 1148 response to RREP messages which cannot be regenerated. In this 1149 case the route request will be retried at a later point. 1151 To implement the congestion control, a queue length is set. If the 1152 queue is full, in order to queue a new message, a message of lower 1153 priority must be removed from the queue. If this is not possible, 1154 the new message MUST be discarded. The queue should be sorted in 1155 order of message priority 1157 6.6. Route Discovery, Retries and Buffering 1159 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1160 messages are multicast to solicit an RREP, whereas RREP are unicast 1161 where possible. The constants used inSection 6.7.1 this section are 1162 defined in Section 10. 1164 When an AODVv2 router needs to forward an IP packet (with source 1165 address OrigAddr and destination address TargAddr) from one of its 1166 Router Clients, it needs a route to TargAddr in its Routing 1167 Information Base. If no route exists, the AODVv2 router generates 1168 (RREQ_Gen) and multicasts a Route Request message (RREQ), on all 1169 configured interfaces, containing OrigAddr and TargAddr. The 1170 procedure for this is described in Section 7.1.1. Each generated 1171 RREQ results in an increment to the router's sequence number. The 1172 AODVv2 router generating an RREQ is referred to as RREQ_Gen. 1174 Buffering might be configured for IP packets awaiting a route for 1175 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1176 of IP packets might have both positive and negative effects. Real- 1177 time traffic, voice, and scheduled delivery may suffer if packets are 1178 buffered and subjected to delays, but TCP connection establishment 1179 will benefit if packets are queued while route discovery is performed 1180 [Koodli01]. Recommendations for appropriate buffer methods are out 1181 of scope for this specification. Determining which packets to 1182 discard first when the buffer is full is a matter of policy at each 1183 AODVv2 router. Note that using different or no buffer methods does 1184 not affect interoperability. 1186 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1187 a route toward TargAddr. This can be achieved by monitoring the 1188 entry in the Multicast Route Message Table that corresponds to the 1189 generated RREP. When CurrentTime exceeds RteMsg.Timestamp + 1190 RREQ_WAIT_TIME and no RREP has been received, RREQ_Gen will retry the 1191 route discovery. 1193 To reduce congestion in a network, repeated attempts at route 1194 discovery for a particular target address utilize a binary 1195 exponential backoff: for each additional attempt, the time to wait 1196 for receipt of the RREP is multiplied by 2. If the requested route 1197 is not learned within the wait period, another RREQ is sent, up to a 1198 total of DISCOVERY_ATTEMPTS_MAX. This is the same technique used in 1199 AODV [RFC3561]. 1201 Through the use of bidirectional link monitoring and blacklists (see 1202 Section 6.2) uni-directional links on initial selected route will be 1203 ignored on subsequent route discovery attempts. 1205 Route discovery is considered to have failed after 1206 DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an RREP 1207 response to the final RREQ. After the attempted route discovery has 1208 failed, RREQ_Gen waits at least RREQ_HOLDDOWN_TIME before attempting 1209 another route discovery to the same destination, in order to avoid 1210 repeatedly generating control traffic that is unlikely to discover a 1211 route. Any IP packets buffered for TargAddr are also dropped and a 1212 Destination Unreachable ICMP message (Type 3) with a code of 1 (Host 1213 Unreachable Error) is delivered to the source of the packet, so that 1214 the application knows about the failure. 1216 If RREQ_Gen does receive a route message containing a route to 1217 TargAddr within the timeout, it processes the message according to 1218 Section 7. When a valid LocalRoute entry is created in the Local 1219 Route Set, the route is also installed in the Routing Information 1220 Base, and the router will begin sending the buffered IP packets. Any 1221 retry timers for the corresponding RREQ are then cancelled. 1223 During route discovery, all routers on the path learn a route to both 1224 OrigAddr and TargAddr, so that routes are constructed in both 1225 directions. The route is optimized for the forward route. 1227 6.7. Processing Received Route Information 1229 All AODVv2 route messages contain a route. A Route Request (RREQ) 1230 contains a route toward OrigAddr (and other addresses as indicated by 1231 OrigPrefixLen), and a Route Reply (RREP) contains a route toward 1232 TargAddr (and other addresses as indicated by TargPrefixLen). All 1233 AODVv2 routers that receive a route message are able to store the 1234 route contained within it in their Local Route Set. Incoming 1235 information is first checked to verify that it is both safe to use 1236 and offers an improvement to existing information, as explained in 1237 Section 6.7.1. If these checks pass, the Local Route Set MUST be 1238 updated according to Section 6.7.2. 1240 In the processes below, RteMsg is used to denote the route message, 1241 AdvRte is used to denote the route contained within it, and 1242 LocalRoute denotes an existing entry in the Local Route Set which 1243 matches AdvRte on address, prefix length, and metric type. 1245 AdvRte has the following properties: 1247 o AdvRte.Address := network address given by combining 1248 RteMsg.OrigAddr and RteMsg.OrigPrefixLen (in RREQ) or 1249 RteMsg.TargAddr and RteMsg.TargPrefixLen (in RREP) 1251 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1252 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1253 in RteMsg, prefix length is the address length, in bits, of 1254 RteMsg.OrigAddr (in RREQ) or RteMsg.TargAddr (in RREP) 1256 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1257 (in RREP) 1259 o AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the 1260 sending interface of the router from which the RteMsg was 1261 received) 1263 o AdvRte.MetricType := RteMsg.MetricType 1265 o AdvRte.Metric := RteMsg.Metric 1267 o AdvRte.Cost := Cost(R) using the cost function associated with the 1268 route's metric type, i.e. Cost(R) = AdvRte.Metric + Cost(L), as 1269 described in Section 5, where L is the link from the advertising 1270 router 1272 o AdvRte.ValidityTime := RteMsg.ValidityTime, if included 1274 6.7.1. Evaluating Route Information 1276 An incoming advertised route (AdvRte) is compared to existing 1277 LocalRoutes to determine whether the advertised route is to be used 1278 to update the AODVv2 Local Route Set. The incoming route information 1279 MUST be processed as follows: 1281 1. Search for LocalRoutes in the Local Route Set matching AdvRte's 1282 address, prefix length and metric type 1284 * If no matching LocalRoute exists, AdvRte MUST be used to 1285 update the Local Route Set and no further checks are required. 1287 * If matching LocalRoutes are found, continue to Step 2. 1289 2. Compare sequence numbers using the technique described in 1290 Section 4.4 1292 * If AdvRte is more recent than all matching LocalRoutes, AdvRte 1293 MUST be used to update the Local Route Set and no further 1294 checks are required. 1296 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1297 Local Route Set. Ignore AdvRte for further processing. 1299 * If the sequence numbers are equal, continue to Step 3. 1301 3. Check that AdvRte is safe against routing loops compared to all 1302 matching LocalRoutes (see Section 5) 1304 * If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte 1305 for further processing. AdvRte MUST NOT be used to update the 1306 Local Route Set because using the incoming information might 1307 cause a routing loop. 1309 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to Step 1310 4. 1312 4. Compare route costs 1314 * If AdvRte is better than all matching LocalRoutes, it SHOULD 1315 be used to update the Local Route Set because it offers 1316 improvement. If it is not used to update the Local Route Set, 1317 the existing non-optimal LocalRoute will continue to be used, 1318 causing data traffic to use a non-optimal route. 1320 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte 1321 SHOULD NOT be used to update the Local Route Set because it 1322 will offer no improvement. 1324 * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for 1325 further processing. AdvRte MUST NOT be used to update the 1326 Local Route Set because it does not offer any improvement. 1328 * If AdvRte is not better (i.e., it is worse or equal) but 1329 LocalRoute is Invalid, AdvRte SHOULD be used to update the 1330 Local Route Set because it can safely repair the existing 1331 Invalid LocalRoute. 1333 If the advertised route is to be used to update the Local Route Set, 1334 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1335 routes will remain in the Local Route Set. 1337 For information on how to apply these changes to the Routing 1338 Information Base, see Section 4.5. 1340 6.7.2. Applying Route Updates 1342 After determining that AdvRte is to be used to update the Local Route 1343 Set (as described in Section 6.7.1), the following procedure applies. 1345 If AdvRte is learned from an RREQ message, the link to the next hop 1346 neighbor may not be confirmed as bidirectional (see Section 4.3). 1347 The route will offer improvement to the Local Route Set if the 1348 neighbor can be confirmed. If there is no existing matching route, 1349 AdvRte allows a corresponding RREP to be sent. If a matching entry 1350 already exists, AdvRte offers potential improvement. 1352 The route update is applied as follows: 1354 1. If no existing entry in the Local Route Set matches AdvRte's 1355 address, prefix length and metric type, continue to Step 4 and 1356 create a new entry in the Local Route Set. 1358 2. If two matching LocalRoutes exist in the Local Route Set, one is 1359 a valid route, and one is an Unconfirmed route, AdvRte may offer 1360 further improvement to the Unconfirmed route, or may offer an 1361 update to the valid route. 1363 * If AdvRte.NextHop's Neighbor.State is Unknown, the advertised 1364 route may offer improvement to the existing valid route, if 1365 the link to the next hop can be confirmed as bidirectional. 1366 Continue processing from Step 5 to update the existing 1367 Unconfirmed LocalRoute. 1369 * If AdvRte.NextHop's Neighbor.State is Confirmed, the 1370 advertised route offers an update or improvement to the 1371 existing valid route. Continue processing from Step 5 to 1372 update the existing valid LocalRoute. 1374 3. If only one matching LocalRoute exists in the Local Route Set: 1376 * If AdvRte.NextHop's Neighbor.State is Confirmed, continue 1377 processing from Step 5 to update the existing LocalRoute. 1379 * If AdvRte.NextHop's Neighbor.State is Unknown, AdvRte may 1380 offer improvement the existing LocalRoute, if the link to 1381 AdvRte.NextHop can be confirmed as bidirectional. 1383 * If LocalRoute.State is Unconfirmed, AdvRte is an improvement 1384 to an existing Unconfirmed route. Continue processing from 1385 Step 5 to update the existing LocalRoute. 1387 * If LocalRoute.State is Invalid, AdvRte can replace the 1388 existing LocalRoute. Continue processing from Step 5 to 1389 update the existing LocalRoute. 1391 * If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored 1392 as an additional entry in the Local Route Set, with 1393 LocalRoute.State set to Unconfirmed. Continue processing from 1394 Step 4 to create a new LocalRoute. 1396 4. Create an entry in the Local Route Set and initialize as follows: 1398 * LocalRoute.Address := AdvRte.Address 1400 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1402 * LocalRoute.MetricType := AdvRte.MetricType 1404 5. Update the LocalRoute as follows: 1406 * LocalRoute.SeqNum := AdvRte.SeqNum 1408 * LocalRoute.NextHop := AdvRte.NextHop 1410 * LocalRoute.NextHopInterface := interface on which RteMsg was 1411 received 1413 * LocalRoute.Metric := AdvRte.Cost 1415 * LocalRoute.LastUsed := CurrentTime 1417 * LocalRoute.LastSeqNumUpdate := CurrentTime 1419 * LocalRoute.ExpirationTime := CurrentTime + AdvRte.ValidityTime 1420 if a validity time exists, otherwise INFINITY_TIME 1422 6. If a new LocalRoute was created, or if the existing 1423 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1424 follows: 1426 * LocalRoute.State := Unconfirmed (if the next hop's 1427 Neighbor.State is Unknown) 1429 * LocalRoute.State := Idle (if the next hop's Neighbor.State is 1430 Confirmed) 1432 7. If an existing LocalRoute.State changed from Invalid or 1433 Unconfirmed to become Idle, any matching Unconfirmed LocalRoute 1434 with worse metric value SHOULD be expunged. 1436 8. If an existing LocalRoute was updated with a better metric value, 1437 any matching Unconfirmed LocalRoute with worse metric value 1438 SHOULD be expunged. 1440 9. If this update results in LocalRoute.State of Active or Idle, 1441 which matches a route request which is still in progress, the 1442 associated route request retry timers SHOULD be cancelled. 1444 If this update to the Local Route Set results in two LocalRoutes to 1445 the same address, the best LocalRoute will be Unconfirmed. In order 1446 to improve the route used for forwarding, the router SHOULD try to 1447 determine if the link to the next hop of that LocalRoute is 1448 bidirectional, by using that LocalRoute to forward future RREPs and 1449 request acknowledgements (see Section 7.2.1). 1451 6.8. Suppressing Redundant Messages Using the Multicast Route Message 1452 Set 1454 When route messages are flooded in a MANET, an AODVv2 router may 1455 receive multiple similar messages. Regenerating every one of these 1456 gives little additional benefit, and generates unnecessary signaling 1457 traffic and might generate unnecessary interference. 1459 Each AODVv2 router stores information about recently received route 1460 messages in the AODVv2 Multicast Route Message Set (Section 4.6). 1462 Entries in the Multicast Route Message Set SHOULD be maintained for 1463 at least RteMsg_ENTRY_TIME after the last Timestamp update in order 1464 to account for long-lived RREQs traversing the network. An entry 1465 MUST be deleted when the sequence number is no longer valid, i.e., 1466 after MAX_SEQNUM_LIFETIME. Memory-constrained devices MAY remove the 1467 entry before this time. 1469 Received route messages are tested against previously received route 1470 messages, and if determined to be redundant, regeneration or response 1471 can be avoided. 1473 To determine if a received message is redundant: 1475 1. Search for an entry in the Multicast Route Message Set with the 1476 same MessageType, OrigAddr, TargAddr, Interface and MetricType 1478 * If there is no entry, the message is not redundant. 1480 * If there is an entry, continue to Step 2. 1482 2. Compare sequence numbers using the technique described in 1483 Section 4.4 1485 * For RREQ messages, use OrigSeqNum of the entry for comparison. 1486 For RREP messages, use TargSeqNum of the entry for comparison. 1488 * If the entry has an older sequence number than the received 1489 message, the message is not redundant. 1491 * If the entry has a newer sequence number than the received 1492 message, the message is redundant. 1494 * If the entry has the same sequence number, continue to Step 3. 1496 3. Compare the metric values 1498 * If the entry has a Metric value that is worse than or equal to 1499 the metric in the received message, the message is redundant. 1501 * If the entry has a Metric value that is better than the metric 1502 in the received message, the message is not redundant. 1504 If the message is redundant, update the Timestamp and RemoveTime on 1505 the entry, since matching route messages are still traversing the 1506 network and this entry should be maintained. This message MUST NOT 1507 be regenerated or responded to. 1509 If the message is not redundant, create an entry or update the 1510 existing entry. 1512 To update a Multicast Route Message Set entry, set: 1514 o RteMsg.MessageType := the message type of the received message 1516 o RteMsg.OrigAddr := OrigAddr from the message 1518 o RteMsg.OrigPrefixLen := the prefix length associated with OrigAddr 1520 o RteMsg.TargAddr := TargAddr from the message 1522 o RteMsg.TargPrefixLen := the prefix length associated with TargAddr 1524 o RteMsg.OrigSeqNum := the sequence number associated with OrigAddr, 1525 if present in the received message 1527 o RteMsg.TargSeqNum := the sequence number associated with TargAddr, 1528 if present in the received message 1530 o RteMsg.Metric := the metric value associated with OrigAddr in a 1531 received RREQ or TargAddr in a received RREP 1533 o RteMsg.MetricType := the metric type associated with RteMsg.Metric 1535 o RteMsg.Timestamp := CurrentTime 1537 o RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME 1539 Where the message is determined not redundant before Step 3, it MUST 1540 be regenerated or responded to. When a message is determined to be 1541 not redundant in Step 3, it MAY be suppressed to avoid extra control 1542 traffic. However, since the processing of the message will result in 1543 an update to the Local Route Set, the message SHOULD be regenerated 1544 or responded to, to ensure other routers have up-to-date information 1545 and the best metrics. If the message is not regenerated, the best 1546 route may not be found. Regeneration or response is to be performed 1547 using the processes outlined in Section 7. 1549 6.9. Suppressing Redundant Route Error Messages using the Route Error 1550 Set 1552 In order to avoid flooding the network with RERR messages when a 1553 stream of IP packets to an unreachable address arrives, an AODVv2 1554 router SHOULD avoid creating duplicate messages by determining 1555 whether an equivalent RERR has recently been sent. This is achieved 1556 with the help of the Route Error Set (see Section 4.7). 1558 To determine if a received RERR is redundant: 1560 1. Search for an entry in the Route Error Set where: 1562 * RerrMsg.AddressList == RERR.AddressList 1564 * RerrMsg.PktSource == RERR.PktSource 1566 If a matching entry is found, no further processing is required 1567 and the RERR SHOULD NOT be sent. 1569 2. If no matching entry is found, a new entry with the following 1570 properties is created: 1572 * RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT 1574 * RerrMsg.AddressList == RERR.AddressList 1575 * RerrMsg.PktSource == RERR.PktSource 1577 6.10. Local Route Set Maintenance 1579 Route maintenance involves monitoring LocalRoutes in the Local Route 1580 Set, updating LocalRoute.State to handle route timeouts and reporting 1581 routes that become Invalid. 1583 6.10.1. LocalRoute State Changes 1585 During normal operation, AODVv2 does not require any explicit 1586 timeouts to manage the lifetime of a route. At any time, any 1587 LocalRoute MAY be examined and updated according to the rules below. 1588 If timers are not used to prompt updates of LocalRoute.State, the 1589 LocalRoute.State MUST be checked before IP packet forwarding and 1590 before any operation based on LocalRoute.State. 1592 Route timeout behaviour is as follows: 1594 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1595 LocalRoute.LastSeqNumUpdate. 1597 o An Idle route MUST become Active when used to forward an IP 1598 packet. If the route is not used to forward an IP packet within 1599 MAX_IDLETIME, LocalRoute.State MUST become Invalid. 1601 o An Active route which is a timed route (i.e., with 1602 LocalRoute.ExpirationTime not equal to INFINITY_TIME) remains 1603 Active until LocalRoute.ExpirationTime, after which it MUST become 1604 Invalid. If it it not a timed route, it MUST become Idle if the 1605 route is not used to forward an IP packet within ACTIVE_INTERVAL. 1607 o An Invalid route SHOULD remain in the Local Route Set, since 1608 LocalRoute.SeqNum is used to classify future information about 1609 LocalRoute.Address as stale or fresh. 1611 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1612 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 1613 zero. This is required to ensure that any AODVv2 routers 1614 following the initialization procedure can safely begin routing 1615 functions using a new sequence number. A LocalRoute with 1616 LocalRoute.State set to Active or Idle can remain in the Local 1617 Route Set after removing the sequence number, for exmple if the 1618 route is reliably carrying traffic. If LocalRoute.State is 1619 Invalid, or later becomes Invalid, the LocalRoute MUST be expunged 1620 from the Local Route Set. 1622 LocalRoutes can become Invalid before a timeout occurs: 1624 o If an external mechanism reports a link as broken, all LocalRoutes 1625 using that link for LocalRoute.NextHop MUST immediately have 1626 LocalRoute.State set to Invalid. 1628 o LocalRoute.State MUST immediately be set to Invalid if a Route 1629 Error (RERR) message is received where: 1631 * The sender is LocalRoute.NextHop or PktSource is a Router 1632 Client address 1634 * There is an Address in AddressList which matches 1635 LocalRoute.Address, and: 1637 + The prefix length associated with this Address, if any, 1638 matches LocalRoute.PrefixLength 1640 + The sequence number associated with this Address, if any, is 1641 newer or equal to LocalRoute.SeqNum (see Section 4.4) 1643 + The metric type associated with this Address matches 1644 LocalRoute.MetricType 1646 LocalRoutes are also updated when Neighbor.State is updated: 1648 o While the value of Neighbor.State is set to Unknown, any routes in 1649 the Local Route Set using that neighbor as a next hop MUST have 1650 LocalRoute.State set to Unconfirmed. 1652 o When the value of Neighbor.State is set to Confirmed, the 1653 Unconfirmed routes in the Local Route Set using that neighbor as a 1654 next hop MUST have LocalRoute.State set to Idle. Any other 1655 matching LocalRoutes with metric values worse than 1656 LocalRoute.Metric MUST be expunged from the Local Route Set. 1658 o When the value of Neighbor.State is set to Blacklisted, any valid 1659 routes in the Local Route Set using that neighbor for their next 1660 hop MUST have LocalRoute.State set to Invalid. 1662 o When a Neighbor Set entry is removed, all routes in the Local 1663 Route Set using that neighbor as next hop MUST have 1664 LocalRoute.State set to Invalid. 1666 Memory constrained devices MAY choose to expunge routes from the 1667 AODVv2 Local Route Set before LocalRoute.ExpirationTime, but MUST 1668 adhere to the following rules: 1670 o An Active route MUST NOT be expunged, as it is in use. If 1671 deleted, IP traffic forwarded to this router will prompt 1672 generation of a Route Error message, and it will be necessary for 1673 a Route Request to be generated by the originator's router to re- 1674 establish the route. 1676 o An Idle route SHOULD NOT be expunged, as it is still valid for 1677 forwarding IP traffic. If deleted, this could result in dropped 1678 IP packets and a Route Request could be generated to re-establish 1679 the route. 1681 o Any Invalid route MAY be expunged. Least recently used Invalid 1682 routes SHOULD be expunged first, since the sequence number 1683 information is less likely to be useful. 1685 o An Unconfirmed route MUST NOT be expunged if it was installed 1686 within the last RREQ_WAIT_TIME, because it may correspond to a 1687 route discovery in progress. A Route Reply message might be 1688 received which needs to use the LocalRoute.NextHop information. 1689 Otherwise, it MAY be expunged. 1691 6.10.2. Reporting Invalid Routes 1693 When LocalRoute.State changes from Active to Invalid as a result of a 1694 broken link or a received Route Error (RERR) message, other AODVv2 1695 routers MUST be informed by sending an RERR message containing 1696 details of the invalidated route. 1698 An RERR message MUST also be sent when an AODVv2 router receives an 1699 IP packet to forward on behalf of another router but does not have a 1700 valid route in its Routing Information Base for the destination of 1701 the packet. 1703 An RERR message MUST also be sent when an AODVv2 router receives an 1704 RREP message to regenerate, but the LocalRoute to the OrigAddr in the 1705 RREP has been lost or is marked as Invalid. 1707 The packet or message triggering the RERR MUST be discarded. 1709 Generation of an RERR message is described in Section 7.4.1. 1711 7. AODVv2 Protocol Messages 1713 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1714 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1715 (RERR). 1717 Each AODVv2 message is defined as a set of data. Rules for the 1718 generation, reception and regeneration of each message type are 1719 described in the following sections. Section 8 discusses how the 1720 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1721 TLVs. 1723 7.1. Route Request (RREQ) Message 1725 Route Request messages are used in route discovery operations to 1726 request a route to a specified target address. RREQ messages have 1727 the following contents: 1729 +-----------------------------------------------------------------+ 1730 | AddressList | 1731 +-----------------------------------------------------------------+ 1732 | PrefixLengthList (optional) | 1733 +-----------------------------------------------------------------+ 1734 | OrigSeqNum, (optional) TargSeqNum | 1735 +-----------------------------------------------------------------+ 1736 | MetricType | 1737 +-----------------------------------------------------------------+ 1738 | OrigMetric | 1739 +-----------------------------------------------------------------+ 1740 | ValidityTime (optional) | 1741 +-----------------------------------------------------------------+ 1743 Figure 1: RREQ message contents 1745 AddressList 1746 Contains OrigAddr and TargAddr, the source and destination 1747 addresses of the IP packet for which a route is requested. 1748 OrigAddr and TargAddr MUST be routable unicast addresses. 1750 PrefixLengthList 1751 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1752 associated with the Router Client entry which includes OrigAddr. 1753 If omitted, the prefix length is equal to OrigAddr's address 1754 length in bits. 1756 OrigSeqNum 1757 The sequence number associated with OrigAddr. 1759 TargSeqNum 1760 A sequence number associated with an existing Invalid route to 1761 TargAddr. This MAY be included if available. 1763 MetricType 1764 The metric type associated with OrigMetric. 1766 OrigMetric 1767 The metric value associated with the LocalRoute to OrigAddr (and 1768 to any other addresses included in the given prefix length), as 1769 seen from the sender of the message. 1771 ValidityTime 1772 The length of time that the message sender is willing to offer a 1773 route toward OrigAddr (and any other addresses included in the 1774 given prefix length). Omitted if no time limit is imposed. 1776 7.1.1. RREQ Generation 1778 An RREQ is generated when an IP packet needs to be forwarded for a 1779 Router Client, and no valid route currently exists for the packet's 1780 destination in the Routing Information Base. 1782 Before creating an RREQ, the router SHOULD check the Multicast Route 1783 Message Set to see if an RREQ has recently been sent for the 1784 requested destination. If so, and the wait time for a reply has not 1785 yet been reached, the router SHOULD continue to await a response 1786 without generating a new RREQ. If the timeout has been reached, a 1787 new RREQ MAY be generated. If buffering is configured, incoming IP 1788 packets awaiting this route SHOULD be buffered until the route 1789 discovery is completed. 1791 If the limit for the rate of AODVv2 control message generation has 1792 been reached, no message SHOULD be generated. 1794 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1795 this procedure: 1797 1. Set AddressList := {OrigAddr, TargAddr} 1799 2. For the PrefixLengthList: 1801 * If OrigAddr is part of an address range configured as a Router 1802 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1803 null}. This allows receiving routers to learn a route to all 1804 the addresses included by the prefix length, not only to 1805 OrigAddr. 1807 * Otherwise, omit PrefixLengthList. 1809 3. For OrigSeqNum: 1811 * Increment the router SeqNum as specified in Section 4.4. 1813 * Set OrigSeqNum := SeqNum. 1815 4. For TargSeqNum: 1817 * If an Invalid route exists in the Local Route Set matching 1818 TargAddr using longest prefix matching and has a valid 1819 sequence number, set TargSeqNum := LocalRoute.SeqNum. 1821 * If no Invalid route exists in the Local Route Set matching 1822 TargAddr, or the route doesn't have a sequence number, omit 1823 TargSeqNum. 1825 5. Include MetricType and set the type accordingly 1827 6. Set OrigMetric := RouterClient.Cost for the Router Client entry 1828 which includes OrigAddr 1830 7. Include ValidityTime if advertising that the route to OrigAddr 1831 (and any other addresses included in the given prefix length) via 1832 this router is offered for a limited time, and set ValidityTime 1833 accordingly 1835 This AODVv2 message is used to create a corresponding [RFC5444] 1836 message (see Section 8) which is handed to the RFC5444 multiplexer 1837 for further processing. By default, the multiplexer is instructed to 1838 multicast the message to LL-MANET- Routers on all interfaces 1839 configured for AODVv2 operation. 1841 7.1.2. RREQ Reception 1843 Upon receiving a Route Request, an AODVv2 router performs the 1844 following steps: 1846 1. Check and update the Neighbor Set according to Section 6.3 1848 * If the sender has Neighbor.State set to Blacklisted, ignore 1849 this RREQ for further processing. 1851 2. Verify that the message contains the required data: OrigAddr, 1852 TargAddr, OrigSeqNum, and OrigMetric, and that OrigAddr and 1853 TargAddr are valid addresses (routable and unicast) 1855 * If not, ignore this RREQ for further processing. 1857 3. Check that the MetricType is supported and configured for use 1859 * If not, ignore this RREQ for further processing. 1861 4. Verify that the cost of the advertised route will not exceed the 1862 maximum allowed metric value for the metric type (Metric <= 1863 MAX_METRIC[MetricType] - Cost(L)) 1865 * If it will, ignore this RREQ for further processing. 1867 5. Process the route to OrigAddr (and any other addresses included 1868 in the given prefix length) as specified in Section 6.7 1870 6. Check if the information in the message is redundant by comparing 1871 to entries in the Multicast Route Message Set, following the 1872 procedure in Section 6.8 1874 * If redundant, ignore this RREQ for further processing. 1876 * If not redundant, continue processing. 1878 7. Check if the TargAddr belongs to one of the Router Clients 1880 * If so, generate an RREP as specified in Section 7.2.1. 1882 * If not, continue to RREQ regeneration. 1884 7.1.3. RREQ Regeneration 1886 By regenerating an RREQ, a router advertises that it will forward IP 1887 packets to the OrigAddr contained in the RREQ (and to other addresses 1888 included in the given prefix length) according to the information 1889 enclosed. The router MAY choose not to regenerate the RREQ, for 1890 example if the router is heavily loaded or low on energy and 1891 therefore unwilling to advertise routing capability for more traffic. 1892 This could, however, decrease connectivity in the network or result 1893 in non-optimal paths. 1895 The RREQ SHOULD NOT be regenerated if the limit for the rate of 1896 AODVv2 control message generation has been reached. 1898 The procedure for RREQ regeneration is as follows: 1900 1. Set AddressList, PrefixLengthList, sequence numbers and 1901 MetricType to the values in the received RREQ 1903 2. Set OrigMetric := LocalRoute[OrigAddr].Metric 1905 3. If the received RREQ contains a ValidityTime, or if the 1906 regenerating router wishes to limit the time that it offers a 1907 route to OrigAddr (and any other addresses included in the given 1908 prefix length), the regenerated RREQ MUST include ValidityTime 1909 * The ValidityTime is either the time limit the previous AODVv2 1910 router specified, or the time limit this router wishes to 1911 impose, whichever is lower. 1913 This AODVv2 message is used to create a corresponding [RFC5444] 1914 message (see Section 8) which is handed to the RFC5444 multiplexer 1915 for further processing. By default, the multiplexer is instructed to 1916 multicast the message to LL-MANET-Routers on all interfaces 1917 configured for AODVv2 operation. However, the regenerated RREQ can 1918 be unicast to the next hop address of the LocalRoute toward TargAddr, 1919 if known. 1921 7.2. Route Reply (RREP) Message 1923 When a Route Request message is received, requesting a route to a 1924 target address (TargAddr) which is configured as part of a Router 1925 Client entry, a Route Reply message is sent in response. The RREP 1926 offers a route to TargAddr (and any other addresses included in the 1927 prefix length). 1929 RREP messages have the following contents: 1931 +-----------------------------------------------------------------+ 1932 | AckReq (optional) | 1933 +-----------------------------------------------------------------+ 1934 | AddressList | 1935 +-----------------------------------------------------------------+ 1936 | PrefixLengthList (optional) | 1937 +-----------------------------------------------------------------+ 1938 | TargSeqNum | 1939 +-----------------------------------------------------------------+ 1940 | MetricType | 1941 +-----------------------------------------------------------------+ 1942 | TargMetric | 1943 +-----------------------------------------------------------------+ 1944 | ValidityTime (optional) | 1945 +-----------------------------------------------------------------+ 1947 Figure 2: RREP message contents 1949 AckReq 1950 The address of the intended next hop of the RREP. This is 1951 included when the link to the next hop toward OrigAddr is not 1952 known to be bidirectional. It indicates that an acknowledgement 1953 of the RREP is requested by the sender from the intended next hop 1954 (see Section 6.2). 1956 AddressList 1957 Contains OrigAddr and TargAddr, the source and destination 1958 addresses of the IP packet for which a route is requested. 1959 OrigAddr and TargAddr MUST be routable unicast addresses. 1961 PrefixLengthList 1962 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 1963 associated with the Router Client entry which includes TargAddr. 1964 If omitted, the prefix length is equal to TargAddr's address 1965 length, in bits. 1967 TargSeqNum 1968 The sequence number associated with TargAddr. 1970 MetricType 1971 The metric type associated with TargMetric. 1973 TargMetric 1974 The metric value associated with the LocalRoute to TargAddr (and 1975 any other addresses included in the given prefix length), as seen 1976 from the sender of the message. 1978 ValidityTime 1979 The length of time that the message sender is willing to offer a 1980 route toward TargAddr (and any other addresses included in the 1981 given prefix length). Omitted if no time limit is imposed. 1983 7.2.1. RREP Generation 1985 A Route Reply message is generated when a Route Request for a Router 1986 Client of the AODVv2 router arrives. This is the case when 1987 RteMsg.TargAddr matches an address which is configured as a Router 1988 Client of the AODVv2 router. 1990 Before creating an RREP, the router SHOULD check if the corresponding 1991 RREQ is redundant, i.e., a Route Reply has already been generated in 1992 response to the RREQ, or if the limit for the rate of AODVv2 control 1993 message generation has been reached. If so, the RREP SHOULD NOT be 1994 created. 1996 The RREP will follow the path of the route to OrigAddr. If the best 1997 route to OrigAddr in the Local Route Set is Unconfirmed, the link to 1998 the next hop neighbor is not yet confirmed as bidirectional (as 1999 described in Section 6.2). In this case the RREP MUST include AckReq 2000 set to the intended next hop address. The AckReq indicates that an 2001 acknowledgement to the RREP is requested from the intended next hop 2002 router in the form of a Route Reply Acknowledgement (RREP_Ack). If 2003 the best route to OrigAddr in the Local Route Set is valid, the link 2004 to the next hop neighbor is already confirmed as bidirectional, and 2005 the AckReq can be omitted. 2007 Implementations MAY allow a number of retries of the RREP if a 2008 requested acknowledgement is not received within 2009 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 2010 maximum of RREP_RETRIES, using the same exponential backoff described 2011 in Section 6.6 for RREQ retries. The acknowledgement MUST be 2012 considered to have failed after the wait time for an RREP_Ack 2013 response to the final RREP. 2015 To generate the RREP, the router (also referred to as RREP_Gen) 2016 follows this procedure: 2018 1. If the link to the next hop router toward OrigAddr is not known 2019 to be bidirectional, include the AckReq with the address of the 2020 intended next hop router (see Section 8.2.3) 2022 2. Set Address List := {OrigAddr, TargAddr} 2024 3. For the PrefixLengthList: 2026 * If TargAddr is part of an address range configured as a Router 2027 Client, set PrefixLengthList := {null, 2028 RouterClient.PrefixLength}. This allows receiving routers to 2029 learn a route to all the addresses included by the prefix 2030 length, not only to TargAddr. 2032 * Otherwise, omit PrefixLengthList. 2034 4. For the TargSeqNum: 2036 * Increment the router SeqNum as specified in Section 4.4. 2038 * Set TargSeqNum := SeqNum. 2040 5. Include MetricType and set the type to match the MetricType in 2041 the received RREQ message 2043 6. Set TargMetric := RouterClient.Cost for the Router Client entry 2044 which includes TargAddr 2046 7. Include ValidityTime if advertising that the route to TargAddr 2047 (and any other addresses included in the given prefix length) via 2048 this router is offered for a limited time, and set ValidityTime 2049 accordingly 2051 This AODVv2 message is used to create a corresponding [RFC5444] 2052 message (see Section 8) which is handed to the RFC5444 multiplexer 2053 for further processing. If the Neighbor Set contains an entry for 2054 the neighbor stored as LocalRoute[OrigAddr].NextHop, with 2055 Neighbor.State set to Confirmed, the multiplexer is instructed to 2056 unicast the RREP to LocalRoute[OrigAddr].NextHop. Otherwise, it 2057 multicasts the RREP to LL-MANET-Routers. The RREP MUST be sent over 2058 the same interface on which the RREQ that triggered it was received. 2060 7.2.2. RREP Reception 2062 Upon receiving a Route Reply, an AODVv2 router performs the following 2063 steps: 2065 1. Verify that the message contains the required data: OrigAddr, 2066 TargAddr, TargSeqNum, and TargMetric, and that OrigAddr and 2067 TargAddr are valid addresses (routable and unicast) 2069 * If not, ignore this RREP for further processing. 2071 2. Check that the MetricType is supported and configured for use 2073 * If not, ignore this RREP for further processing. 2075 3. If this RREP does not correspond to a RREQ generated or 2076 regenerated in the last RREQ_WAIT_TIME, ignore for further 2077 processing. 2079 4. Update the Neighbor Set according to Section 6.3 2081 5. Verify that the cost of the advertised route does not exceed the 2082 maximum allowed metric value for the metric type (Metric <= 2083 MAX_METRIC[MetricType] - Cost(L)) 2085 * If it does, ignore this RREP for further processing. 2087 6. If the AckReq is present, check the intended recipient of the 2088 received RREP: 2090 * If there is an entry in the Router Client Set where 2091 RouterClient.IPAddress matches the address associated with 2092 the AckReq (see Section 8.2.3), the receiving router is the 2093 intended recipient. Send an acknowledgement as specified in 2094 Section 7.3 and continue processing. 2096 * Otherwise, ignore this RREP for further processing. 2098 7. Process the route to TargAddr (and any other addresses included 2099 in the given prefix length) as specified in Section 6.7 2101 8. Check if the message is redundant by comparing to entries in the 2102 Multicast Route Message Set (Section 6.8) 2104 * If redundant, ignore this RREP for further processing. 2106 * If not redundant, save the information in the Multicast Route 2107 Message Set to identify future redundant RREP messages and 2108 continue processing. 2110 9. Check if the OrigAddr belongs to one of the Router Clients 2112 * If so, no further processing is necessary. 2114 * If not, continue to Step 10. 2116 10. Check if a valid (Active or Idle) or Unconfirmed LocalRoute 2117 exists to OrigAddr 2119 * If so, continue to RREP regeneration. 2121 * If not, a Route Error message SHOULD be transmitted to 2122 TargAddr according to Section 7.4.1 and the RREP SHOULD be 2123 discarded and not regenerated. 2125 7.2.3. RREP Regeneration 2127 A received Route Reply message is regenerated toward OrigAddr. By 2128 regenerating a RREP, a router advertises that it will forward IP 2129 packets to TargAddr. 2131 The RREP SHOULD NOT be regenerated if CONTROL_TRAFFIC_LIMIT has been 2132 reached. Otherwise, the router MUST regenerate the RREP. 2134 The procedure for RREP regeneration is as follows: 2136 1. If the link to the next hop router toward OrigAddr is not known 2137 to be bidirectional, include the AckReq with the address of the 2138 intended next hop router 2140 2. Set AddressList, PrefixLengthList, TargSeqNum and MetricType to 2141 the values in the received RREP 2143 3. Set TargMetric := LocalRoute[TargAddr].Metric 2144 4. If the received RREP contains a ValidityTime, or if the 2145 regenerating router wishes to limit the time that it will offer a 2146 route to TargAddr (and any other addresses included in the given 2147 prefix length), the regenerated RREP MUST include ValidityTime 2149 * The ValidityTime is either the time limit the previous AODVv2 2150 router specified, or the time limit this router wishes to 2151 impose, whichever is lower. 2153 This AODVv2 message is used to create a corresponding [RFC5444] 2154 message (see Section 8) which is handed to the RFC5444 multiplexer 2155 for further processing. If the Neighbor Set contains an entry for 2156 the neighbor stored as LocalRoute[OrigAddr].NextHop, with 2157 Neighbor.State set to Confirmed, the multiplexer is instructed to 2158 unicast the RREP to LocalRoute[OrigAddr].NextHop. Otherwise, it 2159 multicasts the RREP to LL-MANET-Routers. The RREP MUST be sent over 2160 LocalRoute[OrigAddr].NextHopInterface. 2162 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2164 The Route Reply Acknowledgement is a response to a Route Reply 2165 message. When the RREP_Ack message is received by the sender of the 2166 RREP, it confirms that the link between the two routers is 2167 bidirectional (see Section 6.2). The RREP_Ack has no further data. 2169 7.3.1. RREP_Ack Generation 2171 An RREP_Ack MUST be generated if a received Route Reply includes an 2172 AckReq with an address matching one of the receiving router's IP 2173 addresses. The RREP_Ack SHOULD NOT be generated if the limit for the 2174 rate of AODVv2 control message generation has been reached. 2176 There is no further data in an RREP_Ack. The [RFC5444] 2177 representation is discussed in Section 8. The RREP_Ack is unicast, 2178 by default, to the source IP address of the RREP message that 2179 requested it. It MUST be sent over the same interface on which the 2180 RREP that triggered it was received. 2182 7.3.2. RREP_Ack Reception 2184 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2185 steps: 2187 1. Check if the RREP_Ack was expected: 2189 * Check if the Multicast Route Message Set contains an entry 2190 where: 2192 + RteMsg.MessageType == RREP 2194 + RteMsg.AckReqAddr matches the source IP address of the 2195 RREP_Ack 2197 + RteMsg.Timestamp > CurrentTime - RREP_Ack_SENT_TIMEOUT 2199 + RteMsg.Interface matches the interface on which the 2200 RREP_Ack was received 2202 * If it does, the router cancels any associated timeouts and 2203 processing continues to Step 2. 2205 * Otherwise no actions are required and processing ends. 2207 2. Update the Neighbor Set according to Section 6.3 2209 7.4. Route Error (RERR) Message 2211 A Route Error message is generated by an AODVv2 router to notify 2212 other AODVv2 routers of routes that are no longer available. An RERR 2213 message has the following contents: 2215 +-----------------------------------------------------------------+ 2216 | PktSource (optional) | 2217 +-----------------------------------------------------------------+ 2218 | AddressList | 2219 +-----------------------------------------------------------------+ 2220 | PrefixLengthList (optional) | 2221 +-----------------------------------------------------------------+ 2222 | SeqNumList (optional) | 2223 +-----------------------------------------------------------------+ 2224 | MetricTypeList | 2225 +-----------------------------------------------------------------+ 2227 Figure 3: RERR message contents 2229 PktSource 2230 The source address of the IP packet triggering the RERR. If the 2231 RERR is triggered by a broken link, PktSource is not required. 2233 AddressList 2234 The addresses of the routes not available through RERR_Gen. 2236 PrefixLengthList 2237 The prefix lengths, in bits, associated with the routes not 2238 available through RERR_Gen. These values indicate whether routes 2239 represent a single device or an address range. 2241 SeqNumList 2242 The sequence numbers of the routes not available through RERR_Gen 2243 (where known). 2245 MetricTypeList 2246 The metric types associated with the routes not available through 2247 RERR_Gen. 2249 7.4.1. RERR Generation 2251 A Route Error message is generated when an AODVv2 router (also 2252 referred to as RERR_Gen) needs to report that a destination is not 2253 reachable. There are three events that cause this response: 2255 o When an IP packet that has been forwarded from another router, but 2256 cannot be forwarded further because there is no valid route in the 2257 Routing Information Base for its destination, the source of the 2258 packet needs to be informed that the route to the destination of 2259 the packet does not exist. The RERR generated MUST include 2260 PktSource set to the source address of the IP packet, and MUST 2261 contain only one unreachable address in the AddressList, i.e., the 2262 destination address of the IP packet. RERR_Gen MUST discard the 2263 IP packet that triggered generation of the RERR. The prefix 2264 length, sequence number and metric type SHOULD be included if 2265 known from an existing Invalid LocalRoute to the unreachable 2266 address. 2268 o When an RREP message cannot be regenerated because the LocalRoute 2269 to OrigAddr has been lost or is Invalid, RREP_Gen needs to be 2270 informed that the route to OrigAddr does not exist. The RERR 2271 generated MUST include PktSource set to the TargAddr of the RREP, 2272 and MUST contain only one unreachable address in the AddressList, 2273 the OrigAddr from the RREP. RERR_Gen MUST discard the RREP 2274 message that triggered generation of the RERR. The prefix length, 2275 sequence number and metric type SHOULD be included if known from 2276 an Invalid LocalRoute to the unreachable address. 2278 o When a link breaks, multiple LocalRoutes may become Invalid, and 2279 the RERR generated MAY contain multiple unreachable addresses. 2280 The RERR MUST include MetricTypeList. PktSource is omitted. All 2281 previously Active LocalRoutes that used the broken link MUST be 2282 reported. The AddressList, PrefixLengthList, SeqNumList, and 2283 MetricTypeList will contain entries for each LocalRoute which has 2284 become Invalid. An RERR message is only sent if an Active 2285 LocalRoute becomes Invalid, though an AODVv2 router can also 2286 include Idle LocalRoutes that become Invalid if the configuration 2287 parameter ENABLE_IDLE_IN_RERR is set (see Section 10.3). 2289 The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been 2290 reached. The RERR also SHOULD NOT be generated if it is a duplicate, 2291 as determined by Section 6.9. 2293 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2294 from the address of one of its Router Clients, it forwards the ICMP 2295 packet in the same way as any other IP packet, and will not generate 2296 any RERR message based on the contents of the ICMP packet. 2298 To generate the RERR, the router follows this procedure: 2300 1. If necessary, include PktSource and set the value as given above 2302 2. For each LocalRoute that needs to be reported: 2304 * Insert LocalRoute.Address into the AddressList. 2306 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2307 and not equal to the address length. 2309 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2311 * Insert LocalRoute.MetricType into MetricTypeList. 2313 The AODVv2 message is used to create a corresponding [RFC5444] 2314 message (see Section 8). 2316 If the RERR is sent in response to an undeliverable IP packet or RREP 2317 message, i.e., if PktSource is included, the RERR SHOULD be sent 2318 unicast to the next hop on the route to PktSource. It MUST be sent 2319 over the same interface on which the undeliverable IP packet was 2320 received. If there is no route to PktSource, the RERR SHOULD be 2321 multicast to LL-MANET-Routers. If the RERR is sent in response to a 2322 broken link, i.e., PktSource is not included, the RERR is, by 2323 default, multicast to LL-MANET-Routers. 2325 7.4.2. RERR Reception 2327 Upon receiving a Route Error, an AODVv2 router performs the following 2328 steps: 2330 1. Verify that the message contains the required data: at least one 2331 unreachable address 2333 * If not, ignore this RERR for further processing. 2335 2. For each address in the AddressList, check that: 2337 * The address is valid (routable and unicast) 2339 * The MetricType is supported and configured for use 2341 * There is a LocalRoute with the same MetricType matching the 2342 address using longest prefix matching 2344 * Either the LocalRoute's next hop is the sender of the RERR and 2345 the next hop interface is the interface on which the RERR was 2346 received, or PktSource is present in the RERR and is a Router 2347 Client address 2349 * The unreachable address' sequence number is either unknown, or 2350 is greater than the LocalRoute's sequence number 2352 If any of the above are false the address does not match a 2353 LocalRoute and MUST NOT be processed or regenerated in a RERR. 2355 If all of the above are true, the LocalRoute which matches the 2356 address is no longer valid. If the LocalRoute was previously 2357 Active, it MUST be reported in a regenerated RERR. If the 2358 LocalRoute was previously Idle, it MAY be reported in a 2359 regenerated RERR, if ENABLE_IDLE_IN_RERR is configured. The 2360 Local Route Set MUST be updated according to these rules: 2362 * If the LocalRoute's prefix length is the same as the 2363 unreachable address' prefix length, set LocalRoute.State to 2364 Invalid. 2366 * If the LocalRoute's prefix length is longer than the 2367 unreachable address' prefix length, the LocalRoute MUST be 2368 expunged from the Local Route Set, since it is a sub-route of 2369 the route which is reported to be Invalid. 2371 * If the prefix length is different, create a new LocalRoute 2372 with the unreachable address, and its prefix length and 2373 sequence number, and set LocalRoute.State to Invalid. These 2374 Invalid routes are retained to avoid processing stale 2375 messages. 2377 * Update the sequence number on the existing LocalRoute, if the 2378 reported sequence number is determined to be newer using the 2379 comparison technique described in Section 4.4. 2381 3. If there are previously Active LocalRoutes that MUST be reported, 2382 as identified in step 2.: 2384 * Regenerate the RERR as detailed in Section 7.4.3. 2386 7.4.3. RERR Regeneration 2388 The Route Error message SHOULD NOT be regenerated if 2389 CONTROL_TRAFFIC_LIMIT has been reached. 2391 The procedure for RERR regeneration is as follows: 2393 1. If PktSource was included in the original RERR, and PktSource is 2394 not a Router Client, copy it into the regenerated RERR 2396 2. For each LocalRoute that needs to be reported as identified in 2397 Section 7.4.1: 2399 * Insert LocalRoute.Address into the AddressList. 2401 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2402 and not equal to the address length. 2404 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2406 * Insert LocalRoute.MetricType into MetricTypeList. 2408 The AODVv2 message is used to create a corresponding [RFC5444] 2409 message (see Section 8). If the RERR contains PktSource, the 2410 regenerated RERR SHOULD be sent unicast to the next hop on the 2411 LocalRoute to PktSource. It MUST be sent over the same interface on 2412 which the undeliverable IP packet was received. If there is no route 2413 to PktSource, or PktSource is a Router Client, it SHOULD be multicast 2414 to LL-MANET-Routers. If the RERR is sent in response to a broken 2415 link, the RERR is, by default, multicast to LL-MANET-Routers. 2417 8. RFC 5444 Representation 2419 AODVv2 specifies that all control messages between routers MUST use 2420 the Generalized Mobile Ad Hoc Network Packet/Message Format 2421 [RFC5444], and therefore AODVv2's route messages comprise data which 2422 is mapped to message elements in [RFC5444]. 2424 [RFC5444] provides a multiplexed transport for multiple protocols. 2425 An [RFC5444] implementation MAY choose to optimize the content of 2426 certain elements during message creation to reduce control message 2427 overhead. 2429 A brief summary of the [RFC5444] format: 2431 1. A packet contains zero or more messages 2432 2. A message contains a Message Header, one Message TLV Block, zero 2433 or more Address Blocks, and one Address Block TLV Block per 2434 Address Block 2436 3. The Message TLV Block MAY contain zero or more Message TLVs 2438 4. An Address Block TLV Block MAY include zero or more Address Block 2439 TLVs 2441 5. Each TLV value in an Address Block TLV Block can be associated 2442 with all of the addresses, or with a contiguous set of addresses, 2443 or with a single address in the Address Block 2445 AODVv2 does not require access to the [RFC5444] packet header. 2447 In the message header, AODVv2 uses and . 2448 The field indicates the length of any addresses in 2449 the message, using := (address length in octets - 2450 1), i.e. 3 for IPv4 and 15 for IPv6. 2452 The addresses in an Address Block MAY appear in any order, and values 2453 in a TLV in the Address Block TLV Block must be associated with the 2454 correct address in the Address Block by the [RFC5444] implementation. 2455 To indicate which value is associated with each address, the AODVv2 2456 message representation uses lists where the order of the addresses in 2457 the AODVv2 AddressList matches the order of values in other data 2458 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2459 [RFC5444] maps this information to Address Block TLVs associated with 2460 the relevant addresses in the Address Block. 2462 Each address included in the Address Block is identified as OrigAddr, 2463 TargAddr, PktSource, or Unreachable Address by including an 2464 ADDRESS_TYPE TLV in the Address Block TLV Block. 2466 The following sections show how AODVv2 data is represented in 2467 [RFC5444] messages. AODVv2 makes use of the VALIDITY_TIME Address 2468 Block TLV from [RFC5497], and defines (in Section 11) a number of new 2469 TLVs. To calculate the time-value for the VALIDITY_TIME Address 2470 Block TLV, the value of C is defined in Section 10.2. 2472 Where the extension type of a TLV is set to zero, this is the default 2473 [RFC5444] value and the extension type will not be included in the 2474 message. 2476 8.1. Route Request Message Representation 2478 8.1.1. Message Header 2480 +-------+---------------+--------+ 2481 | Data | Header Field | Value | 2482 +-------+---------------+--------+ 2483 | None | | RREQ | 2484 +-------+---------------+--------+ 2486 8.1.2. Message TLV Block 2488 AODVv2 does not define any Message TLVs for an RREQ message. 2490 8.1.3. Address Block 2492 An RREQ contains two addresses, OrigAddr and TargAddr, and each 2493 address has an associated prefix length. If the prefix length has 2494 not been included in the AODVv2 message, it is equal to the address 2495 length in bits. 2497 +-------------------------+------------------------------+ 2498 | Data | Address Block | 2499 +-------------------------+------------------------------+ 2500 | OrigAddr/OrigPrefixLen |
+ | 2501 | TargAddr/TargPrefixLen |
+ | 2502 +-------------------------+------------------------------+ 2504 8.1.4. Address Block TLV Block 2506 Address Block TLVs are always associated with one or more addresses 2507 in the Address Block. The following sections show the TLVs that 2508 apply to each address. 2510 8.1.4.1. Address Block TLVs for OrigAddr 2511 +--------------+---------------+------------+-----------------------+ 2512 | Data | TLV Type | Extension | Value | 2513 | | | Type | | 2514 +--------------+---------------+------------+-----------------------+ 2515 | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | 2516 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2517 | | | | RREQ_Gen, the router | 2518 | | | | which initiated route | 2519 | | | | discovery. | 2520 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2521 | /MetricType | | | route to OrigAddr, | 2522 | | | | using MetricType. | 2523 | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | 2524 | | | | route to OrigAddr, | 2525 | | | | represented as | 2526 | | | | detailed in | 2527 | | | | [RFC5497]. | 2528 +--------------+---------------+------------+-----------------------+ 2530 8.1.4.2. Address Block TLVs for TargAddr 2532 +------------+--------------+-------------+-------------------------+ 2533 | Data | TLV Type | Extension | Value | 2534 | | | Type | | 2535 +------------+--------------+-------------+-------------------------+ 2536 | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | 2537 | TargSeqNum | SEQ_NUM | 0 | The last known | 2538 | | | | TargSeqNum for | 2539 | | | | TargAddr. | 2540 +------------+--------------+-------------+-------------------------+ 2542 8.2. Route Reply Message Representation 2544 8.2.1. Message Header 2546 +-------+---------------+--------+ 2547 | Data | Header Field | Value | 2548 +-------+---------------+--------+ 2549 | None | | RREP | 2550 +-------+---------------+--------+ 2552 8.2.2. Message TLV Block 2554 AODVv2 does not define any Message TLVs for an RREP message. 2556 8.2.3. Address Block 2558 An RREP contains a minimum of two addresses, OrigAddr and TargAddr, 2559 and each address has an associated prefix length. If the prefix 2560 length has not been included in the AODVv2 message, it is equal to 2561 the address length in bits. 2563 It MAY also contain the address of the intended next hop, in order to 2564 request acknowledgement to confirm bidirectionality of the link, as 2565 described in Section 6.2. The prefix length associated with this 2566 address is equal to the address length in bits. 2568 +-------------------------+------------------------------+ 2569 | Data | Address Block | 2570 +-------------------------+------------------------------+ 2571 | OrigAddr/OrigPrefixLen |
+ | 2572 | TargAddr/TargPrefixLen |
+ | 2573 | AckReq |
+ | 2574 +-------------------------+------------------------------+ 2576 8.2.4. Address Block TLV Block 2578 Address Block TLVs are always associated with one or more addresses 2579 in the Address Block. The following sections show the TLVs that 2580 apply to each address. 2582 8.2.4.1. Address Block TLVs for OrigAddr 2584 +-------+---------------+-----------------+--------------------+ 2585 | Data | TLV Type | Extension Type | Value | 2586 +-------+---------------+-----------------+--------------------+ 2587 | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | 2588 +-------+---------------+-----------------+--------------------+ 2590 8.2.4.2. Address Block TLVs for TargAddr 2591 +--------------+---------------+------------+-----------------------+ 2592 | Data | TLV Type | Extension | Value | 2593 | | | Type | | 2594 +--------------+---------------+------------+-----------------------+ 2595 | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | 2596 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2597 | | | | RREP_Gen, the router | 2598 | | | | which created the | 2599 | | | | RREP. | 2600 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2601 | /MetricType | | | route to TargAddr, | 2602 | | | | using MetricType. | 2603 | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | 2604 | | | | route to TargAddr, | 2605 | | | | represented as | 2606 | | | | detailed in | 2607 | | | | [RFC5497]. | 2608 +--------------+---------------+------------+-----------------------+ 2610 8.2.4.3. Address Block TLVs for AckReq Intended Recipient Address 2612 +-------+---------------+-----------------+------------------+ 2613 | Data | TLV Type | Extension Type | Value | 2614 +-------+---------------+-----------------+------------------+ 2615 | None | ADDRESS_TYPE | 0 | ADDRTYPE_INTEND | 2616 +-------+---------------+-----------------+------------------+ 2618 8.3. Route Reply Acknowledgement Message Representation 2620 8.3.1. Message Header 2622 +-------+---------------+-----------+ 2623 | Data | Header Field | Value | 2624 +-------+---------------+-----------+ 2625 | None | | RREP_Ack | 2626 +-------+---------------+-----------+ 2628 8.3.2. Message TLV Block 2630 AODVv2 does not define any Message TLVs for an RREP_ack message. 2632 8.3.3. Address Block 2634 AODVv2 does not define an Address Block for an RREP_Ack message. 2636 8.3.4. Address Block TLV Block 2638 AODVv2 does not define any Address Block TLVs for an RREP_Ack 2639 message. 2641 8.4. Route Error Message Representation 2643 Route Error Messages MAY be split into multiple [RFC5444] messages 2644 when the desired contents would exceed the MTU. However, all of the 2645 resulting messages MUST have the same message header as described 2646 below. If PktSource is included in the AODVv2 message, it MUST be 2647 included in all of the resulting [RFC5444] messages. 2649 8.4.1. Message Header 2651 +-------+---------------+--------+ 2652 | Data | Header Field | Value | 2653 +-------+---------------+--------+ 2654 | None | | RERR | 2655 +-------+---------------+--------+ 2657 8.4.2. Message TLV Block 2659 AODVv2 does not define any Message TLVs for an RERR message. 2661 8.4.3. Address Block 2663 The Address Block in an RERR MAY contain PktSource, the source 2664 address of the IP packet triggering RERR generation, as detailed in 2665 Section 7.4. The prefix length associated with PktSource is equal to 2666 the address length in bits. 2668 Address Block always contains one address per route that is no longer 2669 valid, and each address has an associated prefix length. If a prefix 2670 length has not been included for this address, it is equal to the 2671 address length in bits. 2673 +------------------------------+------------------------------------+ 2674 | Data | Address Block | 2675 +------------------------------+------------------------------------+ 2676 | PktSource |
+ for | 2677 | | PktSource | 2678 | AddressList/PrefixLengthList |
+ for | 2679 | | each unreachable address in | 2680 | | AddressList | 2681 +------------------------------+------------------------------------+ 2683 8.4.4. Address Block TLV Block 2685 Address Block TLVs are always associated with one or more addresses 2686 in the Address Block. The following sections show the TLVs that 2687 apply to each type of address in the RERR. 2689 8.4.4.1. Address Block TLVs for PktSource 2691 +------------+---------------+----------------+---------------------+ 2692 | Data | TLV Type | Extension Type | Value | 2693 +------------+---------------+----------------+---------------------+ 2694 | PktSource | ADDRESS_TYPE | 0 | ADDRTYPE_PKTSOURCE | 2695 +------------+---------------+----------------+---------------------+ 2697 8.4.4.2. Address Block TLVs for Unreachable Addresses 2699 +----------------+--------------+------------+----------------------+ 2700 | Data | TLV Type | Extension | Value | 2701 | | | Type | | 2702 +----------------+--------------+------------+----------------------+ 2703 | None | ADDRESS_TYPE | 0 | ADDRTYPE_UNREACHABLE | 2704 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2705 | | | | associated with | 2706 | | | | invalid route to the | 2707 | | | | unreachable address. | 2708 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2709 | | | | set to MetricType of | 2710 | | | | the route to the | 2711 | | | | unreachable address. | 2712 +----------------+--------------+------------+----------------------+ 2714 9. Simple External Network Attachment 2716 Figure 4 shows a stub (i.e., non-transit) network of AODVv2 routers 2717 which is attached to an external network via a single External 2718 Network Access Router (ENAR). The interface to the external network 2719 MUST NOT be configured in the InterfaceSet. 2721 As in any externally-attached network, AODVv2 routers and Router 2722 Clients that wish to be reachable from the external network MUST have 2723 IP addresses within the ENAR's routable and topologically correct 2724 prefix (e.g., 191.0.2.0/24 in Figure 4). This AODVv2 network and 2725 networks attached to routers within it will be advertised to the 2726 external network using procedures which are out of scope for this 2727 specification. 2729 /-------------------------\ 2730 / +----------------+ \ 2731 / | AODVv2 Router | \ 2732 | | 191.0.2.2/32 | | 2733 | +----------------+ | Routable 2734 | +-----+--------+ Prefix 2735 | | ENAR | /191.0.2.0/24 2736 | | AODVv2 Router| / 2737 | | 191.0.2.1 |/ /---------------\ 2738 | | serving net +------+ External \ 2739 | | 191.0.2.0/24 | \ Network / 2740 | +-----+--------+ \---------------/ 2741 | +----------------+ | 2742 | | AODVv2 Router | | 2743 | | 191.0.2.3/32 | | 2744 \ +----------------+ / 2745 \ / 2746 \-------------------------/ 2748 Figure 4: Simple External Network Attachment Example 2750 When an AODVv2 router within the AODVv2 MANET wants to discover a 2751 route toward an address on the external network, it uses the normal 2752 AODVv2 route discovery for that IP Destination Address. The ENAR 2753 MUST respond to RREQ on behalf of all external network destinations, 2754 e.g., destinations not on the configured 191.0.2.0/24 network. RREQs 2755 for addresses inside the AODVv2 network, e.g. destinations on the 2756 configured 191.0.2.0/24 network, are handled using the standard 2757 processes described in Section 7. Note that AODvv2 does not support 2758 RREQs for prefixes that do not equal address length. 2760 When an IP packet from an address on the external network destined 2761 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2762 not have a route toward that destination in its Routing Information 2763 Base, it will perform normal AODVv2 route discovery for that 2764 destination. 2766 Configuring the ENAR as a default router is outside the scope of this 2767 specification. 2769 10. Configuration 2771 AODVv2 uses various parameters which can be grouped into the 2772 following categories: 2774 o Timers 2776 o Protocol constants 2777 o Administrative parameters and controls 2779 This section show the parameters along with their definitions and 2780 default values (if any). 2782 Note that several fields have limited size (bits or bytes). These 2783 sizes and their encoding may place specific limitations on the values 2784 that can be set. 2786 10.1. Timers 2788 AODVv2 requires certain timing information to be associated with 2789 Local Route Set entries and message replies. The default values are 2790 as follows: 2792 +------------------------+----------------+ 2793 | Name | Default Value | 2794 +------------------------+----------------+ 2795 | ACTIVE_INTERVAL | 5 second | 2796 | MAX_IDLETIME | 200 seconds | 2797 | MAX_BLACKLIST_TIME | 200 seconds | 2798 | MAX_SEQNUM_LIFETIME | 300 seconds | 2799 | RERR_TIMEOUT | 3 seconds | 2800 | RteMsg_ENTRY_TIME | 12 seconds | 2801 | RREQ_WAIT_TIME | 2 seconds | 2802 | RREP_Ack_SENT_TIMEOUT | 1 second | 2803 | RREQ_HOLDDOWN_TIME | 10 seconds | 2804 +------------------------+----------------+ 2806 Table 2: Timing Parameter Values 2808 The above timing parameter values have worked well for small and 2809 medium well-connected networks with moderate topology changes. The 2810 timing parameters SHOULD be administratively configurable. Ideally, 2811 for networks with frequent topology changes the AODVv2 parameters 2812 SHOULD be adjusted using experimentally determined values or dynamic 2813 adaptation. For example, in networks with infrequent topology 2814 changes MAX_IDLETIME MAY be set to a much larger value. If the 2815 values were configured differently, the following consequences may be 2816 observed: 2818 o If MAX_SEQNUM_LIFETIME was configured differently across the 2819 network, and any of the routers lost their sequence number or 2820 rebooted, this could result in their next route messages being 2821 classified as stale at any AODVv2 router using a greater value for 2822 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to 2823 the re-initializing router. 2825 o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will 2826 invalidate routes more quickly and free resources used to maintain 2827 them. This can affect bursty traffic flows which have quiet 2828 periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which 2829 has timed out due to perceived inactivity is not reported. When 2830 the bursty traffic resumes, it would cause a RERR to be generated, 2831 and the traffic itself would be dropped. This route would be 2832 removed from all upstream routers, even if those upstream routers 2833 had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route 2834 discovery would be required to re-establish the route, causing 2835 extra routing protocol traffic and disturbance to the bursty 2836 traffic. 2838 o Routers with lower values for MAX_BLACKLIST_TIME would allow 2839 neighboring routers to participate in route discovery sooner than 2840 routers with higher values. This could result in failed route 2841 discoveries if un-blacklisted links are still uni-directional. 2842 Since RREQs are retried, this would not affect success of route 2843 discovery unless this value was so small as to un-blacklist the 2844 router before the RREQ is retried. This value need not be 2845 consistent across the network since it is used for maintaining a 2846 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME. 2848 o Routers with lower values for RERR_TIMEOUT may create more RERR 2849 messages than routers with higher values. This value should be 2850 large enough that a RERR will reach all routers using the route 2851 reported within it before the timer expires, so that no further 2852 data traffic will arrive, and no duplicated RERR messages will be 2853 generated. 2855 o Routers with lower values for RteMsg_ENTRY_TIME may not consider 2856 received redundant multicast route messages as redundant, and may 2857 regenerate these messages unnecessarily. 2859 o Routers with lower values for RREQ_WAIT_TIME may send more 2860 frequent RREQ messages and wrongly determine that a route does not 2861 exist, if the delay in receiving an RREP is greater than this 2862 interval. 2864 o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly 2865 determine links to neighbors to be unidirectional if an RREP_Ack 2866 is delayed longer than this timeout. 2868 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed 2869 route discoveries sooner than routers with higher values. This 2870 may be an advantage if the network topology is frequently 2871 changing, or may unnecessarily cause more routing protocol 2872 traffic. 2874 MAX_SEQNUM_LIFETIME MUST be configured to have the same values for 2875 all AODVv2 routers in the network. 2877 10.2. Protocol Constants 2879 AODVv2 protocol constants typically do not require changes. The 2880 following table lists these constants, along with their values and a 2881 reference to the section describing their use. 2883 +------------------------+---------+--------------------------------+ 2884 | Name | Default | Description | 2885 +------------------------+---------+--------------------------------+ 2886 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 2887 | RREP_RETRIES | 2 | Section 7.2.1 | 2888 | MAX_METRIC[MetricType] | [TBD] | Section 5 | 2889 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 2890 | INFINITY_TIME | [TBD] | Maximum expressible clock time | 2891 | | | (Section 6.7.2) | 2892 | C | 1/1024 | Constant used in validity time | 2893 | | | calculation [RFC5497] | 2894 +------------------------+---------+--------------------------------+ 2896 Table 3: AODVv2 Constants 2898 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 2899 value of type MetricType. Field lengths associated with metric 2900 values are found in Section 10.5. 2902 These protocol constants MUST have the same values for all AODVv2 2903 routers in the ad hoc network. If the values were configured 2904 differently, the following consequences may be observed: 2906 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 2907 be more successful at finding routes, at the cost of additional 2908 control traffic. 2910 o RREP_RETRIES: Routers with lower values are more likely to 2911 blacklist neighbors when there is a temporary fluctuation in link 2912 quality. 2914 o MAX_METRIC[MetricType]: No interoperability problems due to 2915 variations on different routers, but routers with lower values may 2916 exhibit overly restrictive behavior during route comparisons. 2918 o INFINITY_TIME: No interoperability problems due to variations on 2919 different routers, but if a lower value is used, route state 2920 management may exhibit overly restrictive behavior. 2922 o C: Routers with lower values will invalidate timed routes before 2923 routers with higher values, which will cause Route Error messages 2924 to be generated and the route will effectively take on the shorter 2925 validity time. 2927 10.3. Local Settings 2929 The following table lists AODVv2 parameters which SHOULD be 2930 administratively configured for each router: 2932 +------------------------+------------------------+--------------+ 2933 | Name | Default Value | Description | 2934 +------------------------+------------------------+--------------+ 2935 | InterfaceSet | | Section 4.1 | 2936 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 2937 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 2938 | CONTROL_TRAFFIC_LIMIT | [TBD - 50 pkts/sec?] | Section 7 | 2939 +------------------------+------------------------+--------------+ 2941 Table 4: Configuration for Local Settings 2943 10.4. Network-Wide Settings 2945 The following administrative controls MAY be used to change the 2946 operation of the network. The same settings SHOULD be used across 2947 the network. Inconsistent settings at different routers in the 2948 network will not result in protocol errors, but poor performance may 2949 result. 2951 +----------------------+-----------+----------------+ 2952 | Name | Default | Description | 2953 +----------------------+-----------+----------------+ 2954 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 2955 +----------------------+-----------+----------------+ 2957 Table 5: Configuration for Network-Wide Settings 2959 10.5. MetricType Allocation 2961 The metric types used by AODVv2 are identified according to a new 2962 table to be created and maintained by IANA. All implementations MUST 2963 use these values. 2965 +---------------------+----------+--------------------+ 2966 | Name of MetricType | Type | Metric Value Size | 2967 +---------------------+----------+--------------------+ 2968 | Unassigned | 0 | Undefined | 2969 | Hop Count | 1 | 1 octet | 2970 | Unallocated | 2 - 254 | TBD | 2971 | Reserved | 255 | Undefined | 2972 +---------------------+----------+--------------------+ 2974 Table 6: AODVv2 Metric Types 2976 11. IANA Considerations 2978 This section specifies several [RFC5444] message types and address 2979 tlv-types required for AODVv2. 2981 11.1. RFC 5444 Message Types 2983 This specification defines four Message Types, to be allocated from 2984 the 0-223 range of the "Message Types" namespace defined in 2985 [RFC5444], as specified in Table 7. 2987 +-----------------------------------------+-----------+ 2988 | Name of Message | Type | 2989 +-----------------------------------------+-----------+ 2990 | Route Request (RREQ) | 10 (TBD) | 2991 | Route Reply (RREP) | 11 (TBD) | 2992 | Route Error (RERR) | 12 (TBD) | 2993 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 2994 +-----------------------------------------+-----------+ 2996 Table 7: AODVv2 Message Types 2998 11.2. RFC 5444 Address Block TLV Types 3000 This specification defines three Address Block TLV Types, to be 3001 allocated from the "Address Block TLV Types" namespace defined in 3002 [RFC5444], as specified in Table 8. 3004 +------------------------+----------+---------------+---------------+ 3005 | Name of TLV | Type | Length | Reference | 3006 | | | (octets) | | 3007 +------------------------+----------+---------------+---------------+ 3008 | PATH_METRIC | 11 (TBD) | depends on | Section 7 | 3009 | | | MetricType | | 3010 | SEQ_NUM | 12 (TBD) | 2 | Section 7 | 3011 | ADDRESS_TYPE | 13 (TBD) | 1 | Section 8 | 3012 +------------------------+----------+---------------+---------------+ 3014 Table 8: AODVv2 Address Block TLV Types 3016 11.3. ADDRESS_TYPE TLV Values 3018 These values are used in the [RFC5444] Address Type TLV discussed in 3019 Section 8. All implementations MUST use these values. 3021 +---------------+--------+ 3022 | Address Type | Value | 3023 +---------------+--------+ 3024 | ORIGADDR | 0 | 3025 | TARGADDR | 1 | 3026 | UNREACHABLE | 2 | 3027 | PKTSOURCE | 3 | 3028 | INTEND | 4 | 3029 | UNSPECIFIED | 255 | 3030 +---------------+--------+ 3032 Table 9: AODVv2 Address Types 3034 12. Security Considerations 3036 This section describes various security considerations and potential 3037 avenues to secure AODVv2 routing. The main objective of the AODVv2 3038 protocol is for each router to communicate reachability information 3039 about addresses for which it is responsible, and for routes it has 3040 learned from other AODVv2 routers. 3042 Networks using AODVv2 to maintain connectivity and establish routes 3043 on demand may be vulnerable to certain well-known types of threats, 3044 which will be detailed in the following. Some of the threats 3045 described can be mitigated or eliminated. Tools to do so will be 3046 described also. 3048 Since route messages are regenerated at each router, AODVv2 assumes a 3049 security model of transitive trust. The sender of a message MUST be 3050 trusted in order for receiving one-hop neighbours to store the 3051 routing information it provides and regenerate the message to their 3052 own one-hop neighbours. 3054 Routes are installed based on information received from trusted 3055 neighbours. Therefore a chain of trust back to the originator of a 3056 message is assumed by any router using the routing information 3057 received. 3059 Since messages are regenerated rather than forwarded, the message 3060 concepts known as RREQ, RREP and RERR do not travel as a single 3061 unchanged entity between source and destination, and therefore 3062 message integrity cannot be assured end-to-end between OrigAddr and 3063 TargAddr. 3065 The on-demand nature of AODVv2 route discovery automatically reduces 3066 the vulnerability to route disruption. Since control traffic for 3067 updating route tables is diminished, there is less opportunity for 3068 attack and failure. 3070 12.1. Availability 3072 Threats to AODVv2 which reduce availability are considered below. 3074 12.1.1. Denial of Service 3076 Flooding attacks using RREQ amount to a (BLIND) denial of service for 3077 route discovery: By issuing RREQ messages for targets that don't 3078 exist, an attacker can flood the network, blocking resources and 3079 drowning out legitimate traffic. The effect of this attack is 3080 dampened by the fact that duplicate RREQ messages are dropped 3081 (preventing the network from DDoSing itself). Processing 3082 requirements for AODVv2 messages are typically quite small, however 3083 AODVv2 routers receiving RREQs do allocate resources in the form of 3084 Neighbor Set, Local Route Set and Multicast Route Message Set 3085 entries. The attacker can maximize their impact on set growth by 3086 changing OrigAddr for each RREQ. If a specific node is to be 3087 targeted, this attack may be carried out in a DISTRIBUTED fashion, 3088 either by compromising its direct neighbors or by specifying the 3089 target's address as TargAddr. Note that it might be more economical 3090 for the attacker to simply jam the medium; an attack which AODVv2 3091 cannot defend itself against. 3093 Mitigation: 3095 o If AODVv2 routers always verify that the sender of the RERR 3096 message is trusted, this threat is reduced. Processing 3097 requirements would typically be dominated by calculations to 3098 verify integrity. This has the effect of reducing (but by no 3099 means eliminating) AODVv2's vulnerability to denial of service 3100 attacks. 3102 o Authentication of senders can prevent foreign nodes from DoSing an 3103 AODVv2 router. However, this does not protect the network if an 3104 attacker has access to an already authorized router. 3106 12.1.2. Malicious RERR messages 3108 RERR messages are designed to cause removal of installed routes. A 3109 malicious node could send an RERR message with false information to 3110 attempt to get other routers to remove a route to one or more 3111 specific destinations, therefore disrupting traffic to the advertised 3112 destinations. 3114 Routes will be deleted if an RERR is received, withdrawing a route 3115 for which the sender is the receiver's next hop, and when the RERR 3116 includes the MetricType of the installed route, and includes either 3117 no sequence number for the route, or includes a greater sequence 3118 number than the sequence number stored with that route in the 3119 receiver's Local Route Set. Routes will also be deleted if a received 3120 RERR contains a PktSource address corresponding to a Router Client. 3122 The information necessary to construct a malicious RERR could be 3123 learned by eavesdropping, either by listening to AODVv2 messages or 3124 by watching data packet flows. 3126 Since the RERR is multicast, it can be received by many routers in 3127 the ad hoc network, and will be regenerated when processing results 3128 in an active route being removed. This threat could have serious 3129 impact on applications communicating by way of the sender of the RERR 3130 message. 3132 o The set of routers which use the malicious router as a next hop 3133 may be targeted with a malicious RERR with no PktSource address 3134 included, if the RERR contains routes for which the malicious 3135 router is a next hop from the receiving router. However, since 3136 the sender of the RERR message is either malicious or broken, it 3137 is better that it is not used as a next hop for these routes 3138 anyway. 3140 o A single router which does not use the malicious router as part of 3141 its route may be targeted with a malicious RERR with a PktSource 3142 address included. 3144 o Replayed RERR messages could be used to disrupt active routes. 3146 Mitigation: 3148 o Protection against eavesdropping of AODVv2 messages would mitigate 3149 this attack to some extent, but eavesdropping of data packets can 3150 also be used to deduce the information about which routes could be 3151 targeted. 3153 o Protection against a malicious router becoming part of a route 3154 will mitigate the attack where a set of routers are targeted. 3155 This will not protect against the attack if a PktSource address is 3156 included. 3158 o By only regenerating RERR messages where active routes are 3159 removed, the spread of the malicious RERR is limited. 3161 o Including sequence numbers in RERR messages offers protection 3162 against attacks using replays of these RERR messages. 3164 o If AODVv2 routers always verify that the sender of the RERR 3165 message is trusted, this threat is reduced. 3167 12.1.3. False Confirmation of Link Bidirectionality 3169 Links could be erroneously treated as bidirectional if malicious 3170 unsolicited or spoofed RREP messages were to be accepted. This would 3171 result in a route being installed which could not in fact be used to 3172 forward data to the destination, and may divert data packets away 3173 from the intended destination. 3175 There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which 3176 any malicious router could send an RREP in response, in order for the 3177 link to the malicious router to be deemed as bidirectional. 3179 Mitigation: 3181 o Ignoring unsolicited RREP and RREP_Ack messages partially 3182 mitigates against this threat. 3184 o If AODVv2 routers always verify that the sender of the RERR 3185 message is trusted, this threat is reduced. 3187 12.1.4. Message Deletion 3189 A malicious router could decide not to regenerate a RREQ or RREP or 3190 RERR message. Not regenerating a RERR or RREP message would disrupt 3191 route discovery. Not regenerating a RERR message would result in the 3192 source of data packets continuing to maintain and use the route, and 3193 further RERR messages being generated by the sender of the non- 3194 regenerated RERR. A malicious router could intentionally disrupt 3195 traffic flows by not allowing the source of data traffic to re- 3196 discover a new route when one breaks. 3198 Failing to send a RREP_Ack would also disrupt route establishment, by 3199 not allowing the reverse route to be validated. Return traffic which 3200 needs that route will prompt a new route discovery, wasting resources 3201 and incurring a slight delay but not disrupting the ability for 3202 applications to communicate. 3204 Mitigation: 3206 o None. also note that malicious router would have to wait for a 3207 route to break before it could perform this attack. 3209 12.2. Confidentiality 3211 Passive inspection (eavesdropping) of AODVv2 control messages could 3212 enable unauthorized devices to gain information about the network 3213 topology, since exchanging such information is the main purpose of 3214 AODVv2. 3216 Eavesdropping of data traffic could allow a malicious device to 3217 obtain information about how data traffic is being routed. With 3218 knowledge of source and destination addresses, malicious messages 3219 could be constructed to disrupt normal operation. 3221 12.3. Integrity 3223 Integrity of route information can be compromised in the following 3224 types of attack: 3226 12.3.1. Message Insertion 3228 Valid route set entries can be replaced or modified by maliciously 3229 constructed AODVv2 messages, destroying existing routes and the 3230 network's integrity. Any router may pose as another router by 3231 sending RREQ, RREP, RREP_Ack and RERR messages in its name. 3233 o Sending an RREQ message with false information can disrupt traffic 3234 to OrigAddr, if the sequence number attached is not stale compared 3235 to any existing information about OrigAddr. Since RREQ is 3236 multicast and likely to be received by all routers in the ad hoc 3237 network, this threat could have serious impact on applications 3238 communicating with OrigAddr. The actual threat to disrupt routes 3239 to OrigAddr is reduced by the AODVv2 mechanism of marking RREQ- 3240 derived routes as "Unconfirmed" until the link to the next hop is 3241 confirmed. 3243 o Sending an RREP message with false information can disrupt traffic 3244 to TargAddr. Since RREP is unicast, and ignored if a 3245 corresponding RREQ was not recently sent, this threat is 3246 minimized, and is restricted to receivers along the path from 3247 OrigAddr to TargAddr. 3249 o Sending an RREP_Ack message with false information can cause the 3250 route advertised to a target address in an RREP to be erroneously 3251 accepted even though the route would contain a unidirectional link 3252 and thus not be suitable for most traffic. Since RREP_Ack is 3253 unicast, and ignored if a RREP was not sent recently to the sender 3254 of the RREP_Ack, this threat is minimized and is strictly local to 3255 the RREP transmitter expecting the acknowledgement. Unsolicited 3256 RREP_Acks are ignored. 3258 o Sending an RERR message with false information is discussed in 3259 Section 12.1.2. 3261 Mitigation: * If AODVv2 routers always verify that the sender of a 3262 message is trusted, this threat is reduced. 3264 12.3.2. Message Modification - Man in the Middle 3266 Any AODVv2 router can regenerate messages with modified data. 3268 Mitigation: 3270 o If AODVv2 routers verify the integrity of AODVv2 messages, then 3271 the threat of disruption is minimized. A man in the middle with 3272 no knowledge of the shared secret key used to calculate an 3273 integrity check value MAY modify a message but the message will be 3274 rejected when it fails an integrity check. 3276 12.3.3. Replay Attacks 3278 Replaying of RREQ or RREP messages would be of less use to an 3279 attacker, since they would be dropped immediately due to their stale 3280 sequence number. RERR messages MAY or MAY NOT include sequence 3281 numbers and are therefore susceptible to replay attacks. RREP_Ack 3282 messages do not include sequence numbers and are therefore 3283 susceptible to replay attacks. 3285 Mitigation: 3287 o Use of timestamps or sequence numbers prevents replay attacks. 3289 12.4. Protection Mechanisms 3291 12.4.1. Confidentiality and Authentication 3293 Encryption MAY be used for AODVv2 messages. If the routers share a 3294 packet-level security association, the message data can be encrypted 3295 prior to message transmission. The establishment of such security 3296 associations is outside the scope of this specification. Encryption 3297 will not only protect against unauthorized devices obtaining 3298 information about network topology (eavesdropping) but will ensure 3299 that only trusted routers participate in routing operations. 3301 12.4.2. Integrity and Trust using ICVs 3303 Cryptographic Integrity Check Values (ICVs) can be used to ensure 3304 integrity of received messages, protecting against man in the middle 3305 attacks. Further, by using ICVs, only those routers with knowledge 3306 of a shared secret key are allowed to participate in routing 3307 information exchanges. [RFC7182] defines ICV TLVs for use with 3308 [RFC5444]. 3310 The data contained in AODVv2 routing protocol messages MUST be 3311 verified using Integrity Check Values, to avoid the use of message 3312 data if the message has been tampered with. 3314 The method of distribution of shared secret keys is out of the scope 3315 of this protocol. Key management is not specified for the following 3316 reasons: 3318 12.4.3. Replay Protection using Timestamps 3320 Replay attacks MUST be prevented by using timestamps or sequence 3321 numbers in messages. [RFC7182] defines a TIMESTAMP TLV for use with 3322 [RFC5444]. 3324 The data contained in AODVv2 routing protocol messages MUST be 3325 protected with a TIMESTAMP value to ensure the protection against 3326 replaying of the message. Sequence numbers can be used as 3327 timestamps, since they are known to be strictly increasing. 3329 12.4.4. Application to AODVv2 3331 Implementations of AODVv2 MUST support ICV TLVs using type-extensions 3332 1 and 2, hash-function HASH_FUNCTION, and cryptographic function 3333 CRYPTOGRAPHIC_FUNCTION. An ICV MUST be included with every message. 3334 The ICV value MAY be truncated as specified in [RFC7182]. 3336 Implementations of AODVv2 MUST support a TIMESTAMP TLV using type- 3337 extension 0. The timestamp used is a sequence number, and therefore 3338 the length of the field matches the AODVv2 sequence 3339 number defined in Section 4.4. The TIMESTAMP TLV MUST be included in 3340 RREP_Ack and RERR messages. 3342 When more than one message is included in an RFC5444 packet, using a 3343 single ICV Packet TLV or single TIMESTAMP Packet TLV is more 3344 efficient than including ICV and TIMESTAMP Message TLVs in each 3345 message created. In this case, the RFC5444 multiplexer MUST be 3346 instructed to include the Packet TLVs in packets containing AODVv2 3347 messages, or MUST be selected because it always performs these 3348 additions. If the multiplexer is not capable of adding the Packet 3349 TLVs, the TLVs MUST be included as Message TLVs in each AODVv2 3350 message in the packet. 3352 After message generation but before transmission, the ICV and 3353 TIMESTAMP TLVs MUST be added according to each message type as 3354 detailed in the following sections. The following steps list the 3355 generic procedure to be performed: 3357 1. The considerations in Section 8 of [RFC7182] are followed, 3358 removing existing ICV TLVs and adjusting the size and flags 3359 fields. 3361 2. The ICV is calculated over the fields specified below, depending 3362 on message type. This value MAY be truncated (as specified in 3363 [RFC7182]). 3365 3. If the TIMESTAMP is to be included, add the TIMESTAMP TLV, 3366 updating size fields as necessary. 3368 4. Add the ICV TLV, updating size fields as necessary. 3370 5. The changes made in Step 1 are reversed to re-add any existing 3371 ICV TLVs and adjusting the size and flags fields. 3373 The ICV MUST be verified at the receiver. Verification of a received 3374 ICV value is performed by repeating Step 1 and Step 2. If the ICV 3375 value calculated from the received message or packet does not match 3376 the value of in the received message or packet, the 3377 validation fails and the AODVv2 message MUST be discarded. 3379 Verification of a received TIMESTAMP value is performed differently 3380 depending on message type. 3382 12.4.4.1. RREQ Generation and Reception 3384 Since OrigAddr is included in the RREQ, the ICV can be calculated and 3385 verified using all of the message contents. This provides message 3386 integrity and endpoint authentication, because trusted routers MUST 3387 hold the shared key in order to calculate the ICV value. The ICV TLV 3388 has type extension := 1. 3390 Since RREQ_Gen's sequence number is incremented for each new RREQ, 3391 replay protection is already afforded and no extra timestamp 3392 mechanism is required. 3394 12.4.4.2. RREP Generation and Reception 3396 Since TargAddr is included in the RREP, the ICV can be calculated and 3397 verified using all of the message contents. This provides message 3398 integrity and endpoint authentication, because trusted routers MUST 3399 hold the shared key in order to calculate the ICV value. The ICV TLV 3400 has type extension := 1. 3402 Since RREP_Gen's sequence number is incremented for each new RREP, 3403 replay protection is afforded and no extra timestamp mechanism is 3404 required. 3406 12.4.4.3. RREP_Ack Generation and Reception 3408 The RREP_Gen uses the source IP address of the RREP_Ack to identify 3409 the sender to look up whether the RREP_Ack is expected and update the 3410 Neighbor Set, and so the ICV MUST be calculated using the message 3411 contents and the IP source address. The ICV TLV has type extension 3412 := 2 in order to accomplish this. This provides message integrity 3413 and endpoint authentication, because trusted routers MUST hold the 3414 shared key in order to calculate the ICV value. 3416 The message MUST also include a timestamp to protect against replay 3417 attacks, using TargSeqNum from the RREP as the value in the TIMESTAMP 3418 TLV. Verification of a received TIMESTAMP value is performed by 3419 comparing the sequence number in the field with the 3420 sequence number in a recently sent RREP awaiting acknowledgement from 3421 the sender of the RREP_Ack. If the sequence number is not equal, the 3422 AODVv2 message MUST be discarded. 3424 12.4.4.4. RERR Generation and Reception 3426 The receiver of the RERR MUST use the source IP address of the RERR 3427 to identify the sender to look up routes using that sender as next 3428 hop, and so the ICV MUST be calculated using the message contents and 3429 the IP source address. The ICV TLV has type extension := 2 in order 3430 to accomplish this. This provides message integrity and endpoint 3431 authentication, because trusted routers MUST hold the shared key in 3432 order to calculate the ICV value. 3434 The message MUST also include a timestamp to protect against replay 3435 attacks, incrementing and using RERR_Gen's sequence number as the 3436 value in the TIMESTAMP TLV. Verification of a received TIMESTAMP 3437 value is performed by comparing the sequence number in the 3438 field with the last seen sequence number from the 3439 sender of the RERR. If the sequence number is not greater, the 3440 AODVv2 message MUST be discarded. 3442 13. Acknowledgments 3444 AODVv2 is a descendant of the design of previous MANET on-demand 3445 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3446 previous MANET on-demand protocols stem from research and 3447 implementation experiences. Thanks to Elizabeth Belding and Ian 3448 Chakeres for their long time authorship of AODV. Additional thanks 3449 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3450 Thomas Clausen, Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, 3451 Ulrich Herberg, Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, 3452 Lars Kristensen, Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, 3453 Keyur Patel, Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro 3454 Ruiz, Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi, 3455 Seung Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2 3456 and DYMO, as well as numerous specification suggestions. 3458 14. References 3460 14.1. Normative References 3462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3463 Requirement Levels", BCP 14, RFC 2119, 3464 DOI 10.17487/RFC2119, March 1997, 3465 . 3467 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3468 Demand Distance Vector (AODV) Routing", RFC 3561, 3469 DOI 10.17487/RFC3561, July 2003, 3470 . 3472 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3473 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3474 2006, . 3476 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 3477 Pignataro, "The Generalized TTL Security Mechanism 3478 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 3479 . 3481 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 3482 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 3483 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 3484 . 3486 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 3487 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 3488 DOI 10.17487/RFC5497, March 2009, 3489 . 3491 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 3492 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 3493 2009, . 3495 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 3496 and D. Barthel, "Routing Metrics Used for Path Calculation 3497 in Low-Power and Lossy Networks", RFC 6551, 3498 DOI 10.17487/RFC6551, March 2012, 3499 . 3501 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 3502 Check Value and Timestamp TLV Definitions for Mobile Ad 3503 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 3504 April 2014, . 3506 14.2. Informative References 3508 [I-D.perkins-irrep] 3509 Perkins, C., "Intermediate RREP for dynamic MANET On- 3510 demand (AODVv2) Routing", draft-perkins-irrep-03 (work in 3511 progress), May 2015. 3513 [Koodli01] 3514 Koodli, R. and C. Perkins, "Fast handovers and context 3515 transfers in mobile networks", Proceedings of the ACM 3516 SIGCOMM Computer Communication Review 2001, Volume 31 3517 Issue 5, 37-47, October 2001. 3519 [Perkins94] 3520 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 3521 Sequenced Distance-Vector Routing (DSDV) for Mobile 3522 Computers", Proceedings of the ACM SIGCOMM '94 Conference 3523 on Communications Architectures, Protocols and 3524 Applications, London, UK, pp. 234-244, August 1994. 3526 [Perkins99] 3527 Perkins, C. and E. Royer, "Ad hoc On-Demand Distance 3528 Vector (AODV) Routing", Proceedings of the 2nd IEEE 3529 Workshop on Mobile Computing Systems and Applications, New 3530 Orleans, LA, pp. 90-100, February 1999. 3532 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 3533 (MANET): Routing Protocol Performance Issues and 3534 Evaluation Considerations", RFC 2501, 3535 DOI 10.17487/RFC2501, January 1999, 3536 . 3538 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3539 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3540 . 3542 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 3543 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 3544 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 3545 . 3547 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3548 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3549 DOI 10.17487/RFC4861, September 2007, 3550 . 3552 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 3553 Considerations in Mobile Ad Hoc Networks (MANETs)", 3554 RFC 5148, DOI 10.17487/RFC5148, February 2008, 3555 . 3557 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 3558 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 3559 RFC 6130, DOI 10.17487/RFC6130, April 2011, 3560 . 3562 [Sholander02] 3563 Sholander, P., Coccoli, P., Oakes, T., and S. Swank, "A 3564 Portable Software Implementation of a Hybrid MANET Routing 3565 Protocol", 2002. 3567 Appendix A. AODVv2 Draft Updates 3569 This section lists the changes between AODVv2 revisions ...-14.txt 3570 and ...-15.txt. 3572 o Shortened Terminology descriptions of Unreachable Address, 3573 Unreachable Route, Valid Route and add references to sections 3574 explaining the details. 3576 o Clarified language regarding empty Message TLV Blocks and Address 3577 Blocks. 3579 o Removed reference to RFC6551 from MetricType Allocation. 3581 o Removed Message Aggregation Delay extension. 3583 o Detailed what happens if the specified timers aren't the same 3584 across the network. 3586 o RERRs SHOULD be MULTICAST instead of MUST (which enables precursor 3587 lists). 3589 o RREP_Ack Reception: clarified wording regarding blacklist check. 3591 o Removed "approaching the limit" verbiage. 3593 o Added instructions on which messages to drop on congestion. 3595 o Revised set vs. table wording 3597 o Added note that AODVv2 was intended for use in mobile ad hoc 3598 wireless networks. 3600 o Changed language to clarify that the RFC5444 multiplexer sends the 3601 messages, not AODVv2. 3603 o Added instructions on how to use the Multicast Route Message Set 3604 to check whether an RREP_Ack or RREP was received in time. 3606 o Removed optional features. 3608 o Moved AODVv2 to the Experimental Track. 3610 Authors' Addresses 3611 Charles E. Perkins 3612 Futurewei Inc. 3613 2330 Central Expressway 3614 Santa Clara, CA 95050 3615 USA 3617 Phone: +1-408-330-4586 3618 Email: charliep@computer.org 3620 Stan Ratliff 3621 Idirect 3622 13861 Sunrise Valley Drive, Suite 300 3623 Herndon, VA 20171 3624 USA 3626 Email: ratliffstan@gmail.com 3628 John Dowdell 3629 Airbus Defence and Space 3630 Celtic Springs 3631 Newport, Wales NP10 8FZ 3632 United Kingdom 3634 Email: john.dowdell@airbus.com 3636 Lotte Steenbrink 3637 HAW Hamburg, Dept. Informatik 3638 Berliner Tor 7 3639 D-20099 Hamburg 3640 Germany 3642 Email: lotte.steenbrink@haw-hamburg.de 3644 Victoria Mercieca 3645 Airbus Defence and Space 3646 Celtic Springs 3647 Newport, Wales NP10 8FZ 3648 United Kingdom 3650 Email: victoria.mercieca@airbus.com