idnits 2.17.1 draft-perkins-manet-aodvv2-01.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 document date (July 3, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Address' is mentioned on line 408, but not defined == Missing Reference: 'MetricType' is mentioned on line 3350, but not defined == Missing Reference: 'OrigPrefix' is mentioned on line 2261, but not defined == Missing Reference: 'TargPrefix' is mentioned on line 2212, but not defined == Missing Reference: 'HopCount' is mentioned on line 3322, but not defined == Missing Reference: 'TBD' is mentioned on line 3372, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3561 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track S. Ratliff 5 Expires: January 4, 2018 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 July 3, 2017 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-perkins-manet-aodvv2-01 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 January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.1. Interface Set . . . . . . . . . . . . . . . . . . . . . . 11 63 4.2. Router Client Set . . . . . . . . . . . . . . . . . . . . 12 64 4.3. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 66 4.5. Local Route Set . . . . . . . . . . . . . . . . . . . . . 15 67 4.6. Multicast Route Message Set . . . . . . . . . . . . . . . 17 68 4.7. Route Error (RERR) Set . . . . . . . . . . . . . . . . . 18 69 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. AODVv2 Protocol Operations . . . . . . . . . . . . . . . . . 20 71 6.1. Initialization . . . . . . . . . . . . . . . . . . . . . 21 72 6.2. Next Hop Monitoring . . . . . . . . . . . . . . . . . . . 21 73 6.3. Neighbor Set Update . . . . . . . . . . . . . . . . . . . 23 74 6.4. Interaction with the Forwarding Plane . . . . . . . . . . 24 75 6.5. Message Transmission . . . . . . . . . . . . . . . . . . 25 76 6.6. Route Discovery, Retries and Buffering . . . . . . . . . 26 77 6.7. Processing Received Route Information . . . . . . . . . . 28 78 6.7.1. Evaluating Route Information . . . . . . . . . . . . 29 79 6.7.2. Applying Route Updates . . . . . . . . . . . . . . . 30 80 6.8. Suppressing Redundant Messages (Multicast Route Message 81 Set) . . . . . . . . . . . . . . . . . . . . . . . . . . 32 82 6.9. Suppressing Redundant Route Error Messages (Route Error 83 Set) . . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 6.10. Local Route Set Maintenance . . . . . . . . . . . . . . . 35 85 6.10.1. LocalRoute State Changes . . . . . . . . . . . . . . 36 86 6.10.2. Reporting Invalid Routes . . . . . . . . . . . . . . 38 87 7. AODVv2 Protocol Messages . . . . . . . . . . . . . . . . . . 38 88 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . 38 89 7.1.1. RREQ Generation . . . . . . . . . . . . . . . . . . . 40 90 7.1.2. RREQ Reception . . . . . . . . . . . . . . . . . . . 41 91 7.1.3. RREQ Forwarding . . . . . . . . . . . . . . . . . . . 42 92 7.2. Route Reply (RREP) Message . . . . . . . . . . . . . . . 42 93 7.2.1. RREP Generation . . . . . . . . . . . . . . . . . . . 44 94 7.2.2. RREP Reception . . . . . . . . . . . . . . . . . . . 45 95 7.2.3. RREP Forwarding . . . . . . . . . . . . . . . . . . . 47 96 7.3. Route Reply Acknowledgement (RREP_Ack) Message . . . . . 47 97 7.3.1. RREP_Ack Request Generation . . . . . . . . . . . . . 48 98 7.3.2. RREP_Ack Reception . . . . . . . . . . . . . . . . . 48 99 7.3.3. RREP_Ack Response Generation . . . . . . . . . . . . 49 100 7.4. Route Error (RERR) Message . . . . . . . . . . . . . . . 49 101 7.4.1. RERR Generation . . . . . . . . . . . . . . . . . . . 50 102 7.4.2. RERR Reception . . . . . . . . . . . . . . . . . . . 52 103 7.4.3. RERR Regeneration . . . . . . . . . . . . . . . . . . 53 104 8. RFC 5444 Representation . . . . . . . . . . . . . . . . . . . 54 105 8.1. Route Request Message Representation . . . . . . . . . . 55 106 8.1.1. Message Header . . . . . . . . . . . . . . . . . . . 55 107 8.1.2. Message TLV Block . . . . . . . . . . . . . . . . . . 55 108 8.1.3. Address Block . . . . . . . . . . . . . . . . . . . . 55 109 8.1.4. Address Block TLV Block . . . . . . . . . . . . . . . 56 110 8.2. Route Reply Message Representation . . . . . . . . . . . 56 111 8.2.1. Message Header . . . . . . . . . . . . . . . . . . . 56 112 8.2.2. Message TLV Block . . . . . . . . . . . . . . . . . . 57 113 8.2.3. Address Block . . . . . . . . . . . . . . . . . . . . 57 114 8.2.4. Address Block TLV Block . . . . . . . . . . . . . . . 57 115 8.3. Route Reply Acknowledgement Message Representation . . . 58 116 8.3.1. Message Header . . . . . . . . . . . . . . . . . . . 58 117 8.3.2. Message TLV Block . . . . . . . . . . . . . . . . . . 58 118 8.3.3. Address Block . . . . . . . . . . . . . . . . . . . . 58 119 8.3.4. Address Block TLV Block . . . . . . . . . . . . . . . 58 120 8.4. Route Error Message Representation . . . . . . . . . . . 58 121 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 58 122 8.4.2. Message TLV Block . . . . . . . . . . . . . . . . . . 59 123 8.4.3. Address Block . . . . . . . . . . . . . . . . . . . . 59 124 8.4.4. Address Block TLV Block . . . . . . . . . . . . . . . 59 125 9. Simple External Network Attachment . . . . . . . . . . . . . 60 126 10. Precursor Lists . . . . . . . . . . . . . . . . . . . . . . . 62 127 11. Application of RFC 7182 to AODVv2 . . . . . . . . . . . . . . 63 128 11.1. RREQ Generation and Reception . . . . . . . . . . . . . 66 129 11.2. RREP Generation and Reception . . . . . . . . . . . . . 66 130 11.3. RREP_Ack Generation and Reception . . . . . . . . . . . 67 131 11.4. RERR Generation and Reception . . . . . . . . . . . . . 68 132 12. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 68 133 12.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 69 134 12.2. Protocol Constants . . . . . . . . . . . . . . . . . . . 71 135 12.3. Local Settings . . . . . . . . . . . . . . . . . . . . . 72 136 12.4. Network-Wide Settings . . . . . . . . . . . . . . . . . 72 137 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 138 13.1. RFC 5444 Message Type Allocation . . . . . . . . . . . . 73 139 13.2. RFC 5444 Message TLV Types . . . . . . . . . . . . . . . 73 140 13.3. RFC 5444 Address Block TLV Type Allocation . . . . . . . 73 141 13.4. MetricType Allocation . . . . . . . . . . . . . . . . . 74 142 13.5. ADDRESS_TYPE TLV Values . . . . . . . . . . . . . . . . 74 143 14. Security Considerations . . . . . . . . . . . . . . . . . . . 75 144 14.1. Availability . . . . . . . . . . . . . . . . . . . . . . 75 145 14.1.1. Denial of Service . . . . . . . . . . . . . . . . . 75 146 14.1.2. Malicious RERR messages . . . . . . . . . . . . . . 76 147 14.1.3. False Confirmation of Link Bidirectionality . . . . 77 148 14.1.4. Message Deletion . . . . . . . . . . . . . . . . . . 78 149 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 78 150 14.3. Integrity of Routes . . . . . . . . . . . . . . . . . . 78 151 14.3.1. Message Insertion . . . . . . . . . . . . . . . . . 79 152 14.3.2. Message Modification - Man in the Middle . . . . . . 79 153 14.3.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 80 154 14.4. Protection Mechanisms . . . . . . . . . . . . . . . . . 80 155 14.4.1. Confidentiality and Authentication . . . . . . . . . 80 156 14.4.2. Message Integrity using ICVs . . . . . . . . . . . . 80 157 14.4.3. Replay Protection using Timestamps . . . . . . . . . 81 158 14.5. Key Management . . . . . . . . . . . . . . . . . . . . . 81 159 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 160 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 161 16.1. Normative References . . . . . . . . . . . . . . . . . . 83 162 16.2. Informative References . . . . . . . . . . . . . . . . . 83 163 Appendix A. AODVv2 Draft Updates . . . . . . . . . . . . . . . . 84 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 166 1. Overview 168 The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol 169 enables dynamic, multihop routing between participating mobile nodes 170 wishing to establish and maintain an ad hoc network. The basic 171 operations of the AODVv2 protocol are route discovery and route 172 maintenance. AODVv2 does not require nodes to maintain routes to 173 destinations that are not in active communication. AODVv2 allows 174 mobile nodes to respond to link breakages and changes in network 175 topology in a timely manner. The operation of AODVv2 is loop-free, 176 and by avoiding the Bellman-Ford "counting to infinity" problem 177 offers quick convergence when the ad hoc network topology changes 178 (typically, when a node moves in the network). When links break, 179 AODVv2 causes the affected set of nodes to be notified so that they 180 are able to invalidate the routes using the lost link. 182 One distinguishing feature of AODVv2 is its use of a destination 183 sequence number for each route entry. The destination sequence 184 number is created by the destination to be included along with any 185 route information it sends to requesting nodes. Using destination 186 sequence numbers ensures loop freedom and is simple to program. 187 Given the choice between two routes to a destination, a requesting 188 node is required to select the one with the greatest sequence number. 190 Compared to AODV [RFC3561], AODVv2 has moved some features out of the 191 scope of the document, notably intermediate route replies, expanding 192 ring search, and route lifetimes. However, the document has been 193 designed to allow their specification in a separate document. Hello 194 messages and local repair have been removed. AODVv2 provides a 195 mechanism for the use of multiple metric types. Message formats have 196 been updated and made compliant with [RFC5444]. AODVv2 control 197 messages are defined as sets of data, which are mapped to message 198 elements using the Generalized MANET Packet/Message Format defined in 199 [RFC5444] and sent using the parameters in [RFC5498]. Verification 200 of link bidirectionality has been substantially improved, and 201 additional refinements made for route timeouts and state management. 202 Finally, multihoming is now supported. 204 The basic protocol mechanisms are as follows. Since AODVv2 is a 205 reactive protocol, route discovery is initiated only when a route to 206 the target is needed (i.e. when a router's client has data to send). 207 For this purpose, AODVv2 uses Route Request (RREQ) and Route Reply 208 (RREP) messages as follows: an RREQ is distributed across the 209 network. When forwarding an RREQ, all routers across the network 210 also store a possible reverse route back to the originator of the 211 RREQ. When the target receives the RREQ, it answers with an RREP, 212 which is then relayed back to the originator along the path stored by 213 the intermediate routers. A metric value is included within the 214 messages to indicate the cost of the route. AODVv2 uses sequence 215 numbers to identify stale routing information, and compares route 216 metric values to determine if advertised routes could form loops. 217 Route maintenance includes confirming bidirectionality of links to 218 next-hop AODVv2 routers, managing route timeouts, using Route Error 219 (RERR) messages to inform other routers of broken links, and reacting 220 to received Route Error messages. 222 The on-demand nature of AODVv2 requires indications to be exchanged 223 between AODVv2 and the forwarding plane for the following conditions: 225 o a packet is to be forwarded and route discovery is needed 227 o packet forwarding fails, in order to report a route error 229 o packet forwarding succeeds, in order to manage route timeouts. 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 Acknowledgement message to indicate that a 249 Route Reply Acknowledgement is expected in return. 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 Interface Set 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 OrigPrefix. 297 OrigPrefix 298 The prefix configured in the Router Client Set entry which 299 includes OrigAddr. 301 OrigPrefixLen 302 The prefix length, in bits, configured in the Router Client Set 303 entry which includes OrigAddr. 305 OrigSeqNum 306 The sequence number of the AODVv2 router which originated the 307 Route Request on behalf of OrigAddr. 309 PktSource 310 The source address of the IP packet that triggered a Route Error 311 message. 313 PrefixLengthList 314 A list of routing prefix lengths associated with the addresses in 315 the AddressList of a message. 317 Reactive 318 Performed only in reaction to specific events. In AODVv2, routes 319 are requested only when data packets need to be forwarded. In 320 this document, "reactive" is synonymous with "on-demand". 322 RERR (Route Error) 323 The AODVv2 message type used to indicate that an AODVv2 router 324 does not have a valid LocalRoute toward one or more destinations. 326 RERR_Gen (RERR Generating Router) 327 The AODVv2 router generating a Route Error message. 329 RerrMsg (RERR Message) 330 A Route Error (RERR) message. 332 Routable Unicast IP Address 333 A unicast IP address that is scoped sufficiently to be forwarded 334 by a router. Globally-scoped unicast IP addresses and Unique 335 Local Addresses (ULAs) [RFC4193] are examples of routable unicast 336 IP addresses. 338 Router Client 339 An address within an address range configured on an AODVv2 router, 340 on behalf of which that router will initiate and respond to route 341 discoveries. These addresses may be used by the AODVv2 router 342 itself or by devices that are reachable without traversing another 343 AODVv2 router. 345 RREP (Route Reply) 346 The AODVv2 message type used to reply to a Route Request message. 348 RREP_Gen (RREP Generating Router) 349 The AODVv2 router that generates the Route Reply message, i.e., 350 the router configured with TargAddr as a Router Client. 352 RREQ (Route Request) 353 The AODVv2 message type used to discover a route to TargAddr and 354 distribute information about a route to OrigPrefix. 356 RREQ_Gen (RREQ Generating Router) 357 The AODVv2 router that generates the Route Request message, i.e., 358 the router configured with OrigAddr as a Router Client. 360 RteMsg (Route Message) 361 A Route Request (RREQ) or Route Reply (RREP) message. 363 SeqNum 364 The sequence number maintained by an AODVv2 router to indicate 365 freshness of route information. 367 SeqNumList 368 A list of sequence numbers associated with the addresses in the 369 AddressList of a message. 371 TargAddr 372 The target address of a route request, i.e., the destination 373 address of the IP packet triggering route discovery. 375 TargMetric 376 The metric value associated with the route to TargPrefix. 378 TargPrefix 379 The prefix configured in the Router Client Set entry which 380 includes TargAddr. 382 TargPrefixLen 383 The prefix length, in bits, configured in the Router Client Set 384 entry which includes TargAddr. 386 TargSeqNum 387 The sequence number of the AODVv2 router which originated the 388 Route Reply on behalf of TargAddr. 390 Unreachable Address 391 An address reported in a Route Error message, as described in 392 Section 7.4.1. 394 Upstream 395 In the direction from destination to source (from TargAddr to 396 OrigAddr). 398 Valid route 399 A route that can be used for forwarding. 401 This document uses the notational conventions in Table 1 to simplify 402 the text. 404 +-----------------------+------------------------------------+ 405 | Notation | Meaning | 406 +-----------------------+------------------------------------+ 407 | Route[Address] | A route toward Address | 408 | Route[Address].Field | A field in a route toward Address | 409 | RteMsg.Field | A field in either RREQ or RREP | 410 | RerrMsg.Field | A field in a RERR | 411 +-----------------------+------------------------------------+ 413 Table 1: Notational Conventions 415 3. Applicability Statement 417 The AODVv2 routing protocol is a reactive routing protocol designed 418 for use in mobile ad hoc wireless networks, and may also be useful in 419 networks where the nodes are not mobile but economical route 420 maintenance is still required. A reactive protocol only sends 421 messages to discover a route when there is data to send on that 422 route. This requires an interaction with the forwarding plane, to 423 indicate when a packet is to be forwarded, in case reactive route 424 discovery is needed. The set of signals exchanged between AODVv2 and 425 the forwarding plane are discussed in Section 6.4. 427 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 428 i.e., non-transit networks or those not connected to the internet. 429 AODVv2 routers can, however, be configured to perform gateway 430 functions when attached to external networks, as discussed in 431 Section 9. 433 AODVv2 handles a wide variety of mobility and traffic patterns by 434 determining routes on-demand. In networks with a large number of 435 routers, AODVv2 is best suited for relatively sparse traffic 436 scenarios where each router forwards IP packets to a small percentage 437 of destination addresses in the network. In such cases fewer routes 438 are needed, and far less control traffic is produced. In large 439 networks with dense traffic patterns, AODVv2 control messages may 440 cause a broadcast storm, overwhelming the network with control 441 messages. The transmission priorities described in Section 6.5 442 prioritize route maintenance traffic over route discovery traffic. 444 Data packets may be buffered until a route to their destination is 445 available, as described in Section 6.6. 447 AODVv2 is well suited to reactive scenarios such as emergency and 448 disaster relief, where the ability to communicate might be more 449 important than being assured of secure operations. For many other ad 450 hoc networking applications, in which insecure operation could negate 451 the value of establishing communication paths, it is important for 452 neighboring AODVv2 routers to establish security associations with 453 one another. 455 AODVv2 provides for message integrity and security against replay 456 attacks by using integrity check values, timestamps and sequence 457 numbers, as described in Section 14. When security associations have 458 been established, encryption can be used for AODVv2 messages to 459 ensure that only trusted routers participate in routing operations. 461 The AODVv2 route discovery process aims for a route to be established 462 in both directions along the same path. Uni-directional links are 463 not suitable; AODVv2 will detect and exclude those links from route 464 discovery. The route discovered is optimized for the requesting 465 router, and the return path may not be the optimal route. 467 AODVv2 is applicable to memory constrained devices, since only a 468 little routing state is maintained in each AODVv2 router. AODVv2 469 routes that are not needed for forwarding data do not need to be 470 maintained. 472 AODVv2 supports routers with multiple interfaces and multiple IP 473 addresses per interface. A router may also use the same IP address 474 on multiple interfaces. AODVv2 requires only that each interface 475 configured for AODVv2 has at least one unicast IP address. Address 476 assignment procedures are out of scope for AODVv2. 478 AODVv2 supports Router Clients with multiple interfaces, as long as 479 each interface is configured with its own unicast IP address. 481 The routing algorithm in AODVv2 has been operated at layers other 482 than the network layer, using layer-appropriate addresses. 484 AODVv2 is based on AODV [RFC3561]. The following important protocol 485 mechanisms have changed: 487 o Bidirectionality is ensured using a new mechanism 489 o Alternate metrics may be used to determine route quality 491 o Support for multiple interfaces has been improved 493 o Support for multi-interface IP addresses has been added 495 o A new security model allowing end to end integrity checks has been 496 added 498 o A new message format ([RFC5444]) is used. 500 4. Data Structures 502 4.1. Interface Set 504 The Interface Set is a conceptual data structure which contains 505 information about all interfaces configured for use by AODVv2. Any 506 interface with an IP address can be used. Multiple interfaces on a 507 single router can be used. Multiple interfaces on the same router 508 may be configured with the same IP address. 510 Each member in the Interface Set MUST contain the following: 512 Interface.Id 513 An identifier that is unique in node-local scope, allowing the 514 AODVv2 implementation to identify exactly one local network 515 interface. 517 If multiple interfaces of the AODVv2 router are configured for use by 518 AODVv2, they MUST be configured in the Interface Set. 519 Implementations using only one interface do not need the Interface 520 Set, since their single interface is already uniquely identifiable. 522 4.2. Router Client Set 524 An AODVv2 router discovers routes for its own local applications and 525 also for its Router Clients that are reachable without traversing 526 another AODVv2 router. The addresses used by these devices, and the 527 AODVv2 router itself, are configured in the Router Client Set. An 528 AODVv2 router will only originate Route Request and Route Reply 529 messages on behalf of its configured Router Client addresses. 531 Router Client Set entries contain: 533 RouterClient.IPAddress 534 An IP address or the start of an address range that requires route 535 discovery services from the AODVv2 router. 537 RouterClient.PrefixLength 538 The length, in bits, of the routing prefix associated with the 539 RouterClient.IPAddress. If the prefix length is not equal to the 540 address length of RouterClient.IPAddress, the AODVv2 router MUST 541 participate in route discovery on behalf of all addresses within 542 that prefix. 544 RouterClient.Cost 545 The cost associated with reaching this address or address range. 547 4.3. Neighbor Set 549 A Neighbor Set MUST be maintained with information about neighboring 550 AODVv2 routers. Neighbor Set entries are stored when AODVv2 messages 551 are received. If the Neighbor is chosen as a next hop on an 552 installed route, the link to the Neighbor MUST be verified to be 553 bidirectional and the result stored in this set. A route is not 554 valid until the link is confirmed to be bidirectional. 556 Neighbor Set entries MUST contain: 558 Neighbor.IPAddress 559 An IP address of the neighboring router. 561 Neighbor.State 562 Indicates whether the link to the neighbor is bidirectional. 563 There are three possible states: Confirmed, Heard, and 564 Blacklisted. Heard is the initial state. Confirmed indicates 565 that the link to the neighbor has been confirmed as bidirectional. 566 Blacklisted indicates that the link to the neighbor is being 567 treated as uni-directional. Section 6.2 discusses how to monitor 568 link bidirectionality. 570 Neighbor.Timeout 571 Indicates the time at which the Neighbor.State should be updated: 573 o If the value of Neighbor.State is Blacklisted, this indicates the 574 time at which Neighbor.State will revert to Heard. This value is 575 calculated at the time the router is blacklisted and by default is 576 equal to CurrentTime + MAX_BLACKLIST_TIME. 578 o If Neighbor.State is Heard, and an RREP_Ack has been requested 579 from the neighbor, it indicates the time at which Neighbor.State 580 will be set to Blacklisted, if an RREP_Ack has not been received. 582 o If the value of Neighbor.State is Heard and no RREP_Ack has been 583 requested, or if Neighbor.State is Confirmed, this time is set to 584 INFINITY_TIME. 586 Neighbor.Interface 587 The interface on which the link to the neighbor was established. 589 Neighbor.AckSeqNum 590 The next sequence number to use for the TIMESTAMP value in an 591 RREP_Ack request, in order to detect replay of an RREP_Ack 592 response. AckSeqNum is initialized to a random value. 594 Neighbor.HeardRERRSeqNum 595 The last heard sequence number used as the TIMESTAMP value in a 596 RERR received from this neighbor, saved in order to detect replay 597 of a RERR message. HeardRERRSeqNum is initialized to zero. 599 See Section 11.3 and Section 11.4 for more information on how 600 Neighbor.AckSeqNum and Neighbor.HeardRERRSeqNum are used. 602 4.4. Sequence Numbers 604 Sequence Numbers enable AODVv2 routers to determine the temporal 605 order of route discovery messages that originate from a AODVv2 606 router, and thus to identify stale routing information so that it can 607 be discarded. The sequence number fulfills the same roles as the 608 "Destination Sequence Number" of DSDV [Perkins94], and the AODV 609 Sequence Number in [RFC3561]. The sequence numbers from two 610 different routers are not comparable; route discovery messages with 611 sequence numbers belonging to two different routers cannot be 612 compared to determine temporal ordering. 614 Each AODVv2 router in the network MUST maintain its own sequence 615 number. All RREQ and RREP messages created by an AODVv2 router 616 include the router's sequence number, reported as a 16-bit unsigned 617 integer. Each AODVv2 router MUST ensure that its sequence number is 618 strictly increasing, and that it is incremented by one (1) whenever 619 an RREQ or RREP is created, except when the sequence number is 65,535 620 (the maximum value of a 16-bit unsigned integer), in which case it 621 MUST be reset to one (1) to achieve wrap around. The value zero (0) 622 is reserved to indicate that the router's sequence number is unknown. 624 An AODVv2 router MUST use its sequence number only on behalf of its 625 configured Router Clients; route messages forwarded by other routers 626 retain the originator's sequence number. 628 To determine if newly received information is stale and therefore 629 redundant compared to other information originated by the same 630 router, the sequence number attached to the information is compared 631 to the sequence number of existing information about the same route. 632 The comparison is carried out by subtracting the existing sequence 633 number from the newly received sequence number, using unsigned 634 arithmetic. The result of the subtraction is to be interpreted as a 635 signed 16-bit integer. 637 o If the result is negative, the newly received information is 638 considered older than the existing information and therefore stale 639 and redundant and MUST therefore be discarded. 641 o If the result is positive, the newly received information is newer 642 than the existing information and is not considered stale or 643 redundant and MUST therefore be processed. 645 o If the result is zero, the newly received information is not 646 considered stale, and therefore MUST be processed further in case 647 the new information offers a better route (see Section 6.7.1 and 648 Section 6.8). 650 Along with the algorithm in Section 6.7.1, maintaining temporal 651 ordering ensures loop freedom. 653 An AODVv2 router SHOULD maintain its sequence number in persistent 654 storage. On routers unable to store persistent AODVv2 state, 655 recovery can impose a performance penalty (e.g., in case of AODVv2 656 router reboot), since if a router loses its sequence number, there is 657 a delay (by default, on the order of minutes) before the router can 658 resume full operations. If the sequence number is lost, the router 659 MUST follow the procedure in Section 6.1 to safely resume routing 660 operations with a new sequence number. 662 4.5. Local Route Set 664 All AODVv2 routers MUST maintain a Local Route Set, containing 665 information obtained from AODVv2 route messages. The Local Route Set 666 is considered to be stored separately from the forwarding plane's 667 routing table (referred to as Routing Information Base (RIB)), which 668 may be updated by other routing protocols operating on the AODVv2 669 router as well. The Routing Information Base is updated using 670 information from the Local Route Set. Alternatively, if the 671 information specified below can be added to RIB entries, 672 implementations MAY choose to modify the Routing Information Base 673 directly instead of maintaining a dedicated Local Route Set. 675 Routes obtained from AODVv2 route messages are referred to in this 676 document as LocalRoutes, and MUST contain the following information: 678 LocalRoute.Address 679 An address, which, when combined with LocalRoute.PrefixLength, 680 describes the set of destination addresses for which this route 681 enables forwarding. 683 LocalRoute.PrefixLength 684 The prefix length, in bits, associated with LocalRoute.Address. 686 LocalRoute.SeqNum 687 The sequence number associated with LocalRoute.Address, obtained 688 from the last route message that successfully updated this entry. 690 LocalRoute.NextHop 691 The source IP address of the IP packet containing the AODVv2 692 message advertising the route to LocalRoute.Address, i.e., an IP 693 address of the AODVv2 router used for the next hop on the path 694 toward LocalRoute.Address. 696 LocalRoute.NextHopInterface 697 The interface used to send IP packets toward LocalRoute.Address. 699 LocalRoute.LastUsed 700 If this route is installed in the Routing Information Base, the 701 time it was last used to forward an IP packet. If not, the time 702 at which the LocalRoute was created. 704 LocalRoute.LastSeqNumUpdate 705 The time LocalRoute.SeqNum was last updated. 707 LocalRoute.MetricType 708 The type of metric associated with this route. See Section 5 for 709 information about AODVv2's handling of multiple metric types. 711 LocalRoute.Metric 712 The cost of the route toward LocalRoute.Address expressed in units 713 consistent with LocalRoute.MetricType. 715 LocalRoute.Precursors (optional feature) 716 A list of upstream neighbors using the route (see Section 10). 718 LocalRoute.SeqNoRtr 719 If nonzero, the IP address of the router that originated the 720 Sequence Number for this route. 722 LocalRoute.State 723 The last known state (Unconfirmed, Idle, Active, or Invalid) of 724 the route. 726 There are four possible states for a LocalRoute: 728 Unconfirmed 729 A route obtained from a Route Request message, which has not yet 730 been confirmed as bidirectional. It MUST NOT be stored in the RIB 731 to forward general data-plane traffic, but it can be used to 732 transmit RREP packets along with a request for bidirectional link 733 verification. An Unconfirmed route is not otherwise considered a 734 valid route. This state is only used for routes obtained through 735 RREQ messages. 737 Idle 738 A route that has been confirmed to be bidirectional, but has not 739 been used in the last ACTIVE_INTERVAL. It can be used for 740 forwarding IP packets, and therefore it is considered a valid 741 route. 743 Active 744 A valid route that has been used for forwarding IP packets during 745 the last ACTIVE_INTERVAL. 747 Invalid 748 A route that has expired or has broken. It MUST NOT be used for 749 forwarding IP packets. Invalid routes contain the destination's 750 sequence number, which may be useful when assessing freshness of 751 incoming routing information. 753 If the Local Route Set is stored separately from the RIB, routes are 754 added to the RIB when LocalRoute.State becomes Active, and removed 755 from the RIB when LocalRoute.State becomes Invalid. Changes to 756 LocalRoute state are detailed in Section 6.10.1. 758 4.6. Multicast Route Message Set 760 Multicast Route Request (RREQ) messages can be tested for redundancy 761 to avoid unnecessary processing and forwarding. 763 The Multicast Route Message Set is a conceptual set which contains 764 information about previously received multicast route messages, so 765 that incoming route messages can be compared with previously received 766 messages to determine if the incoming information is redundant or 767 stale, so that the router can avoid sending redundant control 768 traffic. 770 Multicast Route Message Set entries contain the following 771 information: 773 RteMsg.OrigPrefix 774 The prefix associated with OrigAddr, the source address of the IP 775 packet triggering the route request. 777 RteMsg.OrigPrefixLen 778 The prefix length associated with RteMsg.OrigPrefix, originally 779 from the Router Client Set entry on RREQ_Gen which includes 780 OrigAddr. 782 RteMsg.TargPrefix 783 The prefix associated with TargAddr, the destination address of 784 the IP packet triggering the route request. In an RREQ this MUST 785 be set to TargAddr. 787 RteMsg.OrigSeqNum 788 The sequence number associated with the route to OrigPrefix, if 789 RteMsg is an RREQ. 791 RteMsg.TargSeqNum 792 The sequence number associated with the route to TargPrefix. 794 RteMsg.MetricType 795 The metric type of the route requested. 797 RteMsg.Metric 798 The metric value received in the RteMsg. 800 RteMsg.Timestamp 801 The last time this Multicast Route Message Set entry was updated. 803 RteMsg.RemovalTime 804 The time at which this entry MUST be removed from the Multicast 805 Route Message Set. 807 RteMsg.Interface 808 The interface on which the message was received. 810 RteMsg.SeqNoRtr 811 If nonzero, the IP address of the router that originated the 812 Sequence Number for this route. 814 The Multicast Route Message Set is maintained so that no two entries 815 have the same OrigPrefix, OrigPrefixLen, TargPrefix, and MetricType. 816 See Section 6.8 for details about updating this set. 818 4.7. Route Error (RERR) Set 820 Each RERR message sent because no route exists for packet forwarding 821 SHOULD be recorded in a conceptual set called the Route Error (RERR) 822 Set. Each entry contains the following information: 824 RerrMsg.Timeout 825 The time after which the entry SHOULD be deleted. 827 RerrMsg.UnreachableAddress 828 The UnreachableAddress reported in the AddressList of the RERR. 830 RerrMsg.PktSource: 831 The PktSource of the RERR. 833 See Section 6.9 for instructions on how to update the set. 835 5. Metrics 837 Metrics measure a cost or quality associated with a route or a link, 838 e.g., latency, delay, financial cost, energy, etc. Metric values are 839 reported in Route Request and Route Reply messages. 841 In Route Request messages, the metric describes the cost of the route 842 from OrigPrefix to the router transmitting the Route Request. For 843 RREQ_Gen, this is the cost associated with the Router Client Set 844 entry which includes OrigAddr. For routers which forward the RREQ, 845 this is the cost from OrigPrefix to the forwarding router, combining 846 the metric value from the received RREQ message with knowledge of the 847 link cost from the sender to the receiver, i.e., the incoming link 848 cost. This updated route cost is included when forwarding the Route 849 Request message, and used to install a route to OrigPrefix. 851 Similarly, in Route Reply messages, the metric reflects the cost of 852 the route from TargPrefix to the router transmitting the Route Reply. 853 For RREP_Gen, this is the cost associated with the Router Client Set 854 entry which includes TargAddr. For routers which forward the RREP, 855 this is the cost from TargPrefix to the forwarding router, combining 856 the metric value from the received RREP message with knowledge of the 857 link cost from the sender to the receiver, i.e., the incoming link 858 cost. This updated route cost is included when forwarding the Route 859 Reply message, and used to install a route to TargPrefix. 861 When link metrics are symmetric, the cost of the routes installed in 862 the Local Route Set at each router will be correct. This assumption 863 is often inexact, but calculating incoming/outgoing metric data is 864 outside of scope of this document. The route discovered is good for 865 the requesting router, but the return path may not be the optimal 866 route. 868 AODVv2 enables the use of multiple metric types. Each route 869 discovery attempt indicates the metric type which is requested for 870 the route. Multiple valid routes may exist in the Local Route Set 871 for the same address and prefix length but for different metric 872 types. More than one route to a particular address and prefix length 873 MUST NOT exist in the Routing Information Base unless each packet can 874 be inspected to determine which route in the RIB has the proper 875 metric type as required for that packet. Otherwise, only one route 876 at a time to a particular address and prefix length may exist in the 877 RIB. The algorithm used to inspect the packet and make the 878 determination about which the routes should be installed in the 879 Routing Information Base is outside the scope of AODVv2. 881 For each MetricType, AODVv2 requires: 883 o A MetricType number, to indicate the metric type of a route. 884 Currently allocated MetricType numbers are listed in Section 13.4. 886 o A maximum value, denoted MAX_METRIC[MetricType]. This MUST always 887 be the maximum expressible metric value of type MetricType. Field 888 lengths associated with metric values are found in Section 13.4. 889 If the cost of a route exceeds MAX_METRIC[MetricType], the route 890 cannot be stored and is ignored. 892 o A function for incoming link cost, denoted Cost(L). Using 893 incoming link costs means that the route obtained has a metric 894 accurate for the direction back towards the originating router. 896 o A function for route cost, denoted Cost(R). 898 o A function to analyze routes for potential loops based on metric 899 information, denoted LoopFree(R1, R2). LoopFree verifies that a 900 route R2 is not a sub-section of another route R1. An AODVv2 901 router invokes LoopFree() as part of the process in Section 6.7.1, 902 when an advertised route (R1) and an existing LocalRoute (R2) have 903 the same destination address, metric type, and sequence number. 904 LoopFree returns FALSE to indicate that an advertised route is not 905 to be used to update a stored LocalRoute, as it may cause a 906 routing loop. In the case where the existing LocalRoute is 907 Invalid, it is possible that the advertised route includes the 908 existing LocalRoute and came from a router which did not yet 909 receive notification of the route becoming Invalid, so the 910 advertised route should not be used to update the Local Route Set, 911 in case it forms a loop to a broken route. 913 AODVv2 currently supports cost metrics where Cost(R) is strictly 914 increasing, by defining: 916 o Cost(R) := Sum of Cost(L) of each link in the route 918 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 920 Implementers MAY consider metric types that are not strictly 921 increasing, but the definitions of Cost and LoopFree functions for 922 such types are undefined, and interoperability issues need to be 923 considered. 925 6. AODVv2 Protocol Operations 927 AODVv2 protocol operations include: 929 o managing sequence numbers, 931 o monitoring next hop AODVv2 routers on discovered routes and 932 updating the Neighbor Set, 934 o performing route discovery and dealing with requests from other 935 routers, 937 o processing incoming route information and updating the Local Route 938 Set, 940 o updating the Multicast Route Message Set and suppressing redundant 941 messages, and 943 o reporting broken routes. 945 These processes are discussed in detail in the following sections. 947 6.1. Initialization 949 When an AODVv2 router does not have information about its previous 950 sequence number, or if its sequence number is lost at any point, the 951 router reinitializes its sequence number to one (1). However, other 952 AODVv2 routers may still hold sequence number information that this 953 router previously issued. Since sequence number information is 954 removed if there has been no update to the sequence number in 955 MAX_SEQNUM_LIFETIME, the initializing router MUST wait for 956 MAX_SEQNUM_LIFETIME before it creates any messages containing its new 957 sequence number. 959 During this wait period, the router is permitted to do the following: 961 o Process information in a received RREQ or RREP message to obtain a 962 route to the originator or target of that route discovery 964 o Forward a received RREQ or RREP 966 o Send an RREP_Ack 968 o Maintain valid routes in the Local Route Set 970 o Create, process and forward RERR messages 972 6.2. Next Hop Monitoring 974 To ensure AODVv2 routers do not establish routes over uni-directional 975 links, AODVv2 routers MUST verify that the link to the next hop 976 router is bidirectional before marking a route as valid in the Local 977 Route Set. 979 AODVv2 provides a mechanism for testing bidirectional connectivity 980 during route discovery, and blacklisting routers where bidirectional 981 connectivity is not available. If a route discovery is retried by 982 RREQ_Gen, the blacklisted routers are excluded from the process, and 983 a different route can be discovered. Further, a route is not to be 984 used for forwarding until the bidirectionality of the link to the 985 next hop is confirmed. AODVv2 routers do not need to monitor 986 bidirectionality for links to neighboring routers which are not used 987 as next hops on routes in the Local Route Set. 989 o Bidirectional connectivity to upstream routers is tested as 990 necessary by requesting acknowledgement of RREP messages, 991 including an AckReq element to indicate that an acknowledgement is 992 requested. This MUST be answered by sending an RREP_Ack in 993 response. Receipt of an RREP_Ack within RREP_Ack_SENT_TIMEOUT 994 demonstrates that bidirectional connectivity exists. Otherwise, 995 the link is considered to be unidirectional. All AODVv2 routers 996 MUST support this process, which is explained in Section 7.2 and 997 Section 7.3. 999 o Receipt of an RREP message containing the route to TargAddr 1000 confirms bidirectionality to the downstream router, since an RREP 1001 message is a reply to an RREQ message which previously crossed the 1002 link in the opposite direction. 1004 To assist with next hop monitoring, a Neighbor Set (Section 4.3) is 1005 maintained. When an RREQ or RREP is received, an AODVv2 router 1006 searches for an entry in the Neighbor Set where all of the following 1007 conditions are met: 1009 o Neighbor.IPAddress == IP address from which the RREQ or RREP was 1010 received 1012 o Neighbor.Interface == Interface on which the RREQ or RREP was 1013 received. 1015 If no such entry exists, a new entry is created as described in 1016 Section 6.3. While the value of Neighbor.State is Heard, 1017 acknowledgement of RREP messages sent to that neighbor MUST be 1018 requested. If an acknowledgement is not received within the timeout 1019 period, the neighbor MUST have Neighbor.State set to Blacklisted. If 1020 an acknowledgement is received within the timeout period, 1021 Neighbor.State is set to Confirmed. When the value of Neighbor.State 1022 is Confirmed, the request for an acknowledgement of any other RREP 1023 message is unnecessary. 1025 Additional indications of connectivity may be available from other 1026 operations, for example: 1028 o MAC layer protocol assuring bidirectional links 1030 o Route timeout 1032 o Lower layer triggers, e.g. message reception or link status 1033 notifications 1035 o TCP timeouts 1037 o Promiscuous listening 1039 o receipt of a Neighborhood Discovery Protocol HELLO message with 1040 the receiving router listed as a neighbor [RFC6130] 1042 o Other monitoring mechanisms or heuristics 1043 If such an external process signals that the link to a neighbor is 1044 bidirectional, the AODVv2 router MAY update the matching Neighbor Set 1045 entry by changing the value of Neighbor.State to Confirmed. If an 1046 external process signals that a link is not bidirectional, the the 1047 value of Neighbor.State MAY be changed to Blacklisted. 1049 6.3. Neighbor Set Update 1051 On receipt of an RREQ or RREP message, the Neighbor Set MUST be 1052 checked for an entry with Neighbor.IPAddress which matches the source 1053 IP address of a packet containing the AODVv2 message. If no matching 1054 entry is found, a new entry is created. 1056 A new Neighbor Set entry is created as follows: 1058 o Neighbor.IPAddress := Source IP address of the received route 1059 message 1061 o Neighbor.State := Heard 1063 o Neighbor.Timeout := INFINITY_TIME 1065 o Neighbor.Interface := Interface on which the RREQ or RREP was 1066 received. (see Section 4.1). 1068 When an RREP_Ack request is sent to a neighbor, the Neighbor Set 1069 entry is updated as follows: 1071 o Neighbor.Timeout := CurrentTime + RREP_Ack_SENT_TIMEOUT 1073 When a received message is one of the following: 1075 o an RREP which answers an RREQ sent within RREQ_WAIT_TIME over the 1076 same interface as Neighbor.Interface 1078 o an RREP_Ack response received from a Neighbor with Neighbor.State 1079 set to Heard, where Neighbor.Timeout > CurrentTime 1081 then the link to the neighbor is bidirectional and the Neighbor Set 1082 entry is updated as follows: 1084 o Neighbor.State := Confirmed 1086 o Neighbor.Timeout := INFINITY_TIME 1088 When the Neighbor.Timeout is reached and Neighbor.State is Heard, 1089 then an RREP_Ack response has not been received from the neighbor 1090 within RREP_Ack_SENT_TIMEOUT of sending the RREP_Ack request. The 1091 link is considered to be uni-directional and the Neighbor Set entry 1092 is updated as follows: 1094 o Neighbor.State := Blacklisted 1096 o Neighbor.Timeout := CurrentTime + MAX_BLACKLIST_TIME 1098 When the Neighbor.Timeout is reached and Neighbor.State is 1099 Blacklisted, the Neighbor Set entry is updated as follows: 1101 o Neighbor.State := Heard 1103 If an external mechanism reports a link as broken, the Neighbor Set 1104 entry SHOULD be removed. 1106 Route requests (RREQs) from neighbors with Neighbor.State set to 1107 Blacklisted MUST be ignored, to avoid persistent IP packet loss or 1108 protocol failures. Neighbor.Timeout allows the neighbor to again be 1109 allowed to participate in route discoveries after MAX_BLACKLIST_TIME, 1110 in case the link between the routers has become bidirectional. 1112 6.4. Interaction with the Forwarding Plane 1114 The signals described in the following are conceptual in nature, and 1115 can be implemented in various ways. Conformant implementations of 1116 AODVv2 are not mandated to implement the forwarding plane separately 1117 from the control plane or data plane; these signals and interactions 1118 are identified simply as assistance for implementers who may find 1119 them useful. 1121 AODVv2 requires signals from the forwarding plane: 1123 o A packet cannot be forwarded because a route is unavailable: 1124 AODVv2 needs to know the source and destination IP addresses of 1125 the packet. If the source of the packet is configured as a Router 1126 Client, the router SHOULD initiate route discovery to the 1127 destination. If it is not a Router Client, the router SHOULD 1128 create a Route Error message. 1130 o A packet is to be forwarded: AODVv2 needs to check the state of 1131 the route to ensure it is still valid. 1133 o Packet forwarding succeeds: AODVv2 needs to update the record of 1134 when a route was last used to forward a packet. 1136 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1137 Error message. 1139 AODVv2 needs to send signals to the forwarding plane when: 1141 o A route discovery is in progress: buffering might be configured 1142 for packets requiring a route, while route discovery is attempted. 1144 o A route discovery failed: any buffered packets requiring that 1145 route should be discarded, and the source of the packet should be 1146 notified that the destination is unreachable (using an ICMP 1147 Destination Unreachable message). Route discovery fails if an 1148 RREQ cannot be generated because the control message generation 1149 limit has been reached (seeSection 6.5), or if an RREP is not 1150 received within RREQ_WAIT_TIME (see Section 6.6). 1152 o A route discovery succeeded: install a corresponding route into 1153 the Routing Information Base and begin transmitting any buffered 1154 packets. 1156 o A route has been made invalid: remove the corresponding route from 1157 the Routing Information Base. 1159 o A route has been updated: update the corresponding route in the 1160 Routing Information Base. 1162 o If routes with more than one metric type are available to a 1163 destination, a way to identify the route that is allowable for the 1164 metric type associated with forwarding the incoming packet. 1166 6.5. Message Transmission 1168 AODVv2 sends [RFC5444] formatted messages using the parameters for 1169 port number and IP protocol specified in [RFC5498]. Mapping of 1170 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1171 multicast messages are sent to the link-local multicast address LL- 1172 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1173 MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2 1174 messages. Note that multicast messages MAY be sent via unicast. For 1175 example, this may occur for certain link-types (non-broadcast media), 1176 for manually configured router adjacencies, or in order to improve 1177 robustness. 1179 When multiple interfaces are available, an AODVv2 router transmitting 1180 a multicast message to LL-MANET-Routers MUST send the message on all 1181 interfaces that have been configured for AODVv2 operation, as given 1182 in the Interface Set (Section 4.1). 1184 To avoid congestion, each AODVv2 router's rate of message generation 1185 SHOULD be administratively configurable and rate-limited 1186 (CONTROL_TRAFFIC_LIMIT). Messages SHOULD NOT be sent more frequently 1187 than one message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If 1188 this threshold is reached, messages MUST be sent based on their 1189 priority: 1191 o Highest priority SHOULD be given to RREP_Ack messages. This 1192 allows links between routers to be confirmed as bidirectional and 1193 avoids undesired blacklisting of next hop routers. 1195 o Second priority SHOULD be given to RERR messages for undeliverable 1196 IP packets. This avoids repeated forwarding of packets over 1197 broken routes that are still in use by other routers. 1199 o Third priority SHOULD be given to RREP messages in order that 1200 RREQs do not time out. 1202 o Fourth priority SHOULD be given to RREQ messages. 1204 o Fifth priority SHOULD be given to RERR messages for newly 1205 invalidated routes. 1207 o Lowest priority SHOULD be given to RERR messages generated in 1208 response to RREP messages which cannot be forwarded. In this case 1209 the route request will be retried at a later point. 1211 To implement the congestion control, a queue length is set. If the 1212 queue is full, in order to queue a new message, a message of lower 1213 priority must be removed from the queue. If this is not possible, 1214 the new message MUST be discarded. The queue should be sorted in 1215 order of message priority 1217 6.6. Route Discovery, Retries and Buffering 1219 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1220 messages are multicast to solicit an RREP, whereas RREP are unicast. 1221 The constants used in this section are defined in Section 12. 1223 When an AODVv2 router needs to forward an IP packet (with source 1224 address OrigAddr and destination address TargAddr) from one of its 1225 Router Clients, it needs a route to TargAddr in its Routing 1226 Information Base. If no route exists, the AODVv2 router generates 1227 (RREQ_Gen) and multicasts a Route Request message (RREQ), on all 1228 configured interfaces, containing information about the source and 1229 destination. The procedure for this is described in Section 7.1.1. 1230 Each generated RREQ results in an increment to the router's sequence 1231 number. The AODVv2 router generating an RREQ is referred to as 1232 RREQ_Gen. 1234 Buffering might be configured for IP packets awaiting a route for 1235 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1236 of IP packets might have both positive and negative effects. TCP 1237 connection establishment will benefit if packets are queued while 1238 route discovery is performed [Koodli01], but real-time traffic, 1239 voice, and scheduled delivery may suffer if packets are buffered and 1240 subjected to delays. Recommendations for appropriate buffer methods 1241 are out of scope for this specification. Determining which packets 1242 to discard first when the buffer is full is a matter of policy at 1243 each AODVv2 router. Using different (or no) buffer methods might 1244 affect performance but does not affect interoperability. 1246 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1247 a route toward TargAddr. This can be achieved by monitoring the 1248 entry in the Multicast Route Message Table that corresponds to the 1249 generated RREQ. When CurrentTime exceeds RteMsg.Timestamp + 1250 RREQ_WAIT_TIME and no RREP has been received, RREQ_Gen will retry the 1251 route discovery. 1253 To reduce congestion in a network, repeated attempts at route 1254 discovery for a particular target address utilize a binary 1255 exponential backoff: for each additional attempt, the time to wait 1256 for receipt of the RREP is multiplied by 2. If the requested route 1257 is not discovered within the wait period, another RREQ is sent, up to 1258 a total of DISCOVERY_ATTEMPTS_MAX. This is the same technique used 1259 in AODV [RFC3561]. 1261 Through the use of bidirectional link monitoring and blacklists (see 1262 Section 6.2), uni-directional links on an initially selected route 1263 will be ignored on subsequent route discovery attempts. 1265 After DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an 1266 RREP response to the final RREQ, route discovery is considered to 1267 have failed. If an attempted route discovery has failed, RREQ_Gen 1268 SHOULD wait at least RREQ_HOLDDOWN_TIME before attempting another 1269 route discovery to the same destination, in order to avoid repeatedly 1270 generating control traffic that is unlikely to discover a route. Any 1271 IP packets buffered for TargAddr are also dropped and a Destination 1272 Unreachable ICMP message (Type 3) with a code of 1 (Host Unreachable 1273 Error) is delivered to the source of the packet, so that the 1274 application knows about the failure. 1276 If RREQ_Gen does receive a route message containing a route to 1277 TargAddr within the timeout, it processes the message according to 1278 Section 7. When a valid LocalRoute entry is created in the Local 1279 Route Set, the route is also installed in the Routing Information 1280 Base, and the router will begin sending the buffered IP packets. Any 1281 retry timers for the corresponding RREQ are then cancelled. 1283 During route discovery, all routers on the path obtain a route to 1284 both OrigPrefix and TargPrefix, so that routes are constructed in 1285 both directions. The route is optimized for the forward route. 1287 6.7. Processing Received Route Information 1289 A Route Request (RREQ) contains a route to OrigPrefix, and a Route 1290 Reply (RREP) contains a route to TargPrefix. All AODVv2 routers that 1291 receive a route message are able to store the route contained within 1292 it in their Local Route Set. Incoming information is first checked to 1293 verify that it is both safe to use and offers an improvement to 1294 existing information, as explained in Section 6.7.1. If these checks 1295 pass, the Local Route Set MUST be updated according to Section 6.7.2. 1297 In the processes below, RteMsg is used to denote the received route 1298 message, AdvRte is used to denote the route contained within it, and 1299 LocalRoute denotes an existing entry in the Local Route Set which 1300 matches AdvRte on address, prefix length, metric type, and SeqNoRtr. 1302 AdvRte has the following properties: 1304 o AdvRte.Address := RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix 1305 (in RREP) 1307 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1308 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1309 in RteMsg, prefix length is the address length, in bits, of 1310 RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix (in RREP) 1312 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1313 (in RREP) 1315 o AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the 1316 sending interface of the router from which the RteMsg was 1317 received) 1319 o AdvRte.MetricType := RteMsg.MetricType 1321 o AdvRte.Metric := RteMsg.Metric 1323 o AdvRte.Cost := Cost(R) using the cost function associated with the 1324 route's metric type. For cost metrics, Cost(R) = AdvRte.Metric + 1325 Cost(L), as described in Section 5, where L is the link from the 1326 advertising router 1328 o AdvRte.SeqNoRtr := the IP address in the Address List of type 1329 SeqNoRtr if one exists, otherwise 0 1331 6.7.1. Evaluating Route Information 1333 An incoming advertised route (AdvRte) is compared to existing 1334 LocalRoutes to determine whether the advertised route is to be used 1335 to update the AODVv2 Local Route Set. The incoming route information 1336 MUST be processed as follows: 1338 1. Search for LocalRoutes in the Local Route Set matching AdvRte's 1339 address, prefix length, metric type, and SeqNoRtr (the AODVv2 1340 router address corresponding to the sequence number). 1342 * If no matching LocalRoute exists, AdvRte MUST be used to 1343 update the Local Route Set and no further checks are required. 1345 * If matching LocalRoutes are found, continue to the next step. 1347 2. Compare sequence numbers using the technique described in 1348 Section 4.4 1350 * If AdvRte is more recent than all matching LocalRoutes, AdvRte 1351 MUST be used to update the Local Route Set and no further 1352 checks are required. 1354 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1355 Local Route Set. Ignore AdvRte for further processing. 1357 * If the sequence numbers are equal, continue to the next step. 1359 3. Check that AdvRte is safe against routing loops compared to all 1360 matching LocalRoutes (see Section 5) 1362 * If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte 1363 for further processing. AdvRte MUST NOT be used to update the 1364 Local Route Set because using the incoming information might 1365 cause a routing loop. 1367 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to the 1368 next step. 1370 4. Compare route costs 1372 * If AdvRte is better than all matching LocalRoutes, it MUST be 1373 used to update the Local Route Set because it offers 1374 improvement. 1376 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte 1377 SHOULD NOT be used to update the Local Route Set because it 1378 will offer no improvement. 1380 * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for 1381 further processing. AdvRte MUST NOT be used to update the 1382 Local Route Set because it does not offer any improvement. 1384 * If AdvRte is not better (i.e., it is worse or equal) but 1385 LocalRoute is Invalid, AdvRte SHOULD be used to update the 1386 Local Route Set because it can safely repair the existing 1387 Invalid LocalRoute. 1389 If the advertised route is to be used to update the Local Route Set, 1390 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1391 routes will remain in the Local Route Set. 1393 For information on how to apply these changes to the Routing 1394 Information Base, see Section 4.5. 1396 6.7.2. Applying Route Updates 1398 After determining that AdvRte is to be used to update the Local Route 1399 Set (as described in Section 6.7.1), the following procedure applies. 1401 If AdvRte is obtained from an RREQ message, the link to the next hop 1402 neighbor may not be confirmed as bidirectional (see Section 4.3). If 1403 there is no existing matching route in the Local Route Set, AdvRte 1404 MUST be installed to allow a corresponding RREP to be sent. If a 1405 matching entry already exists, and the link to the neighbor can be 1406 confirmed as bidirectional, AdvRte offers potential improvement. 1408 The route update is applied as follows: 1410 1. If no existing entry in the Local Route Set matches AdvRte's 1411 address, prefix length, metric type and SeqNoRtr, continue to 1412 Step 4 and create a new entry in the Local Route Set. 1414 2. If two matching LocalRoutes exist in the Local Route Set, one is 1415 a valid route, and one is an Unconfirmed route, AdvRte may offer 1416 further improvement to the Unconfirmed route, or may offer an 1417 update to the valid route. 1419 * If AdvRte.NextHop's Neighbor.State is Heard, the advertised 1420 route may offer improvement to the existing valid route, if 1421 the link to the next hop can be confirmed as bidirectional. 1422 Continue processing from Step 5 to update the existing 1423 Unconfirmed LocalRoute. 1425 * If AdvRte.NextHop's Neighbor.State is Confirmed, the 1426 advertised route offers an update or improvement to the 1427 existing valid route. Continue processing from Step 5 to 1428 update the existing valid LocalRoute. 1430 3. If only one matching LocalRoute exists in the Local Route Set: 1432 * If AdvRte.NextHop's Neighbor.State is Confirmed, continue 1433 processing from Step 5 to update the existing LocalRoute. 1435 * If AdvRte.NextHop's Neighbor.State is Heard, AdvRte may offer 1436 improvement the existing LocalRoute, if the link to 1437 AdvRte.NextHop can be confirmed as bidirectional. 1439 * If LocalRoute.State is Unconfirmed, AdvRte is an improvement 1440 to an existing Unconfirmed route. Continue processing from 1441 Step 5 to update the existing LocalRoute. 1443 * If LocalRoute.State is Invalid, AdvRte can replace the 1444 existing LocalRoute. Continue processing from Step 5 to 1445 update the existing LocalRoute. 1447 * If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored 1448 as an additional entry in the Local Route Set, with 1449 LocalRoute.State set to Unconfirmed. Continue processing from 1450 Step 4 to create a new LocalRoute. 1452 4. Create an entry in the Local Route Set and initialize as follows: 1454 * LocalRoute.Address := AdvRte.Address 1456 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1458 * LocalRoute.MetricType := AdvRte.MetricType 1460 5. Update the LocalRoute as follows: 1462 * LocalRoute.SeqNum := AdvRte.SeqNum 1464 * LocalRoute.NextHop := AdvRte.NextHop 1466 * LocalRoute.NextHopInterface := interface on which RteMsg was 1467 received 1469 * LocalRoute.Metric := AdvRte.Cost 1471 * LocalRoute.LastUsed := CurrentTime 1473 * LocalRoute.LastSeqNumUpdate := CurrentTime 1474 * LocalRoute.SeqNoRtr := AdvRte.SeqNoRtr 1476 6. If a new LocalRoute was created, or if the existing 1477 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1478 follows: 1480 * LocalRoute.State := Unconfirmed (if the next hop's 1481 Neighbor.State is Heard) 1483 * LocalRoute.State := Idle (if the next hop's Neighbor.State is 1484 Confirmed) 1486 7. If an existing LocalRoute.State changed from Invalid or 1487 Unconfirmed to become Idle, any matching Unconfirmed LocalRoute 1488 with worse metric value SHOULD be expunged. 1490 8. If an existing LocalRoute was updated with a better metric value, 1491 any matching Unconfirmed LocalRoute with worse metric value 1492 SHOULD be expunged. 1494 9. If this update results in LocalRoute.State of Active or Idle, 1495 which matches a route request which is still in progress, the 1496 associated route request retry timers MUST be cancelled. 1498 If this update to the Local Route Set results in two LocalRoutes to 1499 the same address, the best LocalRoute will be Unconfirmed. In order 1500 to improve the route used for forwarding, the router SHOULD try to 1501 determine if the link to the next hop of that LocalRoute is 1502 bidirectional, by using that LocalRoute to forward future RREPs and 1503 request acknowledgements (see Section 7.2.1 and Section 7.3. 1505 6.8. Suppressing Redundant Messages (Multicast Route Message Set) 1507 When route messages are flooded in a MANET, an AODVv2 router may 1508 receive several instances of the same message. Forwarding every one 1509 of these would provide little additional benefit, while generating 1510 unnecessary signaling traffic and consequently additional 1511 interference. 1513 Each AODVv2 router stores information about recently received route 1514 messages in the AODVv2 Multicast Route Message Set (Section 4.6). 1516 In this section, an entry in the Multicast Route Message Set will be 1517 called a "multicast entry" for short. Each multicast entry SHOULD be 1518 maintained for at least RteMsg_ENTRY_TIME after the last Timestamp 1519 update in order to account for long-lived RREQs traversing the 1520 network. An entry MUST be deleted when the sequence number is no 1521 longer valid, i.e., after MAX_SEQNUM_LIFETIME. Memory-constrained 1522 devices MAY remove the entry before this time. 1524 Received RteMsgs are tested against multicast entries containing 1525 information about previously received route messages. A multicast 1526 entry is considered to be compatible with a received RteMsg, or 1527 another multicast entry, if they both contain the same OrigPrefix, 1528 OrigPrefixLen, TargPrefix, and MetricType. A multicast entry is 1529 considered to be comparable with a received RteMsg, or another 1530 multicast entry, if they are compatible and if, in addition, they 1531 both have the same SeqNoRtr. These terms will be used in the 1532 following algorithm determining how to process a received RteMsg, and 1533 whether or not the RteMsg is redundant. 1535 If the received message is determined to be redundant, no forwarding 1536 or response to the message is needed. A message is considered to be 1537 redundant if either (a) a comparable newer (as determined by the 1538 OrigSeqNum) entry has already been received with information about 1539 the source and destination addresses of the route discovery operation 1540 or (b) it cannot be determined whether the message is newer compared 1541 to existing entries, but the received message metric value is not any 1542 better than metric values in compatible multicast entries. 1544 To use the received RteMsg to update the Multicast Route Message Set, 1545 and to determine whether or not the received RteMsg requires 1546 additional processing as specified in Section 7, perform the 1547 following steps: 1549 1. First, search for a comparable multicast entry. If there is no 1550 such entry, then create a new entry as follows: 1552 * RteMsg.OrigPrefix := OrigPrefix from the RteMsg 1554 * RteMsg.OrigPrefixLen := the prefix length associated with 1555 OrigPrefix 1557 * RteMsg.TargPrefix := TargPrefix from the message 1559 * RteMsg.SeqNoRtr := the SeqNoRtr associated with RteMsg if 1560 present, otherwise the sequence number associated with 1561 OrigPrefix, if RteMsg is an RREQ 1563 * RteMsg.OrigSeqNum := the sequence number associated with 1564 OrigPrefix, if RteMsg is an RREQ 1566 * RteMsg.TargSeqNum := the sequence number associated with 1567 TargPrefix, if RteMsg is an RREP 1569 * RteMsg.Metric := the metric value associated with OrigPrefix 1570 in a received RREQ 1572 * RteMsg.MetricType := the metric type associated with 1573 RteMsg.Metric 1575 * RteMsg.Interface := the network interface on which the RteMsg 1576 was received. 1578 * RteMsg.Timestamp := CurrentTime 1580 * RteMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1582 2. Otherwise, if there is a comparable multicast entry, first update 1583 the timing information: 1585 * RteMsg.Timestamp := CurrentTime 1587 * RteMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1589 Then compare sequence numbers using the technique described in 1590 Section 4.4: 1592 * If the multicast entry is newer compared to the received 1593 RteMsg, drop the RteMsg and discontinue processing. 1595 * Otherwise, if the sequence numbers are the same, and the 1596 metric value for the multicast entry is no worse than the 1597 metric value in the received RteMsg, drop the RteMsg and 1598 discontinue processing. 1600 Otherwise the RteMsg is newer than the multicast entry or has a 1601 better metric. Continue as follows: 1603 * RteMsg.OrigSeqNum := the sequence number associated with 1604 OrigPrefix, if RteMsg is an RREQ 1606 * RteMsg.TargSeqNum := the sequence number associated with 1607 TargPrefix, if RteMsg is an RREP 1609 * RteMsg.Metric := the metric value associated with OrigPrefix 1610 in a received RREQ 1612 3. Compare the metric values for any other compatible entries with 1613 the updated multicast entry containing the information from the 1614 received RteMsg. If any other compatible entry has a metric as 1615 good or better than that from the received RteMsg, then drop the 1616 RteMsg and discontinue processing. 1618 If processing for the RteMsg has not been discontinued according to 1619 the above instructions, then continue processing the message as 1620 specified in Section 7.1.3. 1622 6.9. Suppressing Redundant Route Error Messages (Route Error Set) 1624 In order to avoid flooding the network with RERR messages when a 1625 stream of IP packets to an unreachable address arrives, an AODVv2 1626 router SHOULD avoid creating duplicate messages by determining 1627 whether an equivalent RERR has recently been sent. This is achieved 1628 with the help of the Route Error Set (see Section 4.7). 1630 To determine if a RERR should be created: 1632 1. Search for an entry in the Route Error Set where: 1634 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1635 reported 1637 * RerrMsg.PktSource == PktSource to be included in the RERR 1639 If a matching entry is found, no further processing is required 1640 and the RERR SHOULD NOT be sent. 1642 2. If no matching entry is found, a new entry with the following 1643 properties is created, and the RERR is created and sent as 1644 described in Section 7.4.1: 1646 * RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT 1648 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1649 reported 1651 * RerrMsg.PktSource == PktSource to be included in the RERR. 1653 6.10. Local Route Set Maintenance 1655 Route maintenance involves the following operations: 1657 o monitoring LocalRoutes in the Local Route Set, 1659 o updating LocalRoute.State to handle route timeouts, 1661 o (for possibly unidirectional links) confirming a route to 1662 OrigAddr, 1664 o reporting routes that become Invalid. 1666 6.10.1. LocalRoute State Changes 1668 During normal operation, AODVv2 does not require explicit timeouts to 1669 manage the lifetime of a valid route. At any time, any LocalRoute 1670 MAY be examined and updated according to the rules below. In case a 1671 Routing Information Base is used for forwarding, the corresponding 1672 RIB entry MUST be updated as soon as the state of a LocalRoute.State 1673 changes. Otherwise, if timers are not used to prompt updates of 1674 LocalRoute.State, the LocalRoute.State MUST be checked before IP 1675 packet forwarding and before any operation based on LocalRoute.State. 1677 Route timeout behaviour is as follows: 1679 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1680 LocalRoute.LastSeqNumUpdate. 1682 o An Idle route MUST be marked as Active when used to forward an IP 1683 packet. 1685 o If an Idle route is not used to forward an IP packet within 1686 MAX_IDLETIME, LocalRoute.State MUST be set to Invalid. 1688 o An Invalid route SHOULD remain in the Local Route Set, since 1689 LocalRoute.SeqNum is used to classify future information about 1690 LocalRoute.Address as stale or fresh. 1692 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1693 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 0. 1694 This is required so that any AODVv2 routers following the 1695 initialization procedure can safely begin routing functions using 1696 a new sequence number. A LocalRoute with LocalRoute.State set to 1697 Active or Idle can remain in the Local Route Set after the 1698 sequence number has been set to 0, for example if the route is 1699 reliably carrying traffic. If LocalRoute.State is Invalid, or 1700 later becomes Invalid, the LocalRoute MUST be expunged from the 1701 Local Route Set. 1703 LocalRoutes can become Invalid before a timeout occurs, as follows: 1705 o If an external mechanism reports a link as broken, all LocalRoutes 1706 using that link for LocalRoute.NextHop MUST immediately have 1707 LocalRoute.State set to Invalid. 1709 o LocalRoute.State MUST immediately be set to Invalid if a Route 1710 Error (RERR) message is received where: 1712 * The sender is LocalRoute.NextHop, or PktSource is a Router 1713 Client address 1715 * There is an Address in AddressList which matches 1716 LocalRoute.Address, and: 1718 + The prefix length associated with this Address, if any, 1719 matches LocalRoute.PrefixLength 1721 + The sequence number associated with this Address, if any, is 1722 newer or equal to LocalRoute.SeqNum (see Section 4.4) 1724 + The metric type associated with this Address matches 1725 LocalRoute.MetricType 1727 A LocalRoute can be Confirmed by inferring connectivity to OrigAddr. 1729 o When an AODVv2 router sends an RREP to OrigAddr for destination 1730 TargAddr, and subsequently the AODVv2 router receives a packet 1731 from OrigAddr with destination TargAddr, the AODVv2 router infers 1732 that the route to OrigAddr has been confirmed. The corresponding 1733 state for LocalRoute.OrigAddr is changed to Active. 1735 LocalRoutes are updated when Neighbor.State is updated: 1737 o While the value of Neighbor.State is set to Heard, any routes in 1738 the Local Route Set using that neighbor as a next hop MUST have 1739 LocalRoute.State set to Unconfirmed. 1741 o When the value of Neighbor.State is set to Blacklisted, any valid 1742 routes in the Local Route Set using that neighbor for their next 1743 hop MUST have LocalRoute.State set to Invalid. 1745 o When a Neighbor Set entry is removed, all routes in the Local 1746 Route Set using that neighbor as next hop MUST have 1747 LocalRoute.State set to Invalid. 1749 Memory constrained devices MAY choose to expunge routes from the 1750 AODVv2 Local Route Set at other times, but MUST adhere to the 1751 following rules: 1753 o An Active route MUST NOT be expunged, as it is in use. If 1754 deleted, IP traffic forwarded to this router would prompt 1755 generation of a Route Error message, necessitating a Route Request 1756 to be generated by the originator's router to re-establish the 1757 route. 1759 o An Idle route SHOULD NOT be expunged, as it is still valid for 1760 forwarding IP traffic. If deleted, this could result in dropped 1761 IP packets and a Route Request could be multicasted to re- 1762 establish the route. 1764 o Any Invalid route MAY be expunged. Least recently used Invalid 1765 routes SHOULD be expunged first, since the sequence number 1766 information is less likely to be useful. 1768 o An Unconfirmed route MUST NOT be expunged if it was installed 1769 within the last RREQ_WAIT_TIME, because it may correspond to a 1770 route discovery in progress. A Route Reply message might be 1771 received which needs to use the LocalRoute.NextHop information. 1772 Otherwise, it MAY be expunged. 1774 6.10.2. Reporting Invalid Routes 1776 When LocalRoute.State changes from Active to Invalid as a result of a 1777 broken link or a received Route Error (RERR) message, other AODVv2 1778 routers MUST be informed by sending an RERR message containing 1779 details of the invalidated route. 1781 An RERR message MUST also be sent when an AODVv2 router receives an 1782 RREP message to forward, but the LocalRoute to the OrigAddr in the 1783 RREP has been lost or is marked as Invalid. 1785 A packet or message triggering the RERR MUST be discarded. 1787 Generation of an RERR message is described in Section 7.4.1. 1789 7. AODVv2 Protocol Messages 1791 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1792 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1793 (RERR). 1795 Each AODVv2 message is defined as a set of data. Rules for the 1796 generation, reception and forwarding of each message type are 1797 described in the following sections. Section 8 discusses how the 1798 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1799 TLVs. 1801 7.1. Route Request (RREQ) Message 1803 Route Request messages are used in route discovery operations to 1804 request a route to a specified target address. RREQ messages have 1805 the following contents: 1807 +-----------------------------------------------------------------+ 1808 | msg_hop_limit | 1809 +-----------------------------------------------------------------+ 1810 | AddressList | 1811 +-----------------------------------------------------------------+ 1812 | PrefixLengthList (optional) | 1813 +-----------------------------------------------------------------+ 1814 | OrigSeqNum, (optional) TargSeqNum | 1815 +-----------------------------------------------------------------+ 1816 | MetricType | 1817 +-----------------------------------------------------------------+ 1818 | OrigMetric | 1819 +-----------------------------------------------------------------+ 1821 Figure 1: RREQ message contents 1823 msg_hop_limit 1824 The remaining number of hops allowed for dissemination of the RREQ 1825 message. 1827 AddressList 1828 Contains: 1830 * OrigPrefix, from the Router Client Set entry which includes 1831 OrigAddr, the source address of the IP packet for which a route 1832 is requested, 1834 * TargPrefix, set to TargAddr, the destination address of the IP 1835 packet for which a route is requested, and 1837 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 1838 OrigRtr -- i.e., the router that originated the Sequence Number 1839 for this RREQ. 1841 PrefixLengthList 1842 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1843 associated with the Router Client Set entry which includes 1844 OrigAddr. If omitted, the prefix length is equal to OrigAddr's 1845 address length in bits. 1847 OrigSeqNum 1848 The sequence number associated with OrigPrefix. 1850 TargSeqNum 1851 A sequence number associated with an existing Invalid route to 1852 TargAddr. This MAY be included if available. 1854 MetricType 1855 The metric type associated with OrigMetric. 1857 OrigMetric 1858 The metric value associated with the route to OrigPrefix, as 1859 determined by the sender of the message. 1861 7.1.1. RREQ Generation 1863 An RREQ is generated to discover a route when an IP packet needs to 1864 be forwarded for a Router Client, and no valid route currently exists 1865 for the packet's destination in the Routing Information Base. 1867 If the limit for the rate of AODVv2 control message generation has 1868 been reached, no message SHOULD be generated Section 6.5. Before 1869 creating an RREQ, the router SHOULD check the Multicast Route Message 1870 Set to see if a compatible RREQ has recently been sent for the 1871 requested destination. If so, and the wait time for a reply has not 1872 yet been reached, the router SHOULD continue to await a response 1873 without generating a new RREQ. If the timeout has been reached, a 1874 new RREQ MAY be generated. If buffering is configured, incoming IP 1875 packets awaiting this route SHOULD be buffered until the route 1876 discovery is completed. 1878 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1879 this procedure: 1881 1. Set msg_hop_limit := MAX_HOPCOUNT 1883 2. Set AddressList := {OrigPrefix, TargPrefix} 1885 3. For the PrefixLengthList: 1887 * If OrigAddr is part of an address range configured as a Router 1888 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1889 null}. 1891 * Otherwise, omit PrefixLengthList. 1893 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 1894 IP address to AddressList, with AddressType SeqNoRtr. 1896 4. For OrigSeqNum: 1898 * Increment the router Sequence Number as specified in 1899 Section 4.4. 1901 * Set OrigSeqNum := router Sequence Number. 1903 5. For TargSeqNum: 1905 * If an Invalid route exists in the Local Route Set matching 1906 TargAddr using longest prefix matching and has a valid 1907 sequence number, set TargSeqNum := LocalRoute.SeqNum. 1909 * If no Invalid route exists in the Local Route Set matching 1910 TargAddr, or the route doesn't have a sequence number, omit 1911 TargSeqNum. 1913 6. Include MetricType and set the type accordingly 1915 7. Find the Router Client Set entry where RouterClient.IPAddress == 1916 OrigPrefix: 1918 * Set OrigMetric := RouterClient.Cost 1920 This AODVv2 message is used to create a corresponding [RFC5444] 1921 message (see Section 8) which is handed to the RFC5444 multiplexer 1922 for further processing. By default, the multiplexer is instructed to 1923 multicast RREQ messages to LL-MANET-Routers on all interfaces 1924 configured for AODVv2 operation. 1926 7.1.2. RREQ Reception 1928 Upon receiving a Route Request, an AODVv2 router performs the 1929 following steps: 1931 1. Check and update the Neighbor Set according to Section 6.3 1933 * If the sender has Neighbor.State set to Blacklisted, ignore 1934 this RREQ for further processing. 1936 2. Verify that the message contains the required data: 1937 msg_hop_limit, OrigPrefix, TargPrefix, OrigSeqNum, and 1938 OrigMetric, and that OrigPrefix and TargPrefix are valid address 1939 prefixes 1941 * If not, ignore this RREQ for further processing. 1943 3. Check that the MetricType is supported and configured for use 1945 * If not, ignore this RREQ for further processing. 1947 4. Determine whether the cost of the advertised route will exceed 1948 the maximum allowed metric value for the metric type (Metric <= 1949 MAX_METRIC[MetricType] - Cost(L)) 1950 * If it will, ignore this RREQ for further processing. 1952 5. Process the route to OrigPrefix as specified in Section 6.7 1954 6. Determine whether or not the information in the message is 1955 redundant, by following the procedure in Section 6.8; if 1956 redundant, ignore this RREQ for further processing. 1958 7. Check if the TargPrefix matches an entry in the Router Client Set 1960 * If so, generate an RREP as specified in Section 7.2.1. 1962 * If not, continue to RREQ forwarding Section 7.2.3. 1964 7.1.3. RREQ Forwarding 1966 Forwarding or responding to a RteMsg provides up-to-date information 1967 and improved metrics to other routers. If a RteMsg is not forwarded, 1968 routes needed by applications may not be discovered. 1970 By forwarding an RREQ, a router advertises that it will forward IP 1971 packets to the OrigPrefix contained in the RREQ according to the 1972 information enclosed. The router MAY choose not to forward the RREQ, 1973 for example if the router is heavily loaded or low on energy and 1974 therefore unwilling to advertise routing capability for more traffic. 1975 This could, however, decrease connectivity in the network or result 1976 in non-optimal paths. 1978 The RREQ MUST NOT be forwarded if the received msg_hop_limit = 1, or 1979 if the limit for the rate of AODVv2 control message generation has 1980 been reached. Otherwise, the RREQ is updated and forwarded as 1981 follows: 1983 1. Set msg_hop_limit := received msg_hop_limit - 1 1985 2. Set OrigMetric := LocalRoute[OrigPrefix].Metric 1987 This modified RREQ is handed to the [RFC5444] multiplexer for further 1988 processing. By default, the multiplexer is instructed to multicast 1989 the message to LL-MANET-Routers on all interfaces configured for 1990 AODVv2 operation. 1992 7.2. Route Reply (RREP) Message 1994 When a Route Request message is received, requesting a route to a 1995 target address (TargAddr) which is configured as part of a Router 1996 Client Set entry, a Route Reply message is sent in response. The 1997 RREP offers a route to TargPrefix. 1999 RREP messages have the following contents: 2001 +-----------------------------------------------------------------+ 2002 | msg_hop_limit | 2003 +-----------------------------------------------------------------+ 2004 | AddressList | 2005 +-----------------------------------------------------------------+ 2006 | PrefixLengthList (optional) | 2007 +-----------------------------------------------------------------+ 2008 | TargSeqNum | 2009 +-----------------------------------------------------------------+ 2010 | MetricType | 2011 +-----------------------------------------------------------------+ 2012 | TargMetric | 2013 +-----------------------------------------------------------------+ 2015 Figure 2: RREP message contents 2017 msg_hop_limit 2018 The remaining number of hops allowed for dissemination of the RREP 2019 message. 2021 AddressList 2022 Contains: 2024 * OrigPrefix, from the Router Client entry which includes 2025 OrigAddr, the source address of the IP packet for which a route 2026 is requested 2028 * TargPrefix, set to TargAddr, the destination address of the IP 2029 packet for which a route is requested. 2031 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 2032 TargRtr -- i.e., the router that originated the Sequence Number 2033 for this RREP. 2035 PrefixLengthList 2036 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 2037 associated with the Router Client Set entry which includes 2038 TargAddr. If omitted, the prefix length is equal to TargAddr's 2039 address length, in bits. 2041 TargSeqNum 2042 The sequence number associated with TargPrefix. 2044 MetricType 2045 The metric type associated with TargMetric. 2047 TargMetric 2048 The metric value associated with the route to TargPrefix, as seen 2049 from the sender of the message. 2051 7.2.1. RREP Generation 2053 A Route Reply message is generated when a Route Request for a Router 2054 Client of the AODVv2 router arrives. This is the case when 2055 RteMsg.TargPrefix matches an entry in the Router Client Set of the 2056 AODVv2 router. 2058 Before creating an RREP, the router SHOULD check whether 2059 CONTROL_TRAFFIC_LIMIT has been reached. If so, the RREP SHOULD NOT 2060 be created. 2062 The RREP will traverse the path of the route to OrigPrefix. If the 2063 best route to OrigPrefix in the Local Route Set is Unconfirmed, the 2064 link to the next hop neighbor is not yet confirmed as bidirectional 2065 (see Section 6.2). In this case an RREP_Ack MUST also be sent as 2066 described in Section 7.3, in order to request an acknowledgement 2067 message from the next hop router to prove that the link is 2068 bidirectional. If the best route to OrigPrefix in the Local Route 2069 Set is valid, the link to the next hop neighbor is already confirmed 2070 as bidirectional, and no acknowledgement is required. 2072 Implementations MAY allow a number of retries of the RREP if a 2073 requested acknowledgement is not received within 2074 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 2075 maximum of RREP_RETRIES, using the same exponential backoff described 2076 in Section 6.6 for RREQ retries. The acknowledgement MUST be 2077 considered to have failed after the wait time for an RREP_Ack 2078 response to the final RREP. 2080 To generate the RREP, the router (also referred to as RREP_Gen) 2081 follows this procedure: 2083 1. Set msg_hop_limit := MAX_HOPCOUNT - msg_hop_limit from the 2084 received RREQ message 2086 2. Set Address List := {OrigPrefix, TargPrefix} 2088 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 2089 IP address to AddressList, with AddressType SeqNoRtr. 2091 3. For the PrefixLengthList: 2093 * If TargAddr is part of an address range configured as a Router 2094 Client, set PrefixLengthList := {null, 2095 RouterClient.PrefixLength}. 2097 * Otherwise, omit PrefixLengthList. 2099 4. For the TargSeqNum: 2101 * Increment the router Sequence Number as specified in 2102 Section 4.4. 2104 * Set TargSeqNum := router Sequence Number. 2106 5. Include MetricType and set the type to match the MetricType in 2107 the received RREQ message. 2109 6. Set TargMetric := RouterClient.Cost for the Router Client Set 2110 entry which includes TargAddr. 2112 This AODVv2 message is used to create a corresponding [RFC5444] 2113 message (see Section 8) which is handed to the RFC5444 multiplexer 2114 for further processing. The multiplexer is instructed to unicast the 2115 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2116 LocalRoute[OrigPrefix].NextHopInterface. 2118 7.2.2. RREP Reception 2120 Upon receiving a Route Reply, an AODVv2 router performs the following 2121 steps: 2123 1. Verify that the message contains the required data: 2124 msg_hop_limit, OrigPrefix, TargPrefix, TargSeqNum, and 2125 TargMetric, and that OrigPrefix and TargPrefix are valid 2126 addresses 2128 * If not, ignore this RREP for further processing. 2130 2. Check that the MetricType is supported and configured for use 2132 * If not, ignore this RREP for further processing. 2134 3. If this RREP does not correspond to an RREQ generated or 2135 forwarded in the last RREQ_WAIT_TIME, ignore for further 2136 processing. 2138 4. If the Multicast Route Message Set does not contain an entry 2139 where: 2141 o RteMsg.OrigPrefix == RREP.OrigPrefix 2143 o RteMsg.OrigPrefixLen == RREP.OrigPrefixLen 2145 o RteMsg.TargAddr exists within RREP.TargPrefix 2147 o RteMsg.OrigSeqNum <= RREP.OrigSeqNum 2149 o RteMsg.SeqNoRtr = RREP.SeqNoRtr 2151 o RteMsg.MetricType == RREP.MetricType 2153 o RteMsg.Timestamp > CurrentTime - RREQ_WAIT_TIME 2155 o RteMsg.Interface == The interface on which the RREP was received 2157 then, ignore this RREP for further processing, since it does not 2158 correspond to a previously sent RREQ. Otherwise continue as follows: 2160 1. Update the Neighbor Set according to Section 6.3 2162 2. Determine whether the cost of the advertised route exceeds the 2163 maximum allowed metric value for the metric type (Metric <= 2164 MAX_METRIC[MetricType] - Cost(L)) 2166 * If it does, ignore this RREP for further processing. 2168 3. Process the route to TargPrefix as specified in Section 6.7 2170 4. Determine whether the message is redundant by comparing to 2171 entries in the Multicast Route Message Set (Section 6.8) 2173 * If redundant, ignore this RREP for further processing. 2175 * If not redundant, save the information in the Multicast Route 2176 Message Set to identify future redundant RREP messages and 2177 continue processing. 2179 5. Determine whether the OrigPrefix matches an entry in the Router 2180 Client Set 2182 * If so, no further processing is necessary. 2184 * If not, continue to the next step. 2186 6. Determine whether a valid (Active or Idle) or Unconfirmed 2187 LocalRoute exists to OrigPrefix 2188 * If so, continue to RREP forwarding Section 7.2.3. 2190 * If not, a Route Error message SHOULD be transmitted toward 2191 TargPrefix according to Section 7.4.1; the RREP MUST be 2192 discarded and not forwarded. 2194 7.2.3. RREP Forwarding 2196 A received Route Reply message is forwarded toward OrigPrefix. By 2197 forwarding the RREP, a router advertises that it has a route to 2198 TargPrefix. 2200 The RREP MUST NOT be forwarded if the received msg_hop_limit = 1, or 2201 if CONTROL_TRAFFIC_LIMIT has been reached. Otherwise, the router 2202 MUST forward the RREP. 2204 The procedure for RREP forwarding is as follows: 2206 1. Set msg_hop_limit := received msg_hop_limit - 1 2208 2. If the link to the next hop router toward OrigAddr is not known 2209 to be bidirectional, also verify bidirectionality (see 2210 Section 6.2). 2212 3. Set TargMetric := LocalRoute[TargPrefix].Metric 2214 This modified message is handed to the [RFC5444] multiplexer for 2215 further processing. The multiplexer is instructed to unicast the 2216 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2217 LocalRoute[OrigPrefix].NextHopInterface. 2219 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2221 The Route Reply Acknowledgement is used as both a request and a 2222 response message to test bidirectionality of a link over which a 2223 Route Reply has also been sent. The router which forwards the RREP 2224 MUST send a Route Reply Acknowledgement message to the intended next 2225 hop, if the link to the next hop neighbor is not yet confirmed as 2226 bidirectional. 2228 The receiving router MUST then reply with a Route Reply 2229 Acknowledgement response message. 2231 When the Route Reply Acknowledgement response message is received by 2232 the sender of the RREP, it confirms that the link between the two 2233 routers is bidirectional (see Section 6.2). 2235 If the Route Reply Acknowledgement is not received within 2236 RREP_Ack_SENT_TIMEOUT, the link is determined to be unidirectional. 2238 +-----------------------------------------------------------------+ 2239 | AckReq (optional) | 2240 +-----------------------------------------------------------------+ 2242 Figure 3: RREP_Ack message contents 2244 7.3.1. RREP_Ack Request Generation 2246 An RREP_Ack MUST be generated if a Route Reply is sent over a link 2247 which is not known to be bidirectional. It includes an AckReq 2248 element to indicate that it is a request for acknowledgement. 2250 The RREP_Ack SHOULD NOT be generated if the limit for the rate of 2251 AODVv2 control message generation has been reached. 2253 The [RFC5444] representation of the RREP_Ack is discussed in 2254 Section 8. 2256 RREP_Ack requests MUST be unicast to LocalRoute[OrigPrefix].NextHop 2257 via LocalRoute[OrigPrefix].NextHopInterface. The multiplexer SHOULD 2258 be instructed to send the RREP_Ack in the same [RFC5444] packet as 2259 the RREP. 2261 The Neighbor Set entry for LocalRoute[OrigPrefix].NextHop MUST also 2262 be updated to indicate that an RREP_Ack is required (see 2263 Section 6.3). 2265 7.3.2. RREP_Ack Reception 2267 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2268 steps: 2270 1. Determine whether an AckReq element is included: 2272 * If so, create an RREP_Ack Response as described in 2273 Section 7.3.3. No further processing is required. 2275 * If not, continue to the next step. 2277 2. Determine whether the Neighbor Set contains an entry where: 2279 * Neighbor.IPAddress == IP.SourceAddress of the RREP_Ack message 2281 * Neighbor.State == Heard 2282 * Neighbor.Timeout < CurrentTime 2284 * Neighbor.Interface matches the interface on which the RREP_Ack 2285 was received 2287 If no such entry is found, the RREP_Ack was not expected; no 2288 actions are required and processing ends. Otherwise, the router 2289 sets Neighbor.Timeout to INFINITY_TIME, and processing continues 2290 to the next step. 2292 3. Update the Neighbor Set according to Section 6.3, including 2293 updating routes using this Neighbor as LocalRoute.NextHop. 2295 7.3.3. RREP_Ack Response Generation 2297 An RREP_Ack response MUST be generated if a received RREP_Ack 2298 includes an AckReq, unless the limit for the rate of AODVv2 control 2299 message generation has been reached in which case the RREP_Ack 2300 response SHOULD NOT be generated. 2302 There is no further data in an RREP_Ack response. The [RFC5444] 2303 representation is discussed in Section 8. In this case, the 2304 multiplexer is instructed to unicast the RREP_Ack to the source IP 2305 address of the RREP_Ack message that requested it, over the same 2306 interface on which the RREP_Ack was received. 2308 7.4. Route Error (RERR) Message 2310 A Route Error message is generated by an AODVv2 router to notify 2311 other AODVv2 routers about routes that are no longer available. An 2312 RERR message has the following contents: 2314 +-----------------------------------------------------------------+ 2315 | PktSource (optional) | 2316 +-----------------------------------------------------------------+ 2317 | AddressList | 2318 +-----------------------------------------------------------------+ 2319 | PrefixLengthList (optional) | 2320 +-----------------------------------------------------------------+ 2321 | SeqNumList (optional) | 2322 +-----------------------------------------------------------------+ 2323 | MetricTypeList | 2324 +-----------------------------------------------------------------+ 2326 Figure 4: RERR message contents 2328 PktSource 2329 The source address of the IP packet triggering the RERR. If the 2330 RERR is triggered by a broken link, PktSource is not required. 2332 AddressList 2333 The addresses of the routes not available through RERR_Gen. 2335 PrefixLengthList 2336 The prefix lengths, in bits, associated with the routes not 2337 available through RERR_Gen. These values indicate whether routes 2338 represent a single device or an address range. 2340 SeqNumList 2341 The sequence numbers (where known) of the routes not available 2342 through RERR_Gen. 2344 MetricTypeList 2345 The metric types associated with the routes not available through 2346 RERR_Gen. 2348 7.4.1. RERR Generation 2350 A Route Error message is generated when an AODVv2 router (also 2351 referred to as RERR_Gen) needs to report that a destination is not 2352 reachable. There are three events that cause this response: 2354 o When an IP packet that has been forwarded from another router, but 2355 there is no valid route in the Routing Information Base for its 2356 destination, the source of the packet needs to be informed that 2357 the route to the destination of the packet does not exist. The 2358 RERR generated MUST include PktSource set to the source address of 2359 the IP packet, and MUST contain only one unreachable address in 2360 the AddressList, i.e., the destination address of the IP packet. 2361 RERR_Gen MUST discard the IP packet that triggered generation of 2362 the RERR. The prefix length, sequence number and metric type 2363 SHOULD be included if known from an existing Invalid LocalRoute to 2364 the unreachable address. 2366 o When an RREP message cannot be forwarded because the LocalRoute to 2367 OrigPrefix has been lost or is Invalid, RREP_Gen needs to be 2368 informed that the route to OrigPrefix does not exist. The RERR 2369 generated MUST include PktSource set to the TargPrefix of the 2370 RREP, and MUST contain only one unreachable address in the 2371 AddressList, the OrigPrefix from the RREP. RERR_Gen MUST discard 2372 the RREP message that triggered generation of the RERR. The 2373 prefix length, sequence number and metric type SHOULD be included 2374 if known from an Invalid LocalRoute to the unreachable address. 2376 o When a link breaks, multiple LocalRoutes may become Invalid, and 2377 the RERR generated MAY contain multiple unreachable addresses. 2378 The RERR MUST include MetricTypeList. PktSource is omitted. All 2379 previously Active LocalRoutes that used the broken link MUST be 2380 reported. The AddressList, SeqNumList, and MetricTypeList will 2381 contain entries for each LocalRoute which has become Invalid. 2382 PrefixLengthList will be included if needed to report invalid 2383 routes to a non-default prefix. An RERR message is only sent if 2384 an Active LocalRoute becomes Invalid, though an AODVv2 router can 2385 also include Idle LocalRoutes that become Invalid if the 2386 configuration parameter ENABLE_IDLE_IN_RERR is set (see 2387 Section 12.3). 2389 The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been 2390 reached. The RERR also SHOULD NOT be generated if it is a duplicate, 2391 as determined by Section 6.9. 2393 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2394 from the address of one of its Router Clients, it forwards the ICMP 2395 packet in the same way as any other IP packet, and will not generate 2396 any RERR message based on the contents of the ICMP packet. 2398 To generate the RERR, the router follows this procedure: 2400 1. If necessary, include PktSource and set the value as given above 2402 2. For each LocalRoute that needs to be reported: 2404 * Insert LocalRoute.Address into the AddressList. 2406 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2407 and not equal to the address length. 2409 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2411 * Insert LocalRoute.MetricType into MetricTypeList. 2413 The AODVv2 message is used to create a corresponding [RFC5444] 2414 message (see Section 8). 2416 If the RERR is sent in response to an undeliverable IP packet or RREP 2417 message (i.e., if PktSource is included), the RERR SHOULD be sent 2418 unicast to the next hop on the route to PktSource. It MUST be sent 2419 over the same interface on which the undeliverable IP packet was 2420 received. If there is no route to PktSource, the RERR SHOULD be 2421 multicast to LL-MANET-Routers. If the RERR is sent in response to a 2422 broken link, i.e., PktSource is not included, the RERR is, by 2423 default, multicast to LL-MANET-Routers. 2425 Section 10 describes processing steps when the optional precursor 2426 lists feature is implemented. 2428 7.4.2. RERR Reception 2430 Upon receiving a Route Error, an AODVv2 router performs the following 2431 steps: 2433 1. Determine whether the message contains at least one unreachable 2434 address; if not, ignore this RERR for further processing. 2435 Otherwise continue as follows: 2437 2. For each address in the AddressList, check that: 2439 * The address is valid (routable and unicast). 2441 * The MetricType is supported and configured for use. 2443 * There is a LocalRoute with the same MetricType matching the 2444 address using longest prefix matching. 2446 * Either the LocalRoute's next hop is the sender of the RERR and 2447 the next hop interface is the interface on which the RERR was 2448 received, or PktSource is present in the RERR and is a Router 2449 Client address. 2451 * The unreachable address' sequence number is either unknown, or 2452 is no less than the LocalRoute's sequence number. 2454 If any of the above are false the address does not match a 2455 LocalRoute and MUST NOT be processed or regenerated in a RERR. 2457 If all of the above are true, the LocalRoute which matches the 2458 unreachable address MUST be marked as Invalid. Otherwise, 2459 regeneration of the RERR proceeds as follows. If the LocalRoute 2460 was previously Active, it MUST be reported in a regenerated RERR. 2461 If the LocalRoute was previously Idle, it MAY be reported in a 2462 regenerated RERR, if ENABLE_IDLE_IN_RERR is configured. The 2463 Local Route Set MUST be updated according to these rules: 2465 * If the LocalRoute's prefix length is the same as the 2466 unreachable address' prefix length, set LocalRoute.State to 2467 Invalid. 2469 * If the LocalRoute's prefix length is longer than the 2470 unreachable address' prefix length, the LocalRoute MUST be 2471 expunged from the Local Route Set, since it is a sub-route of 2472 the route which is reported to be Invalid. 2474 * If the prefix length is different, create a new LocalRoute 2475 with the unreachable address, and its prefix length and 2476 sequence number, and set LocalRoute.State to Invalid. These 2477 Invalid routes are retained to avoid processing stale 2478 messages. 2480 * Update the sequence number on the existing LocalRoute, if the 2481 reported sequence number is determined to be newer using the 2482 comparison method described in Section 4.4. 2484 3. If there are previously Active LocalRoutes that MUST be reported, 2485 regenerate the RERR as detailed in Section 7.4.3. 2487 7.4.3. RERR Regeneration 2489 The Route Error message SHOULD NOT be regenerated if 2490 CONTROL_TRAFFIC_LIMIT has been reached. 2492 The procedure for RERR regeneration is as follows: 2494 1. If PktSource was included in the received RERR, and PktSource is 2495 not a Router Client, copy it into the regenerated RERR 2497 2. For each LocalRoute that needs to be reported as identified in 2498 Section 7.4.1: 2500 * Insert LocalRoute.Address into the AddressList. 2502 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2503 and not equal to the address length. 2505 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2507 * Insert LocalRoute.MetricType into MetricTypeList. 2509 The AODVv2 message is used to create a corresponding [RFC5444] 2510 message (see Section 8). If the RERR contains PktSource, the 2511 regenerated RERR SHOULD be sent unicast to the next hop on the 2512 LocalRoute to PktSource. It MUST be sent over the same interface on 2513 which the undeliverable IP packet was received. If there is no route 2514 to PktSource, or PktSource is a Router Client, it SHOULD be multicast 2515 to LL-MANET-Routers. If the RERR is sent in response to a broken 2516 link, the RERR is, by default, multicast to LL-MANET-Routers. 2518 8. RFC 5444 Representation 2520 AODVv2 specifies that all control messages between routers MUST use 2521 the Generalized Mobile Ad Hoc Network Packet/Message Format 2522 [RFC5444], and therefore AODVv2's route messages comprise data which 2523 is mapped to message elements in [RFC5444]. 2525 [RFC5444] provides a multiplexed transport for multiple protocols. 2526 An [RFC5444] implementation MAY choose to optimize the content of 2527 certain elements during message creation to reduce control message 2528 overhead. 2530 A brief summary of the [RFC5444] format: 2532 1. A packet contains zero or more messages 2534 2. A message contains a Message Header, one Message TLV Block, zero 2535 or more Address Blocks, and one Address Block TLV Block per 2536 Address Block 2538 3. The Message TLV Block contains zero or more Message TLVs 2540 4. An Address Block TLV Block includes zero or more Address Block 2541 TLVs 2543 5. Each TLV value in an Address Block TLV Block can be associated 2544 with all of the addresses, or with a contiguous set of addresses, 2545 or with a single address in the Address Block 2547 AODVv2 does not require access to the [RFC5444] packet header. 2549 In the message header, AODVv2 uses , and 2550 . The field indicates the length 2551 of any addresses in the message, using := (address 2552 length in octets - 1), i.e. 3 for IPv4 and 15 for IPv6. 2554 The addresses in an Address Block MAY appear in any order, and values 2555 in a TLV in the Address Block TLV Block must be associated with the 2556 correct address in the Address Block by the [RFC5444] implementation. 2557 To indicate which value is associated with each address, the AODVv2 2558 message representation uses lists where the order of the addresses in 2559 the AODVv2 AddressList matches the order of values in other data 2560 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2561 [RFC5444] maps this information to Address Block TLVs associated with 2562 the relevant addresses in the Address Block. 2564 Each address included in the Address Block is identified as 2565 OrigPrefix, TargPrefix, PktSource, SeqNoRtr, or Unreachable Address 2566 by including an ADDRESS_TYPE TLV in the Address Block TLV Block. 2568 The following sections show how AODVv2 data is represented in 2569 [RFC5444] messages. In Section 13.3, AODVv2 defines several new 2570 TLVs. 2572 Where the extension type of a TLV is set to zero, this is the default 2573 [RFC5444] value and the extension type will not be included in the 2574 message. 2576 8.1. Route Request Message Representation 2578 8.1.1. Message Header 2580 +---------------+-----------------+---------------------------------+ 2581 | Data | Header Field | Value | 2582 +---------------+-----------------+---------------------------------+ 2583 | None | | RREQ | 2584 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2585 | | | of hops traversed so far by the | 2586 | | | message. | 2587 +---------------+-----------------+---------------------------------+ 2589 8.1.2. Message TLV Block 2591 AODVv2 does not define any Message TLVs for an RREQ message. 2593 8.1.3. Address Block 2595 An RREQ contains OrigPrefix and TargPrefix, and each of these 2596 addresses has an associated prefix length. If the prefix length has 2597 not been included in the AODVv2 message, it is equal to the address 2598 length in bits. 2600 +---------------------------+------------------------------+ 2601 | Data | Address Block | 2602 +---------------------------+------------------------------+ 2603 | OrigPrefix/OrigPrefixLen |
+ | 2604 | TargPrefix/TargPrefixLen |
+ | 2605 | SeqNoRtr/PrefixLen |
+ | 2606 +---------------------------+------------------------------+ 2608 8.1.4. Address Block TLV Block 2610 Address Block TLVs are always associated with one or more addresses 2611 in the Address Block. The following sections show the TLVs that 2612 apply to each address. 2614 8.1.4.1. Address Block TLVs for OrigPrefix 2616 +-------------+--------------+------------+-------------------------+ 2617 | Data | TLV Type | Extension | Value | 2618 | | | Type | | 2619 +-------------+--------------+------------+-------------------------+ 2620 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2621 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2622 | | | | RREQ_Gen, the router | 2623 | | | | which initiated route | 2624 | | | | discovery. | 2625 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2626 | /MetricType | | | route to OrigPrefix, | 2627 | | | | using MetricType. | 2628 +-------------+--------------+------------+-------------------------+ 2630 8.1.4.2. Address Block TLVs for TargPrefix 2632 +------------+--------------+-------------+-------------------------+ 2633 | Data | TLV Type | Extension | Value | 2634 | | | Type | | 2635 +------------+--------------+-------------+-------------------------+ 2636 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2637 | TargSeqNum | SEQ_NUM | 0 | The last known | 2638 | | | | TargSeqNum for | 2639 | | | | TargPrefix. | 2640 +------------+--------------+-------------+-------------------------+ 2642 8.2. Route Reply Message Representation 2644 8.2.1. Message Header 2646 +---------------+-----------------+---------------------------------+ 2647 | Data | Header Field | Value | 2648 +---------------+-----------------+---------------------------------+ 2649 | None | | RREP | 2650 | msg_hop_limit | | MAX_HOPCOUNT - msg_hop_limit | 2651 | | | from the corresponding RREQ, | 2652 | | | reduced by number of hops | 2653 | | | traversed so far by the | 2654 | | | message. | 2655 +---------------+-----------------+---------------------------------+ 2657 8.2.2. Message TLV Block 2659 AODVv2 does not define any Message TLVs for an RREP message. 2661 8.2.3. Address Block 2663 An RREP contains OrigPrefix and TargPrefix, and each of these 2664 addresses has an associated prefix length. If the prefix length has 2665 not been included in the AODVv2 message, it is equal to the address 2666 length in bits. 2668 +---------------------------+------------------------------+ 2669 | Data | Address Block | 2670 +---------------------------+------------------------------+ 2671 | OrigPrefix/OrigPrefixLen |
+ | 2672 | TargPrefix/TargPrefixLen |
+ | 2673 | SeqNoRtr/PrefixLen |
+ | 2674 +---------------------------+------------------------------+ 2676 8.2.4. Address Block TLV Block 2678 Address Block TLVs are always associated with one or more addresses 2679 in the Address Block. The following sections show the TLVs that 2680 apply to each address. 2682 8.2.4.1. Address Block TLVs for OrigPrefix 2684 +-------+---------------+-----------------+-------------+ 2685 | Data | TLV Type | Extension Type | Value | 2686 +-------+---------------+-----------------+-------------+ 2687 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2688 +-------+---------------+-----------------+-------------+ 2690 8.2.4.2. Address Block TLVs for TargPrefix 2692 +--------------+--------------+------------+------------------------+ 2693 | Data | TLV Type | Extension | Value | 2694 | | | Type | | 2695 +--------------+--------------+------------+------------------------+ 2696 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2697 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2698 | | | | RREP_Gen, the router | 2699 | | | | which created the | 2700 | | | | RREP. | 2701 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2702 | /MetricType | | | route to TargPrefix, | 2703 | | | | using MetricType. | 2704 +--------------+--------------+------------+------------------------+ 2706 8.3. Route Reply Acknowledgement Message Representation 2708 8.3.1. Message Header 2710 +-------+---------------+-----------+ 2711 | Data | Header Field | Value | 2712 +-------+---------------+-----------+ 2713 | None | | RREP_Ack | 2714 +-------+---------------+-----------+ 2716 8.3.2. Message TLV Block 2718 AODVv2 defines an AckReq Message TLV, included when an 2719 acknowledgement of this message is required, in order to monitor 2720 adjacency, as described in Section 6.2. 2722 +---------+-----------+-----------------+--------+ 2723 | Data | TLV Type | Extension Type | Value | 2724 +---------+-----------+-----------------+--------+ 2725 | AckReq | ACK_REQ | 0 | None | 2726 +---------+-----------+-----------------+--------+ 2728 8.3.3. Address Block 2730 AODVv2 does not define an Address Block for an RREP_Ack message. 2732 8.3.4. Address Block TLV Block 2734 AODVv2 does not define any Address Block TLVs for an RREP_Ack 2735 message. 2737 8.4. Route Error Message Representation 2739 Route Error Messages MAY be split into multiple [RFC5444] messages 2740 when the desired contents would exceed the MTU. However, all of the 2741 resulting messages MUST have the same message header as described 2742 below. If PktSource is included in the AODVv2 message, it MUST be 2743 included in all of the resulting [RFC5444] messages. 2745 8.4.1. Message Header 2747 +-------+---------------+--------+ 2748 | Data | Header Field | Value | 2749 +-------+---------------+--------+ 2750 | None | | RERR | 2751 +-------+---------------+--------+ 2753 8.4.2. Message TLV Block 2755 AODVv2 does not define any Message TLVs for an RERR message. 2757 8.4.3. Address Block 2759 The Address Block in an RERR MAY contain PktSource, the source 2760 address of the IP packet triggering RERR generation, as detailed in 2761 Section 7.4. The prefix length associated with PktSource is equal to 2762 the address length in bits. 2764 Address Block always contains one address per route that is no longer 2765 valid, and each address has an associated prefix length. If a prefix 2766 length has not been included for this address, it is equal to the 2767 address length in bits. 2769 +------------------------------+------------------------------------+ 2770 | Data | Address Block | 2771 +------------------------------+------------------------------------+ 2772 | PktSource |
+ for | 2773 | | PktSource | 2774 | AddressList/PrefixLengthList |
+ for | 2775 | | each unreachable address in | 2776 | | AddressList | 2777 +------------------------------+------------------------------------+ 2779 8.4.4. Address Block TLV Block 2781 Address Block TLVs are always associated with one or more addresses 2782 in the Address Block. The following sections show the TLVs that 2783 apply to each type of address in the RERR. 2785 8.4.4.1. Address Block TLVs for PktSource 2787 +------------+---------------+-----------------+------------+ 2788 | Data | TLV Type | Extension Type | Value | 2789 +------------+---------------+-----------------+------------+ 2790 | PktSource | ADDRESS_TYPE | 0 | PKTSOURCE | 2791 +------------+---------------+-----------------+------------+ 2793 8.4.4.2. Address Block TLVs for Unreachable Addresses 2794 +----------------+--------------+------------+----------------------+ 2795 | Data | TLV Type | Extension | Value | 2796 | | | Type | | 2797 +----------------+--------------+------------+----------------------+ 2798 | None | ADDRESS_TYPE | 0 | UNREACHABLE | 2799 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2800 | | | | associated with | 2801 | | | | invalid route to the | 2802 | | | | unreachable address. | 2803 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2804 | | | | set to MetricType of | 2805 | | | | the route to the | 2806 | | | | unreachable address. | 2807 +----------------+--------------+------------+----------------------+ 2809 9. Simple External Network Attachment 2811 Figure 5 shows a stub (i.e., non-transit) network of AODVv2 routers 2812 which is attached to an external network (i.e., a network not using 2813 AODVv2) via a single External Network Access Router (ENAR). 2815 As in any externally-attached network, AODVv2 routers and Router 2816 Clients that wish to be reachable from the external network MUST have 2817 IP addresses within the ENAR's routable and topologically correct 2818 prefix (e.g., 191.0.2.0/24 in Figure 5). This AODVv2 network and 2819 networks attached to routers within it will be advertised to the 2820 external network using other routing protocols or procedures which 2821 are out of scope for this specification. 2823 /-------------------------\ 2824 / +----------------+ \ 2825 / | AODVv2 Router | \ 2826 | | 191.0.2.2/32 | | 2827 | +----------------+ | Routable 2828 | +-----+--------+ Prefix 2829 | | ENAR | /191.0.2.0/24 2830 | | AODVv2 Router| / 2831 | | 191.0.2.1 |/ /---------------\ 2832 | | serving net +------+ External \ 2833 | | 191.0.2.0/24 | \ Network / 2834 | +-----+--------+ \---------------/ 2835 | +----------------+ | 2836 | | AODVv2 Router | | 2837 | | 191.0.2.3/32 | | 2838 \ +----------------+ / 2839 \ / 2840 \-------------------------/ 2842 Figure 5: Simple External Network Attachment Example 2844 When an AODVv2 router within the AODVv2 MANET wants to discover a 2845 route toward an address on the external network, it uses the normal 2846 AODVv2 route discovery for that IP Destination Address. 2848 The ENAR MUST respond to RREQ on behalf of all external network 2849 destinations, that is, destinations which are not on the configured 2850 191.0.2.0 /24 network. The ENAR MUST NOT respond with a TargPrefix 2851 and TargPrefixLen which includes any of the networks configured as 2852 part of the AODVv2 network. Sending a Route Request for a gateway is 2853 not currently supported. 2855 If more than one gateway is configured to serve the same external 2856 network, each such gateway MUST configure that external network as a 2857 Router Client with its IP address as the value of SeqNoRtr for the 2858 RouterClient. AODVv2 messages SHOULD NOT be transmitted to routers 2859 in the External Network. 2861 RREQs for addresses inside the AODVv2 network, e.g. destinations on 2862 the configured 191.0.2.0/24 network, are handled using the standard 2863 processes described in Section 7. Note that AODVv2 does not 2864 currently support route discovery for prefixes that do not equal 2865 address length, but RREPs do advertise the prefix on which TargAddr 2866 resides. 2868 When an IP packet from an address on the external network destined 2869 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2870 not have a route toward that destination in its Routing Information 2871 Base, it will perform normal AODVv2 route discovery for that 2872 destination. 2874 Configuring the ENAR as a default router is outside the scope of this 2875 specification. 2877 10. Precursor Lists 2879 This section specifies an interoperable, optional enhancement to 2880 AODVv2 enabling more economical Route Error notifications. 2882 There can be several sources of traffic for a certain destination. 2883 Each source of traffic and each upstream router between the 2884 forwarding AODVv2 router and the traffic source is known as a 2885 "precursor" for the destination. For each destination, an AODVv2 2886 router MAY choose to keep track of precursors that have provided 2887 traffic for that destination. Route Error messages about that 2888 destination can then be sent unicast to these precursors instead of 2889 multicast to all AODVv2 routers. 2891 Since an RERR will be regenerated if it comes from a next hop on a 2892 valid LocalRoute, the RERR SHOULD ideally be sent backwards along the 2893 route that the source of the traffic uses, to ensure it is 2894 regenerated at each hop and reaches the traffic source. If the 2895 reverse path is unknown, the RERR SHOULD be sent toward the source 2896 along any available route. Therefore, the options for saving 2897 precursor information are as follows: 2899 o Save the next hop on an existing route to the IP packet's source 2900 address as the precursor. In this case, it is not guaranteed that 2901 an RERR that is sent will follow the reverse of the source's 2902 route. In rare situations, this may prevent the route from being 2903 invalidated at the source of the data traffic. 2905 o Save the IP packet's source address as the precursor. In this 2906 case, the RERR can be sent along any existing route to the source 2907 of the data traffic, and SHOULD include PktSource to ensure that 2908 the route will be invalidated at the source of the traffic, in 2909 case the RERR does not follow the reverse of the source's route. 2911 o By inspecting the MAC address of each forwarded IP packet, 2912 determine which router forwarded the packet, and save the router 2913 address as a precursor. This ensures that when an RERR is sent to 2914 the precursor router, the route will be invalidated at that 2915 router, and the RERR will be regenerated toward the source of the 2916 IP packet. 2918 During normal operation, each AODVv2 router maintaining precursor 2919 lists for a LocalRoute must update the precursor list whenever it 2920 uses this route to forward traffic to the destination. Precursors 2921 are classified as Active if traffic has recently been forwarded by 2922 the precursor. The precursor is marked with a timestamp to indicate 2923 the time it last forwarded traffic on this route. 2925 When an AODVv2 router detects that one or more LocalRoutes are 2926 broken, it MAY notify each Active precursor using a unicast Route 2927 Error message instead of creating multicast traffic. Unicast is 2928 applicable when there are few Active precursors compared to the 2929 number of neighboring AODVv2 routers. However, the default multicast 2930 behavior is still preferable when there are many precursors, since 2931 fewer message transmissions are required. 2933 When an AODVv2 router supporting precursor lists receives an RERR 2934 message, it SHOULD identify the list of its own affected Active 2935 precursors for the routes in the RERR, and choose to send a unicast 2936 RERR to those, rather than send a multicast RERR. 2938 When a LocalRoute is expunged, any precursor list associated with it 2939 MUST also be expunged. 2941 11. Application of RFC 7182 to AODVv2 2943 Implementations of AODVv2 MUST support ICV TLVs using type-extensions 2944 1 and 2, hash-function HASH_FUNCTION, and cryptographic function 2945 CRYPTOGRAPHIC_FUNCTION. An ICV MUST be included with every message. 2946 The ICV value MAY be truncated as specified in [RFC7182]. 2948 Since the msg-hop-limit and PATH_METRIC values are mutable when 2949 included in AODVv2 messages, these values are set to zero before 2950 calculating an ICV. This means that these values are not protected 2951 end-to-end and are therefore susceptible to manipulation. This form 2952 of attack is described in Section 14.3.2. 2954 Implementations of AODVv2 MUST support a TIMESTAMP TLV using type- 2955 extension 0. The timestamp used is a sequence number, and therefore 2956 the length of the field matches the AODVv2 sequence 2957 number defined in Section 4.4. The TIMESTAMP TLV MUST be included in 2958 RREP_Ack and RERR messages. 2960 When more than one message is included in an RFC5444 packet, using a 2961 single ICV Packet TLV or single TIMESTAMP Packet TLV is more 2962 efficient than including ICV and TIMESTAMP Message TLVs in each 2963 message created. If the RFC5444 multiplexer is capable of adding the 2964 Packet TLVs, it SHOULD be instructed to include the Packet TLVs in 2965 packets containing AODVv2 messages. However, if the multiplexer is 2966 not capable of adding the Packet TLVs, the TLVs MUST be included as 2967 Message TLVs in each AODVv2 message in the packet. 2969 After message generation, but before transmission, the ICV and 2970 TIMESTAMP TLVs MUST be added according to each message type as 2971 detailed in the following sections. The following steps list the 2972 procedure to be performed: 2974 1. If the TIMESTAMP is to be included, depending on AODVv2 message 2975 type as specified below, add the TIMESTAMP TLV. 2977 * When a TIMESTAMP Packet TLV is being added, the Packet TLV 2978 Block size field MUST be updated. 2980 * When a TIMESTAMP Message TLV is being added, the Message TLV 2981 Block size field MUST be updated. 2983 2. The considerations in Section 8 and section 9 of [RFC7182] are 2984 followed, removing existing ICV TLVs and adjusting the size and 2985 flags fields as appropriate: 2987 * When an ICV Packet TLV is being added, existing ICV Packet 2988 TLVs MUST be removed and the Packet TLV Block size MUST be 2989 updated. If the Packet TLV Block now contains no TLVs, the 2990 phastlv bit in the field in the Packet Header MUST 2991 be cleared. 2993 * When an ICV Message TLV is being added, existing ICV Message 2994 TLVs are removed and the Message TLV Block Size MUST be 2995 updated. 2997 3. Mutable fields in the message must have their mutable values set 2998 to zero before calculating the ICV. 3000 * If the msg-hop-limit field is included in the [RFC5444] 3001 message header, msg-hop-limit MUST be set to zero before 3002 calculating the ICV. 3004 * If a PATH_METRIC TLV is included, any values present in the 3005 TLV MUST be set to zero before calculating the ICV value. 3007 4. Depending on the message type, the ICV is calculated over the 3008 appropriate fields (as specified in sections Section 11.1, 3009 Section 11.2, Section 11.3 and Section 11.4) to include the 3010 fields , , , and, if present, (in that order), followed by 3012 the entire packet or message. This value MAY be truncated (as 3013 specified in [RFC7182]). 3015 5. Add the ICV TLV, updating size fields as necessary. 3017 6. The changes made in Step 2 and Step 3 are reversed to re-add any 3018 existing ICV TLVs, re-adjust the relevant size and flags fields, 3019 and set the msg-hop-limit and PATH_METRIC TLV values. 3021 On message reception, and before message processing, verification of 3022 the received message MUST take place: 3024 1. The considerations in Section 8 and Section 9 of [RFC7182] are 3025 followed, removing existing ICV TLVs and adjusting the size and 3026 flags fields as appropriate. 3028 * When verifying the ICV value in an ICV Packet TLV, all ICV 3029 Packet TLVs present in the Packet TLV Block MUST be removed 3030 before calculating the ICV, and the Packet TLV Block size MUST 3031 be updated. If there are no remaining Packet TLVs, the Packet 3032 TLV Block MUST be removed and the phastlv bit in the field MUST be cleared. 3035 * When verifying the ICV value in an ICV Message TLV, all ICV 3036 Message TLVs present in the Message TLV Block MUST be removed 3037 before calculating the ICV, and the Message TLV Block size 3038 MUST be updated. 3040 2. Mutable fields in the message MUST have their mutable values set 3041 to zero before calculating the ICV. 3043 * If the msg-hop-limit field is included in the [RFC5444] 3044 message header, msg-hop-limit MUST be set to zero before 3045 calculating the ICV. 3047 * If a PATH_METRIC TLV is included, any values present in the 3048 TLV MUST be set to zero before calculating the ICV value. 3050 3. The ICV is calculated following the considerations in 3051 Section 12.2 of [RFC7182], to include the fields , 3052 , , and, if present, (in that order), followed by the entire packet or message. 3055 * If the received ICV value is truncated, the calculated ICV 3056 value MUST also be truncated (as specified in [RFC7182]), 3057 before comparing. 3059 * If the ICV value calculated from the received message or 3060 packet does not match the value of in the received 3061 message or packet, the validation fails and the AODVv2 message 3062 MUST be discarded and NOT processed or forwarded. 3064 * If the ICV values do match, the values set to zero before 3065 calculating the ICV are reset to the received values, and 3066 processing continues to Step 4. 3068 4. Verification of a received TIMESTAMP value MUST be performed. 3069 The procedure depends on message type as specified in the 3070 following sub sections. 3072 * If the TIMESTAMP value in the received message is not valid, 3073 the AODVv2 message MUST be discarded and NOT processed or 3074 forwarded. 3076 * If the TIMESTAMP value is valid, processing continues as 3077 defined in Section 7. 3079 11.1. RREQ Generation and Reception 3081 Since OrigPrefix is included in the RREQ, the ICV can be calculated 3082 and verified using the [RFC5444] contents.The ICV TLV has type 3083 extension := 1. Inclusion of an ICV TLV message integrity and 3084 endpoint authentication, because trusted routers MUST hold the shared 3085 key in order to calculate the ICV value, both to include when 3086 creating a message, and to validate the message by checking that the 3087 ICV is correct. 3089 Since RREQ_Gen's sequence number is incremented for each new RREQ, 3090 replay protection is already afforded and no extra TIMESTAMP TLV is 3091 required. 3093 After message generation and before message transmission: 3095 1. Add the ICV TLV as described above. 3097 On message reception and before message processing: 3099 1. Verify the received ICV value as described above. 3101 2. Verification of the sequence number is handled according to 3102 Section 7. 3104 11.2. RREP Generation and Reception 3106 Since TargPrefix is included in the RREP, the ICV can be calculated 3107 and verified using the [RFC5444] contents. The ICV TLV has type 3108 extension 1. Inclusion of an ICV provides message integrity and 3109 endpoint authentication, because trusted routers MUST hold a valid 3110 key in order to calculate the ICV value, both to include when 3111 creating a message, and to validate the message by checking that the 3112 ICV is correct. 3114 Since RREP_Gen's sequence number is incremented for each new RREP, 3115 replay protection is already afforded and no extra TIMESTAMP TLV is 3116 required. 3118 After message generation and before message transmission: 3120 1. Add the ICV TLV as described above. 3122 On message reception and before message processing: 3124 1. Verify the received ICV value as described above. 3126 2. Verification of the sequence number is handled according to 3127 Section 7. 3129 11.3. RREP_Ack Generation and Reception 3131 Since no sequence number is included in the RREP_Ack, a TIMESTAMP TLV 3132 MUST be included to protect against replay attacks. The value in the 3133 TIMESTAMP TLV is set as follows: 3135 o For RREP_Ack request, use Neighbor.AckSeqNum. 3137 o For RREP_Ack response, use the sequence number from the TIMESTAMP 3138 TLV in the received RREP_Ack request. 3140 Since no addresses are included in the RREP_Ack, and the receiver of 3141 the RREP_Ack uses the source IP address of a received RREP_Ack to 3142 identify the sender, the ICV MUST be calculated using the message 3143 contents and the IP source address. The ICV TLV has type extension 3144 := 2 in order to accomplish this. This provides message integrity 3145 and endpoint authentication, because trusted routers MUST hold the 3146 correct key in order to calculate the ICV value. 3148 After message generation and before message transmission: 3150 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3152 On message reception and before message processing: 3154 1. Verify the received ICV value as described above. 3156 2. Verify the received TIMESTAMP value by comparing the sequence 3157 number in the value field of the TIMESTAMP TLV as follows: 3159 * For a received RREP_Ack request, there is no need to verify 3160 the timestamp value. Proceed to message processing as defined 3161 in Section 7. 3163 * For a received RREP_Ack response, compare with the 3164 Neighbor.AckSeqNum of the Neighbor Set entry for sender of the 3165 RREP_Ack request. 3167 * If the sequence number does not match, the AODVv2 message MUST 3168 be discarded. Otherwise, Neighbor.AckSeqNum is incremented by 3169 1 and processing continues according to Section 7. 3171 11.4. RERR Generation and Reception 3173 Since the sender's sequence number is not contained in the RERR, a 3174 TIMESTAMP TLV MUST be included to protect against replay attacks. 3175 The value in the TIMESTAMP TLV is set by incrementing and using 3176 RERR_Gen's sequence number. 3178 Since the receiver of the RERR MUST use the source IP address of the 3179 RERR to identify the sender, the ICV MUST be calculated using the 3180 message contents and the IP source address. The ICV TLV has type 3181 extension := 2 in order to accomplish this. This provides message 3182 integrity and endpoint authentication, because trusted routers MUST 3183 hold the shared key in order to calculate the ICV value. 3185 After message generation and before message transmission: 3187 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3189 On message reception and before message processing: 3191 1. Verify the received ICV value as described above. 3193 2. Verify the received TIMESTAMP value by comparing the sequence 3194 number in the value field of the TIMESTAMP TLV with the 3195 Neighbor.HeardRERRSeqNum. If the sequence number in the message 3196 is lower than the stored value, the AODVv2 message MUST be 3197 discarded. Otherwise, the Neighbor.HeardRERRSeqNum MUST be set 3198 to the received value and processing continues according to 3199 Section 7. 3201 12. Configuration 3203 AODVv2 uses various parameters which can be grouped into the 3204 following categories: 3206 o Timers 3207 o Protocol constants 3209 o Administrative parameters and controls 3211 This section show the parameters along with their definitions and 3212 default values (if any). 3214 Note that several fields have limited size (bits or bytes). These 3215 sizes and their encoding may place specific limitations on the values 3216 that can be set. 3218 12.1. Timers 3220 AODVv2 requires certain timing information to be associated with 3221 Local Route Set entries and message replies. The default values are 3222 as follows: 3224 +------------------------+----------------+ 3225 | Name | Default Value | 3226 +------------------------+----------------+ 3227 | ACTIVE_INTERVAL | 5 second | 3228 | MAX_IDLETIME | 200 seconds | 3229 | MAX_BLACKLIST_TIME | 200 seconds | 3230 | MAX_SEQNUM_LIFETIME | 300 seconds | 3231 | RERR_TIMEOUT | 3 seconds | 3232 | RteMsg_ENTRY_TIME | 12 seconds | 3233 | RREQ_WAIT_TIME | 2 seconds | 3234 | RREP_Ack_SENT_TIMEOUT | 1 second | 3235 | RREQ_HOLDDOWN_TIME | 10 seconds | 3236 +------------------------+----------------+ 3238 Table 2: Timing Parameter Values 3240 The above timing parameter values have worked well for small and 3241 medium well-connected networks with moderate topology changes. The 3242 timing parameters SHOULD be administratively configurable. Ideally, 3243 for networks with frequent topology changes the AODVv2 parameters 3244 SHOULD be adjusted using experimentally determined values or dynamic 3245 adaptation. For example, in networks with infrequent topology 3246 changes MAX_IDLETIME MAY be set to a much larger value. If the 3247 values were configured differently, the following consequences may be 3248 observed: 3250 o If MAX_SEQNUM_LIFETIME was configured differently across the 3251 network, and any of the routers lost their sequence number or 3252 rebooted, this could result in their next route messages being 3253 classified as stale at any AODVv2 router using a greater value for 3254 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to 3255 the re-initializing router. 3257 o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will 3258 invalidate routes more quickly and free resources used to maintain 3259 them. This can affect bursty traffic flows which have quiet 3260 periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which 3261 has timed out due to perceived inactivity is not reported. When 3262 the bursty traffic resumes, it would cause a RERR to be generated, 3263 and the traffic itself would be dropped. This route would be 3264 removed from all upstream routers, even if those upstream routers 3265 had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route 3266 discovery would be required to re-establish the route, causing 3267 extra routing protocol traffic and disturbance to the bursty 3268 traffic. 3270 o Routers with lower values for MAX_BLACKLIST_TIME would allow 3271 neighboring routers to participate in route discovery sooner than 3272 routers with higher values. This could result in failed route 3273 discoveries if un-blacklisted links are still uni-directional. 3274 Since RREQs are retried, this would not affect success of route 3275 discovery unless this value was so small as to un-blacklist the 3276 router before the RREQ is retried. This value need not be 3277 consistent across the network since it is used for maintaining a 3278 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME; 3279 the default value is much larger. 3281 o Routers with lower values for RERR_TIMEOUT may create more RERR 3282 messages than routers with higher values. This value should be 3283 large enough that a RERR will reach all routers using the route 3284 reported within it before the timer expires, so that no further 3285 data traffic will arrive, and no duplicated RERR messages will be 3286 generated. 3288 o Routers with lower values for RteMsg_ENTRY_TIME may not consider 3289 received redundant multicast route messages as redundant, and may 3290 forward these messages unnecessarily. 3292 o Routers with lower values for RREQ_WAIT_TIME may send more 3293 frequent RREQ messages and wrongly determine that a route does not 3294 exist, if the delay in receiving an RREP is greater than this 3295 interval. 3297 o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly 3298 determine links to neighbors to be unidirectional if an RREP_Ack 3299 is delayed longer than this timeout. 3301 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed 3302 route discoveries sooner than routers with higher values. This 3303 may be an advantage if the network topology is frequently 3304 changing, or may unnecessarily cause more routing protocol 3305 traffic. 3307 MAX_SEQNUM_LIFETIME MUST be configured to have the same values for 3308 all AODVv2 routers in the network. 3310 12.2. Protocol Constants 3312 AODVv2 protocol constants typically do not require changes. The 3313 following table lists these constants, along with their values and a 3314 reference to the section describing their use. 3316 +------------------------+-------------+----------------------------+ 3317 | Name | Default | Description | 3318 +------------------------+-------------+----------------------------+ 3319 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 3320 | RREP_RETRIES | 2 | Section 7.2.1 | 3321 | MAX_METRIC[MetricType] | [see below] | Section 5 | 3322 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 3323 | MAX_HOPCOUNT | 20 | Limit to number of hops an | 3324 | | | RREQ or RREP message can | 3325 | | | traverse | 3326 | INFINITY_TIME | [see below] | Maximum expressible clock | 3327 | | | time (Section 6.7.2) | 3328 +------------------------+-------------+----------------------------+ 3330 Table 3: AODVv2 Constants 3332 MAX_HOPCOUNT cannot be larger than 255. 3334 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 3335 value of type MetricType. Field lengths associated with metric 3336 values are found in Section 13.4. 3338 These protocol constants MUST have the same values for all AODVv2 3339 routers in the ad hoc network. If the values were configured 3340 differently, the following consequences may be observed: 3342 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 3343 be more successful at finding routes, at the cost of additional 3344 control traffic. 3346 o RREP_RETRIES: Routers with lower values are more likely to 3347 blacklist neighbors when there is a temporary fluctuation in link 3348 quality. 3350 o MAX_METRIC[MetricType]: No interoperability problems due to 3351 variations on different routers, but routers with lower values may 3352 exhibit overly restrictive behavior during route comparisons. 3354 o MAX_HOPCOUNT: Routers with a value too small would not be able to 3355 discover routes to distant addresses. 3357 o INFINITY_TIME: No interoperability problems due to variations on 3358 different routers, but if a lower value is used, route state 3359 management may exhibit overly restrictive behavior. 3361 12.3. Local Settings 3363 The following table lists AODVv2 parameters which SHOULD be 3364 administratively configured for each router: 3366 +------------------------+---------------------------+--------------+ 3367 | Name | Default Value | Description | 3368 +------------------------+---------------------------+--------------+ 3369 | Interface Set | | Section 4.1 | 3370 | Router Client Set | | Section 4.2 | 3371 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 3372 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 3373 | CONTROL_TRAFFIC_LIMIT | [Adjust for 10% capacity] | Section 7 | 3374 +------------------------+---------------------------+--------------+ 3376 Table 4: Configuration for Local Settings 3378 12.4. Network-Wide Settings 3380 The following administrative controls MAY be used to change the 3381 operation of the network. The same settings SHOULD be used across 3382 the network. Inconsistent settings at different routers in the 3383 network will not result in protocol errors. 3385 +----------------------+-----------+----------------+ 3386 | Name | Default | Description | 3387 +----------------------+-----------+----------------+ 3388 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 3389 +----------------------+-----------+----------------+ 3391 Table 5: Configuration for Network-Wide Settings 3393 13. IANA Considerations 3395 This section specifies several [RFC5444] message types and address 3396 tlv-types required for AODVv2. 3398 13.1. RFC 5444 Message Type Allocation 3400 This specification defines four Message Types, to be allocated from 3401 the 0-223 range of the "Message Types" namespace defined in 3402 [RFC5444]. 3404 +-----------------------------------------+-----------+ 3405 | Name of Message | Type | 3406 +-----------------------------------------+-----------+ 3407 | Route Request (RREQ) | 10 (TBD) | 3408 | Route Reply (RREP) | 11 (TBD) | 3409 | Route Error (RERR) | 12 (TBD) | 3410 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 3411 +-----------------------------------------+-----------+ 3413 13.2. RFC 5444 Message TLV Types 3415 This specification defines one Message TLV Type, to be allocated from 3416 the Message-Type-specific "Message TLV Types" namespace defined in 3417 [RFC5444], as specified in Table 6. 3419 +------------------------+----------+---------------+---------------+ 3420 | Name of TLV | Type | Length | Reference | 3421 | | | (octets) | | 3422 +------------------------+----------+---------------+---------------+ 3423 | ACK_REQ | 128 | 0 | Section 6.2 | 3424 | | (TBD) | | | 3425 +------------------------+----------+---------------+---------------+ 3427 Table 6: AODVv2 Message TLV Types 3429 13.3. RFC 5444 Address Block TLV Type Allocation 3431 This specification defines three Address Block TLV Types, to be 3432 allocated from the Message-Type-specific "Address Block TLV Types" 3433 namespace defined in [RFC5444], as specified in Table 7. 3435 +------------------------+----------+---------------+---------------+ 3436 | Name of TLV | Type | Length | Reference | 3437 | | | (octets) | | 3438 +------------------------+----------+---------------+---------------+ 3439 | PATH_METRIC | 129 | depends on | Section 7 | 3440 | | (TBD) | MetricType | | 3441 | SEQ_NUM | 130 | 2 | Section 7 | 3442 | | (TBD) | | | 3443 | ADDRESS_TYPE | 131 | 1 | Section 8 | 3444 | | (TBD) | | | 3445 +------------------------+----------+---------------+---------------+ 3447 Table 7: AODVv2 Address Block TLV Types 3449 13.4. MetricType Allocation 3451 The metric types used by AODVv2 are identified according to Table 8. 3452 All implementations MUST use these values. 3454 +---------------------+----------+--------------------+ 3455 | Name of MetricType | Type | Metric Value Size | 3456 +---------------------+----------+--------------------+ 3457 | Unassigned | 0 | Undefined | 3458 | Hop Count | 1 | 1 octet | 3459 | Unallocated | 2 - 254 | TBD | 3460 | Reserved | 255 | Undefined | 3461 +---------------------+----------+--------------------+ 3463 Table 8: AODVv2 Metric Types 3465 13.5. ADDRESS_TYPE TLV Values 3467 These values are used in the [RFC5444] Address Type TLV discussed in 3468 Section 8. All implementations MUST use these values. 3470 +---------------+--------+ 3471 | Address Type | Value | 3472 +---------------+--------+ 3473 | ORIGPREFIX | 0 | 3474 | TARGPREFIX | 1 | 3475 | UNREACHABLE | 2 | 3476 | PKTSOURCE | 3 | 3477 | UNSPECIFIED | 255 | 3478 +---------------+--------+ 3480 Table 9: AODVv2 Address Types 3482 14. Security Considerations 3484 This section describes various security considerations and potential 3485 avenues to secure AODVv2 routing. The main objective of the AODVv2 3486 protocol is for each router to communicate reachability information 3487 about addresses for which it is responsible, and for routes it has 3488 discovered from other AODVv2 routers. 3490 Networks using AODVv2 to maintain connectivity and establish routes 3491 on demand may be vulnerable to certain well-known types of threats, 3492 which will be detailed in this section. Some of the threats 3493 described can be mitigated or eliminated. Tools to do so will be 3494 described. 3496 With the exception of metric values, AODVv2 assures the integrity of 3497 all RteMsg data end-to-end though the use of ICVs (see 3498 Section 14.4.2. AODVv2 implementations support ICV and TIMESTAMP 3499 TLVs, unless the implementation is intended for an environment in 3500 which security is unnecessary; otherwise, AODVv2 deployments are 3501 configured to use these TLVs to secure messages. 3503 The on-demand nature of AODVv2 route discovery automatically reduces 3504 the vulnerability to route disruption. Since control traffic for 3505 updating route tables is diminished, there is less opportunity for 3506 attack and failure. 3508 14.1. Availability 3510 Threats to AODVv2 which reduce availability are considered below. 3512 14.1.1. Denial of Service 3514 Flooding attacks using RREQ amount to a (BLIND) denial of service for 3515 route discovery: By issuing RREQ messages for targets that don't 3516 exist, an attacker can flood the network, blocking resources and 3517 drowning out legitimate traffic. By triggering the generation of 3518 CONTROL_TRAFFIC_LIMIT amount of messages (for example by sending 3519 RREQs for many non-existent destinations), an attacker can prevent 3520 legitimate messages from being generated. The effect of this attack 3521 is dampened by the fact that duplicate RREQ messages are dropped 3522 (preventing the network from DDoSing itself). Processing 3523 requirements for AODVv2 messages are typically quite small, however 3524 AODVv2 routers receiving RREQs do allocate resources in the form of 3525 Neighbor Set, Local Route Set and Multicast Route Message Set 3526 entries. The attacker can maximize their impact on set growth by 3527 changing OrigPrefix or OrigPrefixLen for each RREQ. If a specific 3528 node is to be targeted, this attack may be carried out in a 3529 DISTRIBUTED fashion, either by compromising its direct neighbors or 3530 by specifying the target's address with TargPrefix and TargPrefixLen. 3531 Note that it might be more economical for the attacker to simply jam 3532 the medium; an attack which AODVv2 cannot defend itself against. 3534 Mitigation: 3536 o If AODVv2 routers always verify that the sender of the RERR 3537 message is trusted, this threat is reduced. Processing 3538 requirements would typically be dominated by calculations to 3539 verify integrity. This has the effect of reducing (but by no 3540 means eliminating) AODVv2's vulnerability to denial of service 3541 attacks. 3543 o Authentication of senders can prevent unauthenticated routers from 3544 launching a Denial of Service attack on another AODVv2 router. 3545 However, this does not protect the network if an attacker has 3546 access to an already authenticated router. 3548 14.1.2. Malicious RERR messages 3550 RERR messages are designed to cause removal of installed routes. A 3551 malicious node could send an RERR message with false information to 3552 attempt to get other routers to remove a route to one or more 3553 specific destinations, therefore disrupting traffic to the advertised 3554 destinations. 3556 Routes will be deleted if an RERR is received, withdrawing a route 3557 for which the sender is the receiver's next hop, if both of the 3558 following conditions are met: 3560 o the RERR includes the MetricType of the installed route, 3562 o the RERR includes either no sequence number for the route, or 3563 includes a greater sequence number than the sequence number stored 3564 with that route in the receiver's Local Route Set. 3566 Routes will also be deleted if a received RERR contains a PktSource 3567 address corresponding to a Router Client. 3569 The information necessary to construct a malicious RERR could be 3570 discovered by eavesdropping, either by listening to AODVv2 messages 3571 or by watching data packet flows. 3573 When the RERR is multicast, it can be received by many routers in the 3574 ad hoc network, and will be regenerated when processing results in an 3575 active route being removed. This threat could have serious impact on 3576 applications communicating by way of the sender of the RERR message. 3578 o The set of routers which use the malicious router as a next hop 3579 may be targeted with a malicious RERR with no PktSource address 3580 included, if the RERR contains routes for which the malicious 3581 router is a next hop from the receiving router. However, since 3582 the sender of the RERR message is either malicious or broken, it 3583 is better that it is not used as a next hop for these routes 3584 anyway. 3586 o A single router which does not use the malicious router as part of 3587 its route may be targeted with a malicious RERR with a PktSource 3588 address included. 3590 o Replayed RERR messages could be used to disrupt active routes. 3592 Mitigation: 3594 o Protection against eavesdropping of AODVv2 messages would mitigate 3595 this attack to some extent, but eavesdropping of data packets can 3596 also be used to deduce the information about which routes could be 3597 targeted. 3599 o Protection against a malicious router becoming part of a route 3600 will mitigate the attack where a set of routers are targeted. 3601 This will not protect against the attack if a PktSource address is 3602 included. 3604 o By only regenerating RERR messages where active routes are 3605 removed, the spread of the malicious RERR is limited. 3607 o Including sequence numbers in RERR messages offers protection 3608 against attacks using replays of these RERR messages. 3610 o If AODVv2 routers always verify that the sender of the RERR 3611 message is trusted, this threat is reduced. 3613 14.1.3. False Confirmation of Link Bidirectionality 3615 Links could be erroneously treated as bidirectional if malicious 3616 unsolicited or spoofed RREP messages were to be accepted. This would 3617 result in a route being installed which could not in fact be used to 3618 forward data to the destination, and may divert data packets away 3619 from the intended destination. 3621 There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which 3622 any malicious router could send an RREP in response, in order for the 3623 link to the malicious router to be deemed as bidirectional. 3625 Mitigation: 3627 o Ignoring unsolicited RREP and RREP_Ack messages partially 3628 mitigates against this threat. 3630 o If AODVv2 routers always verify that the sender of the RREP 3631 message is trusted, this threat is reduced. 3633 14.1.4. Message Deletion 3635 A malicious router could decide not to forward an RREQ or RREP or 3636 RERR message. Not forwarding a RERR or RREP message would disrupt 3637 route discovery. Not regenerating a RERR message would result in the 3638 source of data packets continuing to maintain and use the route, and 3639 further RERR messages being generated by the sender of the non- 3640 regenerated RERR. A malicious router could intentionally disrupt 3641 traffic flows by not allowing the source of data traffic to re- 3642 discover a new route when one breaks. 3644 Failing to send an RREP_Ack would also disrupt route establishment, 3645 by not allowing the reverse route to be validated. Return traffic 3646 which needs that route will prompt a new route discovery, wasting 3647 resources and incurring a slight delay but not disrupting the ability 3648 for applications to communicate. 3650 Mitigation: 3652 o None. Note that malicious router would have to wait for a route 3653 to break before it could perform this attack. 3655 14.2. Confidentiality 3657 Passive inspection (eavesdropping) of AODVv2 control messages could 3658 enable unauthorized devices to gain information about the network 3659 topology, since exchanging such information is the main purpose of 3660 AODVv2. 3662 Eavesdropping of data traffic could allow a malicious device to 3663 obtain information about how data traffic is being routed. With 3664 knowledge of source and destination addresses, malicious messages 3665 could be constructed to disrupt normal operation. 3667 14.3. Integrity of Routes 3669 Integrity of route information can be compromised in the following 3670 types of attack: 3672 14.3.1. Message Insertion 3674 Valid route set entries can be replaced or modified by maliciously 3675 constructed AODVv2 messages, destroying existing routes and the 3676 network's integrity. Any router may pose as another router by 3677 sending RREQ, RREP, RREP_Ack and RERR messages in its name. 3679 o Sending an RREQ message with false information can disrupt traffic 3680 to OrigPrefix, if the sequence number attached is not stale 3681 compared to any existing information about OrigPrefix. Since RREQ 3682 is multicast and likely to be received by all routers in the ad 3683 hoc network, this threat could have serious impact on applications 3684 communicating with OrigPrefix. 3686 o The actual threat to disrupt routes to OrigPrefix is reduced by 3687 the AODVv2 mechanism of marking RREQ-derived routes as 3688 "Unconfirmed" until the route to OrigAddr can be confirmed. 3690 o Sending an RREP message with false information can disrupt traffic 3691 to TargPrefix. Since RREP is unicast, and ignored if a 3692 corresponding RREQ was not recently sent, this threat is 3693 minimized, and is restricted to receivers along the path from 3694 OrigAddr to TargAddr. 3696 o Sending an RREP_Ack response message with false information can 3697 cause the route to an originator address to be erroneously 3698 accepted even though the route would contain a unidirectional link 3699 and thus not be suitable for most traffic. Since the RREP_Ack 3700 response is unicast, and ignored if an RREP_Ack was not sent 3701 recently to the sender of this RREP_Ack response, this threat is 3702 minimized and is strictly local to the RREP transmitter expecting 3703 the acknowledgement. Unsolicited RREP_Acks are ignored. 3705 o Sending an RERR message with false information is discussed in 3706 Section 14.1.2. 3708 Mitigation: 3710 o If AODVv2 routers always verify that the sender of a message is 3711 trusted, this threat is reduced. 3713 14.3.2. Message Modification - Man in the Middle 3715 Any AODVv2 router can forward messages with modified data. 3717 Mitigation: 3719 o If AODVv2 routers verify the integrity of AODVv2 messages, then 3720 the threat of disruption is minimized. A man in the middle with 3721 no knowledge of the key used to calculate an integrity check value 3722 may modify a message but the message will be rejected when it 3723 fails an integrity check. 3725 14.3.3. Replay Attacks 3727 Replaying of RREQ or RREP messages would be of less use to an 3728 attacker, since they would be dropped immediately due to their stale 3729 sequence number. RERR messages may or may not include sequence 3730 numbers and are therefore susceptible to replay attacks. RREP_Ack 3731 messages do not include sequence numbers and are therefore 3732 susceptible to replay attacks. 3734 Mitigation: 3736 o Use of timestamps or sequence numbers prevents replay attacks. 3738 14.4. Protection Mechanisms 3740 14.4.1. Confidentiality and Authentication 3742 Encryption MAY be used for AODVv2 messages. If the routers share a 3743 packet-level security association, the message data can be encrypted 3744 prior to message transmission. The establishment of such security 3745 associations is outside the scope of this specification. Encryption 3746 will not only protect against unauthorized devices obtaining 3747 information about network topology (eavesdropping) but will ensure 3748 that only trusted routers participate in routing operations. 3750 14.4.2. Message Integrity using ICVs 3752 Cryptographic Integrity Check Values (ICVs) can be used to ensure 3753 integrity of received messages, protecting against man in the middle 3754 attacks. Further, by using ICVs, only those routers with knowledge 3755 of a shared secret key are allowed to participate in routing 3756 information exchanges. [RFC7182] defines ICV TLVs for use with 3757 [RFC5444]. 3759 The data contained in AODVv2 routing protocol messages MUST be 3760 verified using Integrity Check Values, to avoid accepting tampered 3761 messages. 3763 14.4.3. Replay Protection using Timestamps 3765 [RFC7182] defines a TIMESTAMP TLV for use with [RFC5444] which can be 3766 used to prevent replay attacks when sequence numbers are not already 3767 included. 3769 The data contained in AODVv2 routing protocol messages can be 3770 protected with a TIMESTAMP value to ensure the protection against 3771 replaying of the message. Sequence numbers can be used in place of 3772 timestamps, since they are known to be strictly increasing. 3774 14.5. Key Management 3776 The method of distribution of shared secret keys is out of the scope 3777 of this protocol. Key management is not specified for the following 3778 reasons: 3780 Against [RFC4107], an analysis as to whether automated or manual key 3781 management should be used shows a compelling case for automated 3782 management. In particular: 3784 o a potentially large number of routers may have to be managed, 3785 belonging to several organisations, for example in vehicular 3786 applications. 3788 o a stream cipher is likely to be used, such as an AES variant. 3790 o long term session keys might be used by more than two parties, 3791 including multicast operations. AODVv2 makes extensive use of 3792 multicast. 3794 o there may be frequent turnover of devices. 3796 On reviewing the case for manual key management against the same 3797 document, it can be seen that manual management might be advantageous 3798 in environments with limited bandwidth or high round trip times. 3799 AODVv2 lends itself to sparse ad hoc networks where transmission 3800 conditions may indeed be limited, depending on the bearers selected 3801 for use. 3803 However, [RFC4107] assumes that the connectivity between endpoints is 3804 already available. In AODVv2, no route is available to a given 3805 destination until a router client requests that user traffic be 3806 transmitted. It is required to secure the signalling path of the 3807 routing protocol that will establish the path across which key 3808 exchange functions might subsequently be applied, which is clearly 3809 the reverse of the expected functionality. A different strategy is 3810 therefore required. 3812 There are two possible solutions. In each case, it is assumed that a 3813 defence in depth security posture is being adopted by the system 3814 integrator, such that each function in the network as a whole is 3815 appropriately secured or defended as necessary, and that there is not 3816 complete reliance on security mechanisms built in to AODVv2. Such 3817 additional mechanisms could include a suitable wireless device 3818 security technology, so that wireless devices are authenticated and 3819 secured by their peers prior to exchanging user data, which in this 3820 case would include AODVV2 signalling traffic as a payload, and 3821 mechanisms which verify the authenticity and/or integrity of 3822 application-layer user data transported once a route has been 3823 established. 3825 1. In the case that no AODVv2 routers have any detailed prior 3826 knowledge of any other AODVv2 router, but does have knowledge of 3827 the credentials of other organisations in which the router has 3828 been previously configured to trust, it is possible for an AODVv2 3829 router to send an initialisation vector as part of an exchange, 3830 which could be verified against such credentials. Such an 3831 exchange could make use of Identity-Based Signatures 3832 ([I-D.ietf-manet-ibs]), based on Elliptic Curve-Based 3833 Certificateless Signatures for Identity-Based Encryption 3834 [RFC6507], which eliminate the need for a handshake process to 3835 establish trust. 3837 2. If it is impossible to use Identity-Based Signatures, and the 3838 risk to the AODVv2 signalling traffic is considered to be low due 3839 to the use of security countermeasures elsewhere in the system, a 3840 simple pre-placed shared secret could be used between routers, 3841 which is used as-is or is used to generate some ephemeral secret 3842 based on another known variable, such as time of day if that is 3843 universally available at a level of accuracy sufficient to make 3844 such a system viable. 3846 15. Acknowledgments 3848 AODVv2 is a descendant of the design of previous MANET on-demand 3849 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3850 previous MANET on-demand protocols stem from research and 3851 implementation experiences. Thanks to Elizabeth Belding and Ian 3852 Chakeres for their long time authorship of AODV. Additional thanks 3853 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3854 Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, Ulrich Herberg, 3855 Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, Lars Kristensen, 3856 Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, Keyur Patel, 3857 Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro Ruiz, 3858 Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi, Seung 3859 Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2 and 3860 DYMO, as well as numerous specification suggestions. 3862 16. References 3864 16.1. Normative References 3866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3867 Requirement Levels", BCP 14, RFC 2119, 3868 DOI 10.17487/RFC2119, March 1997, 3869 . 3871 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3872 Demand Distance Vector (AODV) Routing", RFC 3561, 3873 DOI 10.17487/RFC3561, July 2003, 3874 . 3876 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 3877 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 3878 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 3879 . 3881 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 3882 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 3883 2009, . 3885 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 3886 Check Value and Timestamp TLV Definitions for Mobile Ad 3887 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 3888 April 2014, . 3890 16.2. Informative References 3892 [I-D.ietf-manet-ibs] 3893 Dearlove, C., "Identity-Based Signatures for MANET Routing 3894 Protocols", draft-ietf-manet-ibs-05 (work in progress), 3895 March 2016. 3897 [Koodli01] 3898 Koodli, R. and C. Perkins, "Fast handovers and context 3899 transfers in mobile networks", Proceedings of the ACM 3900 SIGCOMM Computer Communication Review 2001, Volume 31 3901 Issue 5, 37-47, October 2001. 3903 [Perkins94] 3904 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 3905 Sequenced Distance-Vector Routing (DSDV) for Mobile 3906 Computers", Proceedings of the ACM SIGCOMM '94 Conference 3907 on Communications Architectures, Protocols and 3908 Applications, London, UK, pp. 234-244, August 1994. 3910 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 3911 (MANET): Routing Protocol Performance Issues and 3912 Evaluation Considerations", RFC 2501, 3913 DOI 10.17487/RFC2501, January 1999, 3914 . 3916 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 3917 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 3918 June 2005, . 3920 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3921 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3922 . 3924 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 3925 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 3926 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 3927 . 3929 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 3930 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 3931 RFC 6130, DOI 10.17487/RFC6130, April 2011, 3932 . 3934 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 3935 Signatures for Identity-Based Encryption (ECCSI)", 3936 RFC 6507, DOI 10.17487/RFC6507, February 2012, 3937 . 3939 Appendix A. AODVv2 Draft Updates 3941 This section lists the changes between AODVv2 revisions ...-16.txt 3942 and ...-17.txt. 3944 o Removed wording that suggested RREP_Gen could add multiple 3945 (unrelated) subnets. 3947 o Changed wording in accordance with decision to pursue Proposed 3948 Standard. 3950 o Resolved an error scenario that was based on confirming routes to 3951 OrigAddr before the route to OrigAddr was known to be operational. 3952 But, another AODVv2 router closer to OrigAddr might forward 3953 packets along a previously confirmed route with an obsolete 3954 Sequence Number. These two conditions together were found to 3955 allow for routing loops. 3957 o Enabled multihoming by creating new address type SeqNoRtr, along 3958 with rules prohibiting comparison of sequence numbers from 3959 distinct multihoming routers per advertised prefix. 3961 Authors' Addresses 3963 Charles E. Perkins 3964 Futurewei Inc. 3965 2330 Central Expressway 3966 Santa Clara, CA 95050 3967 USA 3969 Phone: +1-408-330-4586 3970 Email: charliep@computer.org 3972 Stan Ratliff 3973 Idirect 3974 13861 Sunrise Valley Drive, Suite 300 3975 Herndon, VA 20171 3976 USA 3978 Email: ratliffstan@gmail.com 3980 John Dowdell 3981 Airbus Defence and Space 3982 Celtic Springs 3983 Newport, Wales NP10 8FZ 3984 United Kingdom 3986 Email: john.dowdell@airbus.com 3988 Lotte Steenbrink 3989 HAW Hamburg, Dept. Informatik 3990 Berliner Tor 7 3991 D-20099 Hamburg 3992 Germany 3994 Email: lotte.steenbrink@haw-hamburg.de 3995 Victoria Mercieca 3996 Airbus Defence and Space 3997 Celtic Springs 3998 Newport, Wales NP10 8FZ 3999 United Kingdom 4001 Email: victoria.mercieca@airbus.com