idnits 2.17.1 draft-ietf-manet-aodvv2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 (July 15, 2013) is 3935 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: 'MANETs' is mentioned on line 137, but not defined == Missing Reference: 'Addr' is mentioned on line 288, but not defined -- Looks like a reference, but probably isn't: '1' on line 1078 == Missing Reference: 'N' is mentioned on line 301, but not defined == Missing Reference: 'OrigNode' is mentioned on line 1362, but not defined == Missing Reference: 'OrigNdx' is mentioned on line 302, but not defined == Missing Reference: 'TargNode' is mentioned on line 1116, but not defined == Missing Reference: 'TargNdx' is mentioned on line 303, but not defined -- Looks like a reference, but probably isn't: '3' on line 690 == Missing Reference: 'MetricType' is mentioned on line 976, but not defined == Missing Reference: 'OrigNodeNdx' is mentioned on line 1228, but not defined == Missing Reference: 'TargNodeNdx' is mentioned on line 1226, but not defined == Missing Reference: 'TBD' is mentioned on line 1887, but not defined == Unused Reference: 'RFC1812' is defined on line 2079, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 2124, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2134, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 2149, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-09 == Outdated reference: A later version (-03) exists of draft-perkins-irrep-02 Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track S. Ratliff 5 Expires: January 16, 2014 Cisco 6 J. Dowdell 7 Cassidian 8 July 15, 2013 10 Dynamic MANET On-demand (AODVv2) Routing 11 draft-ietf-manet-aodvv2-02 13 Abstract 15 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing 16 protocol is intended for use by mobile routers in wireless, multihop 17 networks. AODVv2 determines unicast routes among AODVv2 routers 18 within the network in an on-demand fashion, offering on-demand 19 convergence in dynamic topologies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 16, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Notational Conventions . . . . . . . . . . . . . . . . . . . 7 58 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 59 5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 9 61 5.2. Bidirectional Connectivity and Blacklists . . . . . . . . 11 62 5.3. Router Clients and Client Networks . . . . . . . . . . . 11 63 5.4. AODVv2 Packet Header Fields and Information Elements . . 12 64 5.5. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 65 5.6. Enabling Alternate Metrics . . . . . . . . . . . . . . . 14 66 5.7. RREQ Table: Received RREQ Messages . . . . . . . . . . . 16 67 6. AODVv2 Operations on Route Table Entries . . . . . . . . . . 17 68 6.1. Evaluating Incoming Routing Information . . . . . . . . . 17 69 6.2. Applying Route Updates To Route Table Entries . . . . . . 18 70 6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . 19 71 7. Routing Messages RREQ and RREP (RteMsgs) . . . . . . . . . . 20 72 7.1. Route Discovery Retries and Buffering . . . . . . . . . . 20 73 7.2. RteMsg Structure . . . . . . . . . . . . . . . . . . . . 21 74 7.3. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 23 75 7.4. RREP Generation . . . . . . . . . . . . . . . . . . . . . 24 76 7.5. Handling a Received RteMsg . . . . . . . . . . . . . . . 25 77 7.5.1. Additional Handling for Incoming RREQ . . . . . . . . 26 78 7.5.2. Additional Handling for Incoming RREP . . . . . . . . 27 79 7.6. Suppressing Redundant RREQ messages . . . . . . . . . . . 27 80 8. Route Maintenance and RERR Messages . . . . . . . . . . . . . 27 81 8.1. Maintaining Route Lifetimes During Packet Forwarding . . 28 82 8.2. Active Next-hop Router 83 Adjacency Monitoring . . . . . . . . . . . . . . . . . . 28 84 8.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 28 85 8.3.1. Case 1: Undeliverable Packet . . . . . . . . . . . . 29 86 8.3.2. Case 2: Broken Link . . . . . . . . . . . . . . . . . 30 87 8.4. Receiving and Handling RERR Messages . . . . . . . . . . 31 88 9. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 32 89 10. Simple Internet Attachment . . . . . . . . . . . . . . . . . 32 90 11. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 33 91 12. AODVv2 Control Packet/Message Generation Limits . . . . . . . 33 92 13. Optional Features . . . . . . . . . . . . . . . . . . . . . . 33 93 13.1. Expanding Rings Multicast . . . . . . . . . . . . . . . 34 94 13.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . 34 95 13.3. Precursor Lists and Notifications . . . . . . . . . . . 34 96 13.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 34 97 13.3.2. Precursor Notification Details . . . . . . . . . . . 35 98 13.4. Multicast RREP Response to RREQ . . . . . . . . . . . . 35 99 13.5. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . 36 100 13.6. Message Aggregation . . . . . . . . . . . . . . . . . . 36 101 13.7. Added Routing Information in RteMsgs . . . . . . . . . . 36 102 13.7.1. Including Added Node Information . . . . . . . . . . 37 103 13.7.2. Handling Added Node Information . . . . . . . . . . 38 104 14. Administratively Configurable 105 Parameters and Timer Values . . . . . . . . . . . . . . . . . 39 106 14.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 39 107 14.2. Protocol constants . . . . . . . . . . . . . . . . . . . 40 108 14.3. Administrative (functional) controls . . . . . . . . . . 40 109 14.4. Other administrative parameters and lists . . . . . . . 40 110 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 111 15.1. AODVv2 Message Types Specification . . . . . . . . . . . 41 112 15.2. Message TLV Type Specification . . . . . . . . . . . . . 41 113 15.3. Address Block TLV Specification . . . . . . . . . . . . 42 114 15.4. Metric Type Number Allocation . . . . . . . . . . . . . 42 115 16. Security Considerations . . . . . . . . . . . . . . . . . . . 42 116 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 117 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 118 18.1. Normative References . . . . . . . . . . . . . . . . . . 45 119 18.2. Informative References . . . . . . . . . . . . . . . . . 45 120 Appendix A. Example RFC 5444-compliant packet formats . . . . . 46 121 A.1. RREQ Message Format . . . . . . . . . . . . . . . . . . . 47 122 A.2. RREP Message Format . . . . . . . . . . . . . . . . . . . 49 123 A.3. RERR Message Format . . . . . . . . . . . . . . . . . . . 51 124 A.4. RREP_ACK Message Format . . . . . . . . . . . . . . . . . 52 125 Appendix B. Changes since revision ...-25.txt . . . . . . . . . 52 126 Appendix C. Changes since revision ...-24.txt . . . . . . . . . 53 127 Appendix D. Changes between revisions ...-21.txt and ...-24.txt 53 128 Appendix E. Shifting Network Prefix Advertisement Between AODVv2 129 Routers . . . . . . . . . . . . . . . . . . . . . . 55 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 132 1. Overview 134 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing 135 protocol [formerly named DYMO] enables on-demand, multihop unicast 136 routing among AODVv2 routers in mobile ad hod networks 137 [MANETs][RFC2501]. The basic operations of the AODVv2 protocol are 138 route discovery and route maintenance. Route discovery is performed 139 when an AODVv2 router must transmit a packet towards a destination 140 for which it does not have a route. Route maintenance is performed 141 to avoid prematurely expunging routes from the route table, and to 142 avoid dropping packets when an active route breaks. 144 During route discovery, the originating AODVv2 router (RREQ_Gen) 145 multicasts a Route Request message (RREQ) to find a route toward some 146 target destination. Using a hop-by-hop retransmission algorithm, 147 each AODVv2 router receiving the RREQ message records a route toward 148 the originator. When the target's AODVv2 router (RREP_Gen) receives 149 the RREQ, it records a route toward RREQ_Gen and generates a Route 150 Reply (RREP) unicast toward RREQ_Gen. Each AODVv2 router that 151 receives the RREP stores a route toward the target, and again 152 unicasts the RREP toward the originator. When RREQ_Gen receives the 153 RREP, routes have then been established between RREQ_Gen (the 154 originating AODVv2 router) and RREP_Gen (the target's AODVv2 router) 155 in both directions. 157 Route maintenance consists of two operations. In order to maintain 158 active routes, AODVv2 routers extend route lifetimes upon 159 successfully forwarding a packet. When a data packet is received to 160 be forwarded downstream but there is no valid route for the 161 destination, then the AODVv2 router of the source of the packet is 162 notified via a Route Error (RERR) message. Each upstream router that 163 receives the RERR marks the route as broken. Before such an upstream 164 AODVv2 router could forward a packet to the same destination, it 165 would have to perform route discovery again for that destination. 167 AODVv2 uses sequence numbers to assure loop freedom [Perkins99], 168 similarly to AODV. Sequence numbers enable AODVv2 routers to 169 determine the temporal order of AODVv2 route discovery messages, 170 thereby avoiding use of stale routing information. Unlike AODV, 171 AODVv2 uses RFC 5444 message and TLV formats. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in 178 [RFC2119]. 180 This document also uses some terminology from [RFC5444]. 182 This document defines the following terminology: 184 Adjacency 185 A bi-directional relationship between neighboring AODVv2 routers 186 for the purpose of exchanging routing information. Not every pair 187 of neighboring routers will necessarily form an adjacency. 188 Neighboring routers may form an adjacency based on various 189 information or other protocols; for example, exchange of AODVv2 190 routing messages, other protocols (e.g. NDP [RFC4861] or NHDP 191 [RFC6130]), or manual configuration. Loss of a routing adjacency 192 may also be indicated by similar information; monitoring of 193 adjacencies where packets are being forwarded is required (see 194 Section 8.2). 195 AODVv2 Router 196 An IP addressable device in the ad-hoc network that performs the 197 AODVv2 protocol operations specified in this document. 198 AODVv2 Sequence Number (SeqNum) 199 Same as Sequence Number. 200 Current_Time 201 The current time as maintained by the AODVv2 router. 202 disregard 203 Ignore for further processing (see Section 5.4), and discard 204 unless it is required to keep the message in the packet for 205 purposes of authentication. 206 Handling Router (HandlingRtr) 207 HandlingRtr denotes the AODVv2 router receiving and handling an 208 AODVv2 message. 209 Incoming Link 210 A link over which an AODVv2 router has received a message from an 211 adjacent router. 212 MANET 213 A Mobile Ad Hoc Network as defined in [RFC2501]. 214 node 215 An IP addressable device in the ad-hoc network. A node may be an 216 AODVv2 router, or it may be a device in the network that does not 217 perform any AODVv2 protocol operations. All nodes in this 218 document are either AODVv2 Routers or else Router Clients. 219 Originating Node (OrigNode) 220 The Originating Node is the node that launched the application 221 requiring communication with the Target Node. If OrigNode is not 222 itself an AODVv2 router, its AODVv2 router (RREQ_Gen) has the 223 responsibility to generate a AODVv2 RREQ message on behalf of 224 OrigNode when necessary to discover a route. 225 reactive 226 A protocol operation is said to be "reactive" if it is performed 227 only in reaction to specific events. As used in this document, 228 "reactive" is essentially synonymous with "on-demand". 229 Routable Unicast IP Address 230 A routable unicast IP address is a unicast IP address that when 231 put into the IP.DestinationAddress field is scoped sufficiently to 232 be forwarded by a router. Globally-scoped unicast IP addresses 233 and Unique Local Addresses (ULAs) [RFC6549] are examples of 234 routable unicast IP addresses. 235 Route Error (RERR) 236 A RERR message is used to indicate that an AODVv2 router does not 237 have a route toward one or more particular destinations. 238 Route Reply (RREP) 239 A RREP message is used to establish a route between the RREQ 240 TargetNode and OrigNode, at all the AODVv2 routers between them. 241 Route Request (RREQ) 242 An AODVv2 router uses a RREQ message to discover a valid route to 243 a particular destination address, called the TargetNode. An 244 AODVv2 router processing a RREQ receives routing information for 245 the RREQ OrigNode. 246 Router Client 247 An AODVv2 router may be configured with a list of other IP 248 addresses and networks which correspond to other non-router nodes 249 which require the services of the AODVv2 router for route 250 discovery and maintenance. An AODVv2 router is always its own 251 client, so that the list of client IP addresses is never empty. 252 RREP Generating Router (RREP_Gen) 253 The RREP Generating Router is the AODVv2 router that serves 254 TargNode. RREP_Gen generates the RREP message to advertise a 255 route for TargNode. 256 RREQ Generating Router (RREQ_Gen) 257 The RREQ Generating Router is the AODVv2 router that serves 258 OrigNode. RREQ_Gen generates the RREQ message to discover a route 259 for TargNode. 260 Sequence Number (SeqNum) 261 AODVv2 mandates that each AODVv2 router maintain an unsigned 262 integer known as the router's "Sequence Number". The Sequence 263 Number guarantees the temporal order of routing information to 264 maintain loop-free routes, and fulfills the same role as the 265 "Destination Sequence Number" of DSDV, and as the AODV Sequence 266 Number in RFC 3561[RFC3561]. The value zero (0) is reserved to 267 indicate that the Sequence Number for an address is unknown. 268 Target Node (TargNode) 269 The Target Node denotes the node for which a route is needed. 270 Type-Length-Value structure (TLV) 271 A generic way to represent information as specified in [RFC5444]. 272 Unreachable Node (UnreachableNode) 273 An UnreachableNode is a node for which a forwarding route is 274 unknown. 275 valid route 276 A route that can be used for forwarding; in other words a route 277 that is not Broken or Expired. 279 3. Notational Conventions 281 This document uses the conventions found in Table 1 to describe 282 information in the fields from [RFC5444]. 284 +---------------------+------------------------------------------+ 285 | Notation | Information Location and/or Meaning | 286 +---------------------+------------------------------------------+ 287 | Route[Addr] | A route table entry towards Addr | 288 | Route[Addr].{field} | A field in a route table entry | 289 | -- | -- | 290 | | RFC 5444 Message Header | 291 | | RFC 5444 Message Header | 292 | AddrBlk | an RFC 5444 Address TLV Block | 293 | AddrBlk[1] | The first address slot in AddrBlk | 294 | AddrBlk[N] | The Nth address slot in AddrBlk | 295 | OrigNdx | The index of OrigNode within the AddrBlk | 296 | TargNdx | The index of TargNode within the AddrBlk | 297 | AddrBlk[OrigNode] | AddrBlk[OrigNdx] | 298 | AddrBlk[TargNode] | AddrBlk[TargNdx] | 299 | AddrTLV | an RFC 5444 Address Block TLV | 300 | AddrTLV[1] | the first item in AddrTLV | 301 | AddrTLV[N] | the Nth item in AddrTLV | 302 | AddrTLV[OrigNode] | AddrTLV[OrigNdx] | 303 | AddrTLV[TargNode] | AddrTLV[TargNdx] | 304 | MetricTLV | Metric AddrTLV for AddrBlk | 305 | SeqNumTLV | Sequence Number AddrTLV for AddrBlk | 306 | OrigSeqNumTLV | Originating Node Sequence Number AddrTLV | 307 | TargSeqNumTLV | Target Node Sequence Number AddrTLV | 308 | -- | -- | 309 | OrigNode | Originating Node | 310 | RREQ_Gen | AODVv2 router originating an RREQ | 311 | RREP_Gen | AODVv2 router responding to an RREQ | 312 | RteMsg | Either RREQ or RREP | 313 | RteMsg.{field} | Field in RREQ or RREP | 314 | HandlingRtr | Handling Router | 315 | TargNode | Target Node | 316 | UnreachableNode | Unreachable Node | 317 +---------------------+------------------------------------------+ 319 Table 1 321 4. Applicability Statement 323 The AODVv2 routing protocol is designed for stub (i.e., non-transit) 324 or disconnected (i.e., from the Internet) mobile ad hoc networks 325 (MANETs). AODVv2 handles a wide variety of mobility patterns by 326 determining routes on-demand. AODVv2 also handles a wide variety of 327 traffic patterns. In networks with a large number of routers, AODVv2 328 is best suited for relatively sparse traffic scenarios where any 329 particular router forwards packets to only a small percentage of the 330 AODVv2 routers in the network, due to the on-demand nature of route 331 discovery and route maintenance. AODVv2 supports routers with 332 multiple interfaces, as long as each interface has its own (unicast 333 routeable) IP address; the set of all network interfaces supporting 334 AODVv2 is administratively configured in a list (namely, 335 AODVv2_INTERFACES). 337 Although AODVv2 is closely related to AODV [RFC3561], and has some of 338 the features of DSR [RFC4728], AODVv2 is not interoperable with 339 either of those other two protocols. 341 AODVv2 is applicable to memory constrained devices, since little 342 routing state is maintained in each AODVv2 router. Only routing 343 information related to routes between active sources and destinations 344 is maintained, in contrast to proactive routing protocols that 345 require routing information to all routers within the MANET be 346 maintained. 348 In addition to routing for its own local applications, each AODVv2 349 router can also route on behalf of other non-routing nodes (i.e., 350 "hosts", or, in this document, "clients"), reachable via those 351 interfaces. Each AODVv2 router, if serving router clients other than 352 itself, is configured with information about the IP addresses of its 353 clients. No AODVv2 router is required to have information about the 354 relationship between any other AODVv2 router and its router clients 355 (see Section 5.3). 357 The coordination among multiple AODVv2 routers to distribute routing 358 information correctly for a shared address (i.e. an address that is 359 advertised and can be reached via multiple AODVv2 routers) is not 360 described in this document. The AODVv2 router operation of shifting 361 responsibility for a routing client from one AODVv2 router to another 362 is mentioned in Appendix E. Address assignment procedures are 363 entirely out of scope for AODVv2. Any such node which is not itself 364 an AODVv2 router SHOULD NOT be served by more than one AODVv2 router 365 at any one time. 367 Multi-homing is difficult unless the sequence number is expanded to 368 include the AODVv2 router's IP address as well as SeqNum. Otherwise, 369 comparing sequence numbers would not work to evaluate freshness. 370 Even when the IP address is included, there isn't a good way to 371 compare sequence numbers from different IP addresses, but at least a 372 handling node can determine whether the two given sequence numbers 373 are comparable. If the route table can store multiple routes for the 374 same destination, then multi-homing can work with sequence numbers 375 augmented by IP addresses. 377 AODVv2 routers perform route discovery to find a route toward a 378 particular destination. Therefore, AODVv2 routers MUST must be 379 configured to respond to RREQs for a certain set of addresses. When 380 AODVv2 is the only protocol interacting with the forwarding table, 381 AODVv2 MAY be configured to perform route discovery for all unknown 382 unicast destinations. 384 AODVv2 only supports bidirectional links. In the case of possible 385 unidirectional links, either blacklists (see Section 5.2) or other 386 means (e.g. adjacency establishment with only neighboring routers 387 that have bidirectional communication as indicated by NHDP [RFC6130]) 388 of assuring and monitoring bi-directionality are recommended. 389 Otherwise, persistent packet loss or persistent protocol failures 390 could occur. The cost of bidirectional link L (denoted Cost(L)) may 391 depend upon the direction across the link for which the cost is 392 measured. 394 The routing algorithm in AODVv2 may be operated at layers other than 395 the network layer, using layer-appropriate addresses. The routing 396 algorithm makes of some persistent state; if there is no persistent 397 storage available for this state, recovery can impose a performance 398 penalty (e.g., in case of AODVv2 router reboots). 400 5. Data Structures 402 5.1. Route Table Entry 404 The route table entry is a conceptual data structure. 405 Implementations may use any internal representation so long as it 406 provides access to the information specified below. 408 Conceptually, a route table entry has the following fields: 410 Route.Address 411 The (host or network) destination address of the node(s) 412 associated with the routing table entry 413 Route.PrefixLength 414 The length of the netmask/prefix. If the value of the 415 Route.PrefixLength is less than the length of addresses in the 416 address family used by the AODVv2 routers, the associated address 417 is a routing prefix, rather than a host address. A PrefixLength 418 is stored for every route in the route table. 419 Route.SeqNum 420 The Sequence Number associated with a route table entry 421 Route.NextHopAddress 422 An IP address of the adjacent AODVv2 router on the path toward the 423 Route.Address 424 Route.NextHopInterface 425 The interface used to send packets toward the Route.Address 426 Route.LastUsed 427 The time that this route was last used 428 Route.ExpirationTime 429 The time at which this route must expire 430 Route.Broken 431 A flag indicating whether this Route is broken. This flag is set 432 to true if the next-hop becomes unreachable or in response to 433 processing to a RERR (see Section 8.4) 434 Route.MetricType 435 The type of the metric for the route towards Route.Address 436 Route.Metric 437 The cost of the route towards Route.Address 439 A route table entry (i.e., a route) may be in one of the following 440 states: 442 Active 443 An Active route is in current use for forwarding packets 444 Idle 445 An Idle route can be used for forwarding packets, even though it 446 is not in current use 447 Expired 448 After a route has been idle for too long, it expires, and may no 449 longer be used for forwarding packets 450 Broken 451 A route marked as Broken cannot be used for forwarding packets but 452 still has valid destination sequence number information. 453 Timed 454 The expiration of a Timed route is controlled by the 455 Route.ExpirationTime time of the route table entry (instead of 456 MAX_IDLETIME). Until that time, a Timed route can be used for 457 forwarding packets. Afterwards, the route must be Expired (or 458 expunged). 460 The route's state determines the operations that can be performed on 461 the route table entry. During use, an Active route is maintained 462 continuously by AODVv2 and is considered to remain active as long as 463 it is used at least once during every ACTIVE_INTERVAL. When a route 464 is no longer Active, it becomes an Idle route. After an idle route 465 remains Idle for MAX_IDLETIME, it becomes an Expired route. An 466 Expired route is not used for forwarding, but the sequence number 467 information can be maintained until the destination sequence number 468 has had no updates for MAX_SEQNUM_LIFETIME; after that time, old 469 sequence number information is considered no longer valuable and the 470 Expired route MUST BE expunged. 472 MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 473 router MUST NOT transmit any routing messages. Thus, if all other 474 AODVv2 routers expunge routes to the rebooted router after that time 475 interval, the rebooted AODVv2 router's sequence number will not be 476 considered stale by any other AODVv2 router in the MANET. 478 When the link to a route's next hop is broken, the route is marked as 479 being Broken, and the route may no longer be used. 481 5.2. Bidirectional Connectivity and Blacklists 483 To avoid repeated failure of Route Discovery, an AODVv2 router 484 (HandlingRtr) handling a RREP message MAY attempt to verify 485 connectivity to the next upstream router towards AODVv2 router 486 originating an RREQ message, by including the Acknowledgement Request 487 (AckReq) message TLV (see Section 15.2) in the RREP. Any unicast 488 packet will satisfy the Acknowledgement Request, for example an ICMP 489 REPLY message. If the verification is not received within 490 UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD put the upstream 491 neighbor in the blacklist. RREQs received from a blacklisted node 492 SHOULD NOT be retransmitted by HandlingRtr. However, the upstream 493 neighbor SHOULD NOT be permanently blacklisted; after a certain time 494 (MAX_BLACKLIST_TIME), it SHOULD once again be considered as a viable 495 upstream neighbor for route discovery operations. 497 For this purpose, a list of blacklisted nodes along with their time 498 of removal SHOULD be maintained: 500 Blacklist.Node 501 The IP address of the node that did not verify bidirectional 502 connectivity. 503 Blacklist.RemoveTime 504 The time at which Blacklist.Node will be removed from the 505 blacklist. 507 5.3. Router Clients and Client Networks 508 An AODVv2 router may offer routing services to other nodes that are 509 not AODVv2 routers. AODVv2 defines the Sequence Number to be the 510 same for the AODVv2 router and each of its clients. 512 For this purpose, CLIENT_ADDRESSES must be configured on each AODVv2 513 router with the following information: 515 Client IP address 516 The IP address of the node that requires routing service from the 517 AODVv2 router. 518 Client Prefix Length 519 The length of the routing prefix associated with the client IP 520 address. 522 If the Client Prefix Length is not the full length of the Client IP 523 address, then the prefix defines a Client Network. If an AODVv2 524 router is configured to serve a Client Network, then the AODVv2 525 router MUST serve every node that has an address within the range 526 defined by the routing prefix of the Client Network. The list of 527 Routing Clients for an AODVv2 router is never empty, since an AODVv2 528 router is always its own client as well. 530 5.4. AODVv2 Packet Header Fields and Information Elements 532 In its default mode of operation, AODVv2 transmits UDP packets using 533 the parameters for port number and IP protocol specified in [RFC5498] 534 to carry protocol packets. By default, AODVv2 packets are sent with 535 the IP destination address set to the link-local multicast address 536 LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, 537 all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to 538 receiving AODVv2 messages. In order to reduce multicast overhead, 539 retransmitting multicast packets in MANETs SHOULD be done according 540 to methods specified in [RFC6621]. AODVv2 does not specify which 541 method should be used to restrict the set of AODVv2 routers that have 542 the responsibility to retransmit multicast packets. Note that 543 multicast packets MAY be sent via unicast. For example, this may 544 occur for certain link-types (non-broadcast media), for manually 545 configured router adjacencies, or in order to improve robustness. 547 The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 548 messages is set to 255. If a packet is received with a value other 549 than 255, any AODVv2 message contained in the packet MUST be 550 disregarded by AODVv2. This mechanism, known as "The Generalized TTL 551 Security Mechanism" (GTSM) [RFC5082] helps to assure that packets 552 have not traversed any intermediate routers. 554 IP packets containing AODVv2 protocol messages SHOULD be given 555 priority queuing and channel access. 557 AODVv2 messages are transmitted in packets that conform to the packet 558 and message format specified in [RFC5444]. Here is a brief summary 559 of the format. 561 A packet formatted according to RFC 5444 contains zero or more 562 messages. 563 A message contains a message header, message TLV block, and zero 564 or more address blocks. 565 Each address block may also have an associated TLV block; this TLV 566 block may encode multiple TLVs. According to RFC 5444, each such 567 TLV may itself include an array of values. 569 If a packet contains only a single AODVv2 message and no packet TLVs, 570 it need only include a minimal Packet-Header [RFC5444]. The length 571 of an address (32 bits for IPv4 and 128 bits for IPv6) inside an 572 AODVv2 message is indicated by the msg-addr-length (MAL) in the msg- 573 header, as specified in [RFC5444]. 575 When multiple messages are aggregated into a single packet according 576 to RFC 5444 formatting, and the aggregation of messages is also 577 authenticated (e.g., with IPsec), and the IP destination is multiple 578 hops away, it becomes infeasible to delete individual messages. In 579 such cases, instead of deleting individual messages, they are 580 maintained in the aggregation of messages, but simply ignored for 581 further processing. In such cases where individual messages cannot 582 be deleted, in this document "disregarded" means "ignored". 583 Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted 584 from the aggregated messages in the RFC 5444 packet. 586 5.5. Sequence Numbers 588 Sequence Numbers allow AODVv2 routers to evaluate the freshness of 589 routing information. Proper maintenance of sequence numbers assures 590 that the destination sequence number value stored by intermediate 591 AODVv2 routers is monotonically increasing along any path from any 592 source to the destination. As a consequence, loop freedom is 593 assured. 595 Each AODVv2 router in the network MUST maintain its own sequence 596 number. An AODVv2 router increments its SeqNum as follows. Most of 597 the time, SeqNum is incremented by simply adding one (1). But to 598 increment SeqNum when it has the value of the largest possible number 599 representable as a 16-bit unsigned integer (i.e., 65,535), it MUST be 600 set to one (1). In other words, the sequence number after 65,535 is 601 1. 603 An AODVv2 router SHOULD maintain its SeqNum in persistent storage. 604 If an AODVv2 router's SeqNum is lost, it MUST take the following 605 actions to avoid the danger of routing loops. First, the AODVv2 606 router MUST invalidate all route table entries, by setting 607 Route.Broken for each entry. Furthermore the AODVv2 router MUST wait 608 for at least MAX_SEQNUM_LIFETIME before transmitting or 609 retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2 610 protocol message is received during this waiting period, the AODVv2 611 router SHOULD perform normal route table entry updates, but not 612 forward the message to other nodes. If a data packet is received for 613 forwarding to another destination during this waiting period, the 614 AODVv2 router MUST transmit a RERR message indicating that no route 615 is available. At the end of the waiting period the AODVv2 router 616 sets its SeqNum to one (1) and begins performing AODVv2 protocol 617 operations again. 619 5.6. Enabling Alternate Metrics 621 AODVv2 route selection in MANETs depends upon associating metric 622 information with each route table entry. When presented with 623 candidate route update information, deciding whether to use the 624 update involves evaluating the metric. Some applications may require 625 metric information other than Hop Count, which has traditionally been 626 the default metric associated with routes in MANET. Unfortunately, 627 it is well known that reliance on Hop Count can cause selection of 628 the worst possible route in many situations. 630 It is beyond the scope of this document to describe how applications 631 specify route selection at the time they launch processing. One 632 possibility would be to provide a route metric preference as part of 633 the library routines for opening sockets. In view of the above 634 considerations, it is important to enable route selection based on 635 metric information other than Hop Count -- in other words, based on 636 "alternate metrics". Each such alternate metric measures a "cost" of 637 using the associated route, and there are many different kinds of 638 cost (latency, delay, monetary, energy, etc.). 640 The most significant change when enabling use of alternate metrics is 641 to require the possibility of multiple routes to the same 642 destination, where the "cost" of each of the multiple routes is 643 measured by a different metric. Moreover, the method by which route 644 updates are tested for usefulness has to be slightly generalized to 645 depend upon a more abstract method of evaluation which, in this 646 document, is named "Cost(R)", where 'R' is the route for which the 647 Cost is to be evaluated. From the above, the route table information 648 for 'R' must always include the type of metric by which Cost(R) is 649 evaluated, so the metric type does not have to be shown as a distinct 650 parameter for Cost(R). Since determining loop freedom is known to 651 depend on comparing the Cost(R) of route update information to the 652 Cost(R) of an existing stored route using the same metric, AODVv2 653 must also be able to invoke an abstract routine which in this 654 document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE 655 when, (under the assumption of nondecreasing SeqNum during Route 656 Discovery) given that R2 is loop-free and Cost(R2) is the cost of 657 route R2, Cost(R1) is known to guarantee loop freedom of the route 658 R1. In this document, LoopFree(R1,R2) will only be invoked for 659 routes R1 and R2 to the same destination which use the same metric. 661 Generally, HopCount may still be considered the default metric for 662 use in MANETs, notwithstanding the above objections. Each metric has 663 to have a Metric Type, and the Metric Type is allocated by IANA as 664 specified in [RFC6551]. Each Route has to include the Metric Type as 665 part of the route table entry for that route. Hop Count has Metric 666 Type assignment 3. The Cost of a route using Metric Type 3 is simply 667 the hop count between the router and the destination. For routes R1 668 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2) 669 <= (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2) 670 for metric types other than 3 is beyond the scope of this document. 672 Whenever an AODV router receives metric information in an incoming 673 message, the value of the metric is as measured by the transmitting 674 router, and does not reflect the cost of traversing the incoming 675 link. In order to simplify the description of storing accrued route 676 costs in the route table, the Cost() function is also defined to 677 return the value of traversing a link 'L'. In other words, the 678 domain of the Cost() function is enlarged to include links as well as 679 routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1 680 for all links. The specification of Cost(L) for metric types other 681 than 3 is beyond the scope of this document. Whether the argument of 682 the Cost() function is a link or a route will, in this document, 683 always be clear. As a natural result of the way routes are looked up 684 according to conformant metric type, all intermediate routers 685 handling a RteMsg will assign the same metric type to all metric 686 information in the RteMsg. 688 For some metrics, a maximum value is defined, namely MAX_METRIC[i] 689 where 'i' is the Metric Type. AODVv2 does not store routes that cost 690 more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be 691 MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount 692 metric. MAX_HOPCOUNT MUST be larger than the AODVv2 network 693 diameter. Otherwise, AODVv2 protocol messages may not reach their 694 intended destinations. 696 5.7. RREQ Table: Received RREQ Messages 698 Two incoming RREQ messages are considered to be "comparable" if they 699 were generated by the same AODVv2 router in order to discover a route 700 for the same destination with the same metric type. According to 701 that notion of comparability, when RREQ messages are flooded in a 702 MANET, an AODVv2 router may well receive comparable RREQ messages 703 from more than one of its neighbors. A router, after receiving an 704 RREQ message, MUST check against previous RREQs to assure that its 705 response message would contain information that is not redundant. 706 Otherwise, multicast RREQs are likely to be retransmitted again and 707 again with almost no additional benefit, but generating a great deal 708 of unnecessary signaling traffic and interference. 710 To avoid transmission of redundant RREQ messages, while still 711 enabling the proper handling of earlier RREQ messages that may have 712 somehow been delayed in the network, it is needed for each AODVv2 713 router to keep a list of the certain information about RREQ messages 714 which it has recently received. 716 This list is called the AODVv2 Received RREQ Table -- or, more 717 briefly, the RREQ Table. Two AODVv2 RREQ messages are comparable if: 719 o they have the same metric type 720 o they have the same OrigNode and TargNode addresses 722 Each entry in the RREQ Table has the following fields: 724 o Metric Type 725 o OrigNode address 726 o TargNode address 727 o Sequence Number 728 o Metric 729 o Timestamp 731 The RREQ Table is maintained so that no two entries in the RREQ Table 732 are comparable -- that is, all RREQs represented in the RREQ Table 733 either have different OrigNode addresses, different TargNode 734 addresses, or different metric types. If two RREQs have the same 735 metric type and OrigNode and Targnode addresses, the information from 736 the one with the older Sequence Number is not needed in the table; in 737 case they have the same Sequence Number, the one with the greater 738 Metric value is not needed; in case they have the same Metric as 739 well, it does not matter which table entry is maintained. Whenever a 740 RREQ Table entry is updated, its Timestamp field should also be 741 updated to reflect the Current_Time. 743 When optional multicast RREP (see Section 13.4) is used to enable 744 selection from among multiple possible return routes, an AODVv2 745 router can eliminate redundant RREP messages using the analogous 746 mechanism along with a RREP Table. Nevertheless, the description in 747 this section only refers to RREQ multicast messages. 749 Protocol handling of RERR messages eliminates the need for tracking 750 RERR messages, since the rules for RERR regeneration prevent the 751 phenomenon of redundant retansmission that affects RREQ and RREP 752 multicast. 754 6. AODVv2 Operations on Route Table Entries 756 In this section, operations are specified for updating the route 757 table due to timeouts and route updates within AODVv2 messages. 758 Route update information in AODVv2 messages includes IP addresses, 759 along with the SeqNum and prefix length associated with each IP 760 address, and including the Metric measured from the node transmitting 761 the AODVv2 message to the IP address in the route update. IP 762 addresses and prefix length are encoded within an RFC 5444 AddrBlk, 763 and the SeqNum and Metric associated with each address in the AddrBlk 764 are encoded in RFC 5444 AddrTLVs. Optionally, there may be AddedNode 765 route updates included in AODVv2 messages, as specified in 766 Section 13.7. In this section, RteMsg is either RREQ or RREP, 767 RteMsg.Addr[i] denotes the [i]th address in an RFC 5444 AddrBlk of 768 the RteMsg. RteMsg.PrefixLength[i] denotes the associated prefix 769 length for RteMsg.Addr[i], and RteMsg.{field} denotes the 770 corresponding value in the named AddrTLV block associated with 771 RteMsg.Addr[i]. All SeqNum comparisons use signed 16-bit arithmetic. 773 6.1. Evaluating Incoming Routing Information 775 If the incoming RteMsg does not have a MetricType Message TLV, then 776 the metric information contained by RteMsg is considered to be of 777 type DEFAULT_METRIC_TYPE -- which is 3 (for HopCount) unless changed 778 by administrative action. Whenever an AODVv2 router (HandlingRtr) 779 handles an incoming RteMsg (i.e., RREQ or RREP), for every relevant 780 address (RteMsg.Addr) in the RteMsg, HandlingRtr searches its route 781 table to see if there is a route table entry with the same MetricType 782 of the RteMsg, matching RteMsg.Addr. If not, HandlingRtr creates a 783 route table entry for RteMsg.Addr as described in Section 6.2. 784 Otherwise, HandlingRtr compares the incoming routing information in 785 RteMsg against the already stored routing information in the route 786 table entry (Route) for RteMsg.Addr, as described below. 788 Suppose Route[RteMsg.Addr] uses the same metric type as the incoming 789 routing information, and the route entry contains Route.SeqNum, 790 Route.Metric, and Route.Broken. Suppose the incoming routing 791 information for Route.Addr is RteMsg.SeqNum and RteMsg.Metric. 792 Define RteMsg.Cost to be (RteMsg.Metric + Cost(L)), where L is the 793 incoming link. The incoming routing information is classified as 794 follows: 796 1. Stale:: RteMsg.SeqNum < Route.SeqNum : 797 If RteMsg.SeqNum < Route.SeqNum the incoming information is stale. 798 Using stale routing information is not allowed, since that might 799 result in routing loops. HandlingRtr MUST NOT update the route 800 table entry using the routing information for RteMsg.Addr. 801 2. Unsafe against loops:: (TRUE != LoopFree (RteMsg, Route)) : 802 If RteMsg is not Stale (as in (1) above), RteMsg.Cost is next 803 considered to insure loop freedom. If (TRUE != LoopFree (RteMsg, 804 Route)) (see Section 5.6), then the incoming RteMsg information is 805 not guaranteed to prevent routing loops, and it MUST NOT be used 806 to update any route table entry. 807 3. More costly:: 808 (RteMsg.Cost >= Route.Metric) && (Route.Broken==FALSE) 809 When RteMsg.SeqNum is the same as in a valid route table entry, 810 and LoopFree (RteMsg, Route) assures loop freedom, incoming 811 information still does not offer any improvement over the existing 812 route table information if RteMsg.Cost >= Route.Metric. Using 813 such incoming routing information to update a route table entry is 814 not recommended. 815 4. Offers improvement:: 816 Incoming routing information that does not match any of the above 817 criteria is better than existing routing table information and 818 SHOULD be used to improve the route table. The following pseudo- 819 code illustrates whether incoming routing information should be 820 used to update an existing route table entry as described in 821 Section 6.2. 823 (RteMsg.SeqNum > Route.SeqNum) OR 824 {(RteMsg.SeqNum == Route.SeqNum) AND 825 [(RteMsg.Cost < Route.Metric) OR 826 ((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]} 828 The above logic corresponds to placing the following conditions on 829 the incoming route update (compared to the existing route table 830 entry) before it can be used: 832 * it is more recent, or 833 * it is not stale and is less costly, or 834 * it can safely repair a broken route. 836 6.2. Applying Route Updates To Route Table Entries 837 To apply the route update, the route table entry is populated with 838 the following information: 840 o Route.Address := RteMsg.Addr 841 o If RteMsg.PrefixLength exists, then Route.PrefixLength := 842 RteMsg.PrefixLength. Otherwise, Route.PrefixLength := maximum 843 length for address family (either 32 or 128). 844 o Route.SeqNum := RteMsg.SeqNum 845 o Route.NextHopAddress := IP.SourceAddress (i.e., an address of the 846 node from which the RteMsg was received) 847 o Route.NextHopInterface is set to the interface on which RteMsg was 848 received 849 o Route.Broken flag := FALSE 850 o If RteMsg.MetricType is included, then 851 Route.MetricType := RteMsg.MetricType. Otherwise, 852 Route.MetricType := DEFAULT_METRIC_TYPE. 853 o Route.Metric := (RteMsg.Metric + Cost(L)), where L is the incoming 854 link. 855 o Route.LastUsed := Current_Time 856 o If RteMsg.VALIDITY_TIME is included, then 857 Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME, 858 otherwise, Route.ExpirationTime := Current_Time + (ACTIVE_INTERVAL 859 + MAX_IDLETIME). 861 With these assignments to the route table entry, a route has been 862 made available, and the route can be used to send any buffered data 863 packets and subsequently to forward any incoming data packets for 864 Route.Addr. An updated route entry also fulfills any outstanding 865 route discovery (RREQ) attempts for Route.Addr. 867 6.3. Route Table Entry Timeouts 869 During normal operation, AODVv2 does not require any explicit 870 timeouts to manage the lifetime of a route. However, the route table 871 entry MUST be examined before using it to forward a packet, as 872 discussed in Section 8.1. Any required expiry or deletion can occur 873 at that time. Nevertheless, it is permissible to implement timers 874 and timeouts to achieve the same effect. 876 At any time, the route table can be examined and route table entries 877 can be expunged according to their current state at the time of 878 examination, as follows. 880 o An Active route MUST NOT be expunged. 881 o An Idle route SHOULD NOT be expunged. 882 o An Expired route MAY be expunged (least recently used first). 883 o A route MUST be expunged if (Current_Time - Route.LastUsed) >= 884 MAX_SEQNUM_LIFETIME. 886 o A route MUST be expunged if Current_Time >= Route.ExpirationTime 888 If precursor lists are maintained for the route (as described in 889 Section 13.3) then the precursor lists must also be expunged at the 890 same time that the route itself is expunged. 892 7. Routing Messages RREQ and RREP (RteMsgs) 894 AODVv2 message types RREQ and RREP are together known as Routing 895 Messages (RteMsgs) and are used to discover a route between an 896 Originating and Target Node, denoted here by OrigNode and TargNode. 897 The constructed route is bidirectional, enabling packets to flow 898 between OrigNode and TargNode. RREQ and RREP have similar 899 information and function, but have some differences in their rules 900 for handling. The main difference between the two messages is that 901 RREQ messages are typically multicast to solicit a RREP, whereas RREP 902 is typically unicast as a response to RREQ. 904 When an AODVv2 router needs to forward a data packet from a node 905 (OrigNode) in its set of router clients, and it does not have a 906 forwarding route toward the packet's IP destination address 907 (TargNode), the AODVv2 router (RREQ_Gen) generates a RREQ (as 908 described in Section 7.3) to discover a route toward TargNode. 909 Subsequently RREQ_Gen awaits reception of an RREP message (see 910 Section 7.4) or other route table update (see Section 6.2) to 911 establish a route toward TargNode. Optionally, RREQ_Gen MAY specify 912 that only the router serving TargNode is allowed to generate an RREP 913 message, by including the DestOnly message TLV (see Section 7.3). 914 The RREQ message contains routing information to enable RREQ 915 recipients to route packets back to OrigNode, and the RREP message 916 contains routing information enabling RREP recipients to route 917 packets to TargNode. 919 7.1. Route Discovery Retries and Buffering 921 After issuing a RREQ, as described above RREQ_Gen awaits a RREP 922 providing a bidirectional route toward Target Node. If the RREP is 923 not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route 924 Discovery by generating another RREQ. Route Discovery SHOULD be 925 considered to have failed after DISCOVERY_ATTEMPTS_MAX and the 926 corresponding wait time for a RREP response to the final RREQ. After 927 the attempted Route Discovery has failed, RREQ_Gen MUST wait at least 928 RREQ_HOLDDOWN_TIME before attempting another Route Discovery to the 929 same destination. 931 To reduce congestion in a network, repeated attempts at route 932 discovery for a particular Target Node SHOULD utilize a binary 933 exponential backoff. 935 Data packets awaiting a route SHOULD be buffered by RREQ_Gen. This 936 buffer SHOULD have a fixed limited size (BUFFER_SIZE_PACKETS or 937 BUFFER_SIZE_BYTES). Determining which packets to discard first is a 938 matter of policy at each AODVv2 router; in the absence of policy 939 constraints, by default older data packets SHOULD be discarded first. 940 Buffering of data packets can have both positive and negative effects 941 (albeit usually positive). Nodes without sufficient memory available 942 for buffering SHOULD be configured to disable buffering by 943 configuring BUFFER_SIZE_PACKETS == 0 and BUFFER_SIZE_BYTES == 0. 944 Doing so will affect the latency required for launching TCP 945 applications to new destinations. 947 If a route discovery attempt has failed (i.e., DISCOVERY_ATTEMPTS_MAX 948 attempts have been made without receiving a RREP) to find a route 949 toward the Target Node, any data packets buffered for the 950 corresponding Target Node MUST BE dropped and a Destination 951 Unreachable ICMP message (Type 3) SHOULD be delivered to the source 952 of the data packet. The code for the ICMP message is 1 (Host 953 unreachable error). If RREQ_Gen is not the source (OrigNode), then 954 the ICMP is sent over the interface from which OrigNode sent the 955 packet to the AODVv2 router. 957 7.2. RteMsg Structure 959 RteMsgs have the following general format: 961 +---------------------------------------------------------------+ 962 | RFC 5444 Message Header (optionally, with MsgTLVs) | 963 +---------------------------------------------------------------+ 964 | AddrBlk := {OrigNode,TargNode} | 965 +---------------------------------------------------------------+ 966 | AddrBlk.PrefixLength[OrigNode OR TargNode] (Optional) | 967 +---------------------------------------------------------------+ 968 | OrigSeqNumTLV AND/OR TargSeqNumTLV | 969 +---------------------------------------------------------------+ 970 | MetricTLV {OrigNode, TargNode} (Optional) | 971 +---------------------------------------------------------------+ 972 | Added Node Address Block (Optional) | 973 +---------------------------------------------------------------+ 974 | Added Node Address SeqNumTLV | 975 +---------------------------------------------------------------+ 976 | Added Node Address MetricTLV[MetricType] | 977 +---------------------------------------------------------------+ 979 Figure 1: RREQ and RREP (RteMsg) message structure 981 Required Message Header Fields 982 The RteMsg MUST contain the following: 984 * 985 * Metric Type Message TLV, if MetricType != 3 986 Optional Message Header Fields 987 The RteMsg may contain the following: 989 * 990 * DestOnly TLV (RREQ only: no Intermediate RREP) 991 * MetricType TLV (Metric Type for Metric AddrTLV) 992 * AckReq TLV (Acknowledgement Requested) 993 AddrBlk 994 This Address Block contains the IP addresses for RREQ Originating 995 and Target Node (OrigNode and TargNode). For both RREP and RREQ, 996 OrigNode and TargNode are as identified in the context of the RREQ 997 message originator. 998 OrigSeqNum AND/OR TargSeqNum AddrTLV 999 At least one of OrigSeqNum or TargSeqNum Address Block TLV is 1000 REQUIRED and carries the destination sequence numbers associated 1001 with either OrigNode or TargNode. Both may appear when SeqNum 1002 information is available for both OrigNode and TargNode. 1003 (Optional) Added Node AddrBlk 1004 AODVv2 allows the inclusion of routing information for other nodes 1005 in addition to OrigNode and TargNode. 1006 (Optional) SeqNum AddrTLV If the Added Node AddrBlk is present, the 1007 SeqNum AddrTLV is REQUIRED, to carry the destination sequence 1008 numbers associated with the Added Nodes. 1009 (Optional) Metric AddrTLV If the Added Node AddrBlk is present, this 1010 AddrTLV is REQUIRED, to carry the metric information associated 1011 with the Added Nodes. See below. 1013 RteMsgs carry information about OrigNode and TargNode. Since their 1014 addresses may appear in arbitrary order within the RFC 5444 AddrBlk, 1015 the OrigSeqNum and/or TargSeqNum TLVs must be used to distinguish the 1016 nature of the node addresses present in the AddrBlk. In each RteMsg, 1017 at least one of OrigSeqNumTLV or TargSeqNumTLV MUST appear. Both 1018 TLVs MAY appear in the same RteMsg, but each one MUST NOT appear more 1019 than once, because there is only one OrigNode and only one TargNode 1020 address in the AddrBlk. 1022 If the OrigSeqNum TLV appears, then the address range for the 1023 OrigSeqNum TLV MUST be limited to a single position in the AddrBlk. 1024 That position is used as the OrigNdx, identifying the OrigNode 1025 address. The other address in the AddrBlk is, by elimination, the 1026 TargNode address, and TargNdx is set appropriately. 1028 Otherwise, if the TargSeqNum TLV appears, then the address range for 1029 the TargSeqNum TLV MUST be limited to a single position in the 1030 AddrBlk. That position is used as the TargNdx, identifying the 1031 TargNode address. The other address in the AddrBlk is, by 1032 elimination, the OrigNode address, and OrigNdx is set appropriately. 1034 7.3. RREQ Generation 1036 The AODVv2 router generating the RREQ (RREQ_Gen) on behalf of its 1037 client OrigNode follows the steps in this section. OrigNode MUST be 1038 a unicast address. The order of protocol elements is illustrated 1039 schematically in Figure 1. 1041 1. RREQ_Gen MUST increment its SeqNum by one (1) according to the 1042 rules specified in Section 5.5. This assures that each node 1043 receiving the RREQ will update its route table using the 1044 information in the RREQ. 1045 2. If RREQ_Gen requires that only the router providing connectivity 1046 to TargNode is allowed to generate a RREP, then RREQ_Gen includes 1047 the "Destination RREP Only" (DestOnly) TLV as part of the RFC 1048 5444 message header. This also assures that RREP_Gen increments 1049 its sequence number. Otherwise, (if the optional behavior is 1050 enabled) other AODVv2 routers MAY respond to the RREQ if they 1051 have a valid route to TargNode (see Section 13.2). 1052 3. SHOULD be set to MAX_HOPCOUNT. 1053 4. , if included, MUST be set to 0. 1055 * This RFC 5444 constraint causes the typical RREQ payload to 1056 incur additional enlargement (otherwise, could 1057 often be used as the metric). 1058 5. RREQ.AddrBlk := {OrigNode.Addr, TargNode.Addr} 1060 Let OrigNodeNdx and TargNodeNdx denote the indexes of OrigNode 1061 and TargNode respectively in the RREQ.AddrBlk list. 1062 6. If Route[OrigNode].PrefixLength/8 is equal to the number of bytes 1063 in the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no 1064 is included with the RREQ.AddrBlk. Otherwise, 1065 RREQ.PrefixLength[OrigNodeNdx] := Route[OrigNode].PrefixLength 1066 according to the rules of RFC 5444 AddrBlk encoding. 1067 7. RREQ.OrigSeqNumTLV[OrigNodeNdx] := RREQ_Gen SeqNum 1068 8. RREQ.TargSeqNumTLV[TargNodeNdx] := TargNode SeqNum (only if 1069 known) 1071 RREQ_Gen SHOULD include TargNode's SeqNum, if a previous value of 1072 the TargNode's SeqNum is known (e.g., from an invalid routing 1073 table entry using longest-prefix matching). If TargNode's SeqNum 1074 is not included, AODVv2 routers handling the RREQ assume that 1075 RREQ_Gen does not have that information. If ENABLE_IRREP is 1076 enabled, then any route to TargNode will satisfy the RREQ 1077 [I-D.perkins-irrep]. 1078 9. RREQ.MetricTLV[1] := Route[OrigNode].Metric 1080 An example RREQ message format is illustrated in Appendix A.1. 1082 7.4. RREP Generation 1084 This section specifies the generation of an RREP by an AODVv2 router 1085 (RREP_Gen) that provides connectivity for the Target Node (TargNode) 1086 of a RREQ, thus enabling the establishment of a route between 1087 OrigNode and TargNode. If TargNode is not a unicast IP address the 1088 RREP MUST NOT be generated, and processing for the RREQ is complete. 1089 Before transmitting a RREP, the routing information of the RREQ is 1090 processed as specified in Section 6.2; after such processing, 1091 RREP_Gen has an updated route to OrigNode as well as TargNode. The 1092 basic format of an RREP conforms to the structure for RteMsgs as 1093 shown in Figure 1. 1095 RREP_Gen generates the RREP as follows: 1097 1. RREP_Gen checks the RREQ against recently received RREQ 1098 information as specified in Section 7.6. If a previously 1099 received RREQ has made the information in the incoming RREQ to 1100 be redundant, no RREP is generated and processing is complete. 1101 2. RREP_Gen MUST increment its SeqNum by one (1) according to the 1102 rules specified in Section 5.5. 1103 3. RREP.AddrBlk := {OrigNode.Addr, TargNode.Addr} 1105 Let OrigNodeNdx and TargNodeNdx denote the indexes of OrigNode 1106 and TargNode respectively in the RREQ.AddrBlk list. 1107 4. RREP.OrigSeqNumTLV[OrigNodeNdx] := Route[OrigNode].Seqnum 1108 5. RREP.TargSeqNumTLV[TargNodeNdx] := RREP_Gen's SeqNum 1109 6. If Route[TargNode].PrefixLength/8 is equal to the number of 1110 bytes in the addresses of the RREQ (4 for IPv4, 16 for IPv6), 1111 then no is included with the RREP.AddrBlk. 1112 Otherwise, RREP.PrefixLength[TargNodeNdx] := 1113 Route[TargNode].PrefixLength according to the rules of RFC 5444 1114 AddrBlk encoding. 1115 7. RREP.MetricType[TargNodeNdx] := Route[TargNode].MetricType 1116 8. RREP.Metric[TargNodeNdx] := Route[TargNode].Metric 1117 9. , if included, MUST be set to 0. 1118 10. SHOULD be set to RREQ.. 1119 11. IP.DestinationAddr := Route[OrigNode].NextHop 1121 An example message format for RREP is illustrated in Appendix A.2. 1123 7.5. Handling a Received RteMsg 1125 Before an AODVv2 router can make use of a received RteMsg (i.e., RREQ 1126 or RREP), the router first must verify that the RteMsg is permissible 1127 according to the following steps. OrigNodeNdx and TargNodeNdx are 1128 set according to the rules in Section 7.2. For RREQ, RteMsg.Metric 1129 is MetricTLV[OrigNodeNdx]. For RREP, RteMsg.Metric is 1130 MetricTLV[TargNodeNdx]. In this section (unless qualified by 1131 additional description such as "upstream" or "neighboring") all 1132 occurrences of the term "router" refer to the AODVv2 router handling 1133 the received RteMsg. 1135 1. A router MUST handle RteMsgs only from neighbors as specified in 1136 Section 5.4. RteMsgs from other sources MUST be disregarded. 1137 2. The router examines the RteMsg to ascertain that it contains the 1138 required information: , TargNode.Addr, 1139 OrigNode.Addr, RteMsg.Metric, and either RteMsg.OrigSeqNum or 1140 RteMsg.TargSeqNum. If the required information does not exist, 1141 the message is disregarded. 1142 3. The router checks that OrigNode.Addr and TargNode.Addr are valid 1143 routable unicast addresses. If not, the message is disregarded. 1144 4. The router checks the Metric Type MsgTLV (if present) to assure 1145 that the Metric Type associated with the Metric AddrTLV 1146 information in the RREQ or RREP is known, and that Cost(L) can be 1147 computed, where 'L' is the incoming link. If not, the message is 1148 disregarded. 1150 * DISCUSSION: or, can change the AddrBlk metric to use HopCount, 1151 e.g., measured from . 1152 5. If (MAX_METRIC[RteMsg.MetricType] - Cost(L)) <= RteMsg.Metric, 1153 the RteMsg is disregarded, where Cost(L) denotes the cost of 1154 traversing the incoming link (i.e., as measured by the network 1155 interface receiving the incoming RteMsg). 1157 An AODVv2 router handles a permissible RteMsg according to the 1158 following steps. 1160 1. The router MUST process the routing information for OrigNode and 1161 TargNode contained in the RteMsg as specified in Section 6.1. 1162 2. The router MAY process AddedNode routing information (if present) 1163 as specified in Section 13.7.1. Otherwise, if AddedNode 1164 information is not processed, it MUST be deleted, because it may 1165 no longer be accurate as a route update to any upstream router. 1166 3. If RteMsg. is zero (0), no further action is 1167 taken, and the RteMsg is not retransmitted. Otherwise, the 1168 router MUST decrement RteMsg.. 1170 4. If the RteMsg. is present, and == 1171 MAX_HOPCOUNT, then no further action is taken. Otherwise, the 1172 router MUST increment RteMsg. 1174 Further actions to transmit an updated RteMsg depend upon whether the 1175 incoming RteMsg is an RREP or an RREQ. 1177 7.5.1. Additional Handling for Incoming RREQ 1179 o By sending a RREQ, a router advertises that it will route for 1180 addresses contained in the RteMsg based on the information 1181 enclosed. The router MAY choose not to send the RREQ, though not 1182 resending the RREQ could decrease connectivity in the network or 1183 result in nonoptimal paths. The circumstances under which a 1184 router might choose not to re-transmit a RREQ are not specified in 1185 this document. Some examples might include the following: 1187 * The router is already heavily loaded and does not want to 1188 advertise routing for more traffic 1189 * The router recently transmitted identical routing information 1190 (e.g. in a RREQ advertising the same metric) Section 7.6 1191 * The router is low on energy and has to reduce energy expended 1192 for sending protocol messages or packet forwarding 1194 Unless the router is prepared to send a RREQ, it halts processing. 1195 o If the upstream router sending a RREQ is in the Blacklist, and 1196 Current_Time < Blacklist.RemoveTime, then the router receiving 1197 that RREQ MUST NOT transmit any outgoing RteMsg, and processing is 1198 complete. 1199 o Otherwise, if the upstream router is in the Blacklist, and 1200 Current_Time >= Blacklist.RemoveTime, then the upstream router 1201 SHOULD be removed from the Blacklist, and message processing 1202 continued. 1203 o The incoming RREQ MUST be checked against previously received 1204 information from the RREQ Table Section 7.6. If the information 1205 in the incoming RteMsg is redundant, then then no further action 1206 is taken. 1207 o If TargNode is a client of the router receiving the RREQ, then the 1208 router generates a RREP message as specified in Section 7.4, and 1209 subsequently processing for the RREQ is complete. Otherwise, 1210 processing continues as follows. 1211 o RREQ.MetricType := Route[OrigNode].MetricType 1212 o RREQ.MetricTLV[OrigNodeNdx] := Route[OrigNode].Metric 1213 o The RREQ (with updated fields as specified above>) SHOULD be sent 1214 to the IP multicast address LL-MANET-Routers [RFC5498]. If the 1215 RREQ is unicast, the IP.DestinationAddress is set to 1216 Route[RREQ.TargNode].NextHopAddress. 1218 7.5.2. Additional Handling for Incoming RREP 1220 As before, OrigNode and TargNode are named in the context of RREQ_Gen 1221 (i.e., the router originating the RREQ for which the RREP was 1222 generated) (see Table 1). OrigNodeNdx and TargNodeNdx are set 1223 according to the rules in Section 7.2. 1225 o If no forwarding route exists to OrigNode, then a RERR SHOULD be 1226 transmitted to RREP.AddrBlk[TargNodeNdx]. Otherwise, if 1227 HandlingRtr is not RREQ_Gen then the outgoing RREP is sent to the 1228 Route.NextHopAddress for the RREP.AddrBlk[OrigNodeNdx]. 1229 o If HandlingRtr is RREQ_Gen then the RREP satisfies RREQ_Gen's 1230 earlier RREQ, and RREP processing is completed. Any packets 1231 buffered for OrigNode should be transmitted. 1233 7.6. Suppressing Redundant RREQ messages 1235 Since RREQ messages are multicast, there are common circumstances in 1236 which an AODVv2 router might transmit a redundant response (RREQ or 1237 RREP), duplicating the information transmitted in response to some 1238 other recent RREQ (see Section 5.7). Before responding, an AODVv2 1239 router MUST suppress such redundant RREQ messages. This is done by 1240 checking the list of recently received RREQs to determine whether the 1241 incoming RREQ contains new information, as follows: 1243 o The AODVv2 router searches the RREQ Table for recent entries with 1244 the same OrigNode, TargNode, and Metric Type. If there is no such 1245 entry, the incoming RREQ message is not suppressed. A new entry 1246 for the incoming RREQ is created in the RREQ Table. 1247 o If there is such an entry, and the incoming RREQ has a newer 1248 sequence number, the incoming RREQ is not suppressed, and the 1249 existing table entry MUST be updated to reflect the new Sequence 1250 Number and Metric. 1251 o Similarly, if the Sequence Numbers are the same, and the incoming 1252 RREQ offers a better Metric, the incoming RREQ is not suppressed, 1253 and the RREQ Table entry MUST be updated to reflect the new 1254 Metric. 1255 o Otherwise, the incoming RREQ is suppressed. 1257 8. Route Maintenance and RERR Messages 1259 AODVv2 routers attempt to maintain active routes. When a routing 1260 problem is encountered, an AODVv2 router (denoted RERR_Gen) attempts 1261 to quickly notify upstream routers. Two kinds of routing problems 1262 may trigger generation of a RERR message. The first case happens 1263 when the router receives a packet but does not have a route for the 1264 destination of the packet. The second case happens immediately upon 1265 detection of a broken link (see Section 8.2) of an Active route, to 1266 quickly notify upstream AODVv2 routers that that route is no longer 1267 available. 1269 8.1. Maintaining Route Lifetimes During Packet Forwarding 1271 Before using a route to forward a packet, an AODVv2 router MUST check 1272 the status of the route as follows. 1274 If the route is marked has been marked as Broken, it cannot be 1275 used for forwarding. 1276 If Current_Time > Route.ExpirationTime, the route table entry has 1277 expired, and cannot be used for forwarding. 1278 Similarly, if (Route.ExpirationTime == MAXTIME), and if 1279 (Current_Time - Route.LastUsed) > (ACTIVE_INTERVAL + 1280 MAX_IDLETIME), the route has expired, and cannot be used for 1281 forwarding. 1282 Furthermore, if Current_Time - Route.LastUsed > 1283 (MAX_SEQNUM_LIFETIME), the route table entry MUST be expunged. 1285 If any of the above route error conditions hold true, the route 1286 cannot be used to forward the packet, and an RERR message MUST be 1287 generated (see Section 8.3). 1289 Otherwise, Route.LastUsed := Current_Time, and the packet is 1290 forwarded to the route's next hop. 1292 Optionally, if a precursor list is maintained for the route, see 1293 Section 13.3 for precursor lifetime operations. 1295 8.2. Active Next-hop Router Adjacency Monitoring 1297 AODVv2 routers SHOULD monitor connectivity to adjacent routers along 1298 active routes. This monitoring can be accomplished by one or several 1299 mechanisms, including: 1301 o Neighborhood discovery [RFC6130] 1302 o Route timeout 1303 o Lower layer trigger that a link is broken 1304 o TCP timeouts 1305 o Promiscuous listening 1306 o Other monitoring mechanisms or heuristics 1308 If a next-hop AODVv2 router has become unreachable, RERR_Gen follows 1309 the procedures specified in Section 8.3.2. 1311 8.3. RERR Generation 1312 An RERR message is generated by a AODVv2 router (i.e., RERR_Gen) in 1313 order to notify upstream routers that packets cannot be delivered to 1314 certain destinations. An RERR message has the following general 1315 structure: 1317 +---------------------------------------------------------------+ 1318 | RFC 5444 Message Header | 1319 +---------------------------------------------------------------+ 1320 | UnreachableNode AddrBlk (Unreachable Node addresses) | 1321 +---------------------------------------------------------------+ 1322 | UnreachableNode SeqNum AddrBlk TLV | 1323 +---------------------------------------------------------------+ 1325 Figure 2: RERR message structure 1327 Required Message Header Fields 1328 The RERR MUST contain the following: 1330 * 1331 * PktSource Message TLV (see Section 15), if the RERR is unicast 1332 * Metric Type Message TLV (see Section 15), if MetricType != 3 1333 Optional Message Header Fields 1334 The RERR may contain the following: 1336 * 1337 UnreachableNode AddrBlk 1338 This Address Block contains the IP addresses unreachable by AODVv2 1339 router transmitting the RERR. 1340 Sequence Number AddrBlk TLV 1341 This Address Block TLV carries the destination sequence number 1342 associated with each UnreachableNode when that information is 1343 available. 1344 UnreachableNode.PrefixLength 1345 The prefix length associated with an UnreachableNode. 1347 There are two kinds of events indicating that packets cannot be 1348 delivered to certain destinations. The two cases differ in the way 1349 that the neighboring IP destination address for the RERR is chosen, 1350 and in the way that the set of UnreachableNodes is identified. 1352 In both cases, the MUST be included and SHOULD be set 1353 to MAX_HOPCOUNT. SHOULD be included and set to 0, to 1354 facilitate use of various route repair strategies including expanding 1355 rings multicast and Intermediate RREP [I-D.perkins-irrep]. 1357 8.3.1. Case 1: Undeliverable Packet 1358 The first case happens when the router receives a packet from another 1359 AODVv2 router but does not have a valid route for the destination of 1360 the packet. In this case, there is exactly one UnreachableNode to be 1361 included in the RERR's AddrBlk (either IP.DestinationAddress from a 1362 data packet or RREP.AddrBlk[OrigNode]). The RERR SHOULD be sent to 1363 the multicast address LL-MANET-Routers, but RERR_Gen MAY instead send 1364 the RERR to the next hop towards the source IP address of the packet 1365 which was undeliverable. For unicast RERR, the PktSource Message TLV 1366 MUST be included, containing the the source IP address of the 1367 undeliverable packet, or the IP address of TargRtr in case the 1368 undeliverable packet was an RREP message generated by TargRtr. If a 1369 Sequence Number for UnreachableNode is known, that Sequence Number 1370 SHOULD be included in a Seqnum AddrTLV the RERR. Otherwise all nodes 1371 handling the RERR will assume their route through RERR_Gen towards 1372 the UnreachableNode is no longer valid and flag those routes as 1373 broken, regardless of the Sequence Number information for those 1374 routes. RERR_Gen MUST discard the packet or message that triggered 1375 generation of the RERR. 1377 If an AODVv2 router receives an ICMP packet from the address of one 1378 of its client nodes, it simply relays the packet to the ICMP packet's 1379 destination address, and does not generate any RERR message. 1381 8.3.2. Case 2: Broken Link 1383 The second case happens when the link breaks to an active adjacent 1384 AODVv2 router (i.e., the next hop of an active route). In this case, 1385 the RERR MUST be sent to the multicast address LL-MANET-Routers, 1386 except when the optional feature of maintaining precursor lists is 1387 used as specified in Section 13.3. All routes (Active, Idle and 1388 Expired) that use the broken link MUST be marked as Broken. The set 1389 of UnreachableNodes is initialized by identifying those Active routes 1390 which use the broken link. For each such Active Route, Route.Dest is 1391 added to the set of Unreachable Nodes. After the Active Routes using 1392 the broken link have all been included as UnreachableNodes, Idle 1393 routes MAY also be included, if allowed by the setting of 1394 ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR does 1395 not exceed the MTU (interface "Maximum Transfer Unit") of the 1396 physical medium. 1398 If the set of UnreachableNodes is empty, no RERR is generated. 1399 Otherwise, RERR_Gen generates a new RERR, and the address of each 1400 UnreachableNode is inserted into an AddrBlock. The value for each 1401 UnreachableNode's SeqNum (UnreachableNode.SeqNum) MUST be placed in 1402 the SeqNum AddrTLV. If none of UnreachableNode.Addr entries are 1403 associated with routing prefixes (i.e., no prefix length is shorter 1404 than the maximum length for the address family), then the AddrBlk 1405 SHOULD NOT include any prefix-length information. 1407 Every broken route reported in the RERR MUST have the same Metric 1408 Type. If the Metric Type is not 3, then the RERR message MUST 1409 contain a MetricType MsgTLV indicating the Metric Type of the broken 1410 route(s). 1412 8.4. Receiving and Handling RERR Messages 1414 When an AODVv2 router (HandlingRtr) receives a RERR message, it uses 1415 the information provided to invalidate affected routes. If the 1416 information in the RERR may be relevant to upstream neighbors using 1417 those routes, HandlingRtr subsequently sends another RERR to those 1418 neighbors. This operation has the effect of retransmitting the RERR 1419 information and is counted as another "hop" for purposes of properly 1420 modifying and in the RERR message 1421 header. 1423 HandlingRtr examines the incoming RERR to assure that it contains 1424 and at least one UnreachableNode.Address. If the 1425 required information does not exist, the incoming RERR message is 1426 disregarded and further processing stopped. Otherwise, for each 1427 UnreachableNode.Address, HandlingRtr searches its route table for a 1428 route using longest prefix matching. If no such Route is found, 1429 processing is complete for that UnreachableNode.Address. Otherwise, 1430 HandlingRtr verifies the following: 1432 1. The UnreachableNode.Address is a routable unicast address. 1433 2. Route.NextHopAddress is the same as RERR IP.SourceAddress. 1434 3. Route.NextHopInterface is the same as the interface on which the 1435 RERR was received. 1436 4. The UnreachableNode.SeqNum is unknown, OR Route.SeqNum <= 1437 UnreachableNode.SeqNum (using signed 16-bit arithmetic). 1439 If the Route satisfies all of the above conditions, HandlingRtr 1440 checks whether Route.PrefixLength is the same as the prefix length 1441 for UnreachableNode.Address. If so, HandlingRtr simply sets the 1442 Route.Broken flag for that Route. Otherwise, HandlingRtr creates a 1443 new route (call it BrokenRoute) with the same PrefixLength as the 1444 prefix length for UnreachableNode.Address, and sets the 1445 BrokenRoute.Broken flag for that new route. If the prefix length for 1446 BrokenRoute is shorter than Route.PrefixLength, then Route MUST be 1447 expunged from the routing table (since it is a subroute of the larger 1448 route which is reported to be broken). Furthermore, if is greater than 0, then HandlingRtr adds the UnreachableNode 1450 address and TLV information to an AddrBlk for delivery in the 1451 outgoing RERR message. 1453 If there are no UnreachableNode addresses to be transmitted in an 1454 RERR to upstream routers, HandlingRtr MUST discard the RERR, and no 1455 further action is taken. 1457 Otherwise, is decremented by one (1) and processing 1458 continues as follows: 1460 o (Optional) If precursor lists are maintained, the outgoing RERR 1461 SHOULD be sent to the active precursors of the broken route as 1462 specified in Section 13.3. 1463 o Otherwise, if the incoming RERR message was received at the LL- 1464 MANET-Routers [RFC5498] multicast address, the outgoing RERR 1465 SHOULD also be sent to LL-MANET-Routers. 1466 o Otherwise, if the PktSource Message TLV is present, and 1467 HandlingRtr has a Route to PktSource.Addr, then HandlingRtr MUST 1468 send the outgoing RERR to Route[PktSource.Addr].NextHop. 1469 o Otherwise, the outgoing RERR MUST be sent to LL-MANET-Routers. 1471 9. Unknown Message and TLV Types 1473 If a message with an unknown type is received, the message is 1474 disregarded. 1476 For handling of messages that contain unknown TLV types, ignore the 1477 information for processing, but preserve it unmodified for 1478 forwarding. 1480 10. Simple Internet Attachment 1482 Simple Internet attachment means attachment of a stub (i.e., non- 1483 transit) network of AODVv2 routers to the Internet via a single 1484 Internet AODVv2 router (called IAR). 1486 As in any Internet-attached network, AODVv2 routers, and their 1487 clients, wishing to be reachable from hosts on the Internet MUST have 1488 IP addresses within the IAR's routable and topologically correct 1489 prefix (e.g. 191.0.2.0/24). 1491 /-------------------------\ 1492 / +----------------+ \ 1493 / | AODVv2 Router | \ 1494 | | 191.0.2.2/32 | | 1495 | +----------------+ | Routable 1496 | +-----+--------+ Prefix 1497 | | Internet | /191.0.2/24 1498 | | AODVv2 Router| / 1499 | | 191.0.2.1 |/ /----------------\ 1500 | | serving net +-------+ Internet \ 1501 | | 191.0.2/24 | \ / 1502 | +-----+--------+ \----------------/ 1503 | +----------------+ | 1504 | | AODVv2 Router | | 1505 | | 191.0.2.3/32 | | 1506 \ +----------------+ / 1507 \ / 1508 \-------------------------/ 1510 Figure 3: Simple Internet Attachment Example 1512 When an AODVv2 router within the AODVv2 MANET wants to discover a 1513 route toward a node on the Internet, it uses the normal AODVv2 route 1514 discovery for that IP Destination Address. The IAR MUST respond to 1515 RREQ on behalf of all Internet destinations. 1517 When a packet from a node on the Internet destined for a node in the 1518 AODVv2 MANET reaches the IAR, if the IAR does not have a route toward 1519 that destination it will perform normal AODVv2 route discovery for 1520 that destination. 1522 11. Multiple Interfaces 1524 AODVv2 may be used with multiple interfaces; therefore, the 1525 particular interface over which packets arrive MUST be known whenever 1526 a packet is received. Whenever a new route is created, the interface 1527 through which the Route.Address can be reached is also recorded in 1528 the route table entry. 1530 When multiple interfaces are available, a node transmitting a 1531 multicast packet with IP.DestinationAddress set to LL-MANET-Routers 1532 SHOULD send the packet on all interfaces that have been configured 1533 for AODVv2 operation. 1535 Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all 1536 their AODVv2 interfaces. 1538 12. AODVv2 Control Packet/Message Generation Limits 1540 To avoid messaging overload, each AODVv2 router's rate of packet/ 1541 message generation SHOULD be limited. The rate and algorithm for 1542 limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the implementor 1543 and should be administratively configurable. AODVv2 messages SHOULD 1544 be discarded in the following order of preference: RREQ, RREP, and 1545 finally RERR. 1547 13. Optional Features 1548 Some optional features of AODVv2, associated with AODV, are not 1549 required by minimal implementations. These features are expected to 1550 apply in networks with greater mobility, or larger node populations, 1551 or requiring reduced latency for application launches. The optional 1552 features are as follows: 1554 o Expanding Rings Multicast 1555 o Intermediate RREPs (iRREPs): Without iRREP, only the destination 1556 can respond to a RREQ. 1557 o Precursor lists. 1558 o Reporting Multiple Unreachable Nodes. An RERR message can carry 1559 more than one Unreachable Destination node for cases when a single 1560 link breakage causes multiple destinations to become unreachable 1561 from an intermediate router. 1562 o RREP_ACK. 1563 o Message Aggregation. 1564 o Inclusion of Added Routing Information. 1566 13.1. Expanding Rings Multicast 1568 For multicast RREQ, MAY be set in accordance with an 1569 expanding ring search as described in [RFC3561] to limit the RREQ 1570 propagation to a subset of the local network and possibly reduce 1571 route discovery overhead. 1573 13.2. Intermediate RREP 1575 This specification has been published as a separate Internet Draft 1576 [I-D.perkins-irrep]. 1578 13.3. Precursor Lists and Notifications 1580 This section specifies an interoperable enhancement to AODVv2 (and 1581 possibly other reactive routing protocols) enabling more economical 1582 notifications to active sources of traffic upon determination that a 1583 route needed to forward such traffic to its destination has become 1584 Broken. 1586 13.3.1. Overview 1588 In many circumstances, there can be several sources of traffic for a 1589 certain destination. Each such source of traffic is known as a 1590 "precursor" for the destination, as well as all upstream routers 1591 between the forwarding AODVv2 router and the traffic source. For 1592 each active destination, an AODVv2 router MAY choose to keep track of 1593 the upstream neighbors that have provided traffic for that 1594 destination; there is no need to keep track of upstream routers any 1595 farther away than the next hop. 1597 Moreover, any particular link to an adjacent AODVv2 router may be a 1598 path component of multiple routes towards various destinations. The 1599 precursors for all destinations using the next hop across any link 1600 are collectively known as the precursors for that next hop. 1602 When an AODVv2 router determines that an active link to one of its 1603 downstream neighbors has broken, the AODVv2 router detecting the 1604 broken link must mark multiple routes as Broken, for each of the 1605 newly unreachable destinations, as described in Section 8.3. Each 1606 route that relies on the newly broken link is no longer valid. 1607 Furthermore, the precursors of the broken link should be notified 1608 (using RERR) about the change in status of their route to a 1609 destination downstream along the broken next hop. 1611 13.3.2. Precursor Notification Details 1613 During normal operation, each AODVv2 router wishing to maintain 1614 precursor lists as described above, maintains a precursor table and 1615 updates the table whenever the node forwards traffic to one of the 1616 destinations in its route table. For each precursor in the precursor 1617 list, a record must be maintained to indicate whether the precursor 1618 has been used for recent traffic (in other words, whether the 1619 precursor is an Active precursor). So, when traffic arrives from a 1620 precursor, the Current_Time is used to mark the time of last use for 1621 the precursor list element associated with that precursor. 1623 When an AODVv2 router detects that a link is broken, then for each 1624 precursor using that next hop, the node MAY notify the precursor 1625 using either unicast or multicast RERR: 1627 unicast RERR to each Active precursor 1628 This option is applicable when there are few Active precursors 1629 compared to the number of neighboring AODVv2 routers. 1630 multicast RERR to RERR_PRECURSORS 1631 RERR_PRECURSORS is, by default, LL-MANET-Routers [RFC5498]. This 1632 option is typically preferable when there are many precursors, 1633 since fewer packet transmissions are required. 1635 Each active upstream neighbor (i.e., precursor) MAY then execute the 1636 same procedure until all active upstream routers have received the 1637 RERR notification. 1639 13.4. Multicast RREP Response to RREQ 1641 The RREQ Target Router (RREP_Gen) MAY, as an alternative to 1642 unicasting a RREP, be configured to distribute routing information 1643 about the route toward the RREQ TargNode (RREP_Gen's client) more 1644 widely. That is, RREP_Gen MAY be configured respond to a route 1645 discovery by generating a RREP, using the procedure in Section 7.4, 1646 but multicasting the RREP to LL-MANET-Routers [RFC5498] (subject to 1647 similar suppression algorithm for redundant RREP multicasts as 1648 described in Section 7.6). The redundant message suppression must 1649 occur at every router handling the multicast RREP. Afterwards, 1650 RREP_Gen processing for the incoming RREQ is complete. 1652 Broadcast RREP response to incoming RREQ was originally specified to 1653 handle unidirectional links, but it is expensive. Due to the 1654 significant overhead, AODVv2 routers MUST NOT use multicast RREP 1655 unless configured to do so by setting the administrative parameter 1656 USE_MULTICAST_RREP. 1658 13.5. RREP_ACK 1660 Instead of relying on existing mechanisms for requesting verification 1661 of link bidirectionality during Route Discovery, RREP_Ack is provided 1662 as an optional feature and modeled on the RREP_Ack message type from 1663 AODV [RFC3561]. 1665 Since the RREP_ACK is simply echoed back to the node from which the 1666 RREP was received, there is no need for any additional RFC 5444 1667 address information (or TLVs). Considerations of packet TTL are as 1668 specified in Section 5.4. An example message format is illustrated 1669 in section Appendix A.4. 1671 13.6. Message Aggregation 1673 The aggregation of multiple messages into a packet is specified in 1674 RFC 5444 [RFC5444]. 1676 Implementations MAY choose to briefly delay transmission of messages 1677 for the purpose of aggregation (into a single packet) or to improve 1678 performance by using jitter [RFC5148]. 1680 13.7. Added Routing Information in RteMsgs 1682 DSR [RFC4728] includes source routes as part of the data of its RREPs 1683 and RREQs. Doing so allows additional topology information to be 1684 multicast along with the RteMsg, and potentially allows updating for 1685 stale routing information at MANET routers along new paths between 1686 source and destination. To maintain this functionality, AODVv2 has 1687 defined a somewhat more general method that enables inclusion of 1688 source routes in RteMsgs. 1690 Including additional routing information in outgoing RREQ or RREP 1691 messages can eliminate some route discovery attempts to the nodes 1692 whose information is included, if AODVv2 routers receiving the 1693 information use it to update their routing tables. 1695 Note that, since the initial merger of DSR with AODV to create this 1696 protocol, further experimentation has shown that including the 1697 additional routing information is not always helpful. Sometimes it 1698 seems to help, and other times it seems to reduce overall 1699 performance. The results depend upon packet size and traffic 1700 patterns. 1702 13.7.1. Including Added Node Information 1704 An AODVv2 router (HandlingRtr) MAY optionally append AddedNode 1705 routing information to a RREQ or RREP. This is controllable by an 1706 option (APPEND_INFORMATION) which SHOULD be administratively 1707 configurable or controlled according to the traffic characteristics 1708 of the network. 1710 The following notation is used to specify the methods for inclusion 1711 of routing information for addtional nodes. 1713 AddedNode 1714 The IP address of an additional node that can be reached via the 1715 AODVv2 router adding this information. Each AddedNode.Address 1716 MUST include its prefix. Each AddedNode.Address MUST also have an 1717 associated Node.SeqNum in the address TLV block. 1718 AddedNode.SeqNum 1719 The Sequence Number associated with the AddedNode's routing 1720 information. 1721 AddedNode.Metric 1722 The cost of the route needed to reach the associated 1723 AddedNode.Address. This field is increased by Cost(L) at each 1724 intermediate AODVv2 router, where 'L' is the incoming link. If, 1725 for the Metric Type of the AddrBlk, it is not known how to compute 1726 Cost(L), the AddedNode.Addr information MUST be deleted from the 1727 AddedNode AddrBlk. 1729 The VALIDITY_TIME of routing information for appended address(es) 1730 MUST be included, to inform routers about when to expire this 1731 information. A typical value for VALIDITY_TIME is 1732 (ACTIVE_INTERVAL+MAX_IDLETIME) - (Current_Time - Route.LastUsed) but 1733 other values (less than MAX_SEQNUM_TIME) MAY be chosen. The 1734 VALIDITY_TIME TLV is defined in [RFC5497]. 1736 SeqNum and Metric AddrTLVs about any appended address(es) MUST be 1737 included. 1739 Routing information about the TargNode MUST NOT be added to the 1740 AddedAddrBlk. Also, duplicate address entries SHOULD NOT be added. 1741 Only the best routing information (Section 6.1) for a particular 1742 address SHOULD be included; if route information is included for a 1743 destination address already in the AddedAddrBlk, the previous 1744 information SHOULD NOT be included in the RteMsg. 1746 13.7.2. Handling Added Node Information 1748 An intermediate node (i.e., HandlingRtr) obeys the following 1749 procedures when processing AddedNode.Address information and other 1750 associated TLVs that are included with a RteMsg. For each AddedNode 1751 (except the TargetNode) in the RteMsg, the AddedNode.Metric 1752 information MUST be increased by Cost(L), where 'L' is the incoming 1753 link. If, for the Metric Type of the AddrBlk, it is not known how to 1754 compute Cost(L), the AddedNode.Addr information MUST be deleted from 1755 the AddedNode AddrBlk. If the resulting Cost of the route to the 1756 AddedNode is greater than MAX_METRIC[i], the AddedNode information is 1757 discarded. If the resulting Distance value for another node is 1758 greater than MAX_METRIC[i], the associated address and its 1759 information are removed from the RteMsg. 1761 After handling the OrigNode's routing information, then each address 1762 that is not the TargetNode MAY be considered for creating and 1763 updating routes. Creating and updating routes to other nodes can 1764 eliminate RREQ for those IP destinations, in the event that data 1765 needs to be forwarded to the IP destination(s) now or in the near 1766 future. 1768 For each of the additional addresses considered, HandlingRtr first 1769 checks that the address is a routable unicast address. If the 1770 address is not a unicast address, then the address and all related 1771 information MUST be removed. 1773 If the routing table does not have a matching route with a known 1774 Route.SeqNum for this additional address using longest-prefix 1775 matching, then a route MAY be created and updated as described in 1776 Section 6.2. If a route table entry exists with a known 1777 Route.SeqNum, the incoming routing information is compared with the 1778 route table entry following the procedure described in Section 6.1. 1779 If the incoming routing information is used, the route table entry 1780 SHOULD be updated as described in Section 6.2. 1782 If the routing information for an AddedNode.Address is not used, then 1783 it is removed from the RteMsg. 1785 If route information is included for a destination address already in 1786 the AddedAddrBlk, the previous information SHOULD NOT be included in 1787 the RteMsg. 1789 14. Administratively Configurable Parameters and Timer Values 1791 AODVv2 uses various configurable parameters of various types: 1793 o Timers 1794 o Protocol constants 1795 o Administrative (functional) controls 1796 o Other administrative parameters and lists 1798 The tables in the following sections show the parameters along their 1799 definitions and default values (if any). 1801 Note: several fields have limited size (bits or bytes). These sizes 1802 and their encoding may place specific limitations on the values that 1803 can be set. For example, is a 8-bit field and 1804 therefore MAX_HOPCOUNT cannot be larger than 255. 1806 14.1. Timers 1808 AODVv2 requires certain timing information to be associated with 1809 route table entries. The default values are as follows, subject to 1810 future experience: 1812 +------------------------------+---------------+ 1813 | Name | Default Value | 1814 +------------------------------+---------------+ 1815 | ACTIVE_INTERVAL | 5 second | 1816 | MAX_IDLETIME | 200 seconds | 1817 | MAX_BLACKLIST_TIME | 200 seconds | 1818 | MAX_SEQNUM_LIFETIME | 300 seconds | 1819 | ROUTE_RREQ_WAIT_TIME | 2 seconds | 1820 | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | 1821 | RREQ_HOLDDOWN_TIME | 10 seconds | 1822 +------------------------------+---------------+ 1824 Table 2: Timing Parameter Values 1826 The above timing parameter values have worked well for small and 1827 medium well-connected networks with moderate topology changes. 1829 The timing parameters SHOULD be administratively configurable for the 1830 network where AODVv2 is used. Ideally, for networks with frequent 1831 topology changes the AODVv2 parameters should be adjusted using 1832 either experimentally determined values or dynamic adaptation. For 1833 example, in networks with infrequent topology changes MAX_IDLETIME 1834 may be set to a much larger value. 1836 14.2. Protocol constants 1838 AODVv2 protocol constants typically do not require changes. The 1839 following table lists these constants, along with their values and a 1840 reference to the specification describing their use. 1842 +----------------------------+------------------+-------------------+ 1843 | Name | Default Value | Description | 1844 +----------------------------+------------------+-------------------+ 1845 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 7.1 | 1846 | MAX_HOPCOUNT | 20 hops | Section 5.6 | 1847 | MAX_METRIC[i] | Specified only | Section 5.6 | 1848 | | for HopCount | | 1849 | MAXTIME | [TBD] | Maximum | 1850 | | | expressible clock | 1851 | | | time | 1852 +----------------------------+------------------+-------------------+ 1854 Table 3: Parameter Values 1856 14.3. Administrative (functional) controls 1858 The following administrative controls may be used to change the 1859 operation of the network, by enabling optional behaviors. These 1860 options are not required for correct routing behavior, although they 1861 may potentially reduce AODVv2 protocol messaging in certain 1862 situations. The default behavior is to NOT enable most such options, 1863 options. Packet buffering is enabled by default. 1865 +-------------------------+-------------------------------+ 1866 | Name | Description | 1867 +-------------------------+-------------------------------+ 1868 | APPEND_INFORMATION | Section 13.7.1 | 1869 | DEFAULT_METRIC_TYPE | 3 {Hop Count (see [RFC6551])} | 1870 | ENABLE_IDLE_UNREACHABLE | Section 8.3.2 | 1871 | ENABLE_IRREP | Section 7.3 | 1872 | USE_MULTICAST_RREP | Section 13.4 | 1873 +-------------------------+-------------------------------+ 1875 Table 4: Administratively Configured Controls 1877 14.4. Other administrative parameters and lists 1879 The following table lists contains AODVv2 parameters which should be 1880 administratively configured for each specific network. 1882 +-----------------------+-----------------------+-----------------+ 1883 | Name | Default Value | Cross Reference | 1884 +-----------------------+-----------------------+-----------------+ 1885 | AODVv2_INTERFACES | | Section 4 | 1886 | BUFFER_SIZE_PACKETS | 2 | Section 7.1 | 1887 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 7.1 | 1888 | CLIENT_ADDRESSES | AODVv2_INTERFACES | Section 5.3 | 1889 | CONTROL_TRAFFIC_LIMIT | TBD [50 packets/sec?] | Section 12 | 1890 +-----------------------+-----------------------+-----------------+ 1892 Table 5: Other Administrative Parameters 1894 15. IANA Considerations 1896 This section specifies several message types, message tlv-types, and 1897 address tlv-types. Also, a new registry of 16-bit alternate metric 1898 types is specified. 1900 15.1. AODVv2 Message Types Specification 1902 +----------------------------------------+------------+ 1903 | Name | Type (TBD) | 1904 +----------------------------------------+------------+ 1905 | Route Request (RREQ) | 10 | 1906 | Route Reply (RREP) | 11 | 1907 | Route Error (RERR) | 12 | 1908 | Route Reply Acknowledgement (RREP_ACK) | 13 | 1909 +----------------------------------------+------------+ 1911 Table 6: AODVv2 Message Types 1913 15.2. Message TLV Type Specification 1915 +--------------------------+-----------+------------+---------------+ 1916 | Name | Type | Length in | Cross | 1917 | | (TBD) | octets | Reference | 1918 +--------------------------+-----------+------------+---------------+ 1919 | Acknowledgment Request | 10 | 0 | Section 5.2 | 1920 | (AckReq) | | | | 1921 | Destination RREP Only | 11 | 0 | Section 7.3 | 1922 | (DestOnly) | | | | 1923 | Packet Source | 12 | 4 or 16 | Section 8.3 | 1924 | (PktSource) | | | | 1925 | Metric Type | 13 | 1 | Section 7.2 | 1926 +--------------------------+-----------+------------+---------------+ 1928 Table 7: Message TLV Types 1930 15.3. Address Block TLV Specification 1932 +---------------------------+---------+---------------+-------------+ 1933 | Name | Type | Length | Value | 1934 | | (TBD) | | | 1935 +---------------------------+---------+---------------+-------------+ 1936 | Metric | 10 | depends on | Section 7.2 | 1937 | | | Metric Type | | 1938 | Sequence Number (SeqNum) | 11 | 2 octets | Section 7.2 | 1939 | Originating Node Sequence | 12 | 2 octets | Section 7.2 | 1940 | Number (OrigSeqNum) | | | | 1941 | Target Node Sequence | 13 | 2 octets | Section 7.2 | 1942 | Number (TargSeqNum) | | | | 1943 | VALIDITY_TIME | 1 | 1 octet | [RFC5497] | 1944 +---------------------------+---------+---------------+-------------+ 1946 Table 8: Address Block TLV (AddrTLV) Types 1948 15.4. Metric Type Number Allocation 1950 Metric types are identified according to the assignments as specified 1951 in [RFC6551]. The metric type of the Hop Count metric is assigned to 1952 be 3, in order to maintain compatibility with that existing table of 1953 values from RFC 6551. Non-addititve metrics are not supported in 1954 this draft. 1956 +-------------+----------+-------------+ 1957 | Name | Type | Metric Size | 1958 +-------------+----------+-------------+ 1959 | Unallocated | 0 -- 2 | TBD | 1960 | Hop Count | 3 - TBD | 1 octet | 1961 | Unallocated | 4 -- 254 | TBD | 1962 | Reserved | 255 | Undefined | 1963 +-------------+----------+-------------+ 1965 Table 9: Metric Types 1967 16. Security Considerations 1969 The objective of the AODVv2 protocol is for each router to 1970 communicate reachability information about addresses for which it is 1971 responsible. Positive routing information (i.e. a route exists) is 1972 distributed via RteMsgs and negative routing information (i.e. a 1973 route does not exist) via RERRs. AODVv2 routers that handle these 1974 messages store the contained information to properly forward data 1975 packets, and they generally provide this information to other AODVv2 1976 routers. 1978 This section does not mandate any specific security measures. 1979 Instead, this section describes various security considerations and 1980 potential avenues to secure AODVv2 routing. 1982 The most important security mechanisms for AODVv2 routing are 1983 integrity/authentication and confidentiality. 1985 In situations where routing information or router identity are 1986 suspect, integrity and authentication techniques SHOULD be applied to 1987 AODVv2 messages. In these situations, routing information that is 1988 distributed over multiple hops SHOULD also verify the integrity and 1989 identity of information based on originator of the routing 1990 information. 1992 A digital signature could be used to identify the source of AODVv2 1993 messages and information, along with its authenticity. A nonce or 1994 timestamp SHOULD also be used to protect against replay attacks. S/ 1995 MIME and OpenPGP are two authentication/integrity protocols that 1996 could be adapted for this purpose. 1998 In situations where confidentiality of AODVv2 messages is important, 1999 cryptographic techniques can be applied. 2001 In certain situations, for example sending a RREP or RERR, an AODVv2 2002 router could include proof that it has previously received valid 2003 routing information to reach the destination, at one point of time in 2004 the past. In situations where routers are suspected of transmitting 2005 maliciously erroneous information, the original routing information 2006 along with its security credentials SHOULD be included. 2008 Note that if multicast is used, any confidentiality and integrity 2009 algorithms used MUST permit multiple receivers to handle the message. 2011 Routing protocols, however, are prime targets for impersonation 2012 attacks. In networks where the node membership is not known, it is 2013 difficult to determine the occurrence of impersonation attacks, and 2014 security prevention techniques are difficult at best. However, when 2015 the network membership is known and there is a danger of such 2016 attacks, AODVv2 messages must be protected by the use of 2017 authentication techniques, such as those involving generation of 2018 unforgeable and cryptographically strong message digests or digital 2019 signatures. While AODVv2 does not place restrictions on the 2020 authentication mechanism used for this purpose, IPsec Authentication 2021 Message (AH) is an appropriate choice for cases where the nodes share 2022 an appropriate security association that enables the use of AH. 2024 In particular, routing messages SHOULD be authenticated to avoid 2025 creation of spurious routes to a destination. Otherwise, an attacker 2026 could masquerade as that destination and maliciously deny service to 2027 the destination and/or maliciously inspect and consume traffic 2028 intended for delivery to the destination. RERR messages SHOULD be 2029 authenticated in order to prevent malicious nodes from disrupting 2030 active routes between communicating nodes. 2032 If the mobile nodes in the ad hoc network have pre-established 2033 security associations, the purposes for which the security 2034 associations are created should include that of authorizing the 2035 processing of AODVv2 control packets. Given this understanding, the 2036 mobile nodes should be able to use the same authentication mechanisms 2037 based on their IP addresses as they would have used otherwise. 2039 If the mobile nodes in the ad hoc network have pre-established 2040 security associations, the purposes for which the security 2041 associations Most AODVv2 messages are transmitted to the multicast 2042 address LL-MANET-Routers [RFC5498]. It is therefore required for 2043 security that AODVv2 neighbors exchange security information that can 2044 be used to insert an ICV [RFC6621] into the AODVv2 message block 2045 [RFC5444]. This enables hop-by-hop security, which is proper for 2046 these message types that may have mutable fields. For destination- 2047 only RREP discovery procedures, AODVv2 routers that share a security 2048 association SHOULD use the appropriate mechanisms as specified in RFC 2049 6621. The establishment of these security associations is out of 2050 scope for this document. 2052 17. Acknowledgments 2054 AODVv2 is a descendant of the design of previous MANET on-demand 2055 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 2056 previous MANET on-demand protocols stem from research and 2057 implementation experiences. Thanks to Elizabeth Belding-Royer for 2058 her long time authorship of AODV. Additional thanks to Luke Klein- 2059 Berndt, Pedro Ruiz, Fransisco Ros, Henning Rogge, Koojana 2060 Kuladinithi, Ramon Caceres, Thomas Clausen, Christopher Dearlove, 2061 Seung Yi, Romain Thouvenin, Tronje Krop, Henner Jakob, Alexandru 2062 Petrescu, Christoph Sommer, Cong Yuan, Lars Kristensen, and Derek 2063 Atkins for reviewing of AODVv2, as well as several specification 2064 suggestions. 2066 This revision of AODVv2 separates the minimal base specification from 2067 other optional features to expedite the process of assuring 2068 compatibility with the existing LOADng specification 2069 [I-D.clausen-lln-loadng] (minimal reactive routing protocol 2070 specification). Thanks are due to A. Colin de Verdiere, J. Yi, A. 2071 Niktash, Y. Igarashi, Satoh. H., and U. Herberg for their 2072 development of LOADng and sharing details for assuring 2073 appropriateness of AODVv2 for their application. 2075 18. References 2077 18.1. Normative References 2079 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 2080 1812, June 1995. 2082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2083 Requirement Levels", BCP 14, RFC 2119, March 1997. 2085 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 2086 Pignataro, "The Generalized TTL Security Mechanism 2087 (GTSM)", RFC 5082, October 2007. 2089 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 2090 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 2091 Format", RFC 5444, February 2009. 2093 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 2094 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2095 2009. 2097 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 2098 (MANET) Protocols", RFC 5498, March 2009. 2100 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 2101 Barthel, "Routing Metrics Used for Path Calculation in 2102 Low-Power and Lossy Networks", RFC 6551, March 2012. 2104 18.2. Informative References 2106 [I-D.clausen-lln-loadng] 2107 Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 2108 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 2109 Dean, "The Lightweight On-demand Ad hoc Distance-vector 2110 Routing Protocol - Next Generation (LOADng)", draft- 2111 clausen-lln-loadng-09 (work in progress), July 2013. 2113 [I-D.perkins-irrep] 2114 Perkins, C. and I. Chakeres, "Intermediate RREP for 2115 dynamic MANET On-demand (AODVv2) Routing", draft-perkins- 2116 irrep-02 (work in progress), November 2012. 2118 [Perkins99] 2119 Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand 2120 Distance Vector (AODV) Routing", Proceedings of the 2nd 2121 IEEE Workshop on Mobile Computing Systems and 2122 Applications, New Orleans, LA, pp. 90-100, February 1999. 2124 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 2126 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 2127 (MANET): Routing Protocol Performance Issues and 2128 Evaluation Considerations", RFC 2501, January 1999. 2130 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 2131 Demand Distance Vector (AODV) Routing", RFC 3561, July 2132 2003. 2134 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2135 Addresses", RFC 4193, October 2005. 2137 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 2138 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 2139 IPv4", RFC 4728, February 2007. 2141 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2142 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2143 September 2007. 2145 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2146 Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 2147 5148, February 2008. 2149 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2150 for IPv6", RFC 5340, July 2008. 2152 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 2153 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 2154 RFC 6130, April 2011. 2156 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2157 Instance Extensions", RFC 6549, March 2012. 2159 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 2160 May 2012. 2162 Appendix A. Example RFC 5444-compliant packet formats 2164 The following three subsections show example RFC 5444-compliant 2165 packets for AODVv2 message types RREQ, RREP, and RERR. These 2166 proposed message formats are designed based on expected savings from 2167 IPv6 addressable MANET nodes, and a layout for the Address TLVs that 2168 may be viewed as natural, even if perhaps not the absolute most 2169 compact possible encoding. 2171 For RteMsgs, the msg-hdr fields are followed by at least one and 2172 optionally two Address Blocks. The first AddrBlk contains OrigNode 2173 and TargNode. For each AddrBlk, there must be AddrTLVs of type 2174 Seqnum and of type Metric. 2176 In addition to the Seqnum TLV, there MUST be an AddrTLV of type 2177 Metric. The msg-hop-count counts the number of hops followed by the 2178 RteMsg from point of generation to the current intermediate AODVv2 2179 router handling the RteMsg. Alternate metrics are enabled by the 2180 inclusion of the MetricType Message TLV. When there is no such 2181 MetricType Message TLV present, then the Metric AddrTLV measures 2182 HopCount. The Metric AddrTLV also provides a way for the AODV router 2183 generating the RREQ or RREP to supply an initial nonzero cost for the 2184 route to its client node (OrigNode or TargNode, for RREQ or RREP 2185 respectively). 2187 AddedNode information MAY be included in a RteMsg by adding a second 2188 AddrBlk. Both Metric AddrTLVs use the same Metric Type. 2190 In all cases, the length of an address (32 bits for IPv4 and 128 bits 2191 for IPv6) inside an AODVv2 message is indicated by the msg-addr- 2192 length (MAL) in the msg-header, as specified in [RFC5444]. 2194 A.1. RREQ Message Format 2196 Figure 4 illustrates a packet format for an example RREQ message. 2198 0 1 2 3 2199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | PV=0 | PF=0 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=28 | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | msg-size=28 | msg-hop-limit | msg.tlvs-length=0 | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | addr.tlvs-length=11 | type=SeqNum |0|1|0|1|0|0|Rsv| 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | type=Metric |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | OrigNodeHopCt | 2216 +-+-+-+-+-+-+-+-+ 2218 Figure 4: Example IPv4 RREQ, with SeqNum and Metric AddrTLVs 2220 The fields in Figure 4 are to be interpreted as follows: 2222 o PV=0 (Packet Header Version = 0) 2223 o PF=0 (Packet Flags = 0) 2224 o msg-type=RREQ (first [and only] message is of type RREQ) 2225 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2226 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2227 o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2228 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2229 o msg.tlvs-length=0 (no Message TLVs) 2230 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2231 o AddrBlk flags: 2233 * bit 0 (ahashead): 1 2234 * bit 1 (ahasfulltail): 0 2235 * bit 2 (ahaszerotail): 0 2236 * bit 3 (ahassingleprelen): 0 2237 * bit 4 (ahasmultiprelen): 0 2238 * bits 5-7: RESERVED 2239 o head-length=3 (length of head part of each address is 3 octets) 2240 o Head (3 initial bytes for both Originating & Target addresses) 2241 o Orig.Tail (4th byte of Originating Node IP address) 2242 o Target.Tail (4th byte of Target Node IP address) 2243 o addr.tlvs-length=11 (length in bytes for SeqNum and Metric TLVs 2244 o type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets) 2245 o AddrTLV flags for SeqNumTLV: 2247 * bit 0 (thastypeext): 0 2248 * bit 1 (thassingleindex): 1 2249 * bit 2 (thasmultiindex): 0 2250 * bit 3 (thasvalue): 1 2251 * bit 4 (thasextlen): 0 2252 * bit 5 (tismultivalue): 0 2253 * bits 6-7: RESERVED 2254 o Index-start=0 (SeqNum TLV values start at index 0) 2255 o tlv-length=2 (so there is only one TLV value, [1 = 2/2]) 2256 o Orig.Node Sequence # (first [and only] TLV value for SeqNum TLVs 2257 o type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet) 2258 o AddrTLV flags for MetricTLV: 2260 * bit 0 (thastypeext): 0 2261 * bit 1 (thassingleindex): 1 2262 * bit 2 (thasmultiindex): 0 2263 * bit 3 (thasvalue): 1 2264 * bit 4 (thasextlen): 0 2265 * bit 5 (tismultivalue): 0 2266 * bits 6-7: RESERVED 2267 o Index-start=0 (Metric TLV values start at index 0) 2268 o tlv-length=1 (so there is only one TLV value, [1 = 1/1]) 2269 o OrigNodeHopCt (first [and only] TLV value for Metric TLVs) 2271 A.2. RREP Message Format 2273 Figure 5 illustrates a packet format for an example RREP message. 2275 0 1 2 3 2276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | PV=0 | PF=0 | msg-type=RREP | MF=4 | MAL=3 | msg-size=30 | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | msg-size=30 | msg-hop-limit | msg.tlvs-length=0 | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | addr.tlvs-length=13 | type=SeqNum |0|1|0|1|0|0|Rsv| 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Target.Node Sequence # | type=Metric |0|1|0|1|0|0|Rsv| 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | Index-start=1 | tlv-length=1 | TargNodeHopCt | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 Figure 5: Example IPv4 RREP, with 2 SeqNums and 1 Metric 2297 The fields in Figure 5 are to be interpreted as follows: 2299 o PV=0 (Packet Header Version = 0) 2300 o PF=0 (Packet Flags = 0) 2301 o msg-type=RREP (first [and only] message is of type RREP) 2302 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2303 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2304 o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2305 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2306 o msg.tlvs-length=0 (no Message TLVs) 2307 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2308 o AddrBlk flags: 2310 * bit 0 (ahashead): 1 2311 * bit 1 (ahasfulltail): 0 2312 * bit 2 (ahaszerotail): 0 2313 * bit 3 (ahassingleprelen): 0 2314 * bit 4 (ahasmultiprelen): 0 2315 * bits 5-7: RESERVED 2316 o head-length=3 (length of head part of each address is 3 octets) 2317 o Head (3 initial bytes for both Originating & Target addresses) 2318 o Orig.Tail (4th byte of Originating Node IP address) 2319 o Target.Tail (4th byte of Target Node IP address) 2320 o addr.tlvs-length=13 (length in bytes for SeqNum and Metric TLVs 2321 o type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets) 2322 o AddrTLV flags for SeqNumTLV: 2324 * bit 0 (thastypeext): 0 2325 * bit 1 (thassingleindex): 1 2326 * bit 2 (thasmultiindex): 0 2327 * bit 3 (thasvalue): 1 2328 * bit 4 (thasextlen): 0 2329 * bit 5 (tismultivalue): 0 2330 * bits 6-7: RESERVED 2331 o Index-start=0 (SeqNum TLV values start at index 0) 2332 o tlv-length=4 (so there is are two TLV values, [2 = 4/2]) 2333 o Orig.Node Sequence # (first of two TLV values for SeqNum TLVs 2334 o Targ.Node Sequence # (second of two TLV values for SeqNum TLVs 2335 o type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet) 2336 o AddrTLV flags for MetricTLV [01010000, same as for SeqNumTLV] 2337 o Index-start=1 (Metric TLV values start at index 1) 2338 o tlv-length=1 (so there is only one TLV value, [1 = 1/1]) 2339 o TargNodeHopCt (first [and only] TLV value for Metric TLVs) 2341 A.3. RERR Message Format 2343 Figure 6 illustrates a packet format for an example RERR message. 2345 0 1 2 3 2346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | PV=0 | PF=0 | msg-type=RERR | MF=4 | MAL=3 | msg-size=24 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | msg-size=24 | msg-hop-limit | msg.tlvs-length=0 | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 | Head (3 bytes)| 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | addr.tlvs-length=7 | type=SeqNum |0|0|1|1|0|1|Rsv| 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | tlv-length=4 | Dest_1 Sequence # | Dest_2 Seq# | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | Dest_2 Seq# | 2361 +-+-+-+-+-+-+-+-+ 2363 Figure 6: Example IPv4 RERR with Two Unreachable Nodes 2365 The fields in Figure 6 are to be interpreted as follows: 2367 o PV=0 (Packet Header Version = 0) 2368 o PF=0 (Packet Flags = 0) 2369 o msg-type=RERR (first [and only] message is of type RERR) 2370 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2371 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2372 o msg-size=24 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2373 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2374 o msg.tlvs-length=0 (no Message TLVs) 2375 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2376 o AddrBlk flags == 10000000 [same as RREQ and RREP AddrBlk examples] 2377 o head-length=3 (length of head part of each address is 3 octets) 2378 o Head (3 initial bytes for both Unreachable Nodes, Dest_1 and 2379 Dest_2) 2380 o Dest_1.Tail (4th byte of Dest_1 IP address) 2381 o Dest_2.Tail (4th byte of Dest_2 IP address) 2382 o addr.tlvs-length=7 (length in bytes for SeqNum TLV 2383 o type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each) 2384 o AddrTLV flags for SeqNumTLV: 2386 * bit 0 (thastypeext): 0 2387 * bit 1 (thassingleindex): 0 2388 * bit 2 (thasmultiindex): 1 2389 * bit 3 (thasvalue): 1 2390 * bit 4 (thasextlen): 0 2391 * bit 5 (tismultivalue): 1 2392 * bits 6-7: RESERVED 2393 o Index-start=0 (SeqNum TLV values start at index 0) 2394 o tlv-length=4 (so there is are two TLV values, [2 = 4/2]) 2395 o Dest_1 Sequence # (first of two TLV values for SeqNum TLVs) 2396 o Dest_2 Sequence # (second of two TLV values for SeqNum TLVs) 2398 A.4. RREP_ACK Message Format 2400 The figure below illustrates a packet format for an example RREP_ACK 2401 message. 2403 0 1 2 3 2404 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 | PV=0 | PF=0 |msgtype=RREPAck| MF=0 | MAL=3 | msg-size=4 | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | msg-size=4 | 2409 +-+-+-+-+-+-+-+-+ 2411 Figure 7: Example IPv4 RREP_ACK 2413 Appendix B. Changes since revision ...-25.txt 2415 The main goals of this revision are to improve readability and to 2416 introduce a protocol update which enables order-independent listing 2417 of the Originating Node and Target Node (OrigNode and TargNode) in 2418 the AddrBlk of RREQ and RREP messages. 2420 o Added two new AddrTLV types, OrigSeqNum and TargSeqNum. Changed 2421 processing description to identify OrigNdx and TargNdx, instead of 2422 implicitly assuming OrigNdx = 1 and TargNdx = 2 as in previous 2423 versions of the specification. See Section 7.2, Section 7.3, 2424 Section 7.4, Section 7.5, and Section 15.3. 2425 o Reworded initial paragraph of Section 6 to eliminate the use of 2426 terminology "DestIP", in order to reduce possible confusion with 2427 the meaning of the term "TargNode", etc. 2428 o Moved description of reasons why a node might not elect to 2429 retransmit a RteMsg from Section 7.5 to section Section 7.5.1. If 2430 an AODVv2 router would elect to not send an RREP message, it 2431 should not send the RREQ message which might elicit that RREP 2432 message. Otherwise, valid routes will go undiscovered. 2433 o Eliminated use of terminology for "Msg." to indicate fields in the 2434 RFC 5444 Message Header. 2435 o Replaced instances of "useless" by "redundant". Made numerous 2436 other editorial changes and corrections. 2438 o Changed membership of editorial team. 2439 o Formally changed document name to "aodvv2" instead of "dymo". 2441 Appendix C. Changes since revision ...-24.txt 2443 The main goals of this revision are to improve readability and to 2444 introduce a protocol update to handle suppression of unnecessary 2445 multicast RREQs and certain other messages. 2447 o Specified operations for maintenance and use of RREQ Table (see 2448 Section 5.7, Section 7.6). 2449 o Inserted explanations for example packet formats in appendix (see 2450 Appendix A). 2451 o Eliminated OwnSeqNum, RERR_dest, and various other abbreviations, 2452 reworded relevant text. 2453 o Reorganized Section 14 into four sections so that the various 2454 parameters are grouped more naturally into tables of similar 2455 types. 2456 o Replaced parameter descriptions in the tables in Section 14, with 2457 cross references to the parameter descriptions in the body of the 2458 specification. 2459 o Created parameters and administrative controls ENABLE_IRREP and 2460 MAX_BLACKLIST_TIME which had been alluded to in the body of the 2461 specification. 2462 o Corrected metric comparison formulae to include cost of incoming 2463 link. 2464 o Renamed Unicast Response Request MsgTLV to be Acknowledgment 2465 Request. 2466 o Clarified and mandates and 2467 initialization. 2468 o Reformatted various tables to improve readability. 2469 o Changed some descriptions to apply to "Incoming" messages instead 2470 of "Outgoing" messages, enabling simpler specification. 2471 o Many other minor editorial improvements to improve readability and 2472 eliminate possibly ambiguities. 2474 Appendix D. Changes between revisions ...-21.txt and ...-24.txt 2476 The revisions of this document that were numbered 22 and 23 were 2477 produced without sufficient time for preparation, and suffered from 2478 numerous editorial errors. Therefore, this list of changes is 2479 enumerated based on differences between this revision (24) and 2480 revision 21. 2482 o Alternate metrics enabled: 2484 * New section added to describe general design approach. 2485 * Abstract functions "Cost()" and "LoopFree()" defined. 2487 * MAX_HOPCOUNT typically replaced by MAX_METRIC. 2488 * DEFAULT_METRIC_TYPE parameter defined, defaulting to HopCount. 2489 * MetricType Message TLV defined. 2490 * Metric Address TLV defined. 2491 o Many changes for RFC 5444 compliance 2492 o New section added for "Notational Conventions" (see Table 1). 2493 Many changes to improve readability and accuracy (e.g., eliminate 2494 use of "Flooding", "ThisNode", ...). 2495 o Reorganized and simplified route lifetime management (see 2496 Section 5.1). 2497 o Reorganized document structure, combining closely related small 2498 sections and eliminating top-level "Detailed ..." section. 2500 * RREQ and RREP specification sections coalesced. 2501 * RERR specification sections coalesced. 2502 * Eliminated resulting duplicated specification. 2503 * New section added for "Notational Conventions". 2504 o Internet-Facing AODVv2 router renamed to be IAR 2505 o "Optional Features" section (see Section 13) created to contain 2506 features not required within base specification, including: 2508 * Adding RREP-ACK message type instead of relying on reception of 2509 arbitrary packets as sufficient response to establish 2510 bidirectionality. 2511 * Expanding Rings Multicast 2512 * Intermediate RREPs (iRREPs): Without iRREP, only the 2513 destination can respond to a RREQ. 2514 * Precursor lists. 2515 * Reporting Multiple Unreachable Nodes. An RERR message can 2516 carry more than one Unreachable Destination node for cases when 2517 a single link breakage causes multiple destinations to become 2518 unreachable from an intermediate router. 2519 * Message Aggregation. 2520 * Inclusion of Added Routing Information. 2521 o Sequence number MUST be incremented after generating any RteMsg. 2522 o Resulting simplifications for accepting route updates in RteMsgs. 2523 o Sequence number MUST (instead of SHOULD) be set to 1 after 2524 rollover. 2525 o AODVv2 routers MUST (instead of SHOULD) only handle AODVv2 2526 messages from adjacent routers. 2527 o Clarification that Added Routing information in RteMsgs is 2528 optional (MAY) to use. 2529 o Clarification that if Added Routing information in RteMsgs is 2530 used, then the Route Table Entry SHOULD be updated using normal 2531 procedures as described in Section 6.2. 2532 o Clarification in Section 7.1 that nodes may be configured to 2533 buffer zero packets. 2535 o Clarification in Section 7.1 that buffered packets MUST be dropped 2536 if route discovery fails. 2537 o In Section 8.2, relax mandate for monitoring connectivity to next- 2538 hop AODVv2 neighbors (from MUST to SHOULD), in order to allow for 2539 minimal implementations 2540 o Remove Route.Forwarding flag; identical to "NOT" Route.Broken. 2541 o Routing Messages MUST be originated with the set 2542 to MAX_HOPCOUNT. 2543 o Maximum hop count set to MAX_HOPCOUNT, and 255 is reserved for 2544 "unknown". Since the current draft only uses hop-count as 2545 distance, this is also the current maximum distance. 2547 Appendix E. Shifting Network Prefix Advertisement Between AODVv2 2548 Routers 2550 Only one AODVv2 router within a MANET SHOULD be responsible for a 2551 particular address at any time. If two AODVv2 routers dynamically 2552 shift the advertisement of a network prefix, correct AODVv2 routing 2553 behavior must be observed. The AODVv2 router adding the new network 2554 prefix must wait for any existing routing information about this 2555 network prefix to be purged from the network. Therefore, it must 2556 wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous AODVv2 2557 router for this address stopped advertising routing information on 2558 its behalf. 2560 Authors' Addresses 2562 Charles E. Perkins 2563 Futurewei Inc. 2564 2330 Central Expressway 2565 Santa Clara, CA 95050 2566 USA 2568 Phone: +1-408-330-5305 2569 Email: charliep@computer.org 2571 Stan Ratliff 2572 Cisco 2573 170 West Tasman Drive 2574 San Jose, CA 95134 2575 USA 2577 Email: sratliff@cisco.com 2578 John Dowdell 2579 Cassidian 2580 Celtic Springs 2581 Newport, Wales NP10 8FZ 2582 United Kingdom 2584 Email: John.Dowdell@Cassidian.com