idnits 2.17.1 draft-perkins-manet-aodvv2-00.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 (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Address' is mentioned on line 407, but not defined == Missing Reference: 'MetricType' is mentioned on line 2997, but not defined == Missing Reference: 'OrigPrefix' is mentioned on line 2229, but not defined == Missing Reference: 'TargPrefix' is mentioned on line 2179, but not defined == Missing Reference: 'TBD' is mentioned on line 3019, but not defined == Missing Reference: 'HopCount' is mentioned on line 2969, but not defined Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Experimental S. Ratliff 5 Expires: September 14, 2017 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 March 13, 2017 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-perkins-manet-aodvv2-00 17 Abstract 19 The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing 20 protocol is intended for use by mobile routers in wireless, multihop 21 networks. AODVv2 determines unicast routes among AODVv2 routers 22 within the network in an on-demand fashion. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 14, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 61 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.1. InterfaceSet . . . . . . . . . . . . . . . . . . . . . . 11 63 4.2. Router Client Set . . . . . . . . . . . . . . . . . . . . 11 64 4.3. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 66 4.5. Local Route Set . . . . . . . . . . . . . . . . . . . . . 14 67 4.6. Multicast Route Message Set . . . . . . . . . . . . . . . 16 68 4.7. Route Error (RERR) Set . . . . . . . . . . . . . . . . . 18 69 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. AODVv2 Protocol Operations . . . . . . . . . . . . . . . . . 20 71 6.1. Initialization . . . . . . . . . . . . . . . . . . . . . 20 72 6.2. Next Hop Monitoring . . . . . . . . . . . . . . . . . . . 21 73 6.3. Neighbor Set Update . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . 27 78 6.7.1. Evaluating Route Information . . . . . . . . . . . . 28 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) . . . . . . . . . . . . . . . . . . . . . . . . . . 34 84 6.10. Local Route Set Maintenance . . . . . . . . . . . . . . . 35 85 6.10.1. LocalRoute State Changes . . . . . . . . . . . . . . 35 86 6.10.2. Reporting Invalid Routes . . . . . . . . . . . . . . 37 87 7. AODVv2 Protocol Messages . . . . . . . . . . . . . . . . . . 37 88 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . 38 89 7.1.1. RREQ Generation . . . . . . . . . . . . . . . . . . . 39 90 7.1.2. RREQ Reception . . . . . . . . . . . . . . . . . . . 40 91 7.1.3. RREQ Forwarding . . . . . . . . . . . . . . . . . . . 41 92 7.2. Route Reply (RREP) Message . . . . . . . . . . . . . . . 42 93 7.2.1. RREP Generation . . . . . . . . . . . . . . . . . . . 43 94 7.2.2. RREP Reception . . . . . . . . . . . . . . . . . . . 44 95 7.2.3. RREP Forwarding . . . . . . . . . . . . . . . . . . . 46 96 7.3. Route Reply Acknowledgement (RREP_Ack) Message . . . . . 46 97 7.3.1. RREP_Ack Request Generation . . . . . . . . . . . . . 47 98 7.3.2. RREP_Ack Reception . . . . . . . . . . . . . . . . . 47 99 7.3.3. RREP_Ack Response Generation . . . . . . . . . . . . 48 100 7.4. Route Error (RERR) Message . . . . . . . . . . . . . . . 48 101 7.4.1. RERR Generation . . . . . . . . . . . . . . . . . . . 49 102 7.4.2. RERR Reception . . . . . . . . . . . . . . . . . . . 51 103 7.4.3. RERR Regeneration . . . . . . . . . . . . . . . . . . 52 104 8. RFC 5444 Representation . . . . . . . . . . . . . . . . . . . 53 105 8.1. Route Request Message Representation . . . . . . . . . . 54 106 8.1.1. Message Header . . . . . . . . . . . . . . . . . . . 54 107 8.1.2. Message TLV Block . . . . . . . . . . . . . . . . . . 54 108 8.1.3. Address Block . . . . . . . . . . . . . . . . . . . . 54 109 8.1.4. Address Block TLV Block . . . . . . . . . . . . . . . 55 110 8.2. Route Reply Message Representation . . . . . . . . . . . 55 111 8.2.1. Message Header . . . . . . . . . . . . . . . . . . . 56 112 8.2.2. Message TLV Block . . . . . . . . . . . . . . . . . . 56 113 8.2.3. Address Block . . . . . . . . . . . . . . . . . . . . 56 114 8.2.4. Address Block TLV Block . . . . . . . . . . . . . . . 56 115 8.3. Route Reply Acknowledgement Message Representation . . . 57 116 8.3.1. Message Header . . . . . . . . . . . . . . . . . . . 57 117 8.3.2. Message TLV Block . . . . . . . . . . . . . . . . . . 57 118 8.3.3. Address Block . . . . . . . . . . . . . . . . . . . . 57 119 8.3.4. Address Block TLV Block . . . . . . . . . . . . . . . 57 120 8.4. Route Error Message Representation . . . . . . . . . . . 58 121 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 58 122 8.4.2. Message TLV Block . . . . . . . . . . . . . . . . . . 58 123 8.4.3. Address Block . . . . . . . . . . . . . . . . . . . . 58 124 8.4.4. Address Block TLV Block . . . . . . . . . . . . . . . 58 125 9. Simple External Network Attachment . . . . . . . . . . . . . 59 126 10. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 61 127 10.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 61 128 10.2. Protocol Constants . . . . . . . . . . . . . . . . . . . 63 129 10.3. Local Settings . . . . . . . . . . . . . . . . . . . . . 64 130 10.4. Network-Wide Settings . . . . . . . . . . . . . . . . . 64 131 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 132 11.1. RFC 5444 Message Type Allocation . . . . . . . . . . . . 65 133 11.2. RFC 5444 Message TLV Types . . . . . . . . . . . . . . . 65 134 11.3. RFC 5444 Address Block TLV Type Allocation . . . . . . . 66 135 11.4. MetricType Allocation . . . . . . . . . . . . . . . . . 66 136 11.5. ADDRESS_TYPE TLV Values . . . . . . . . . . . . . . . . 66 137 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 138 12.1. Availability . . . . . . . . . . . . . . . . . . . . . . 67 139 12.1.1. Denial of Service . . . . . . . . . . . . . . . . . 67 140 12.1.2. Malicious RERR messages . . . . . . . . . . . . . . 68 141 12.1.3. False Confirmation of Link Bidirectionality . . . . 70 142 12.1.4. Message Deletion . . . . . . . . . . . . . . . . . . 70 143 12.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 70 144 12.3. Integrity of Routes . . . . . . . . . . . . . . . . . . 71 145 12.3.1. Message Insertion . . . . . . . . . . . . . . . . . 71 146 12.3.2. Message Modification - Man in the Middle . . . . . . 72 147 12.3.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 72 148 12.4. Protection Mechanisms . . . . . . . . . . . . . . . . . 72 149 12.4.1. Confidentiality and Authentication . . . . . . . . . 72 150 12.4.2. Message Integrity using ICVs . . . . . . . . . . . . 72 151 12.4.3. Replay Protection using Timestamps . . . . . . . . . 73 152 12.4.4. Application to AODVv2 . . . . . . . . . . . . . . . 73 153 12.5. Key Management . . . . . . . . . . . . . . . . . . . . . 78 154 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 155 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 156 14.1. Normative References . . . . . . . . . . . . . . . . . . 80 157 14.2. Informative References . . . . . . . . . . . . . . . . . 81 158 Appendix A. AODVv2 Draft Updates . . . . . . . . . . . . . . . . 82 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 161 1. Overview 163 The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol 164 enables dynamic, multihop routing between participating mobile nodes 165 wishing to establish and maintain an ad hoc network. The basic 166 operations of the AODVv2 protocol are route discovery and route 167 maintenance. AODVv2 does not require nodes to maintain routes to 168 destinations that are not in active communication. AODVv2 allows 169 mobile nodes to respond to link breakages and changes in network 170 topology in a timely manner. The operation of AODVv2 is loop-free, 171 and by avoiding the Bellman-Ford "counting to infinity" problem 172 offers quick convergence when the ad hoc network topology changes 173 (typically, when a node moves in the network). When links break, 174 AODVv2 causes the affected set of nodes to be notified so that they 175 are able to invalidate the routes using the lost link. 177 One distinguishing feature of AODVv2 is its use of a destination 178 sequence number for each route entry. The destination sequence 179 number is created by the destination to be included along with any 180 route information it sends to requesting nodes. Using destination 181 sequence numbers ensures loop freedom and is simple to program. 182 Given the choice between two routes to a destination, a requesting 183 node is required to select the one with the greatest sequence number. 185 Compared to AODV [RFC3561], AODVv2 has moved some features out of the 186 scope of the document, notably intermediate route replies, expanding 187 ring search, route lifetimes and precursor lists. However, the 188 document has been designed to allow their specification in a separate 189 document. Hello messages and local repair have been removed. AODVv2 190 provides a mechanism for the use of multiple metric types. Message 191 formats have been updated and made compliant with [RFC5444]. AODVv2 192 control messages are defined as sets of data, which are mapped to 193 message elements using the Generalized MANET Packet/Message Format 194 defined in [RFC5444] and sent using the parameters in [RFC5498]. 195 Verification of link bidirectionality has been substantially 196 improved, and additional refinements made for route timeouts and 197 state management. 199 The basic protocol mechanisms are as follows. Since AODVv2 is a 200 reactive protocol, route discovery is initiated only when a route to 201 the target is needed (i.e. when a router' client wants to send data). 202 AODVv2 does this with the help of a Route Request (RREQ) and Route 203 Reply (RREP) cycle: an RREQ is distributed across the network until 204 it arrives at the target. When forwarding an RREQ, all routers 205 across the network store the neighbor they've received the RREQ from, 206 memorizing a possible route back to the originator of the RREQ. When 207 the target receives the RREQ, it answers with an RREP, which then 208 travels back to the originator along the path memorized by the 209 intermediate routers. A metric value is included within the messages 210 to record the cost of the route. AODVv2 uses sequence numbers to 211 identify stale routing information, and compares route metric values 212 to determine if advertised routes could form loops. Route 213 maintenance includes confirming bidirectionality of links to next-hop 214 AODVv2 routers and issuing Route Error (RERR) messages informing 215 other routers of broken links. It also includes reacting to received 216 Route Error messages, and extending and enforcing route timeouts. 218 The on-demand nature of AODVv2 requires signals to be exchanged 219 between AODVv2 and the forwarding plane. These signals indicate 220 when: 222 o a packet is to be forwarded, in order to initiate route discovery 224 o packet forwarding fails, in order to initiate route error 225 reporting 227 o a packet is successfully forwarded, for route maintenance. 229 Security for authentication of AODVv2 routers and encryption of 230 control messages is accomplished using the TIMESTAMP and ICV TLVs 231 defined in [RFC7182]. 233 2. Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 237 "OPTIONAL" in this document are to be interpreted as described in 238 [RFC2119]. In addition, this document uses terminology from 239 [RFC5444], and defines the following terms: 241 AddressList 242 A list of IP addresses as used in AODVv2 messages. 244 AckReq 245 Used in a Route Reply Acknowledgement message to indicate that a 246 Route Reply Acknowledgement is expected in return. 248 AdvRte 249 A route advertised in an incoming route message. 251 AODVv2 Router 252 An IP addressable device in the ad hoc network that performs the 253 AODVv2 protocol operations specified in this document. 255 CurrentTime 256 The current time as maintained by the AODVv2 router. 258 ENAR (External Network Access Router) 259 An AODVv2 router with an interface to an external, non-AODVv2 260 network. 262 InterfaceSet 263 The set of all network interfaces supporting AODVv2. 265 Invalid route 266 A route that cannot be used for forwarding but still contains 267 useful sequence number information. 269 LocalRoute 270 An entry in the Local Route Set as defined in Section 4.5. 272 MANET 273 A Mobile Ad Hoc Network as defined in [RFC2501]. 275 MetricType 276 The metric type for a metric value included in a message. 278 MetricTypeList 279 A list of metric types associated with the addresses in the 280 AddressList of a Route Error message. 282 Neighbor 283 An AODVv2 router from which an RREQ or RREP message has been 284 received. Neighbors exchange routing information and verify 285 bidirectionality of the link to a neighbor before installing a 286 route via that neighbor into the Local Route Set. 288 OrigAddr 289 The source IP address of the IP packet triggering route discovery. 291 OrigMetric 292 The metric value associated with the route to OrigPrefix. 294 OrigPrefix 295 The prefix configured in the Router Client Set entry which 296 includes OrigAddr. 298 OrigPrefixLen 299 The prefix length, in bits, configured in the Router Client Set 300 entry which includes OrigAddr. 302 OrigSeqNum 303 The sequence number of the AODVv2 router which originated the 304 Route Request on behalf of OrigAddr. 306 PktSource 307 The source address of the IP packet that triggered a Route Error 308 message. 310 PrefixLengthList 311 A list of routing prefix lengths associated with the addresses in 312 the AddressList of a message. 314 Reactive 315 Performed only in reaction to specific events. In AODVv2, routes 316 are requested only when data packets need to be forwarded. In 317 this document, "reactive" is synonymous with "on-demand". 319 RERR (Route Error) 320 The AODVv2 message type used to indicate that an AODVv2 router 321 does not have a valid LocalRoute toward one or more particular 322 destinations. 324 RERR_Gen (RERR Generating Router) 325 The AODVv2 router generating a Route Error message. 327 RerrMsg (RERR Message) 328 A Route Error (RERR) message. 330 Routable Unicast IP Address 331 A routable unicast IP address is a unicast IP address that is 332 scoped sufficiently to be forwarded by a router. Globally-scoped 333 unicast IP addresses and Unique Local Addresses (ULAs) [RFC4193] 334 are examples of routable unicast IP addresses. 336 Router Client 337 An address or address range configured on an AODVv2 router, on 338 behalf of which that router will initiate and respond to route 339 discoveries. These addresses may be used by the AODVv2 router 340 itself or by its Router Clients that are reachable without 341 traversing another AODVv2 router. 343 RREP (Route Reply) 344 The AODVv2 message type used to reply to a Route Request message. 346 RREP_Gen (RREP Generating Router) 347 The AODVv2 router that generates the Route Reply message, i.e., 348 the router configured with TargAddr as a Router Client. 350 RREQ (Route Request) 351 The AODVv2 message type used to discover a route to TargAddr and 352 distribute information about a route to OrigPrefix. 354 RREQ_Gen (RREQ Generating Router) 355 The AODVv2 router that generates the Route Request message, i.e., 356 the router configured with OrigAddr as a Router Client. 358 RteMsg (Route Message) 359 A Route Request (RREQ) or Route Reply (RREP) message. 361 SeqNum 362 The sequence number maintained by an AODVv2 router to indicate 363 freshness of route information. 365 SeqNumList 366 A list of sequence numbers associated with the addresses in the 367 AddressList of a message. 369 TargAddr 370 The target address of a route request, i.e., the destination 371 address of the IP packet triggering route discovery. 373 TargMetric 374 The metric value associated with the route to TargPrefix. 376 TargPrefix 377 The prefix configured in the Router Client Set entry which 378 includes TargAddr. 380 TargPrefixLen 381 The prefix length, in bits, configured in the Router Client Set 382 entry which includes TargAddr. 384 TargSeqNum 385 The sequence number of the AODVv2 router which originated the 386 Route Reply on behalf of TargAddr. 388 Unreachable Address 389 An address reported in a Route Error message, as described in 390 Section 7.4.1. 392 Upstream 393 In the direction from destination to source (from TargAddr to 394 OrigAddr). 396 Valid route 397 A route that can be used for forwarding, as described in 398 Section 7.4.1. 400 This document uses the notational conventions in Table 1 to simplify 401 the text. 403 +-----------------------+------------------------------------+ 404 | Notation | Meaning | 405 +-----------------------+------------------------------------+ 406 | Route[Address] | A route toward Address | 407 | Route[Address].Field | A field in a route toward Address | 408 | RteMsg.Field | A field in either RREQ or RREP | 409 +-----------------------+------------------------------------+ 411 Table 1: Notational Conventions 413 3. Applicability Statement 415 The AODVv2 routing protocol is a reactive routing protocol intended 416 for use in mobile ad hoc wireless networks. A reactive protocol only 417 sends messages to discover a route when there is data to send on that 418 route. Therefore, a reactive routing protocol requires certain 419 interactions with the forwarding plane (for example, to indicate when 420 a packet is to be forwarded, in order to initiate route discovery). 421 The set of signals exchanged between AODVv2 and the forwarding plane 422 are discussed in Section 6.4. 424 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 425 i.e., non-transit networks or those not connected to the internet. 426 AODVv2 can, however, be configured to perform gateway functions when 427 attached to external networks, as discussed in Section 9. 429 AODVv2 handles a wide variety of mobility and traffic patterns by 430 determining routes on-demand. In networks with a large number of 431 routers, AODVv2 is best suited for relatively sparse traffic 432 scenarios where each router forwards IP packets to a small percentage 433 of other AODVv2 routers in the network. In this case fewer routes 434 are needed, and therefore less control traffic is produced. In large 435 networks with very frequent or bursty traffic, AODVv2 control 436 messages may cause a broadcast storm, overwhelming the network with 437 control messages and preventing routes from being established. This 438 especially applies to networks with point-to-point or point-to- 439 multipoint traffic. In this case, the transmission priorities 440 described in Section 6.5 prioritize route maintenance traffic over 441 route discovery traffic. 443 Data packets may be buffered until a route to their destination is 444 available, as described in Section 6.6. 446 AODVv2 provides for message integrity and security against replay 447 attacks by using integrity check values, timestamps and sequence 448 numbers, as described in Section 12. If security associations can be 449 established, encryption can be used for AODVv2 messages to ensure 450 that only trusted routers participate in routing operations. 452 Since the route discovery process aims for a route to be established 453 in both directions along the same path, uni-directional links are not 454 suitable. AODVv2 will detect and exclude those links from route 455 discovery. The route discovered is optimised for the requesting 456 router, and the return path may not be the optimal route. 458 AODVv2 is applicable to memory constrained devices, since only a 459 little routing state is maintained in each AODVv2 router. AODVv2 460 routes that are not needed for forwarding data do not need to be 461 maintained. On routers unable to store persistent AODVv2 state, 462 recovery can impose a performance penalty (e.g., in case of AODVv2 463 router reboot), since if a router loses its sequence number, there is 464 a delay before the router can resume full operations. This is 465 described in Section 6.1. 467 AODVv2 supports routers with multiple interfaces and multiple IP 468 addresses per interface. A router may also use the same IP address 469 on multiple interfaces. AODVv2 requires only that each interface 470 configured for AODVv2 has at least one unicast IP address. Address 471 assignment procedures are out of scope for AODVv2. 473 AODVv2 supports Router Clients with multiple interfaces, as long as 474 each interface is configured with its own unicast IP address. Multi- 475 homing of a Router Client IP address is not supported by AODVv2, and 476 therefore an IP address SHOULD NOT be configured as a Router Client 477 on more than one AODVv2 router at any one time. 479 The routing algorithm in AODVv2 MAY be operated at layers other than 480 the network layer, using layer-appropriate addresses. 482 AODVv2 is based on AODV [RFC3561]. The following important protocol 483 mechanisms have changed: 485 o Bidirectionality is ensured using a new mechanism 487 o Alternate metrics may be used to determine route quality 489 o Support for multiple interfaces has been improved 491 o Support for multi-interface IP addresses has been added 493 o A new security model allowing end to end integrity checks has been 494 added 496 o A new message format ([RFC5444]) is used. 498 4. Data Structures 500 4.1. InterfaceSet 502 The InterfaceSet is a conceptual data structure which contains 503 information about all interfaces configured for use by AODVv2. Any 504 interface with an IP address can be used. Multiple interfaces on a 505 single router can be used. Multiple interfaces on the same router 506 may be configured with the same IP address. 508 Each element in the InterfaceSet MUST contain the following: 510 Interface.Id 511 An identifier that is unique in node-local scope and that allows 512 the AODVv2 implementation to identify exactly one local network 513 interface. 515 If multiple interfaces of the AODVv2 router are configured for use by 516 AODVv2, they MUST be configured in the InterfaceSet. 518 Implementations for constrained devices using only one interface MAY 519 choose not to use the InterfaceSet. 521 4.2. Router Client Set 523 An AODVv2 router provides route discovery services for its own local 524 applications and for its Router Clients that are reachable without 525 traversing another AODVv2 router. The addresses used by these 526 devices, and the AODVv2 router itself, are configured in the Router 527 Client Set. An AODVv2 router will only originate Route Request and 528 Route Reply messages on behalf of configured Router Client addresses. 530 Router Client Set entries MUST contain: 532 RouterClient.IPAddress 533 An IP address or the start of an address range that requires route 534 discovery services from the AODVv2 router. 536 RouterClient.PrefixLength 537 The length, in bits, of the routing prefix associated with the 538 RouterClient.IPAddress. If the prefix length is not equal to the 539 address length of RouterClient.IPAddress, the AODVv2 router MUST 540 participate in route discovery on behalf of all addresses within 541 that prefix. 543 RouterClient.Cost 544 The cost associated with reaching this address or address range. 546 4.3. Neighbor Set 548 A Neighbor Set MUST be maintained with information about neighboring 549 AODVv2 routers. Neighbor Set entries are stored when AODVv2 messages 550 are received. If the Neighbor is chosen as a next hop on an 551 installed route, the link to the Neighbor MUST be tested for 552 bidirectionality and the result stored in this set. A route will 553 only be considered valid when the link is confirmed to be 554 bidirectional. 556 Neighbor Set entries MUST contain: 558 Neighbor.IPAddress 559 An IP address of the neighboring router, learned from the source 560 IP address of a received IP packet containing an AODVv2 route 561 message. 563 Neighbor.State 564 Indicates whether the link to the neighbor is bidirectional. 565 There are three possible states: Confirmed, Heard, and 566 Blacklisted. Heard is the initial state. Confirmed indicates 567 that the link to the neighbor has been confirmed as bidirectional. 568 Blacklisted indicates that the link to the neighbor may have 569 become uni-directional. Section 6.2 discusses how to monitor link 570 bidirectionality. 572 Neighbor.Timeout 573 Indicates at which time the Neighbor.State should be updated: 575 o If the value of Neighbor.State is Blacklisted, this indicates the 576 time at which Neighbor.State will revert to Heard. By default 577 this value is calculated at the time the router is blacklisted and 578 is equal to CurrentTime + MAX_BLACKLIST_TIME. 580 o If Neighbor.State is Heard, and an RREP_Ack has been requested 581 from the neighbor, it indicates the time at which Neighbor.State 582 will be set to Blacklisted, if an RREP_Ack has not been received. 584 o If the value of Neighbor.State is Heard and no RREP_Ack has been 585 requested, or if Neighbor.State is Confirmed, this time is set to 586 INFINITY_TIME. 588 Neighbor.Interface 589 The interface on which the link to the neighbor was established. 591 Neighbor.AckSeqNum 592 The next sequence number to use for the TIMESTAMP value in an 593 RREP_Ack request, in order to detect replay of an RREP_Ack 594 response. AckSeqNum is initialized to a random value. 596 Neighbor.HeardRERRSeqNum 597 The last heard sequence number used as the TIMESTAMP value in a 598 RERR received from this neighbor, saved in order to detect replay 599 of a RERR message. HeardRERRSeqNum is initialized to zero. 601 See Section 12.4.4.3 and Section 12.4.4.4 for more information on how 602 Neighbor.AckSeqNum and Neighbor.HeardRERRSeqNum are used. 604 4.4. Sequence Numbers 606 Sequence Numbers enable AODVv2 routers to determine the temporal 607 order of route discovery information that originates from any single 608 AODVv2 router, and thus to identify stale routing information so that 609 it can be discarded. The sequence number fulfills the same roles as 610 the "Destination Sequence Number" of DSDV [Perkins94], and the AODV 611 Sequence Number in [RFC3561]. The sequence numbers from two 612 different routers are not comparable. Route discovery messages with 613 sequence numbers belonging to two different routers cannot be 614 compared to determine temporal ordering. 616 Each AODVv2 router in the network MUST maintain its own sequence 617 number. All RREQ and RREP messages created by an AODVv2 router 618 include the router's sequence number, reported as a 16-bit unsigned 619 integer. Each AODVv2 router MUST ensure that its sequence number is 620 strictly increasing, and that it is incremented by one (1) whenever 621 an RREQ or RREP is created, except when the sequence number is 65,535 622 (the maximum value of a 16-bit unsigned integer), in which case it 623 MUST be reset to one (1) to achieve wrap around. The value zero (0) 624 is reserved to indicate that the sequence number is unknown. 626 An AODVv2 router MUST only attach its own sequence number to 627 information about a route to one of its configured Router Clients; 628 all route messages forwarded by other routers retain the originator's 629 sequence number. 631 To determine if newly received information is stale and therefore 632 redundant compared to other information originated by the same 633 router, the sequence number attached to the information is compared 634 to the sequence number of existing information about the same route. 635 The comparison is carried out by subtracting the existing sequence 636 number from the newly received sequence number, using unsigned 637 arithmetic. The result of the subtraction is to be interpreted as a 638 signed 16-bit integer. 640 o If the result is negative, the newly received information is 641 considered older than the existing information and is considered 642 stale and redundant and MUST therefore be discarded. 644 o If the result is positive, the newly received information is 645 considered newer than the existing information and is not 646 considered stale or redundant and MUST therefore be processed. 648 o If the result is zero, the newly received information is not 649 considered stale, and therefore MUST be processed further to 650 determine if it is redundant. For example, it is considered 651 redundant if the metric attached to the newly received information 652 is higher than the metric of existing information about the same 653 route (see Section 6.7.1 and Section 6.8). 655 This, along with the processes in Section 6.7.1, ensures loop 656 freedom. 658 An AODVv2 router SHOULD maintain its sequence number in persistent 659 storage. If the sequence number is lost, the router MUST follow the 660 procedure in Section 6.1 to safely resume routing operations with a 661 new sequence number. 663 4.5. Local Route Set 665 All AODVv2 routers MUST maintain a Local Route Set, containing 666 information about routes learned from AODVv2 route messages. The 667 Local Route Set is stored separately from the forwarding plane's 668 routing table (referred to as Routing Information Base (RIB)), which 669 may be updated by other routing protocols operating on the AODVv2 670 router as well. The Routing Information Base is updated using 671 information from the Local Route Set. Alternatively, if the 672 information specified below can be added to RIB entries, 673 implementations MAY choose to modify the Routing Information Base 674 directly instead of maintaining a dedicated Local Route Set. 676 Routes learned from AODVv2 route messages are referred to in this 677 document as LocalRoutes, and MUST contain the following information: 679 LocalRoute.Address 680 An address, which, when combined with LocalRoute.PrefixLength, 681 describes the set of destination addresses this route includes. 683 LocalRoute.PrefixLength 684 The prefix length, in bits, associated with LocalRoute.Address. 686 LocalRoute.SeqNum 687 The sequence number associated with LocalRoute.Address, obtained 688 from the last route message that successfully updated this entry. 690 LocalRoute.NextHop 691 The source IP address of the IP packet containing the AODVv2 692 message advertising the route to LocalRoute.Address, i.e., an IP 693 address of the AODVv2 router used for the next hop on the path 694 toward LocalRoute.Address. 696 LocalRoute.NextHopInterface 697 The interface used to send IP packets toward LocalRoute.Address. 699 LocalRoute.LastUsed 700 If this route is installed in the Routing Information Base, the 701 time it was last used to forward an IP packet. If not, the time 702 at which the LocalRoute was created. 704 LocalRoute.LastSeqNumUpdate 705 The time LocalRoute.SeqNum was last updated. 707 LocalRoute.MetricType 708 The type of metric associated with this route. 710 LocalRoute.Metric 711 The cost of the route toward LocalRoute.Address expressed in units 712 consistent with LocalRoute.MetricType. 714 LocalRoute.State 715 The last known state (Unconfirmed, Idle, Active, or Invalid) of 716 the route. 718 LocalRoute.SeqNoRtr 719 If nonzero, the IP address of the router that originated the 720 Sequence Number for this route. 722 There are four possible states for a LocalRoute: 724 Unconfirmed 725 A route learned from a Route Request message, which has not yet 726 been confirmed as bidirectional. It MUST NOT be used for 727 forwarding IP packets, except possibly for RREP packets that are 728 used for route discovery and bidirectional link verification. 729 Therefore it is not referred to as a valid route. This state is 730 only used for routes learned through RREQ messages. 732 Idle 733 A route that has been learned from a route message, and has also 734 been confirmed, but has not been used in the last ACTIVE_INTERVAL. 735 It is able to be used for forwarding IP packets, and therefore it 736 is referred to as a valid route. 738 Active 739 A route that has been learned from a route message, and has also 740 been confirmed, and has been used in the last ACTIVE_INTERVAL. It 741 is able to be used for forwarding IP packets, and therefore it is 742 referred to as a valid route. 744 Invalid 745 A route that has expired or been lost. It MUST NOT be used for 746 forwarding IP packets, and therefore it is not referred to as a 747 valid route. Invalid routes contain sequence number information 748 which allows incoming information to be assessed for freshness. 750 If the Local Route Set is stored separately from the Routing 751 Information Base, routes are added to the Routing Information Base 752 when LocalRoute.State is valid (set to Active or Idle), and removed 753 from the Routing Information Base when LocalRoute.State becomes 754 Invalid. 756 Changes to LocalRoute state are detailed in Section 6.10.1. 758 Multiple valid routes for the same address and prefix length but for 759 different metric types may exist in the Local Route Set, but only one 760 route to a particular address and prefix length may exist in the 761 Routing Information Base. The decision of which of the routes should 762 be installed in the Routing Information Base is outside the scope of 763 AODVv2. 765 4.6. Multicast Route Message Set 767 Route Request (RREQ) messages are multicast by default and forwarded 768 multiple times. This set stores recently received RREQs in order 769 that received RREQs can be tested for redundancy to avoid unnecessary 770 processing and forwarding. 772 The Multicast Route Message Set is a conceptual set which contains 773 information about previously received multicast route messages, so 774 that incoming route messages can be compared with previously received 775 messages to determine if the incoming information is redundant or 776 stale, and the router can avoid sending redundant control traffic. 778 Multicast Route Message Set entries MUST contain the following 779 information: 781 RteMsg.OrigPrefix 782 The prefix associated with OrigAddr, the source address of the IP 783 packet triggering the route request. 785 RteMsg.OrigPrefixLen 786 The prefix length associated with RteMsg.OrigPrefix, originally 787 from the Router Client Set entry on RREQ_Gen which includes 788 OrigAddr. 790 RteMsg.TargPrefix 791 The prefix associated with TargAddr, the destination address of 792 the IP packet triggering the route request. In an RREQ this MUST 793 be set to TargAddr. 795 RteMsg.OrigSeqNum 796 The sequence number associated with the route to OrigPrefix, if 797 RteMsg is an RREQ. 799 RteMsg.TargSeqNum 800 The sequence number associated with the route to TargPrefix. 802 RteMsg.MetricType 803 The metric type of the route requested. 805 RteMsg.Metric 806 The metric value received in the RteMsg. 808 RteMsg.Timestamp 809 The last time this Multicast Route Message Set entry was updated. 811 RteMsg.RemoveTime 812 The time at which this entry MUST be removed from the Multicast 813 Route Message Set. This is set to CurrentTime + 814 MAX_SEQNUM_LIFETIME, whenever the RteMsg.OrigSeqNum of this entry 815 is updated. 817 RteMsg.Interface 818 The interface on which the message was received. 820 RteMsg.SeqNoRtr 821 If nonzero, the IP address of the router that originated the 822 Sequence Number for this route. 824 The Multicast Route Message Set is maintained so that no two entries 825 have the same OrigPrefix, OrigPrefixLen, TargPrefix, and MetricType. 826 See Section 6.8 for details about updating this set. 828 4.7. Route Error (RERR) Set 830 Each RERR message sent because no route exists for packet forwarding 831 SHOULD be recorded in a conceptual set called the Route Error (RERR) 832 Set. Each entry contains the following information: 834 RerrMsg.Timeout 835 The time after which the entry SHOULD be deleted. 837 RerrMsg.UnreachableAddress 838 The UnreachableAddress reported in the AddressList of the RERR. 840 RerrMsg.PktSource: 841 The PktSource of the RERR. 843 See section Section 6.9 for instructions on how to update the set. 845 5. Metrics 847 Metrics measure a cost or quality associated with a route or a link, 848 e.g., latency, delay, financial cost, energy, etc. Metric values are 849 reported in Route Request and Route Reply messages. 851 In Route Request messages, the metric describes the cost of the route 852 from OrigPrefix to the router sending the Route Request. For 853 RREQ_Gen, this is the cost associated with the Router Client Set 854 entry which includes OrigAddr. For routers which forward the RREQ, 855 this is the cost from OrigPrefix to the forwarding router, combining 856 the metric value from the received RREQ message with knowledge of the 857 link cost from the sender to the receiver, i.e., the incoming link 858 cost. This updated route cost is included when forwarding the Route 859 Request message, and used to install a route to OrigPrefix. 861 Similarly, in Route Reply messages, the metric reflects the cost of 862 the route from TargPrefix to the router sending the Route Reply. For 863 RREP_Gen, this is the cost associated with the Router Client Set 864 entry which includes TargAddr. For routers which forward the RREP, 865 this is the cost from TargPrefix to the forwarding router, combining 866 the metric value from the received RREP message with knowledge of the 867 link cost from the sender to the receiver, i.e., the incoming link 868 cost. This updated route cost is included when forwarding the Route 869 Reply message, and used to install a route to TargPrefix. 871 Assuming link metrics are symmetric, the cost of the routes installed 872 in the Local Route Set at each router will be correct. While this 873 assumption is not always correct, calculating incoming/outgoing 874 metric data is outside of scope of this document. The route 875 discovered is optimised for the requesting router, and the return 876 path may not be the optimal route. 878 AODVv2 enables the use of multiple metric types. Each route 879 discovery attempt indicates the metric type which is requested for 880 the route. Each route discovery attempt MUST use only one metric 881 type. 883 For each MetricType, AODVv2 requires: 885 o A MetricType number, to indicate the metric type of a route. 886 MetricType numbers allocated are detailed in Section 11.4. 888 o A maximum value, denoted MAX_METRIC[MetricType]. This MUST always 889 be the maximum expressible metric value of type MetricType. Field 890 lengths associated with metric values are found in Section 11.4. 891 If the cost of a route exceeds MAX_METRIC[MetricType], the route 892 is ignored. 894 o A function for incoming link cost, denoted Cost(L). Using 895 incoming link costs means that the route learned has a path 896 optimized for the direction from OrigAddr to TargAddr. 898 o A function for route cost, denoted Cost(R). 900 o A function to analyze routes for potential loops based on metric 901 information, denoted LoopFree(R1, R2). LoopFree verifies that a 902 route R2 is not a sub-section of another route R1. An AODVv2 903 router invokes LoopFree() as part of the process in Section 6.7.1, 904 when an advertised route (R1) and an existing LocalRoute (R2) have 905 the same destination address, metric type, and sequence number. 906 LoopFree returns FALSE to indicate that an advertised route is not 907 to be used to update a stored LocalRoute, as it may cause a 908 routing loop. In the case where the existing LocalRoute is 909 Invalid, it is possible that the advertised route includes the 910 existing LocalRoute and came from a router which did not yet 911 receive notification of the route becoming Invalid, so the 912 advertised route should not be used to update the Local Route Set, 913 in case it forms a loop to a broken route. 915 AODVv2 currently supports cost metrics where Cost(R) is strictly 916 increasing, by defining: 918 o Cost(R) := Sum of Cost(L) of each link in the route 920 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 922 Implementers MAY consider other metric types, but the definitions of 923 Cost and LoopFree functions for such types are undefined, and 924 interoperability issues need to be considered. 926 6. AODVv2 Protocol Operations 928 The AODVv2 protocol's operations include managing sequence numbers, 929 monitoring next hop AODVv2 routers on discovered routes and updating 930 the Neighbor Set, performing route discovery and dealing with 931 requests from other routers, processing incoming route information 932 and updating the Local Route Set, updating the Multicast Route 933 Message Set and suppressing redundant messages, and reporting broken 934 routes. These processes are discussed in detail in the following 935 sections. 937 6.1. Initialization 939 During initialization where an AODVv2 router does not have 940 information about its previous sequence number, or if its sequence 941 number is lost at any point, the router resets its sequence number to 942 one (1). However, other AODVv2 routers may still hold sequence 943 number information that this router previously issued. Since 944 sequence number information is removed if there has been no update to 945 the sequence number in MAX_SEQNUM_LIFETIME, the initializing router 946 MUST wait for MAX_SEQNUM_LIFETIME before it creates any messages 947 containing its new sequence number. It can then be sure that the 948 information it sends will not be considered stale. 950 During this wait period, the router is permitted to do the following: 952 o Process information in a received RREQ or RREP message to learn a 953 route to the originator or target of that route discovery 955 o Forward a received RREQ or RREP 957 o Send an RREP_Ack 959 o Maintain valid routes in the Local Route Set 960 o Create, process and forward RERR messages 962 6.2. Next Hop Monitoring 964 To ensure AODVv2 routers Routers do not establish routes over uni- 965 directional links, AODVv2 routers MUST verify that the link to the 966 next hop router is bidirectional before marking a route as valid in 967 the Local Route Set. 969 AODVv2 provides a mechanism for testing bidirectional connectivity 970 during route discovery, and blacklisting routers where bidirectional 971 connectivity is not available. If a route discovery is retried by 972 RREQ_Gen, the blacklisted routers can be excluded from the process, 973 and a different route can be discovered. Further, a route is not to 974 be used for forwarding until the bidirectionality of the link to the 975 next hop is confirmed. AODVv2 routers do not need to monitor 976 bidirectionality for links to neighboring routers which are not used 977 as next hops on routes in the Local Route Set. 979 o Bidirectional connectivity to upstream routers is tested by 980 requesting acknowledgement of RREP messages by also sending an 981 RREP_Ack, including an AckReq element to indicate that an 982 acknowledgement is requested. This MUST be answered by sending an 983 RREP_Ack in response. Receipt of an RREP_Ack within 984 RREP_Ack_SENT_TIMEOUT proves that bidirectional connectivity 985 exists. Otherwise, a link is determined to be unidirectional. 986 All AODVv2 routers MUST support this process, which is explained 987 in Section 7.2 and Section 7.3. 989 o For the downstream router, receipt of an RREP message containing 990 the route to TargAddr is confirmation of bidirectionality , since 991 an RREP message is a reply to a RREQ message which previously 992 crossed the link in the opposite direction. 994 To assist with next hop monitoring, a Neighbor Set (Section 4.3) is 995 maintained. When an RREQ or RREP is received, search for an entry in 996 the Neighbor Set where all of the following conditions are met: 998 o Neighbor.IPAddress == IP address from which the RREQ or RREP was 999 received 1001 o Neighbor.Interface == Interface on which the RREQ or RREP was 1002 received. 1004 If such an entry does not exist, a new entry is created as described 1005 in Section 6.3. While the value of Neighbor.State is Heard, 1006 acknowledgement of RREP messages sent to that neighbor MUST be 1007 requested. If an acknowledgement is not received within the timeout 1008 period, the neighbor MUST have Neighbor.State set to Blacklisted. If 1009 an acknowledgement is received within the timeout period, 1010 Neighbor.State is set to Confirmed. While the value of 1011 Neighbor.State is Confirmed, the request for an acknowledgement of 1012 any other RREP message is unnecessary. 1014 When routers perform other operations such as those from the list 1015 below, these MAY be used as additional indications of connectivity: 1017 o NHDP HELLO Messages [RFC6130] 1019 o Route timeout 1021 o Lower layer triggers, e.g. message reception or link status 1022 notifications 1024 o TCP timeouts 1026 o Promiscuous listening 1028 o Other monitoring mechanisms or heuristics 1030 If such an external process signals that the link to a neighbor is 1031 bidirectional, the AODVv2 router MAY update the matching Neighbor Set 1032 entry by changing the value of Neighbor.State to Confirmed, e.g. 1033 receipt of a Neighborhood Discovery Protocol HELLO message with the 1034 receiving router listed as a neighbor. If an external process 1035 signals that a link is not bidirectional, the the value of 1036 Neighbor.State MAY be changed to Blacklisted, e.g. notification of a 1037 TCP timeout. 1039 6.3. Neighbor Set Update 1041 On receipt of an RREQ or RREP message, the Neighbor Set MUST be 1042 checked for an entry with Neighbor.IPAddress which matches the source 1043 IP address of a packet containing the AODVv2 message. If no matching 1044 entry is found, a new entry is created. 1046 A new Neighbor Set entry is created as follows: 1048 o Neighbor.IPAddress := Source IP address of the received route 1049 message 1051 o Neighbor.State := Heard 1053 o Neighbor.Timeout := INFINITY_TIME 1054 o Neighbor.Interface := Interface on which the RREQ or RREP was 1055 received. MUST equal Interface.Id of one of the entries in the 1056 InterfaceSet (see Section 4.1). 1058 When an RREP_Ack is sent to a neighbor, the Neighbor Set entry is 1059 updated as follows: 1061 o Neighbor.Timeout := CurrentTime + RREP_Ack_SENT_TIMEOUT 1063 When a received message is one of the following: 1065 o an RREP which answers an RREQ sent within RREQ_WAIT_TIME over the 1066 same interface as Neighbor.Interface 1068 o an RREP_Ack response received from a Neighbor with Neighbor.State 1069 set to Heard, where Neighbor.Timeout > CurrentTime 1071 then the link to the neighbor is bidirectional and the Neighbor Set 1072 entry is updated as follows: 1074 o Neighbor.State := Confirmed 1076 o Neighbor.Timeout := INFINITY_TIME 1078 When the Neighbor.Timeout is reached and Neighbor.State is Heard, 1079 then an RREP_Ack response has not been received from the neighbor 1080 within RREP_Ack_SENT_TIMEOUT of sending the RREP_Ack request. The 1081 link is considered to be uni-directional and the Neighbor Set entry 1082 is updated as follows: 1084 o Neighbor.State := Blacklisted 1086 o Neighbor.Timeout := CurrentTime + MAX_BLACKLIST_TIME 1088 When the Neighbor.Timeout is reached and Neighbor.State is 1089 Blacklisted, the Neighbor Set entry is updated as follows: 1091 o Neighbor.State := Heard 1093 If an external mechanism reports a link as broken, the Neighbor Set 1094 entry SHOULD be removed. 1096 Route requests from neighbors with Neighbor.State set to Blacklisted 1097 are ignored to avoid persistent IP packet loss or protocol failures. 1098 Neighbor.Timeout allows the neighbor to again be allowed to 1099 participate in route discoveries after MAX_BLACKLIST_TIME, in case 1100 the link between the routers has become bidirectional. 1102 6.4. Interaction with the Forwarding Plane 1104 The signals descried in the following are conceptual signals, and can 1105 be implemented in various ways. Conformant implementations of AODVv2 1106 are not mandated to implement the forwarding plane separately from 1107 the control plane or data plane; these signals and interactions are 1108 identified simply as assistance for implementers who may find them 1109 useful. 1111 AODVv2 requires signals from the forwarding plane: 1113 o A packet cannot be forwarded because a route is unavailable: 1114 AODVv2 needs to know the source and destination IP addresses of 1115 the packet. If the source of the packet is configured as a Router 1116 Client, the router SHOULD initiate route discovery to the 1117 destination. If it is not a Router Client, the router SHOULD 1118 create a Route Error message. 1120 o A packet is to be forwarded: AODVv2 needs to check the state of 1121 the route to ensure it is still valid. 1123 o Packet forwarding succeeds: AODVv2 needs to update the record of 1124 when a route was last used to forward a packet. 1126 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1127 Error message. 1129 AODVv2 needs to send signals to the forwarding plane: 1131 o A route discovery is in progress: buffering might be configured 1132 for packets requiring a route, while route discovery is attempted. 1134 o A route discovery failed: any buffered packets requiring that 1135 route should be discarded, and the source of the packet should be 1136 notified that the destination is unreachable (using an ICMP 1137 Destination Unreachable message). Route discovery fails if an 1138 RREQ cannot be generated because the control message generation 1139 limit has been reached, or if an RREP is not received within 1140 RREQ_WAIT_TIME (see Section 6.6). 1142 o A route discovery is not permitted: any buffered packets requiring 1143 that route should be discarded. A route discovery will not be 1144 attempted if the source address of the packet needing a route is 1145 not configured as a Router Client. 1147 o A route discovery succeeded: install a corresponding route into 1148 the Routing Information Base and begin transmitting any buffered 1149 packets. 1151 o A route has been made invalid: remove the corresponding route from 1152 the Routing Information Base. 1154 o A route has been updated: update the corresponding route in the 1155 Routing Information Base. 1157 o CEP: If routes with more than one metric type are available to a 1158 destination, a way to identify the route that is allowable for 1159 each metric type 1161 6.5. Message Transmission 1163 AODVv2 sends [RFC5444] formatted messages using the parameters for 1164 port number and IP protocol specified in [RFC5498]. Mapping of 1165 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1166 multicast messages are sent to the link-local multicast address LL- 1167 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1168 MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2 1169 messages. Note that multicast messages MAY be sent via unicast. For 1170 example, this may occur for certain link-types (non-broadcast media), 1171 for manually configured router adjacencies, or in order to improve 1172 robustness. 1174 When multiple interfaces are available, an AODVv2 router transmitting 1175 a multicast message to LL-MANET-Routers MUST send the message on all 1176 interfaces that have been configured for AODVv2 operation, as given 1177 in the InterfaceSet (Section 4.1). 1179 To avoid congestion, each AODVv2 router's rate of message generation 1180 SHOULD be limited (CONTROL_TRAFFIC_LIMIT) and administratively 1181 configurable. Messages SHOULD NOT be sent more frequently than one 1182 message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If this 1183 threshold is reached, messages MUST be sent based on their priority: 1185 o Highest priority SHOULD be given to RREP_Ack messages. This 1186 allows links between routers to be confirmed as bidirectional and 1187 avoids undesired blacklisting of next hop routers. 1189 o Second priority SHOULD be given to RERR messages for undeliverable 1190 IP packets. This avoids repeated forwarding of packets over 1191 broken routes that are still in use by other routers. 1193 o Third priority SHOULD be given to RREP messages in order that 1194 RREQs do not time out. 1196 o Fourth priority SHOULD be given to RREQ messages. 1198 o Fifth priority SHOULD be given to RERR messages for newly 1199 invalidated routes. 1201 o Lowest priority SHOULD be given to RERR messages generated in 1202 response to RREP messages which cannot be forwarded. In this case 1203 the route request will be retried at a later point. 1205 To implement the congestion control, a queue length is set. If the 1206 queue is full, in order to queue a new message, a message of lower 1207 priority must be removed from the queue. If this is not possible, 1208 the new message MUST be discarded. The queue should be sorted in 1209 order of message priority 1211 6.6. Route Discovery, Retries and Buffering 1213 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1214 messages are multicast to solicit an RREP, whereas RREP are unicast. 1215 The constants used in this section are defined in Section 10. 1217 When an AODVv2 router needs to forward an IP packet (with source 1218 address OrigAddr and destination address TargAddr) from one of its 1219 Router Clients, it needs a route to TargAddr in its Routing 1220 Information Base. If no route exists, the AODVv2 router generates 1221 (RREQ_Gen) and multicasts a Route Request message (RREQ), on all 1222 configured interfaces, containing information about the source and 1223 destination. The procedure for this is described in Section 7.1.1. 1224 Each generated RREQ results in an increment to the router's sequence 1225 number. The AODVv2 router generating an RREQ is referred to as 1226 RREQ_Gen. 1228 Buffering might be configured for IP packets awaiting a route for 1229 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1230 of IP packets might have both positive and negative effects. Real- 1231 time traffic, voice, and scheduled delivery may suffer if packets are 1232 buffered and subjected to delays, but TCP connection establishment 1233 will benefit if packets are queued while route discovery is performed 1234 [Koodli01]. Recommendations for appropriate buffer methods are out 1235 of scope for this specification. Determining which packets to 1236 discard first when the buffer is full is a matter of policy at each 1237 AODVv2 router. Note that using different or no buffer methods does 1238 not affect interoperability. 1240 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1241 a route toward TargAddr. This can be achieved by monitoring the 1242 entry in the Multicast Route Message Table that corresponds to the 1243 generated RREQ. When CurrentTime exceeds RteMsg.Timestamp + 1244 RREQ_WAIT_TIME and no RREP has been received, RREQ_Gen will retry the 1245 route discovery. 1247 To reduce congestion in a network, repeated attempts at route 1248 discovery for a particular target address utilize a binary 1249 exponential backoff: for each additional attempt, the time to wait 1250 for receipt of the RREP is multiplied by 2. If the requested route 1251 is not learned within the wait period, another RREQ is sent, up to a 1252 total of DISCOVERY_ATTEMPTS_MAX. This is the same technique used in 1253 AODV [RFC3561]. 1255 Through the use of bidirectional link monitoring and blacklists (see 1256 Section 6.2) uni-directional links on initial selected route will be 1257 ignored on subsequent route discovery attempts. 1259 Route discovery is considered to have failed after 1260 DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an RREP 1261 response to the final RREQ. After the attempted route discovery has 1262 failed, RREQ_Gen waits at least RREQ_HOLDDOWN_TIME before attempting 1263 another route discovery to the same destination, in order to avoid 1264 repeatedly generating control traffic that is unlikely to discover a 1265 route. Any IP packets buffered for TargAddr are also dropped and a 1266 Destination Unreachable ICMP message (Type 3) with a code of 1 (Host 1267 Unreachable Error) is delivered to the source of the packet, so that 1268 the application knows about the failure. 1270 If RREQ_Gen does receive a route message containing a route to 1271 TargAddr within the timeout, it processes the message according to 1272 Section 7. When a valid LocalRoute entry is created in the Local 1273 Route Set, the route is also installed in the Routing Information 1274 Base, and the router will begin sending the buffered IP packets. Any 1275 retry timers for the corresponding RREQ are then cancelled. 1277 During route discovery, all routers on the path learn a route to both 1278 OrigPrefix and TargPrefix, so that routes are constructed in both 1279 directions. The route is optimized for the forward route. 1281 6.7. Processing Received Route Information 1283 All AODVv2 route messages contain a route. A Route Request (RREQ) 1284 contains a route to OrigPrefix, and a Route Reply (RREP) contains a 1285 route to TargPrefix. All AODVv2 routers that receive a route message 1286 are able to store the route contained within it in their Local Route 1287 Set. Incoming information is first checked to verify that it is both 1288 safe to use and offers an improvement to existing information, as 1289 explained in Section 6.7.1. If these checks pass, the Local Route 1290 Set MUST be updated according to Section 6.7.2. 1292 In the processes below, RteMsg is used to denote the route message, 1293 AdvRte is used to denote the route contained within it, and 1294 LocalRoute denotes an existing entry in the Local Route Set which 1295 matches AdvRte on address, prefix length, metric type, and SeqNoRtr. 1297 AdvRte has the following properties: 1299 o AdvRte.Address := RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix 1300 (in RREP) 1302 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1303 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1304 in RteMsg, prefix length is the address length, in bits, of 1305 RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix (in RREP) 1307 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1308 (in RREP) 1310 o AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the 1311 sending interface of the router from which the RteMsg was 1312 received) 1314 o AdvRte.MetricType := RteMsg.MetricType 1316 o AdvRte.Metric := RteMsg.Metric 1318 o AdvRte.Cost := Cost(R) using the cost function associated with the 1319 route's metric type, i.e. Cost(R) = AdvRte.Metric + Cost(L), as 1320 described in Section 5, where L is the link from the advertising 1321 router 1323 o AdvRte.SeqNoRtr := the IP address in the Address List of type 1324 SeqNoRtr if one exists, otherwise 0 1326 6.7.1. Evaluating Route Information 1328 An incoming advertised route (AdvRte) is compared to existing 1329 LocalRoutes to determine whether the advertised route is to be used 1330 to update the AODVv2 Local Route Set. The incoming route information 1331 MUST be processed as follows: 1333 1. Search for LocalRoutes in the Local Route Set matching AdvRte's 1334 address, prefix length, metric type, and SeqNoRtr (the AODVv2 1335 router address corresponding to the sequence number). 1337 * If no matching LocalRoute exists, AdvRte MUST be used to 1338 update the Local Route Set and no further checks are required. 1340 * If matching LocalRoutes are found, continue to Step 2. 1342 2. Compare sequence numbers using the technique described in 1343 Section 4.4 1345 * If AdvRte is more recent than all matching LocalRoutes, AdvRte 1346 MUST be used to update the Local Route Set and no further 1347 checks are required. 1349 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1350 Local Route Set. Ignore AdvRte for further processing. 1352 * If the sequence numbers are equal, continue to Step 3. 1354 3. Check that AdvRte is safe against routing loops compared to all 1355 matching LocalRoutes (see Section 5) 1357 * If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte 1358 for further processing. AdvRte MUST NOT be used to update the 1359 Local Route Set because using the incoming information might 1360 cause a routing loop. 1362 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to Step 1363 4. 1365 4. Compare route costs 1367 * If AdvRte is better than all matching LocalRoutes, it MUST be 1368 used to update the Local Route Set because it offers 1369 improvement. 1371 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte 1372 SHOULD NOT be used to update the Local Route Set because it 1373 will offer no improvement. 1375 * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for 1376 further processing. AdvRte MUST NOT be used to update the 1377 Local Route Set because it does not offer any improvement. 1379 * If AdvRte is not better (i.e., it is worse or equal) but 1380 LocalRoute is Invalid, AdvRte SHOULD be used to update the 1381 Local Route Set because it can safely repair the existing 1382 Invalid LocalRoute. 1384 If the advertised route is to be used to update the Local Route Set, 1385 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1386 routes will remain in the Local Route Set. 1388 For information on how to apply these changes to the Routing 1389 Information Base, see Section 4.5. 1391 6.7.2. Applying Route Updates 1393 After determining that AdvRte is to be used to update the Local Route 1394 Set (as described in Section 6.7.1), the following procedure applies. 1396 If AdvRte is learned from an RREQ message, the link to the next hop 1397 neighbor may not be confirmed as bidirectional (see Section 4.3). If 1398 there is no existing matching route in the Local Route Set, AdvRte 1399 MUST be installed to allow a corresponding RREP to be sent. If a 1400 matching entry already exists, AdvRte offers potential improvement, 1401 if the link to the neighbor can be confirmed as bidirectional. 1403 The route update is applied as follows: 1405 1. If no existing entry in the Local Route Set matches AdvRte's 1406 address, prefix length, metric type and SeqNoRtr, continue to 1407 Step 4 and create a new entry in the Local Route Set. 1409 2. If two matching LocalRoutes exist in the Local Route Set, one is 1410 a valid route, and one is an Unconfirmed route, AdvRte may offer 1411 further improvement to the Unconfirmed route, or may offer an 1412 update to the valid route. 1414 * If AdvRte.NextHop's Neighbor.State is Heard, the advertised 1415 route may offer improvement to the existing valid route, if 1416 the link to the next hop can be confirmed as bidirectional. 1417 Continue processing from Step 5 to update the existing 1418 Unconfirmed LocalRoute. 1420 * If AdvRte.NextHop's Neighbor.State is Confirmed, the 1421 advertised route offers an update or improvement to the 1422 existing valid route. Continue processing from Step 5 to 1423 update the existing valid LocalRoute. 1425 3. If only one matching LocalRoute exists in the Local Route Set: 1427 * If AdvRte.NextHop's Neighbor.State is Confirmed, continue 1428 processing from Step 5 to update the existing LocalRoute. 1430 * If AdvRte.NextHop's Neighbor.State is Heard, AdvRte may offer 1431 improvement the existing LocalRoute, if the link to 1432 AdvRte.NextHop can be confirmed as bidirectional. 1434 * If LocalRoute.State is Unconfirmed, AdvRte is an improvement 1435 to an existing Unconfirmed route. Continue processing from 1436 Step 5 to update the existing LocalRoute. 1438 * If LocalRoute.State is Invalid, AdvRte can replace the 1439 existing LocalRoute. Continue processing from Step 5 to 1440 update the existing LocalRoute. 1442 * If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored 1443 as an additional entry in the Local Route Set, with 1444 LocalRoute.State set to Unconfirmed. Continue processing from 1445 Step 4 to create a new LocalRoute. 1447 4. Create an entry in the Local Route Set and initialize as follows: 1449 * LocalRoute.Address := AdvRte.Address 1451 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1453 * LocalRoute.MetricType := AdvRte.MetricType 1455 5. Update the LocalRoute as follows: 1457 * LocalRoute.SeqNum := AdvRte.SeqNum 1459 * LocalRoute.NextHop := AdvRte.NextHop 1461 * LocalRoute.NextHopInterface := interface on which RteMsg was 1462 received 1464 * LocalRoute.Metric := AdvRte.Cost 1466 * LocalRoute.LastUsed := CurrentTime 1468 * LocalRoute.LastSeqNumUpdate := CurrentTime 1470 6. If a new LocalRoute was created, or if the existing 1471 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1472 follows: 1474 * LocalRoute.State := Unconfirmed (if the next hop's 1475 Neighbor.State is Heard) 1477 * LocalRoute.State := Idle (if the next hop's Neighbor.State is 1478 Confirmed) 1480 7. If an existing LocalRoute.State changed from Invalid or 1481 Unconfirmed to become Idle, any matching Unconfirmed LocalRoute 1482 with worse metric value SHOULD be expunged. 1484 8. If an existing LocalRoute was updated with a better metric value, 1485 any matching Unconfirmed LocalRoute with worse metric value 1486 SHOULD be expunged. 1488 9. If this update results in LocalRoute.State of Active or Idle, 1489 which matches a route request which is still in progress, the 1490 associated route request retry timers MUST be cancelled. 1492 If this update to the Local Route Set results in two LocalRoutes to 1493 the same address, the best LocalRoute will be Unconfirmed. In order 1494 to improve the route used for forwarding, the router SHOULD try to 1495 determine if the link to the next hop of that LocalRoute is 1496 bidirectional, by using that LocalRoute to forward future RREPs and 1497 request acknowledgements (see Section 7.2.1 and Section 7.3. 1499 6.8. Suppressing Redundant Messages (Multicast Route Message Set) 1501 When route messages are flooded in a MANET, an AODVv2 router may 1502 receive several instances of the same message. Forwarding every one 1503 of these gives little additional benefit, and generates unnecessary 1504 signaling traffic and might generate unnecessary interference. 1506 Each AODVv2 router stores information about recently received route 1507 messages in the AODVv2 Multicast Route Message Set (Section 4.6). 1509 Entries in the Multicast Route Message Set SHOULD be maintained for 1510 at least RteMsg_ENTRY_TIME after the last Timestamp update in order 1511 to account for long-lived RREQs traversing the network. An entry 1512 MUST be deleted when the sequence number is no longer valid, i.e., 1513 after MAX_SEQNUM_LIFETIME. Memory-constrained devices MAY remove the 1514 entry before this time. 1516 Received route messages are tested against previously received route 1517 messages, and if determined to be redundant, forwarding or response 1518 can be avoided. 1520 To determine if a received message is redundant: 1522 1. Search for an entry in the Multicast Route Message Set with the 1523 same OrigPrefix, OrigPrefixLen, TargPrefix, Interface and 1524 MetricType 1526 * If there is no entry, the message is not redundant. 1528 * If there is an entry, continue to Step 2. 1530 2. Compare sequence numbers using the technique described in 1531 Section 4.4 1532 * Use OrigSeqNum of the entry for comparison. If the incoming 1533 message contains SeqNoRtr that is not comparable to the stored 1534 sequence number, continue to Step 3. 1536 * If the entry has an older sequence number than the received 1537 message, the message is not redundant. 1539 * If the entry has a newer sequence number than the received 1540 message, the message is redundant. 1542 * If the entry has the same sequence number, continue to Step 3. 1544 3. Compare the metric values 1546 * If the entry has a Metric value that is worse than or equal to 1547 the metric in the received message, the message is redundant. 1549 * If the entry has a Metric value that is better than the metric 1550 in the received message, the message is not redundant. 1552 If the message is redundant, update the entry as follows: 1554 o RteMsg.Timestamp := CurrentTime 1556 o RteMasg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME 1558 since matching route messages are still traversing the network and 1559 this entry should be maintained. This message MUST NOT be forwarded 1560 or responded to. 1562 If the message is not redundant, create an entry or update the 1563 existing entry. 1565 To update a Multicast Route Message Set entry, set: 1567 o RteMsg.OrigPrefix := OrigPrefix from the message 1569 o RteMsg.OrigPrefixLen := the prefix length associated with 1570 OrigPrefix 1572 o RteMsg.TargPrefix := TargPrefix from the message 1574 o RteMsg.OrigSeqNum := the sequence number associated with 1575 OrigPrefix, if RteMsg is an RREQ 1577 o RteMsg.TargSeqNum := the sequence number associated with 1578 TargPrefix, if RteMsg is an RREP 1580 o RteMsg.Metric := the metric value associated with OrigPrefix in a 1581 received RREQ 1583 o RteMsg.MetricType := the metric type associated with RteMsg.Metric 1585 o RteMsg.Timestamp := CurrentTime 1587 o RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME 1589 Where the message is determined not redundant before Step 3, it MUST 1590 be forwarded or responded to. When a message is determined to be not 1591 redundant in Step 3, it MAY be suppressed to avoid extra control 1592 traffic. However, since the processing of the message will result in 1593 an update to the Local Route Set, the message SHOULD be forwarded or 1594 responded to, to ensure other routers have up-to-date information and 1595 the best metrics. If the message is not forwarded, the best route 1596 may not be found. Forwarding or response is to be performed using 1597 the processes outlined in Section 7. 1599 6.9. Suppressing Redundant Route Error Messages (Route Error Set) 1601 In order to avoid flooding the network with RERR messages when a 1602 stream of IP packets to an unreachable address arrives, an AODVv2 1603 router SHOULD avoid creating duplicate messages by determining 1604 whether an equivalent RERR has recently been sent. This is achieved 1605 with the help of the Route Error Set (see Section 4.7). 1607 To determine if a RERR should be created: 1609 1. Search for an entry in the Route Error Set where: 1611 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1612 reported 1614 * RerrMsg.PktSource == PktSource to be included in the RERR 1616 If a matching entry is found, no further processing is required 1617 and the RERR SHOULD NOT be sent. 1619 2. If no matching entry is found, a new entry with the following 1620 properties is created, and the RERR is created and sent as 1621 described in Section 7.4.1: 1623 * RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT 1625 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1626 reported 1628 * RerrMsg.PktSource == PktSource to be included in the RERR 1630 6.10. Local Route Set Maintenance 1632 Route maintenance involves monitoring LocalRoutes in the Local Route 1633 Set, updating LocalRoute.State to handle route timeouts or (in the 1634 case of possibly unidirectional links) infer confirmation of a route 1635 to OrigAddr, and reporting routes that become Invalid. 1637 6.10.1. LocalRoute State Changes 1639 During normal operation, AODVv2 does not require any explicit 1640 timeouts to manage the lifetime of a route. At any time, any 1641 LocalRoute MAY be examined and updated according to the rules below. 1642 In case a Routing Information Base is used for forwarding, the 1643 corresponding RIB entry MUST be updated as soon as the state of a 1644 LocalRoute.State changes. Otherwise, if timers are not used to 1645 prompt updates of LocalRoute.State, the LocalRoute.State MUST be 1646 checked before IP packet forwarding and before any operation based on 1647 LocalRoute.State. 1649 Route timeout behaviour is as follows: 1651 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1652 LocalRoute.LastSeqNumUpdate. 1654 o An Idle route MUST become Active when used to forward an IP 1655 packet. If the route is not used to forward an IP packet within 1656 MAX_IDLETIME, LocalRoute.State MUST become Invalid. 1658 o An Invalid route SHOULD remain in the Local Route Set, since 1659 LocalRoute.SeqNum is used to classify future information about 1660 LocalRoute.Address as stale or fresh. 1662 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1663 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 0. 1664 This is required to ensure that any AODVv2 routers following the 1665 initialization procedure can safely begin routing functions using 1666 a new sequence number. A LocalRoute with LocalRoute.State set to 1667 Active or Idle can remain in the Local Route Set after the 1668 sequence number has been set to 0, for example if the route is 1669 reliably carrying traffic. If LocalRoute.State is Invalid, or 1670 later becomes Invalid, the LocalRoute MUST be expunged from the 1671 Local Route Set. 1673 LocalRoutes can become Invalid before a timeout occurs: 1675 o If an external mechanism reports a link as broken, all LocalRoutes 1676 using that link for LocalRoute.NextHop MUST immediately have 1677 LocalRoute.State set to Invalid. 1679 o LocalRoute.State MUST immediately be set to Invalid if a Route 1680 Error (RERR) message is received where: 1682 * The sender is LocalRoute.NextHop or PktSource is a Router 1683 Client address 1685 * There is an Address in AddressList which matches 1686 LocalRoute.Address, and: 1688 + The prefix length associated with this Address, if any, 1689 matches LocalRoute.PrefixLength 1691 + The sequence number associated with this Address, if any, is 1692 newer or equal to LocalRoute.SeqNum (see Section 4.4) 1694 + The metric type associated with this Address matches 1695 LocalRoute.MetricType 1697 A LocalRoute can be Confirmed by inferring connectivity to OrigAddr. 1699 o When an AODVv2 router sends an RREP to OrigAddr for destination 1700 TargAddr, and subsequently the AODVv2 router receives a packet 1701 from OrigAddr with destination TargAddr, the AODVv2 router infers 1702 that the route to OrigAddr has been confirmed. The corresponding 1703 state for LocalRoute.OrigAddr is changed to Active. 1705 LocalRoutes are updated when Neighbor.State is updated: 1707 o While the value of Neighbor.State is set to Heard, any routes in 1708 the Local Route Set using that neighbor as a next hop MUST have 1709 LocalRoute.State set to Unconfirmed. 1711 o When the value of Neighbor.State is set to Blacklisted, any valid 1712 routes in the Local Route Set using that neighbor for their next 1713 hop MUST have LocalRoute.State set to Invalid. 1715 o When a Neighbor Set entry is removed, all routes in the Local 1716 Route Set using that neighbor as next hop MUST have 1717 LocalRoute.State set to Invalid. 1719 Memory constrained devices MAY choose to expunge routes from the 1720 AODVv2 Local Route Set at other times, but MUST adhere to the 1721 following rules: 1723 o An Active route MUST NOT be expunged, as it is in use. If 1724 deleted, IP traffic forwarded to this router will prompt 1725 generation of a Route Error message, and it will be necessary for 1726 a Route Request to be generated by the originator's router to re- 1727 establish the route. 1729 o An Idle route SHOULD NOT be expunged, as it is still valid for 1730 forwarding IP traffic. If deleted, this could result in dropped 1731 IP packets and a Route Request could be generated to re-establish 1732 the route. 1734 o Any Invalid route MAY be expunged. Least recently used Invalid 1735 routes SHOULD be expunged first, since the sequence number 1736 information is less likely to be useful. 1738 o An Unconfirmed route MUST NOT be expunged if it was installed 1739 within the last RREQ_WAIT_TIME, because it may correspond to a 1740 route discovery in progress. A Route Reply message might be 1741 received which needs to use the LocalRoute.NextHop information. 1742 Otherwise, it MAY be expunged. 1744 6.10.2. Reporting Invalid Routes 1746 When LocalRoute.State changes from Active to Invalid as a result of a 1747 broken link or a received Route Error (RERR) message, other AODVv2 1748 routers MUST be informed by sending an RERR message containing 1749 details of the invalidated route. 1751 An RERR message MUST also be sent when an AODVv2 router receives an 1752 RREP message to forward, but the LocalRoute to the OrigPrefix in the 1753 RREP has been lost or is marked as Invalid. 1755 An RERR message MUST also be sent when an AODVv2 router receives an 1756 RREP message to forward, but the LocalRoute to the OrigAddr in the 1757 RREP has been lost or is marked as Invalid. 1759 The packet or message triggering the RERR MUST be discarded. 1761 Generation of an RERR message is described in Section 7.4.1. 1763 7. AODVv2 Protocol Messages 1765 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1766 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1767 (RERR). 1769 Each AODVv2 message is defined as a set of data. Rules for the 1770 generation, reception and forwarding of each message type are 1771 described in the following sections. Section 8 discusses how the 1772 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1773 TLVs. 1775 7.1. Route Request (RREQ) Message 1777 Route Request messages are used in route discovery operations to 1778 request a route to a specified target address. RREQ messages have 1779 the following contents: 1781 +-----------------------------------------------------------------+ 1782 | msg_hop_limit | 1783 +-----------------------------------------------------------------+ 1784 | AddressList | 1785 +-----------------------------------------------------------------+ 1786 | PrefixLengthList (optional) | 1787 +-----------------------------------------------------------------+ 1788 | OrigSeqNum, (optional) TargSeqNum | 1789 +-----------------------------------------------------------------+ 1790 | MetricType | 1791 +-----------------------------------------------------------------+ 1792 | OrigMetric | 1793 +-----------------------------------------------------------------+ 1795 Figure 1: RREQ message contents 1797 msg_hop_limit 1798 The remaining number of hops allowed for dissemination of the RREQ 1799 message. 1801 AddressList 1802 Contains: * OrigPrefix, from the Router Client Set entry which 1803 includes OrigAddr, the source address of the IP packet for which a 1804 route is requested, * TargPrefix, set to TargAddr, the destination 1805 address of the IP packet for which a route is requested, and * 1806 Optionally, if RouterClient.SeqNoRtr is true, the IP address of 1807 OrigRtr -- i.e., the router that originated the Sequence Number 1808 for this RREQ. 1810 PrefixLengthList 1811 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1812 associated with the Router Client Set entry which includes 1813 OrigAddr. If omitted, the prefix length is equal to OrigAddr's 1814 address length in bits. 1816 OrigSeqNum 1817 The sequence number associated with OrigPrefix. 1819 TargSeqNum 1820 A sequence number associated with an existing Invalid route to 1821 TargAddr. This MAY be included if available. 1823 MetricType 1824 The metric type associated with OrigMetric. 1826 OrigMetric 1827 The metric value associated with the route to OrigPrefix, as seen 1828 from the sender of the message. 1830 7.1.1. RREQ Generation 1832 An RREQ is generated when an IP packet needs to be forwarded for a 1833 Router Client, and no valid route currently exists for the packet's 1834 destination in the Routing Information Base. 1836 Before creating an RREQ, the router SHOULD check the Multicast Route 1837 Message Set to see if an RREQ has recently been sent for the 1838 requested destination. If so, and the wait time for a reply has not 1839 yet been reached, the router SHOULD continue to await a response 1840 without generating a new RREQ. If the timeout has been reached, a 1841 new RREQ MAY be generated. If buffering is configured, incoming IP 1842 packets awaiting this route SHOULD be buffered until the route 1843 discovery is completed. 1845 If the limit for the rate of AODVv2 control message generation has 1846 been reached, no message SHOULD be generated. 1848 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1849 this procedure: 1851 1. Set msg_hop_limit := MAX_HOPCOUNT 1853 2. Set AddressList := {OrigPrefix, TargPrefix} 1855 3. For the PrefixLengthList: 1857 * If OrigAddr is part of an address range configured as a Router 1858 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1859 null}. 1861 * Otherwise, omit PrefixLengthList. 1863 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 1864 IP address to AddressList, with AddressType SeqNoRtr. 1866 4. For OrigSeqNum: 1868 * Increment the router Sequence Number as specified in 1869 Section 4.4. 1871 * Set OrigSeqNum := router Sequence Number. 1873 5. For TargSeqNum: 1875 * If an Invalid route exists in the Local Route Set matching 1876 TargAddr using longest prefix matching and has a valid 1877 sequence number, set TargSeqNum := LocalRoute.SeqNum. 1879 * If no Invalid route exists in the Local Route Set matching 1880 TargAddr, or the route doesn't have a sequence number, omit 1881 TargSeqNum. 1883 6. Include MetricType and set the type accordingly 1885 7. Find the Router Client Set entry where RouterClient.IPAddress == 1886 OrigPrefix: 1888 * Set OrigMetric := RouterClient.Cost 1890 This AODVv2 message is used to create a corresponding [RFC5444] 1891 message (see Section 8) which is handed to the RFC5444 multiplexer 1892 for further processing. By default, the multiplexer is instructed to 1893 multicast the message to LL-MANET-Routers on all interfaces 1894 configured for AODVv2 operation. The RREP MUST be sent over 1895 LocalRoute[OrigPrefix].NextHopInterface. 1897 7.1.2. RREQ Reception 1899 Upon receiving a Route Request, an AODVv2 router performs the 1900 following steps: 1902 1. Check and update the Neighbor Set according to Section 6.3 1904 * If the sender has Neighbor.State set to Blacklisted, ignore 1905 this RREQ for further processing. 1907 2. Verify that the message contains the required data: 1908 msg_hop_limit, OrigPrefix, TargPrefix, OrigSeqNum, and 1909 OrigMetric, and that OrigPrefix and TargPrefix are valid 1910 addresses 1912 * If not, ignore this RREQ for further processing. 1914 3. Check that the MetricType is supported and configured for use 1915 * If not, ignore this RREQ for further processing. 1917 4. Verify that the cost of the advertised route will not exceed the 1918 maximum allowed metric value for the metric type (Metric <= 1919 MAX_METRIC[MetricType] - Cost(L)) 1921 * If it will, ignore this RREQ for further processing. 1923 5. Process the route to OrigPrefix as specified in Section 6.7 1925 6. Check if the information in the message is redundant by comparing 1926 to entries in the Multicast Route Message Set, following the 1927 procedure in Section 6.8 1929 * If redundant, ignore this RREQ for further processing. 1931 * If not redundant, create a new entry in the Multicast Route 1932 Message Set and continue processing. 1934 7. Check if the TargPrefix matches an entry in the Router Client Set 1936 * If so, generate an RREP as specified in Section 7.2.1. 1938 * If not, continue to RREQ forwarding. 1940 7.1.3. RREQ Forwarding 1942 By forwarding an RREQ, a router advertises that it will forward IP 1943 packets to the OrigPrefix contained in the RREQ according to the 1944 information enclosed. The router MAY choose not to forward the RREQ, 1945 for example if the router is heavily loaded or low on energy and 1946 therefore unwilling to advertise routing capability for more traffic. 1947 This could, however, decrease connectivity in the network or result 1948 in non-optimal paths. 1950 The RREQ SHOULD NOT be forwarded if the limit for the rate of AODVv2 1951 control message generation has been reached. 1953 The procedure for RREQ forwarding is as follows: 1955 1. Set msg_hop_limit := received msg_hop_limit - 1 1957 2. If msg_hop_limit is now zero, discontinue the forwarding process 1959 3. Set OrigMetric := LocalRoute[OrigPrefix].Metric 1961 This modified message is handed to the [RFC5444] multiplexer for 1962 further processing. By default, the multiplexer is instructed to 1963 multicast the message to LL-MANET-Routers on all interfaces 1964 configured for AODVv2 operation. 1966 7.2. Route Reply (RREP) Message 1968 When a Route Request message is received, requesting a route to a 1969 target address (TargAddr) which is configured as part of a Router 1970 Client Set entry, a Route Reply message is sent in response. The 1971 RREP offers a route to TargPrefix. 1973 RREP messages have the following contents: 1975 +-----------------------------------------------------------------+ 1976 | msg_hop_limit | 1977 +-----------------------------------------------------------------+ 1978 | AddressList | 1979 +-----------------------------------------------------------------+ 1980 | PrefixLengthList (optional) | 1981 +-----------------------------------------------------------------+ 1982 | TargSeqNum | 1983 +-----------------------------------------------------------------+ 1984 | MetricType | 1985 +-----------------------------------------------------------------+ 1986 | TargMetric | 1987 +-----------------------------------------------------------------+ 1989 Figure 2: RREP message contents 1991 msg_hop_limit 1992 The remaining number of hops allowed for dissemination of the RREP 1993 message. 1995 AddressList 1996 Contains: * OrigPrefix, from the Router Client entry which 1997 includes OrigAddr, the source address of the IP packet for which a 1998 route is requested * TargPrefix, set to TargAddr, the destination 1999 address of the IP packet for which a route is requested. * 2000 Optionally, if RouterClient.SeqNoRtr is true, the IP address of 2001 TargRtr -- i.e., the router that originated the Sequence Number 2002 for this RREP. 2004 PrefixLengthList 2005 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 2006 associated with the Router Client Set entry which includes 2007 TargAddr. If omitted, the prefix length is equal to TargAddr's 2008 address length, in bits. 2010 TargSeqNum 2011 The sequence number associated with TargPrefix. 2013 MetricType 2014 The metric type associated with TargMetric. 2016 TargMetric 2017 The metric value associated with the route to TargPrefix, as seen 2018 from the sender of the message. 2020 7.2.1. RREP Generation 2022 A Route Reply message is generated when a Route Request for a Router 2023 Client of the AODVv2 router arrives. This is the case when 2024 RteMsg.TargPrefix matches an entry in the Router Client Set of the 2025 AODVv2 router. 2027 Before creating an RREP, the router SHOULD check if 2028 CONTROL_TRAFFIC_LIMIT has been reached. If so, the RREP SHOULD NOT 2029 be created. 2031 The RREP will follow the path of the route to OrigPrefix. If the 2032 best route to OrigPrefix in the Local Route Set is Unconfirmed, the 2033 link to the next hop neighbor is not yet confirmed as bidirectional 2034 (as described in Section 6.2). In this case an RREP_Ack MUST also be 2035 sent as described in Section 7.3, in order to request an 2036 acknowledgement message from the next hop router to prove that the 2037 link is bidirectional. If the best route to OrigPrefix in the Local 2038 Route Set is valid, the link to the next hop neighbor is already 2039 confirmed as bidirectional, and no acknowledgement is required. 2041 Implementations MAY allow a number of retries of the RREP if a 2042 requested acknowledgement is not received within 2043 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 2044 maximum of RREP_RETRIES, using the same exponential backoff described 2045 in Section 6.6 for RREQ retries. The acknowledgement MUST be 2046 considered to have failed after the wait time for an RREP_Ack 2047 response to the final RREP. 2049 To generate the RREP, the router (also referred to as RREP_Gen) 2050 follows this procedure: 2052 1. Set msg_hop_limit := MAX_HOPCOUNT - msg_hop_limit from the 2053 received RREQ message 2055 2. Set Address List := {OrigPrefix, TargPrefix} 2057 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 2058 IP address to AddressList, with AddressType SeqNoRtr. 2060 3. For the PrefixLengthList: 2062 * If TargAddr is part of an address range configured as a Router 2063 Client, set PrefixLengthList := {null, 2064 RouterClient.PrefixLength}. 2066 * Otherwise, omit PrefixLengthList. 2068 4. For the TargSeqNum: 2070 * Increment the router Sequence Number as specified in 2071 Section 4.4. 2073 * Set TargSeqNum := router Sequence Number. 2075 5. Include MetricType and set the type to match the MetricType in 2076 the received RREQ message. 2078 6. Set TargMetric := RouterClient.Cost for the Router Client Set 2079 entry which includes TargAddr. 2081 This AODVv2 message is used to create a corresponding [RFC5444] 2082 message (see Section 8) which is handed to the RFC5444 multiplexer 2083 for further processing. The multiplexer is instructed to unicast the 2084 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2085 LocalRoute[OrigPrefix].NextHopInterface. 2087 7.2.2. RREP Reception 2089 Upon receiving a Route Reply, an AODVv2 router performs the following 2090 steps: 2092 1. Verify that the message contains the required data: 2093 msg_hop_limit, OrigPrefix, TargPrefix, TargSeqNum, and 2094 TargMetric, and that OrigPrefix and TargPrefix are valid 2095 addresses 2097 * If not, ignore this RREP for further processing. 2099 2. Check that the MetricType is supported and configured for use 2101 * If not, ignore this RREP for further processing. 2103 3. If this RREP does not correspond to an RREQ generated or 2104 forwarded in the last RREQ_WAIT_TIME, ignore for further 2105 processing. 2107 4. If the Multicast Route Message Set does not contain an entry 2108 where: 2110 o RteMsg.OrigPrefix == RREP.OrigPrefix 2112 o RteMsg.OrigPrefixLen == RREP.OrigPrefixLen 2114 o RteMsg.TargAddr exists within RREP.TargPrefix 2116 o RteMsg.OrigSeqNum <= RREP.OrigSeqNum 2118 o RteMsg.SeqNoRtr <= RREP.SeqNoRtr 2120 o RteMsg.MetricType == RREP.MetricType 2122 o RteMsg.Timestamp > CurrentTime - RREQ_WAIT_TIME 2124 o RteMsg.Interface == The interface on which the RREP was received 2126 then, ignore this RREP for further processing, since it does not 2127 correspond to a previously sent RREQ. 2129 1. Update the Neighbor Set according to Section 6.3 2131 2. Verify that the cost of the advertised route does not exceed the 2132 maximum allowed metric value for the metric type (Metric <= 2133 MAX_METRIC[MetricType] - Cost(L)) 2135 * If it does, ignore this RREP for further processing. 2137 3. Process the route to TargPrefix as specified in Section 6.7 2139 4. Check if the message is redundant by comparing to entries in the 2140 Multicast Route Message Set (Section 6.8) 2142 * If redundant, ignore this RREP for further processing. 2144 * If not redundant, save the information in the Multicast Route 2145 Message Set to identify future redundant RREP messages and 2146 continue processing. 2148 5. Check if the OrigPrefix matches an entry in the Router Client Set 2150 * If so, no further processing is necessary. 2152 * If not, continue to Step 10. CEP: There is no step 10. 2154 6. Check if a valid (Active or Idle) or Unconfirmed LocalRoute 2155 exists to OrigPrefix 2157 * If so, continue to RREP forwarding. 2159 * If not, a Route Error message SHOULD be transmitted toward 2160 TargPrefix according to Section 7.4.1 and the RREP SHOULD be 2161 discarded and not forwarded. 2163 7.2.3. RREP Forwarding 2165 A received Route Reply message is forwarded toward OrigPrefix. By 2166 forwarding an RREP, a router advertises that it will forward IP 2167 packets to TargPrefix. 2169 The RREP SHOULD NOT be forwarded if CONTROL_TRAFFIC_LIMIT has been 2170 reached. Otherwise, the router MUST forward the RREP. 2172 The procedure for RREP forwarding is as follows: 2174 1. Set msg_hop_limit := received msg_hop_limit - 1 2176 2. If msg_hop_limit is now zero, do not continue the forwarding 2177 process 2179 3. Set TargMetric := LocalRoute[TargPrefix].Metric 2181 This modified message is handed to the [RFC5444] multiplexer for 2182 further processing. The multiplexer is instructed to unicast the 2183 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2184 LocalRoute[OrigPrefix].NextHopInterface. 2186 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2188 The Route Reply Acknowledgement is used as both a request and a 2189 response message to test bidirectionality of a link over which a 2190 Route Reply has also been sent. The router which forwards the RREP 2191 MUST send a Route Reply Acknowledgement message to the intended next 2192 hop, if the link to the next hop neighbor is not yet confirmed as 2193 bidirectional. 2195 The receiving router MUST then reply with a Route Reply 2196 Acknowledgement response message. 2198 When the Route Reply Acknowledgement response message is received by 2199 the sender of the RREP, it confirms that the link between the two 2200 routers is bidirectional (see Section 6.2). 2202 If the Route Reply Acknowledgement is not received within 2203 RREP_Ack_SENT_TIMEOUT, the link is determined to be unidirectional. 2205 +-----------------------------------------------------------------+ 2206 | AckReq (optional) | 2207 +-----------------------------------------------------------------+ 2209 Figure 3: RREP_Ack message contents 2211 7.3.1. RREP_Ack Request Generation 2213 An RREP_Ack MUST be generated if a Route Reply is sent over a link 2214 which is not known to be bidirectional. It includes an AckReq 2215 element to indicate that it is a request for acknowledgement. 2217 The RREP_Ack SHOULD NOT be generated if the limit for the rate of 2218 AODVv2 control message generation has been reached. 2220 The [RFC5444] representation of the RREP_Ack is discussed in 2221 Section 8. 2223 The RREP_Ack request MUST be sent unicast to the 2224 LocalRoute[OrigPrefix].NextHop via 2225 LocalRoute[OrigPrefix].NextHopInterface. The multiplexer MAY be 2226 instructed to send the RREP_Ack in the same [RFC5444] packet as the 2227 RREP. 2229 The Neighbor Set entry for LocalRoute[OrigPrefix].NextHop MUST also 2230 be updated to indicate that an RREP_Ack is required (see 2231 Section 6.3). 2233 7.3.2. RREP_Ack Reception 2235 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2236 steps: 2238 1. Check if an AckReq element is included: 2240 * If so, create an RREP_Ack Response as described in 2241 Section 7.3.3. No further processing is required. 2243 * If not, continue to step 2. 2245 2. Check if the RREP_Ack was expected: 2247 * Check if the Neighbor Set contains an entry where: 2249 + Neighbor.IPAddress == IP.SourceAddress of the RREP_Ack 2250 message 2252 + Neighbor.State == Heard 2254 + Neighbor.Timeout < CurrentTime 2256 + Neighbor.Interface matches the interface on which the 2257 RREP_Ack was received 2259 * If it does, the router sets Neighbor.Timeout to INFINITY_TIME, 2260 and processing continues to Step 3. 2262 * Otherwise no actions are required and processing ends. 2264 3. Update the Neighbor Set according to Section 6.3, including 2265 updating routes using this Neighbor as LocalRoute.NextHop. 2267 7.3.3. RREP_Ack Response Generation 2269 An RREP_Ack response MUST be generated if a received RREP_Ack 2270 includes an AckReq. 2272 The RREP_Ack response SHOULD NOT be generated if the limit for the 2273 rate of AODVv2 control message generation has been reached. 2275 There is no further data in an RREP_Ack response. The [RFC5444] 2276 representation is discussed in Section 8. In this case, the 2277 multiplexer is instructed to unicast the RREP_Ack to the source IP 2278 address of the RREP_Ack message that requested it, over the same 2279 interface on which the RREP_Ack was received. 2281 7.4. Route Error (RERR) Message 2283 A Route Error message is generated by an AODVv2 router to notify 2284 other AODVv2 routers of routes that are no longer available. An RERR 2285 message has the following contents: 2287 +-----------------------------------------------------------------+ 2288 | PktSource (optional) | 2289 +-----------------------------------------------------------------+ 2290 | AddressList | 2291 +-----------------------------------------------------------------+ 2292 | PrefixLengthList (optional) | 2293 +-----------------------------------------------------------------+ 2294 | SeqNumList (optional) | 2295 +-----------------------------------------------------------------+ 2296 | MetricTypeList | 2297 +-----------------------------------------------------------------+ 2299 Figure 4: RERR message contents 2301 PktSource 2302 The source address of the IP packet triggering the RERR. If the 2303 RERR is triggered by a broken link, PktSource is not required. 2305 AddressList 2306 The addresses of the routes not available through RERR_Gen. 2308 PrefixLengthList 2309 The prefix lengths, in bits, associated with the routes not 2310 available through RERR_Gen. These values indicate whether routes 2311 represent a single device or an address range. 2313 SeqNumList 2314 The sequence numbers of the routes not available through RERR_Gen 2315 (where known). 2317 MetricTypeList 2318 The metric types associated with the routes not available through 2319 RERR_Gen. 2321 7.4.1. RERR Generation 2323 A Route Error message is generated when an AODVv2 router (also 2324 referred to as RERR_Gen) needs to report that a destination is not 2325 reachable. There are three events that cause this response: 2327 o When an IP packet that has been forwarded from another router, but 2328 cannot be forwarded further because there is no valid route in the 2329 Routing Information Base for its destination, the source of the 2330 packet needs to be informed that the route to the destination of 2331 the packet does not exist. The RERR generated MUST include 2332 PktSource set to the source address of the IP packet, and MUST 2333 contain only one unreachable address in the AddressList, i.e., the 2334 destination address of the IP packet. RERR_Gen MUST discard the 2335 IP packet that triggered generation of the RERR. The prefix 2336 length, sequence number and metric type SHOULD be included if 2337 known from an existing Invalid LocalRoute to the unreachable 2338 address. 2340 o When an RREP message cannot be forwarded because the LocalRoute to 2341 OrigPrefix has been lost or is Invalid, RREP_Gen needs to be 2342 informed that the route to OrigPrefix does not exist. The RERR 2343 generated MUST include PktSource set to the TargPrefix of the 2344 RREP, and MUST contain only one unreachable address in the 2345 AddressList, the OrigPrefix from the RREP. RERR_Gen MUST discard 2346 the RREP message that triggered generation of the RERR. The 2347 prefix length, sequence number and metric type SHOULD be included 2348 if known from an Invalid LocalRoute to the unreachable address. 2350 o When a link breaks, multiple LocalRoutes may become Invalid, and 2351 the RERR generated MAY contain multiple unreachable addresses. 2352 The RERR MUST include MetricTypeList. PktSource is omitted. All 2353 previously Active LocalRoutes that used the broken link MUST be 2354 reported. The AddressList, SeqNumList, and MetricTypeList will 2355 contain entries for each LocalRoute which has become Invalid. 2356 PrefixLengthList will be included if needed to report invalid 2357 routes to a non-default prefix. An RERR message is only sent if 2358 an Active LocalRoute becomes Invalid, though an AODVv2 router can 2359 also include Idle LocalRoutes that become Invalid if the 2360 configuration parameter ENABLE_IDLE_IN_RERR is set (see 2361 Section 10.3). 2363 The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been 2364 reached. The RERR also SHOULD NOT be generated if it is a duplicate, 2365 as determined by Section 6.9. 2367 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2368 from the address of one of its Router Clients, it forwards the ICMP 2369 packet in the same way as any other IP packet, and will not generate 2370 any RERR message based on the contents of the ICMP packet. 2372 To generate the RERR, the router follows this procedure: 2374 1. If necessary, include PktSource and set the value as given above 2376 2. For each LocalRoute that needs to be reported: 2378 * Insert LocalRoute.Address into the AddressList. 2380 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2381 and not equal to the address length. 2383 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2385 * Insert LocalRoute.MetricType into MetricTypeList. 2387 The AODVv2 message is used to create a corresponding [RFC5444] 2388 message (see Section 8). 2390 If the RERR is sent in response to an undeliverable IP packet or RREP 2391 message, i.e., if PktSource is included, the RERR SHOULD be sent 2392 unicast to the next hop on the route to PktSource. It MUST be sent 2393 over the same interface on which the undeliverable IP packet was 2394 received. If there is no route to PktSource, the RERR SHOULD be 2395 multicast to LL-MANET-Routers. If the RERR is sent in response to a 2396 broken link, i.e., PktSource is not included, the RERR is, by 2397 default, multicast to LL-MANET-Routers. 2399 7.4.2. RERR Reception 2401 Upon receiving a Route Error, an AODVv2 router performs the following 2402 steps: 2404 1. Verify that the message contains the required data: at least one 2405 unreachable address 2407 * If not, ignore this RERR for further processing. 2409 2. For each address in the AddressList, check that: 2411 * The address is valid (routable and unicast). 2413 * The MetricType is supported and configured for use. 2415 * There is a LocalRoute with the same MetricType matching the 2416 address using longest prefix matching. 2418 * Either the LocalRoute's next hop is the sender of the RERR and 2419 the next hop interface is the interface on which the RERR was 2420 received, or PktSource is present in the RERR and is a Router 2421 Client address. 2423 * The unreachable address' sequence number is either unknown, or 2424 is greater than the LocalRoute's sequence number. 2426 If any of the above are false the address does not match a 2427 LocalRoute and MUST NOT be processed or regenerated in a RERR. 2429 If all of the above are true, the LocalRoute which matches the 2430 address is no longer valid. If the LocalRoute was previously 2431 Active, it MUST be reported in a regenerated RERR. If the 2432 LocalRoute was previously Idle, it MAY be reported in a 2433 regenerated RERR, if ENABLE_IDLE_IN_RERR is configured. The 2434 Local Route Set MUST be updated according to these rules: 2436 * If the LocalRoute's prefix length is the same as the 2437 unreachable address' prefix length, set LocalRoute.State to 2438 Invalid. 2440 * If the LocalRoute's prefix length is longer than the 2441 unreachable address' prefix length, the LocalRoute MUST be 2442 expunged from the Local Route Set, since it is a sub-route of 2443 the route which is reported to be Invalid. 2445 * If the prefix length is different, create a new LocalRoute 2446 with the unreachable address, and its prefix length and 2447 sequence number, and set LocalRoute.State to Invalid. These 2448 Invalid routes are retained to avoid processing stale 2449 messages. 2451 * Update the sequence number on the existing LocalRoute, if the 2452 reported sequence number is determined to be newer using the 2453 comparison technique described in Section 4.4. 2455 3. If there are previously Active LocalRoutes that MUST be reported, 2456 as identified in step 2.: 2458 * Regenerate the RERR as detailed in Section 7.4.3. 2460 7.4.3. RERR Regeneration 2462 The Route Error message SHOULD NOT be regenerated if 2463 CONTROL_TRAFFIC_LIMIT has been reached. 2465 The procedure for RERR regeneration is as follows: 2467 1. If PktSource was included in the original RERR, and PktSource is 2468 not a Router Client, copy it into the regenerated RERR 2470 2. For each LocalRoute that needs to be reported as identified in 2471 Section 7.4.1: 2473 * Insert LocalRoute.Address into the AddressList. 2475 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2476 and not equal to the address length. 2478 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2480 * Insert LocalRoute.MetricType into MetricTypeList. 2482 The AODVv2 message is used to create a corresponding [RFC5444] 2483 message (see Section 8). If the RERR contains PktSource, the 2484 regenerated RERR SHOULD be sent unicast to the next hop on the 2485 LocalRoute to PktSource. It MUST be sent over the same interface on 2486 which the undeliverable IP packet was received. If there is no route 2487 to PktSource, or PktSource is a Router Client, it SHOULD be multicast 2488 to LL-MANET-Routers. If the RERR is sent in response to a broken 2489 link, the RERR is, by default, multicast to LL-MANET-Routers. 2491 8. RFC 5444 Representation 2493 AODVv2 specifies that all control messages between routers MUST use 2494 the Generalized Mobile Ad Hoc Network Packet/Message Format 2495 [RFC5444], and therefore AODVv2's route messages comprise data which 2496 is mapped to message elements in [RFC5444]. 2498 [RFC5444] provides a multiplexed transport for multiple protocols. 2499 An [RFC5444] implementation MAY choose to optimize the content of 2500 certain elements during message creation to reduce control message 2501 overhead. 2503 A brief summary of the [RFC5444] format: 2505 1. A packet contains zero or more messages 2507 2. A message contains a Message Header, one Message TLV Block, zero 2508 or more Address Blocks, and one Address Block TLV Block per 2509 Address Block 2511 3. The Message TLV Block MAY contain zero or more Message TLVs 2513 4. An Address Block TLV Block MAY include zero or more Address Block 2514 TLVs 2516 5. Each TLV value in an Address Block TLV Block can be associated 2517 with all of the addresses, or with a contiguous set of addresses, 2518 or with a single address in the Address Block 2520 AODVv2 does not require access to the [RFC5444] packet header. 2522 In the message header, AODVv2 uses , and 2523 . The field indicates the length 2524 of any addresses in the message, using := (address 2525 length in octets - 1), i.e. 3 for IPv4 and 15 for IPv6. 2527 The addresses in an Address Block MAY appear in any order, and values 2528 in a TLV in the Address Block TLV Block must be associated with the 2529 correct address in the Address Block by the [RFC5444] implementation. 2530 To indicate which value is associated with each address, the AODVv2 2531 message representation uses lists where the order of the addresses in 2532 the AODVv2 AddressList matches the order of values in other data 2533 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2534 [RFC5444] maps this information to Address Block TLVs associated with 2535 the relevant addresses in the Address Block. 2537 Each address included in the Address Block is identified as 2538 OrigPrefix, TargPrefix, PktSource, or Unreachable Address by 2539 including an ADDRESS_TYPE TLV in the Address Block TLV Block. 2541 The following sections show how AODVv2 data is represented in 2542 [RFC5444] messages. In Section 11.3, AODVv2 defines several new 2543 TLVs. 2545 Where the extension type of a TLV is set to zero, this is the default 2546 [RFC5444] value and the extension type will not be included in the 2547 message. 2549 8.1. Route Request Message Representation 2551 8.1.1. Message Header 2553 +---------------+-----------------+---------------------------------+ 2554 | Data | Header Field | Value | 2555 +---------------+-----------------+---------------------------------+ 2556 | None | | RREQ | 2557 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2558 | | | of hops traversed so far by the | 2559 | | | message. | 2560 +---------------+-----------------+---------------------------------+ 2562 8.1.2. Message TLV Block 2564 AODVv2 does not define any Message TLVs for an RREQ message. 2566 8.1.3. Address Block 2568 An RREQ contains OrigPrefix and TargPrefix, and each of these 2569 addresses has an associated prefix length. If the prefix length has 2570 not been included in the AODVv2 message, it is equal to the address 2571 length in bits. 2573 +----------------------------+------------------------------+ 2574 | Data | Address Block | 2575 +----------------------------+------------------------------+ 2576 | OrigPrefix/OrigPrefixLen |
+ | 2577 | TargPrefix/TargPrefixLen |
+ | 2578 | SeqNoRtr/PrefixLen + | 2579 +----------------------------+------------------------------+ 2581 8.1.4. Address Block TLV Block 2583 Address Block TLVs are always associated with one or more addresses 2584 in the Address Block. The following sections show the TLVs that 2585 apply to each address. 2587 8.1.4.1. Address Block TLVs for OrigPrefix 2589 +-------------+--------------+------------+-------------------------+ 2590 | Data | TLV Type | Extension | Value | 2591 | | | Type | | 2592 +-------------+--------------+------------+-------------------------+ 2593 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2594 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2595 | | | | RREQ_Gen, the router | 2596 | | | | which initiated route | 2597 | | | | discovery. | 2598 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2599 | /MetricType | | | route to OrigPrefix, | 2600 | | | | using MetricType. | 2601 +-------------+--------------+------------+-------------------------+ 2603 8.1.4.2. Address Block TLVs for TargPrefix 2605 +------------+--------------+-------------+-------------------------+ 2606 | Data | TLV Type | Extension | Value | 2607 | | | Type | | 2608 +------------+--------------+-------------+-------------------------+ 2609 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2610 | TargSeqNum | SEQ_NUM | 0 | The last known | 2611 | | | | TargSeqNum for | 2612 | | | | TargPrefix. | 2613 +------------+--------------+-------------+-------------------------+ 2615 8.2. Route Reply Message Representation 2616 8.2.1. Message Header 2618 +---------------+-----------------+---------------------------------+ 2619 | Data | Header Field | Value | 2620 +---------------+-----------------+---------------------------------+ 2621 | None | | RREP | 2622 | msg_hop_limit | | MAX_HOPCOUNT - msg_hop_limit | 2623 | | | from the corresponding RREQ, | 2624 | | | reduced by number of hops | 2625 | | | traversed so far by the | 2626 | | | message. | 2627 +---------------+-----------------+---------------------------------+ 2629 8.2.2. Message TLV Block 2631 AODVv2 does not define any Message TLVs for an RREP message. 2633 8.2.3. Address Block 2635 An RREP contains OrigPrefix and TargPrefix, and each of these 2636 addresses has an associated prefix length. If the prefix length has 2637 not been included in the AODVv2 message, it is equal to the address 2638 length in bits. 2640 +----------------------------+------------------------------+ 2641 | Data | Address Block | 2642 +----------------------------+------------------------------+ 2643 | OrigPrefix/OrigPrefixLen |
+ | 2644 | TargPrefix/TargPrefixLen |
+ | 2645 | SeqNoRtr/PrefixLen + | 2646 +----------------------------+------------------------------+ 2648 8.2.4. Address Block TLV Block 2650 Address Block TLVs are always associated with one or more addresses 2651 in the Address Block. The following sections show the TLVs that 2652 apply to each address. 2654 8.2.4.1. Address Block TLVs for OrigPrefix 2656 +-------+---------------+-----------------+-------------+ 2657 | Data | TLV Type | Extension Type | Value | 2658 +-------+---------------+-----------------+-------------+ 2659 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2660 +-------+---------------+-----------------+-------------+ 2662 8.2.4.2. Address Block TLVs for TargPrefix 2664 +--------------+--------------+------------+------------------------+ 2665 | Data | TLV Type | Extension | Value | 2666 | | | Type | | 2667 +--------------+--------------+------------+------------------------+ 2668 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2669 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2670 | | | | RREP_Gen, the router | 2671 | | | | which created the | 2672 | | | | RREP. | 2673 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2674 | /MetricType | | | route to TargPrefix, | 2675 | | | | using MetricType. | 2676 +--------------+--------------+------------+------------------------+ 2678 8.3. Route Reply Acknowledgement Message Representation 2680 8.3.1. Message Header 2682 +-------+---------------+-----------+ 2683 | Data | Header Field | Value | 2684 +-------+---------------+-----------+ 2685 | None | | RREP_Ack | 2686 +-------+---------------+-----------+ 2688 8.3.2. Message TLV Block 2690 AODVv2 defines an AckReq Message TLV, included when an 2691 acknowledgement of this message is required, in order to monitor 2692 adjacency, as described in Section 6.2. 2694 +---------+-----------+-----------------+--------+ 2695 | Data | TLV Type | Extension Type | Value | 2696 +---------+-----------+-----------------+--------+ 2697 | AckReq | ACK_REQ | 0 | None | 2698 +---------+-----------+-----------------+--------+ 2700 8.3.3. Address Block 2702 AODVv2 does not define an Address Block for an RREP_Ack message. 2704 8.3.4. Address Block TLV Block 2706 AODVv2 does not define any Address Block TLVs for an RREP_Ack 2707 message. 2709 8.4. Route Error Message Representation 2711 Route Error Messages MAY be split into multiple [RFC5444] messages 2712 when the desired contents would exceed the MTU. However, all of the 2713 resulting messages MUST have the same message header as described 2714 below. If PktSource is included in the AODVv2 message, it MUST be 2715 included in all of the resulting [RFC5444] messages. 2717 8.4.1. Message Header 2719 +-------+---------------+--------+ 2720 | Data | Header Field | Value | 2721 +-------+---------------+--------+ 2722 | None | | RERR | 2723 +-------+---------------+--------+ 2725 8.4.2. Message TLV Block 2727 AODVv2 does not define any Message TLVs for an RERR message. 2729 8.4.3. Address Block 2731 The Address Block in an RERR MAY contain PktSource, the source 2732 address of the IP packet triggering RERR generation, as detailed in 2733 Section 7.4. The prefix length associated with PktSource is equal to 2734 the address length in bits. 2736 Address Block always contains one address per route that is no longer 2737 valid, and each address has an associated prefix length. If a prefix 2738 length has not been included for this address, it is equal to the 2739 address length in bits. 2741 +------------------------------+------------------------------------+ 2742 | Data | Address Block | 2743 +------------------------------+------------------------------------+ 2744 | PktSource |
+ for | 2745 | | PktSource | 2746 | AddressList/PrefixLengthList |
+ for | 2747 | | each unreachable address in | 2748 | | AddressList | 2749 +------------------------------+------------------------------------+ 2751 8.4.4. Address Block TLV Block 2753 Address Block TLVs are always associated with one or more addresses 2754 in the Address Block. The following sections show the TLVs that 2755 apply to each type of address in the RERR. 2757 8.4.4.1. Address Block TLVs for PktSource 2759 +------------+---------------+-----------------+------------+ 2760 | Data | TLV Type | Extension Type | Value | 2761 +------------+---------------+-----------------+------------+ 2762 | PktSource | ADDRESS_TYPE | 0 | PKTSOURCE | 2763 +------------+---------------+-----------------+------------+ 2765 8.4.4.2. Address Block TLVs for Unreachable Addresses 2767 +----------------+--------------+------------+----------------------+ 2768 | Data | TLV Type | Extension | Value | 2769 | | | Type | | 2770 +----------------+--------------+------------+----------------------+ 2771 | None | ADDRESS_TYPE | 0 | UNREACHABLE | 2772 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2773 | | | | associated with | 2774 | | | | invalid route to the | 2775 | | | | unreachable address. | 2776 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2777 | | | | set to MetricType of | 2778 | | | | the route to the | 2779 | | | | unreachable address. | 2780 +----------------+--------------+------------+----------------------+ 2782 9. Simple External Network Attachment 2784 Figure 5 shows a stub (i.e., non-transit) network of AODVv2 routers 2785 which is attached to an external network via a single External 2786 Network Access Router (ENAR). The interface to the external network 2787 MUST NOT be configured in the InterfaceSet. 2789 As in any externally-attached network, AODVv2 routers and Router 2790 Clients that wish to be reachable from the external network MUST have 2791 IP addresses within the ENAR's routable and topologically correct 2792 prefix (e.g., 191.0.2.0/24 in Figure 5). This AODVv2 network and 2793 networks attached to routers within it will be advertised to the 2794 external network using procedures which are out of scope for this 2795 specification. 2797 /-------------------------\ 2798 / +----------------+ \ 2799 / | AODVv2 Router | \ 2800 | | 191.0.2.2/32 | | 2801 | +----------------+ | Routable 2802 | +-----+--------+ Prefix 2803 | | ENAR | /191.0.2.0/24 2804 | | AODVv2 Router| / 2805 | | 191.0.2.1 |/ /---------------\ 2806 | | serving net +------+ External \ 2807 | | 191.0.2.0/24 | \ Network / 2808 | +-----+--------+ \---------------/ 2809 | +----------------+ | 2810 | | AODVv2 Router | | 2811 | | 191.0.2.3/32 | | 2812 \ +----------------+ / 2813 \ / 2814 \-------------------------/ 2816 Figure 5: Simple External Network Attachment Example 2818 When an AODVv2 router within the AODVv2 MANET wants to discover a 2819 route toward an address on the external network, it uses the normal 2820 AODVv2 route discovery for that IP Destination Address. 2822 The ENAR MUST respond to RREQ on behalf of all external network 2823 destinations, that is, destinations which are not on the configured 2824 191.0.2.0 /24 network. The ENAR MUST NOT respond with a TargPrefix 2825 and TargPrefixLen which includes any of the networks configured as 2826 part of the AODVv2 network. Sending a Route Request for a gateway is 2827 not currently supported. If more than one gateway is configured to 2828 serve the same external network, each such gateway MUST configure 2829 that external network as a Router Client with its IP address as the 2830 value of SeqNoRtr for the RouterClient. 2832 RREQs for addresses inside the AODVv2 network, e.g. destinations on 2833 the configured 191.0.2.0/24 network, are handled using the standard 2834 processes described in Section 7. Note that AODVv2 does not 2835 currently support route discovery for prefixes that do not equal 2836 address length, but RREPs do advertise the prefix on which TargAddr 2837 resides. 2839 When an IP packet from an address on the external network destined 2840 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2841 not have a route toward that destination in its Routing Information 2842 Base, it will perform normal AODVv2 route discovery for that 2843 destination. 2845 Configuring the ENAR as a default router is outside the scope of this 2846 specification. 2848 10. Configuration 2850 AODVv2 uses various parameters which can be grouped into the 2851 following categories: 2853 o Timers 2855 o Protocol constants 2857 o Administrative parameters and controls 2859 This section show the parameters along with their definitions and 2860 default values (if any). 2862 Note that several fields have limited size (bits or bytes). These 2863 sizes and their encoding may place specific limitations on the values 2864 that can be set. 2866 10.1. Timers 2868 AODVv2 requires certain timing information to be associated with 2869 Local Route Set entries and message replies. The default values are 2870 as follows: 2872 +------------------------+----------------+ 2873 | Name | Default Value | 2874 +------------------------+----------------+ 2875 | ACTIVE_INTERVAL | 5 second | 2876 | MAX_IDLETIME | 200 seconds | 2877 | MAX_BLACKLIST_TIME | 200 seconds | 2878 | MAX_SEQNUM_LIFETIME | 300 seconds | 2879 | RERR_TIMEOUT | 3 seconds | 2880 | RteMsg_ENTRY_TIME | 12 seconds | 2881 | RREQ_WAIT_TIME | 2 seconds | 2882 | RREP_Ack_SENT_TIMEOUT | 1 second | 2883 | RREQ_HOLDDOWN_TIME | 10 seconds | 2884 +------------------------+----------------+ 2886 Table 2: Timing Parameter Values 2888 The above timing parameter values have worked well for small and 2889 medium well-connected networks with moderate topology changes. The 2890 timing parameters SHOULD be administratively configurable. Ideally, 2891 for networks with frequent topology changes the AODVv2 parameters 2892 SHOULD be adjusted using experimentally determined values or dynamic 2893 adaptation. For example, in networks with infrequent topology 2894 changes MAX_IDLETIME MAY be set to a much larger value. If the 2895 values were configured differently, the following consequences may be 2896 observed: 2898 o If MAX_SEQNUM_LIFETIME was configured differently across the 2899 network, and any of the routers lost their sequence number or 2900 rebooted, this could result in their next route messages being 2901 classified as stale at any AODVv2 router using a greater value for 2902 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to 2903 the re-initializing router. 2905 o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will 2906 invalidate routes more quickly and free resources used to maintain 2907 them. This can affect bursty traffic flows which have quiet 2908 periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which 2909 has timed out due to perceived inactivity is not reported. When 2910 the bursty traffic resumes, it would cause a RERR to be generated, 2911 and the traffic itself would be dropped. This route would be 2912 removed from all upstream routers, even if those upstream routers 2913 had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route 2914 discovery would be required to re-establish the route, causing 2915 extra routing protocol traffic and disturbance to the bursty 2916 traffic. 2918 o Routers with lower values for MAX_BLACKLIST_TIME would allow 2919 neighboring routers to participate in route discovery sooner than 2920 routers with higher values. This could result in failed route 2921 discoveries if un-blacklisted links are still uni-directional. 2922 Since RREQs are retried, this would not affect success of route 2923 discovery unless this value was so small as to un-blacklist the 2924 router before the RREQ is retried. This value need not be 2925 consistent across the network since it is used for maintaining a 2926 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME. 2928 o Routers with lower values for RERR_TIMEOUT may create more RERR 2929 messages than routers with higher values. This value should be 2930 large enough that a RERR will reach all routers using the route 2931 reported within it before the timer expires, so that no further 2932 data traffic will arrive, and no duplicated RERR messages will be 2933 generated. 2935 o Routers with lower values for RteMsg_ENTRY_TIME may not consider 2936 received redundant multicast route messages as redundant, and may 2937 forward these messages unnecessarily. 2939 o Routers with lower values for RREQ_WAIT_TIME may send more 2940 frequent RREQ messages and wrongly determine that a route does not 2941 exist, if the delay in receiving an RREP is greater than this 2942 interval. 2944 o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly 2945 determine links to neighbors to be unidirectional if an RREP_Ack 2946 is delayed longer than this timeout. 2948 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed 2949 route discoveries sooner than routers with higher values. This 2950 may be an advantage if the network topology is frequently 2951 changing, or may unnecessarily cause more routing protocol 2952 traffic. 2954 MAX_SEQNUM_LIFETIME MUST be configured to have the same values for 2955 all AODVv2 routers in the network. 2957 10.2. Protocol Constants 2959 AODVv2 protocol constants typically do not require changes. The 2960 following table lists these constants, along with their values and a 2961 reference to the section describing their use. 2963 +------------------------+---------+--------------------------------+ 2964 | Name | Default | Description | 2965 +------------------------+---------+--------------------------------+ 2966 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 2967 | RREP_RETRIES | 2 | Section 7.2.1 | 2968 | MAX_METRIC[MetricType] | [TBD] | Section 5 | 2969 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 2970 | MAX_HOPCOUNT | 20 | Limit to number of hops an | 2971 | | | RREQ or RREP message can | 2972 | | | traverse | 2973 | INFINITY_TIME | [TBD] | Maximum expressible clock time | 2974 | | | (Section 6.7.2) | 2975 +------------------------+---------+--------------------------------+ 2977 Table 3: AODVv2 Constants 2979 MAX_HOPCOUNT cannot be larger than 255. 2981 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 2982 value of type MetricType. Field lengths associated with metric 2983 values are found in Section 11.4. 2985 These protocol constants MUST have the same values for all AODVv2 2986 routers in the ad hoc network. If the values were configured 2987 differently, the following consequences may be observed: 2989 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 2990 be more successful at finding routes, at the cost of additional 2991 control traffic. 2993 o RREP_RETRIES: Routers with lower values are more likely to 2994 blacklist neighbors when there is a temporary fluctuation in link 2995 quality. 2997 o MAX_METRIC[MetricType]: No interoperability problems due to 2998 variations on different routers, but routers with lower values may 2999 exhibit overly restrictive behavior during route comparisons. 3001 o MAX_HOPCOUNT: Routers with a value too small would not be able to 3002 discover routes to distant addresses. 3004 o INFINITY_TIME: No interoperability problems due to variations on 3005 different routers, but if a lower value is used, route state 3006 management may exhibit overly restrictive behavior. 3008 10.3. Local Settings 3010 The following table lists AODVv2 parameters which SHOULD be 3011 administratively configured for each router: 3013 +------------------------+------------------------+--------------+ 3014 | Name | Default Value | Description | 3015 +------------------------+------------------------+--------------+ 3016 | InterfaceSet | | Section 4.1 | 3017 | Router Client Set | | Section 4.2 | 3018 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 3019 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 3020 | CONTROL_TRAFFIC_LIMIT | [TBD - 50 pkts/sec?] | Section 7 | 3021 +------------------------+------------------------+--------------+ 3023 Table 4: Configuration for Local Settings 3025 10.4. Network-Wide Settings 3027 The following administrative controls MAY be used to change the 3028 operation of the network. The same settings SHOULD be used across 3029 the network. Inconsistent settings at different routers in the 3030 network will not result in protocol errors, but poor performance may 3031 result. 3033 +----------------------+-----------+----------------+ 3034 | Name | Default | Description | 3035 +----------------------+-----------+----------------+ 3036 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 3037 +----------------------+-----------+----------------+ 3039 Table 5: Configuration for Network-Wide Settings 3041 11. IANA Considerations 3043 This section specifies several [RFC5444] message types and address 3044 tlv-types required for AODVv2. 3046 11.1. RFC 5444 Message Type Allocation 3048 This specification defines four Message Types, to be allocated from 3049 the 0-223 range of the "Message Types" namespace defined in 3050 [RFC5444]. 3052 +-----------------------------------------+-----------+ 3053 | Name of Message | Type | 3054 +-----------------------------------------+-----------+ 3055 | Route Request (RREQ) | 10 (TBD) | 3056 | Route Reply (RREP) | 11 (TBD) | 3057 | Route Error (RERR) | 12 (TBD) | 3058 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 3059 +-----------------------------------------+-----------+ 3061 11.2. RFC 5444 Message TLV Types 3063 This specification defines one Message TLV Type, to be allocated from 3064 the Message-Type-specific "Message TLV Types" namespace defined in 3065 [RFC5444], as specified in Table 6. 3067 +------------------------+----------+---------------+---------------+ 3068 | Name of TLV | Type | Length | Reference | 3069 | | | (octets) | | 3070 +------------------------+----------+---------------+---------------+ 3071 | ACK_REQ | 128 | 0 | Section 6.2 | 3072 | | (TBD) | | | 3073 +------------------------+----------+---------------+---------------+ 3075 Table 6: AODVv2 Message TLV Types 3077 11.3. RFC 5444 Address Block TLV Type Allocation 3079 This specification defines three Address Block TLV Types, to be 3080 allocated from the Message-Type-specific "Address Block TLV Types" 3081 namespace defined in [RFC5444], as specified in Table 7. 3083 +------------------------+----------+---------------+---------------+ 3084 | Name of TLV | Type | Length | Reference | 3085 | | | (octets) | | 3086 +------------------------+----------+---------------+---------------+ 3087 | PATH_METRIC | 129 | depends on | Section 7 | 3088 | | (TBD) | MetricType | | 3089 | SEQ_NUM | 130 | 2 | Section 7 | 3090 | | (TBD) | | | 3091 | ADDRESS_TYPE | 131 | 1 | Section 8 | 3092 | | (TBD) | | | 3093 +------------------------+----------+---------------+---------------+ 3095 Table 7: AODVv2 Address Block TLV Types 3097 11.4. MetricType Allocation 3099 The metric types used by AODVv2 are identified according to Table 8. 3100 All implementations MUST use these values. 3102 +---------------------+----------+--------------------+ 3103 | Name of MetricType | Type | Metric Value Size | 3104 +---------------------+----------+--------------------+ 3105 | Unassigned | 0 | Undefined | 3106 | Hop Count | 1 | 1 octet | 3107 | Unallocated | 2 - 254 | TBD | 3108 | Reserved | 255 | Undefined | 3109 +---------------------+----------+--------------------+ 3111 Table 8: AODVv2 Metric Types 3113 11.5. ADDRESS_TYPE TLV Values 3115 These values are used in the [RFC5444] Address Type TLV discussed in 3116 Section 8. All implementations MUST use these values. 3118 +---------------+--------+ 3119 | Address Type | Value | 3120 +---------------+--------+ 3121 | ORIGPREFIX | 0 | 3122 | TARGPREFIX | 1 | 3123 | UNREACHABLE | 2 | 3124 | PKTSOURCE | 3 | 3125 | UNSPECIFIED | 255 | 3126 +---------------+--------+ 3128 Table 9: AODVv2 Address Types 3130 12. Security Considerations 3132 This section describes various security considerations and potential 3133 avenues to secure AODVv2 routing. The main objective of the AODVv2 3134 protocol is for each router to communicate reachability information 3135 about addresses for which it is responsible, and for routes it has 3136 learned from other AODVv2 routers. 3138 Networks using AODVv2 to maintain connectivity and establish routes 3139 on demand may be vulnerable to certain well-known types of threats, 3140 which will be detailed in this section. Some of the threats 3141 described can be mitigated or eliminated. Tools to do so will be 3142 described. 3144 With the exception of metric values, AODVv2 assures the integrity of 3145 all RteMsg data end-to-end though the use of ICVs (see 3146 Section 12.4.2. 3148 The on-demand nature of AODVv2 route discovery automatically reduces 3149 the vulnerability to route disruption. Since control traffic for 3150 updating route tables is diminished, there is less opportunity for 3151 attack and failure. 3153 12.1. Availability 3155 Threats to AODVv2 which reduce availability are considered below. 3157 12.1.1. Denial of Service 3159 Flooding attacks using RREQ amount to a (BLIND) denial of service for 3160 route discovery: By issuing RREQ messages for targets that don't 3161 exist, an attacker can flood the network, blocking resources and 3162 drowning out legitimate traffic. By triggering the generation of 3163 CONTROL_TRAFFIC_LIMIT amount of messages (for example by sending 3164 RREQs for many non-existent destinations), an attacker can prevent 3165 legitimate messages from being generated. The effect of this attack 3166 is dampened by the fact that duplicate RREQ messages are dropped 3167 (preventing the network from DDoSing itself). Processing 3168 requirements for AODVv2 messages are typically quite small, however 3169 AODVv2 routers receiving RREQs do allocate resources in the form of 3170 Neighbor Set, Local Route Set and Multicast Route Message Set 3171 entries. The attacker can maximize their impact on set growth by 3172 changing OrigPrefix or OrigPrefixLen for each RREQ. If a specific 3173 node is to be targeted, this attack may be carried out in a 3174 DISTRIBUTED fashion, either by compromising its direct neighbors or 3175 by specifying the target's address with TargPrefix and TargPrefixLen. 3176 Note that it might be more economical for the attacker to simply jam 3177 the medium; an attack which AODVv2 cannot defend itself against. 3179 Mitigation: 3181 o If AODVv2 routers always verify that the sender of the RERR 3182 message is trusted, this threat is reduced. Processing 3183 requirements would typically be dominated by calculations to 3184 verify integrity. This has the effect of reducing (but by no 3185 means eliminating) AODVv2's vulnerability to denial of service 3186 attacks. 3188 o Authentication of senders can prevent unauthenticated routers from 3189 launching a Denial of Service attack on another AODVv2 router. 3190 However, this does not protect the network if an attacker has 3191 access to an already authenticated router. 3193 12.1.2. Malicious RERR messages 3195 RERR messages are designed to cause removal of installed routes. A 3196 malicious node could send an RERR message with false information to 3197 attempt to get other routers to remove a route to one or more 3198 specific destinations, therefore disrupting traffic to the advertised 3199 destinations. 3201 Routes will be deleted if an RERR is received, withdrawing a route 3202 for which the sender is the receiver's next hop, under the following 3203 conditions: 3205 o when the RERR includes the MetricType of the installed route, 3207 o includes either no sequence number for the route, or includes a 3208 greater sequence number than the sequence number stored with that 3209 route in the receiver's Local Route Set. 3211 Routes will also be deleted if a received RERR contains a PktSource 3212 address corresponding to a Router Client. 3214 The information necessary to construct a malicious RERR could be 3215 learned by eavesdropping, either by listening to AODVv2 messages or 3216 by watching data packet flows. 3218 When the RERR is multicast, it can be received by many routers in the 3219 ad hoc network, and will be regenerated when processing results in an 3220 active route being removed. This threat could have serious impact on 3221 applications communicating by way of the sender of the RERR message. 3223 o The set of routers which use the malicious router as a next hop 3224 may be targeted with a malicious RERR with no PktSource address 3225 included, if the RERR contains routes for which the malicious 3226 router is a next hop from the receiving router. However, since 3227 the sender of the RERR message is either malicious or broken, it 3228 is better that it is not used as a next hop for these routes 3229 anyway. 3231 o A single router which does not use the malicious router as part of 3232 its route may be targeted with a malicious RERR with a PktSource 3233 address included. 3235 o Replayed RERR messages could be used to disrupt active routes. 3237 Mitigation: 3239 o Protection against eavesdropping of AODVv2 messages would mitigate 3240 this attack to some extent, but eavesdropping of data packets can 3241 also be used to deduce the information about which routes could be 3242 targeted. 3244 o Protection against a malicious router becoming part of a route 3245 will mitigate the attack where a set of routers are targeted. 3246 This will not protect against the attack if a PktSource address is 3247 included. 3249 o By only regenerating RERR messages where active routes are 3250 removed, the spread of the malicious RERR is limited. 3252 o Including sequence numbers in RERR messages offers protection 3253 against attacks using replays of these RERR messages. 3255 o If AODVv2 routers always verify that the sender of the RERR 3256 message is trusted, this threat is reduced. 3258 12.1.3. False Confirmation of Link Bidirectionality 3260 Links could be erroneously treated as bidirectional if malicious 3261 unsolicited or spoofed RREP messages were to be accepted. This would 3262 result in a route being installed which could not in fact be used to 3263 forward data to the destination, and may divert data packets away 3264 from the intended destination. 3266 There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which 3267 any malicious router could send an RREP in response, in order for the 3268 link to the malicious router to be deemed as bidirectional. 3270 Mitigation: 3272 o Ignoring unsolicited RREP and RREP_Ack messages partially 3273 mitigates against this threat. 3275 o If AODVv2 routers always verify that the sender of the RREP 3276 message is trusted, this threat is reduced. 3278 12.1.4. Message Deletion 3280 A malicious router could decide not to forward an RREQ or RREP or 3281 RERR message. Not forwarding a RERR or RREP message would disrupt 3282 route discovery. Not regenerating a RERR message would result in the 3283 source of data packets continuing to maintain and use the route, and 3284 further RERR messages being generated by the sender of the non- 3285 regenerated RERR. A malicious router could intentionally disrupt 3286 traffic flows by not allowing the source of data traffic to re- 3287 discover a new route when one breaks. 3289 Failing to send an RREP_Ack would also disrupt route establishment, 3290 by not allowing the reverse route to be validated. Return traffic 3291 which needs that route will prompt a new route discovery, wasting 3292 resources and incurring a slight delay but not disrupting the ability 3293 for applications to communicate. 3295 Mitigation: 3297 o None. Note that malicious router would have to wait for a route 3298 to break before it could perform this attack. 3300 12.2. Confidentiality 3302 Passive inspection (eavesdropping) of AODVv2 control messages could 3303 enable unauthorized devices to gain information about the network 3304 topology, since exchanging such information is the main purpose of 3305 AODVv2. 3307 Eavesdropping of data traffic could allow a malicious device to 3308 obtain information about how data traffic is being routed. With 3309 knowledge of source and destination addresses, malicious messages 3310 could be constructed to disrupt normal operation. 3312 12.3. Integrity of Routes 3314 Integrity of route information can be compromised in the following 3315 types of attack: 3317 12.3.1. Message Insertion 3319 Valid route set entries can be replaced or modified by maliciously 3320 constructed AODVv2 messages, destroying existing routes and the 3321 network's integrity. Any router may pose as another router by 3322 sending RREQ, RREP, RREP_Ack and RERR messages in its name. 3324 o Sending an RREQ message with false information can disrupt traffic 3325 to OrigPrefix, if the sequence number attached is not stale 3326 compared to any existing information about OrigPrefix. Since RREQ 3327 is multicast and likely to be received by all routers in the ad 3328 hoc network, this threat could have serious impact on applications 3329 communicating with OrigPrefix. 3331 o The actual threat to disrupt routes to OrigPrefix is reduced by 3332 the AODVv2 mechanism of marking RREQ-derived routes as 3333 "Unconfirmed" until the route to OrigAddr can be confirmed. 3335 o Sending an RREP message with false information can disrupt traffic 3336 to TargPrefix. Since RREP is unicast, and ignored if a 3337 corresponding RREQ was not recently sent, this threat is 3338 minimized, and is restricted to receivers along the path from 3339 OrigAddr to TargAddr. 3341 o Sending an RREP_Ack response message with false information can 3342 cause the route to an originator address to be erroneously 3343 accepted even though the route would contain a unidirectional link 3344 and thus not be suitable for most traffic. Since the RREP_Ack 3345 response is unicast, and ignored if a RREP_Ack was not sent 3346 recently to the sender of this RREP_Ack response, this threat is 3347 minimized and is strictly local to the RREP transmitter expecting 3348 the acknowledgement. Unsolicited RREP_Acks are ignored. 3350 o Sending an RERR message with false information is discussed in 3351 Section 12.1.2. 3353 Mitigation: 3355 o If AODVv2 routers always verify that the sender of a message is 3356 trusted, this threat is reduced. 3358 12.3.2. Message Modification - Man in the Middle 3360 Any AODVv2 router can forward messages with modified data. 3362 Mitigation: 3364 o If AODVv2 routers verify the integrity of AODVv2 messages, then 3365 the threat of disruption is minimized. A man in the middle with 3366 no knowledge of the key used to calculate an integrity check value 3367 may modify a message but the message will be rejected when it 3368 fails an integrity check. 3370 12.3.3. Replay Attacks 3372 Replaying of RREQ or RREP messages would be of less use to an 3373 attacker, since they would be dropped immediately due to their stale 3374 sequence number. RERR messages may or may not include sequence 3375 numbers and are therefore susceptible to replay attacks. RREP_Ack 3376 messages do not include sequence numbers and are therefore 3377 susceptible to replay attacks. 3379 Mitigation: 3381 o Use of timestamps or sequence numbers prevents replay attacks. 3383 12.4. Protection Mechanisms 3385 12.4.1. Confidentiality and Authentication 3387 Encryption MAY be used for AODVv2 messages. If the routers share a 3388 packet-level security association, the message data can be encrypted 3389 prior to message transmission. The establishment of such security 3390 associations is outside the scope of this specification. Encryption 3391 will not only protect against unauthorized devices obtaining 3392 information about network topology (eavesdropping) but will ensure 3393 that only trusted routers participate in routing operations. 3395 12.4.2. Message Integrity using ICVs 3397 Cryptographic Integrity Check Values (ICVs) can be used to ensure 3398 integrity of received messages, protecting against man in the middle 3399 attacks. Further, by using ICVs, only those routers with knowledge 3400 of a shared secret key are allowed to participate in routing 3401 information exchanges. [RFC7182] defines ICV TLVs for use with 3402 [RFC5444]. 3404 The data contained in AODVv2 routing protocol messages MUST be 3405 verified using Integrity Check Values, to avoid accepting tampered 3406 messages. 3408 12.4.3. Replay Protection using Timestamps 3410 [RFC7182] defines a TIMESTAMP TLV for use with [RFC5444] which can be 3411 used to prevent replay attacks when sequence numbers are not already 3412 included. 3414 The data contained in AODVv2 routing protocol messages must be 3415 protected with a TIMESTAMP value to ensure the protection against 3416 replaying of the message. Sequence numbers can be used as 3417 timestamps, since they are known to be strictly increasing. 3419 12.4.4. Application to AODVv2 3421 AODVv2 implementations MUST support ICV and TIMESTAMP TLVs, unless 3422 the implementation is intended solely for an environment in which 3423 security is unnecessary. AODVv2 deployments SHOULD be configured to 3424 use these TLVs to secure messages. 3426 Implementations of AODVv2 MUST support ICV TLVs using type-extensions 3427 1 and 2, hash-function HASH_FUNCTION, and cryptographic function 3428 CRYPTOGRAPHIC_FUNCTION. An ICV MUST be included with every message. 3429 The ICV value MAY be truncated as specified in [RFC7182]. 3431 Since the msg-hop-limit and PATH_METRIC values are mutable when 3432 included in AODVv2 messages, these values are set to zero before 3433 calculating an ICV. This means that these values are not protected 3434 end-to-end and are therefore susceptible to manipulation. This form 3435 of attack is described in Section 12.3.2. 3437 Implementations of AODVv2 MUST support a TIMESTAMP TLV using type- 3438 extension 0. The timestamp used is a sequence number, and therefore 3439 the length of the field matches the AODVv2 sequence 3440 number defined in Section 4.4. The TIMESTAMP TLV MUST be included in 3441 RREP_Ack and RERR messages. 3443 When more than one message is included in an RFC5444 packet, using a 3444 single ICV Packet TLV or single TIMESTAMP Packet TLV is more 3445 efficient than including ICV and TIMESTAMP Message TLVs in each 3446 message created. If the RFC5444 multiplexer is capable of adding the 3447 Packet TLVs, it SHOULD be instructed to include the Packet TLVs in 3448 packets containing AODVv2 messages. However, if the multiplexer is 3449 not capable of adding the Packet TLVs, the TLVs MUST be included as 3450 Message TLVs in each AODVv2 message in the packet. 3452 After message generation but before transmission, the ICV and 3453 TIMESTAMP TLVs MUST be added according to each message type as 3454 detailed in the following sections. The following steps list the 3455 procedure to be performed: 3457 1. If the TIMESTAMP is to be included, depending on AODVv2 message 3458 type as specified below, add the TIMESTAMP TLV. 3460 o When a TIMESTAMP Packet TLV is being added, the Packet TLV Block 3461 size field MUST be updated. 3463 o When a TIMESTAMP Message TLV is being added, the Message TLV Block 3464 size field MUST be updated. 3466 1. The considerations in Section 8 and section 9 of [RFC7182] are 3467 followed, removing existing ICV TLVs and adjusting the size and 3468 flags fields as appropriate: 3470 o When an ICV Packet TLV is being added, existing ICV Packet TLVs 3471 MUST be removed and the Packet TLV Block size MUST be updated. If 3472 the Packet TLV Block now contains no TLVs, the phastlv bit in the 3473 field in the Packet Header MUST be cleared. 3475 o When an ICV Message TLV is being added, existing ICV Message TLVs 3476 are removed and the Message TLV Block Size MUST be updated. 3478 1. Mutable fields in the message must have their mutable values set 3479 to zero before calculating the ICV. 3481 o If the msg-hop-limit field is included in the [RFC5444] message 3482 header, msg-hop-limit MUST be set to zero before calculating the 3483 ICV. 3485 o If a PATH_METRIC TLV is included, any values present in the TLV 3486 MUST be set to zero before calculating the ICV value. 3488 1. Depending on the message type, the ICV is calculated over the 3489 appropriate fields (as specified in sections Section 12.4.4.1, 3490 Section 12.4.4.2, Section 12.4.4.3 and Section 12.4.4.4) to 3491 include the fields , , 3492 , and, if present, (in that order), 3493 followed by the entire packet or message. This value MAY be 3494 truncated (as specified in [RFC7182]). 3496 2. Add the ICV TLV, updating size fields as necessary. 3498 3. The changes made in Step 2 and Step 3 are reversed to re-add any 3499 existing ICV TLVs, re-adjust the relevant size and flags fields, 3500 and set the msg-hop-limit and PATH_METRIC TLV values. 3502 On message reception, and before message processing, verification of 3503 the received message MUST take place: 3505 1. The considerations in Section 8 and Section 9 of [RFC7182] are 3506 followed, removing existing ICV TLVs and adjusting the size and 3507 flags fields as appropriate. 3509 o When verifying the ICV value in an ICV Packet TLV, all ICV Packet 3510 TLVs present in the Packet TLV Block MUST be removed before 3511 calculating the ICV, and the Packet TLV Block size MUST be 3512 updated. If there are no remaining Packet TLVs, the Packet TLV 3513 Block MUST be removed and the phastlv bit in the field 3514 MUST be cleared. 3516 o When verifying the ICV value in an ICV Message TLV, all ICV 3517 Message TLVs present in the Message TLV Block MUST be removed 3518 before calculating the ICV, and the Message TLV Block size MUST be 3519 updated. 3521 1. Mutable fields in the message MUST have their mutable values set 3522 to zero before calculating the ICV. 3524 o If the msg-hop-limit field is included in the [RFC5444] message 3525 header, msg-hop-limit MUST be set to zero before calculating the 3526 ICV. 3528 o If a PATH_METRIC TLV is included, any values present in the TLV 3529 MUST be set to zero before calculating the ICV value. 3531 1. The ICV is calculated following the considerations in 3532 Section 12.2 of [RFC7182], to include the fields , 3533 , , and, if present, (in that order), followed by the entire packet or message. 3536 o If the received ICV value is truncated, the calculated ICV value 3537 MUST also be truncated (as specified in [RFC7182]), before 3538 comparing. 3540 o If the ICV value calculated from the received message or packet 3541 does not match the value of in the received message or 3542 packet, the validation fails and the AODVv2 message MUST be 3543 discarded and NOT processed or forwarded. 3545 o If the ICV values do match, the values set to zero before 3546 calculating the ICV are reset to the received values, and 3547 processing continues to Step 4. 3549 1. Verification of a received TIMESTAMP value MUST be performed. 3550 The procedure depends on message type as specified in the 3551 following sub sections. 3553 o If the TIMESTAMP value in the received message is not valid, the 3554 AODVv2 message MUST be discarded and NOT processed or forwarded. 3556 o If the TIMESTAMP value is valid, processing continues as defined 3557 in Section 7. 3559 12.4.4.1. RREQ Generation and Reception 3561 Since OrigPrefix is included in the RREQ, the ICV can be calculated 3562 and verified using the [RFC5444] contents.The ICV TLV has type 3563 extension := 1. Inclusion of an ICV TLV message integrity and 3564 endpoint authentication, because trusted routers MUST hold the shared 3565 key in order to calculate the ICV value, both to include when 3566 creating a message, and to validate the message by checking that the 3567 ICV is correct. 3569 Since RREQ_Gen's sequence number is incremented for each new RREQ, 3570 replay protection is already afforded and no extra TIMESTAMP TLV is 3571 required. 3573 After message generation and before message transmission: 3575 1. Add the ICV TLV as described above. 3577 On message reception and before message processing: 3579 1. Verify the received ICV value as described above. 3581 2. Verification of the sequence number is handled according to 3582 Section 7. 3584 12.4.4.2. RREP Generation and Reception 3586 Since TargPrefix is included in the RREP, the ICV can be calculated 3587 and verified using the [RFC5444] contents. The ICV TLV has type 3588 extension 1. Inclusion of an ICV provides message integrity and 3589 endpoint authentication, because trusted routers MUST hold a valid 3590 key in order to calculate the ICV value, both to include when 3591 creating a message, and to validate the message by checking that the 3592 ICV is correct. 3594 Since RREP_Gen's sequence number is incremented for each new RREP, 3595 replay protection is already afforded and no extra TIMESTAMP TLV is 3596 required. 3598 After message generation and before message transmission: 3600 1. Add the ICV TLV as described above. 3602 On message reception and before message processing: 3604 1. Verify the received ICV value as described above. 3606 2. Verification of the sequence number is handled according to 3607 Section 7. 3609 12.4.4.3. RREP_Ack Generation and Reception 3611 Since no sequence number is included in the RREP_Ack, a TIMESTAMP TLV 3612 MUST be included to protect against replay attacks. The value in the 3613 TIMESTAMP TLV is set as follows: 3615 o For RREP_Ack request, use Neighbor.AckSeqNum. 3617 o For RREP_Ack response, use the sequence number from the TIMESTAMP 3618 TLV in the received RREP_Ack request. 3620 Since no addresses are included in the RREP_Ack, and the receiver of 3621 the RREP_Ack uses the source IP address of a received RREP_Ack to 3622 identify the sender, the ICV MUST be calculated using the message 3623 contents and the IP source address. The ICV TLV has type extension 3624 := 2 in order to accomplish this. This provides message integrity 3625 and endpoint authentication, because trusted routers MUST hold the 3626 correct key in order to calculate the ICV value. 3628 After message generation and before message transmission: 3630 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3632 On message reception and before message processing: 3634 1. Verify the received ICV value as described above. 3636 2. Verify the received TIMESTAMP value by comparing the sequence 3637 number in the value field of the TIMESTAMP TLV as follows: 3639 o For a received RREP_Ack request, there is no need to verify the 3640 timestamp value. Proceed to message processing as defined in 3641 Section 7. 3643 o For a received RREP_Ack response, compare with the 3644 Neighbor.AckSeqNum of the Neighbor Set entry for sender of the 3645 RREP_Ack request. 3647 o If the sequence number does not match, the AODVv2 message MUST be 3648 discarded. Otherwise, Neighbor.AckSeqNum is incremented by 1 and 3649 processing continues according to Section 7. 3651 12.4.4.4. RERR Generation and Reception 3653 Since the sender's sequence number is not contained in the RERR, a 3654 TIMESTAMP TLV MUST be included to protect against replay attacks. 3655 The value in the TIMESTAMP TLV is set by incrementing and using 3656 RERR_Gen's sequence number. 3658 Since the receiver of the RERR MUST use the source IP address of the 3659 RERR to identify the sender, the ICV MUST be calculated using the 3660 message contents and the IP source address. The ICV TLV has type 3661 extension := 2 in order to accomplish this. This provides message 3662 integrity and endpoint authentication, because trusted routers MUST 3663 hold the shared key in order to calculate the ICV value. 3665 After message generation and before message transmission: 3667 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3669 On message reception and before message processing: 3671 1. Verify the received ICV value as described above. 3673 2. Verify the received TIMESTAMP value by comparing the sequence 3674 number in the value field of the TIMESTAMP TLV with the 3675 Neighbor.HeardRERRSeqNum. If the sequence number in the message 3676 is lower than the stored value, the AODVv2 message MUST be 3677 discarded. Otherwise, the Neighbor.HeardRERRSeqNum MUST be set 3678 to the received value and processing continues according to 3679 Section 7. 3681 12.5. Key Management 3683 The method of distribution of shared secret keys is out of the scope 3684 of this protocol. Key management is not specified for the following 3685 reasons: 3687 Against [RFC4107], an analysis as to whether automated or manual key 3688 management should be used shows a compelling case for automated 3689 management. In particular: 3691 o a potentially large number of routers may have to be managed, 3692 belonging to several organisations, for example in vehicular 3693 applications. 3695 o a stream cipher is likely to be used, such as an AES variant. 3697 o long term session keys might be used by more than two parties, 3698 including multicast operations. AODVv2 makes extensive use of 3699 multicast. 3701 o there may be frequent turnover of devices. 3703 On reviewing the case for manual key management against the same 3704 document, it can be seen that manual management might be advantageous 3705 in environments with limited bandwidth or high round trip times. 3706 AODVv2 lends itself to sparse ad hoc networks where transmission 3707 conditions may indeed be limited, depending on the bearers selected 3708 for use. 3710 However, [RFC4107] assumes that the connectivity between endpoints is 3711 already available. In AODVv2, no route is available to a given 3712 destination until a router client requests that user traffic be 3713 transmitted. It is required to secure the signalling path of the 3714 routing protocol that will establish the path across which key 3715 exchange functions might subsequently be applied, which is clearly 3716 the reverse of the expected functionality. A different strategy is 3717 therefore required. 3719 There are two possible solutions. In each case, it is assumed that a 3720 defence in depth security posture is being adopted by the system 3721 integrator, such that each function in the network as a whole is 3722 appropriately secured or defended as necessary, and that there is not 3723 complete reliance on security mechanisms built in to AODVv2. Such 3724 additional mechanisms could include a suitable wireless device 3725 security technology, so that wireless devices are authenticated and 3726 secured by their peers prior to exchanging user data, which in this 3727 case would include AODVV2 signalling traffic as a payload, and 3728 mechanisms which verify the authenticity and/or integrity of 3729 application-layer user data transported once a route has been 3730 established. 3732 1. In the case that no AODVv2 routers have any detailed prior 3733 knowledge of any other AODVv2 router, but does have knowledge of 3734 the credentials of other organisations in which the router has 3735 been previously configured to trust, it is possible for an AODVv2 3736 router to send an initialisation vector as part of an exchange, 3737 which could be verified against such credentials. Such an 3738 exchange could make use of Identity-Based Signatures 3739 ([I-D.ietf-manet-ibs]), based on Elliptic Curve-Based 3740 Certificateless Signatures for Identity-Based Encryption 3741 [RFC6507], which eliminate the need for a handshake process to 3742 establish trust. 3744 2. If it is impossible to use Identity-Based Signatures, and the 3745 risk to the AODVv2 signalling traffic is considered to be low due 3746 to the use of security countermeasures elsewhere in the system, a 3747 simple pre-placed shared secret could be used between routers, 3748 which is used as-is or is used to generate some ephemeral secret 3749 based on another known variable, such as time of day if that is 3750 universally available at a level of accuracy sufficient to make 3751 such a system viable. 3753 13. Acknowledgments 3755 AODVv2 is a descendant of the design of previous MANET on-demand 3756 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3757 previous MANET on-demand protocols stem from research and 3758 implementation experiences. Thanks to Elizabeth Belding and Ian 3759 Chakeres for their long time authorship of AODV. Additional thanks 3760 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3761 Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, Ulrich Herberg, 3762 Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, Lars Kristensen, 3763 Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, Keyur Patel, 3764 Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro Ruiz, 3765 Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi, Seung 3766 Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2 and 3767 DYMO, as well as numerous specification suggestions. 3769 14. References 3771 14.1. Normative References 3773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3774 Requirement Levels", BCP 14, RFC 2119, 3775 DOI 10.17487/RFC2119, March 1997, 3776 . 3778 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3779 Demand Distance Vector (AODV) Routing", RFC 3561, 3780 DOI 10.17487/RFC3561, July 2003, 3781 . 3783 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 3784 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 3785 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 3786 . 3788 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 3789 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 3790 2009, . 3792 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 3793 Check Value and Timestamp TLV Definitions for Mobile Ad 3794 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 3795 April 2014, . 3797 14.2. Informative References 3799 [I-D.ietf-manet-ibs] 3800 Dearlove, C., "Identity-Based Signatures for MANET Routing 3801 Protocols", draft-ietf-manet-ibs-05 (work in progress), 3802 March 2016. 3804 [Koodli01] 3805 Koodli, R. and C. Perkins, "Fast handovers and context 3806 transfers in mobile networks", Proceedings of the ACM 3807 SIGCOMM Computer Communication Review 2001, Volume 31 3808 Issue 5, 37-47, October 2001. 3810 [Perkins94] 3811 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 3812 Sequenced Distance-Vector Routing (DSDV) for Mobile 3813 Computers", Proceedings of the ACM SIGCOMM '94 Conference 3814 on Communications Architectures, Protocols and 3815 Applications, London, UK, pp. 234-244, August 1994. 3817 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 3818 (MANET): Routing Protocol Performance Issues and 3819 Evaluation Considerations", RFC 2501, 3820 DOI 10.17487/RFC2501, January 1999, 3821 . 3823 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 3824 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 3825 June 2005, . 3827 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3828 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3829 . 3831 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 3832 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 3833 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 3834 . 3836 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 3837 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 3838 RFC 6130, DOI 10.17487/RFC6130, April 2011, 3839 . 3841 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 3842 Signatures for Identity-Based Encryption (ECCSI)", 3843 RFC 6507, DOI 10.17487/RFC6507, February 2012, 3844 . 3846 Appendix A. AODVv2 Draft Updates 3848 This section lists the changes between AODVv2 revisions ...-16.txt 3849 and ...-17.txt. 3851 o Removed wording that suggested RREP_Gen could add multiple 3852 (unrelated) subnets. 3854 o Changed wording in accordance with decision to pursue Proposed 3855 Standard. 3857 o Resolved an error scenario that was based on confirming routes to 3858 OrigAddr before the route to OrigAddr was known to be operational. 3859 But, another AODVv2 router closer to OrigAddr might forward 3860 packets along a previously confirmed route with an obsolete 3861 Sequence Number. These two conditions together were found to 3862 allow for routing loops. 3864 o Enabled multihoming by creating new address type SeqNoRtr, along 3865 with rules prohibiting comparison of sequence numbers from 3866 distinct multihoming routers per advertised prefix. 3868 Authors' Addresses 3870 Charles E. Perkins 3871 Futurewei Inc. 3872 2330 Central Expressway 3873 Santa Clara, CA 95050 3874 USA 3876 Phone: +1-408-330-4586 3877 Email: charliep@computer.org 3878 Stan Ratliff 3879 Idirect 3880 13861 Sunrise Valley Drive, Suite 300 3881 Herndon, VA 20171 3882 USA 3884 Email: ratliffstan@gmail.com 3886 John Dowdell 3887 Airbus Defence and Space 3888 Celtic Springs 3889 Newport, Wales NP10 8FZ 3890 United Kingdom 3892 Email: john.dowdell@airbus.com 3894 Lotte Steenbrink 3895 HAW Hamburg, Dept. Informatik 3896 Berliner Tor 7 3897 D-20099 Hamburg 3898 Germany 3900 Email: lotte.steenbrink@haw-hamburg.de 3902 Victoria Mercieca 3903 Airbus Defence and Space 3904 Celtic Springs 3905 Newport, Wales NP10 8FZ 3906 United Kingdom 3908 Email: victoria.mercieca@airbus.com