idnits 2.17.1 draft-perkins-manet-aodvv2-02.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 date (October 30, 2017) is 2369 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 409, but not defined == Missing Reference: 'MetricType' is mentioned on line 3363, but not defined == Missing Reference: 'OrigPrefix' is mentioned on line 2273, but not defined == Missing Reference: 'TargPrefix' is mentioned on line 2224, but not defined == Missing Reference: 'HopCount' is mentioned on line 3335, but not defined == Missing Reference: 'TBD' is mentioned on line 3385, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3561 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-02 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: May 3, 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 October 30, 2017 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-perkins-manet-aodvv2-02 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 https://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 May 3, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . 57 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 . . . . . . . . . . . 59 121 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 59 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 13.6. ICMPv6 Code Field for ICMP Destination Unreachable . . . 75 144 14. Security Considerations . . . . . . . . . . . . . . . . . . . 75 145 14.1. Availability . . . . . . . . . . . . . . . . . . . . . . 75 146 14.1.1. Denial of Service . . . . . . . . . . . . . . . . . 75 147 14.1.2. Malicious RERR messages . . . . . . . . . . . . . . 76 148 14.1.3. False Confirmation of Link Bidirectionality . . . . 78 149 14.1.4. Message Deletion . . . . . . . . . . . . . . . . . . 78 150 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 78 151 14.3. Integrity of Routes . . . . . . . . . . . . . . . . . . 79 152 14.3.1. Message Insertion . . . . . . . . . . . . . . . . . 79 153 14.3.2. Message Modification - Man in the Middle . . . . . . 80 154 14.3.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 80 155 14.4. Protection Mechanisms . . . . . . . . . . . . . . . . . 80 156 14.4.1. Confidentiality and Authentication . . . . . . . . . 80 157 14.4.2. Message Integrity using ICVs . . . . . . . . . . . . 80 158 14.4.3. Replay Protection using Timestamps . . . . . . . . . 81 159 14.5. Key Management . . . . . . . . . . . . . . . . . . . . . 81 160 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 161 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 162 16.1. Normative References . . . . . . . . . . . . . . . . . . 83 163 16.2. Informative References . . . . . . . . . . . . . . . . . 83 164 Appendix A. Most Recent AODVv2 Draft Updates . . . . . . . . . . 85 165 Appendix B. Previous AODVv2 Draft Updates . . . . . . . . . . . 85 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 168 1. Overview 170 The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol 171 enables dynamic, multihop routing between participating mobile nodes 172 wishing to establish and maintain an ad hoc network. The basic 173 operations of the AODVv2 protocol are route discovery and route 174 maintenance. AODVv2 does not require nodes to maintain routes to 175 destinations that are not in active communication. AODVv2 allows 176 mobile nodes to respond to link breakages and changes in network 177 topology in a timely manner. The operation of AODVv2 is loop-free, 178 and by avoiding the Bellman-Ford "counting to infinity" problem 179 offers quick convergence when the ad hoc network topology changes 180 (typically, when a node moves in the network). When links break, 181 AODVv2 causes the affected set of nodes to be notified so that they 182 are able to invalidate the routes using the lost link. 184 One distinguishing feature of AODVv2 is its use of a destination 185 sequence number for each route entry. The destination sequence 186 number is created by the destination to be included along with any 187 route information it sends to requesting nodes. Using destination 188 sequence numbers ensures loop freedom and is simple to program. 189 Given the choice between two routes to a destination, a requesting 190 node is required to select the one with the greatest sequence number. 192 Compared to AODV [RFC3561], AODVv2 has moved some features out of the 193 scope of the document, notably intermediate route replies, expanding 194 ring search, and route lifetimes. However, the document has been 195 designed to allow their specification in a separate document. Hello 196 messages and local repair have been removed. AODVv2 provides a 197 mechanism for the use of multiple metric types. Message formats have 198 been updated and made compliant with [RFC5444]. AODVv2 control 199 messages are defined as sets of data, which are mapped to message 200 elements using the Generalized MANET Packet/Message Format defined in 201 [RFC5444] and sent using the parameters in [RFC5498]. Verification 202 of link bidirectionality has been substantially improved, and 203 additional refinements made for route timeouts and state management. 204 Finally, multihoming is now supported. 206 The basic protocol mechanisms are as follows. Since AODVv2 is a 207 reactive protocol, route discovery is initiated only when a route to 208 the target is needed (i.e. when a router's client has data to send). 209 For this purpose, AODVv2 uses Route Request (RREQ) and Route Reply 210 (RREP) messages as follows: an RREQ is distributed across the 211 network. When forwarding an RREQ, all routers across the network 212 also store a possible reverse route back to the originator of the 213 RREQ. When the target receives the RREQ, it answers with an RREP, 214 which is then relayed back to the originator along the path stored by 215 the intermediate routers. A metric value is included within the 216 messages to indicate the cost of the route. AODVv2 uses sequence 217 numbers to identify stale routing information, and compares route 218 metric values to determine if advertised routes could form loops. 219 Route maintenance includes confirming bidirectionality of links to 220 next-hop AODVv2 routers, managing route timeouts, using Route Error 221 (RERR) messages to inform other routers of broken links, and reacting 222 to received Route Error messages. 224 The on-demand nature of AODVv2 requires indications to be exchanged 225 between AODVv2 and the forwarding plane for the following conditions: 227 o a packet is to be forwarded and route discovery is needed 229 o packet forwarding fails, in order to report a route error 231 o packet forwarding succeeds, in order to manage route timeouts. 233 Security for authentication of AODVv2 routers and encryption of 234 control messages is accomplished using the TIMESTAMP and ICV TLVs 235 defined in [RFC7182]. 237 2. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in 242 [RFC2119]. In addition, this document uses terminology from 243 [RFC5444], and defines the following terms: 245 AddressList 246 A list of IP addresses as used in AODVv2 messages. 248 AckReq 249 Used in a Route Reply Acknowledgement message to indicate that a 250 Route Reply Acknowledgement is expected in return. 252 AdvRte 253 A route advertised in an incoming route message. 255 AODVv2 Router 256 An IP addressable device in the ad hoc network that performs the 257 AODVv2 protocol operations specified in this document. 259 CurrentTime 260 The current time as maintained by the AODVv2 router. 262 ENAR (External Network Access Router) 263 An AODVv2 router with an interface to an external, non-AODVv2 264 network. 266 Interface Set 267 The set of all network interfaces supporting AODVv2. 269 Invalid route 270 A route that cannot be used for forwarding but still contains 271 useful sequence number information. 273 LocalRoute 274 An entry in the Local Route Set as defined in Section 4.5. 276 MANET 277 A Mobile Ad Hoc Network as defined in [RFC2501]. 279 MetricType 280 The metric type for a metric value included in a message. 282 MetricTypeList 283 A list of metric types associated with the addresses in the 284 AddressList of a Route Error message. 286 Neighbor 287 An AODVv2 router from which an RREQ or RREP message has been 288 received. Neighbors exchange routing information and verify 289 bidirectionality of the link to a neighbor before installing a 290 route via that neighbor into the Local Route Set. 292 OrigAddr 293 The source IP address of the IP packet triggering route discovery. 295 OrigMetric 296 The metric value associated with the route to OrigPrefix. 298 OrigPrefix 299 The prefix configured in the Router Client Set entry which 300 includes OrigAddr. 302 OrigPrefixLen 303 The prefix length, in bits, configured in the Router Client Set 304 entry which includes OrigAddr. 306 OrigSeqNum 307 The sequence number of the AODVv2 router which originated the 308 Route Request on behalf of OrigAddr. 310 PktSource 311 The source address of the IP packet that triggered a Route Error 312 message. 314 PrefixLengthList 315 A list of routing prefix lengths associated with the addresses in 316 the AddressList of a message. 318 Reactive 319 Performed only in reaction to specific events. In AODVv2, routes 320 are requested only when data packets need to be forwarded. In 321 this document, "reactive" is synonymous with "on-demand". 323 RERR (Route Error) 324 The AODVv2 message type used to indicate that an AODVv2 router 325 does not have a valid LocalRoute toward one or more destinations. 327 RERR_Gen (RERR Generating Router) 328 The AODVv2 router generating a Route Error message. 330 RerrMsg (RERR Message) 331 A Route Error (RERR) message. 333 Routable Unicast IP Address 334 A unicast IP address that is scoped sufficiently to be forwarded 335 by a router. Globally-scoped unicast IP addresses and Unique 336 Local Addresses (ULAs) [RFC4193] are examples of routable unicast 337 IP addresses. 339 Router Client 340 An address within an address range configured on an AODVv2 router, 341 on behalf of which that router will initiate and respond to route 342 discoveries. These addresses may be used by the AODVv2 router 343 itself or by devices that are reachable without traversing another 344 AODVv2 router. 346 RREP (Route Reply) 347 The AODVv2 message type used to reply to a Route Request message. 349 RREP_Gen (RREP Generating Router) 350 The AODVv2 router that generates the Route Reply message, i.e., 351 the router configured with TargAddr as a Router Client. 353 RREQ (Route Request) 354 The AODVv2 message type used to discover a route to TargAddr and 355 distribute information about a route to OrigPrefix. 357 RREQ_Gen (RREQ Generating Router) 358 The AODVv2 router that generates the Route Request message, i.e., 359 the router configured with OrigAddr as a Router Client. 361 RteMsg (Route Message) 362 A Route Request (RREQ) or Route Reply (RREP) message. 364 SeqNum 365 The sequence number maintained by an AODVv2 router to indicate 366 freshness of route information. 368 SeqNumList 369 A list of sequence numbers associated with the addresses in the 370 AddressList of a message. 372 TargAddr 373 The target address of a route request, i.e., the destination 374 address of the IP packet triggering route discovery. 376 TargMetric 377 The metric value associated with the route to TargPrefix. 379 TargPrefix 380 The prefix configured in the Router Client Set entry which 381 includes TargAddr. 383 TargPrefixLen 384 The prefix length, in bits, configured in the Router Client Set 385 entry which includes TargAddr. 387 TargSeqNum 388 The sequence number of the AODVv2 router which originated the 389 Route Reply on behalf of TargAddr. 391 Unreachable Address 392 An address reported in a Route Error message, as described in 393 Section 7.4.1. 395 Upstream 396 In the direction from destination to source (from TargAddr to 397 OrigAddr). 399 Valid route 400 A route that can be used for forwarding. 402 This document uses the notational conventions in Table 1 to simplify 403 the text. 405 +-----------------------+-------------------------------------------+ 406 | Notation | Meaning | 407 +-----------------------+-------------------------------------------+ 408 | Route[Address] | A route toward Address | 409 | Route[Address].Field | A field in a route toward Address | 410 | McMsg.Field | A field in a Multicast Route Message | 411 | | entry | 412 | RteMsg.Field | A field in either RREQ or RREP | 413 | RerrMsg.Field | A field in a RERR | 414 +-----------------------+-------------------------------------------+ 416 Table 1: Notational Conventions 418 3. Applicability Statement 420 The AODVv2 routing protocol is a reactive routing protocol designed 421 for use in mobile ad hoc wireless networks, and may also be useful in 422 networks where the nodes are not mobile but economical route 423 maintenance is still required. A reactive protocol only sends 424 messages to discover a route when there is data to send on that 425 route. This requires an interaction with the forwarding plane, to 426 indicate when a packet is to be forwarded, in case reactive route 427 discovery is needed. The set of signals exchanged between AODVv2 and 428 the forwarding plane are discussed in Section 6.4. 430 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 431 i.e., non-transit networks or those not connected to the internet. 432 AODVv2 routers can, however, be configured to perform gateway 433 functions when attached to external networks, as discussed in 434 Section 9. 436 AODVv2 handles a wide variety of mobility and traffic patterns by 437 determining routes on-demand. In networks with a large number of 438 routers, AODVv2 is best suited for relatively sparse traffic 439 scenarios where each router forwards IP packets to a small percentage 440 of destination addresses in the network. In such cases fewer routes 441 are needed, and far less control traffic is produced. In large 442 networks with dense traffic patterns, AODVv2 control messages may 443 cause a broadcast storm, overwhelming the network with control 444 messages. The transmission priorities described in Section 6.5 445 prioritize route maintenance traffic over route discovery traffic. 447 Data packets may be buffered until a route to their destination is 448 available, as described in Section 6.6. 450 AODVv2 is well suited to reactive scenarios such as emergency and 451 disaster relief, where the ability to communicate might be more 452 important than being assured of secure operations. For many other ad 453 hoc networking applications, in which insecure operation could negate 454 the value of establishing communication paths, it is important for 455 neighboring AODVv2 routers to establish security associations with 456 one another. 458 AODVv2 provides for message integrity and security against replay 459 attacks by using integrity check values, timestamps and sequence 460 numbers, as described in Section 14. When security associations have 461 been established, encryption can be used for AODVv2 messages to 462 ensure that only trusted routers participate in routing operations. 464 The AODVv2 route discovery process aims for a route to be established 465 in both directions along the same path. Uni-directional links are 466 not suitable; AODVv2 will detect and exclude those links from route 467 discovery. The route discovered is optimized for the requesting 468 router, and the return path may not be the optimal route. 470 AODVv2 is applicable to memory constrained devices, since only a 471 little routing state is maintained in each AODVv2 router. AODVv2 472 routes that are not needed for forwarding data do not need to be 473 maintained. 475 AODVv2 supports routers with multiple interfaces and multiple IP 476 addresses per interface. A router may also use the same IP address 477 on multiple interfaces. AODVv2 requires only that each interface 478 configured for AODVv2 has at least one unicast IP address. Address 479 assignment procedures are out of scope for AODVv2. 481 AODVv2 supports Router Clients with multiple interfaces, as long as 482 each interface is configured with its own unicast IP address. 484 The routing algorithm in AODVv2 has been operated at layers other 485 than the network layer, using layer-appropriate addresses. 487 AODVv2 is based on AODV [RFC3561]. The following important protocol 488 mechanisms have changed: 490 o Bidirectionality is ensured using a new mechanism 492 o Alternate metrics may be used to determine route quality 494 o Support for multiple interfaces has been improved 496 o Support for multi-interface IP addresses has been added 498 o A new security model allowing end to end integrity checks has been 499 added 501 o A new message format ([RFC5444]) is used. 503 4. Data Structures 505 4.1. Interface Set 507 The Interface Set is a conceptual data structure which contains 508 information about all interfaces configured for use by AODVv2. Any 509 interface with an IP address can be used. Multiple interfaces on a 510 single router can be used. Multiple interfaces on the same router 511 may be configured with the same IP address. 513 Each member in the Interface Set MUST contain the following: 515 Interface.Id 516 An identifier that is unique in node-local scope, allowing the 517 AODVv2 implementation to identify exactly one local network 518 interface. 520 If multiple interfaces of the AODVv2 router are configured for use by 521 AODVv2, they MUST be configured in the Interface Set. 522 Implementations using only one interface do not need the Interface 523 Set, since their single interface is already uniquely identifiable. 525 4.2. Router Client Set 527 An AODVv2 router discovers routes for its own local applications and 528 also for its Router Clients that are reachable without traversing 529 another AODVv2 router. The addresses used by these devices, and the 530 AODVv2 router itself, are configured in the Router Client Set. An 531 AODVv2 router will only originate Route Request and Route Reply 532 messages on behalf of its configured Router Client addresses. 534 Router Client Set entries contain: 536 RouterClient.IPAddress 537 An IP address or the start of an address range that requires route 538 discovery services from the AODVv2 router. 540 RouterClient.PrefixLength 541 The length, in bits, of the routing prefix associated with the 542 RouterClient.IPAddress. If the prefix length is not equal to the 543 address length of RouterClient.IPAddress, the AODVv2 router MUST 544 participate in route discovery on behalf of all addresses within 545 that prefix. 547 RouterClient.Cost 548 The cost associated with reaching this address or address range. 550 4.3. Neighbor Set 552 A Neighbor Set MUST be maintained with information about neighboring 553 AODVv2 routers. Neighbor Set entries are stored when AODVv2 messages 554 are received. If the Neighbor is chosen as a next hop on an 555 installed route, the link to the Neighbor MUST be verified to be 556 bidirectional and the result stored in this set. A route is not 557 valid until the link is confirmed to be bidirectional (see 558 Section 6.2). 560 Neighbor Set entries MUST contain: 562 Neighbor.IPAddress 563 An IP address of the neighboring router. 565 Neighbor.State 566 Indicates whether the link to the neighbor is bidirectional. 567 There are three possible states: CONFIRMED, HEARD, and 568 BLACKLISTED. HEARD is the initial state. CONFIRMED indicates 569 that the link to the neighbor has been confirmed as bidirectional. 570 BLACKLISTED indicates that the link to the neighbor is being 571 treated as uni-directional. Section 6.2 discusses how to monitor 572 link bidirectionality. 574 Neighbor.Timeout 575 Indicates the time at which the Neighbor.State should be updated: 577 o If the value of Neighbor.State is BLACKLISTED, this indicates the 578 time at which Neighbor.State will revert to HEARD. This value is 579 calculated at the time the router is blacklisted and by default is 580 equal to CurrentTime + MAX_BLACKLIST_TIME. 582 o If Neighbor.State is HEARD, and an RREP_Ack has been requested 583 from the neighbor, it indicates the time at which Neighbor.State 584 will be set to BLACKLISTED, if an RREP_Ack has not been received. 586 o If the value of Neighbor.State is HEARD and no RREP_Ack has been 587 requested, or if Neighbor.State is CONFIRMED, this time is set to 588 INFINITY_TIME. 590 Neighbor.Interface 591 The interface on which the link to the neighbor was established. 593 Neighbor.AckSeqNum 594 The next sequence number to use for the TIMESTAMP value in an 595 RREP_Ack request, in order to detect replay of an RREP_Ack 596 response. AckSeqNum is initialized to a random value. 598 Neighbor.HeardRERRSeqNum 599 The last heard sequence number used as the TIMESTAMP value in a 600 RERR received from this neighbor, saved in order to detect replay 601 of a RERR message. HeardRERRSeqNum is initialized to zero. 603 See Section 11.3 and Section 11.4 for more information on how 604 Neighbor.AckSeqNum and Neighbor.HeardRERRSeqNum are used. 606 4.4. Sequence Numbers 608 Sequence Numbers enable AODVv2 routers to determine the temporal 609 order of route discovery messages that originate from a AODVv2 610 router, and thus to identify stale routing information so that it can 611 be discarded. The sequence number fulfills the same roles as the 612 "Destination Sequence Number" of DSDV [Perkins94], and the AODV 613 Sequence Number in [RFC3561]. The sequence numbers from two 614 different routers are not comparable; route discovery messages with 615 sequence numbers belonging to two different routers cannot be 616 compared to determine temporal ordering. 618 Each AODVv2 router in the network MUST maintain its own sequence 619 number. All RREQ and RREP messages created by an AODVv2 router 620 include the router's sequence number, reported as a 16-bit unsigned 621 integer. Each AODVv2 router MUST ensure that its sequence number is 622 strictly increasing, and that it is incremented by one (1) whenever 623 an RREQ or RREP is created, except when the sequence number is 65,535 624 (the maximum value of a 16-bit unsigned integer), in which case it 625 MUST be reset to one (1) to achieve wrap around. The value zero (0) 626 is reserved to indicate that the router's sequence number is unknown. 628 An AODVv2 router MUST use its sequence number only on behalf of its 629 configured Router Clients; route messages forwarded by other routers 630 retain the originator's sequence number. 632 To determine if newly received information is stale and therefore 633 redundant compared to other information originated by the same 634 router, the sequence number attached to the information is compared 635 to the sequence number of existing information about the same route. 636 The comparison is carried out by subtracting the existing sequence 637 number from the newly received sequence number, using unsigned 638 arithmetic. The result of the subtraction is to be interpreted as a 639 signed 16-bit integer. 641 o If the result is negative, the newly received information is 642 considered older than the existing information and therefore stale 643 and redundant and MUST therefore be discarded. 645 o If the result is positive, the newly received information is newer 646 than the existing information and is not considered stale or 647 redundant and MUST therefore be processed. 649 o If the result is zero, the newly received information is not 650 considered stale, and therefore MUST be processed further in case 651 the new information offers a better route (see Section 6.7.1 and 652 Section 6.8). 654 Along with the algorithm in Section 6.7.1, maintaining temporal 655 ordering ensures loop freedom. 657 An AODVv2 router SHOULD maintain its sequence number in persistent 658 storage. On routers unable to store persistent AODVv2 state, 659 recovery can impose a performance penalty (e.g., in case of AODVv2 660 router reboot), since if a router loses its sequence number, there is 661 a delay (by default, on the order of minutes) before the router can 662 resume full operations. If the sequence number is lost, the router 663 MUST follow the procedure in Section 6.1 to safely resume routing 664 operations with a new sequence number. 666 4.5. Local Route Set 668 All AODVv2 routers MUST maintain a Local Route Set, containing 669 information obtained from AODVv2 route messages. The Local Route Set 670 is considered to be stored separately from the forwarding plane's 671 routing table (referred to as Routing Information Base (RIB)), which 672 may be updated by other routing protocols operating on the AODVv2 673 router as well. The Routing Information Base is updated using 674 information from the Local Route Set. Alternatively, if the 675 information specified below can be added to RIB entries, 676 implementations MAY choose to modify the Routing Information Base 677 directly instead of maintaining a dedicated Local Route Set. 679 Routes obtained from AODVv2 route messages are referred to in this 680 document as LocalRoutes, and MUST contain the following information: 682 LocalRoute.Address 683 An address, which, when combined with LocalRoute.PrefixLength, 684 describes the set of destination addresses for which this route 685 enables forwarding. 687 LocalRoute.PrefixLength 688 The prefix length, in bits, associated with LocalRoute.Address. 690 LocalRoute.SeqNum 691 The sequence number associated with LocalRoute.Address, obtained 692 from the last route message that successfully updated this entry. 694 LocalRoute.NextHop 695 The source IP address of the IP packet containing the AODVv2 696 message advertising the route to LocalRoute.Address, i.e., an IP 697 address of the AODVv2 router used for the next hop on the path 698 toward LocalRoute.Address. 700 LocalRoute.NextHopInterface 701 The interface used to send IP packets toward LocalRoute.Address. 703 LocalRoute.LastUsed 704 If this route is installed in the Routing Information Base, the 705 time it was last used to forward an IP packet. If not, the time 706 at which the LocalRoute was created. 708 LocalRoute.LastSeqNumUpdate 709 The time LocalRoute.SeqNum was last updated. 711 LocalRoute.MetricType 712 The type of metric associated with this route. See Section 5 for 713 information about AODVv2's handling of multiple metric types. 715 LocalRoute.Metric 716 The cost of the route toward LocalRoute.Address expressed in units 717 consistent with LocalRoute.MetricType. 719 LocalRoute.Precursors (optional feature) 720 A list of upstream neighbors using the route (see Section 10). 722 LocalRoute.SeqNoRtr 723 If nonzero, the IP address of the router that originated the 724 Sequence Number for this route. 726 LocalRoute.State 727 The last known state (Unconfirmed, Idle, Active, or Invalid) of 728 the route. 730 There are four possible states for a LocalRoute: 732 Unconfirmed 733 A route obtained from a Route Request message, which has not yet 734 been confirmed as bidirectional. It MUST NOT be stored in the RIB 735 to forward general data-plane traffic, but it can be used to 736 transmit RREP packets along with a request for bidirectional link 737 verification. An Unconfirmed route is not otherwise considered a 738 valid route. This state is only used for routes obtained through 739 RREQ messages. 741 Idle 742 A route that has been confirmed to be bidirectional, but has not 743 been used in the last ACTIVE_INTERVAL. It can be used for 744 forwarding IP packets, and therefore it is considered a valid 745 route. 747 Active 748 A valid route that has been used for forwarding IP packets during 749 the last ACTIVE_INTERVAL. 751 Invalid 752 A route that has expired or has broken. It MUST NOT be used for 753 forwarding IP packets. Invalid routes contain the destination's 754 sequence number, which may be useful when assessing freshness of 755 incoming routing information. 757 If the Local Route Set is stored separately from the RIB, routes are 758 added to the RIB when LocalRoute.State becomes Active, and removed 759 from the RIB when LocalRoute.State becomes Invalid. Changes to 760 LocalRoute state are detailed in Section 6.10.1. 762 4.6. Multicast Route Message Set 764 Multicast Route Request (RREQ) messages can be tested for redundancy 765 to avoid unnecessary processing and forwarding. 767 The Multicast Route Message Set is a conceptual set which contains 768 information about previously received multicast route messages, so 769 that incoming route messages can be compared with previously received 770 messages to determine if the incoming information is redundant or 771 stale, so that the router can avoid sending redundant control 772 traffic. 774 Multicast Route Message Set entries contain the following 775 information: 777 McMsg.OrigPrefix 778 The prefix associated with OrigAddr, the source address of the IP 779 packet triggering the route request. 781 McMsg.OrigPrefixLen 782 The prefix length associated with McMsg.OrigPrefix, originally 783 from the Router Client Set entry on RREQ_Gen which includes 784 OrigAddr. 786 McMsg.TargPrefix 787 The prefix associated with TargAddr, the destination address of 788 the IP packet triggering the route request. In an RREQ this MUST 789 be set to TargAddr. 791 McMsg.OrigSeqNum 792 The sequence number associated with the route to OrigPrefix, if 793 RteMsg is an RREQ. 795 McMsg.TargSeqNum 796 The sequence number associated with the route to TargPrefix. 798 McMsg.MetricType 799 The metric type of the route requested. 801 McMsg.Metric 802 The metric value received in the RteMsg. 804 McMsg.Timestamp 805 The last time this Multicast Route Message Set entry was updated. 807 McMsg.RemovalTime 808 The time at which this entry MUST be removed from the Multicast 809 Route Message Set. 811 McMsg.Interface 812 The interface on which the message was received. 814 McMsg.SeqNoRtr 815 If nonzero, the IP address of the router that originated the 816 Sequence Number for this route. 818 The Multicast Route Message Set is maintained so that no two entries 819 have the same OrigPrefix, OrigPrefixLen, TargPrefix, and MetricType. 820 See Section 6.8 for details about updating this set. 822 4.7. Route Error (RERR) Set 824 Each RERR message sent because no route exists for packet forwarding 825 SHOULD be recorded in a conceptual set called the Route Error (RERR) 826 Set. Each entry contains the following information: 828 RerrMsg.Timeout 829 The time after which the entry SHOULD be deleted. 831 RerrMsg.UnreachableAddress 832 The UnreachableAddress reported in the AddressList of the RERR. 834 RerrMsg.PktSource: 835 The PktSource of the RERR. 837 See Section 6.9 for instructions on how to update the set. 839 5. Metrics 841 Metrics measure a cost or quality associated with a route or a link, 842 e.g., latency, delay, financial cost, energy, etc. Metric values are 843 reported in Route Request and Route Reply messages. 845 In Route Request messages, the metric describes the cost of the route 846 from OrigPrefix to the router transmitting the Route Request. For 847 RREQ_Gen, this is the cost associated with the Router Client Set 848 entry which includes OrigAddr. For routers which forward the RREQ, 849 this is the cost from OrigPrefix to the forwarding router, combining 850 the metric value from the received RREQ message with knowledge of the 851 link cost from the sender to the receiver, i.e., the incoming link 852 cost. This updated route cost is included when forwarding the Route 853 Request message, and used to install a route to OrigPrefix. 855 Similarly, in Route Reply messages, the metric reflects the cost of 856 the route from TargPrefix to the router transmitting the Route Reply. 857 For RREP_Gen, this is the cost associated with the Router Client Set 858 entry which includes TargAddr. For routers which forward the RREP, 859 this is the cost from TargPrefix to the forwarding router, combining 860 the metric value from the received RREP message with knowledge of the 861 link cost from the sender to the receiver, i.e., the incoming link 862 cost. This updated route cost is included when forwarding the Route 863 Reply message, and used to install a route to TargPrefix. 865 When link metrics are symmetric, the cost of the routes installed in 866 the Local Route Set at each router will be correct. This assumption 867 is often inexact, but calculating incoming/outgoing metric data is 868 outside of scope of this document. The route discovered is good for 869 the requesting router, but the return path may not be the optimal 870 route. 872 AODVv2 enables the use of multiple metric types. Each route 873 discovery attempt indicates the metric type which is requested for 874 the route. Multiple valid routes may exist in the Local Route Set 875 for the same address and prefix length but for different metric 876 types. More than one route to a particular address and prefix length 877 MUST NOT exist in the Routing Information Base unless each packet can 878 be inspected to determine which route in the RIB has the proper 879 metric type as required for that packet. Otherwise, only one route 880 at a time to a particular address and prefix length may exist in the 881 RIB. The algorithm used to inspect the packet and make the 882 determination about which the routes should be installed in the 883 Routing Information Base is outside the scope of AODVv2. 885 For each MetricType, AODVv2 requires: 887 o A MetricType number, to indicate the metric type of a route. 888 Currently allocated MetricType numbers are listed in Section 13.4. 890 o A maximum value, denoted MAX_METRIC[MetricType]. This MUST always 891 be the maximum expressible metric value of type MetricType. Field 892 lengths associated with metric values are found in Section 13.4. 893 If the cost of a route exceeds MAX_METRIC[MetricType], the route 894 cannot be stored and is ignored. 896 o A function for incoming link cost, denoted Cost(L). Using 897 incoming link costs means that the route obtained has a metric 898 accurate for the direction back towards the originating router. 900 o A function for route cost, denoted Cost(R). 902 o A function to analyze routes for potential loops based on metric 903 information, denoted LoopFree(R1, R2). LoopFree verifies that a 904 route R2 is not a sub-section of another route R1. An AODVv2 905 router invokes LoopFree() as part of the process in Section 6.7.1, 906 when an advertised route (R1) and an existing LocalRoute (R2) have 907 the same destination address, metric type, and sequence number. 908 LoopFree returns FALSE to indicate that an advertised route is not 909 to be used to update a stored LocalRoute, as it may cause a 910 routing loop. In the case where the existing LocalRoute is 911 Invalid, it is possible that the advertised route includes the 912 existing LocalRoute and came from a router which did not yet 913 receive notification of the route becoming Invalid, so the 914 advertised route should not be used to update the Local Route Set, 915 in case it forms a loop to a broken route. 917 AODVv2 currently supports cost metrics where Cost(R) is strictly 918 increasing, by defining: 920 o Cost(R) := Sum of Cost(L) of each link in the route 922 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 924 Implementers MAY consider metric types that are not strictly 925 increasing, but the definitions of Cost and LoopFree functions for 926 such types are undefined, and interoperability issues need to be 927 considered. 929 6. AODVv2 Protocol Operations 931 AODVv2 protocol operations include: 933 o managing sequence numbers, 935 o monitoring next hop AODVv2 routers on discovered routes and 936 updating the Neighbor Set, 938 o performing route discovery and dealing with requests from other 939 routers, 941 o processing incoming route information and updating the Local Route 942 Set, 944 o updating the Multicast Route Message Set and suppressing redundant 945 messages, and 947 o reporting broken routes. 949 These processes are discussed in detail in the following sections. 951 6.1. Initialization 953 When an AODVv2 router does not have information about its previous 954 sequence number, or if its sequence number is lost at any point, the 955 router reinitializes its sequence number to one (1). However, other 956 AODVv2 routers may still hold sequence number information that this 957 router previously issued. Since sequence number information is 958 removed if there has been no update to the sequence number in 959 MAX_SEQNUM_LIFETIME, the initializing router MUST wait for 960 MAX_SEQNUM_LIFETIME before it creates any messages containing its new 961 sequence number. 963 During this wait period, the router is permitted to do the following: 965 o Process information in a received RREQ or RREP message to obtain a 966 route to the originator or target of that route discovery 968 o Forward a received RREQ or RREP 970 o Send an RREP_Ack 972 o Maintain valid routes in the Local Route Set 974 o Create, process and forward RERR messages 976 6.2. Next Hop Monitoring 978 To ensure AODVv2 routers do not establish routes over uni-directional 979 links, AODVv2 routers MUST verify that the link to the next hop 980 router is bidirectional before marking a route as valid in the Local 981 Route Set. 983 AODVv2 provides a mechanism for testing bidirectional connectivity 984 during route discovery, and blacklisting routers where bidirectional 985 connectivity is not available. If a route discovery is retried by 986 RREQ_Gen, the blacklisted routers are excluded from the process, and 987 a different route can be discovered. Further, a route is not to be 988 used for forwarding until the bidirectionality of the link to the 989 next hop is confirmed. AODVv2 routers do not need to monitor 990 bidirectionality for links to neighboring routers which are not used 991 as next hops on routes in the Local Route Set. 993 o Bidirectional connectivity to upstream routers is tested as 994 necessary by requesting acknowledgement of RREP messages, 995 including an AckReq element to indicate that an acknowledgement is 996 requested. This MUST be answered by sending an RREP_Ack in 997 response. Receipt of an RREP_Ack within RREP_Ack_SENT_TIMEOUT 998 demonstrates that bidirectional connectivity exists. Otherwise, 999 the link is considered to be unidirectional. All AODVv2 routers 1000 MUST support this process, which is explained in Section 7.2 and 1001 Section 7.3. 1003 o Receipt of an RREP message containing the route to TargAddr 1004 confirms bidirectionality to the downstream router, since an RREP 1005 message is a reply to an RREQ message which previously crossed the 1006 link in the opposite direction. 1008 To assist with next hop monitoring, a Neighbor Set (Section 4.3) is 1009 maintained. When an RREQ or RREP is received, an AODVv2 router 1010 searches for an entry in the Neighbor Set where all of the following 1011 conditions are met: 1013 o Neighbor.IPAddress == IP address from which the RREQ or RREP was 1014 received 1016 o Neighbor.Interface == Interface on which the RREQ or RREP was 1017 received. 1019 If no such entry exists, a new entry is created as described in 1020 Section 6.3. While the value of Neighbor.State is HEARD, 1021 acknowledgement of RREP messages sent to that neighbor MUST be 1022 requested. If an acknowledgement is not received within the timeout 1023 period, the neighbor MUST have Neighbor.State set to BLACKLISTED. If 1024 an acknowledgement is received within the timeout period, 1025 Neighbor.State is set to CONFIRMED. When the value of Neighbor.State 1026 is CONFIRMED, the request for an acknowledgement of any other RREP 1027 message is unnecessary. 1029 Additional indications of connectivity may be available from other 1030 operations, for example: 1032 o MAC layer protocol assuring bidirectional links 1034 o Route timeout 1036 o Lower layer triggers, e.g. message reception or link status 1037 notifications 1039 o TCP timeouts 1041 o Promiscuous listening 1043 o receipt of a Neighborhood Discovery Protocol HELLO message with 1044 the receiving router listed as a neighbor [RFC6130] 1046 o Other monitoring mechanisms or heuristics 1047 If such an external process signals that the link to a neighbor is 1048 bidirectional, the AODVv2 router MAY update the matching Neighbor Set 1049 entry by changing the value of Neighbor.State to CONFIRMED. If an 1050 external process signals that a link is not bidirectional, then the 1051 value of Neighbor.State MAY be changed to BLACKLISTED. 1053 6.3. Neighbor Set Update 1055 On receipt of an RREQ or RREP message, the Neighbor Set MUST be 1056 checked for an entry with Neighbor.IPAddress which matches the source 1057 IP address of a packet containing the AODVv2 message. If no matching 1058 entry is found, a new entry is created. 1060 A new Neighbor Set entry is created as follows: 1062 o Neighbor.IPAddress := Source IP address of the received route 1063 message 1065 o Neighbor.State := HEARD 1067 o Neighbor.Timeout := INFINITY_TIME 1069 o Neighbor.Interface := Interface on which the RREQ or RREP was 1070 received. (see Section 4.1). 1072 When an RREP_Ack request is sent to a neighbor, the Neighbor Set 1073 entry is updated as follows: 1075 o Neighbor.Timeout := CurrentTime + RREP_Ack_SENT_TIMEOUT 1077 When a received message is one of the following: 1079 o an RREP which answers an RREQ sent within RREQ_WAIT_TIME over the 1080 same interface as Neighbor.Interface 1082 o an RREP_Ack response received from a Neighbor with Neighbor.State 1083 set to HEARD, where Neighbor.Timeout > CurrentTime 1085 then the link to the neighbor is bidirectional and the Neighbor Set 1086 entry is updated as follows: 1088 o Neighbor.State := CONFIRMED 1090 o Neighbor.Timeout := INFINITY_TIME 1092 When the Neighbor.Timeout is reached and Neighbor.State is HEARD, 1093 then an RREP_Ack response has not been received from the neighbor 1094 within RREP_Ack_SENT_TIMEOUT of sending the RREP_Ack request. The 1095 link is considered to be uni-directional and the Neighbor Set entry 1096 is updated as follows: 1098 o Neighbor.State := BLACKLISTED 1100 o Neighbor.Timeout := CurrentTime + MAX_BLACKLIST_TIME 1102 When the Neighbor.Timeout is reached and Neighbor.State is 1103 BLACKLISTED, the Neighbor Set entry is updated as follows: 1105 o Neighbor.State := HEARD 1107 If an external mechanism reports a link as broken, the Neighbor Set 1108 entry SHOULD be removed. 1110 Route requests (RREQs) from neighbors with Neighbor.State set to 1111 BLACKLISTED MUST be ignored, to avoid persistent IP packet loss or 1112 protocol failures. Neighbor.Timeout allows the neighbor to again be 1113 allowed to participate in route discoveries after MAX_BLACKLIST_TIME, 1114 in case the link between the routers has become bidirectional. 1116 6.4. Interaction with the Forwarding Plane 1118 The signals described in the following are conceptual in nature, and 1119 can be implemented in various ways. Conformant implementations of 1120 AODVv2 are not mandated to implement the forwarding plane separately 1121 from the control plane or data plane; these signals and interactions 1122 are identified simply as assistance for implementers who may find 1123 them useful. 1125 AODVv2 requires signals from the forwarding plane: 1127 o A packet cannot be forwarded because a route is unavailable: 1128 AODVv2 needs to know the source and destination IP addresses of 1129 the packet. If the source of the packet is configured as a Router 1130 Client, the router SHOULD initiate route discovery to the 1131 destination. If it is not a Router Client, the router SHOULD 1132 create a Route Error message. 1134 o A packet is to be forwarded: AODVv2 needs to check the state of 1135 the route to ensure it is still valid. 1137 o Packet forwarding succeeds: AODVv2 needs to update the record of 1138 when a route was last used to forward a packet. 1140 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1141 Error message. 1143 AODVv2 needs to send signals to the forwarding plane when: 1145 o A route discovery is in progress: buffering might be configured 1146 for packets requiring a route, while route discovery is attempted. 1148 o A route discovery failed: any buffered packets requiring that 1149 route should be discarded, and the source of the packet should be 1150 notified that the destination is unreachable (using an ICMP 1151 Destination Unreachable message). Route discovery fails if an 1152 RREQ cannot be generated because the control message generation 1153 limit has been reached (see Section 6.5), or if an RREP is not 1154 received within RREQ_WAIT_TIME (see Section 6.6). 1156 o A route discovery succeeded: install a corresponding route into 1157 the Routing Information Base and begin transmitting any buffered 1158 packets. 1160 o A route has been made invalid: for the affected destination, 1161 remove the corresponding next hop from the Routing Information 1162 Base. 1164 o A route has been updated: update the corresponding route in the 1165 Routing Information Base. 1167 o If routes with more than one metric type are available to a 1168 destination, a way to identify the route that is allowable for the 1169 metric type associated with forwarding the incoming packet. 1171 6.5. Message Transmission 1173 AODVv2 sends [RFC5444] formatted messages using the parameters for 1174 port number and IP protocol specified in [RFC5498]. Mapping of 1175 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1176 multicast messages are sent to the link-local multicast address LL- 1177 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1178 MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2 1179 messages. Note that multicast messages MAY be sent via unicast. For 1180 example, this may occur for certain link-types (non-broadcast media), 1181 for manually configured router adjacencies, or in order to improve 1182 robustness. 1184 When multiple interfaces are available, an AODVv2 router transmitting 1185 a multicast message to LL-MANET-Routers MUST send the message on all 1186 interfaces that have been configured for AODVv2 operation, as given 1187 in the Interface Set (Section 4.1). 1189 To avoid congestion, each AODVv2 router's rate of message generation 1190 SHOULD be administratively configurable and rate-limited 1191 (CONTROL_TRAFFIC_LIMIT). Messages SHOULD NOT be sent more frequently 1192 than one message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If 1193 this threshold is reached, messages MUST be sent based on their 1194 priority: 1196 o Highest priority SHOULD be given to RREP_Ack messages. This 1197 allows links between routers to be confirmed as bidirectional and 1198 avoids undesired blacklisting of next hop routers. 1200 o Second priority SHOULD be given to RERR messages for undeliverable 1201 IP packets. This avoids repeated forwarding of packets over 1202 broken routes that are still in use by other routers. 1204 o Third priority SHOULD be given to RREP messages in order that 1205 RREQs do not time out. 1207 o Fourth priority SHOULD be given to RREQ messages. 1209 o Fifth priority SHOULD be given to RERR messages for newly 1210 invalidated routes. 1212 o Lowest priority SHOULD be given to RERR messages generated in 1213 response to RREP messages which cannot be forwarded. In this case 1214 the route request will be retried at a later point. 1216 To implement the congestion control, a queue length is set. If the 1217 queue is full, in order to queue a new message, a message of lower 1218 priority must be removed from the queue. If this is not possible, 1219 the new message MUST be discarded. The queue should be sorted in 1220 order of message priority 1222 6.6. Route Discovery, Retries and Buffering 1224 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1225 messages are multicast to solicit an RREP, whereas RREP are unicast. 1226 The constants used in this section are defined in Section 12. 1228 When an AODVv2 router needs to forward an IP packet (with source 1229 address OrigAddr and destination address TargAddr) from one of its 1230 Router Clients, it needs a route to TargAddr in its Routing 1231 Information Base. If no route exists, the AODVv2 router (RREQ_Gen) 1232 generates and multicasts a Route Request message (RREQ), on all 1233 configured interfaces, containing information about the source and 1234 destination. The procedure for this is described in Section 7.1.1. 1235 Each generated RREQ results in an increment to the router's sequence 1236 number. The AODVv2 router generating an RREQ is referred to as 1237 RREQ_Gen. 1239 Buffering might be configured for IP packets awaiting a route for 1240 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1241 of IP packets might have both positive and negative effects. TCP 1242 connection establishment will benefit if packets are queued while 1243 route discovery is performed [Koodli01], but real-time traffic, 1244 voice, and scheduled delivery may suffer if packets are buffered and 1245 subjected to delays. Recommendations for appropriate buffer methods 1246 are out of scope for this specification. Determining which packets 1247 to discard first when the buffer is full is a matter of policy at 1248 each AODVv2 router. Using different (or no) buffer methods might 1249 affect performance but does not affect interoperability. 1251 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1252 a route toward TargAddr. This can be achieved by monitoring the 1253 entry in the Multicast Route Message Table that corresponds to the 1254 generated RREQ. When CurrentTime exceeds McMsg.Timestamp + 1255 RREQ_WAIT_TIME and no RREP has been received, RREQ_Gen will retry the 1256 route discovery. 1258 To reduce congestion in a network, repeated attempts at route 1259 discovery for a particular target address utilize a binary 1260 exponential backoff: for each additional attempt, the time to wait 1261 for receipt of the RREP is multiplied by 2. If the requested route 1262 is not discovered within the wait period, another RREQ is sent, up to 1263 a total of DISCOVERY_ATTEMPTS_MAX. This is the same technique used 1264 in AODV [RFC3561]. 1266 Through the use of bidirectional link monitoring and blacklists (see 1267 Section 6.2), uni-directional links on an initially selected route 1268 will be ignored on subsequent route discovery attempts. 1270 After DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an 1271 RREP response to the final RREQ, route discovery is considered to 1272 have failed. If an attempted route discovery has failed, RREQ_Gen 1273 SHOULD wait at least RREQ_HOLDDOWN_TIME before attempting another 1274 route discovery to the same destination, in order to avoid repeatedly 1275 generating control traffic that is unlikely to discover a route. Any 1276 IP packets buffered for TargAddr are also dropped and a Destination 1277 Unreachable ICMP message (Type 3) with a code of 1 (Host Unreachable 1278 Error) is delivered to the source of the packet, so that the 1279 application knows about the failure. 1281 If RREQ_Gen does receive a route message containing a route to 1282 TargAddr within the timeout, it processes the message according to 1283 Section 7. When a valid LocalRoute entry is created in the Local 1284 Route Set, the route is also installed in the Routing Information 1285 Base, and the router will begin sending the buffered IP packets. Any 1286 retry timers for the corresponding RREQ are then cancelled. 1288 During route discovery, all routers on the path obtain a route to 1289 both OrigPrefix and TargPrefix, so that routes are constructed in 1290 both directions. The route is optimized for the forward route. 1292 6.7. Processing Received Route Information 1294 A Route Request (RREQ) contains a route to OrigPrefix, and a Route 1295 Reply (RREP) contains a route to TargPrefix. All AODVv2 routers that 1296 receive a route message first check that they have sufficient memory 1297 to store the route contained within it in their Local Route Set. 1298 Incoming information is first checked to verify that it is both safe 1299 to use and offers an improvement to existing information, as 1300 explained in Section 6.7.1. If these checks pass, the Local Route 1301 Set MUST be updated according to Section 6.7.2. 1303 In the processes below, RteMsg is used to denote the received route 1304 message, AdvRte is used to denote the route contained within it, and 1305 LocalRoute denotes an existing entry in the Local Route Set which 1306 matches AdvRte on address, prefix length, metric type, and SeqNoRtr. 1308 AdvRte has the following properties: 1310 o AdvRte.Address := RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix 1311 (in RREP) 1313 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1314 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1315 in RteMsg, prefix length is the address length, in bits, of 1316 RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix (in RREP) 1318 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1319 (in RREP) 1321 o AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the 1322 sending interface of the router from which the RteMsg was 1323 received) 1325 o AdvRte.MetricType := RteMsg.MetricType 1327 o AdvRte.Metric := RteMsg.Metric 1329 o AdvRte.Cost := Cost(R) using the cost function associated with the 1330 route's metric type. For cost metrics, Cost(R) = AdvRte.Metric + 1331 Cost(L), as described in Section 5, where L is the link from the 1332 advertising router 1334 o AdvRte.SeqNoRtr := the IP address in the Address List of type 1335 SeqNoRtr if one exists, otherwise 0 1337 6.7.1. Evaluating Route Information 1339 An incoming advertised route (AdvRte) is compared to existing 1340 LocalRoutes to determine whether the advertised route is to be used 1341 to update the AODVv2 Local Route Set. The incoming route information 1342 MUST be processed as follows: 1344 1. Search for LocalRoutes in the Local Route Set matching AdvRte's 1345 address, prefix length, metric type, and SeqNoRtr (the AODVv2 1346 router address corresponding to the sequence number). 1348 * If no matching LocalRoute exists, AdvRte MUST be used to 1349 update the Local Route Set and no further checks are required. 1351 * If matching LocalRoutes are found, continue to the next step. 1353 2. Compare sequence numbers using the technique described in 1354 Section 4.4 1356 * If AdvRte is more recent than all matching LocalRoutes, AdvRte 1357 MUST be used to update the Local Route Set and no further 1358 checks are required. 1360 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1361 Local Route Set. Ignore AdvRte for further processing. 1363 * If the sequence numbers are equal, continue to the next step. 1365 3. Check that AdvRte is safe against routing loops compared to all 1366 matching LocalRoutes (see Section 5) 1368 * If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte 1369 for further processing. AdvRte MUST NOT be used to update the 1370 Local Route Set because using the incoming information might 1371 cause a routing loop. 1373 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to the 1374 next step. 1376 4. Compare route costs 1378 * If AdvRte is better than all matching LocalRoutes, it MUST be 1379 used to update the Local Route Set because it offers 1380 improvement. 1382 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte 1383 SHOULD NOT be used to update the Local Route Set because it 1384 will offer no improvement. 1386 * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for 1387 further processing. AdvRte MUST NOT be used to update the 1388 Local Route Set because it does not offer any improvement. 1390 * If AdvRte is not better (i.e., it is worse or equal) but 1391 LocalRoute is Invalid, AdvRte SHOULD be used to update the 1392 Local Route Set because it can safely repair the existing 1393 Invalid LocalRoute. 1395 If the advertised route is to be used to update the Local Route Set, 1396 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1397 routes will remain in the Local Route Set. 1399 For information on how to apply these changes to the Routing 1400 Information Base, see Section 4.5. 1402 6.7.2. Applying Route Updates 1404 After determining that AdvRte is to be used to update the Local Route 1405 Set (as described in Section 6.7.1), the following procedure applies. 1407 If AdvRte is obtained from an RREQ message, the link to the next hop 1408 neighbor may not be confirmed as bidirectional (see Section 4.3). If 1409 there is no existing matching route in the Local Route Set, AdvRte 1410 MUST be installed to allow a corresponding RREP to be sent. If a 1411 matching entry already exists, and the link to the neighbor can be 1412 confirmed as bidirectional, AdvRte offers potential improvement. 1414 The route update is applied as follows: 1416 1. If no existing entry in the Local Route Set matches AdvRte's 1417 address, prefix length, metric type and SeqNoRtr, continue to 1418 Step 4 and create a new entry in the Local Route Set. 1420 2. If two matching LocalRoutes exist in the Local Route Set, one is 1421 a valid route, and one is an Unconfirmed route, AdvRte may offer 1422 further improvement to the Unconfirmed route, or may offer an 1423 update to the valid route. 1425 * If AdvRte.NextHop's Neighbor.State is HEARD, the advertised 1426 route may offer improvement to the existing valid route, if 1427 the link to the next hop can be confirmed as bidirectional. 1428 Continue processing from Step 5 to update the existing 1429 Unconfirmed LocalRoute. 1431 * If AdvRte.NextHop's Neighbor.State is CONFIRMED, the 1432 advertised route offers an update or improvement to the 1433 existing valid route. Continue processing from Step 5 to 1434 update the existing valid LocalRoute. 1436 3. If only one matching LocalRoute exists in the Local Route Set: 1438 * If AdvRte.NextHop's Neighbor.State is CONFIRMED, continue 1439 processing from Step 5 to update the existing LocalRoute. 1441 * If AdvRte.NextHop's Neighbor.State is HEARD, AdvRte may offer 1442 improvement the existing LocalRoute, if the link to 1443 AdvRte.NextHop can be confirmed as bidirectional. 1445 * If LocalRoute.State is Unconfirmed, AdvRte is an improvement 1446 to an existing Unconfirmed route. Continue processing from 1447 Step 5 to update the existing LocalRoute. 1449 * If LocalRoute.State is Invalid, AdvRte can replace the 1450 existing LocalRoute. Continue processing from Step 5 to 1451 update the existing LocalRoute. 1453 * If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored 1454 as an additional entry in the Local Route Set, with 1455 LocalRoute.State set to Unconfirmed. Continue processing from 1456 Step 4 to create a new LocalRoute. 1458 4. Create an entry in the Local Route Set and initialize as follows: 1460 * LocalRoute.Address := AdvRte.Address 1462 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1464 * LocalRoute.MetricType := AdvRte.MetricType 1466 5. Update the LocalRoute as follows: 1468 * LocalRoute.SeqNum := AdvRte.SeqNum 1470 * LocalRoute.NextHop := AdvRte.NextHop 1472 * LocalRoute.NextHopInterface := interface on which RteMsg was 1473 received 1475 * LocalRoute.Metric := AdvRte.Cost 1477 * LocalRoute.LastUsed := CurrentTime 1479 * LocalRoute.LastSeqNumUpdate := CurrentTime 1480 * LocalRoute.SeqNoRtr := AdvRte.SeqNoRtr 1482 6. If a new LocalRoute was created, or if the existing 1483 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1484 follows: 1486 * LocalRoute.State := Unconfirmed (if the next hop's 1487 Neighbor.State is HEARD) 1489 * LocalRoute.State := Idle (if the next hop's Neighbor.State is 1490 CONFIRMED) 1492 7. If an existing LocalRoute.State changed from Invalid or 1493 Unconfirmed to become Idle, any matching Unconfirmed LocalRoute 1494 with worse metric value SHOULD be expunged. 1496 8. If an existing LocalRoute was updated with a better metric value, 1497 any matching Unconfirmed LocalRoute with worse metric value 1498 SHOULD be expunged. 1500 9. If this update results in LocalRoute.State of Active or Idle, 1501 which matches a route request which is still in progress, the 1502 associated route request retry timers MUST be cancelled. 1504 If this update to the Local Route Set results in two LocalRoutes to 1505 the same address, the best LocalRoute will be Unconfirmed. In order 1506 to improve the route used for forwarding, the router SHOULD try to 1507 determine if the link to the next hop of that LocalRoute is 1508 bidirectional, by using that LocalRoute to forward future RREPs and 1509 request acknowledgements (see Section 7.2.1 and Section 7.3. 1511 6.8. Suppressing Redundant Messages (Multicast Route Message Set) 1513 When route messages are flooded in a MANET, an AODVv2 router may 1514 receive several instances of the same message. Forwarding every one 1515 of these would provide little additional benefit, while generating 1516 unnecessary signaling traffic and consequently additional 1517 interference. There have been a number of variations of AODV (e.g., 1518 [I-D.ietf-roll-aodv-rpl]), that have specified multicast for flooding 1519 RREP messages as well as RREQ messages. Since, in this document, 1520 suppression techniques are only needed for RREQ messages, multicast 1521 RREP messages are not considered. However, the technique involved is 1522 almost identical, and can be handled by substituting "RteMsg" instead 1523 of RREQ in the following text. 1525 Each AODVv2 router stores information about recently received RREQ 1526 messages in the AODVv2 Multicast Route Message Set (Section 4.6). 1528 In this section, an entry in the Multicast Route Message Set will be 1529 called a "multicast entry" for short. Each multicast entry SHOULD be 1530 maintained for at least RteMsg_ENTRY_TIME after the last Timestamp 1531 update in order to account for long-lived RREQs traversing the 1532 network. An entry MUST be deleted when the sequence number is no 1533 longer valid, i.e., after MAX_SEQNUM_LIFETIME. Memory-constrained 1534 devices MAY remove the entry before this time. 1536 Received RREQs are tested against multicast entries containing 1537 information about previously received RREQs. A multicast entry is 1538 considered to be compatible with a received RREQ, or another 1539 multicast entry, if they both contain the same OrigPrefix, 1540 OrigPrefixLen, TargPrefix, and MetricType. A multicast entry is 1541 considered to be comparable with a received RREQ, or another 1542 multicast entry, if they are compatible and if, in addition, they 1543 both have the same SeqNoRtr. These terms will be used in the 1544 following algorithm determining how to process a received RREQ, and 1545 whether or not the RREQ is redundant. 1547 If the received message is determined to be redundant, no forwarding 1548 or response to the message is needed. A message is considered to be 1549 redundant if either (a) a comparable newer (as determined by the 1550 OrigSeqNum) entry has already been received with information about 1551 the source and destination addresses of the route discovery operation 1552 or (b) it cannot be determined whether the message is newer compared 1553 to existing entries, but the received message metric value is not any 1554 better than metric values in compatible multicast entries. 1556 To use the received RREQ to update the Multicast Route Message Set, 1557 and to determine whether or not the received RREQ requires additional 1558 processing as specified in Section 7, perform the following steps: 1560 1. First, search for a comparable multicast entry. If there is no 1561 such entry, then create a new entry as follows: 1563 * McMsg.OrigPrefix := OrigPrefix from the RREQ 1565 * McMsg.OrigPrefixLen := the prefix length associated with 1566 OrigPrefix 1568 * McMsg.TargPrefix := TargPrefix from the message 1570 * McMsg.SeqNoRtr := the SeqNoRtr associated with RREQ if 1571 present, otherwise the sequence number associated with 1572 OrigPrefix 1574 * McMsg.OrigSeqNum := the sequence number associated with 1575 OrigPrefix 1577 * McMsg.Metric := the metric value associated with OrigPrefix in 1578 the received RREQ 1580 * McMsg.MetricType := the metric type associated with 1581 McMsg.Metric 1583 * McMsg.Interface := the network interface on which the RREQ was 1584 received. 1586 * McMsg.Timestamp := CurrentTime 1588 * McMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1590 2. Otherwise, if there is a comparable multicast entry, first update 1591 the timing information: 1593 * McMsg.Timestamp := CurrentTime 1595 * McMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1597 Then compare sequence numbers using the technique described in 1598 Section 4.4: 1600 * If the multicast entry is newer compared to the received RREQ, 1601 drop the RREQ and discontinue processing. 1603 * Otherwise, if the sequence numbers are the same, and the 1604 metric value for the multicast entry is no worse than the 1605 metric value in the received RREQ, drop the RREQ and 1606 discontinue processing. 1608 Otherwise the RREQ is newer than the multicast entry or has a 1609 better metric. Continue as follows: 1611 * McMsg.OrigSeqNum := the sequence number associated with 1612 OrigPrefix 1614 * McMsg.Metric := the metric value associated with OrigPrefix in 1615 the received RREQ 1617 3. Compare the metric values for any other compatible entries with 1618 the updated multicast entry containing the information from the 1619 received RREQ. If any other compatible entry has a metric as 1620 good or better than that from the received RREQ, then drop the 1621 RREQ and discontinue processing. 1623 If processing for the RREQ has not been discontinued according to the 1624 above instructions, then continue processing the message as specified 1625 in Section 7.1.3. 1627 6.9. Suppressing Redundant Route Error Messages (Route Error Set) 1629 In order to avoid flooding the network with RERR messages when a 1630 stream of IP packets to an unreachable address arrives, an AODVv2 1631 router SHOULD avoid creating duplicate messages by determining 1632 whether an equivalent RERR has recently been sent. This is achieved 1633 with the help of the Route Error Set (see Section 4.7). 1635 To determine if a RERR should be created: 1637 1. Search for an entry in the Route Error Set where: 1639 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1640 reported 1642 * RerrMsg.PktSource == PktSource to be included in the RERR 1644 If a matching entry is found, no further processing is required 1645 and the RERR SHOULD NOT be sent. 1647 2. If no matching entry is found, a new entry with the following 1648 properties is created, and the RERR is created and sent as 1649 described in Section 7.4.1: 1651 * RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT 1653 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1654 reported 1656 * RerrMsg.PktSource == PktSource to be included in the RERR. 1658 6.10. Local Route Set Maintenance 1660 Route maintenance involves the following operations: 1662 o monitoring LocalRoutes in the Local Route Set, 1664 o updating LocalRoute.State to handle route timeouts, 1666 o (for possibly unidirectional links) confirming a route to 1667 OrigAddr, 1669 o reporting routes that become Invalid. 1671 6.10.1. LocalRoute State Changes 1673 During normal operation, AODVv2 does not require explicit timeouts to 1674 manage the lifetime of a valid route. At any time, any LocalRoute 1675 MAY be examined and updated according to the rules below. In case a 1676 Routing Information Base is used for forwarding, the corresponding 1677 RIB entry MUST be updated as soon as the state of a LocalRoute.State 1678 changes. Otherwise, if timers are not used to prompt updates of 1679 LocalRoute.State, the LocalRoute.State MUST be checked before IP 1680 packet forwarding and before any operation based on LocalRoute.State. 1682 Route timeout behaviour is as follows: 1684 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1685 LocalRoute.LastSeqNumUpdate. 1687 o An Idle route MUST be marked as Active when used to forward an IP 1688 packet. 1690 o If an Idle route is not used to forward an IP packet within 1691 MAX_IDLETIME, LocalRoute.State MUST be set to Invalid. 1693 o An Invalid route SHOULD remain in the Local Route Set, since 1694 LocalRoute.SeqNum is used to classify future information about 1695 LocalRoute.Address as stale or fresh. 1697 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1698 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 0. 1699 This is required so that any AODVv2 routers following the 1700 initialization procedure can safely begin routing functions using 1701 a new sequence number. A LocalRoute with LocalRoute.State set to 1702 Active or Idle can remain in the Local Route Set after the 1703 sequence number has been set to 0, for example if the route is 1704 reliably carrying traffic. If LocalRoute.State is Invalid, or 1705 later becomes Invalid, the LocalRoute MUST be expunged from the 1706 Local Route Set. 1708 LocalRoutes can become Invalid before a timeout occurs, as follows: 1710 o If an external mechanism reports a link as broken, all LocalRoutes 1711 using that link for LocalRoute.NextHop MUST immediately have 1712 LocalRoute.State set to Invalid. 1714 o LocalRoute.State MUST immediately be set to Invalid if a Route 1715 Error (RERR) message is received where: 1717 * The sender is LocalRoute.NextHop, or PktSource is a Router 1718 Client address 1720 * There is an Address in AddressList which matches 1721 LocalRoute.Address, and: 1723 + The prefix length associated with this Address, if any, 1724 matches LocalRoute.PrefixLength 1726 + The sequence number associated with this Address, if any, is 1727 newer or equal to LocalRoute.SeqNum (see Section 4.4) 1729 + The metric type associated with this Address matches 1730 LocalRoute.MetricType 1732 A LocalRoute can be confirmed by inferring connectivity to OrigAddr. 1734 o When an AODVv2 router sends an RREP to OrigAddr for destination 1735 TargAddr, and subsequently the AODVv2 router receives a packet 1736 from OrigAddr with destination TargAddr, the AODVv2 router infers 1737 that the route to OrigAddr has been confirmed. The corresponding 1738 state for LocalRoute.OrigAddr is changed to Active. 1740 LocalRoutes are updated when Neighbor.State is updated: 1742 o While the value of Neighbor.State is set to HEARD, any routes in 1743 the Local Route Set using that neighbor as a next hop MUST have 1744 LocalRoute.State set to Unconfirmed. 1746 o When the value of Neighbor.State is set to BLACKLISTED, any valid 1747 routes in the Local Route Set using that neighbor for their next 1748 hop MUST have LocalRoute.State set to Invalid. 1750 o When a Neighbor Set entry is removed, all routes in the Local 1751 Route Set using that neighbor as next hop MUST have 1752 LocalRoute.State set to Invalid. 1754 Memory constrained devices MAY choose to expunge routes from the 1755 AODVv2 Local Route Set at other times, but MUST adhere to the 1756 following rules: 1758 o An Active route MUST NOT be expunged, as it is in use. If 1759 deleted, IP traffic forwarded to this router would prompt 1760 generation of a Route Error message, necessitating a Route Request 1761 to be generated by the originator's router to re-establish the 1762 route. 1764 o An Idle route SHOULD NOT be expunged, as it is still valid for 1765 forwarding IP traffic. If deleted, this could result in dropped 1766 IP packets and a Route Request could be multicasted to re- 1767 establish the route. 1769 o Any Invalid route MAY be expunged. Least recently used Invalid 1770 routes SHOULD be expunged first, since the sequence number 1771 information is less likely to be useful. 1773 o An Unconfirmed route MUST NOT be expunged if it was installed 1774 within the last RREQ_WAIT_TIME, because it may correspond to a 1775 route discovery in progress. A Route Reply message might be 1776 received which needs to use the LocalRoute.NextHop information. 1777 Otherwise, it MAY be expunged. 1779 6.10.2. Reporting Invalid Routes 1781 When LocalRoute.State changes from Active to Invalid as a result of a 1782 broken link or a received Route Error (RERR) message, other AODVv2 1783 routers MUST be informed by sending an RERR message containing 1784 details of the invalidated route. 1786 An RERR message MUST also be sent when an AODVv2 router receives an 1787 RREP message to forward, but the LocalRoute to the OrigAddr in the 1788 RREP has been lost or is marked as Invalid. 1790 A packet or message triggering the RERR MUST be discarded. 1792 Generation of an RERR message is described in Section 7.4.1. 1794 7. AODVv2 Protocol Messages 1796 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1797 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1798 (RERR). 1800 Each AODVv2 message is defined as a set of data. Rules for the 1801 generation, reception and forwarding of each message type are 1802 described in the following sections. Section 8 discusses how the 1803 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1804 TLVs. 1806 7.1. Route Request (RREQ) Message 1808 Route Request messages are used in route discovery operations to 1809 request a route to a specified target address. RREQ messages have 1810 the following contents: 1812 +-----------------------------------------------------------------+ 1813 | msg_hop_limit | 1814 +-----------------------------------------------------------------+ 1815 | AddressList | 1816 +-----------------------------------------------------------------+ 1817 | PrefixLengthList (optional) | 1818 +-----------------------------------------------------------------+ 1819 | OrigSeqNum, (optional) TargSeqNum | 1820 +-----------------------------------------------------------------+ 1821 | MetricType | 1822 +-----------------------------------------------------------------+ 1823 | OrigMetric | 1824 +-----------------------------------------------------------------+ 1826 Figure 1: RREQ message contents 1828 msg_hop_limit 1829 The remaining number of hops allowed for dissemination of the RREQ 1830 message. 1832 AddressList 1833 Contains: 1835 * OrigPrefix, from the Router Client Set entry which includes 1836 OrigAddr, the source address of the IP packet for which a route 1837 is requested, 1839 * TargPrefix, set to TargAddr, the destination address of the IP 1840 packet for which a route is requested, and 1842 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 1843 OrigRtr -- i.e., the router that originated the Sequence Number 1844 for this RREQ. 1846 PrefixLengthList 1847 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1848 associated with the Router Client Set entry which includes 1849 OrigAddr. If omitted, the prefix length is equal to OrigAddr's 1850 address length in bits. 1852 OrigSeqNum 1853 The sequence number associated with OrigPrefix. 1855 TargSeqNum 1856 A sequence number associated with an existing Invalid route to 1857 TargAddr. This MAY be included if available. 1859 MetricType 1860 The metric type associated with OrigMetric. 1862 OrigMetric 1863 The metric value associated with the route to OrigPrefix, as 1864 determined by the sender of the message. 1866 7.1.1. RREQ Generation 1868 An RREQ is generated to discover a route when an IP packet needs to 1869 be forwarded for a Router Client, and no valid route currently exists 1870 for the packet's destination in the Routing Information Base. 1872 If the limit for the rate of AODVv2 control message generation has 1873 been reached, no message SHOULD be generated Section 6.5. Before 1874 creating an RREQ, the router SHOULD check the Multicast Route Message 1875 Set to see if a compatible RREQ has recently been sent for the 1876 requested destination. If so, and the wait time for a reply has not 1877 yet been reached, the router SHOULD continue to await a response 1878 without generating a new RREQ. If the timeout has been reached, a 1879 new RREQ MAY be generated. If buffering is configured, incoming IP 1880 packets awaiting this route SHOULD be buffered until the route 1881 discovery is completed. 1883 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1884 this procedure: 1886 1. Set msg_hop_limit := MAX_HOPCOUNT 1888 2. Set AddressList := {OrigPrefix, TargPrefix} 1890 3. For the PrefixLengthList: 1892 * If OrigAddr is part of an address range configured as a Router 1893 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1894 null}. 1896 * Otherwise, omit PrefixLengthList. 1898 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 1899 IP address to AddressList, with AddressType SeqNoRtr. 1901 4. For OrigSeqNum: 1903 * Increment the router Sequence Number as specified in 1904 Section 4.4. 1906 * Set OrigSeqNum := router Sequence Number. 1908 5. For TargSeqNum: 1910 * If an Invalid route exists in the Local Route Set matching 1911 TargAddr using longest prefix matching and has a valid 1912 sequence number, set TargSeqNum := LocalRoute.SeqNum. 1914 * If no Invalid route exists in the Local Route Set matching 1915 TargAddr, or the route doesn't have a sequence number, omit 1916 TargSeqNum. 1918 6. Include MetricType and set the type accordingly 1920 7. Find the Router Client Set entry where RouterClient.IPAddress == 1921 OrigPrefix: 1923 * Set OrigMetric := RouterClient.Cost 1925 This AODVv2 message is used to create a corresponding [RFC5444] 1926 message (see Section 8) which is handed to the RFC5444 multiplexer 1927 for further processing. By default, the multiplexer is instructed to 1928 multicast RREQ messages to LL-MANET-Routers on all interfaces 1929 configured for AODVv2 operation. 1931 7.1.2. RREQ Reception 1933 Upon receiving a Route Request, an AODVv2 router performs the 1934 following steps: 1936 1. Check and update the Neighbor Set according to Section 6.3 1938 * If the sender has Neighbor.State set to BLACKLISTED, ignore 1939 this RREQ for further processing. 1941 2. Verify that the message contains the required data: 1942 msg_hop_limit, OrigPrefix, TargPrefix, OrigSeqNum, and 1943 OrigMetric, and that OrigPrefix and TargPrefix are valid address 1944 prefixes 1946 * If not, ignore this RREQ for further processing. 1948 3. Check that the MetricType is supported and configured for use 1950 * If so, continue to the next numbered step. 1952 * Otherwise, if the TargPrefix matches an entry in the Router 1953 Client Set, send an ICMP Destination Unreachable message to 1954 the source with Code value set to "Metric Type Mismatch" (see 1955 Section 13.6). 1957 * Ignore this RREQ for further processing. 1959 4. Determine whether the cost of the advertised route will exceed 1960 the maximum allowed metric value for the metric type (Metric <= 1961 MAX_METRIC[MetricType] - Cost(L)) 1963 * If it will, ignore this RREQ for further processing. 1965 5. Process the route to OrigPrefix as specified in Section 6.7 1967 6. Determine whether or not the information in the message is 1968 redundant, by following the procedure in Section 6.8; if 1969 redundant, ignore this RREQ for further processing. 1971 7. Check if the TargPrefix matches an entry in the Router Client Set 1973 * If so, generate an RREP as specified in Section 7.2.1. 1975 * If not, continue to RREQ forwarding Section 7.2.3. 1977 7.1.3. RREQ Forwarding 1979 Forwarding or responding to a RteMsg provides up-to-date information 1980 and improved metrics to other routers. If a RteMsg is not forwarded, 1981 routes needed by applications may not be discovered. 1983 By forwarding an RREQ, a router advertises that it will forward IP 1984 packets to the OrigPrefix contained in the RREQ according to the 1985 information enclosed. The router MAY choose not to forward the RREQ, 1986 for example if the router is heavily loaded or low on energy and 1987 therefore unwilling to advertise routing capability for more traffic. 1988 This could, however, decrease connectivity in the network or result 1989 in non-optimal paths. 1991 The RREQ MUST NOT be forwarded if the received msg_hop_limit = 1, or 1992 if the limit for the rate of AODVv2 control message generation has 1993 been reached. Otherwise, the RREQ is updated and forwarded as 1994 follows: 1996 1. Set msg_hop_limit := received msg_hop_limit - 1 1998 2. Set OrigMetric := LocalRoute[OrigPrefix].Metric 2000 This modified RREQ is handed to the [RFC5444] multiplexer for further 2001 processing. By default, the multiplexer is instructed to multicast 2002 the message to LL-MANET-Routers on all interfaces configured for 2003 AODVv2 operation. 2005 7.2. Route Reply (RREP) Message 2007 When a Route Request message is received, requesting a route to a 2008 target address (TargAddr) which is configured as part of a Router 2009 Client Set entry, a Route Reply message is sent in response. The 2010 RREP offers a route to TargPrefix. 2012 RREP messages have the following contents: 2014 +-----------------------------------------------------------------+ 2015 | msg_hop_limit | 2016 +-----------------------------------------------------------------+ 2017 | AddressList | 2018 +-----------------------------------------------------------------+ 2019 | PrefixLengthList (optional) | 2020 +-----------------------------------------------------------------+ 2021 | TargSeqNum | 2022 +-----------------------------------------------------------------+ 2023 | MetricType | 2024 +-----------------------------------------------------------------+ 2025 | TargMetric | 2026 +-----------------------------------------------------------------+ 2028 Figure 2: RREP message contents 2030 msg_hop_limit 2031 The remaining number of hops allowed for dissemination of the RREP 2032 message. 2034 AddressList 2035 Contains: 2037 * OrigPrefix, from the Router Client entry which includes 2038 OrigAddr, the source address of the IP packet for which a route 2039 is requested 2041 * TargPrefix, set to TargAddr, the destination address of the IP 2042 packet for which a route is requested. 2044 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 2045 TargRtr -- i.e., the router that originated the Sequence Number 2046 for this RREP. 2048 PrefixLengthList 2049 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 2050 associated with the Router Client Set entry which includes 2051 TargAddr. If omitted, the prefix length is equal to TargAddr's 2052 address length, in bits. 2054 TargSeqNum 2055 The sequence number associated with TargPrefix. 2057 MetricType 2058 The metric type associated with TargMetric. 2060 TargMetric 2061 The metric value associated with the route to TargPrefix, as seen 2062 from the sender of the message. 2064 7.2.1. RREP Generation 2066 A Route Reply message is generated when a Route Request for a Router 2067 Client of the AODVv2 router arrives. This is the case when 2068 RteMsg.TargPrefix matches an entry in the Router Client Set of the 2069 AODVv2 router. 2071 Before creating an RREP, the router SHOULD check whether 2072 CONTROL_TRAFFIC_LIMIT has been reached. If so, the RREP SHOULD NOT 2073 be created. 2075 The RREP will traverse the path of the route to OrigPrefix. If the 2076 best route to OrigPrefix in the Local Route Set is Unconfirmed, the 2077 link to the next hop neighbor is not yet confirmed as bidirectional 2078 (see Section 6.2). In this case an RREP_Ack MUST also be sent as 2079 described in Section 7.3, in order to request an acknowledgement 2080 message from the next hop router to prove that the link is 2081 bidirectional. If the best route to OrigPrefix in the Local Route 2082 Set is valid, the link to the next hop neighbor is already confirmed 2083 as bidirectional, and no acknowledgement is required. 2085 Implementations MAY allow a number of retries of the RREP if a 2086 requested acknowledgement is not received within 2087 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 2088 maximum of RREP_RETRIES, using the same exponential backoff described 2089 in Section 6.6 for RREQ retries. The acknowledgement MUST be 2090 considered to have failed after the wait time for an RREP_Ack 2091 response to the final RREP. 2093 To generate the RREP, the router (also referred to as RREP_Gen) 2094 follows this procedure: 2096 1. Set msg_hop_limit := MAX_HOPCOUNT - msg_hop_limit from the 2097 received RREQ message 2099 2. Set Address List := {OrigPrefix, TargPrefix} 2100 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 2101 IP address to AddressList, with AddressType SeqNoRtr. 2103 3. For the PrefixLengthList: 2105 * If TargAddr is part of an address range configured as a Router 2106 Client, set PrefixLengthList := {null, 2107 RouterClient.PrefixLength}. 2109 * Otherwise, omit PrefixLengthList. 2111 4. For the TargSeqNum: 2113 * Increment the router Sequence Number as specified in 2114 Section 4.4. 2116 * Set TargSeqNum := router Sequence Number. 2118 5. Include MetricType and set the type to match the MetricType in 2119 the received RREQ message. 2121 6. Set TargMetric := RouterClient.Cost for the Router Client Set 2122 entry which includes TargAddr. 2124 This AODVv2 message is used to create a corresponding [RFC5444] 2125 message (see Section 8) which is handed to the RFC5444 multiplexer 2126 for further processing. The multiplexer is instructed to unicast the 2127 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2128 LocalRoute[OrigPrefix].NextHopInterface. 2130 7.2.2. RREP Reception 2132 Upon receiving a Route Reply, an AODVv2 router performs the following 2133 steps: 2135 1. Verify that the message contains the required data: 2136 msg_hop_limit, OrigPrefix, TargPrefix, TargSeqNum, and 2137 TargMetric, and that OrigPrefix and TargPrefix are valid 2138 addresses 2140 * If not, ignore this RREP for further processing. 2142 2. Check that the MetricType is supported and configured for use 2144 * If not, ignore this RREP for further processing. 2146 3. If this RREP does not correspond to an RREQ generated or 2147 forwarded in the last RREQ_WAIT_TIME, ignore for further 2148 processing. 2150 4. If the Multicast Route Message Set does not contain an entry 2151 where: 2153 o McMsg.OrigPrefix == RREP.OrigPrefix 2155 o McMsg.OrigPrefixLen == RREP.OrigPrefixLen 2157 o McMsg.TargAddr exists within RREP.TargPrefix 2159 o McMsg.OrigSeqNum <= RREP.OrigSeqNum 2161 o McMsg.SeqNoRtr = RREP.SeqNoRtr 2163 o McMsg.MetricType == RREP.MetricType 2165 o McMsg.Timestamp > CurrentTime - RREQ_WAIT_TIME 2167 o McMsg.Interface == The interface on which the RREP was received 2169 then, ignore this RREP for further processing, since it does not 2170 correspond to a previously sent RREQ. Otherwise continue as follows: 2172 1. Update the Neighbor Set according to Section 6.3 2174 2. Determine whether the cost of the advertised route exceeds the 2175 maximum allowed metric value for the metric type (Metric <= 2176 MAX_METRIC[MetricType] - Cost(L)) 2178 * If it does, ignore this RREP for further processing. 2180 3. Process the route to TargPrefix as specified in Section 6.7 2182 4. Determine whether the message is redundant by comparing to 2183 entries in the Multicast Route Message Set (Section 6.8) 2185 * If redundant, ignore this RREP for further processing. 2187 * If not redundant, save the information in the Multicast Route 2188 Message Set to identify future redundant RREP messages and 2189 continue processing. 2191 5. Determine whether the OrigPrefix matches an entry in the Router 2192 Client Set 2193 * If so, no further processing is necessary. 2195 * If not, continue to the next step. 2197 6. Determine whether a valid (Active or Idle) or Unconfirmed 2198 LocalRoute exists to OrigPrefix 2200 * If so, continue to RREP forwarding Section 7.2.3. 2202 * If not, a Route Error message SHOULD be transmitted toward 2203 TargPrefix according to Section 7.4.1; the RREP MUST be 2204 discarded and not forwarded. 2206 7.2.3. RREP Forwarding 2208 A received Route Reply message is forwarded toward OrigPrefix. By 2209 forwarding the RREP, a router advertises that it has a route to 2210 TargPrefix. 2212 The RREP MUST NOT be forwarded if the received msg_hop_limit = 1, or 2213 if CONTROL_TRAFFIC_LIMIT has been reached. Otherwise, the router 2214 MUST forward the RREP. 2216 The procedure for RREP forwarding is as follows: 2218 1. Set msg_hop_limit := received msg_hop_limit - 1 2220 2. If the link to the next hop router toward OrigAddr is not known 2221 to be bidirectional, also verify bidirectionality (see 2222 Section 6.2). 2224 3. Set TargMetric := LocalRoute[TargPrefix].Metric 2226 This modified message is handed to the [RFC5444] multiplexer for 2227 further processing. The multiplexer is instructed to unicast the 2228 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2229 LocalRoute[OrigPrefix].NextHopInterface. 2231 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2233 The Route Reply Acknowledgement is used as both a request and a 2234 response message to test bidirectionality of a link over which a 2235 Route Reply has also been sent. The router which forwards the RREP 2236 MUST send a Route Reply Acknowledgement message to the intended next 2237 hop, if the link to the next hop neighbor is not yet confirmed as 2238 bidirectional. 2240 The receiving router MUST then reply with a Route Reply 2241 Acknowledgement response message. 2243 When the Route Reply Acknowledgement response message is received by 2244 the sender of the RREP, it confirms that the link between the two 2245 routers is bidirectional (see Section 6.2). 2247 If the Route Reply Acknowledgement is not received within 2248 RREP_Ack_SENT_TIMEOUT, the link is determined to be unidirectional. 2250 +-----------------------------------------------------------------+ 2251 | AckReq (optional) | 2252 +-----------------------------------------------------------------+ 2254 Figure 3: RREP_Ack message contents 2256 7.3.1. RREP_Ack Request Generation 2258 An RREP_Ack MUST be generated if a Route Reply is sent over a link 2259 which is not known to be bidirectional. It includes an AckReq 2260 element to indicate that it is a request for acknowledgement. 2262 The RREP_Ack SHOULD NOT be generated if the limit for the rate of 2263 AODVv2 control message generation has been reached. 2265 The [RFC5444] representation of the RREP_Ack is discussed in 2266 Section 8. 2268 RREP_Ack requests MUST be unicast to LocalRoute[OrigPrefix].NextHop 2269 via LocalRoute[OrigPrefix].NextHopInterface. The multiplexer SHOULD 2270 be instructed to send the RREP_Ack in the same [RFC5444] packet as 2271 the RREP. 2273 The Neighbor Set entry for LocalRoute[OrigPrefix].NextHop MUST also 2274 be updated to indicate that an RREP_Ack is required (see 2275 Section 6.3). 2277 7.3.2. RREP_Ack Reception 2279 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2280 steps: 2282 1. Determine whether an AckReq element is included: 2284 * If so, create an RREP_Ack Response as described in 2285 Section 7.3.3. No further processing is required. 2287 * If not, continue to the next step. 2289 2. Determine whether the Neighbor Set contains an entry where: 2291 * Neighbor.IPAddress == IP.SourceAddress of the RREP_Ack message 2293 * Neighbor.State == HEARD 2295 * Neighbor.Timeout < CurrentTime 2297 * Neighbor.Interface matches the interface on which the RREP_Ack 2298 was received 2300 If no such entry is found, the RREP_Ack was not expected; no 2301 actions are required and processing ends. Otherwise, the router 2302 sets Neighbor.Timeout to INFINITY_TIME, and processing continues 2303 to the next step. 2305 3. Update the Neighbor Set according to Section 6.3, including 2306 updating routes using this Neighbor as LocalRoute.NextHop. 2308 7.3.3. RREP_Ack Response Generation 2310 An RREP_Ack response MUST be generated if a received RREP_Ack 2311 includes an AckReq, unless the limit for the rate of AODVv2 control 2312 message generation has been reached in which case the RREP_Ack 2313 response SHOULD NOT be generated. 2315 There is no further data in an RREP_Ack response. The [RFC5444] 2316 representation is discussed in Section 8. In this case, the 2317 multiplexer is instructed to unicast the RREP_Ack to the source IP 2318 address of the RREP_Ack message that requested it, over the same 2319 interface on which the RREP_Ack was received. 2321 7.4. Route Error (RERR) Message 2323 A Route Error message is generated by an AODVv2 router to notify 2324 other AODVv2 routers about routes that are no longer available. An 2325 RERR message has the following contents: 2327 +-----------------------------------------------------------------+ 2328 | PktSource (optional) | 2329 +-----------------------------------------------------------------+ 2330 | AddressList | 2331 +-----------------------------------------------------------------+ 2332 | PrefixLengthList (optional) | 2333 +-----------------------------------------------------------------+ 2334 | SeqNumList (optional) | 2335 +-----------------------------------------------------------------+ 2336 | MetricTypeList | 2337 +-----------------------------------------------------------------+ 2339 Figure 4: RERR message contents 2341 PktSource 2342 The source address of the IP packet triggering the RERR. If the 2343 RERR is triggered by a broken link, PktSource is not required. 2345 AddressList 2346 The addresses of the routes not available through RERR_Gen. 2348 PrefixLengthList 2349 The prefix lengths, in bits, associated with the routes not 2350 available through RERR_Gen. These values indicate whether routes 2351 represent a single device or an address range. 2353 SeqNumList 2354 The sequence numbers (where known) of the routes not available 2355 through RERR_Gen. 2357 MetricTypeList 2358 The metric types associated with the routes not available through 2359 RERR_Gen. 2361 7.4.1. RERR Generation 2363 A Route Error message is generated when an AODVv2 router (also 2364 referred to as RERR_Gen) needs to report that a destination is not 2365 reachable. There are three events that cause this response: 2367 o When an IP packet that has been forwarded from another router, but 2368 there is no valid route in the Routing Information Base for its 2369 destination, the source of the packet needs to be informed that 2370 the route to the destination of the packet does not exist. The 2371 RERR generated MUST include PktSource set to the source address of 2372 the IP packet, and MUST contain only one unreachable address in 2373 the AddressList, i.e., the destination address of the IP packet. 2374 RERR_Gen MUST discard the IP packet that triggered generation of 2375 the RERR. The prefix length, sequence number and metric type 2376 SHOULD be included if known from an existing Invalid LocalRoute to 2377 the unreachable address. 2379 o When an RREP message cannot be forwarded because the LocalRoute to 2380 OrigPrefix has been lost or is Invalid, RREP_Gen needs to be 2381 informed that the route to OrigPrefix does not exist. The RERR 2382 generated MUST include PktSource set to the TargPrefix of the 2383 RREP, and MUST contain only one unreachable address in the 2384 AddressList, the OrigPrefix from the RREP. RERR_Gen MUST discard 2385 the RREP message that triggered generation of the RERR. The 2386 prefix length, sequence number and metric type SHOULD be included 2387 if known from an Invalid LocalRoute to the unreachable address. 2389 o When a link breaks, multiple LocalRoutes may become Invalid, and 2390 the RERR generated MAY contain multiple unreachable addresses. 2391 The RERR MUST include MetricTypeList. PktSource is omitted. All 2392 previously Active LocalRoutes that used the broken link MUST be 2393 reported. The AddressList, SeqNumList, and MetricTypeList will 2394 contain entries for each LocalRoute which has become Invalid. 2395 PrefixLengthList will be included if needed to report invalid 2396 routes to a non-default prefix. An RERR message is only sent if 2397 an Active LocalRoute becomes Invalid, though an AODVv2 router can 2398 also include Idle LocalRoutes that become Invalid if the 2399 configuration parameter ENABLE_IDLE_IN_RERR is set (see 2400 Section 12.3). 2402 The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been 2403 reached. The RERR also SHOULD NOT be generated if it is a duplicate, 2404 as determined by Section 6.9. 2406 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2407 from the address of one of its Router Clients, it forwards the ICMP 2408 packet in the same way as any other IP packet, and will not generate 2409 any RERR message based on the contents of the ICMP packet. 2411 To generate the RERR, the router follows this procedure: 2413 1. If necessary, include PktSource and set the value as given above 2415 2. For each LocalRoute that needs to be reported: 2417 * Insert LocalRoute.Address into the AddressList. 2419 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2420 and not equal to the address length. 2422 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2424 * Insert LocalRoute.MetricType into MetricTypeList. 2426 The AODVv2 message is used to create a corresponding [RFC5444] 2427 message (see Section 8). 2429 If the RERR is sent in response to an undeliverable IP packet or RREP 2430 message (i.e., if PktSource is included), the RERR SHOULD be sent 2431 unicast to the next hop on the route to PktSource. It MUST be sent 2432 over the same interface on which the undeliverable IP packet was 2433 received. If there is no route to PktSource, the RERR SHOULD be 2434 multicast to LL-MANET-Routers. If the RERR is sent in response to a 2435 broken link, i.e., PktSource is not included, the RERR is, by 2436 default, multicast to LL-MANET-Routers. 2438 Section 10 describes processing steps when the optional precursor 2439 lists feature is implemented. 2441 7.4.2. RERR Reception 2443 Upon receiving a Route Error, an AODVv2 router performs the following 2444 steps: 2446 1. Determine whether the message contains at least one unreachable 2447 address; if not, ignore this RERR for further processing. 2448 Otherwise continue as follows: 2450 2. For each address in the AddressList, check that: 2452 * The address is valid (routable and unicast). 2454 * The MetricType is supported and configured for use. 2456 * There is a LocalRoute with the same MetricType matching the 2457 address using longest prefix matching. 2459 * Either the LocalRoute's next hop is the sender of the RERR and 2460 the next hop interface is the interface on which the RERR was 2461 received, or PktSource is present in the RERR and is a Router 2462 Client address. 2464 * The unreachable address' sequence number is either unknown, or 2465 is no less than the LocalRoute's sequence number. 2467 If any of the above are false the address does not match a 2468 LocalRoute and MUST NOT be processed or regenerated in a RERR. 2470 If all of the above are true, the LocalRoute which matches the 2471 unreachable address MUST be marked as Invalid. Otherwise, 2472 regeneration of the RERR proceeds as follows. If the LocalRoute 2473 was previously Active, it MUST be reported in a regenerated RERR. 2474 If the LocalRoute was previously Idle, it MAY be reported in a 2475 regenerated RERR, if ENABLE_IDLE_IN_RERR is configured. The 2476 Local Route Set MUST be updated according to these rules: 2478 * If the LocalRoute's prefix length is the same as the 2479 unreachable address' prefix length, set LocalRoute.State to 2480 Invalid. 2482 * If the LocalRoute's prefix length is longer than the 2483 unreachable address' prefix length, the LocalRoute MUST be 2484 expunged from the Local Route Set, since it is a sub-route of 2485 the route which is reported to be Invalid. 2487 * If the prefix length is different, create a new LocalRoute 2488 with the unreachable address, and its prefix length and 2489 sequence number, and set LocalRoute.State to Invalid. These 2490 Invalid routes are retained to avoid processing stale 2491 messages. 2493 * Update the sequence number on the existing LocalRoute, if the 2494 reported sequence number is determined to be newer using the 2495 comparison method described in Section 4.4. 2497 3. If there are previously Active LocalRoutes that MUST be reported, 2498 regenerate the RERR as detailed in Section 7.4.3. 2500 7.4.3. RERR Regeneration 2502 The Route Error message SHOULD NOT be regenerated if 2503 CONTROL_TRAFFIC_LIMIT has been reached. 2505 The procedure for RERR regeneration is as follows: 2507 1. If PktSource was included in the received RERR, and PktSource is 2508 not a Router Client, copy it into the regenerated RERR 2510 2. For each LocalRoute that needs to be reported as identified in 2511 Section 7.4.1: 2513 * Insert LocalRoute.Address into the AddressList. 2515 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2516 and not equal to the address length. 2518 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2520 * Insert LocalRoute.MetricType into MetricTypeList. 2522 The AODVv2 message is used to create a corresponding [RFC5444] 2523 message (see Section 8). If the RERR contains PktSource, the 2524 regenerated RERR SHOULD be sent unicast to the next hop on the 2525 LocalRoute to PktSource. It MUST be sent over the same interface on 2526 which the undeliverable IP packet was received. If there is no route 2527 to PktSource, or PktSource is a Router Client, it SHOULD be multicast 2528 to LL-MANET-Routers. If the RERR is sent in response to a broken 2529 link, the RERR is, by default, multicast to LL-MANET-Routers. 2531 8. RFC 5444 Representation 2533 AODVv2 specifies that all control messages between routers MUST use 2534 the Generalized Mobile Ad Hoc Network Packet/Message Format 2535 [RFC5444], and therefore AODVv2's route messages comprise data which 2536 is mapped to message elements in [RFC5444]. 2538 [RFC5444] provides a multiplexed transport for multiple protocols. 2539 An [RFC5444] implementation MAY choose to optimize the content of 2540 certain elements during message creation to reduce control message 2541 overhead. 2543 A brief summary of the [RFC5444] format: 2545 1. A packet contains zero or more messages 2547 2. A message contains a Message Header, one Message TLV Block, zero 2548 or more Address Blocks, and one Address Block TLV Block per 2549 Address Block 2551 3. The Message TLV Block contains zero or more Message TLVs 2553 4. An Address Block TLV Block includes zero or more Address Block 2554 TLVs 2556 5. Each TLV value in an Address Block TLV Block can be associated 2557 with all of the addresses, or with a contiguous set of addresses, 2558 or with a single address in the Address Block 2560 AODVv2 does not require access to the [RFC5444] packet header. 2562 In the message header, AODVv2 uses , and 2563 . The field indicates the length 2564 of any addresses in the message, using := (address 2565 length in octets - 1), i.e. 3 for IPv4 and 15 for IPv6. 2567 The addresses in an Address Block MAY appear in any order, and values 2568 in a TLV in the Address Block TLV Block must be associated with the 2569 correct address in the Address Block by the [RFC5444] implementation. 2570 To indicate which value is associated with each address, the AODVv2 2571 message representation uses lists where the order of the addresses in 2572 the AODVv2 AddressList matches the order of values in other data 2573 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2574 [RFC5444] maps this information to Address Block TLVs associated with 2575 the relevant addresses in the Address Block. 2577 Each address included in the Address Block is identified as 2578 OrigPrefix, TargPrefix, PktSource, SeqNoRtr, or Unreachable Address 2579 by including an ADDRESS_TYPE TLV in the Address Block TLV Block. 2581 The following sections show how AODVv2 data is represented in 2582 [RFC5444] messages. In Section 13.3, AODVv2 defines several new 2583 TLVs. 2585 Where the extension type of a TLV is set to zero, this is the default 2586 [RFC5444] value and the extension type will not be included in the 2587 message. 2589 8.1. Route Request Message Representation 2591 8.1.1. Message Header 2593 +---------------+-----------------+---------------------------------+ 2594 | Data | Header Field | Value | 2595 +---------------+-----------------+---------------------------------+ 2596 | None | | RREQ | 2597 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2598 | | | of hops traversed so far by the | 2599 | | | message. | 2600 +---------------+-----------------+---------------------------------+ 2602 8.1.2. Message TLV Block 2604 AODVv2 does not define any Message TLVs for an RREQ message. 2606 8.1.3. Address Block 2608 An RREQ contains OrigPrefix and TargPrefix, and each of these 2609 addresses has an associated prefix length. If the prefix length has 2610 not been included in the AODVv2 message, it is equal to the address 2611 length in bits. 2613 +---------------------------+------------------------------+ 2614 | Data | Address Block | 2615 +---------------------------+------------------------------+ 2616 | OrigPrefix/OrigPrefixLen |
+ | 2617 | TargPrefix/TargPrefixLen |
+ | 2618 | SeqNoRtr/PrefixLen |
+ | 2619 +---------------------------+------------------------------+ 2621 8.1.4. Address Block TLV Block 2623 Address Block TLVs are always associated with one or more addresses 2624 in the Address Block. The following sections show the TLVs that 2625 apply to each address. 2627 8.1.4.1. Address Block TLVs for OrigPrefix 2629 +-------------+--------------+------------+-------------------------+ 2630 | Data | TLV Type | Extension | Value | 2631 | | | Type | | 2632 +-------------+--------------+------------+-------------------------+ 2633 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2634 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2635 | | | | RREQ_Gen, the router | 2636 | | | | which initiated route | 2637 | | | | discovery. | 2638 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2639 | /MetricType | | | route to OrigPrefix, | 2640 | | | | using MetricType. | 2641 +-------------+--------------+------------+-------------------------+ 2643 8.1.4.2. Address Block TLVs for TargPrefix 2645 +------------+--------------+-------------+-------------------------+ 2646 | Data | TLV Type | Extension | Value | 2647 | | | Type | | 2648 +------------+--------------+-------------+-------------------------+ 2649 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2650 | TargSeqNum | SEQ_NUM | 0 | The last known | 2651 | | | | TargSeqNum for | 2652 | | | | TargPrefix. | 2653 +------------+--------------+-------------+-------------------------+ 2655 8.2. Route Reply Message Representation 2656 8.2.1. Message Header 2658 +---------------+-----------------+---------------------------------+ 2659 | Data | Header Field | Value | 2660 +---------------+-----------------+---------------------------------+ 2661 | None | | RREP | 2662 | msg_hop_limit | | MAX_HOPCOUNT - msg_hop_limit | 2663 | | | from the corresponding RREQ, | 2664 | | | reduced by number of hops | 2665 | | | traversed so far by the | 2666 | | | message. | 2667 +---------------+-----------------+---------------------------------+ 2669 8.2.2. Message TLV Block 2671 AODVv2 does not define any Message TLVs for an RREP message. 2673 8.2.3. Address Block 2675 An RREP contains OrigPrefix and TargPrefix, and each of these 2676 addresses has an associated prefix length. If the prefix length has 2677 not been included in the AODVv2 message, it is equal to the address 2678 length in bits. 2680 +---------------------------+------------------------------+ 2681 | Data | Address Block | 2682 +---------------------------+------------------------------+ 2683 | OrigPrefix/OrigPrefixLen |
+ | 2684 | TargPrefix/TargPrefixLen |
+ | 2685 | SeqNoRtr/PrefixLen |
+ | 2686 +---------------------------+------------------------------+ 2688 8.2.4. Address Block TLV Block 2690 Address Block TLVs are always associated with one or more addresses 2691 in the Address Block. The following sections show the TLVs that 2692 apply to each address. 2694 8.2.4.1. Address Block TLVs for OrigPrefix 2696 +-------+---------------+-----------------+-------------+ 2697 | Data | TLV Type | Extension Type | Value | 2698 +-------+---------------+-----------------+-------------+ 2699 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2700 +-------+---------------+-----------------+-------------+ 2702 8.2.4.2. Address Block TLVs for TargPrefix 2704 +--------------+--------------+------------+------------------------+ 2705 | Data | TLV Type | Extension | Value | 2706 | | | Type | | 2707 +--------------+--------------+------------+------------------------+ 2708 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2709 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2710 | | | | RREP_Gen, the router | 2711 | | | | which created the | 2712 | | | | RREP. | 2713 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2714 | /MetricType | | | route to TargPrefix, | 2715 | | | | using MetricType. | 2716 +--------------+--------------+------------+------------------------+ 2718 8.3. Route Reply Acknowledgement Message Representation 2720 8.3.1. Message Header 2722 +-------+---------------+-----------+ 2723 | Data | Header Field | Value | 2724 +-------+---------------+-----------+ 2725 | None | | RREP_Ack | 2726 +-------+---------------+-----------+ 2728 8.3.2. Message TLV Block 2730 AODVv2 defines an AckReq Message TLV, included when an 2731 acknowledgement of this message is required, in order to monitor 2732 adjacency, as described in Section 6.2. 2734 +---------+-----------+-----------------+--------+ 2735 | Data | TLV Type | Extension Type | Value | 2736 +---------+-----------+-----------------+--------+ 2737 | AckReq | ACK_REQ | 0 | None | 2738 +---------+-----------+-----------------+--------+ 2740 8.3.3. Address Block 2742 AODVv2 does not define an Address Block for an RREP_Ack message. 2744 8.3.4. Address Block TLV Block 2746 AODVv2 does not define any Address Block TLVs for an RREP_Ack 2747 message. 2749 8.4. Route Error Message Representation 2751 Route Error Messages MAY be split into multiple [RFC5444] messages 2752 when the desired contents would exceed the MTU. However, all of the 2753 resulting messages MUST have the same message header as described 2754 below. If PktSource is included in the AODVv2 message, it MUST be 2755 included in all of the resulting [RFC5444] messages. 2757 8.4.1. Message Header 2759 +-------+---------------+--------+ 2760 | Data | Header Field | Value | 2761 +-------+---------------+--------+ 2762 | None | | RERR | 2763 +-------+---------------+--------+ 2765 8.4.2. Message TLV Block 2767 AODVv2 does not define any Message TLVs for an RERR message. 2769 8.4.3. Address Block 2771 The Address Block in an RERR MAY contain PktSource, the source 2772 address of the IP packet triggering RERR generation, as detailed in 2773 Section 7.4. The prefix length associated with PktSource is equal to 2774 the address length in bits. 2776 Address Block always contains one address per route that is no longer 2777 valid, and each address has an associated prefix length. If a prefix 2778 length has not been included for this address, it is equal to the 2779 address length in bits. 2781 +------------------------------+------------------------------------+ 2782 | Data | Address Block | 2783 +------------------------------+------------------------------------+ 2784 | PktSource |
+ for | 2785 | | PktSource | 2786 | AddressList/PrefixLengthList |
+ for | 2787 | | each unreachable address in | 2788 | | AddressList | 2789 +------------------------------+------------------------------------+ 2791 8.4.4. Address Block TLV Block 2793 Address Block TLVs are always associated with one or more addresses 2794 in the Address Block. The following sections show the TLVs that 2795 apply to each type of address in the RERR. 2797 8.4.4.1. Address Block TLVs for PktSource 2799 +------------+---------------+-----------------+------------+ 2800 | Data | TLV Type | Extension Type | Value | 2801 +------------+---------------+-----------------+------------+ 2802 | PktSource | ADDRESS_TYPE | 0 | PKTSOURCE | 2803 +------------+---------------+-----------------+------------+ 2805 8.4.4.2. Address Block TLVs for Unreachable Addresses 2807 +----------------+--------------+------------+----------------------+ 2808 | Data | TLV Type | Extension | Value | 2809 | | | Type | | 2810 +----------------+--------------+------------+----------------------+ 2811 | None | ADDRESS_TYPE | 0 | UNREACHABLE | 2812 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2813 | | | | associated with | 2814 | | | | invalid route to the | 2815 | | | | unreachable address. | 2816 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2817 | | | | set to MetricType of | 2818 | | | | the route to the | 2819 | | | | unreachable address. | 2820 +----------------+--------------+------------+----------------------+ 2822 9. Simple External Network Attachment 2824 Figure 5 shows a stub (i.e., non-transit) network of AODVv2 routers 2825 which is attached to an external network (i.e., a network not using 2826 AODVv2) via a single External Network Access Router (ENAR). 2828 As in any externally-attached network, AODVv2 routers and Router 2829 Clients that wish to be reachable from the external network MUST have 2830 IP addresses within the ENAR's routable and topologically correct 2831 prefix (e.g., 191.0.2.0/24 in Figure 5). This AODVv2 network and 2832 networks attached to routers within it will be advertised to the 2833 external network using other routing protocols or procedures which 2834 are out of scope for this specification. 2836 /-------------------------\ 2837 / +----------------+ \ 2838 / | AODVv2 Router | \ 2839 | | 191.0.2.2/32 | | 2840 | +----------------+ | Routable 2841 | +-----+--------+ Prefix 2842 | | ENAR | /191.0.2.0/24 2843 | | AODVv2 Router| / 2844 | | 191.0.2.1 |/ /---------------\ 2845 | | serving net +------+ External \ 2846 | | 191.0.2.0/24 | \ Network / 2847 | +-----+--------+ \---------------/ 2848 | +----------------+ | 2849 | | AODVv2 Router | | 2850 | | 191.0.2.3/32 | | 2851 \ +----------------+ / 2852 \ / 2853 \-------------------------/ 2855 Figure 5: Simple External Network Attachment Example 2857 When an AODVv2 router within the AODVv2 MANET wants to discover a 2858 route toward an address on the external network, it uses the normal 2859 AODVv2 route discovery for that IP Destination Address. 2861 The ENAR MUST respond to RREQ on behalf of all external network 2862 destinations, that is, destinations which are not on the configured 2863 191.0.2.0 /24 network. The ENAR MUST NOT respond with a TargPrefix 2864 and TargPrefixLen which includes any of the networks configured as 2865 part of the AODVv2 network. Sending a Route Request for a gateway is 2866 not currently supported. 2868 If more than one gateway is configured to serve the same external 2869 network, each such gateway MUST configure that external network as a 2870 Router Client with its IP address as the value of SeqNoRtr for the 2871 RouterClient. AODVv2 messages SHOULD NOT be transmitted to routers 2872 in the External Network. 2874 RREQs for addresses inside the AODVv2 network, e.g. destinations on 2875 the configured 191.0.2.0/24 network, are handled using the standard 2876 processes described in Section 7. Note that AODVv2 does not 2877 currently support route discovery for prefixes that do not equal 2878 address length, but RREPs do advertise the prefix on which TargAddr 2879 resides. 2881 When an IP packet from an address on the external network destined 2882 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2883 not have a route toward that destination in its Routing Information 2884 Base, it will perform normal AODVv2 route discovery for that 2885 destination. 2887 Configuring the ENAR as a default router is outside the scope of this 2888 specification. 2890 10. Precursor Lists 2892 This section specifies an interoperable, optional enhancement to 2893 AODVv2 enabling more economical Route Error notifications. 2895 There can be several sources of traffic for a certain destination. 2896 Each source of traffic and each upstream router between the 2897 forwarding AODVv2 router and the traffic source is known as a 2898 "precursor" for the destination. For each destination, an AODVv2 2899 router MAY choose to keep track of precursors that have provided 2900 traffic for that destination. Route Error messages about that 2901 destination can then be sent unicast to these precursors instead of 2902 multicast to all AODVv2 routers. 2904 Since an RERR will be regenerated if it comes from a next hop on a 2905 valid LocalRoute, the RERR SHOULD ideally be sent backwards along the 2906 route that the source of the traffic uses, to ensure it is 2907 regenerated at each hop and reaches the traffic source. If the 2908 reverse path is unknown, the RERR SHOULD be sent toward the source 2909 along any available route. Therefore, the options for saving 2910 precursor information are as follows: 2912 o Save the next hop on an existing route to the IP packet's source 2913 address as the precursor. In this case, it is not guaranteed that 2914 an RERR that is sent will follow the reverse of the source's 2915 route. In rare situations, this may prevent the route from being 2916 invalidated at the source of the data traffic. 2918 o Save the IP packet's source address as the precursor. In this 2919 case, the RERR can be sent along any existing route to the source 2920 of the data traffic, and SHOULD include PktSource to ensure that 2921 the route will be invalidated at the source of the traffic, in 2922 case the RERR does not follow the reverse of the source's route. 2924 o By inspecting the MAC address of each forwarded IP packet, 2925 determine which router forwarded the packet, and save the router 2926 address as a precursor. This ensures that when an RERR is sent to 2927 the precursor router, the route will be invalidated at that 2928 router, and the RERR will be regenerated toward the source of the 2929 IP packet. 2931 During normal operation, each AODVv2 router maintaining precursor 2932 lists for a LocalRoute must update the precursor list whenever it 2933 uses this route to forward traffic to the destination. Precursors 2934 are classified as Active if traffic has recently been forwarded by 2935 the precursor. The precursor is marked with a timestamp to indicate 2936 the time it last forwarded traffic on this route. 2938 When an AODVv2 router detects that one or more LocalRoutes are 2939 broken, it MAY notify each Active precursor using a unicast Route 2940 Error message instead of creating multicast traffic. Unicast is 2941 applicable when there are few Active precursors compared to the 2942 number of neighboring AODVv2 routers. However, the default multicast 2943 behavior is still preferable when there are many precursors, since 2944 fewer message transmissions are required. 2946 When an AODVv2 router supporting precursor lists receives an RERR 2947 message, it SHOULD identify the list of its own affected Active 2948 precursors for the routes in the RERR, and choose to send a unicast 2949 RERR to those, rather than send a multicast RERR. 2951 When a LocalRoute is expunged, any precursor list associated with it 2952 MUST also be expunged. 2954 11. Application of RFC 7182 to AODVv2 2956 Implementations of AODVv2 MUST support ICV TLVs using type-extensions 2957 1 and 2, hash-function AES-CCM, and cryptographic function AES-CCM, 2958 both as defined in [RFC7251]. An ICV MUST be included with every 2959 message. The ICV value MAY be truncated as specified in [RFC7182]. 2961 Since the msg-hop-limit and PATH_METRIC values are mutable when 2962 included in AODVv2 messages, these values are set to zero before 2963 calculating an ICV. This means that these values are not protected 2964 end-to-end and are therefore susceptible to manipulation. This form 2965 of attack is described in Section 14.3.2. 2967 Implementations of AODVv2 MUST support a TIMESTAMP TLV using type- 2968 extension 0. The timestamp used is a sequence number, and therefore 2969 the length of the field matches the AODVv2 sequence 2970 number defined in Section 4.4. The TIMESTAMP TLV MUST be included in 2971 RREP_Ack and RERR messages. 2973 When more than one message is included in an RFC5444 packet, using a 2974 single ICV Packet TLV or single TIMESTAMP Packet TLV is more 2975 efficient than including ICV and TIMESTAMP Message TLVs in each 2976 message created. If the RFC5444 multiplexer is capable of adding the 2977 Packet TLVs, it SHOULD be instructed to include the Packet TLVs in 2978 packets containing AODVv2 messages. However, if the multiplexer is 2979 not capable of adding the Packet TLVs, the TLVs MUST be included as 2980 Message TLVs in each AODVv2 message in the packet. 2982 After message generation, but before transmission, the ICV and 2983 TIMESTAMP TLVs MUST be added according to each message type as 2984 detailed in the following sections. The following steps list the 2985 procedure to be performed: 2987 1. If the TIMESTAMP is to be included, depending on AODVv2 message 2988 type as specified below, add the TIMESTAMP TLV. 2990 * When a TIMESTAMP Packet TLV is being added, the Packet TLV 2991 Block size field MUST be updated. 2993 * When a TIMESTAMP Message TLV is being added, the Message TLV 2994 Block size field MUST be updated. 2996 2. The considerations in Section 8 and section 9 of [RFC7182] are 2997 followed, removing existing ICV TLVs and adjusting the size and 2998 flags fields as appropriate: 3000 * When an ICV Packet TLV is being added, existing ICV Packet 3001 TLVs MUST be removed and the Packet TLV Block size MUST be 3002 updated. If the Packet TLV Block now contains no TLVs, the 3003 phastlv bit in the field in the Packet Header MUST 3004 be cleared. 3006 * When an ICV Message TLV is being added, existing ICV Message 3007 TLVs are removed and the Message TLV Block Size MUST be 3008 updated. 3010 3. Mutable fields in the message must have their mutable values set 3011 to zero before calculating the ICV. 3013 * If the msg-hop-limit field is included in the [RFC5444] 3014 message header, msg-hop-limit MUST be set to zero before 3015 calculating the ICV. 3017 * If a PATH_METRIC TLV is included, any values present in the 3018 TLV MUST be set to zero before calculating the ICV value. 3020 4. Depending on the message type, the ICV is calculated over the 3021 appropriate fields (as specified in sections Section 11.1, 3022 Section 11.2, Section 11.3 and Section 11.4) to include the 3023 fields , , , and, if present, (in that order), followed by 3025 the entire packet or message. This value MAY be truncated (as 3026 specified in [RFC7182]). 3028 5. Add the ICV TLV, updating size fields as necessary. 3030 6. The changes made in Step 2 and Step 3 are reversed to re-add any 3031 existing ICV TLVs, re-adjust the relevant size and flags fields, 3032 and set the msg-hop-limit and PATH_METRIC TLV values. 3034 On message reception, and before message processing, verification of 3035 the received message MUST take place: 3037 1. The considerations in Section 8 and Section 9 of [RFC7182] are 3038 followed, removing existing ICV TLVs and adjusting the size and 3039 flags fields as appropriate. 3041 * When verifying the ICV value in an ICV Packet TLV, all ICV 3042 Packet TLVs present in the Packet TLV Block MUST be removed 3043 before calculating the ICV, and the Packet TLV Block size MUST 3044 be updated. If there are no remaining Packet TLVs, the Packet 3045 TLV Block MUST be removed and the phastlv bit in the field MUST be cleared. 3048 * When verifying the ICV value in an ICV Message TLV, all ICV 3049 Message TLVs present in the Message TLV Block MUST be removed 3050 before calculating the ICV, and the Message TLV Block size 3051 MUST be updated. 3053 2. Mutable fields in the message MUST have their mutable values set 3054 to zero before calculating the ICV. 3056 * If the msg-hop-limit field is included in the [RFC5444] 3057 message header, msg-hop-limit MUST be set to zero before 3058 calculating the ICV. 3060 * If a PATH_METRIC TLV is included, any values present in the 3061 TLV MUST be set to zero before calculating the ICV value. 3063 3. The ICV is calculated following the considerations in 3064 Section 12.2 of [RFC7182], to include the fields , 3065 , , and, if present, (in that order), followed by the entire packet or message. 3068 * If the received ICV value is truncated, the calculated ICV 3069 value MUST also be truncated (as specified in [RFC7182]), 3070 before comparing. 3072 * If the ICV value calculated from the received message or 3073 packet does not match the value of in the received 3074 message or packet, the validation fails and the AODVv2 message 3075 MUST be discarded and NOT processed or forwarded. 3077 * If the ICV values do match, the values set to zero before 3078 calculating the ICV are reset to the received values, and 3079 processing continues to Step 4. 3081 4. Verification of a received TIMESTAMP value MUST be performed. 3082 The procedure depends on message type as specified in the 3083 following sub sections. 3085 * If the TIMESTAMP value in the received message is not valid, 3086 the AODVv2 message MUST be discarded and NOT processed or 3087 forwarded. 3089 * If the TIMESTAMP value is valid, processing continues as 3090 defined in Section 7. 3092 11.1. RREQ Generation and Reception 3094 Since OrigPrefix is included in the RREQ, the ICV can be calculated 3095 and verified using the [RFC5444] contents.The ICV TLV has type 3096 extension := 1. Inclusion of an ICV TLV message integrity and 3097 endpoint authentication, because trusted routers MUST hold the shared 3098 key in order to calculate the ICV value, both to include when 3099 creating a message, and to validate the message by checking that the 3100 ICV is correct. 3102 Since RREQ_Gen's sequence number is incremented for each new RREQ, 3103 replay protection is already afforded and no extra TIMESTAMP TLV is 3104 required. 3106 After message generation and before message transmission: 3108 1. Add the ICV TLV as described above. 3110 On message reception and before message processing: 3112 1. Verify the received ICV value as described above. 3114 2. Verification of the sequence number is handled according to 3115 Section 7. 3117 11.2. RREP Generation and Reception 3119 Since TargPrefix is included in the RREP, the ICV can be calculated 3120 and verified using the [RFC5444] contents. The ICV TLV has type 3121 extension 1. Inclusion of an ICV provides message integrity and 3122 endpoint authentication, because trusted routers MUST hold a valid 3123 key in order to calculate the ICV value, both to include when 3124 creating a message, and to validate the message by checking that the 3125 ICV is correct. 3127 Since RREP_Gen's sequence number is incremented for each new RREP, 3128 replay protection is already afforded and no extra TIMESTAMP TLV is 3129 required. 3131 After message generation and before message transmission: 3133 1. Add the ICV TLV as described above. 3135 On message reception and before message processing: 3137 1. Verify the received ICV value as described above. 3139 2. Verification of the sequence number is handled according to 3140 Section 7. 3142 11.3. RREP_Ack Generation and Reception 3144 Since no sequence number is included in the RREP_Ack, a TIMESTAMP TLV 3145 MUST be included to protect against replay attacks. The value in the 3146 TIMESTAMP TLV is set as follows: 3148 o For RREP_Ack request, use Neighbor.AckSeqNum. 3150 o For RREP_Ack response, use the sequence number from the TIMESTAMP 3151 TLV in the received RREP_Ack request. 3153 Since no addresses are included in the RREP_Ack, and the receiver of 3154 the RREP_Ack uses the source IP address of a received RREP_Ack to 3155 identify the sender, the ICV MUST be calculated using the message 3156 contents and the IP source address. The ICV TLV has type extension 3157 := 2 in order to accomplish this. This provides message integrity 3158 and endpoint authentication, because trusted routers MUST hold the 3159 correct key in order to calculate the ICV value. 3161 After message generation and before message transmission: 3163 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3165 On message reception and before message processing: 3167 1. Verify the received ICV value as described above. 3169 2. Verify the received TIMESTAMP value by comparing the sequence 3170 number in the value field of the TIMESTAMP TLV as follows: 3172 * For a received RREP_Ack request, there is no need to verify 3173 the timestamp value. Proceed to message processing as defined 3174 in Section 7. 3176 * For a received RREP_Ack response, compare with the 3177 Neighbor.AckSeqNum of the Neighbor Set entry for sender of the 3178 RREP_Ack request. 3180 * If the sequence number does not match, the AODVv2 message MUST 3181 be discarded. Otherwise, Neighbor.AckSeqNum is incremented by 3182 1 and processing continues according to Section 7. 3184 11.4. RERR Generation and Reception 3186 Since the sender's sequence number is not contained in the RERR, a 3187 TIMESTAMP TLV MUST be included to protect against replay attacks. 3188 The value in the TIMESTAMP TLV is set by incrementing and using 3189 RERR_Gen's sequence number. 3191 Since the receiver of the RERR MUST use the source IP address of the 3192 RERR to identify the sender, the ICV MUST be calculated using the 3193 message contents and the IP source address. The ICV TLV has type 3194 extension := 2 in order to accomplish this. This provides message 3195 integrity and endpoint authentication, because trusted routers MUST 3196 hold the shared key in order to calculate the ICV value. 3198 After message generation and before message transmission: 3200 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3202 On message reception and before message processing: 3204 1. Verify the received ICV value as described above. 3206 2. Verify the received TIMESTAMP value by comparing the sequence 3207 number in the value field of the TIMESTAMP TLV with the 3208 Neighbor.HeardRERRSeqNum. If the sequence number in the message 3209 is lower than the stored value, the AODVv2 message MUST be 3210 discarded. Otherwise, the Neighbor.HeardRERRSeqNum MUST be set 3211 to the received value and processing continues according to 3212 Section 7. 3214 12. Configuration 3216 AODVv2 uses various parameters which can be grouped into the 3217 following categories: 3219 o Timers 3220 o Protocol constants 3222 o Administrative parameters and controls 3224 This section show the parameters along with their definitions and 3225 default values (if any). 3227 Note that several fields have limited size (bits or bytes). These 3228 sizes and their encoding may place specific limitations on the values 3229 that can be set. 3231 12.1. Timers 3233 AODVv2 requires certain timing information to be associated with 3234 Local Route Set entries and message replies. The default values are 3235 as follows: 3237 +------------------------+----------------+ 3238 | Name | Default Value | 3239 +------------------------+----------------+ 3240 | ACTIVE_INTERVAL | 5 second | 3241 | MAX_IDLETIME | 200 seconds | 3242 | MAX_BLACKLIST_TIME | 200 seconds | 3243 | MAX_SEQNUM_LIFETIME | 300 seconds | 3244 | RERR_TIMEOUT | 3 seconds | 3245 | RteMsg_ENTRY_TIME | 12 seconds | 3246 | RREQ_WAIT_TIME | 2 seconds | 3247 | RREP_Ack_SENT_TIMEOUT | 1 second | 3248 | RREQ_HOLDDOWN_TIME | 10 seconds | 3249 +------------------------+----------------+ 3251 Table 2: Timing Parameter Values 3253 The above timing parameter values have worked well for small and 3254 medium well-connected networks with moderate topology changes. The 3255 timing parameters SHOULD be administratively configurable. Ideally, 3256 for networks with frequent topology changes the AODVv2 parameters 3257 SHOULD be adjusted using experimentally determined values or dynamic 3258 adaptation. For example, in networks with infrequent topology 3259 changes MAX_IDLETIME MAY be set to a much larger value. If the 3260 values were configured differently, the following consequences may be 3261 observed: 3263 o If MAX_SEQNUM_LIFETIME was configured differently across the 3264 network, and any of the routers lost their sequence number or 3265 rebooted, this could result in their next route messages being 3266 classified as stale at any AODVv2 router using a greater value for 3267 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to 3268 the re-initializing router. 3270 o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will 3271 invalidate routes more quickly and free resources used to maintain 3272 them. This can affect bursty traffic flows which have quiet 3273 periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which 3274 has timed out due to perceived inactivity is not reported. When 3275 the bursty traffic resumes, it would cause a RERR to be generated, 3276 and the traffic itself would be dropped. This route would be 3277 removed from all upstream routers, even if those upstream routers 3278 had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route 3279 discovery would be required to re-establish the route, causing 3280 extra routing protocol traffic and disturbance to the bursty 3281 traffic. 3283 o Routers with lower values for MAX_BLACKLIST_TIME would allow 3284 neighboring routers to participate in route discovery sooner than 3285 routers with higher values. This could result in failed route 3286 discoveries if un-blacklisted links are still uni-directional. 3287 Since RREQs are retried, this would not affect success of route 3288 discovery unless this value was so small as to un-blacklist the 3289 router before the RREQ is retried. This value need not be 3290 consistent across the network since it is used for maintaining a 3291 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME; 3292 the default value is much larger. 3294 o Routers with lower values for RERR_TIMEOUT may create more RERR 3295 messages than routers with higher values. This value should be 3296 large enough that a RERR will reach all routers using the route 3297 reported within it before the timer expires, so that no further 3298 data traffic will arrive, and no duplicated RERR messages will be 3299 generated. 3301 o Routers with lower values for RteMsg_ENTRY_TIME may not consider 3302 received redundant multicast route messages as redundant, and may 3303 forward these messages unnecessarily. 3305 o Routers with lower values for RREQ_WAIT_TIME may send more 3306 frequent RREQ messages and wrongly determine that a route does not 3307 exist, if the delay in receiving an RREP is greater than this 3308 interval. 3310 o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly 3311 determine links to neighbors to be unidirectional if an RREP_Ack 3312 is delayed longer than this timeout. 3314 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed 3315 route discoveries sooner than routers with higher values. This 3316 may be an advantage if the network topology is frequently 3317 changing, or may unnecessarily cause more routing protocol 3318 traffic. 3320 MAX_SEQNUM_LIFETIME MUST be configured to have the same values for 3321 all AODVv2 routers in the network. 3323 12.2. Protocol Constants 3325 AODVv2 protocol constants typically do not require changes. The 3326 following table lists these constants, along with their values and a 3327 reference to the section describing their use. 3329 +------------------------+-------------+----------------------------+ 3330 | Name | Default | Description | 3331 +------------------------+-------------+----------------------------+ 3332 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 3333 | RREP_RETRIES | 2 | Section 7.2.1 | 3334 | MAX_METRIC[MetricType] | [see below] | Section 5 | 3335 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 3336 | MAX_HOPCOUNT | 20 | Limit to number of hops an | 3337 | | | RREQ or RREP message can | 3338 | | | traverse | 3339 | INFINITY_TIME | [see below] | Maximum expressible clock | 3340 | | | time (Section 6.7.2) | 3341 +------------------------+-------------+----------------------------+ 3343 Table 3: AODVv2 Constants 3345 MAX_HOPCOUNT cannot be larger than 255. 3347 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 3348 value of type MetricType. Field lengths associated with metric 3349 values are found in Section 13.4. 3351 These protocol constants MUST have the same values for all AODVv2 3352 routers in the ad hoc network. If the values were configured 3353 differently, the following consequences may be observed: 3355 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 3356 be more successful at finding routes, at the cost of additional 3357 control traffic. 3359 o RREP_RETRIES: Routers with lower values are more likely to 3360 blacklist neighbors when there is a temporary fluctuation in link 3361 quality. 3363 o MAX_METRIC[MetricType]: No interoperability problems due to 3364 variations on different routers, but routers with lower values may 3365 exhibit overly restrictive behavior during route comparisons. 3367 o MAX_HOPCOUNT: Routers with a value too small would not be able to 3368 discover routes to distant addresses. 3370 o INFINITY_TIME: No interoperability problems due to variations on 3371 different routers, but if a lower value is used, route state 3372 management may exhibit overly restrictive behavior. 3374 12.3. Local Settings 3376 The following table lists AODVv2 parameters which SHOULD be 3377 administratively configured for each router: 3379 +------------------------+---------------------------+--------------+ 3380 | Name | Default Value | Description | 3381 +------------------------+---------------------------+--------------+ 3382 | Interface Set | | Section 4.1 | 3383 | Router Client Set | | Section 4.2 | 3384 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 3385 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 3386 | CONTROL_TRAFFIC_LIMIT | [Adjust for 10% capacity] | Section 7 | 3387 +------------------------+---------------------------+--------------+ 3389 Table 4: Configuration for Local Settings 3391 12.4. Network-Wide Settings 3393 The following administrative controls MAY be used to change the 3394 operation of the network. The same settings SHOULD be used across 3395 the network. Inconsistent settings at different routers in the 3396 network will not result in protocol errors. 3398 +----------------------+-----------+----------------+ 3399 | Name | Default | Description | 3400 +----------------------+-----------+----------------+ 3401 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 3402 +----------------------+-----------+----------------+ 3404 Table 5: Configuration for Network-Wide Settings 3406 13. IANA Considerations 3408 This section specifies several [RFC5444] message types and address 3409 tlv-types required for AODVv2, as well as a new Code value for ICMP 3410 Destination Unreachable. 3412 13.1. RFC 5444 Message Type Allocation 3414 This specification defines four Message Types, to be allocated from 3415 the 0-223 range of the "Message Types" namespace defined in 3416 [RFC5444]. 3418 +-----------------------------------------+-----------+ 3419 | Name of Message | Type | 3420 +-----------------------------------------+-----------+ 3421 | Route Request (RREQ) | 10 (TBD) | 3422 | Route Reply (RREP) | 11 (TBD) | 3423 | Route Error (RERR) | 12 (TBD) | 3424 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 3425 +-----------------------------------------+-----------+ 3427 13.2. RFC 5444 Message TLV Types 3429 This specification defines one Message TLV Type, to be allocated from 3430 the Message-Type-specific "Message TLV Types" namespace defined in 3431 [RFC5444], as specified in Table 6. 3433 +------------------------+----------+---------------+---------------+ 3434 | Name of TLV | Type | Length | Reference | 3435 | | | (octets) | | 3436 +------------------------+----------+---------------+---------------+ 3437 | ACK_REQ | 128 | 0 | Section 6.2 | 3438 | | (TBD) | | | 3439 +------------------------+----------+---------------+---------------+ 3441 Table 6: AODVv2 Message TLV Types 3443 13.3. RFC 5444 Address Block TLV Type Allocation 3445 This specification defines three Address Block TLV Types, to be 3446 allocated from the Message-Type-specific "Address Block TLV Types" 3447 namespace defined in [RFC5444], as specified in Table 7. 3449 +------------------------+----------+---------------+---------------+ 3450 | Name of TLV | Type | Length | Reference | 3451 | | | (octets) | | 3452 +------------------------+----------+---------------+---------------+ 3453 | PATH_METRIC | 129 | depends on | Section 7 | 3454 | | (TBD) | MetricType | | 3455 | SEQ_NUM | 130 | 2 | Section 7 | 3456 | | (TBD) | | | 3457 | ADDRESS_TYPE | 131 | 1 | Section 8 | 3458 | | (TBD) | | | 3459 +------------------------+----------+---------------+---------------+ 3461 Table 7: AODVv2 Address Block TLV Types 3463 13.4. MetricType Allocation 3465 The metric types used by AODVv2 are identified according to Table 8. 3466 All implementations MUST use these values. 3468 +---------------------+----------+--------------------+ 3469 | Name of MetricType | Type | Metric Value Size | 3470 +---------------------+----------+--------------------+ 3471 | Unassigned | 0 | Undefined | 3472 | Hop Count | 1 | 1 octet | 3473 | Unallocated | 2 - 254 | TBD | 3474 | Reserved | 255 | Undefined | 3475 +---------------------+----------+--------------------+ 3477 Table 8: AODVv2 Metric Types 3479 13.5. ADDRESS_TYPE TLV Values 3481 These values are used in the [RFC5444] Address Type TLV discussed in 3482 Section 8. All implementations MUST use these values. 3484 +---------------+--------+ 3485 | Address Type | Value | 3486 +---------------+--------+ 3487 | ORIGPREFIX | 0 | 3488 | TARGPREFIX | 1 | 3489 | UNREACHABLE | 2 | 3490 | PKTSOURCE | 3 | 3491 | UNSPECIFIED | 255 | 3492 +---------------+--------+ 3494 Table 9: AODVv2 Address Types 3496 13.6. ICMPv6 Code Field for ICMP Destination Unreachable 3498 A new Code Value is defined for ICMP Destination Unreachable messages 3499 (see Section 7.1.2). 3501 +-----------------------+----------+ 3502 | Code Value | Value | 3503 +-----------------------+----------+ 3504 | Metric Type Mismatch | 8 (TBD) | 3505 +-----------------------+----------+ 3507 Table 10: AODVv2 ICMPv6 Code Field value 3509 14. Security Considerations 3511 This section describes various security considerations and potential 3512 avenues to secure AODVv2 routing. The main objective of the AODVv2 3513 protocol is for each router to communicate reachability information 3514 about addresses for which it is responsible, and for routes it has 3515 discovered from other AODVv2 routers. 3517 Networks using AODVv2 to maintain connectivity and establish routes 3518 on demand may be vulnerable to certain well-known types of threats, 3519 which will be detailed in this section. Some of the threats 3520 described can be mitigated or eliminated. Tools to do so will be 3521 described. 3523 With the exception of metric values, AODVv2 assures the integrity of 3524 all RteMsg data end-to-end though the use of ICVs (see 3525 Section 14.4.2. AODVv2 implementations support ICV and TIMESTAMP 3526 TLVs, unless the implementation is intended for an environment in 3527 which security is unnecessary; otherwise, AODVv2 deployments are 3528 configured to use these TLVs to secure messages. 3530 The on-demand nature of AODVv2 route discovery automatically reduces 3531 the vulnerability to route disruption. Since control traffic for 3532 updating route tables is diminished, there is less opportunity for 3533 attack and failure. 3535 14.1. Availability 3537 Threats to AODVv2 which reduce availability are considered below. 3539 14.1.1. Denial of Service 3541 Flooding attacks using RREQ amount to a (BLIND) denial of service for 3542 route discovery: By issuing RREQ messages for targets that don't 3543 exist, an attacker can flood the network, blocking resources and 3544 drowning out legitimate traffic. By triggering the generation of 3545 CONTROL_TRAFFIC_LIMIT amount of messages (for example by sending 3546 RREQs for many non-existent destinations), an attacker can prevent 3547 legitimate messages from being generated. The effect of this attack 3548 is dampened by the fact that duplicate RREQ messages are dropped 3549 (preventing the network from DDoSing itself). Processing 3550 requirements for AODVv2 messages are typically quite small, however 3551 AODVv2 routers receiving RREQs do allocate resources in the form of 3552 Neighbor Set, Local Route Set and Multicast Route Message Set 3553 entries. The attacker can maximize their impact on set growth by 3554 changing OrigPrefix or OrigPrefixLen for each RREQ. If a specific 3555 node is to be targeted, this attack may be carried out in a 3556 DISTRIBUTED fashion, either by compromising its direct neighbors or 3557 by specifying the target's address with TargPrefix and TargPrefixLen. 3558 Note that it might be more economical for the attacker to simply jam 3559 the medium; an attack which AODVv2 cannot defend itself against. 3561 Mitigation: 3563 o If AODVv2 routers always verify that the sender of the RERR 3564 message is trusted, this threat is reduced. Processing 3565 requirements would typically be dominated by calculations to 3566 verify integrity. This has the effect of reducing (but by no 3567 means eliminating) AODVv2's vulnerability to denial of service 3568 attacks. 3570 o Authentication of senders can prevent unauthenticated routers from 3571 launching a Denial of Service attack on another AODVv2 router. 3572 However, this does not protect the network if an attacker has 3573 access to an already authenticated router. 3575 14.1.2. Malicious RERR messages 3577 RERR messages are designed to cause removal of installed routes. A 3578 malicious node could send an RERR message with false information to 3579 attempt to get other routers to remove a route to one or more 3580 specific destinations, therefore disrupting traffic to the advertised 3581 destinations. 3583 Routes will be deleted if an RERR is received, withdrawing a route 3584 for which the sender is the receiver's next hop, if both of the 3585 following conditions are met: 3587 o the RERR includes the MetricType of the installed route, 3589 o the RERR includes either no sequence number for the route, or 3590 includes a greater sequence number than the sequence number stored 3591 with that route in the receiver's Local Route Set. 3593 Routes will also be deleted if a received RERR contains a PktSource 3594 address corresponding to a Router Client. 3596 The information necessary to construct a malicious RERR could be 3597 discovered by eavesdropping, either by listening to AODVv2 messages 3598 or by watching data packet flows. 3600 When the RERR is multicast, it can be received by many routers in the 3601 ad hoc network, and will be regenerated when processing results in an 3602 active route being removed. This threat could have serious impact on 3603 applications communicating by way of the sender of the RERR message. 3605 o The set of routers which use the malicious router as a next hop 3606 may be targeted with a malicious RERR with no PktSource address 3607 included, if the RERR contains routes for which the malicious 3608 router is a next hop from the receiving router. However, since 3609 the sender of the RERR message is either malicious or broken, it 3610 is better that it is not used as a next hop for these routes 3611 anyway. 3613 o A single router which does not use the malicious router as part of 3614 its route may be targeted with a malicious RERR with a PktSource 3615 address included. 3617 o Replayed RERR messages could be used to disrupt active routes. 3619 Mitigation: 3621 o Protection against eavesdropping of AODVv2 messages would mitigate 3622 this attack to some extent, but eavesdropping of data packets can 3623 also be used to deduce the information about which routes could be 3624 targeted. 3626 o Protection against a malicious router becoming part of a route 3627 will mitigate the attack where a set of routers are targeted. 3628 This will not protect against the attack if a PktSource address is 3629 included. 3631 o By only regenerating RERR messages where active routes are 3632 removed, the spread of the malicious RERR is limited. 3634 o Including sequence numbers in RERR messages offers protection 3635 against attacks using replays of these RERR messages. 3637 o If AODVv2 routers always verify that the sender of the RERR 3638 message is trusted, this threat is reduced. 3640 14.1.3. False Confirmation of Link Bidirectionality 3642 Links could be erroneously treated as bidirectional if malicious 3643 unsolicited or spoofed RREP messages were to be accepted. This would 3644 result in a route being installed which could not in fact be used to 3645 forward data to the destination, and may divert data packets away 3646 from the intended destination. 3648 There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which 3649 any malicious router could send an RREP in response, in order for the 3650 link to the malicious router to be deemed as bidirectional. 3652 Mitigation: 3654 o Ignoring unsolicited RREP and RREP_Ack messages partially 3655 mitigates against this threat. 3657 o If AODVv2 routers always verify that the sender of the RREP 3658 message is trusted, this threat is reduced. 3660 14.1.4. Message Deletion 3662 A malicious router could decide not to forward an RREQ or RREP or 3663 RERR message. Not forwarding a RERR or RREP message would disrupt 3664 route discovery. Not regenerating a RERR message would result in the 3665 source of data packets continuing to maintain and use the route, and 3666 further RERR messages being generated by the sender of the non- 3667 regenerated RERR. A malicious router could intentionally disrupt 3668 traffic flows by not allowing the source of data traffic to re- 3669 discover a new route when one breaks. 3671 Failing to send an RREP_Ack would also disrupt route establishment, 3672 by not allowing the reverse route to be validated. Return traffic 3673 which needs that route will prompt a new route discovery, wasting 3674 resources and incurring a slight delay but not disrupting the ability 3675 for applications to communicate. 3677 Mitigation: 3679 o None. Note that malicious router would have to wait for a route 3680 to break before it could perform this attack. 3682 14.2. Confidentiality 3684 Passive inspection (eavesdropping) of AODVv2 control messages could 3685 enable unauthorized devices to gain information about the network 3686 topology, since exchanging such information is the main purpose of 3687 AODVv2. 3689 Eavesdropping of data traffic could allow a malicious device to 3690 obtain information about how data traffic is being routed. With 3691 knowledge of source and destination addresses, malicious messages 3692 could be constructed to disrupt normal operation. 3694 14.3. Integrity of Routes 3696 Integrity of route information can be compromised in the following 3697 types of attack: 3699 14.3.1. Message Insertion 3701 Valid route set entries can be replaced or modified by maliciously 3702 constructed AODVv2 messages, destroying existing routes and the 3703 network's integrity. Any router may pose as another router by 3704 sending RREQ, RREP, RREP_Ack and RERR messages in its name. 3706 o Sending an RREQ message with false information can disrupt traffic 3707 to OrigPrefix, if the sequence number attached is not stale 3708 compared to any existing information about OrigPrefix. Since RREQ 3709 is multicast and likely to be received by all routers in the ad 3710 hoc network, this threat could have serious impact on applications 3711 communicating with OrigPrefix. 3713 o The actual threat to disrupt routes to OrigPrefix is reduced by 3714 the AODVv2 mechanism of marking RREQ-derived routes as 3715 "Unconfirmed" until the route to OrigAddr can be confirmed. 3717 o Sending an RREP message with false information can disrupt traffic 3718 to TargPrefix. Since RREP is unicast, and ignored if a 3719 corresponding RREQ was not recently sent, this threat is 3720 minimized, and is restricted to receivers along the path from 3721 OrigAddr to TargAddr. 3723 o Sending an RREP_Ack response message with false information can 3724 cause the route to an originator address to be erroneously 3725 accepted even though the route would contain a unidirectional link 3726 and thus not be suitable for most traffic. Since the RREP_Ack 3727 response is unicast, and ignored if an RREP_Ack was not sent 3728 recently to the sender of this RREP_Ack response, this threat is 3729 minimized and is strictly local to the RREP transmitter expecting 3730 the acknowledgement. Unsolicited RREP_Acks are ignored. 3732 o Sending an RERR message with false information is discussed in 3733 Section 14.1.2. 3735 Mitigation: 3737 o If AODVv2 routers always verify that the sender of a message is 3738 trusted, this threat is reduced. 3740 14.3.2. Message Modification - Man in the Middle 3742 Any AODVv2 router can forward messages with modified data. 3744 Mitigation: 3746 o If AODVv2 routers verify the integrity of AODVv2 messages, then 3747 the threat of disruption is minimized. A man in the middle with 3748 no knowledge of the key used to calculate an integrity check value 3749 may modify a message but the message will be rejected when it 3750 fails an integrity check. 3752 14.3.3. Replay Attacks 3754 Replaying of RREQ or RREP messages would be of less use to an 3755 attacker, since they would be dropped immediately due to their stale 3756 sequence number. RERR messages may or may not include sequence 3757 numbers and are therefore susceptible to replay attacks. RREP_Ack 3758 messages do not include sequence numbers and are therefore 3759 susceptible to replay attacks. 3761 Mitigation: 3763 o Use of timestamps or sequence numbers prevents replay attacks. 3765 14.4. Protection Mechanisms 3767 14.4.1. Confidentiality and Authentication 3769 Encryption MAY be used for AODVv2 messages. If the routers share a 3770 packet-level security association, the message data can be encrypted 3771 prior to message transmission. The establishment of such security 3772 associations is outside the scope of this specification. Encryption 3773 will not only protect against unauthorized devices obtaining 3774 information about network topology (eavesdropping) but will ensure 3775 that only trusted routers participate in routing operations. 3777 14.4.2. Message Integrity using ICVs 3779 Cryptographic Integrity Check Values (ICVs) can be used to ensure 3780 integrity of received messages, protecting against man in the middle 3781 attacks. Further, by using ICVs, only those routers with knowledge 3782 of a shared secret key are allowed to participate in routing 3783 information exchanges. [RFC7182] defines ICV TLVs for use with 3784 [RFC5444]. 3786 The data contained in AODVv2 routing protocol messages MUST be 3787 verified using Integrity Check Values, to avoid accepting tampered 3788 messages. 3790 14.4.3. Replay Protection using Timestamps 3792 [RFC7182] defines a TIMESTAMP TLV for use with [RFC5444] which can be 3793 used to prevent replay attacks when sequence numbers are not already 3794 included. 3796 The data contained in AODVv2 routing protocol messages can be 3797 protected with a TIMESTAMP value to ensure the protection against 3798 replaying of the message. Sequence numbers can be used in place of 3799 timestamps, since they are known to be strictly increasing. 3801 14.5. Key Management 3803 The method of distribution of shared secret keys is out of the scope 3804 of this protocol. Key management is not specified for the following 3805 reasons: 3807 Against [RFC4107], an analysis as to whether automated or manual key 3808 management should be used shows a compelling case for automated 3809 management. In particular: 3811 o a potentially large number of routers may have to be managed, 3812 belonging to several organisations, for example in vehicular 3813 applications. 3815 o a stream cipher is likely to be used, such as an AES variant. 3817 o long term session keys might be used by more than two parties, 3818 including multicast operations. AODVv2 makes extensive use of 3819 multicast. 3821 o there may be frequent turnover of devices. 3823 On reviewing the case for manual key management against the same 3824 document, it can be seen that manual management might be advantageous 3825 in environments with limited bandwidth or high round trip times. 3826 AODVv2 lends itself to sparse ad hoc networks where transmission 3827 conditions may indeed be limited, depending on the bearers selected 3828 for use. 3830 However, [RFC4107] assumes that the connectivity between endpoints is 3831 already available. In AODVv2, no route is available to a given 3832 destination until a router client requests that user traffic be 3833 transmitted. It is required to secure the signalling path of the 3834 routing protocol that will establish the path across which key 3835 exchange functions might subsequently be applied, which is clearly 3836 the reverse of the expected functionality. A different strategy is 3837 therefore required. 3839 There are two possible solutions. In each case, it is assumed that a 3840 defence in depth security posture is being adopted by the system 3841 integrator, such that each function in the network as a whole is 3842 appropriately secured or defended as necessary, and that there is not 3843 complete reliance on security mechanisms built in to AODVv2. Such 3844 additional mechanisms could include a suitable wireless device 3845 security technology, so that wireless devices are authenticated and 3846 secured by their peers prior to exchanging user data, which in this 3847 case would include AODVV2 signalling traffic as a payload, and 3848 mechanisms which verify the authenticity and/or integrity of 3849 application-layer user data transported once a route has been 3850 established. 3852 1. In the case that no AODVv2 routers have any detailed prior 3853 knowledge of any other AODVv2 router, but does have knowledge of 3854 the credentials of other organisations in which the router has 3855 been previously configured to trust, it is possible for an AODVv2 3856 router to send an initialisation vector as part of an exchange, 3857 which could be verified against such credentials. Such an 3858 exchange could make use of Identity-Based Signatures 3859 ([I-D.ietf-manet-ibs]), based on Elliptic Curve-Based 3860 Certificateless Signatures for Identity-Based Encryption 3861 [RFC6507], which eliminate the need for a handshake process to 3862 establish trust. 3864 2. If it is impossible to use Identity-Based Signatures, and the 3865 risk to the AODVv2 signalling traffic is considered to be low due 3866 to the use of security countermeasures elsewhere in the system, a 3867 simple pre-placed shared secret could be used between routers, 3868 which is used as-is or is used to generate some ephemeral secret 3869 based on another known variable, such as time of day if that is 3870 universally available at a level of accuracy sufficient to make 3871 such a system viable. 3873 15. Acknowledgments 3875 AODVv2 is a descendant of the design of previous MANET on-demand 3876 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3877 previous MANET on-demand protocols stem from research and 3878 implementation experiences. Thanks to Elizabeth Belding and Ian 3879 Chakeres for their long time authorship of AODV. Additional thanks 3880 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3881 Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, Ulrich Herberg, 3882 Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, Lars Kristensen, 3883 Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, Keyur Patel, 3884 Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro Ruiz, 3885 Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi, Seung 3886 Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2 and 3887 DYMO, as well as numerous specification suggestions. 3889 16. References 3891 16.1. Normative References 3893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3894 Requirement Levels", BCP 14, RFC 2119, 3895 DOI 10.17487/RFC2119, March 1997, 3896 . 3898 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3899 Demand Distance Vector (AODV) Routing", RFC 3561, 3900 DOI 10.17487/RFC3561, July 2003, 3901 . 3903 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 3904 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 3905 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 3906 . 3908 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 3909 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 3910 2009, . 3912 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 3913 Check Value and Timestamp TLV Definitions for Mobile Ad 3914 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 3915 April 2014, . 3917 16.2. Informative References 3919 [I-D.ietf-manet-ibs] 3920 Dearlove, C., "Identity-Based Signatures for MANET Routing 3921 Protocols", draft-ietf-manet-ibs-05 (work in progress), 3922 March 2016. 3924 [I-D.ietf-roll-aodv-rpl] 3925 Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. 3926 Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 3927 Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in 3928 progress), September 2017. 3930 [Koodli01] 3931 Koodli, R. and C. Perkins, "Fast handovers and context 3932 transfers in mobile networks", Proceedings of the ACM 3933 SIGCOMM Computer Communication Review 2001, Volume 31 3934 Issue 5, 37-47, October 2001. 3936 [Perkins94] 3937 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 3938 Sequenced Distance-Vector Routing (DSDV) for Mobile 3939 Computers", Proceedings of the ACM SIGCOMM '94 Conference 3940 on Communications Architectures, Protocols and 3941 Applications, London, UK, pp. 234-244, August 1994. 3943 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 3944 (MANET): Routing Protocol Performance Issues and 3945 Evaluation Considerations", RFC 2501, 3946 DOI 10.17487/RFC2501, January 1999, 3947 . 3949 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 3950 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 3951 June 2005, . 3953 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3954 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3955 . 3957 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 3958 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 3959 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 3960 . 3962 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 3963 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 3964 RFC 6130, DOI 10.17487/RFC6130, April 2011, 3965 . 3967 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 3968 Signatures for Identity-Based Encryption (ECCSI)", 3969 RFC 6507, DOI 10.17487/RFC6507, February 2012, 3970 . 3972 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 3973 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 3974 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 3975 . 3977 Appendix A. Most Recent AODVv2 Draft Updates 3979 This section lists the changes between recent AODVv2 revisions 3980 ...-01.txt and ...-02.txt. 3982 o Changed notation for entries in Multicast Route Message table from 3983 RteMsg to McMsg {for Multicast Message} (see Table 1, Section 4.6, 3984 and Section 6.8). 3986 o Sharpened description of suppressing multicast messages to apply 3987 only to RREQs (see Section 6.8). 3989 o Supplied AES-CCM as the default choice for HASH_FUNCTION and 3990 CRYPTOGRAPHIC_FUNCTION (see Section 11). 3992 o Changed the names of the Neighbor.State to be capitalized: 3993 CONFIRMED, HEARD, and BLACKLISTED (see Section 4.3). 3995 o Created a new Code field value for ICMP Destination Unreachable 3996 messages (see Section 13.6). This allows the target of a RREQ to 3997 inform RREQ_Gen that the requested Metric Type is not available 3998 (see Section 7.1.2). This will prevent continued flooding for a 3999 Route Discovery that can never be satisfied. 4001 o Corrected various typos and made some stylistic improvements and 4002 clarifications. 4004 Appendix B. Previous AODVv2 Draft Updates 4006 This section lists the changes between recent AODVv2 revisions 4007 ...-00.txt and ...-01.txt. 4009 o Add RerrMsg as a Notational Convenience Table 1 4011 o Wordsmithing, reduce repeated text 4013 o Restore optional Precursor feature (see Section 10) 4015 o Correct misuse of RFC 2119 language 4017 o Revise the method by which a multi-hop path is deemed to be 4018 Confirmed 4020 o Remove technical specification details from definitions 4022 o Move security operational mandates from Security Considerations 4023 into a new section Section 11 4025 o Sharpen language related to assuring that routing must follow 4026 paths appropriate to the metric type for which the route was 4027 established (see Section 5). 4029 o Replace rambling paragraphs by itemized lists to improve 4030 readability 4032 o Allow use of MAC-layer hints about bidirectionality (see 4033 Section 6.2). 4035 o Define concepts of compatibility and comparability for Multicast 4036 Route Message entries (see Section 6.8). This is needed to enable 4037 proper comparisons in case multihomed nodes have route discoveries 4038 from multiple routers 4040 o Sharpen language related to multihoming 4042 o Suggest a proper default for CONTROL_TRAFFIC_LIMIT (see 4043 Section 12.3). 4045 o Sharpen Security Considerations Section according to suggestions 4046 from Bob Moskowitz 4048 Authors' Addresses 4050 Charles E. Perkins 4051 Futurewei Inc. 4052 2330 Central Expressway 4053 Santa Clara, CA 95050 4054 USA 4056 Phone: +1-408-330-4586 4057 Email: charliep@computer.org 4059 Stan Ratliff 4060 Idirect 4061 13861 Sunrise Valley Drive, Suite 300 4062 Herndon, VA 20171 4063 USA 4065 Email: ratliffstan@gmail.com 4066 John Dowdell 4067 Airbus Defence and Space 4068 Celtic Springs 4069 Newport, Wales NP10 8FZ 4070 United Kingdom 4072 Email: john.dowdell@airbus.com 4074 Lotte Steenbrink 4075 HAW Hamburg, Dept. Informatik 4076 Berliner Tor 7 4077 D-20099 Hamburg 4078 Germany 4080 Email: lotte.steenbrink@haw-hamburg.de 4082 Victoria Mercieca 4083 Airbus Defence and Space 4084 Celtic Springs 4085 Newport, Wales NP10 8FZ 4086 United Kingdom 4088 Email: victoria.mercieca@airbus.com