idnits 2.17.1 draft-perkins-manet-aodvv2-03.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 (February 28, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Address' is mentioned on line 502, but not defined == Missing Reference: 'MetricType' is mentioned on line 3456, but not defined == Missing Reference: 'OrigPrefix' is mentioned on line 2365, but not defined == Missing Reference: 'TargPrefix' is mentioned on line 2316, but not defined == Missing Reference: 'HopCount' is mentioned on line 3428, but not defined == Missing Reference: 'TBD' is mentioned on line 3477, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3561 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-05 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track S. Ratliff 5 Expires: September 1, 2019 Idirect 6 J. Dowdell 7 Airbus Defence and Space 8 L. Steenbrink 9 Freie Universitaet Berlin 10 V. Pritchard 11 Airbus Defence and Space 12 February 28, 2019 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-perkins-manet-aodvv2-03 17 Abstract 19 The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing 20 protocol is intended for use by mobile routers in wireless, multihop 21 networks. AODVv2 determines unicast routes among AODVv2 routers 22 within the network in an on-demand fashion. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 1, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Distance Vector Routing Protocols . . . . . . . . . . . . 4 60 1.2. Basic Protocol Mechanisms . . . . . . . . . . . . . . . . 5 61 1.3. Comparison to RFC 3561 . . . . . . . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 11 64 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 13 65 4.1. Network Interfaces used by AODVv2 . . . . . . . . . . . . 13 66 4.2. Router Client Set . . . . . . . . . . . . . . . . . . . . 13 67 4.3. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . 14 68 4.4. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15 69 4.5. Local Route Set . . . . . . . . . . . . . . . . . . . . . 16 70 4.6. Multicast Message Set . . . . . . . . . . . . . . . . . . 18 71 4.7. Route Error (RERR) Set . . . . . . . . . . . . . . . . . 19 72 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 6. AODVv2 Protocol Operations . . . . . . . . . . . . . . . . . 22 74 6.1. Reinitialization . . . . . . . . . . . . . . . . . . . . 22 75 6.2. Next Hop Monitoring . . . . . . . . . . . . . . . . . . . 23 76 6.3. Neighbor Set Update . . . . . . . . . . . . . . . . . . . 24 77 6.4. Interaction with the Forwarding Plane . . . . . . . . . . 26 78 6.5. Message Transmission . . . . . . . . . . . . . . . . . . 27 79 6.6. Route Discovery, Retries and Buffering . . . . . . . . . 28 80 6.7. Processing Received Route Information . . . . . . . . . . 29 81 6.7.1. Evaluating Route Information . . . . . . . . . . . . 30 82 6.7.2. Applying Route Updates . . . . . . . . . . . . . . . 32 83 6.8. Suppressing Redundant Messages (Multicast Message Set) . 34 84 6.9. Suppressing Redundant Route Error Messages (Route Error 85 Set) . . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 6.10. Local Route Set Maintenance . . . . . . . . . . . . . . . 37 87 6.10.1. LocalRoute State Changes . . . . . . . . . . . . . . 38 88 6.10.2. Reporting Invalid Routes . . . . . . . . . . . . . . 40 89 7. AODVv2 Protocol Messages . . . . . . . . . . . . . . . . . . 40 90 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . 40 91 7.1.1. RREQ Generation . . . . . . . . . . . . . . . . . . . 42 92 7.1.2. RREQ Reception . . . . . . . . . . . . . . . . . . . 43 93 7.1.3. RREQ Forwarding . . . . . . . . . . . . . . . . . . . 44 94 7.2. Route Reply (RREP) Message . . . . . . . . . . . . . . . 45 95 7.2.1. RREP Generation . . . . . . . . . . . . . . . . . . . 46 96 7.2.2. RREP Reception . . . . . . . . . . . . . . . . . . . 47 97 7.2.3. RREP Forwarding . . . . . . . . . . . . . . . . . . . 49 98 7.3. Route Reply Acknowledgement (RREP_Ack) Message . . . . . 49 99 7.3.1. RREP_Ack Request Generation . . . . . . . . . . . . . 50 100 7.3.2. RREP_Ack Reception . . . . . . . . . . . . . . . . . 50 101 7.3.3. RREP_Ack Response Generation . . . . . . . . . . . . 51 102 7.4. Route Error (RERR) Message . . . . . . . . . . . . . . . 51 103 7.4.1. RERR Generation . . . . . . . . . . . . . . . . . . . 52 104 7.4.2. RERR Reception . . . . . . . . . . . . . . . . . . . 54 105 7.4.3. RERR Regeneration . . . . . . . . . . . . . . . . . . 55 106 8. RFC 5444 Representation . . . . . . . . . . . . . . . . . . . 56 107 8.1. Route Request Message Representation . . . . . . . . . . 57 108 8.1.1. Message Header . . . . . . . . . . . . . . . . . . . 57 109 8.1.2. Message TLV Block . . . . . . . . . . . . . . . . . . 57 110 8.1.3. Address Block . . . . . . . . . . . . . . . . . . . . 57 111 8.1.4. Address Block TLV Block . . . . . . . . . . . . . . . 58 112 8.2. Route Reply Message Representation . . . . . . . . . . . 58 113 8.2.1. Message Header . . . . . . . . . . . . . . . . . . . 59 114 8.2.2. Message TLV Block . . . . . . . . . . . . . . . . . . 59 115 8.2.3. Address Block . . . . . . . . . . . . . . . . . . . . 59 116 8.2.4. Address Block TLV Block . . . . . . . . . . . . . . . 59 117 8.3. Route Reply Acknowledgement Message Representation . . . 60 118 8.3.1. Message Header . . . . . . . . . . . . . . . . . . . 60 119 8.3.2. Message TLV Block . . . . . . . . . . . . . . . . . . 60 120 8.3.3. Address Block . . . . . . . . . . . . . . . . . . . . 60 121 8.3.4. Address Block TLV Block . . . . . . . . . . . . . . . 60 122 8.4. Route Error Message Representation . . . . . . . . . . . 61 123 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 61 124 8.4.2. Message TLV Block . . . . . . . . . . . . . . . . . . 61 125 8.4.3. Address Block . . . . . . . . . . . . . . . . . . . . 61 126 8.4.4. Address Block TLV Block . . . . . . . . . . . . . . . 61 127 9. Simple External Network Attachment . . . . . . . . . . . . . 62 128 10. Precursor Lists . . . . . . . . . . . . . . . . . . . . . . . 64 129 11. Application of RFC 7182 to AODVv2 . . . . . . . . . . . . . . 65 130 11.1. RREQ Generation and Reception . . . . . . . . . . . . . 68 131 11.2. RREP Generation and Reception . . . . . . . . . . . . . 68 132 11.3. RREP_Ack Generation and Reception . . . . . . . . . . . 69 133 11.4. RERR Generation and Reception . . . . . . . . . . . . . 70 134 12. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 70 135 12.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 71 136 12.2. Protocol Constants . . . . . . . . . . . . . . . . . . . 73 137 12.3. Local Settings . . . . . . . . . . . . . . . . . . . . . 74 138 12.4. Network-Wide Settings . . . . . . . . . . . . . . . . . 74 139 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 140 13.1. RFC 5444 Message Type Allocation . . . . . . . . . . . . 75 141 13.2. RFC 5444 Message TLV Types . . . . . . . . . . . . . . . 75 142 13.3. RFC 5444 Address Block TLV Type Allocation . . . . . . . 75 143 13.4. MetricType Allocation . . . . . . . . . . . . . . . . . 76 144 13.5. ADDRESS_TYPE TLV Values . . . . . . . . . . . . . . . . 76 145 13.6. ICMPv6 Code Field for ICMP Destination Unreachable . . . 77 146 14. Security Considerations . . . . . . . . . . . . . . . . . . . 77 147 14.1. Availability . . . . . . . . . . . . . . . . . . . . . . 77 148 14.1.1. Denial of Service . . . . . . . . . . . . . . . . . 77 149 14.1.2. Malicious RERR messages . . . . . . . . . . . . . . 78 150 14.1.3. False Confirmation of Link Bidirectionality . . . . 80 151 14.1.4. Message Deletion . . . . . . . . . . . . . . . . . . 80 152 14.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 80 153 14.3. Integrity of Routes . . . . . . . . . . . . . . . . . . 81 154 14.3.1. Message Insertion . . . . . . . . . . . . . . . . . 81 155 14.3.2. Message Modification - Man in the Middle . . . . . . 82 156 14.3.3. Replay Attacks . . . . . . . . . . . . . . . . . . . 82 157 14.4. Protection Mechanisms . . . . . . . . . . . . . . . . . 82 158 14.4.1. Confidentiality and Authentication . . . . . . . . . 82 159 14.4.2. Message Integrity using ICVs . . . . . . . . . . . . 82 160 14.4.3. Replay Protection using Timestamps . . . . . . . . . 83 161 14.5. Key Management . . . . . . . . . . . . . . . . . . . . . 83 162 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 163 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 164 16.1. Normative References . . . . . . . . . . . . . . . . . . 85 165 16.2. Informative References . . . . . . . . . . . . . . . . . 85 166 Appendix A. Recent AODVv2 Draft Updates . . . . . . . . . . . . 87 167 Appendix B. Previous AODVv2 Draft Updates . . . . . . . . . . . 88 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 170 1. Overview 172 The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol 173 enables dynamic, multihop routing between participating mobile 174 routers wishing to establish and maintain an ad hoc network. The 175 basic operations of the AODVv2 protocol are route discovery and route 176 maintenance. AODVv2 does not require nodes to maintain routes to 177 destinations that are not in active communication. AODVv2 allows 178 mobile nodes to respond to link breakages and changes in network 179 connectivity. 181 1.1. Distance Vector Routing Protocols 183 AODVv2 is a distance-vector routing protocol, which means that routes 184 are stored with information about the next hop (vector for 185 forwarding) and the metric or cost of using the route (a "distance" 186 to the destination along that route). Typically, if multiple routes 187 to a particular destination are available to be selected, the route 188 with the least cost (e.g., shortest distance) is chosen for the 189 purpose of forwarding packets to that destination. Distance-vector 190 (Bellman-Ford) routing protocols were historically vulnerable to what 191 became known as the "counting to infinity" problem. That problem 192 causes routes to grow quickly worse over time, and results from a 193 router's inability to detect out-of-sequence routing updates and 194 subsequent retransmission of stale information. AODVv2 uses sequence 195 numbers to assure detection of stale routing information, as was done 196 previously in DSDV and as described in [Perkins94]. The operation of 197 AODVv2 is consequently loop-free and offers quick convergence when 198 the ad hoc network topology changes (typically, when a node moves in 199 the network). When links break, AODVv2 causes the affected set of 200 nodes to be notified so that they are able to invalidate the routes 201 using the broken link. 203 AODVv2 stores a destination sequence number for each route entry. 204 The destination sequence number is created by the destination to be 205 included along with any route information it sends to requesting 206 nodes. Using destination sequence numbers ensures loop freedom and 207 is simple to program. Given the choice between two routes to a 208 destination, a requesting node is required to select the one with the 209 greatest sequence number. 211 1.2. Basic Protocol Mechanisms 213 The basic protocol mechanisms are as follows. AODVv2 is a reactive 214 protocol, meaning that route discovery is initiated only when a route 215 to the target is needed (i.e. when a router's client has data to send 216 (see Section 4.2)). For this purpose, AODVv2 uses Route Request 217 (RREQ) and Route Reply (RREP) messages as follows: an RREQ is 218 distributed across the network. Routers (other than the target) 219 receiving the RREQ retransmit it and also store a reverse route back 220 to the originator of the RREQ. 222 : / \ : 223 | / \| \ 224 - S ----- A ---... \ M-----D 225 | / \ /-----J---... / 226 : / \ / / /|\ / 227 : -B-------/ / : \ / 228 | K-----L--.... 229 : | /| 231 Figure 1: Flooding a RREQ through the network 233 In figure Figure 1, node 'S' needs to discover a route to a desired 234 destination node 'D'. S generates a RREQ to be flooded throughout 235 the network. The RREQ traverses nodes A, B, J, K, L, and M before 236 finally arriving at the target node D. The RREQ will also most 237 likely be received and retransmitted by many other nodes in the 238 network. Each intermediate node that receives the RREQ stores a 239 reverse route back to node S so that communication between S and D 240 can be established in case that intermediate node receives a RREP in 241 response to the RREQ. 243 When the target receives the RREQ, it answers with an RREP, which is 244 then relayed back to the originator along the path stored by the 245 intermediate routers. A metric value is included within the messages 246 to indicate the cost of the route. 248 S <--- A <--- B <--- J <--- K <--- L <--- M <--- D 250 Figure 2: D sends a RREP back to the node S 252 In figure Figure 2, node 'D' transmits a RREP back towards S. Node M 253 has stored a route back to S by way of node L. Node L has stored a 254 route back to S by way of node K, and so on. Also, each node that 255 receives the RREP uses the information in the RREP to store a route 256 to node 'D'. For instance, the RREP contains the metric describing 257 the cost of the route from an intermediate node X to node D, as well 258 as information about the next hop towards D -- namely, the node which 259 transmitted the RREP to X. 261 AODVv2 uses sequence numbers as described above to identify stale 262 routing information, and compares route metric values to determine if 263 advertised routes could form loops. Route maintenance includes 264 confirming bidirectionality of links to next-hop AODVv2 routers, 265 managing route timeouts, using Route Error (RERR) messages to inform 266 other routers of broken links, and reacting to received Route Error 267 messages. 269 AODVv2 requires indications to be exchanged between AODVv2 and the 270 forwarding subsystem for the following conditions: 272 o a packet needs to be forwarded and a route needs to be discovered 273 (this happens because of the on-demand nature of AODVv2) 275 o packet forwarding fails, in order to report a route error 277 o packet forwarding succeeds, in order to manage route timeouts. 279 Security for authentication of AODVv2 routers and encryption of 280 control messages is accomplished using the TIMESTAMP and ICV TLVs 281 defined in [RFC7182]. 283 1.3. Comparison to RFC 3561 285 AODVv2 operates in a fashion very similar to AODV[RFC3561]. The 286 mechanism for route discovery is basically the same, so that similar 287 performance results can be expected. Compared to AODV, AODVv2 has 288 moved some features out of the scope of the document, notably 289 intermediate route replies, and expanding ring search. However, this 290 document has been designed to allow specification of those features 291 in a separate document. 293 AODVv2 control messages are defined as sets of data. As described in 294 Section 8, these sets of data can be mapped to message elements using 295 the Generalized MANET Packet/Message Format defined in [RFC5444] and 296 sent using the parameters in [RFC5498]. Additional refinements have 297 been made for route timeouts and state management. Other mappings 298 for the sets of data for the control messages are possible. 300 Compared to AODV[RFC3561], the following protocol mechanisms have 301 changed: 303 o Verification of link bidirectionality has been substantially 304 improved 306 o Alternate metrics may be used to determine route quality 308 o Support for multiple interfaces has been improved 310 o Support for multi-interface IP addresses has been added 312 o A new security model allowing end to end integrity checks has been 313 added 315 o Message formats have been updated and made compliant with 316 [RFC5444]. 318 o Hello messages and local repair have been removed. 320 o Multihoming is supported. 322 AODVv2 has not been designed to be interoperable with AODV. However, 323 it would be straightforward to allow both protocols to be used in the 324 same ad hoc network as long as compatible metrics were used. 326 2. Terminology 328 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 329 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 330 "OPTIONAL" in this document are to be interpreted as described in 331 [RFC2119]. The names of the protocol messages in AODVv2 are chosen 332 to conform to the names of the similar protocol messages in 333 [RFC3561]. In addition, this document uses terminology from 334 [RFC5444], and defines the following terms: 336 Address Block 337 An AddressList along with address type for each address (see 338 Section 8). 340 AddressList 341 A list of IP addresses as used in AODVv2 messages. The IP address 342 family is determined, for instance, by parameter choice in 343 [RFC5444], or other shim layer between AODVv2 and the network 344 layer. 346 AckReq 347 Used in a Route Reply Acknowledgement message to indicate that a 348 Route Reply Acknowledgement is expected in return (see 349 Section 7.3). 351 AdvRte 352 A route advertised in an incoming route message (RREQ or RREP). 354 AODVv2 Router 355 An IP addressable device in the ad hoc network that performs the 356 AODVv2 protocol operations specified in this document. 358 CurrentTime 359 The current time as maintained by the AODVv2 router. 361 Invalid route 362 A route that cannot be used for forwarding but still contains 363 useful sequence number information. 365 LocalRoute 366 An entry in the Local Route Set as defined in Section 4.5. 368 MANET 369 A Mobile Ad Hoc Network as defined in [RFC2501]. 371 MetricType 372 The metric type for a metric value included in a message (see 373 Section 13.4). 375 MetricTypeList 376 A list of metric types associated with the addresses in the 377 AddressList of a Route Error message. 379 Neighbor 380 An AODVv2 router from which an RREQ or RREP message has been 381 received. Neighbors exchange routing information and verify 382 bidirectionality of the link to a neighbor before installing a 383 route via that neighbor into the Local Route Set. 385 OrigAddr 386 The source IP address of the IP packet triggering route discovery. 388 OrigMetric 389 The metric value associated with the route to OrigPrefix. 391 OrigPrefix 392 The prefix configured in the Router Client Set entry which 393 includes OrigAddr. 395 OrigPrefixLen 396 The prefix length, in bits, configured in the Router Client Set 397 entry which includes OrigAddr. 399 OrigSeqNum 400 The sequence number of the AODVv2 router which originated the 401 Route Request on behalf of OrigAddr. 403 PktSource 404 The source address of the IP packet that triggered a Route Error 405 message. 407 PrefixLengthList 408 A list of routing prefix lengths associated with the addresses in 409 the AddressList of a message. 411 Reactive 412 Performed only in reaction to specific events. In AODVv2, routes 413 are requested only when data packets need to be forwarded. In 414 this document, "reactive" is synonymous with "on-demand". 416 RERR (Route Error) 417 The AODVv2 message type used to indicate that an AODVv2 router 418 does not have a valid LocalRoute toward one or more destinations. 420 RERR_Gen (RERR Generating Router) 421 The AODVv2 router generating a Route Error message. 423 RerrMsg (RERR Message) 424 A Route Error (RERR) message. 426 Routable Unicast IP Address 427 A unicast IP address that is scoped sufficiently to be forwarded 428 by a router. Globally-scoped unicast IP addresses and Unique 429 Local Addresses (ULAs) [RFC4193] are examples of routable unicast 430 IP addresses. 432 Router Client 433 An address within an address range configured on an AODVv2 router, 434 on behalf of which that router will initiate and respond to route 435 discoveries. These addresses may be used by the AODVv2 router 436 itself or by devices that are reachable without traversing another 437 AODVv2 router. 439 RREP (Route Reply) 440 The AODVv2 message type used to reply to a Route Request message. 442 RREP_Gen (RREP Generating Router) 443 The AODVv2 router that generates the Route Reply message, i.e., 444 the router configured with TargAddr as a Router Client. 446 RREQ (Route Request) 447 The AODVv2 message type used to discover a route to TargAddr and 448 distribute information about a route to OrigPrefix. 450 RREQ_Gen (RREQ Generating Router) 451 The AODVv2 router that generates the Route Request message, i.e., 452 the router configured with OrigAddr as a Router Client. 454 RteMsg (Route Message) 455 A Route Request (RREQ) or Route Reply (RREP) message. 457 SeqNum 458 The sequence number maintained by an AODVv2 router to indicate 459 freshness of route information. 461 SeqNumList 462 A list of sequence numbers associated with the addresses in the 463 AddressList of a message. 465 TargAddr 466 The target address of a route request, i.e., the destination 467 address of the IP packet triggering route discovery. 469 TargMetric 470 The metric value associated with the route to TargPrefix. 472 TargPrefix 473 The prefix configured in the Router Client Set entry which 474 includes TargAddr. 476 TargPrefixLen 477 The prefix length, in bits, configured in the Router Client Set 478 entry which includes TargAddr. 480 TargSeqNum 481 The sequence number of the AODVv2 router which originated the 482 Route Reply on behalf of TargAddr. 484 Unreachable Address 485 An address reported in a Route Error message, as described in 486 Section 7.4.1. 488 Upstream 489 In the direction from destination to source (from TargAddr to 490 OrigAddr). 492 Valid route 493 A route that can be used for forwarding. 495 This document uses the notational conventions in Table 1 to simplify 496 the text. 498 +-----------------------+---------------------------------------+ 499 | Notation | Meaning | 500 +-----------------------+---------------------------------------+ 501 | Route[Address] | A route toward Address | 502 | Route[Address].Field | A field in a route toward Address | 503 | McMsg.Field | A field in a Multicast Message entry | 504 | RteMsg.Field | A field in either RREQ or RREP | 505 | RerrMsg.Field | A field in a RERR | 506 +-----------------------+---------------------------------------+ 508 Table 1: Notational Conventions 510 3. Applicability Statement 512 The AODVv2 routing protocol is a reactive routing protocol designed 513 for use in mobile ad hoc wireless networks, and may also be useful in 514 networks where the nodes are not mobile but economical route 515 maintenance is still required. A reactive protocol only sends 516 messages to discover a route when there is data to send on that 517 route. This requires an interaction with the forwarding plane, to 518 indicate when a packet is to be forwarded, in case reactive route 519 discovery is needed. The set of signals exchanged between AODVv2 and 520 the forwarding plane are discussed in Section 6.4. 522 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 523 i.e., non-transit networks or those not connected to the internet. 524 AODVv2 routers can, however, be configured to perform gateway 525 functions when attached to external networks, as discussed in 526 Section 9. 528 AODVv2 handles a wide variety of mobility and traffic patterns by 529 determining routes on-demand. In networks with a large number of 530 routers, AODVv2 is best suited for relatively sparse traffic 531 scenarios where each router forwards IP packets to a small percentage 532 of destination addresses in the network. In such cases fewer routes 533 are needed, and far less control traffic is produced. In large 534 networks with dense traffic patterns, AODVv2 control messages may 535 cause a broadcast storm, overwhelming the network with control 536 messages. The transmission priorities described in Section 6.5 537 prioritize route maintenance traffic over route discovery traffic. 539 Data packets may be buffered until a route to their destination is 540 available, as described in Section 6.6. 542 AODVv2 is well suited to reactive scenarios such as emergency and 543 disaster relief, where the ability to communicate might be more 544 important than being assured of secure operations. For many other ad 545 hoc networking applications, in which insecure operation could negate 546 the value of establishing communication paths, it is important for 547 neighboring AODVv2 routers to establish security associations with 548 one another. 550 AODVv2 provides for message integrity and security against replay 551 attacks by using integrity check values, timestamps and sequence 552 numbers, as described in Section 14. When security associations have 553 been established, encryption can be used for AODVv2 messages to 554 ensure that only trusted routers participate in routing operations. 556 The AODVv2 route discovery process aims for a route to be established 557 in both directions along the same path. Uni-directional links are 558 not suitable; AODVv2 will detect and exclude those links from route 559 discovery. The route discovered is optimized for the requesting 560 router, and the return path may not be the optimal route. 562 AODVv2 is applicable to memory constrained devices, since only a 563 little routing state is maintained in each AODVv2 router. AODVv2 564 routes that are not needed for forwarding data do not need to be 565 maintained. 567 AODVv2 supports routers with multiple interfaces and multiple IP 568 addresses per interface. A router may also use the same IP address 569 on multiple interfaces. AODVv2 requires only that each interface 570 configured for AODVv2 has at least one unicast IP address (see 571 Section 4.1). Address assignment procedures are out of scope for 572 AODVv2. 574 AODVv2 supports Router Clients with multiple interfaces, as long as 575 each Client interface is configured with its own unicast IP address. 577 The routing algorithm in AODVv2 has been operated at layers other 578 than the network layer, using layer-appropriate addresses. 580 4. Data Structures 582 4.1. Network Interfaces used by AODVv2 584 AODVv2 has to maintain information about all network interfaces 585 configured for sending or receiving AODVv2 messages. Any interface 586 with an IP address can be used. Multiple interfaces on a single 587 router can be used. Multiple interfaces on the same router may be 588 configured with the same IP address; in this case, sufficient 589 information about those network interfaces has to be maintained by 590 the AODVv2 router in order to determine which of them has received an 591 incoming AODVv2 message. For instance, it is often possible to 592 determine the incoming interface by inspecting the MAC address of the 593 layer-2 frame header. 595 4.2. Router Client Set 597 An AODVv2 router discovers routes for its own local applications and 598 also for its Router Clients that are reachable without traversing 599 another AODVv2 router. The addresses used by these devices, and the 600 AODVv2 router itself, are configured in the Router Client Set. An 601 AODVv2 router will only originate Route Request and Route Reply 602 messages on behalf of its configured Router Client addresses. 604 Router Client Set entries are configured manually or by mechanisms 605 out of scope for this document. Each client's entry contains: 607 RouterClient.IPAddress 608 An IP address or the start of an address range that requires route 609 discovery services from the AODVv2 router. 611 RouterClient.PrefixLength 612 The length, in bits, of the routing prefix associated with the 613 RouterClient.IPAddress. If the prefix length is not equal to the 614 address length of RouterClient.IPAddress, the AODVv2 router MUST 615 participate in route discovery on behalf of all addresses within 616 that prefix. 618 RouterClient.Cost 619 The cost associated with reaching the client's address or address 620 range. 622 4.3. Neighbor Set 624 A Neighbor Set is used to maintain information about neighboring 625 AODVv2 routers. Neighbor Set entries are stored when AODVv2 messages 626 are received. If the Neighbor is chosen as a next hop on an 627 installed route, the link to the Neighbor is tested for 628 bidirectionality; the result is stored in the Neighbor Set. 630 Neighbor Set entries MUST contain: 632 Neighbor.IPAddress 633 An IP address of the neighboring router. 635 Neighbor.State 636 Indicates whether the link to the neighbor is bidirectional. 637 There are three possible states: CONFIRMED, HEARD, and 638 BLACKLISTED. HEARD is the initial state. CONFIRMED indicates 639 that the link to the neighbor has been confirmed as bidirectional. 640 BLACKLISTED indicates that the link to the neighbor is being 641 treated as uni-directional. Section 6.2 discusses how to monitor 642 link bidirectionality. 644 Neighbor.Timeout 645 Indicates the time at which the Neighbor.State should be updated: 647 o If the value of Neighbor.State is BLACKLISTED, this indicates the 648 time at which Neighbor.State will revert to HEARD. This value is 649 calculated at the time the router is blacklisted and by default is 650 equal to CurrentTime + MAX_BLACKLIST_TIME. 652 o If Neighbor.State is HEARD, and an RREP_Ack has been requested 653 from the neighbor, it indicates the time at which Neighbor.State 654 will be set to BLACKLISTED, if an RREP_Ack has not been received. 656 o If the value of Neighbor.State is HEARD and no RREP_Ack has been 657 requested, or if Neighbor.State is CONFIRMED, this time is set to 658 INFINITY_TIME. 660 Neighbor.Interface 661 The interface on which the link to the neighbor was established. 663 Neighbor.AckSeqNum 664 The next sequence number to use for the TIMESTAMP value in an 665 RREP_Ack request, in order to detect replay of an RREP_Ack 666 response. AckSeqNum is initialized to a random value. 668 Neighbor.HeardRERRSeqNum 669 The last heard sequence number used as the TIMESTAMP value in a 670 RERR received from this neighbor, saved in order to detect replay 671 of a RERR message. HeardRERRSeqNum is initialized to zero. 673 See Section 11.3 and Section 11.4 for more information on how 674 Neighbor.AckSeqNum and Neighbor.HeardRERRSeqNum are used. 676 4.4. Sequence Numbers 678 Sequence Numbers enable AODVv2 routers to determine the temporal 679 order of route discovery messages that originate from a AODVv2 680 router, and thus to identify stale routing information so that it can 681 be discarded. The sequence number fulfills the same roles as the 682 "Destination Sequence Number" of DSDV [Perkins94], and the AODV 683 Sequence Number in [RFC3561]. The sequence numbers from two 684 different routers are not comparable; route discovery messages with 685 sequence numbers belonging to two different routers cannot be 686 compared to determine temporal ordering. 688 Each AODVv2 router in the network MUST maintain its own sequence 689 number. All RREQ and RREP messages created by an AODVv2 router 690 include the router's sequence number, reported as a 16-bit unsigned 691 integer. Each AODVv2 router MUST ensure that its sequence number is 692 strictly increasing, and that it is incremented by one (1) whenever 693 an RREQ or RREP is created, except when the sequence number is 65,535 694 (the maximum value of a 16-bit unsigned integer), in which case it 695 MUST be reset to one (1) to achieve wrap around. The value zero (0) 696 is reserved to indicate that the router's sequence number is unknown. 698 An AODVv2 router MUST use its sequence number only on behalf of its 699 configured Router Clients; route messages forwarded by other routers 700 retain the originator's sequence number. 702 To determine if newly received information is stale and therefore 703 redundant compared to other information originated by the same 704 router, the sequence number attached to the information is compared 705 to the sequence number of existing information about the same route. 706 The comparison is carried out by subtracting the existing sequence 707 number from the newly received sequence number, using unsigned 708 arithmetic. The result of the subtraction is to be interpreted as a 709 signed 16-bit integer. 711 o If the result is negative, the newly received information is 712 considered older than the existing information and therefore stale 713 and redundant and MUST therefore be discarded. 715 o If the result is positive, the newly received information is newer 716 than the existing information and is not considered stale or 717 redundant and MUST therefore be processed. 719 o If the result is zero, the newly received information is not 720 considered stale, and therefore MUST be processed further in case 721 the new information offers a better route (see Section 6.7.1 and 722 Section 6.8). 724 Along with the algorithm in Section 6.7.1, maintaining temporal 725 ordering ensures loop freedom. 727 An AODVv2 router SHOULD maintain its sequence number in persistent 728 storage. On routers unable to store persistent AODVv2 state, 729 recovery can impose a performance penalty (e.g., in case of AODVv2 730 router reboot), since if a router loses its sequence number, there is 731 a delay (by default, on the order of minutes) before the router can 732 resume full operations. If the sequence number is lost, the router 733 MUST follow the procedure in Section 6.1 to safely resume routing 734 operations with a new sequence number. 736 4.5. Local Route Set 738 All AODVv2 routers MUST maintain a Local Route Set, containing 739 information obtained from AODVv2 route messages. The Local Route Set 740 may be considered to be stored separately from the forwarding plane's 741 routing table (referred to as Routing Information Base (RIB)), which 742 may be updated by other routing protocols operating on the AODVv2 743 router as well. The Routing Information Base is updated using 744 information from the Local Route Set. Alternatively, if the 745 information specified below can be added to RIB entries, 746 implementations MAY choose to modify the Routing Information Base 747 directly instead of maintaining a dedicated Local Route Set. In this 748 case, since the route table entry is accessed whenever a packet uses 749 the route, the LastUsed (see below) field can be tested to determine 750 the state of the route, including whether or not the route has timed 751 out. For example, if CurrentTime is less than LocalRoute.LastUsed + 752 ACTIVE_INTERVAL + MAX_IDLETIME, a valid route can still be used to 753 forward the packet. Otherwise, the route has timed out, and the 754 state of the route MUST be changed to be Invalid. When this method 755 of managing route timeouts can be used, AODVv2 does not otherwise 756 require the implementation to maintain a timer interrupt. This may 757 be considered an "on-demand" method for managing route timeouts. 759 Routes obtained from AODVv2 route messages are referred to in this 760 document as LocalRoutes, and MUST contain the following information: 762 LocalRoute.Address 763 An address, which, when combined with LocalRoute.PrefixLength, 764 describes the set of destination addresses for which this route 765 enables forwarding. 767 LocalRoute.PrefixLength 768 The prefix length, in bits, associated with LocalRoute.Address. 770 LocalRoute.SeqNum 771 The sequence number associated with LocalRoute.Address, obtained 772 from the last route message that successfully updated this entry. 774 LocalRoute.NextHop 775 The source IP address of the IP packet containing the AODVv2 776 message advertising the route to LocalRoute.Address, i.e., an IP 777 address of the AODVv2 router used for the next hop on the path 778 toward LocalRoute.Address. 780 LocalRoute.NextHopInterface 781 The interface used to send IP packets toward LocalRoute.Address. 783 LocalRoute.LastUsed 784 If this route is installed in the Routing Information Base, the 785 time it was last used to forward an IP packet. If not, the time 786 at which the LocalRoute was created. 788 LocalRoute.LastSeqNumUpdate 789 The time LocalRoute.SeqNum was last updated. 791 LocalRoute.MetricType 792 The type of metric associated with this route. See Section 5 for 793 information about AODVv2's handling of multiple metric types. 795 LocalRoute.Metric 796 The cost of the route toward LocalRoute.Address expressed in units 797 consistent with LocalRoute.MetricType. 799 LocalRoute.Precursors (optional feature) 800 A list of upstream neighbors using the route (see Section 10). 802 LocalRoute.SeqNoRtr 803 If nonzero, the IP address of the router that originated the 804 Sequence Number for this route. 806 LocalRoute.State 807 The last known state (Unconfirmed, Idle, Active, or Invalid) of 808 the route. 810 There are four possible states for a LocalRoute: 812 Unconfirmed 813 A route obtained from a Route Request message, which has not yet 814 been confirmed as bidirectional. It MUST NOT be stored in the RIB 815 to forward general data-plane traffic, but it can be used to 816 transmit RREP packets along with a request for bidirectional link 817 verification. An Unconfirmed route is not otherwise considered a 818 valid route. This state is only used for routes obtained through 819 RREQ messages. 821 Idle 822 A route that has been confirmed to be bidirectional, but has not 823 been used in the last ACTIVE_INTERVAL. It can be used for 824 forwarding IP packets, and therefore it is considered a valid 825 route. 827 Active 828 A valid route that has been used for forwarding IP packets during 829 the last ACTIVE_INTERVAL. 831 Invalid 832 A route that has expired or has broken. It MUST NOT be used for 833 forwarding IP packets. Invalid routes contain the destination's 834 sequence number, which may be useful when assessing freshness of 835 incoming routing information. 837 If the Local Route Set is stored separately from the RIB, then routes 838 are added to the RIB when LocalRoute.State becomes Active, and 839 removed from the RIB when LocalRoute.State becomes Invalid. Changes 840 to LocalRoute state are detailed in Section 6.10.1. 842 4.6. Multicast Message Set 844 Multicast RREQ messages SHOULD be tested for redundancy to avoid 845 unnecessary processing and forwarding. 847 The Multicast Message Set is a conceptual set which contains 848 information about previously received multicast messages, so that 849 incoming messages can be compared with previously received messages 850 to determine if the incoming information is redundant or stale, so 851 that the router can avoid sending redundant control traffic. 853 Multicast Message Set entries contain the following information: 855 McMsg.OrigPrefix 856 The prefix associated with OrigAddr, the source address of the IP 857 packet triggering the RREQ. 859 McMsg.OrigPrefixLen 860 The prefix length associated with McMsg.OrigPrefix, from the 861 Router Client Set entry on RREQ_Gen which includes OrigAddr. 863 McMsg.TargPrefix 864 The prefix associated with TargAddr, the destination address of 865 the IP packet triggering the route request. In an RREQ this MUST 866 be set to TargAddr. 868 McMsg.OrigSeqNum 869 The sequence number associated with the route to OrigPrefix, if 870 RteMsg is an RREQ. 872 McMsg.TargSeqNum 873 The sequence number associated with the route to TargPrefix. 875 McMsg.MetricType 876 The metric type of the route requested. 878 McMsg.Metric 879 The metric value received in the RteMsg. 881 McMsg.Timestamp 882 The last time this Multicast Message Set entry was updated. 884 McMsg.RemovalTime 885 The time at which this entry MUST be removed from the Multicast 886 Route Message Set. 888 McMsg.Interface 889 The interface on which the message was received. 891 McMsg.SeqNoRtr 892 If nonzero, the IP address of the router that originated the 893 Sequence Number for this route. 895 The Multicast Message Set is maintained so that no two entries have 896 the same OrigPrefix, OrigPrefixLen, TargPrefix, and MetricType. See 897 Section 6.8 for details about updating this set. 899 4.7. Route Error (RERR) Set 901 Each RERR message sent because no route exists for packet forwarding 902 SHOULD be recorded in a conceptual set called the Route Error (RERR) 903 Set. Each entry contains the following information: 905 RerrMsg.Timeout 906 The time after which the entry SHOULD be deleted. 908 RerrMsg.UnreachableAddress 909 The UnreachableAddress reported in the AddressList of the RERR. 911 RerrMsg.PktSource: 912 The PktSource of the RERR (see Section 2). 914 See Section 6.9 for instructions on how to update the set. 916 5. Metrics 918 Metrics measure a cost or quality associated with a route or a link, 919 e.g., latency, delay, financial cost, energy, etc. Metric values are 920 reported in Route Request and Route Reply messages. 922 In Route Request messages, the metric describes the cost of the route 923 from OrigPrefix to the router transmitting the Route Request. For 924 RREQ_Gen, this is the cost associated with the Router Client Set 925 entry which includes OrigAddr. For routers which forward the RREQ, 926 this is the cost from OrigPrefix to the forwarding router, combining 927 the metric value from the received RREQ message with knowledge of the 928 link cost from the sender to the receiver, i.e., the incoming link 929 cost. This updated route cost is included when forwarding the Route 930 Request message, and used to install a route to OrigPrefix. 932 Similarly, in Route Reply messages, the metric reflects the cost of 933 the route from TargPrefix to the router transmitting the Route Reply. 934 For RREP_Gen, this is the cost associated with the Router Client Set 935 entry which includes TargAddr. For routers which forward the RREP, 936 this is the cost from TargPrefix to the forwarding router, combining 937 the metric value from the received RREP message with knowledge of the 938 link cost from the sender to the receiver, i.e., the incoming link 939 cost. This updated route cost is included when forwarding the Route 940 Reply message, and used to install a route to TargPrefix. 942 When link metrics are symmetric, the cost of the routes installed in 943 the Local Route Set at each router will be correct. This assumption 944 is often inexact, but calculating incoming/outgoing metric data is 945 outside of scope of this document. The route discovered is good for 946 the requesting router, but the return path may not be the optimal 947 route. 949 AODVv2 enables the use of multiple metric types. Each route 950 discovery attempt indicates the metric type which is requested for 951 the route. Multiple valid routes may exist in the Local Route Set 952 for the same address and prefix length but for different metric 953 types. More than one route to a particular address and prefix length 954 MUST NOT exist in the Routing Information Base unless each packet can 955 be inspected to determine which route in the RIB has the proper 956 metric type as required for that packet. Otherwise, only one route 957 at a time to a particular address and prefix length may exist in the 958 RIB. The algorithm used to inspect the packet and make the 959 determination about which the routes should be installed in the 960 Routing Information Base is outside the scope of AODVv2. 962 For each MetricType, AODVv2 requires: 964 o A MetricType number, to indicate the metric type of a route. 965 Currently allocated MetricType numbers are listed in Section 13.4. 967 o A maximum value, denoted MAX_METRIC[MetricType]. This MUST always 968 be the maximum expressible metric value of type MetricType. Field 969 lengths associated with metric values are found in Section 13.4. 970 If the cost of a route exceeds MAX_METRIC[MetricType], the route 971 cannot be stored and is ignored. 973 o A function for incoming link cost, denoted Cost(L). Using 974 incoming link costs means that the route obtained has a metric 975 accurate for the direction back towards the originating router. 977 o A function for route cost, denoted Cost(R). 979 o A function to analyze routes for potential loops based on metric 980 information, denoted LoopFree(R1, R2). LoopFree verifies that a 981 route R2 is not a sub-section of another route R1. An AODVv2 982 router invokes LoopFree() as part of the process in Section 6.7.1, 983 when an advertised route (R1) and an existing LocalRoute (R2) have 984 the same destination address, metric type, and sequence number. 985 LoopFree returns FALSE to indicate that an advertised route is not 986 to be used to update a stored LocalRoute, as it may cause a 987 routing loop. In the case where the existing LocalRoute is 988 Invalid, it is possible that the advertised route includes the 989 existing LocalRoute and came from a router which did not yet 990 receive notification of the route becoming Invalid, so the 991 advertised route should not be used to update the Local Route Set, 992 in case it forms a loop to a broken route. 994 AODVv2 currently supports cost metrics where Cost(R) is strictly 995 increasing, by defining: 997 o Cost(R) := Sum of Cost(L) of each link in the route 999 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 1001 Implementers MAY consider metric types that are not strictly 1002 increasing, but the definitions of Cost and LoopFree functions for 1003 such types are undefined, and interoperability issues need to be 1004 considered. 1006 6. AODVv2 Protocol Operations 1008 AODVv2 protocol operations include: 1010 o managing sequence numbers, 1012 o monitoring next hop AODVv2 routers on discovered routes and 1013 updating the Neighbor Set, 1015 o performing route discovery and dealing with requests from other 1016 routers, 1018 o processing incoming route information and updating the Local Route 1019 Set, 1021 o updating the Multicast Message Set and suppressing redundant 1022 messages, and 1024 o reporting broken routes. 1026 These processes are discussed in detail in the following sections. 1028 6.1. Reinitialization 1030 When an AODVv2 router does not have information about its previous 1031 sequence number, or if its sequence number is lost at any point, the 1032 router reinitializes its sequence number to one (1). However, other 1033 AODVv2 routers may still hold sequence number information that this 1034 router previously issued. Since sequence number information is 1035 removed if there has been no update to the sequence number in 1036 MAX_SEQNUM_LIFETIME, the re-initializing router MUST wait for 1037 MAX_SEQNUM_LIFETIME before it creates any messages containing its new 1038 sequence number. Nevertheless, the re-initializing router can still 1039 participate in creating routes as an intermediate router. 1041 During this wait period, the router is permitted to do the following: 1043 o Process information in a received RREQ or RREP message to obtain a 1044 route to the originator or target of that route discovery 1046 o Forward a received RREQ or RREP 1048 o Send an RREP_Ack 1050 o Maintain valid routes in the Local Route Set 1051 o Create, process and forward RERR messages 1053 6.2. Next Hop Monitoring 1055 To ensure AODVv2 routers do not establish routes over uni-directional 1056 links, AODVv2 routers MUST verify that the link to the next hop 1057 router is bidirectional before marking a route as valid in the Local 1058 Route Set. 1060 AODVv2 provides a mechanism for testing bidirectional connectivity 1061 during route discovery, and blacklisting routers where bidirectional 1062 connectivity is not available. AODVv2 treats blacklisted routers as 1063 ineligible to be receivers of RREPs; then, a route through a 1064 different neighbor might be discovered. A route is not to be used 1065 for forwarding until the link to the next hop is confirmed to be 1066 bidirectional. AODVv2 routers do not need to monitor 1067 bidirectionality of links to neighboring routers which are not used 1068 as next hops on routes in the Local Route Set. 1070 o Bidirectional connectivity to upstream routers can be tested by 1071 requesting acknowledgement of RREP messages, i.e., by including an 1072 AckReq element to indicate that an acknowledgement is requested. 1073 This MUST be answered by sending an RREP_Ack in response. Receipt 1074 of an RREP_Ack within RREP_Ack_SENT_TIMEOUT demonstrates that 1075 bidirectional connectivity exists. Otherwise, the link is 1076 considered to be unidirectional. All AODVv2 routers MUST support 1077 this process, which is explained in Section 7.3. 1079 o Receipt of an RREP message containing the route to TargAddr 1080 confirms bidirectionality to the downstream router, since an RREP 1081 message is a reply to an RREQ message which previously crossed the 1082 link in the opposite direction. 1084 To assist with next hop monitoring, a Neighbor Set (Section 4.3) is 1085 maintained. When an RREQ or RREP is received, an AODVv2 router 1086 searches for an entry in the Neighbor Set where all of the following 1087 conditions are met: 1089 o Neighbor.IPAddress == IP address from which the RREQ or RREP was 1090 received 1092 o Neighbor.Interface == Interface on which the RREQ or RREP was 1093 received. 1095 If no such entry exists, a new entry is created as described in 1096 Section 6.3. While the value of Neighbor.State is HEARD, 1097 acknowledgement of RREP messages sent to that neighbor MUST be 1098 requested. If an acknowledgement is requested but not received 1099 within the timeout period, Neighbor.State for that neighbor MUST be 1100 set to BLACKLISTED. If an acknowledgement is received within the 1101 timeout period, Neighbor.State is set to CONFIRMED. When the value 1102 of Neighbor.State is CONFIRMED, the request for an acknowledgement of 1103 any other RREP message is unnecessary. AODVv2 does not require 1104 periodic or continuous recertification of bidirectionality. 1106 There are many external mechanisms that can provide indications of 1107 connectivity. Among them are the following: 1109 o MAC layer protocol assuring bidirectional links (for example, 1110 [dot11]) 1112 o Route timeout (see Section 6.10.1) 1114 o Lower layer triggers indicating message reception or change in 1115 link status (see, for example, [RFC8175]) 1117 o Listening for AODVv2 messages from neighbors even when destined to 1118 another IP address 1120 o Receipt of a Neighborhood Discovery Protocol HELLO message with 1121 the receiving router listed as a neighbor [RFC6130] 1123 o TCP[RFC0793] timeouts (although TCP takes a while to signal 1124 failure) 1126 If the MAC layer, or such an external process as listed above, 1127 signals that the link to a neighbor is bidirectional, the AODVv2 1128 router MAY update the matching Neighbor Set entry by changing the 1129 value of Neighbor.State to CONFIRMED. If an external process signals 1130 that a link is not bidirectional, then the value of Neighbor.State 1131 MAY be changed to BLACKLISTED. 1133 6.3. Neighbor Set Update 1135 On receipt of an RREQ or RREP message, the Neighbor Set MUST be 1136 checked for an entry with Neighbor.IPAddress which matches the source 1137 IP address of a packet containing the AODVv2 message. If no matching 1138 entry is found, a new entry is created. 1140 A new Neighbor Set entry is created as follows: 1142 o Neighbor.IPAddress := Source IP address of the received route 1143 message 1145 o Neighbor.State := HEARD 1146 o Neighbor.Timeout := INFINITY_TIME 1148 o Neighbor.Interface := the interface on which the RREQ or RREP was 1149 received. 1151 o Neighbor.AckSeqNum := a random value 1153 o Neighbor.HeardRERRSeqNum := 0 (see Section 4.1). 1155 When an RREP_Ack request is sent to a neighbor, the Neighbor Set 1156 entry is updated as follows: 1158 o Neighbor.Timeout := CurrentTime + RREP_Ack_SENT_TIMEOUT 1160 When a received message is one of the following: 1162 o an RREP which answers an RREQ sent within RREQ_WAIT_TIME over the 1163 same interface as Neighbor.Interface 1165 o an RREP_Ack response received from a Neighbor with Neighbor.State 1166 set to HEARD, where Neighbor.Timeout > CurrentTime 1168 then the link to the neighbor is bidirectional and the Neighbor Set 1169 entry is updated as follows: 1171 o Neighbor.State := CONFIRMED 1173 o Neighbor.Timeout := INFINITY_TIME 1175 If the Neighbor.Timeout is reached and Neighbor.State is HEARD, then 1176 an RREP_Ack response has not been received from the neighbor within 1177 RREP_Ack_SENT_TIMEOUT of sending the RREP_Ack request. The link is 1178 considered to be uni-directional and the Neighbor Set entry is 1179 updated as follows: 1181 o Neighbor.State := BLACKLISTED 1183 o Neighbor.Timeout := CurrentTime + MAX_BLACKLIST_TIME 1185 When the Neighbor.Timeout is reached and Neighbor.State is 1186 BLACKLISTED, the Neighbor Set entry is updated as follows: 1188 o Neighbor.State := HEARD 1190 o Neighbor.Timeout := INFINITY_TIME 1192 If an external mechanism reports a link as broken, the Neighbor Set 1193 entry MUST be removed. 1195 Route requests (RREQs) from neighbors with Neighbor.State set to 1196 BLACKLISTED MUST be ignored, to avoid persistent IP packet loss or 1197 protocol failures. Neighbor.Timeout allows the neighbor to again be 1198 allowed to participate in route discoveries after MAX_BLACKLIST_TIME, 1199 in case the link between the routers has become bidirectional. 1201 6.4. Interaction with the Forwarding Plane 1203 The signals described in the following are conceptual in nature, and 1204 can be implemented in various ways. The following descriptions of 1205 these signals and interactions are intended to assist implementers 1206 who may find them useful. Implementations of AODVv2 do not have to 1207 implement the forwarding plane separately from the control plane or 1208 data plane. By keeping track of success or failure of packet 1209 forwarding, AODV can avoid unnecessary route discovery operations, 1210 while still invalidating routes as early as possible to avoid 1211 transmitting packets over failed routes. 1213 AODVv2 makes use of the following signals: 1215 o A packet cannot be forwarded because a route is unavailable: 1216 AODVv2 needs to know the source and destination IP addresses of 1217 the packet. If the source of the packet is configured as a Router 1218 Client, the router MUST initiate route discovery to the 1219 destination. Otherwise, the router SHOULD create a Route Error 1220 message. 1222 o A packet is to be forwarded: AODVv2 needs to check the state of 1223 the entry in the Local Route Set to ensure that the route is still 1224 valid. 1226 o Packet forwarding succeeds: AODVv2 needs to update the record of 1227 when a route was last used to forward a packet, i.e. 1228 LocalRoute.LastUsed := CurrentTime(see Section 6.7.2). 1230 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1231 Error message. 1233 AODVv2 sends signals to the conceptual forwarding plane when: 1235 o A route discovery is in progress: buffering might be configured 1236 for packets requiring a route, while route discovery is attempted 1237 (see Section 6.6). 1239 o A route discovery failed: any buffered packets requiring that 1240 route should be discarded, and the source of the packet SHOULD be 1241 notified that the destination is unreachable (using an ICMP 1242 Destination Unreachable message [RFC4443]). Route discovery fails 1243 if an RREQ cannot be generated because the control message 1244 generation limit has been reached (see Section 6.5), or if an RREP 1245 is not received within RREQ_WAIT_TIME (see Section 6.6). 1247 o A route discovery succeeded: install a corresponding route into 1248 the Routing Information Base and begin transmitting any buffered 1249 packets. 1251 o A route has been made invalid: for the affected destination, 1252 remove the corresponding next hop from the Routing Information 1253 Base. 1255 o A route has been updated: update the corresponding route in the 1256 Routing Information Base. 1258 o If routes with more than one metric type are available to a 1259 destination, a way to identify the route that is allowable for the 1260 metric type associated with forwarding the incoming packet. 1262 6.5. Message Transmission 1264 AODVv2 sends [RFC5444] formatted messages using the parameters for 1265 port number and IP protocol specified in [RFC5498]. Mapping of 1266 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1267 multicast messages are sent to the link-local multicast address LL- 1268 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1269 MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2 1270 messages. Such messages MAY be transmitted via unicast. For 1271 example, this may occur for certain link-types (non-broadcast media), 1272 for manually configured router adjacencies, or in order to improve 1273 robustness. 1275 When multiple interfaces are available, an AODVv2 router transmitting 1276 a multicast message to LL-MANET-Routers MUST send the message on all 1277 interfaces that have been configured for AODVv2 operation, (see 1278 Section 4.1). 1280 To avoid congestion, each AODVv2 router's rate of message generation 1281 SHOULD be administratively configurable and rate-limited 1282 (CONTROL_TRAFFIC_LIMIT). Messages SHOULD NOT be sent more frequently 1283 than one message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If 1284 this threshold is reached, messages MUST be sent based on their 1285 priority: 1287 o Highest priority SHOULD be given to RREP_Ack messages. This 1288 allows links between routers to be confirmed as bidirectional and 1289 avoids undesired blacklisting of next hop routers. 1291 o Second priority SHOULD be given to RERR messages for undeliverable 1292 IP packets. This avoids repeated forwarding of packets over 1293 broken routes that are still in use by other routers. 1295 o Third priority SHOULD be given to RREP messages in order that 1296 RREQs do not time out. 1298 o Fourth priority SHOULD be given to RREQ messages. 1300 o Fifth priority SHOULD be given to RERR messages for newly 1301 invalidated routes. 1303 o Lowest priority SHOULD be given to RERR messages generated in 1304 response to RREP messages which cannot be forwarded. In this case 1305 the route request will be retried at a later point. 1307 To implement the congestion control, a queue length is set. If the 1308 queue is full, in order to queue a new message, a message of lower 1309 priority must be removed from the queue. If this is not possible, 1310 the new message MUST be discarded. The queue should be sorted in 1311 order of message priority 1313 6.6. Route Discovery, Retries and Buffering 1315 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1316 messages are multicast to solicit an RREP, whereas RREP are unicast. 1317 The constants used in this section are defined in Section 12. 1319 When an AODVv2 router needs to forward an IP packet (with source 1320 address OrigAddr and destination address TargAddr) from one of its 1321 Router Clients, it needs a route to TargAddr in its Routing 1322 Information Base. If no route exists, the AODVv2 router (RREQ_Gen) 1323 generates and multicasts a Route Request message (RREQ), on all 1324 configured interfaces, containing information about the source and 1325 destination. The procedure for this is described in Section 7.1.1. 1326 Each generated RREQ results in an increment to the router's sequence 1327 number. The AODVv2 router generating an RREQ is referred to as 1328 RREQ_Gen. 1330 Buffering might be configured for IP packets awaiting a route for 1331 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1332 of IP packets might have both positive and negative effects. TCP 1333 connection establishment will benefit if packets are queued while 1334 route discovery is performed [Koodli01], but real-time traffic, 1335 voice, and scheduled delivery may suffer if packets are buffered and 1336 subjected to delays. Recommendations for appropriate buffer methods 1337 are out of scope for this specification. Determining which packets 1338 to discard first when the buffer is full is a matter of policy. 1340 Using different (or no) buffer methods might affect performance but 1341 does not affect interoperability. 1343 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1344 a route toward TargAddr. This can be achieved by monitoring the 1345 entry in the Multicast Message Set that corresponds to the generated 1346 RREQ. When CurrentTime exceeds McMsg.Timestamp + RREQ_WAIT_TIME and 1347 no RREP has been received, RREQ_Gen will retry the route discovery. 1349 To reduce congestion in a network, repeated attempts at route 1350 discovery for a particular target address utilize a binary 1351 exponential backoff: for each additional attempt, the time to wait 1352 for receipt of the RREP is multiplied by 2. If the requested route 1353 is not discovered within the wait period, another RREQ is sent, up to 1354 a total of DISCOVERY_ATTEMPTS_MAX. This is the same technique used 1355 in AODV [RFC3561]. 1357 Through the use of bidirectional link monitoring and blacklists (see 1358 Section 6.2), uni-directional links on an initially selected route 1359 will be ignored on subsequent route discovery attempts. 1361 After DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an 1362 RREP response to the final RREQ, route discovery is considered to 1363 have failed. If an attempted route discovery has failed, RREQ_Gen 1364 SHOULD wait at least RREQ_HOLDDOWN_TIME before attempting another 1365 route discovery to the same destination, in order to avoid repeatedly 1366 generating control traffic that is unlikely to discover a route. Any 1367 IP packets buffered for TargAddr are also dropped, and a Destination 1368 Unreachable ICMP message (Type 3) with a code of 1 (Host Unreachable 1369 Error) MUST be sent to the source of the packet so that the 1370 application knows about the failure. 1372 If RREQ_Gen does receive a route message containing a route to 1373 TargAddr within the timeout, it processes the message according to 1374 Section 7. When a valid LocalRoute entry is created in the Local 1375 Route Set, the route is also installed in the Routing Information 1376 Base, and the router will begin sending the buffered IP packets. Any 1377 retry timers for the corresponding RREQ are then cancelled. 1379 During route discovery, all routers on the path obtain a route to 1380 both OrigPrefix and TargPrefix, so that routes are constructed in 1381 both directions. The route is optimized for the forward route. 1383 6.7. Processing Received Route Information 1385 A Route Request (RREQ) contains a route to OrigPrefix, and a Route 1386 Reply (RREP) contains a route to TargPrefix. Incoming information is 1387 checked to verify that it offers an improvement to existing 1388 information and that it would not create a routing loop, as explained 1389 in Section 6.7.1. If these checks pass, and if sufficient memory is 1390 available, refer to Section 6.7.2 for details about how to update the 1391 Local Route Set. 1393 RteMsg denotes the received route message (RREP or RREQ), AdvRte 1394 denotes the route defined by the information within the RteMsg, and 1395 LocalRoute denotes an existing entry in the Local Route Set which 1396 matches the address, prefix length, metric type, and SeqNoRtr of the 1397 AdvRte. 1399 AdvRte contains the following information extracted from the RteMsg: 1401 o AdvRte.Address := RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix 1402 (in RREP) 1404 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1405 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1406 in RteMsg, prefix length is the address length, in bits, of 1407 RteMsg.OrigPrefix (in RREQ) or RteMsg.TargPrefix (in RREP) 1409 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1410 (in RREP) 1412 o AdvRte.NextHop := the IP source address of the RteMsg (an address 1413 of the sending interface of the router from which the RteMsg was 1414 received) 1416 o AdvRte.MetricType := RteMsg.MetricType 1418 o AdvRte.Metric := RteMsg.Metric 1420 o AdvRte.Cost := Cost(R) using the cost function associated with the 1421 route's metric type. For cost metrics as described in Section 5, 1422 Cost(R) = AdvRte.Metric + Cost(L), where L is the link from the 1423 advertising router 1425 o AdvRte.SeqNoRtr := the IP address in the AddressList of type 1426 SeqNoRtr if one exists, otherwise 0 1428 6.7.1. Evaluating Route Information 1430 An incoming advertised route (AdvRte) is compared to existing 1431 LocalRoutes to determine whether the advertised route is to be used 1432 to update the AODVv2 Local Route Set. The incoming route information 1433 MUST be processed as follows: 1435 1. Search for LocalRoutes in the Local Route Set matching AdvRte's 1436 Address, PrefixLength, MetricType, and SeqNoRtr (the AODVv2 1437 router address corresponding to the sequence number). 1439 * If no matching LocalRoute exists, AdvRte MUST be used to 1440 update the Local Route Set and no further checks are required. 1442 * If matching LocalRoutes are found, continue to the next step. 1444 2. Compare sequence numbers using the technique described in 1445 Section 4.4 1447 * If AdvRte is more recent than all matching LocalRoutes, AdvRte 1448 MUST be used to update the Local Route Set and no further 1449 checks are required. 1451 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1452 Local Route Set. Ignore AdvRte for further processing. 1454 * If the sequence numbers are equal, continue to the next step. 1456 3. Test AdvRte against all matching LocalRoutes to ensure that a 1457 routing loop is not created (see Section 5). 1459 * If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte 1460 for further processing. AdvRte MUST NOT be used to update the 1461 Local Route Set because using the incoming information might 1462 cause a routing loop. 1464 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to the 1465 next step. 1467 4. Compare route costs 1469 * If AdvRte is better than all matching LocalRoutes, it MUST be 1470 used to update the Local Route Set because it offers 1471 improvement. 1473 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte 1474 SHOULD NOT be used to update the Local Route Set because it 1475 will offer no improvement. 1477 * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for 1478 further processing. AdvRte MUST NOT be used to update the 1479 Local Route Set because it does not offer any improvement. 1481 * If AdvRte is not better (i.e., it is worse or equal) but 1482 LocalRoute is Invalid, AdvRte SHOULD be used to update the 1483 Local Route Set because it can safely repair the existing 1484 Invalid LocalRoute. 1486 If the advertised route is to be used to update the Local Route Set, 1487 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1488 routes will remain in the Local Route Set. 1490 For information on how to apply these changes to the Routing 1491 Information Base, see Section 4.5. 1493 6.7.2. Applying Route Updates 1495 After determining that AdvRte is to be used to update the Local Route 1496 Set (as described in Section 6.7.1), the following procedure applies. 1498 If AdvRte is obtained from an RREQ message, the link to the next hop 1499 neighbor may not be confirmed as bidirectional (see Section 4.3). If 1500 there is no existing matching route in the Local Route Set, AdvRte 1501 MUST be installed to allow a corresponding RREP to be sent. If a 1502 matching entry already exists, and the link to the neighbor can be 1503 confirmed as bidirectional, AdvRte offers potential improvement. 1505 The route update is applied as follows: 1507 1. If no existing entry in the Local Route Set matches AdvRte's 1508 address, prefix length, metric type and SeqNoRtr, continue to 1509 Step 4 and create a new entry in the Local Route Set. 1511 2. If two matching LocalRoutes exist in the Local Route Set, one is 1512 a valid route, and one is an Unconfirmed route, AdvRte may offer 1513 further improvement to the Unconfirmed route, or may offer an 1514 update to the valid route. 1516 * If AdvRte.NextHop's Neighbor.State is HEARD, the advertised 1517 route may offer improvement to the existing valid route, if 1518 the link to the next hop can be confirmed as bidirectional. 1519 Continue processing from Step 5 to update the existing 1520 Unconfirmed LocalRoute. 1522 * If AdvRte.NextHop's Neighbor.State is CONFIRMED, the 1523 advertised route offers an update or improvement to the 1524 existing valid route. Continue processing from Step 5 to 1525 update the existing valid LocalRoute. 1527 3. If only one matching LocalRoute exists in the Local Route Set: 1529 * If AdvRte.NextHop's Neighbor.State is CONFIRMED, continue 1530 processing from Step 5 to update the existing LocalRoute. 1532 * If AdvRte.NextHop's Neighbor.State is HEARD, AdvRte may offer 1533 improvement the existing LocalRoute, if the link to 1534 AdvRte.NextHop can be confirmed as bidirectional. 1536 * If LocalRoute.State is Unconfirmed, AdvRte is an improvement 1537 to an existing Unconfirmed route. Continue processing from 1538 Step 5 to update the existing LocalRoute. 1540 * If LocalRoute.State is Invalid, AdvRte can replace the 1541 existing LocalRoute. Continue processing from Step 5 to 1542 update the existing LocalRoute. 1544 * If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored 1545 as an additional entry in the Local Route Set, with 1546 LocalRoute.State set to Unconfirmed. Continue processing from 1547 Step 4 to create a new LocalRoute. 1549 4. Create an entry in the Local Route Set and initialize as follows: 1551 * LocalRoute.Address := AdvRte.Address 1553 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1555 * LocalRoute.MetricType := AdvRte.MetricType 1557 5. Update the LocalRoute as follows: 1559 * LocalRoute.SeqNum := AdvRte.SeqNum 1561 * LocalRoute.NextHop := AdvRte.NextHop 1563 * LocalRoute.NextHopInterface := interface on which RteMsg was 1564 received 1566 * LocalRoute.Metric := AdvRte.Cost 1568 * LocalRoute.LastUsed := CurrentTime 1570 * LocalRoute.LastSeqNumUpdate := CurrentTime 1572 * LocalRoute.SeqNoRtr := AdvRte.SeqNoRtr 1574 6. If a new LocalRoute was created, or if the existing 1575 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1576 follows: 1578 * LocalRoute.State := Unconfirmed (if the next hop's 1579 Neighbor.State is HEARD) 1581 * LocalRoute.State := Idle (if the next hop's Neighbor.State is 1582 CONFIRMED) 1584 7. If an existing LocalRoute.State changed from Invalid or 1585 Unconfirmed to become Idle, any matching Unconfirmed LocalRoute 1586 with worse metric value SHOULD be expunged. 1588 8. If an existing LocalRoute was updated with a better metric value, 1589 any matching Unconfirmed LocalRoute with worse metric value 1590 SHOULD be expunged. 1592 9. If this update results in LocalRoute.State of Active or Idle, 1593 which matches a route request which is still in progress, the 1594 associated route request retry timers MUST be cancelled. 1596 If this update to the Local Route Set results in two LocalRoutes to 1597 the same address, the best LocalRoute will be Unconfirmed. In order 1598 to improve the route used for forwarding, the router SHOULD try to 1599 determine if the link to the next hop of that LocalRoute is 1600 bidirectional, by using that LocalRoute to forward future RREPs and 1601 request acknowledgements (see Section 7.2.1 and Section 7.3. 1603 6.8. Suppressing Redundant Messages (Multicast Message Set) 1605 When route messages are flooded in a MANET, an AODVv2 router may 1606 receive several instances of the same message. Forwarding every one 1607 of these would provide little additional benefit, while generating 1608 unnecessary signaling traffic and consequently additional 1609 interference. There have been a number of variations of AODV (e.g., 1610 [I-D.ietf-roll-aodv-rpl]), that have specified multicast for flooding 1611 RREP messages as well as RREQ messages. Since, in this document, 1612 suppression techniques are only needed for RREQ messages, multicast 1613 RREP messages are not considered. However, the technique involved is 1614 almost identical, and can be handled by substituting "RteMsg" instead 1615 of RREQ in the following text. 1617 Each AODVv2 router stores information about recently received RREQ 1618 messages in the AODVv2 Multicast Message Set (Section 4.6). 1620 In this section, an entry in the Multicast Message Set will be called 1621 a "multicast entry" for short. Each multicast entry SHOULD be 1622 maintained for at least RteMsg_ENTRY_TIME after the last Timestamp 1623 update in order to account for long-lived RREQs traversing the 1624 network. An entry MUST be deleted when the sequence number is no 1625 longer valid, i.e., after MAX_SEQNUM_LIFETIME. Memory-constrained 1626 devices MAY remove the entry before this time. 1628 Received RREQs are tested against multicast entries containing 1629 information about previously received RREQs. A multicast entry is 1630 considered to be compatible with a received RREQ, or another 1631 multicast entry, if they both contain the same OrigPrefix, 1632 OrigPrefixLen, TargPrefix, and MetricType. A multicast entry is 1633 considered to be comparable with a received RREQ, or another 1634 multicast entry, if they are compatible and if, in addition, they 1635 both have the same SeqNoRtr. These terms will be used in the 1636 following algorithm determining how to process a received RREQ, and 1637 whether or not the RREQ is redundant. 1639 If the received message is determined to be redundant, no forwarding 1640 or response to the message is needed. A message is considered to be 1641 redundant if either (a) a comparable newer (as determined by the 1642 OrigSeqNum) entry has already been received with information about 1643 the source and destination addresses of the route discovery operation 1644 or (b) it cannot be determined whether the message is newer compared 1645 to existing entries, but the received message metric value is not any 1646 better than metric values in compatible multicast entries. 1648 To use the received RREQ to update the Multicast Message Set, and to 1649 determine whether or not the received RREQ requires additional 1650 processing as specified in Section 7, perform the following steps: 1652 1. First, search for a comparable multicast entry. If there is no 1653 such entry, then create a new entry as follows: 1655 * McMsg.OrigPrefix := OrigPrefix from the RREQ 1657 * McMsg.OrigPrefixLen := the prefix length associated with 1658 OrigPrefix 1660 * McMsg.TargPrefix := TargPrefix from the message 1662 * McMsg.SeqNoRtr := the SeqNoRtr associated with RREQ if 1663 present, otherwise the sequence number associated with 1664 OrigPrefix 1666 * McMsg.OrigSeqNum := the sequence number associated with 1667 OrigPrefix 1669 * McMsg.Metric := the metric value associated with OrigPrefix in 1670 the received RREQ 1672 * McMsg.MetricType := the metric type associated with 1673 McMsg.Metric 1675 * McMsg.Interface := the network interface on which the RREQ was 1676 received. 1678 * McMsg.Timestamp := CurrentTime 1680 * McMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1682 2. Otherwise, if there is a comparable multicast entry, first update 1683 the timing information: 1685 * McMsg.Timestamp := CurrentTime 1687 * McMsg.RemovalTime := CurrentTime + MAX_SEQNUM_LIFETIME 1689 Then compare sequence numbers using the technique described in 1690 Section 4.4: 1692 * If the multicast entry is newer compared to the received RREQ, 1693 drop the RREQ and discontinue processing. 1695 * Otherwise, if the sequence numbers are the same, and the 1696 metric value for the multicast entry is no worse than the 1697 metric value in the received RREQ, drop the RREQ and 1698 discontinue processing. 1700 Otherwise the RREQ is newer than the multicast entry or has a 1701 better metric. Continue as follows: 1703 * McMsg.OrigSeqNum := the sequence number associated with 1704 OrigPrefix 1706 * McMsg.Metric := the metric value associated with OrigPrefix in 1707 the received RREQ 1709 3. Compare the metric values for any other compatible entries with 1710 the updated multicast entry containing the information from the 1711 received RREQ. If any other compatible entry has a metric as 1712 good or better than that from the received RREQ, then drop the 1713 RREQ and discontinue processing. 1715 If processing for the RREQ has not been discontinued according to the 1716 above instructions, then continue processing the message as specified 1717 in Section 7.1.3. 1719 6.9. Suppressing Redundant Route Error Messages (Route Error Set) 1721 In order to avoid flooding the network with RERR messages when a 1722 stream of IP packets to an unreachable address arrives, an AODVv2 1723 router SHOULD avoid creating duplicate messages by determining 1724 whether an equivalent RERR has recently been sent. This is achieved 1725 with the help of the Route Error Set (see Section 4.7). 1727 To determine if a RERR should be created: 1729 1. Search for an entry in the Route Error Set where: 1731 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1732 reported 1734 * RerrMsg.PktSource == PktSource to be included in the RERR 1736 If a matching entry is found, no further processing is required 1737 and the RERR SHOULD NOT be sent. 1739 2. If no matching entry is found, a new entry with the following 1740 properties is created, and the RERR is created and sent as 1741 described in Section 7.4.1: 1743 * RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT 1745 * RerrMsg.UnreachableAddress == UnreachableAddress to be 1746 reported 1748 * RerrMsg.PktSource == PktSource to be included in the RERR. 1750 6.10. Local Route Set Maintenance 1752 Route maintenance involves the following operations: 1754 o monitoring LocalRoutes in the Local Route Set, 1756 o updating LocalRoute.State to handle route timeouts, 1758 o (for possibly unidirectional links) confirming a route to 1759 OrigAddr, 1761 o reporting routes that become Invalid. 1763 6.10.1. LocalRoute State Changes 1765 During normal operation, AODVv2 does not require explicit timeouts to 1766 manage the lifetime of a valid route. At any time, any LocalRoute 1767 MAY be examined and updated according to the rules below. In case a 1768 Routing Information Base is used for forwarding, the corresponding 1769 RIB entry MUST be updated as soon as the state of a LocalRoute.State 1770 changes. Otherwise, if timers are not used to prompt updates of 1771 LocalRoute.State, the LocalRoute.State MUST be checked before IP 1772 packet forwarding and before any operation based on LocalRoute.State. 1774 Route timeout behaviour is as follows: 1776 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1777 LocalRoute.LastSeqNumUpdate. 1779 o An Idle route MUST be marked as Active when used to forward an IP 1780 packet. 1782 o If an Idle route is not used to forward an IP packet within 1783 MAX_IDLETIME, LocalRoute.State MUST be set to Invalid. 1785 o An Invalid route SHOULD remain in the Local Route Set, since 1786 LocalRoute.SeqNum is used to classify future information about 1787 LocalRoute.Address as stale or fresh. 1789 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1790 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 0. 1791 This is required so that any AODVv2 routers following the re- 1792 initialization procedure (see Section 6.1) can safely begin 1793 routing functions using a new sequence number. A LocalRoute with 1794 LocalRoute.State set to Active or Idle can remain in the Local 1795 Route Set after the sequence number has been set to 0, for example 1796 if the route is reliably carrying traffic. If LocalRoute.State is 1797 Invalid, or later becomes Invalid, the LocalRoute MUST be expunged 1798 from the Local Route Set. 1800 LocalRoutes can become Invalid before a timeout occurs, as follows: 1802 o If an external mechanism reports a link as broken, all LocalRoutes 1803 using that link for LocalRoute.NextHop MUST immediately have 1804 LocalRoute.State set to Invalid. 1806 o LocalRoute.State MUST immediately be set to Invalid if a Route 1807 Error (RERR) message is received where: 1809 * The sender is LocalRoute.NextHop, or PktSource is a Router 1810 Client address 1812 * There is an Address in AddressList which matches 1813 LocalRoute.Address, and: 1815 + The prefix length associated with this Address, if any, 1816 matches LocalRoute.PrefixLength 1818 + The sequence number associated with this Address, if any, is 1819 newer or equal to LocalRoute.SeqNum (see Section 4.4) 1821 + The metric type associated with this Address matches 1822 LocalRoute.MetricType 1824 A LocalRoute can be confirmed by inferring connectivity to OrigAddr. 1826 o When an AODVv2 router sends an RREP to OrigAddr for destination 1827 TargAddr, and subsequently the AODVv2 router receives a packet 1828 from OrigAddr with destination TargAddr, the AODVv2 router infers 1829 that the route to OrigAddr has been confirmed. The corresponding 1830 state for LocalRoute.OrigAddr is changed to Active. 1832 LocalRoutes are updated when Neighbor.State is updated: 1834 o While the value of Neighbor.State is set to HEARD, any routes in 1835 the Local Route Set using that neighbor as a next hop MUST have 1836 LocalRoute.State set to Unconfirmed. 1838 o When the value of Neighbor.State is set to BLACKLISTED, any valid 1839 routes in the Local Route Set using that neighbor for their next 1840 hop MUST have LocalRoute.State set to Invalid. 1842 o When a Neighbor Set entry is removed, all routes in the Local 1843 Route Set using that neighbor as next hop MUST have 1844 LocalRoute.State set to Invalid. 1846 Memory constrained devices MAY choose to expunge routes from the 1847 AODVv2 Local Route Set at other times, but MUST adhere to the 1848 following rules: 1850 o An Active route MUST NOT be expunged, as it is in use. If 1851 deleted, IP traffic forwarded to this router would prompt 1852 generation of a Route Error message, necessitating a Route Request 1853 to be generated by the originator's router to re-establish the 1854 route. 1856 o An Idle route SHOULD NOT be expunged, as it is still valid for 1857 forwarding IP traffic. If deleted, this could result in dropped 1858 IP packets and a Route Request could be multicasted to re- 1859 establish the route. 1861 o Any Invalid route MAY be expunged. Least recently used Invalid 1862 routes SHOULD be expunged first, since the sequence number 1863 information is less likely to be useful. 1865 o An Unconfirmed route MUST NOT be expunged if it was installed 1866 within the last RREQ_WAIT_TIME, because it may correspond to a 1867 route discovery in progress. A Route Reply message might be 1868 received which needs to use the LocalRoute.NextHop information. 1869 Otherwise, it MAY be expunged. 1871 6.10.2. Reporting Invalid Routes 1873 When LocalRoute.State changes from Active to Invalid as a result of a 1874 broken link or a received Route Error (RERR) message, other AODVv2 1875 routers MUST be informed by sending an RERR message containing 1876 details of the invalidated route. 1878 An RERR message MUST also be sent when an AODVv2 router receives an 1879 RREP message to forward, but the LocalRoute to the OrigAddr in the 1880 RREP is not available or is marked as Invalid. 1882 A packet or message triggering the RERR MUST be discarded. 1884 Generation of an RERR message is described in Section 7.4.1. 1886 7. AODVv2 Protocol Messages 1888 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1889 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1890 (RERR). 1892 Each AODVv2 message is defined as a set of data. Rules for the 1893 generation, reception and forwarding of each message type are 1894 described in the following sections. Section 8 discusses how the 1895 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1896 TLVs. 1898 7.1. Route Request (RREQ) Message 1900 Route Request messages are used in route discovery operations to 1901 request a route to a specified target address. RREQ messages have 1902 the following contents: 1904 +-----------------------------------------------------------------+ 1905 | msg_hop_limit | 1906 +-----------------------------------------------------------------+ 1907 | AddressList | 1908 +-----------------------------------------------------------------+ 1909 | PrefixLengthList (optional) | 1910 +-----------------------------------------------------------------+ 1911 | OrigSeqNum, (optional) TargSeqNum | 1912 +-----------------------------------------------------------------+ 1913 | MetricType | 1914 +-----------------------------------------------------------------+ 1915 | OrigMetric | 1916 +-----------------------------------------------------------------+ 1918 Figure 3: RREQ message contents 1920 msg_hop_limit 1921 The remaining number of hops allowed for dissemination of the RREQ 1922 message. 1924 AddressList 1925 Contains: 1927 * OrigPrefix, from the Router Client Set entry which includes 1928 OrigAddr, the source address of the IP packet for which a route 1929 is requested, 1931 * TargPrefix, set to TargAddr, the destination address of the IP 1932 packet for which a route is requested, and 1934 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 1935 OrigRtr -- i.e., the router that originated the Sequence Number 1936 for this RREQ. 1938 PrefixLengthList 1939 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1940 associated with the Router Client Set entry which includes 1941 OrigAddr. If omitted, the prefix length is equal to OrigAddr's 1942 address length in bits. 1944 OrigSeqNum 1945 The sequence number associated with OrigPrefix. 1947 TargSeqNum 1948 A sequence number associated with an existing Invalid route to 1949 TargAddr. This MAY be included if available. 1951 MetricType 1952 The metric type associated with OrigMetric. 1954 OrigMetric 1955 The metric value associated with the route to OrigPrefix, as 1956 determined by the sender of the message. 1958 7.1.1. RREQ Generation 1960 An RREQ is generated to discover a route when an IP packet needs to 1961 be forwarded for a Router Client, and no valid route currently exists 1962 for the packet's destination in the Routing Information Base. 1964 If the limit for the rate of AODVv2 control message generation has 1965 been reached, no message SHOULD be generated Section 6.5. Before 1966 creating an RREQ, the router SHOULD check the Multicast Message Set 1967 to see if a compatible RREQ has already been sent for the requested 1968 destination. If so, and the wait time for a reply has not yet been 1969 reached, the router SHOULD continue to await a response without 1970 generating a new RREQ. If the timeout has been reached, a new RREQ 1971 MAY be generated. If buffering is configured, incoming IP packets 1972 awaiting this route SHOULD be buffered until the route discovery is 1973 completed. 1975 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1976 this procedure: 1978 1. Set msg_hop_limit := MAX_HOPCOUNT 1980 2. Set AddressList := {OrigPrefix, TargPrefix} 1982 3. For the PrefixLengthList: 1984 * If OrigAddr is part of an address range configured as a Router 1985 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1986 null}. 1988 * Otherwise, omit PrefixLengthList. 1990 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 1991 IP address to AddressList, with AddressType SeqNoRtr. 1993 4. For OrigSeqNum: 1995 * Increment the router Sequence Number as specified in 1996 Section 4.4. 1998 * Set OrigSeqNum := router Sequence Number. 2000 5. For TargSeqNum: 2002 * If an Invalid route exists in the Local Route Set matching 2003 TargAddr using longest prefix matching and has a valid 2004 sequence number, set TargSeqNum := LocalRoute.SeqNum. 2006 * If no Invalid route exists in the Local Route Set matching 2007 TargAddr, or the route doesn't have a sequence number, omit 2008 TargSeqNum. 2010 6. Include MetricType and set the type accordingly 2012 7. Find the Router Client Set entry where RouterClient.IPAddress == 2013 OrigPrefix: 2015 * Set OrigMetric := RouterClient.Cost 2017 This AODVv2 message is used to create a corresponding [RFC5444] 2018 message (see Section 8) which is handed to the RFC5444 multiplexer 2019 for further processing. By default, the multiplexer is instructed to 2020 multicast RREQ messages to LL-MANET-Routers on all interfaces 2021 configured for AODVv2 operation. 2023 7.1.2. RREQ Reception 2025 Upon receiving a Route Request, an AODVv2 router performs the 2026 following steps: 2028 1. Check and update the Neighbor Set according to Section 6.3 2030 * If the sender has Neighbor.State set to BLACKLISTED, ignore 2031 this RREQ for further processing. 2033 2. Verify that the message contains the required data: 2034 msg_hop_limit, OrigPrefix, TargPrefix, OrigSeqNum, and 2035 OrigMetric, and that OrigPrefix and TargPrefix are valid address 2036 prefixes 2038 * If not, ignore this RREQ for further processing. 2040 3. Check that the MetricType is supported and configured for use 2042 * If so, continue to the next numbered step. 2044 * Otherwise, if the TargPrefix matches an entry in the Router 2045 Client Set, send an ICMP Destination Unreachable message to 2046 the source with Code value set to "Metric Type Mismatch" (see 2047 Section 13.6). 2049 * Ignore this RREQ for further processing. 2051 4. Determine whether the cost of the advertised route will exceed 2052 the maximum allowed metric value for the metric type (Metric <= 2053 MAX_METRIC[MetricType] - Cost(L)) 2055 * If it will, ignore this RREQ for further processing. 2057 5. Process the route to OrigPrefix as specified in Section 6.7 2059 6. Determine whether or not the information in the message is 2060 redundant, by following the procedure in Section 6.8; if 2061 redundant, ignore this RREQ for further processing. 2063 7. Check if the TargPrefix matches an entry in the Router Client Set 2065 * If so, generate an RREP as specified in Section 7.2.1. 2067 * If not, continue to RREQ forwarding Section 7.2.3. 2069 7.1.3. RREQ Forwarding 2071 Forwarding or responding to a RteMsg provides up-to-date information 2072 and improved metrics to other routers. If a RteMsg is not forwarded, 2073 routes needed by applications may not be discovered. 2075 By forwarding an RREQ, a router advertises that it will forward IP 2076 packets to the OrigPrefix contained in the RREQ according to the 2077 information enclosed. The router MAY choose not to forward the RREQ, 2078 for example if the router is heavily loaded or low on energy and 2079 therefore unwilling to advertise routing capability for more traffic. 2080 This could, however, decrease connectivity in the network or result 2081 in non-optimal paths. 2083 The RREQ MUST NOT be forwarded if the received msg_hop_limit = 1, or 2084 if the limit for the rate of AODVv2 control message generation has 2085 been reached. Otherwise, the RREQ is updated and forwarded as 2086 follows: 2088 1. Set msg_hop_limit := received msg_hop_limit - 1 2090 2. Set OrigMetric := LocalRoute[OrigPrefix].Metric 2092 This modified RREQ is handed to the [RFC5444] multiplexer for further 2093 processing. By default, the multiplexer is instructed to multicast 2094 the message to LL-MANET-Routers on all interfaces configured for 2095 AODVv2 operation. 2097 7.2. Route Reply (RREP) Message 2099 When a Route Request message is received, requesting a route to a 2100 target address (TargAddr) which is configured as part of a Router 2101 Client Set entry, a Route Reply message is sent in response. The 2102 RREP offers a route to TargPrefix. 2104 RREP messages have the following contents: 2106 +-----------------------------------------------------------------+ 2107 | msg_hop_limit | 2108 +-----------------------------------------------------------------+ 2109 | AddressList | 2110 +-----------------------------------------------------------------+ 2111 | PrefixLengthList (optional) | 2112 +-----------------------------------------------------------------+ 2113 | TargSeqNum | 2114 +-----------------------------------------------------------------+ 2115 | MetricType | 2116 +-----------------------------------------------------------------+ 2117 | TargMetric | 2118 +-----------------------------------------------------------------+ 2120 Figure 4: RREP message contents 2122 msg_hop_limit 2123 The remaining number of hops allowed for dissemination of the RREP 2124 message. 2126 AddressList 2127 Contains: 2129 * OrigPrefix, from the Router Client entry which includes 2130 OrigAddr, the source address of the IP packet for which a route 2131 is requested 2133 * TargPrefix, set to TargAddr, the destination address of the IP 2134 packet for which a route is requested. 2136 * Optionally, if RouterClient.SeqNoRtr is true, the IP address of 2137 TargRtr -- i.e., the router that originated the Sequence Number 2138 for this RREP. 2140 PrefixLengthList 2141 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 2142 associated with the Router Client Set entry which includes 2143 TargAddr. If omitted, the prefix length is equal to TargAddr's 2144 address length, in bits. 2146 TargSeqNum 2147 The sequence number associated with TargPrefix. 2149 MetricType 2150 The metric type associated with TargMetric. 2152 TargMetric 2153 The metric value associated with the route to TargPrefix, as seen 2154 from the sender of the message. 2156 7.2.1. RREP Generation 2158 A Route Reply message is generated when a Route Request for a Router 2159 Client of the AODVv2 router arrives. This is the case when 2160 RteMsg.TargPrefix matches an entry in the Router Client Set of the 2161 AODVv2 router. 2163 Before creating an RREP, the router SHOULD check whether 2164 CONTROL_TRAFFIC_LIMIT has been reached. If so, the RREP SHOULD NOT 2165 be created. 2167 The RREP will traverse the path of the route to OrigPrefix. If the 2168 best route to OrigPrefix in the Local Route Set is Unconfirmed, the 2169 link to the next hop neighbor is not yet confirmed as bidirectional 2170 (see Section 6.2). In this case an RREP_Ack MUST also be sent as 2171 described in Section 7.3, in order to request an acknowledgement 2172 message from the next hop router to prove that the link is 2173 bidirectional. If the best route to OrigPrefix in the Local Route 2174 Set is valid, the link to the next hop neighbor is already confirmed 2175 as bidirectional, and no acknowledgement is required. 2177 Implementations MAY allow a number of retries of the RREP if a 2178 requested acknowledgement is not received within 2179 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 2180 maximum of RREP_RETRIES, using the same exponential backoff described 2181 in Section 6.6 for RREQ retries. The acknowledgement MUST be 2182 considered to have failed after the wait time for an RREP_Ack 2183 response to the final RREP. 2185 To generate the RREP, the router (also referred to as RREP_Gen) 2186 follows this procedure: 2188 1. Set msg_hop_limit := MAX_HOPCOUNT - msg_hop_limit from the 2189 received RREQ message 2191 2. Set AddressList := {OrigPrefix, TargPrefix} 2192 * If RouterClient.SeqNoRtr is nonzero, then add the router's own 2193 IP address to AddressList, with AddressType SeqNoRtr. 2195 3. For the PrefixLengthList: 2197 * If TargAddr is part of an address range configured as a Router 2198 Client, set PrefixLengthList := {null, 2199 RouterClient.PrefixLength}. 2201 * Otherwise, omit PrefixLengthList. 2203 4. For the TargSeqNum: 2205 * Increment the router Sequence Number as specified in 2206 Section 4.4. 2208 * Set TargSeqNum := router Sequence Number. 2210 5. Include MetricType and set the type to match the MetricType in 2211 the received RREQ message. 2213 6. Set TargMetric := RouterClient.Cost for the Router Client Set 2214 entry which includes TargAddr. 2216 This AODVv2 message is used to create a corresponding [RFC5444] 2217 message (see Section 8) which is handed to the RFC5444 multiplexer 2218 for further processing. The multiplexer is instructed to unicast the 2219 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2220 LocalRoute[OrigPrefix].NextHopInterface. 2222 7.2.2. RREP Reception 2224 Upon receiving a Route Reply, an AODVv2 router performs the following 2225 steps: 2227 1. Verify that the message contains the required data: 2228 msg_hop_limit, OrigPrefix, TargPrefix, TargSeqNum, and 2229 TargMetric, and that OrigPrefix and TargPrefix are valid 2230 addresses 2232 * If not, ignore this RREP for further processing. 2234 2. Check that the MetricType is supported and configured for use 2236 * If not, ignore this RREP for further processing. 2238 3. If this RREP does not correspond to an RREQ generated or 2239 forwarded in the last RREQ_WAIT_TIME, ignore for further 2240 processing. 2242 4. If the Multicast Message Set does not contain an entry where: 2244 o McMsg.OrigPrefix == RREP.OrigPrefix 2246 o McMsg.OrigPrefixLen == RREP.OrigPrefixLen 2248 o McMsg.TargAddr exists within RREP.TargPrefix 2250 o McMsg.OrigSeqNum <= RREP.OrigSeqNum 2252 o McMsg.SeqNoRtr = RREP.SeqNoRtr 2254 o McMsg.MetricType == RREP.MetricType 2256 o McMsg.Timestamp > CurrentTime - RREQ_WAIT_TIME 2258 o McMsg.Interface == The interface on which the RREP was received 2260 then, ignore this RREP for further processing, since it does not 2261 correspond to a previously sent RREQ. Otherwise continue as follows: 2263 1. Update the Neighbor Set according to Section 6.3 2265 2. Determine whether the cost of the advertised route exceeds the 2266 maximum allowed metric value for the metric type (Metric <= 2267 MAX_METRIC[MetricType] - Cost(L)) 2269 * If it does, ignore this RREP for further processing. 2271 3. Process the route to TargPrefix as specified in Section 6.7 2273 4. Determine whether the message is redundant by comparing to 2274 entries in the Multicast Message Set (Section 6.8) 2276 * If redundant, ignore this RREP for further processing. 2278 * If not redundant, save the information in the Multicast 2279 Message Set to identify future redundant RREP messages and 2280 continue processing. 2282 5. Determine whether the OrigPrefix matches an entry in the Router 2283 Client Set 2285 * If so, no further processing is necessary. 2287 * If not, continue to the next step. 2289 6. Determine whether a valid (Active or Idle) or Unconfirmed 2290 LocalRoute exists to OrigPrefix 2292 * If so, continue to RREP forwarding Section 7.2.3. 2294 * If not, a Route Error message SHOULD be transmitted toward 2295 TargPrefix according to Section 7.4.1; the RREP MUST be 2296 discarded and not forwarded. 2298 7.2.3. RREP Forwarding 2300 A received Route Reply message is forwarded toward OrigPrefix. By 2301 forwarding the RREP, a router advertises that it has a route to 2302 TargPrefix. 2304 The RREP MUST NOT be forwarded if the received msg_hop_limit = 1, or 2305 if CONTROL_TRAFFIC_LIMIT has been reached. Otherwise, the router 2306 MUST forward the RREP. 2308 The procedure for RREP forwarding is as follows: 2310 1. Set msg_hop_limit := received msg_hop_limit - 1 2312 2. If the link to the next hop router toward OrigAddr is not known 2313 to be bidirectional, also verify bidirectionality (see 2314 Section 6.2). 2316 3. Set TargMetric := LocalRoute[TargPrefix].Metric 2318 This modified message is handed to the [RFC5444] multiplexer for 2319 further processing. The multiplexer is instructed to unicast the 2320 RREP to LocalRoute[OrigPrefix].NextHop. The RREP MUST be sent over 2321 LocalRoute[OrigPrefix].NextHopInterface. 2323 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2325 The Route Reply Acknowledgement is used as both a request and a 2326 response message to test bidirectionality of a link over which a 2327 Route Reply has also been sent. The router which forwards the RREP 2328 MUST send a Route Reply Acknowledgement message to the intended next 2329 hop, if the link to the next hop neighbor is not yet confirmed as 2330 bidirectional. 2332 The receiving router MUST then reply with a Route Reply 2333 Acknowledgement response message. 2335 When the Route Reply Acknowledgement response message is received by 2336 the sender of the RREP, it confirms that the link between the two 2337 routers is bidirectional (see Section 6.2). 2339 If the Route Reply Acknowledgement is not received within 2340 RREP_Ack_SENT_TIMEOUT, the link is determined to be unidirectional. 2342 +-----------------------------------------------------------------+ 2343 | AckReq (optional) | 2344 +-----------------------------------------------------------------+ 2346 Figure 5: RREP_Ack message contents 2348 7.3.1. RREP_Ack Request Generation 2350 An RREP_Ack MUST be generated if a Route Reply is sent over a link 2351 which is not known to be bidirectional. It includes an AckReq 2352 element to indicate that it is a request for acknowledgement. 2354 The RREP_Ack SHOULD NOT be generated if the limit for the rate of 2355 AODVv2 control message generation has been reached. 2357 The [RFC5444] representation of the RREP_Ack is discussed in 2358 Section 8. 2360 RREP_Ack requests MUST be unicast to LocalRoute[OrigPrefix].NextHop 2361 via LocalRoute[OrigPrefix].NextHopInterface. The multiplexer SHOULD 2362 be instructed to send the RREP_Ack in the same [RFC5444] packet as 2363 the RREP. 2365 The Neighbor Set entry for LocalRoute[OrigPrefix].NextHop MUST also 2366 be updated to indicate that an RREP_Ack is required (see 2367 Section 6.3). 2369 7.3.2. RREP_Ack Reception 2371 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2372 steps: 2374 1. Determine whether an AckReq element is included: 2376 * If so, create an RREP_Ack Response as described in 2377 Section 7.3.3. No further processing is required. 2379 * If not, continue to the next step. 2381 2. Determine whether the Neighbor Set contains an entry where: 2383 * Neighbor.IPAddress == IP source address of the RREP_Ack 2384 message 2386 * Neighbor.State == HEARD 2388 * Neighbor.Timeout < CurrentTime 2390 * Neighbor.Interface matches the interface on which the RREP_Ack 2391 was received 2393 If no such entry is found, the RREP_Ack was not expected; no 2394 actions are required and processing ends. Otherwise, the router 2395 sets Neighbor.Timeout to INFINITY_TIME, and processing continues 2396 to the next step. 2398 3. Update the Neighbor Set according to Section 6.3, including 2399 updating routes using this Neighbor as LocalRoute.NextHop. 2401 7.3.3. RREP_Ack Response Generation 2403 An RREP_Ack response MUST be generated if a received RREP_Ack 2404 includes an AckReq, unless the limit for the rate of AODVv2 control 2405 message generation has been reached in which case the RREP_Ack 2406 response SHOULD NOT be generated. 2408 There is no further data in an RREP_Ack response. The [RFC5444] 2409 representation is discussed in Section 8. In this case, the 2410 multiplexer is instructed to unicast the RREP_Ack to the source IP 2411 address of the RREP_Ack message that requested it, over the same 2412 interface on which the RREP_Ack was received. 2414 7.4. Route Error (RERR) Message 2416 A Route Error message is generated by an AODVv2 router to notify 2417 other AODVv2 routers about routes that are no longer available. An 2418 RERR message has the following contents: 2420 +-----------------------------------------------------------------+ 2421 | PktSource (optional) | 2422 +-----------------------------------------------------------------+ 2423 | AddressList | 2424 +-----------------------------------------------------------------+ 2425 | PrefixLengthList (optional) | 2426 +-----------------------------------------------------------------+ 2427 | SeqNumList (optional) | 2428 +-----------------------------------------------------------------+ 2429 | MetricTypeList | 2430 +-----------------------------------------------------------------+ 2432 Figure 6: RERR message contents 2434 PktSource 2435 The source address of the IP packet triggering the RERR. If the 2436 RERR is triggered by a broken link, PktSource is not required. 2438 AddressList 2439 The addresses of the routes not available through RERR_Gen. 2441 PrefixLengthList 2442 The prefix lengths, in bits, associated with the routes not 2443 available through RERR_Gen. These values indicate whether routes 2444 represent a single device or an address range. 2446 SeqNumList 2447 The sequence numbers (where known) of the routes not available 2448 through RERR_Gen. 2450 MetricTypeList 2451 The metric types associated with the routes not available through 2452 RERR_Gen. 2454 7.4.1. RERR Generation 2456 A Route Error message is generated when an AODVv2 router (also 2457 referred to as RERR_Gen) needs to report that a destination is not 2458 reachable. There are three events that cause this response: 2460 o When an IP packet that has been forwarded from another router, but 2461 there is no valid route in the Routing Information Base for its 2462 destination, the source of the packet needs to be informed that 2463 the route to the destination of the packet does not exist. The 2464 RERR generated MUST include PktSource set to the source address of 2465 the IP packet, and MUST contain only one unreachable address in 2466 the AddressList, i.e., the destination address of the IP packet. 2467 RERR_Gen MUST discard the IP packet that triggered generation of 2468 the RERR. The prefix length, sequence number and metric type 2469 SHOULD be included if known from an existing Invalid LocalRoute to 2470 the unreachable address. 2472 o When an RREP message cannot be forwarded because there is no valid 2473 LocalRoute to OrigPrefix, RREP_Gen needs to be informed that the 2474 route to OrigPrefix does not exist. The RERR generated MUST 2475 include PktSource set to the TargPrefix of the RREP, and MUST 2476 contain only one unreachable address in the AddressList, the 2477 OrigPrefix from the RREP. RERR_Gen MUST discard the RREP message 2478 that triggered generation of the RERR. The prefix length, 2479 sequence number and metric type SHOULD be included if known from 2480 an Invalid LocalRoute to the unreachable address. 2482 o When a link breaks, multiple LocalRoutes may become Invalid, and 2483 the RERR generated MAY contain multiple unreachable addresses. 2484 The RERR MUST include MetricTypeList. PktSource is omitted. All 2485 previously Active LocalRoutes that used the broken link MUST be 2486 reported. The AddressList, SeqNumList, and MetricTypeList will 2487 contain entries for each LocalRoute which has become Invalid. 2488 PrefixLengthList will be included if needed to report invalid 2489 routes to a non-default prefix. An RERR message is only sent if 2490 an Active LocalRoute becomes Invalid, though an AODVv2 router MAY 2491 also include Idle LocalRoutes that become Invalid if the 2492 configuration parameter ENABLE_IDLE_IN_RERR is set (see 2493 Section 12.3). 2495 The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been 2496 reached. The RERR also SHOULD NOT be generated if it is a duplicate, 2497 as determined by Section 6.9. 2499 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2500 from the address of one of its Router Clients, it forwards the ICMP 2501 packet in the same way as any other IP packet, and will not generate 2502 any RERR message based on the contents of the ICMP packet. 2504 To generate the RERR, the router follows this procedure: 2506 1. If necessary, include PktSource and set the value as given above 2508 2. For each LocalRoute that needs to be reported: 2510 * Insert LocalRoute.Address into the AddressList. 2512 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2513 and not equal to the address length. 2515 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2517 * Insert LocalRoute.MetricType into MetricTypeList. 2519 The AODVv2 message is used to create a corresponding [RFC5444] 2520 message (see Section 8). 2522 If the RERR is sent in response to an undeliverable IP packet or RREP 2523 message (i.e., if PktSource is included), the RERR SHOULD be sent 2524 unicast to the next hop on the route to PktSource. It MUST be sent 2525 over the same interface on which the undeliverable IP packet was 2526 received. If there is no route to PktSource, the RERR SHOULD be 2527 multicast to LL-MANET-Routers. If the RERR is sent in response to a 2528 broken link, i.e., PktSource is not included, the RERR is, by 2529 default, multicast to LL-MANET-Routers. 2531 Section 10 describes processing steps when the optional precursor 2532 lists feature is implemented. 2534 7.4.2. RERR Reception 2536 Upon receiving a Route Error, an AODVv2 router performs the following 2537 steps: 2539 1. Determine whether the message contains at least one unreachable 2540 address; if not, ignore this RERR for further processing. 2541 Otherwise continue as follows: 2543 2. For each address in the AddressList, check that: 2545 * The address is valid (routable and unicast). 2547 * The MetricType is supported and configured for use. 2549 * There is a LocalRoute with the same MetricType matching the 2550 address using longest prefix matching. 2552 * Either the LocalRoute's next hop is the sender of the RERR and 2553 the next hop interface is the interface on which the RERR was 2554 received, or PktSource is present in the RERR and is a Router 2555 Client address. 2557 * The unreachable address' sequence number is either unknown, or 2558 is no less than the LocalRoute's sequence number. 2560 If any of the above are false the address does not match a 2561 LocalRoute and MUST NOT be processed or regenerated in a RERR. 2563 If all of the above are true, the LocalRoute which matches the 2564 unreachable address MUST be marked as Invalid. Otherwise, 2565 regeneration of the RERR proceeds as follows. If the LocalRoute 2566 was previously Active, it MUST be reported in a regenerated RERR. 2567 If the LocalRoute was previously Idle, it MAY be reported in a 2568 regenerated RERR, if ENABLE_IDLE_IN_RERR is configured. The 2569 Local Route Set MUST be updated according to these rules: 2571 * If the LocalRoute's prefix length is the same as the 2572 unreachable address' prefix length, set LocalRoute.State to 2573 Invalid. 2575 * If the LocalRoute's prefix length is longer than the 2576 unreachable address' prefix length, the LocalRoute MUST be 2577 expunged from the Local Route Set, since it is a sub-route of 2578 the route which is reported to be Invalid. 2580 * If the prefix length is different, create a new LocalRoute 2581 with the unreachable address, and its prefix length and 2582 sequence number, and set LocalRoute.State to Invalid. These 2583 Invalid routes are retained to avoid processing stale 2584 messages. 2586 * Update the sequence number on the existing LocalRoute, if the 2587 reported sequence number is determined to be newer using the 2588 comparison method described in Section 4.4. 2590 3. If there are previously Active LocalRoutes that MUST be reported, 2591 regenerate the RERR as detailed in Section 7.4.3. 2593 7.4.3. RERR Regeneration 2595 The Route Error message SHOULD NOT be regenerated if 2596 CONTROL_TRAFFIC_LIMIT has been reached. 2598 The procedure for RERR regeneration is as follows: 2600 1. If PktSource was included in the received RERR, and PktSource is 2601 not a Router Client, copy it into the regenerated RERR 2603 2. For each LocalRoute that needs to be reported as identified in 2604 Section 7.4.1: 2606 * Insert LocalRoute.Address into the AddressList. 2608 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2609 and not equal to the address length. 2611 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2613 * Insert LocalRoute.MetricType into MetricTypeList. 2615 The AODVv2 message is used to create a corresponding [RFC5444] 2616 message (see Section 8). If the RERR contains PktSource, the 2617 regenerated RERR SHOULD be sent unicast to the next hop on the 2618 LocalRoute to PktSource. It MUST be sent over the same interface on 2619 which the undeliverable IP packet was received. If there is no route 2620 to PktSource, or PktSource is a Router Client, it SHOULD be multicast 2621 to LL-MANET-Routers. If the RERR is sent in response to a broken 2622 link, the RERR is, by default, multicast to LL-MANET-Routers. 2624 8. RFC 5444 Representation 2626 AODVv2 specifies that all control messages between routers MUST use 2627 the Generalized Mobile Ad Hoc Network Packet/Message Format 2628 [RFC5444], and therefore AODVv2's route messages comprise data which 2629 is mapped to message elements in [RFC5444]. 2631 [RFC5444] provides a multiplexed transport for multiple protocols. 2632 An [RFC5444] implementation MAY choose to optimize the content of 2633 certain elements during message creation to reduce control message 2634 overhead. 2636 A brief summary of the [RFC5444] format: 2638 1. A packet contains zero or more messages 2640 2. A message contains a Message Header, one Message TLV Block, zero 2641 or more Address Blocks, and one Address Block TLV Block per 2642 Address Block 2644 3. The Message TLV Block contains zero or more Message TLVs 2646 4. An Address Block TLV Block includes zero or more Address Block 2647 TLVs 2649 5. Each TLV value in an Address Block TLV Block can be associated 2650 with all of the addresses, or with a contiguous set of addresses, 2651 or with a single address in the Address Block 2653 AODVv2 does not require access to the [RFC5444] packet header. 2655 In the message header, AODVv2 uses , and 2656 . The field indicates the length 2657 of any addresses in the message, using := (address 2658 length in octets - 1), i.e. 3 for IPv4 and 15 for IPv6. 2660 The addresses in an Address Block MAY appear in any order, and values 2661 in a TLV in the Address Block TLV Block must be associated with the 2662 correct address in the Address Block by the [RFC5444] implementation. 2663 To indicate which value is associated with each address, the AODVv2 2664 message representation uses lists where the order of the addresses in 2665 the AODVv2 AddressList matches the order of values in other data 2666 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2667 [RFC5444] maps this information to Address Block TLVs associated with 2668 the relevant addresses in the Address Block. 2670 Each address included in the Address Block is identified as 2671 OrigPrefix, TargPrefix, PktSource, SeqNoRtr, or Unreachable Address 2672 by including an ADDRESS_TYPE TLV in the Address Block TLV Block. 2674 The following sections show how AODVv2 data is represented in 2675 [RFC5444] messages. In Section 13.3, AODVv2 defines several new 2676 TLVs. 2678 Where the extension type of a TLV is set to zero, this is the default 2679 [RFC5444] value and the extension type will not be included in the 2680 message. 2682 8.1. Route Request Message Representation 2684 8.1.1. Message Header 2686 +---------------+-----------------+---------------------------------+ 2687 | Data | Header Field | Value | 2688 +---------------+-----------------+---------------------------------+ 2689 | None | | RREQ | 2690 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2691 | | | of hops traversed so far by the | 2692 | | | message. | 2693 +---------------+-----------------+---------------------------------+ 2695 8.1.2. Message TLV Block 2697 AODVv2 does not define any Message TLVs for an RREQ message. 2699 8.1.3. Address Block 2701 An RREQ contains OrigPrefix and TargPrefix, and each of these 2702 addresses has an associated prefix length. If the prefix length has 2703 not been included in the AODVv2 message, it is equal to the address 2704 length in bits. 2706 +---------------------------+------------------------------+ 2707 | Data | Address Block | 2708 +---------------------------+------------------------------+ 2709 | OrigPrefix/OrigPrefixLen |
+ | 2710 | TargPrefix/TargPrefixLen |
+ | 2711 | SeqNoRtr/PrefixLen |
+ | 2712 +---------------------------+------------------------------+ 2714 8.1.4. Address Block TLV Block 2716 Address Block TLVs are always associated with one or more addresses 2717 in the Address Block. The following sections show the TLVs that 2718 apply to each address. 2720 8.1.4.1. Address Block TLVs for OrigPrefix 2722 +-------------+--------------+------------+-------------------------+ 2723 | Data | TLV Type | Extension | Value | 2724 | | | Type | | 2725 +-------------+--------------+------------+-------------------------+ 2726 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2727 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2728 | | | | RREQ_Gen, the router | 2729 | | | | which initiated route | 2730 | | | | discovery. | 2731 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2732 | /MetricType | | | route to OrigPrefix, | 2733 | | | | using MetricType. | 2734 +-------------+--------------+------------+-------------------------+ 2736 8.1.4.2. Address Block TLVs for TargPrefix 2738 +------------+--------------+-------------+-------------------------+ 2739 | Data | TLV Type | Extension | Value | 2740 | | | Type | | 2741 +------------+--------------+-------------+-------------------------+ 2742 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2743 | TargSeqNum | SEQ_NUM | 0 | The last known | 2744 | | | | TargSeqNum for | 2745 | | | | TargPrefix. | 2746 +------------+--------------+-------------+-------------------------+ 2748 8.2. Route Reply Message Representation 2749 8.2.1. Message Header 2751 +---------------+-----------------+---------------------------------+ 2752 | Data | Header Field | Value | 2753 +---------------+-----------------+---------------------------------+ 2754 | None | | RREP | 2755 | msg_hop_limit | | MAX_HOPCOUNT - msg_hop_limit | 2756 | | | from the corresponding RREQ, | 2757 | | | reduced by number of hops | 2758 | | | traversed so far by the | 2759 | | | message. | 2760 +---------------+-----------------+---------------------------------+ 2762 8.2.2. Message TLV Block 2764 AODVv2 does not define any Message TLVs for an RREP message. 2766 8.2.3. Address Block 2768 An RREP contains OrigPrefix and TargPrefix, and each of these 2769 addresses has an associated prefix length. If the prefix length has 2770 not been included in the AODVv2 message, it is equal to the address 2771 length in bits. 2773 +---------------------------+------------------------------+ 2774 | Data | Address Block | 2775 +---------------------------+------------------------------+ 2776 | OrigPrefix/OrigPrefixLen |
+ | 2777 | TargPrefix/TargPrefixLen |
+ | 2778 | SeqNoRtr/PrefixLen |
+ | 2779 +---------------------------+------------------------------+ 2781 8.2.4. Address Block TLV Block 2783 Address Block TLVs are always associated with one or more addresses 2784 in the Address Block. The following sections show the TLVs that 2785 apply to each address. 2787 8.2.4.1. Address Block TLVs for OrigPrefix 2789 +-------+---------------+-----------------+-------------+ 2790 | Data | TLV Type | Extension Type | Value | 2791 +-------+---------------+-----------------+-------------+ 2792 | None | ADDRESS_TYPE | 0 | ORIGPREFIX | 2793 +-------+---------------+-----------------+-------------+ 2795 8.2.4.2. Address Block TLVs for TargPrefix 2797 +--------------+--------------+------------+------------------------+ 2798 | Data | TLV Type | Extension | Value | 2799 | | | Type | | 2800 +--------------+--------------+------------+------------------------+ 2801 | None | ADDRESS_TYPE | 0 | TARGPREFIX | 2802 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2803 | | | | RREP_Gen, the router | 2804 | | | | which created the | 2805 | | | | RREP. | 2806 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2807 | /MetricType | | | route to TargPrefix, | 2808 | | | | using MetricType. | 2809 +--------------+--------------+------------+------------------------+ 2811 8.3. Route Reply Acknowledgement Message Representation 2813 8.3.1. Message Header 2815 +-------+---------------+-----------+ 2816 | Data | Header Field | Value | 2817 +-------+---------------+-----------+ 2818 | None | | RREP_Ack | 2819 +-------+---------------+-----------+ 2821 8.3.2. Message TLV Block 2823 AODVv2 defines an AckReq Message TLV, included when an 2824 acknowledgement of this message is required, in order to monitor 2825 adjacency, as described in Section 6.2. 2827 +---------+-----------+-----------------+--------+ 2828 | Data | TLV Type | Extension Type | Value | 2829 +---------+-----------+-----------------+--------+ 2830 | AckReq | ACK_REQ | 0 | None | 2831 +---------+-----------+-----------------+--------+ 2833 8.3.3. Address Block 2835 AODVv2 does not define an Address Block for an RREP_Ack message. 2837 8.3.4. Address Block TLV Block 2839 AODVv2 does not define any Address Block TLVs for an RREP_Ack 2840 message. 2842 8.4. Route Error Message Representation 2844 Route Error Messages MAY be split into multiple [RFC5444] messages 2845 when the desired contents would exceed the MTU. However, all of the 2846 resulting messages MUST have the same message header as described 2847 below. If PktSource is included in the AODVv2 message, it MUST be 2848 included in all of the resulting [RFC5444] messages. 2850 8.4.1. Message Header 2852 +-------+---------------+--------+ 2853 | Data | Header Field | Value | 2854 +-------+---------------+--------+ 2855 | None | | RERR | 2856 +-------+---------------+--------+ 2858 8.4.2. Message TLV Block 2860 AODVv2 does not define any Message TLVs for an RERR message. 2862 8.4.3. Address Block 2864 The Address Block in an RERR MAY contain PktSource, the source 2865 address of the IP packet triggering RERR generation, as detailed in 2866 Section 7.4. The prefix length associated with PktSource is equal to 2867 the address length in bits. 2869 Address Block always contains one address per route that is no longer 2870 valid, and each address has an associated prefix length. If a prefix 2871 length has not been included for this address, it is equal to the 2872 address length in bits. 2874 +------------------------------+------------------------------------+ 2875 | Data | Address Block | 2876 +------------------------------+------------------------------------+ 2877 | PktSource |
+ for | 2878 | | PktSource | 2879 | AddressList/PrefixLengthList |
+ for | 2880 | | each unreachable address in | 2881 | | AddressList | 2882 +------------------------------+------------------------------------+ 2884 8.4.4. Address Block TLV Block 2886 Address Block TLVs are always associated with one or more addresses 2887 in the Address Block. The following sections show the TLVs that 2888 apply to each type of address in the RERR. 2890 8.4.4.1. Address Block TLVs for PktSource 2892 +------------+---------------+-----------------+------------+ 2893 | Data | TLV Type | Extension Type | Value | 2894 +------------+---------------+-----------------+------------+ 2895 | PktSource | ADDRESS_TYPE | 0 | PKTSOURCE | 2896 +------------+---------------+-----------------+------------+ 2898 8.4.4.2. Address Block TLVs for Unreachable Addresses 2900 +----------------+--------------+------------+----------------------+ 2901 | Data | TLV Type | Extension | Value | 2902 | | | Type | | 2903 +----------------+--------------+------------+----------------------+ 2904 | None | ADDRESS_TYPE | 0 | UNREACHABLE | 2905 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2906 | | | | associated with | 2907 | | | | invalid route to the | 2908 | | | | unreachable address. | 2909 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2910 | | | | set to MetricType of | 2911 | | | | the route to the | 2912 | | | | unreachable address. | 2913 +----------------+--------------+------------+----------------------+ 2915 9. Simple External Network Attachment 2917 Figure 7 shows a stub (i.e., non-transit) network of AODVv2 routers 2918 which is attached to an external network (i.e., a network not using 2919 AODVv2) via a single External Network Access Router (ENAR). 2921 As in any externally-attached network, AODVv2 routers and Router 2922 Clients that wish to be reachable from the external network MUST have 2923 IP addresses within the ENAR's routable and topologically correct 2924 prefix (e.g., 191.0.2.0/24 in Figure 7). This AODVv2 network and 2925 networks attached to routers within it will be advertised to the 2926 external network using other routing protocols or procedures which 2927 are out of scope for this specification. 2929 /-------------------------\ 2930 / +----------------+ \ 2931 / | AODVv2 Router | \ 2932 | | 191.0.2.2/32 | | 2933 | +----------------+ | Routable 2934 | +-----+--------+ Prefix 2935 | | ENAR | /191.0.2.0/24 2936 | | AODVv2 Router| / 2937 | | 191.0.2.1 |/ /---------------\ 2938 | | serving net +------+ External \ 2939 | | 191.0.2.0/24 | \ Network / 2940 | +-----+--------+ \---------------/ 2941 | +----------------+ | 2942 | | AODVv2 Router | | 2943 | | 191.0.2.3/32 | | 2944 \ +----------------+ / 2945 \ / 2946 \-------------------------/ 2948 Figure 7: Simple External Network Attachment Example 2950 When an AODVv2 router within the AODVv2 MANET wants to discover a 2951 route toward an address on the external network, it uses the normal 2952 AODVv2 route discovery for that IP Destination Address. 2954 The ENAR MUST respond to RREQ on behalf of all external network 2955 destinations, that is, destinations which are not on the configured 2956 191.0.2.0 /24 network. The ENAR MUST NOT respond with a TargPrefix 2957 and TargPrefixLen which includes any of the networks configured as 2958 part of the AODVv2 network. Sending a Route Request for a gateway is 2959 not currently supported. 2961 If more than one gateway is configured to serve the same external 2962 network, each such gateway MUST configure that external network as a 2963 Router Client with its IP address as the value of SeqNoRtr for the 2964 RouterClient. AODVv2 messages SHOULD NOT be transmitted to routers 2965 in the External Network. 2967 RREQs for addresses inside the AODVv2 network, e.g. destinations on 2968 the configured 191.0.2.0/24 network, are handled using the standard 2969 processes described in Section 7. Note that AODVv2 does not 2970 currently support route discovery for prefixes that do not equal 2971 address length, but RREPs do advertise the prefix on which TargAddr 2972 resides. 2974 When an IP packet from an address on the external network destined 2975 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2976 not have a route toward that destination in its Routing Information 2977 Base, it will perform normal AODVv2 route discovery for that 2978 destination. 2980 Configuring the ENAR as a default router is outside the scope of this 2981 specification. 2983 10. Precursor Lists 2985 This section specifies an interoperable, optional enhancement to 2986 AODVv2 enabling more economical Route Error notifications. 2988 There can be several sources of traffic for a certain destination. 2989 Each source of traffic and each upstream router between the 2990 forwarding AODVv2 router and the traffic source is known as a 2991 "precursor" for the destination. For each destination, an AODVv2 2992 router MAY choose to keep track of precursors that have provided 2993 traffic for that destination. Route Error messages about that 2994 destination can then be sent unicast to these precursors instead of 2995 multicast to all AODVv2 routers. 2997 Since an RERR will be regenerated if it comes from a next hop on a 2998 valid LocalRoute, the RERR SHOULD ideally be sent backwards along the 2999 route that the source of the traffic uses, to ensure it is 3000 regenerated at each hop and reaches the traffic source. If the 3001 reverse path is unknown, the RERR SHOULD be sent toward the source 3002 along any available route. Therefore, the options for saving 3003 precursor information are as follows: 3005 o Save the next hop on an existing route to the IP packet's source 3006 address as the precursor. In this case, it is not guaranteed that 3007 an RERR that is sent will follow the reverse of the source's 3008 route. In rare situations, this may prevent the route from being 3009 invalidated at the source of the data traffic. 3011 o Save the IP packet's source address as the precursor. In this 3012 case, the RERR can be sent along any existing route to the source 3013 of the data traffic, and SHOULD include PktSource to ensure that 3014 the route will be invalidated at the source of the traffic, in 3015 case the RERR does not follow the reverse of the source's route. 3017 o By inspecting the MAC address of each forwarded IP packet, 3018 determine which router forwarded the packet, and save the router 3019 address as a precursor. This ensures that when an RERR is sent to 3020 the precursor router, the route will be invalidated at that 3021 router, and the RERR will be regenerated toward the source of the 3022 IP packet. 3024 During normal operation, each AODVv2 router maintaining precursor 3025 lists for a LocalRoute must update the precursor list whenever it 3026 uses this route to forward traffic to the destination. Precursors 3027 are classified as Active if traffic has recently been forwarded by 3028 the precursor. The precursor is marked with a timestamp to indicate 3029 the time it last forwarded traffic on this route. 3031 When an AODVv2 router detects that one or more LocalRoutes are 3032 broken, it MAY notify each Active precursor using a unicast Route 3033 Error message instead of creating multicast traffic. Unicast is 3034 applicable when there are few Active precursors compared to the 3035 number of neighboring AODVv2 routers. However, the default multicast 3036 behavior is still preferable when there are many precursors, since 3037 fewer message transmissions are required. 3039 When an AODVv2 router supporting precursor lists receives an RERR 3040 message, it SHOULD identify the list of its own affected Active 3041 precursors for the routes in the RERR, and choose to send a unicast 3042 RERR to those, rather than send a multicast RERR. 3044 When a LocalRoute is expunged, any precursor list associated with it 3045 MUST also be expunged. 3047 11. Application of RFC 7182 to AODVv2 3049 Implementations of AODVv2 MUST support ICV TLVs using type-extensions 3050 1 and 2, hash-function AES-CCM, and cryptographic function AES-CCM, 3051 both as defined in [RFC7251]. An ICV MUST be included with every 3052 message. The ICV value MAY be truncated as specified in [RFC7182]. 3054 Since the msg-hop-limit and PATH_METRIC values are mutable when 3055 included in AODVv2 messages, these values are set to zero before 3056 calculating an ICV. This means that these values are not protected 3057 end-to-end and are therefore susceptible to manipulation. This form 3058 of attack is described in Section 14.3.2. 3060 Implementations of AODVv2 MUST support a TIMESTAMP TLV using type- 3061 extension 0. The timestamp used is a sequence number, and therefore 3062 the length of the field matches the AODVv2 sequence 3063 number defined in Section 4.4. The TIMESTAMP TLV MUST be included in 3064 RREP_Ack and RERR messages. 3066 When more than one message is included in an RFC5444 packet, using a 3067 single ICV Packet TLV or single TIMESTAMP Packet TLV is more 3068 efficient than including ICV and TIMESTAMP Message TLVs in each 3069 message created. If the RFC5444 multiplexer is capable of adding the 3070 Packet TLVs, it SHOULD be instructed to include the Packet TLVs in 3071 packets containing AODVv2 messages. However, if the multiplexer is 3072 not capable of adding the Packet TLVs, the TLVs MUST be included as 3073 Message TLVs in each AODVv2 message in the packet. 3075 After message generation, but before transmission, the ICV and 3076 TIMESTAMP TLVs MUST be added according to each message type as 3077 detailed in the following sections. The following steps list the 3078 procedure to be performed: 3080 1. If the TIMESTAMP is to be included, depending on AODVv2 message 3081 type as specified below, add the TIMESTAMP TLV. 3083 * When a TIMESTAMP Packet TLV is being added, the Packet TLV 3084 Block size field MUST be updated. 3086 * When a TIMESTAMP Message TLV is being added, the Message TLV 3087 Block size field MUST be updated. 3089 2. The considerations in Section 8 and section 9 of [RFC7182] are 3090 followed, removing existing ICV TLVs and adjusting the size and 3091 flags fields as appropriate: 3093 * When an ICV Packet TLV is being added, existing ICV Packet 3094 TLVs MUST be removed and the Packet TLV Block size MUST be 3095 updated. If the Packet TLV Block now contains no TLVs, the 3096 phastlv bit in the field in the Packet Header MUST 3097 be cleared. 3099 * When an ICV Message TLV is being added, existing ICV Message 3100 TLVs are removed and the Message TLV Block Size MUST be 3101 updated. 3103 3. Mutable fields in the message must have their mutable values set 3104 to zero before calculating the ICV. 3106 * If the msg-hop-limit field is included in the [RFC5444] 3107 message header, msg-hop-limit MUST be set to zero before 3108 calculating the ICV. 3110 * If a PATH_METRIC TLV is included, any values present in the 3111 TLV MUST be set to zero before calculating the ICV value. 3113 4. Depending on the message type, the ICV is calculated over the 3114 appropriate fields (as specified in sections Section 11.1, 3115 Section 11.2, Section 11.3 and Section 11.4) to include the 3116 fields , , , and, if present, (in that order), followed by 3118 the entire packet or message. This value MAY be truncated (as 3119 specified in [RFC7182]). 3121 5. Add the ICV TLV, updating size fields as necessary. 3123 6. The changes made in Step 2 and Step 3 are reversed to re-add any 3124 existing ICV TLVs, re-adjust the relevant size and flags fields, 3125 and set the msg-hop-limit and PATH_METRIC TLV values. 3127 On message reception, and before message processing, verification of 3128 the received message MUST take place: 3130 1. The considerations in Section 8 and Section 9 of [RFC7182] are 3131 followed, removing existing ICV TLVs and adjusting the size and 3132 flags fields as appropriate. 3134 * When verifying the ICV value in an ICV Packet TLV, all ICV 3135 Packet TLVs present in the Packet TLV Block MUST be removed 3136 before calculating the ICV, and the Packet TLV Block size MUST 3137 be updated. If there are no remaining Packet TLVs, the Packet 3138 TLV Block MUST be removed and the phastlv bit in the field MUST be cleared. 3141 * When verifying the ICV value in an ICV Message TLV, all ICV 3142 Message TLVs present in the Message TLV Block MUST be removed 3143 before calculating the ICV, and the Message TLV Block size 3144 MUST be updated. 3146 2. Mutable fields in the message MUST have their mutable values set 3147 to zero before calculating the ICV. 3149 * If the msg-hop-limit field is included in the [RFC5444] 3150 message header, msg-hop-limit MUST be set to zero before 3151 calculating the ICV. 3153 * If a PATH_METRIC TLV is included, any values present in the 3154 TLV MUST be set to zero before calculating the ICV value. 3156 3. The ICV is calculated following the considerations in 3157 Section 12.2 of [RFC7182], to include the fields , 3158 , , and, if present, (in that order), followed by the entire packet or message. 3161 * If the received ICV value is truncated, the calculated ICV 3162 value MUST also be truncated (as specified in [RFC7182]), 3163 before comparing. 3165 * If the ICV value calculated from the received message or 3166 packet does not match the value of in the received 3167 message or packet, the validation fails and the AODVv2 message 3168 MUST be discarded and NOT processed or forwarded. 3170 * If the ICV values do match, the values set to zero before 3171 calculating the ICV are reset to the received values, and 3172 processing continues to Step 4. 3174 4. Verification of a received TIMESTAMP value MUST be performed. 3175 The procedure depends on message type as specified in the 3176 following sub sections. 3178 * If the TIMESTAMP value in the received message is not valid, 3179 the AODVv2 message MUST be discarded and NOT processed or 3180 forwarded. 3182 * If the TIMESTAMP value is valid, processing continues as 3183 defined in Section 7. 3185 11.1. RREQ Generation and Reception 3187 Since OrigPrefix is included in the RREQ, the ICV can be calculated 3188 and verified using the [RFC5444] contents.The ICV TLV has type 3189 extension := 1. Inclusion of an ICV TLV message integrity and 3190 endpoint authentication, because trusted routers MUST hold the shared 3191 key in order to calculate the ICV value, both to include when 3192 creating a message, and to validate the message by checking that the 3193 ICV is correct. 3195 Since RREQ_Gen's sequence number is incremented for each new RREQ, 3196 replay protection is already afforded and no extra TIMESTAMP TLV is 3197 required. 3199 After message generation and before message transmission: 3201 1. Add the ICV TLV as described above. 3203 On message reception and before message processing: 3205 1. Verify the received ICV value as described above. 3207 2. Verification of the sequence number is handled according to 3208 Section 7. 3210 11.2. RREP Generation and Reception 3212 Since TargPrefix is included in the RREP, the ICV can be calculated 3213 and verified using the [RFC5444] contents. The ICV TLV has type 3214 extension 1. Inclusion of an ICV provides message integrity and 3215 endpoint authentication, because trusted routers MUST hold a valid 3216 key in order to calculate the ICV value, both to include when 3217 creating a message, and to validate the message by checking that the 3218 ICV is correct. 3220 Since RREP_Gen's sequence number is incremented for each new RREP, 3221 replay protection is already afforded and no extra TIMESTAMP TLV is 3222 required. 3224 After message generation and before message transmission: 3226 1. Add the ICV TLV as described above. 3228 On message reception and before message processing: 3230 1. Verify the received ICV value as described above. 3232 2. Verification of the sequence number is handled according to 3233 Section 7. 3235 11.3. RREP_Ack Generation and Reception 3237 Since no sequence number is included in the RREP_Ack, a TIMESTAMP TLV 3238 MUST be included to protect against replay attacks. The value in the 3239 TIMESTAMP TLV is set as follows: 3241 o For RREP_Ack request, use Neighbor.AckSeqNum. 3243 o For RREP_Ack response, use the sequence number from the TIMESTAMP 3244 TLV in the received RREP_Ack request. 3246 Since no addresses are included in the RREP_Ack, and the receiver of 3247 the RREP_Ack uses the source IP address of a received RREP_Ack to 3248 identify the sender, the ICV MUST be calculated using the message 3249 contents and the IP source address. The ICV TLV has type extension 3250 := 2 in order to accomplish this. This provides message integrity 3251 and endpoint authentication, because trusted routers MUST hold the 3252 correct key in order to calculate the ICV value. 3254 After message generation and before message transmission: 3256 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3258 On message reception and before message processing: 3260 1. Verify the received ICV value as described above. 3262 2. Verify the received TIMESTAMP value by comparing the sequence 3263 number in the value field of the TIMESTAMP TLV as follows: 3265 * For a received RREP_Ack request, there is no need to verify 3266 the timestamp value. Proceed to message processing as defined 3267 in Section 7. 3269 * For a received RREP_Ack response, compare with the 3270 Neighbor.AckSeqNum of the Neighbor Set entry for sender of the 3271 RREP_Ack request. 3273 * If the sequence number does not match, the AODVv2 message MUST 3274 be discarded. Otherwise, Neighbor.AckSeqNum is incremented by 3275 1 and processing continues according to Section 7. 3277 11.4. RERR Generation and Reception 3279 Since the sender's sequence number is not contained in the RERR, a 3280 TIMESTAMP TLV MUST be included to protect against replay attacks. 3281 The value in the TIMESTAMP TLV is set by incrementing and using 3282 RERR_Gen's sequence number. 3284 Since the receiver of the RERR MUST use the source IP address of the 3285 RERR to identify the sender, the ICV MUST be calculated using the 3286 message contents and the IP source address. The ICV TLV has type 3287 extension := 2 in order to accomplish this. This provides message 3288 integrity and endpoint authentication, because trusted routers MUST 3289 hold the shared key in order to calculate the ICV value. 3291 After message generation and before message transmission: 3293 1. Add the TIMESTAMP TLV and ICV TLV as described above. 3295 On message reception and before message processing: 3297 1. Verify the received ICV value as described above. 3299 2. Verify the received TIMESTAMP value by comparing the sequence 3300 number in the value field of the TIMESTAMP TLV with the 3301 Neighbor.HeardRERRSeqNum. If the sequence number in the message 3302 is lower than the stored value, the AODVv2 message MUST be 3303 discarded. Otherwise, the Neighbor.HeardRERRSeqNum MUST be set 3304 to the received value and processing continues according to 3305 Section 7. 3307 12. Configuration 3309 AODVv2 uses various parameters which can be grouped into the 3310 following categories: 3312 o Timers 3313 o Protocol constants 3315 o Administrative parameters and controls 3317 This section show the parameters along with their definitions and 3318 default values (if any). 3320 Note that several fields have limited size (bits or bytes). These 3321 sizes and their encoding may place specific limitations on the values 3322 that can be set. 3324 12.1. Timers 3326 AODVv2 requires certain timing information to be associated with 3327 Local Route Set entries and message replies. The default values are 3328 as follows: 3330 +------------------------+----------------+ 3331 | Name | Default Value | 3332 +------------------------+----------------+ 3333 | ACTIVE_INTERVAL | 5 second | 3334 | MAX_IDLETIME | 200 seconds | 3335 | MAX_BLACKLIST_TIME | 200 seconds | 3336 | MAX_SEQNUM_LIFETIME | 300 seconds | 3337 | RERR_TIMEOUT | 3 seconds | 3338 | RteMsg_ENTRY_TIME | 12 seconds | 3339 | RREQ_WAIT_TIME | 2 seconds | 3340 | RREP_Ack_SENT_TIMEOUT | 1 second | 3341 | RREQ_HOLDDOWN_TIME | 10 seconds | 3342 +------------------------+----------------+ 3344 Table 2: Timing Parameter Values 3346 The above timing parameter values have worked well for small and 3347 medium well-connected networks with moderate topology changes. The 3348 timing parameters SHOULD be administratively configurable. Ideally, 3349 for networks with frequent topology changes the AODVv2 parameters 3350 SHOULD be adjusted using experimentally determined values or dynamic 3351 adaptation. For example, in networks with infrequent topology 3352 changes MAX_IDLETIME MAY be set to a much larger value. If the 3353 values were configured differently, the following consequences may be 3354 observed: 3356 o If MAX_SEQNUM_LIFETIME was configured differently across the 3357 network, and any of the routers lost their sequence number, this 3358 could result in their next route messages being classified as 3359 stale at any AODVv2 router using a greater value for 3360 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to 3361 the re-initializing router. 3363 o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will 3364 invalidate routes more quickly and free resources used to maintain 3365 them. This can affect bursty traffic flows which have quiet 3366 periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which 3367 has timed out due to perceived inactivity is not reported. When 3368 the bursty traffic resumes, it would cause a RERR to be generated, 3369 and the traffic itself would be dropped. This route would be 3370 removed from all upstream routers, even if those upstream routers 3371 had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route 3372 discovery would be required to re-establish the route, causing 3373 extra routing protocol traffic and disturbance to the bursty 3374 traffic. 3376 o Routers with lower values for MAX_BLACKLIST_TIME would allow 3377 neighboring routers to participate in route discovery sooner than 3378 routers with higher values. This could result in failed route 3379 discoveries if un-blacklisted links are still uni-directional. 3380 Since RREQs are retried, this would not affect success of route 3381 discovery unless this value was so small as to un-blacklist the 3382 router before the RREQ is retried. This value need not be 3383 consistent across the network since it is used for maintaining a 3384 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME; 3385 the default value is much larger. 3387 o Routers with lower values for RERR_TIMEOUT may create more RERR 3388 messages than routers with higher values. This value should be 3389 large enough that a RERR will reach all routers using the route 3390 reported within it before the timer expires, so that no further 3391 data traffic will arrive, and no duplicated RERR messages will be 3392 generated. 3394 o Routers with lower values for RteMsg_ENTRY_TIME may not consider 3395 received redundant multicast route messages as redundant, and may 3396 forward these messages unnecessarily. 3398 o Routers with lower values for RREQ_WAIT_TIME may send more 3399 frequent RREQ messages and wrongly determine that a route does not 3400 exist, if the delay in receiving an RREP is greater than this 3401 interval. 3403 o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly 3404 determine links to neighbors to be unidirectional if an RREP_Ack 3405 is delayed longer than this timeout. 3407 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed 3408 route discoveries sooner than routers with higher values. This 3409 may be an advantage if the network topology is frequently 3410 changing, or may unnecessarily cause more routing protocol 3411 traffic. 3413 MAX_SEQNUM_LIFETIME MUST be configured to have the same values for 3414 all AODVv2 routers in the network. 3416 12.2. Protocol Constants 3418 AODVv2 protocol constants typically do not require changes. The 3419 following table lists these constants, along with their values and a 3420 reference to the section describing their use. 3422 +------------------------+-------------+----------------------------+ 3423 | Name | Default | Description | 3424 +------------------------+-------------+----------------------------+ 3425 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 3426 | RREP_RETRIES | 2 | Section 7.2.1 | 3427 | MAX_METRIC[MetricType] | [see below] | Section 5 | 3428 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 3429 | MAX_HOPCOUNT | 20 | Limit to number of hops an | 3430 | | | RREQ or RREP message can | 3431 | | | traverse | 3432 | INFINITY_TIME | [see below] | Maximum expressible clock | 3433 | | | time (Section 6.7.2) | 3434 +------------------------+-------------+----------------------------+ 3436 Table 3: AODVv2 Constants 3438 MAX_HOPCOUNT cannot be larger than 255. 3440 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 3441 value of type MetricType. Field lengths associated with metric 3442 values are found in Section 13.4. 3444 These protocol constants MUST have the same values for all AODVv2 3445 routers in the ad hoc network. If the values were configured 3446 differently, the following consequences may be observed: 3448 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 3449 be more successful at finding routes, at the cost of additional 3450 control traffic. 3452 o RREP_RETRIES: Routers with lower values are more likely to 3453 blacklist neighbors when there is a temporary fluctuation in link 3454 quality. 3456 o MAX_METRIC[MetricType]: No interoperability problems due to 3457 variations on different routers, but routers with lower values may 3458 exhibit overly restrictive behavior during route comparisons. 3460 o MAX_HOPCOUNT: Routers with a value too small would not be able to 3461 discover routes to distant addresses. 3463 o INFINITY_TIME: No interoperability problems due to variations on 3464 different routers, but if a lower value is used, route state 3465 management may exhibit overly restrictive behavior. 3467 12.3. Local Settings 3469 The following table lists AODVv2 parameters which SHOULD be 3470 administratively configured for each router: 3472 +------------------------+---------------------------+--------------+ 3473 | Name | Default Value | Description | 3474 +------------------------+---------------------------+--------------+ 3475 | Router Client Set | | Section 4.2 | 3476 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 3477 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 3478 | CONTROL_TRAFFIC_LIMIT | [Adjust for 10% capacity] | Section 7 | 3479 +------------------------+---------------------------+--------------+ 3481 Table 4: Configuration for Local Settings 3483 12.4. Network-Wide Settings 3485 The following administrative controls MAY be used to change the 3486 operation of the network. The same settings SHOULD be used across 3487 the network. Inconsistent settings at different routers in the 3488 network will not result in protocol errors. 3490 +----------------------+-----------+----------------+ 3491 | Name | Default | Description | 3492 +----------------------+-----------+----------------+ 3493 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 3494 +----------------------+-----------+----------------+ 3496 Table 5: Configuration for Network-Wide Settings 3498 13. IANA Considerations 3500 This section specifies several [RFC5444] message types and address 3501 tlv-types required for AODVv2, as well as a new Code value for ICMP 3502 Destination Unreachable. 3504 13.1. RFC 5444 Message Type Allocation 3506 This specification defines four Message Types, to be allocated from 3507 the 0-223 range of the "Message Types" namespace defined in 3508 [RFC5444]. 3510 +-----------------------------------------+-----------+ 3511 | Name of Message | Type | 3512 +-----------------------------------------+-----------+ 3513 | Route Request (RREQ) | 10 (TBD) | 3514 | Route Reply (RREP) | 11 (TBD) | 3515 | Route Error (RERR) | 12 (TBD) | 3516 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 3517 +-----------------------------------------+-----------+ 3519 13.2. RFC 5444 Message TLV Types 3521 This specification defines one Message TLV Type, to be allocated from 3522 the Message-Type-specific "Message TLV Types" namespace defined in 3523 [RFC5444], as specified in Table 6. 3525 +------------------------+----------+---------------+---------------+ 3526 | Name of TLV | Type | Length | Reference | 3527 | | | (octets) | | 3528 +------------------------+----------+---------------+---------------+ 3529 | ACK_REQ | 128 | 0 | Section 6.2 | 3530 | | (TBD) | | | 3531 +------------------------+----------+---------------+---------------+ 3533 Table 6: AODVv2 Message TLV Types 3535 13.3. RFC 5444 Address Block TLV Type Allocation 3537 This specification defines three Address Block TLV Types, to be 3538 allocated from the Message-Type-specific "Address Block TLV Types" 3539 namespace defined in [RFC5444], as specified in Table 7. 3541 +------------------------+----------+---------------+---------------+ 3542 | Name of TLV | Type | Length | Reference | 3543 | | | (octets) | | 3544 +------------------------+----------+---------------+---------------+ 3545 | PATH_METRIC | 129 | depends on | Section 7 | 3546 | | (TBD) | MetricType | | 3547 | SEQ_NUM | 130 | 2 | Section 7 | 3548 | | (TBD) | | | 3549 | ADDRESS_TYPE | 131 | 1 | Section 8 | 3550 | | (TBD) | | | 3551 +------------------------+----------+---------------+---------------+ 3553 Table 7: AODVv2 Address Block TLV Types 3555 13.4. MetricType Allocation 3557 The metric types used by AODVv2 are identified according to Table 8. 3558 All implementations MUST use these values. 3560 +---------------------+----------+--------------------+ 3561 | Name of MetricType | Type | Metric Value Size | 3562 +---------------------+----------+--------------------+ 3563 | Unassigned | 0 | Undefined | 3564 | Hop Count | 1 | 1 octet | 3565 | Unallocated | 2 - 254 | TBD | 3566 | Reserved | 255 | Undefined | 3567 +---------------------+----------+--------------------+ 3569 Table 8: AODVv2 Metric Types 3571 13.5. ADDRESS_TYPE TLV Values 3573 These values are used in the [RFC5444] Address Type TLV discussed in 3574 Section 8. All implementations MUST use these values. 3576 +---------------+--------+ 3577 | Address Type | Value | 3578 +---------------+--------+ 3579 | ORIGPREFIX | 0 | 3580 | TARGPREFIX | 1 | 3581 | UNREACHABLE | 2 | 3582 | PKTSOURCE | 3 | 3583 | UNSPECIFIED | 255 | 3584 +---------------+--------+ 3586 Table 9: AODVv2 Address Types 3588 13.6. ICMPv6 Code Field for ICMP Destination Unreachable 3590 A new Code Value is defined for ICMP Destination Unreachable messages 3591 (see Section 7.1.2). 3593 +-----------------------+----------+ 3594 | Code Value | Value | 3595 +-----------------------+----------+ 3596 | Metric Type Mismatch | 8 (TBD) | 3597 +-----------------------+----------+ 3599 Table 10: AODVv2 ICMPv6 Code Field value 3601 14. Security Considerations 3603 This section describes various security considerations and potential 3604 avenues to secure AODVv2 routing. The main objective of the AODVv2 3605 protocol is for each router to communicate reachability information 3606 about addresses for which it is responsible, and for routes it has 3607 discovered from other AODVv2 routers. 3609 Networks using AODVv2 to maintain connectivity and establish routes 3610 on demand may be vulnerable to certain well-known types of threats, 3611 which will be detailed in this section. Some of the threats 3612 described can be mitigated or eliminated. Tools to do so will be 3613 described. 3615 With the exception of metric values, AODVv2 assures the integrity of 3616 all RteMsg data end-to-end though the use of ICVs (see 3617 Section 14.4.2. AODVv2 implementations support ICV and TIMESTAMP 3618 TLVs, unless the implementation is intended for an environment in 3619 which security is unnecessary; otherwise, AODVv2 deployments are 3620 configured to use these TLVs to secure messages. 3622 The on-demand nature of AODVv2 route discovery automatically reduces 3623 the vulnerability to route disruption. Since control traffic for 3624 updating route tables is diminished, there is less opportunity for 3625 attack and failure. 3627 14.1. Availability 3629 Threats to AODVv2 which reduce availability are considered below. 3631 14.1.1. Denial of Service 3633 Flooding attacks using RREQ amount to a (BLIND) denial of service for 3634 route discovery: By issuing RREQ messages for targets that don't 3635 exist, an attacker can flood the network, blocking resources and 3636 drowning out legitimate traffic. By triggering the generation of 3637 CONTROL_TRAFFIC_LIMIT amount of messages (for example by sending 3638 RREQs for many non-existent destinations), an attacker can prevent 3639 legitimate messages from being generated. The effect of this attack 3640 is dampened by the fact that duplicate RREQ messages are dropped 3641 (preventing the network from DDoSing itself). Processing 3642 requirements for AODVv2 messages are typically quite small, however 3643 AODVv2 routers receiving RREQs do allocate resources in the form of 3644 Neighbor Set, Local Route Set and Multicast Route Message Set 3645 entries. The attacker can maximize their impact on set growth by 3646 changing OrigPrefix or OrigPrefixLen for each RREQ. If a specific 3647 node is to be targeted, this attack may be carried out in a 3648 distributed fashion, either by compromising its direct neighbors or 3649 by specifying the target's address with TargPrefix and TargPrefixLen. 3650 Note that it might be more economical for the attacker to simply jam 3651 the medium; an attack which AODVv2 cannot defend itself against. 3653 Mitigation: 3655 o If AODVv2 routers always verify that the sender of the RERR 3656 message is trusted, this threat is reduced. Processing 3657 requirements would typically be dominated by calculations to 3658 verify integrity. This has the effect of reducing (but by no 3659 means eliminating) AODVv2's vulnerability to denial of service 3660 attacks. 3662 o Authentication of senders can prevent unauthenticated routers from 3663 launching a Denial of Service attack on another AODVv2 router. 3664 However, this does not protect the network if an attacker has 3665 access to an already authenticated router. 3667 14.1.2. Malicious RERR messages 3669 RERR messages are designed to cause removal of installed routes. A 3670 malicious node could send an RERR message with false information to 3671 attempt to get other routers to remove a route to one or more 3672 specific destinations, therefore disrupting traffic to the advertised 3673 destinations. 3675 Routes will be deleted if an RERR is received, withdrawing a route 3676 for which the sender is the receiver's next hop, if both of the 3677 following conditions are met: 3679 o the RERR includes the MetricType of the installed route, 3681 o the RERR includes either no sequence number for the route, or 3682 includes a greater sequence number than the sequence number stored 3683 with that route in the receiver's Local Route Set. 3685 Routes will also be deleted if a received RERR contains a PktSource 3686 address corresponding to a Router Client. 3688 The information necessary to construct a malicious RERR could be 3689 discovered by eavesdropping, either by listening to AODVv2 messages 3690 or by watching data packet flows. 3692 When the RERR is multicast, it can be received by many routers in the 3693 ad hoc network, and will be regenerated when processing results in an 3694 active route being removed. This threat could have serious impact on 3695 applications communicating by way of the sender of the RERR message. 3697 o The set of routers which use the malicious router as a next hop 3698 may be targeted with a malicious RERR with no PktSource address 3699 included, if the RERR contains routes for which the malicious 3700 router is a next hop from the receiving router. However, since 3701 the sender of the RERR message is either malicious or broken, it 3702 is better that it is not used as a next hop for these routes 3703 anyway. 3705 o A single router which does not use the malicious router as part of 3706 its route may be targeted with a malicious RERR with a PktSource 3707 address included. 3709 o Replayed RERR messages could be used to disrupt active routes. 3711 Mitigation: 3713 o Protection against eavesdropping of AODVv2 messages would mitigate 3714 this attack to some extent, but eavesdropping of data packets can 3715 also be used to deduce the information about which routes could be 3716 targeted. 3718 o Protection against a malicious router becoming part of a route 3719 will mitigate the attack where a set of routers are targeted. 3720 This will not protect against the attack if a PktSource address is 3721 included. 3723 o By only regenerating RERR messages where active routes are 3724 removed, the spread of the malicious RERR is limited. 3726 o Including sequence numbers in RERR messages offers protection 3727 against attacks using replays of these RERR messages. 3729 o If AODVv2 routers always verify that the sender of the RERR 3730 message is trusted, this threat is reduced. 3732 14.1.3. False Confirmation of Link Bidirectionality 3734 Links could be erroneously treated as bidirectional if malicious 3735 unsolicited or spoofed RREP messages were to be accepted. This would 3736 result in a route being installed which could not in fact be used to 3737 forward data to the destination, and may divert data packets away 3738 from the intended destination. 3740 There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which 3741 any malicious router could send an RREP in response, in order for the 3742 link to the malicious router to be deemed as bidirectional. 3744 Mitigation: 3746 o Ignoring unsolicited RREP and RREP_Ack messages partially 3747 mitigates against this threat. 3749 o If AODVv2 routers always verify that the sender of the RREP 3750 message is trusted, this threat is reduced. 3752 14.1.4. Message Deletion 3754 A malicious router could decide not to forward an RREQ or RREP or 3755 RERR message. Not forwarding a RERR or RREP message would disrupt 3756 route discovery. Not regenerating a RERR message would result in the 3757 source of data packets continuing to maintain and use the route, and 3758 further RERR messages being generated by the sender of the non- 3759 regenerated RERR. A malicious router could intentionally disrupt 3760 traffic flows by not allowing the source of data traffic to re- 3761 discover a new route when one breaks. 3763 Failing to send an RREP_Ack would also disrupt route establishment, 3764 by not allowing the reverse route to be validated. Return traffic 3765 which needs that route will prompt a new route discovery, wasting 3766 resources and incurring a slight delay but not disrupting the ability 3767 for applications to communicate. 3769 Mitigation: 3771 o None. Note that malicious router would have to wait for a route 3772 to break before it could perform this attack. 3774 14.2. Confidentiality 3776 Passive inspection (eavesdropping) of AODVv2 control messages could 3777 enable unauthorized devices to gain information about the network 3778 topology, since exchanging such information is the main purpose of 3779 AODVv2. 3781 Eavesdropping of data traffic could allow a malicious device to 3782 obtain information about how data traffic is being routed. With 3783 knowledge of source and destination addresses, malicious messages 3784 could be constructed to disrupt normal operation. 3786 14.3. Integrity of Routes 3788 Integrity of route information can be compromised in the following 3789 types of attack: 3791 14.3.1. Message Insertion 3793 Valid route set entries can be replaced or modified by maliciously 3794 constructed AODVv2 messages, destroying existing routes and the 3795 network's integrity. Any router may pose as another router by 3796 sending RREQ, RREP, RREP_Ack and RERR messages in its name. 3798 o Sending an RREQ message with false information can disrupt traffic 3799 to OrigPrefix, if the sequence number attached is not stale 3800 compared to any existing information about OrigPrefix. Since RREQ 3801 is multicast and likely to be received by all routers in the ad 3802 hoc network, this threat could have serious impact on applications 3803 communicating with OrigPrefix. 3805 o The actual threat to disrupt routes to OrigPrefix is reduced by 3806 the AODVv2 mechanism of marking RREQ-derived routes as 3807 "Unconfirmed" until the route to OrigAddr can be confirmed. 3809 o Sending an RREP message with false information can disrupt traffic 3810 to TargPrefix. Since RREP is unicast, and ignored if a 3811 corresponding RREQ was not recently sent, this threat is 3812 minimized, and is restricted to receivers along the path from 3813 OrigAddr to TargAddr. 3815 o Sending an RREP_Ack response message with false information can 3816 cause the route to an originator address to be erroneously 3817 accepted even though the route would contain a unidirectional link 3818 and thus not be suitable for most traffic. Since the RREP_Ack 3819 response is unicast, and ignored if an RREP_Ack was not sent 3820 recently to the sender of this RREP_Ack response, this threat is 3821 minimized and is strictly local to the RREP transmitter expecting 3822 the acknowledgement. Unsolicited RREP_Acks are ignored. 3824 o Sending an RERR message with false information is discussed in 3825 Section 14.1.2. 3827 Mitigation: 3829 o If AODVv2 routers always verify that the sender of a message is 3830 trusted, this threat is reduced. 3832 14.3.2. Message Modification - Man in the Middle 3834 Any AODVv2 router can forward messages with modified data. 3836 Mitigation: 3838 o If AODVv2 routers verify the integrity of AODVv2 messages, then 3839 the threat of disruption is minimized. A man in the middle with 3840 no knowledge of the key used to calculate an integrity check value 3841 may modify a message but the message will be rejected when it 3842 fails an integrity check. 3844 14.3.3. Replay Attacks 3846 Replaying of RREQ or RREP messages would be of less use to an 3847 attacker, since they would be dropped immediately due to their stale 3848 sequence number. RERR messages may or may not include sequence 3849 numbers and are therefore susceptible to replay attacks. RREP_Ack 3850 messages do not include sequence numbers and are therefore 3851 susceptible to replay attacks. 3853 Mitigation: 3855 o Use of timestamps or sequence numbers prevents replay attacks. 3857 14.4. Protection Mechanisms 3859 14.4.1. Confidentiality and Authentication 3861 Encryption MAY be used for AODVv2 messages. If the routers share a 3862 packet-level security association, the message data can be encrypted 3863 prior to message transmission. The establishment of such security 3864 associations is outside the scope of this specification. Encryption 3865 will not only protect against unauthorized devices obtaining 3866 information about network topology (eavesdropping) but will ensure 3867 that only trusted routers participate in routing operations. 3869 14.4.2. Message Integrity using ICVs 3871 Cryptographic Integrity Check Values (ICVs) can be used to ensure 3872 integrity of received messages, protecting against man in the middle 3873 attacks. Further, by using ICVs, only those routers with knowledge 3874 of a shared secret key are allowed to participate in routing 3875 information exchanges. [RFC7182] defines ICV TLVs for use with 3876 [RFC5444]. 3878 The data contained in AODVv2 routing protocol messages MUST be 3879 verified using Integrity Check Values, to avoid accepting tampered 3880 messages. 3882 14.4.3. Replay Protection using Timestamps 3884 [RFC7182] defines a TIMESTAMP TLV for use with [RFC5444] which can be 3885 used to prevent replay attacks when sequence numbers are not already 3886 included. 3888 The data contained in AODVv2 routing protocol messages can be 3889 protected with a TIMESTAMP value to ensure the protection against 3890 replaying of the message. Sequence numbers can be used in place of 3891 timestamps, since they are known to be strictly increasing. 3893 14.5. Key Management 3895 The method of distribution of shared secret keys is out of the scope 3896 of this protocol. Key management is not specified for the following 3897 reasons: 3899 Against [RFC4107], an analysis as to whether automated or manual key 3900 management should be used shows a compelling case for automated 3901 management. In particular: 3903 o a potentially large number of routers may have to be managed, 3904 belonging to several organisations, for example in vehicular 3905 applications. 3907 o a stream cipher is likely to be used, such as an AES variant. 3909 o long term session keys might be used by more than two parties, 3910 including multicast operations. AODVv2 makes extensive use of 3911 multicast. 3913 o there may be frequent turnover of devices. 3915 On reviewing the case for manual key management against the same 3916 document, it can be seen that manual management might be advantageous 3917 in environments with limited bandwidth or high round trip times. 3918 AODVv2 lends itself to sparse ad hoc networks where transmission 3919 conditions may indeed be limited, depending on the bearers selected 3920 for use. 3922 However, [RFC4107] assumes that the connectivity between endpoints is 3923 already available. In AODVv2, no route is available to a given 3924 destination until a router client requests that user traffic be 3925 transmitted. It is required to secure the signalling path of the 3926 routing protocol that will establish the path across which key 3927 exchange functions might subsequently be applied, which is clearly 3928 the reverse of the expected functionality. A different strategy is 3929 therefore required. 3931 There are two possible solutions. In each case, it is assumed that a 3932 defence in depth security posture is being adopted by the system 3933 integrator, such that each function in the network as a whole is 3934 appropriately secured or defended as necessary, and that there is not 3935 complete reliance on security mechanisms built in to AODVv2. Such 3936 additional mechanisms could include a suitable wireless device 3937 security technology, so that wireless devices are authenticated and 3938 secured by their peers prior to exchanging user data, which in this 3939 case would include AODVV2 signalling traffic as a payload, and 3940 mechanisms which verify the authenticity and/or integrity of 3941 application-layer user data transported once a route has been 3942 established. 3944 1. In the case that no AODVv2 routers have any detailed prior 3945 knowledge of any other AODVv2 router, but does have knowledge of 3946 the credentials of other organisations in which the router has 3947 been previously configured to trust, it is possible for an AODVv2 3948 router to send an initialisation vector as part of an exchange, 3949 which could be verified against such credentials. Such an 3950 exchange could make use of Identity-Based Signatures 3951 ([I-D.ietf-manet-ibs]), based on Elliptic Curve-Based 3952 Certificateless Signatures for Identity-Based Encryption 3953 [RFC6507], which eliminate the need for a handshake process to 3954 establish trust. 3956 2. If it is impossible to use Identity-Based Signatures, and the 3957 risk to the AODVv2 signalling traffic is considered to be low due 3958 to the use of security countermeasures elsewhere in the system, a 3959 simple pre-placed shared secret could be used between routers, 3960 which is used as-is or is used to generate some ephemeral secret 3961 based on another known variable, such as time of day if that is 3962 universally available at a level of accuracy sufficient to make 3963 such a system viable. 3965 15. Acknowledgments 3967 AODVv2 is a descendant of the design of previous MANET on-demand 3968 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3969 previous MANET on-demand protocols stem from research and 3970 implementation experiences. Thanks to Elizabeth Belding and Ian 3971 Chakeres for their long time authorship of AODV. Additional thanks 3972 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3973 Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, Sri Gundavelli, 3974 Ulrich Herberg, Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, 3975 Lars Kristensen, Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, 3976 Keyur Patel, Alexandru Petrescu, Alvaro Retana, Henning Rogge, 3977 Fransisco Ros, Pedro Ruiz, Christoph Sommer, Romain Thouvenin, Pascal 3978 Thubert, Richard Trefler, Jiazi Yi, Seung Yi, Behnaz Yousefi, and 3979 Cong Yuan, for their reviews of AODVv2 and DYMO, as well as numerous 3980 specification suggestions. 3982 16. References 3984 16.1. Normative References 3986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3987 Requirement Levels", BCP 14, RFC 2119, 3988 DOI 10.17487/RFC2119, March 1997, 3989 . 3991 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3992 Demand Distance Vector (AODV) Routing", RFC 3561, 3993 DOI 10.17487/RFC3561, July 2003, 3994 . 3996 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3997 Control Message Protocol (ICMPv6) for the Internet 3998 Protocol Version 6 (IPv6) Specification", STD 89, 3999 RFC 4443, DOI 10.17487/RFC4443, March 2006, 4000 . 4002 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 4003 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 4004 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 4005 . 4007 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 4008 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 4009 2009, . 4011 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 4012 Check Value and Timestamp TLV Definitions for Mobile Ad 4013 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 4014 April 2014, . 4016 16.2. Informative References 4018 [dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for 4019 Information technology--Telecommunications and information 4020 exchange between systems Local and metropolitan area 4021 networks--Specific requirements - Part 11: Wireless LAN 4022 Medium Access Control (MAC) and Physical Layer (PHY) 4023 Specification", March 2016. 4025 [I-D.ietf-manet-ibs] 4026 Dearlove, C., "Identity-Based Signatures for MANET Routing 4027 Protocols", draft-ietf-manet-ibs-05 (work in progress), 4028 March 2016. 4030 [I-D.ietf-roll-aodv-rpl] 4031 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 4032 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 4033 Networks (LLNs)", draft-ietf-roll-aodv-rpl-05 (work in 4034 progress), October 2018. 4036 [Koodli01] 4037 Koodli, R. and C. Perkins, "Fast handovers and context 4038 transfers in mobile networks", Proceedings of the ACM 4039 SIGCOMM Computer Communication Review 2001, Volume 31 4040 Issue 5, 37-47, October 2001. 4042 [Perkins94] 4043 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 4044 Sequenced Distance-Vector Routing (DSDV) for Mobile 4045 Computers", Proceedings of the ACM SIGCOMM '94 Conference 4046 on Communications Architectures, Protocols and 4047 Applications, London, UK, pp. 234-244, August 1994. 4049 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 4050 RFC 793, DOI 10.17487/RFC0793, September 1981, 4051 . 4053 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 4054 (MANET): Routing Protocol Performance Issues and 4055 Evaluation Considerations", RFC 2501, 4056 DOI 10.17487/RFC2501, January 1999, 4057 . 4059 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 4060 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 4061 June 2005, . 4063 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 4064 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 4065 . 4067 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 4068 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 4069 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 4070 . 4072 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 4073 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 4074 RFC 6130, DOI 10.17487/RFC6130, April 2011, 4075 . 4077 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 4078 Signatures for Identity-Based Encryption (ECCSI)", 4079 RFC 6507, DOI 10.17487/RFC6507, February 2012, 4080 . 4082 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 4083 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 4084 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 4085 . 4087 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 4088 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 4089 DOI 10.17487/RFC8175, June 2017, 4090 . 4092 Appendix A. Recent AODVv2 Draft Updates 4094 This section lists the changes between recent AODVv2 revisions 4095 ...-02.txt and ...-03.txt. 4097 o Changed name of Multicast Route Message table to be Multicast 4098 Message table (see Section 4.6, and Section 6.8). 4100 o Reorganized the Overview to include the list of differences 4101 between AODVv2 and RFC 3561, as well as an expanded description of 4102 Distance Vector protocol so that "Counting to Infinity" can be 4103 explained in somewhat more detail. 4105 o Improved consistency in terminology used (e.g., lost link versus 4106 broken link, metric type versus MetricType. Address List versus 4107 AddressList, IP.SourceAddress versus IP source address, 4108 participating mobile nodes versus participating mobile routers) 4110 o Added Figures to depict the operation of RREQ and RREP during 4111 Route Discovery. 4113 o Added text to Section 4.5 explaining how the LocalRoute.LastUsed 4114 field can be used to eliminate the need for maintaining a timer 4115 interrupt service. 4117 o Added terminology for Address Block 4119 o Eliminated "Interface Set" term 4121 o Removed "ENAR" from Terminology section since its use is local to 4122 Section 9 4124 o Eliminated instances of RFC 2119 mandate language that was 4125 inadvisedly used for various operations on internal data 4126 structures. 4128 o Clarified that a re-initializing router can still participate in 4129 creating routes as an intermediate router. 4131 o Improved language surrounding the use of external mechnanisms for 4132 establishing local connectivity. Added citations. 4134 o Strengthened mandate to remove a Neighbor Set entry, in the case 4135 that an external mechanism reports a link as broken 4137 o Eliminated ambiguous uses of the word "safe" by rewording to 4138 emphasize prevention of routing loops. 4140 o Updated and added bibliographic entries. 4142 Appendix B. Previous AODVv2 Draft Updates 4144 This section lists the changes between AODVv2 revisions ...-00.txt 4145 and ...-02.txt. 4147 o Changed notation for entries in Multicast Route Message table from 4148 RteMsg to McMsg {for Multicast Message} (see Table 1, Section 4.6, 4149 and Section 6.8). 4151 o Sharpened description of suppressing multicast messages to apply 4152 only to RREQs (see Section 6.8). 4154 o Supplied AES-CCM as the default choice for HASH_FUNCTION and 4155 CRYPTOGRAPHIC_FUNCTION (see Section 11). 4157 o Changed the names of the Neighbor.State to be capitalized: 4158 CONFIRMED, HEARD, and BLACKLISTED (see Section 4.3). 4160 o Created a new Code field value for ICMP Destination Unreachable 4161 messages (see Section 13.6). This allows the target of a RREQ to 4162 inform RREQ_Gen that the requested Metric Type is not available 4163 (see Section 7.1.2). This will prevent continued flooding for a 4164 Route Discovery that can never be satisfied. 4166 o Corrected various typos and made some stylistic improvements and 4167 clarifications. 4169 o Add RerrMsg as a Notational Convenience Table 1 4171 o Wordsmithing, reduce repeated text 4173 o Restore optional Precursor feature (see Section 10) 4175 o Correct misuse of RFC 2119 language 4177 o Revise the method by which a multi-hop path is deemed to be 4178 Confirmed 4180 o Remove technical specification details from definitions 4182 o Move security operational mandates from Security Considerations 4183 into a new section Section 11 4185 o Sharpen language related to assuring that routing must follow 4186 paths appropriate to the metric type for which the route was 4187 established (see Section 5). 4189 o Replace rambling paragraphs by itemized lists to improve 4190 readability 4192 o Allow use of MAC-layer hints about bidirectionality (see 4193 Section 6.2). 4195 o Define concepts of compatibility and comparability for Multicast 4196 Route Message entries (see Section 6.8). This is needed to enable 4197 proper comparisons in case multihomed nodes have route discoveries 4198 from multiple routers 4200 o Sharpen language related to multihoming 4202 o Suggest a proper default for CONTROL_TRAFFIC_LIMIT (see 4203 Section 12.3). 4205 o Sharpen Security Considerations Section according to suggestions 4206 from Bob Moskowitz 4208 Authors' Addresses 4210 Charles E. Perkins 4211 Futurewei Inc. 4212 2330 Central Expressway 4213 Santa Clara, CA 95050 4214 USA 4216 Phone: +1-408-330-4586 4217 Email: charliep@computer.org 4219 Stan Ratliff 4220 Idirect 4221 13861 Sunrise Valley Drive, Suite 300 4222 Herndon, VA 20171 4223 USA 4225 Email: ratliffstan@gmail.com 4227 John Dowdell 4228 Airbus Defence and Space 4229 Celtic Springs 4230 Newport, Wales NP10 8FZ 4231 United Kingdom 4233 Email: john.dowdell.ietf@gmail.com 4235 Lotte Steenbrink 4236 Freie Universitaet Berlin 4237 Kaiserswerther Str. 16-18 4238 D-14195 Berlin 4239 Germany 4241 Email: lotte.steenbrink@fu-berlin.de 4243 Victoria Pritchard 4244 Airbus Defence and Space 4245 Celtic Springs 4246 Newport, Wales NP10 8FZ 4247 United Kingdom 4249 Email: pritchardv0@gmail.com>