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