idnits 2.17.1 draft-ietf-roll-aodv-rpl-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL C.E. Perkins 3 Internet-Draft Lupin Lodge 4 Intended status: Standards Track S.V.R.Anand 5 Expires: 8 September 2022 Indian Institute of Science 6 S. Anamalamudi 7 SRM University-AP 8 B. Liu 9 Huawei Technologies 10 7 March 2022 12 Supporting Asymmetric Links in Low Power Networks: AODV-RPL 13 draft-ietf-roll-aodv-rpl-13 15 Abstract 17 Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) 18 traffic flows is a desirable feature in Low power and Lossy Networks 19 (LLNs). For that purpose, this document specifies a reactive P2P 20 route discovery mechanism for both hop-by-hop routing and source 21 routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL 22 protocol (AODV-RPL). Paired Instances are used to construct 23 directional paths, for cases where there are asymmetric links between 24 source and target nodes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 8 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 6 62 4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 7 63 4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 7 64 4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 9 65 4.3. AODV-RPL Target Option . . . . . . . . . . . . . . . . . 10 66 5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 12 67 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 14 68 6.1. Route Request Generation . . . . . . . . . . . . . . . . 14 69 6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14 70 6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 15 71 6.2.2. Step 2: TargNode and Intermediate Router 72 determination . . . . . . . . . . . . . . . . . . . . 15 73 6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 16 74 6.2.4. Step 4: Symmetric Route Processing at an Intermediate 75 Router . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.2.5. Step 5: RREQ propagation at an Intermediate Router . 17 77 6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 17 78 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 17 79 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 18 80 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 18 81 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 18 82 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 19 83 6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 19 84 6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 19 85 6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 20 86 6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 20 87 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 21 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 12.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Appendix A. Example: Using ETX/RSSI Values to determine value of S 97 bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 27 99 B.1. Changes from version 12 to version 13 . . . . . . . . . . 27 100 B.2. Changes from version 11 to version 12 . . . . . . . . . . 28 101 B.3. Changes from version 10 to version 11 . . . . . . . . . . 28 102 B.4. Changes from version 09 to version 10 . . . . . . . . . . 29 103 B.5. Changes from version 08 to version 09 . . . . . . . . . . 30 104 B.6. Changes from version 07 to version 08 . . . . . . . . . . 30 105 B.7. Changes from version 06 to version 07 . . . . . . . . . . 31 106 B.8. Changes from version 05 to version 06 . . . . . . . . . . 31 107 B.9. Changes from version 04 to version 05 . . . . . . . . . . 31 108 B.10. Changes from version 03 to version 04 . . . . . . . . . . 32 109 B.11. Changes from version 02 to version 03 . . . . . . . . . . 32 110 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 32 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 113 1. Introduction 115 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is 116 an IPv6 distance vector routing protocol designed to support multiple 117 traffic flows through a root-based Destination-Oriented Directed 118 Acyclic Graph (DODAG). Typically, a router does not have routing 119 information for most other routers. Consequently, for traffic 120 between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic) 121 data packets either have to traverse the root in non-storing mode, or 122 traverse a common ancestor in storing mode. Such P2P traffic is 123 thereby likely to traverse longer routes and may suffer severe 124 congestion near the root (for more information see [RFC6997], 125 [RFC6998]). The network environment that is considered in this 126 document is assumed to be the same as described in Section 1 of 127 [RFC6550]. 129 The route discovery process in AODV-RPL is modeled on the analogous 130 procedure specified in AODV [RFC3561]. The on-demand nature of AODV 131 route discovery is natural for the needs of peer-to-peer routing in 132 RPL-based LLNs. AODV terminology has been adapted for use with AODV- 133 RPL messages, namely RREQ for Route Request, and RREP for Route 134 Reply. AODV-RPL currently omits some features compared to AODV -- in 135 particular, flagging Route Errors, "blacklisting" unidirectional 136 links ([RFC3561]), multihoming, and handling unnumbered interfaces. 138 AODV-RPL reuses and extends the core RPL functionality to support 139 routes with bidirectional asymmetric links. It retains RPL's DODAG 140 formation, RPL Instance and the associated Objective Function 141 (defined in [RFC6551]), trickle timers, and support for storing and 142 non-storing modes. AODV-RPL adds basic messages RREQ and RREP as 143 part of RPL DODAG Information Object (DIO) control message, which go 144 in separate (paired) RPL instances. AODV-RPL does not utilize the 145 Destination Advertisement Object (DAO) control message of RPL. AODV- 146 RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with 147 three new Options for the DIO message, dedicated to discover P2P 148 routes. These P2P routes may differ from routes discoverable by 149 native RPL. Since AODV-RPL uses newly defined Options, there is no 150 conflict with P2P-RPL [RFC6997], a previous document using the same 151 MOP. AODV-RPL can be operated whether or not P2P-RPL or native RPL 152 is running otherwise. For many networks AODV-RPL could be a 153 replacement for RPL, since it can find better routes at very moderate 154 extra cost. Consequently, it is unlikely that RPL would be needed in 155 a network that is running AODV-RPL, even though it would be possible 156 to run both protocols at the same time. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 AODV-RPL reuses names for messages and data structures, including 167 Rank, DODAG and DODAGID, as defined in RPL [RFC6550]. 169 AODV 170 Ad Hoc On-demand Distance Vector Routing [RFC3561]. 172 Asymmetric Route 173 The route from the OrigNode to the TargNode can traverse different 174 nodes than the route from the TargNode to the OrigNode. An 175 asymmetric route may result from the asymmetry of links, such that 176 only one direction of the series of links satisfies the Objective 177 Function during route discovery. 179 Bi-directional Asymmetric Link 180 A link that can be used in both directions but with different link 181 characteristics. 183 DIO 184 DODAG Information Object 186 DODAG RREQ-Instance (or simply RREQ-Instance) 187 RPL Instance built using the DIO with RREQ option; used for 188 transmission of control messages from OrigNode to TargNode, thus 189 enabling data transmission from TargNode to OrigNode. 191 DODAG RREP-Instance (or simply RREP-Instance) 192 RPL Instance built using the DIO with RREP option; used for 193 transmission of control messages from TargNode to OrigNode thus 194 enabling data transmission from OrigNode to TargNode. 196 Downward Direction 197 The direction from the OrigNode to the TargNode. 199 Downward Route 200 A route in the downward direction. 202 hop-by-hop routing 203 Routing when each router stores routing information about the next 204 hop. 206 on-demand routing 207 Routing in which a route is established only when needed. 209 OrigNode 210 The IPv6 router (Originating Node) initiating the AODV-RPL route 211 discovery to obtain a route to TargNode. 213 Paired DODAGs 214 Two DODAGs for a single route discovery process between OrigNode 215 and TargNode. 217 P2P 218 Peer-to-Peer -- in other words, not constrained a priori to 219 traverse a common ancestor. 221 reactive routing 222 Same as "on-demand" routing. 224 RREQ-DIO message 225 A DIO message containing the RREQ option. The RPLInstanceID in 226 RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO 227 message has a secure variant as noted in [RFC6550]. 229 RREQ-InstanceID 230 The RPLInstanceID for the RREQ-Instance. This term is used to 231 indicate the value of the RPLInstanceID as provided by OrigNode in 232 the RREQ message. The RPLInstanceID in the RREP message along 233 with the Delta value determines the associated RREQ-InstanceID. 235 RREP-DIO message 236 A DIO message containing the RREP option. OrigNode pairs the 237 RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO 238 message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. 239 The RREP-DIO message has a secure variant as noted in [RFC6550]. 241 Source routing 242 A mechanism by which the source supplies the complete route 243 towards the target node along with each data packet [RFC6550]. 245 Symmetric route 246 The upstream and downstream routes traverse the same routers and 247 over the same links. 249 TargNode 250 The IPv6 router (Target Node) for which OrigNode requires a route 251 and initiates Route Discovery within the LLN network. 253 Upward Direction 254 The direction from the TargNode to the OrigNode. 256 Upward Route 257 A route in the upward direction. 259 ART option 260 AODV-RPL Target option: a target option defined in this document. 262 3. Overview of AODV-RPL 264 With AODV-RPL, routes from OrigNode to TargNode within the LLN 265 network are established "on-demand". In other words, the route 266 discovery mechanism in AODV-RPL is invoked reactively when OrigNode 267 has data for delivery to the TargNode but existing routes do not 268 satisfy the application's requirements. AODV-RPL works without 269 requiring the use of RPL or any other routing protocol. 271 The routes discovered by AODV-RPL are not constrained to traverse a 272 common ancestor. AODV-RPL can enable asymmetric communication paths 273 in networks with bidirectional asymmetric links. For this purpose, 274 AODV-RPL enables discovery of two routes: namely, one from OrigNode 275 to TargNode, and another from TargNode to OrigNode. AODV-RPL also 276 enables discovery of symmetric routes along Paired DODAGs, when 277 symmetric routes are possible (see Section 5). 279 In AODV-RPL, routes are discovered by first forming a temporary DAG 280 rooted at the OrigNode. Paired DODAGs (Instances) are constructed 281 during route formation between the OrigNode and TargNode. The RREQ- 282 Instance is formed by route control messages from OrigNode to 283 TargNode whereas the RREP-Instance is formed by route control 284 messages from TargNode to OrigNode. Intermediate routers join the 285 DODAGs based on the Rank [RFC6550] as calculated from the DIO 286 message. Henceforth in this document, "RREQ-DIO message" means the 287 DIO message from OrigNode toward TargNode, containing the RREQ option 288 as specified in Section 4.1. Similarly, "RREP-DIO message" means the 289 DIO message from TargNode toward OrigNode, containing the RREP option 290 as specified in Section 4.2. The route discovered in the RREQ- 291 Instance is used for transmitting data from TargNode to OrigNode, and 292 the route discovered in RREP-Instance is used for transmitting data 293 from OrigNode to TargNode. 295 4. AODV-RPL DIO Options 297 4.1. AODV-RPL RREQ Option 299 OrigNode selects one of its IPv6 addresses and sets it in the DODAGID 300 field of the RREQ-DIO message. Exactly one RREQ option MUST be 301 present in a RREQ-DIO message, otherwise the message MUST be dropped. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Option Type | Option Length |S|H|X| Compr | L | RankLimit | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Orig SeqNo | | 309 +-+-+-+-+-+-+-+-+ | 310 | | 311 | | 312 | Address Vector (Optional, Variable Length) | 313 | | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 1: Format for AODV-RPL RREQ Option 319 OrigNode supplies the following information in the RREQ option: 321 Option Type 322 TBD2 324 Option Length 325 The length of the option in octets, excluding the Type and Length 326 fields. Variable due to the presence of the address vector and 327 the number of octets elided according to the Compr value. 329 S 330 Symmetric bit indicating a symmetric route from the OrigNode to 331 the router transmitting this RREQ-DIO. See Section 5. 333 H 334 Set to one for a hop-by-hop route. Set to zero for a source 335 route. This flag controls both the downstream route and upstream 336 route. 338 X 339 Reserved; MUST be initialized to zero and ignored upon reception. 341 Compr 342 4-bit unsigned integer. When Compr is nonzero, exactly that 343 number of prefix octets MUST be elided from each address before 344 storing it in the Address Vector. The octets elided are shared 345 with the IPv6 address in the DODAGID. This field is only used in 346 source routing mode (H=0). In hop-by-hop mode (H=1), this field 347 MUST be set to zero and ignored upon reception. 349 L 350 2-bit unsigned integer determining the length of time that a node 351 is able to belong to the RREQ-Instance (a temporary DAG including 352 the OrigNode and the TargNode). Once the time is reached, a node 353 MUST leave the RREQ-Instance and stop sending or receiving any 354 more DIOs for the RREQ-Instance. This naturally depends on the 355 node's ability to keep track of time. Once a node leaves an RREQ- 356 Instance, it MUST NOT rejoin the same RREQ-Instance. L is 357 independent from the route lifetime, which is defined in the DODAG 358 configuration option. 360 * 0x00: No time limit imposed. 361 * 0x01: 16 seconds 362 * 0x02: 64 seconds 363 * 0x03: 256 seconds 365 RankLimit 366 This field indicates the upper limit on the integer portion of the 367 Rank (calculated using the DAGRank() macro defined in [RFC6550]). 368 A value of 0 in this field indicates the limit is infinity. 370 Orig SeqNo 371 Sequence Number of OrigNode. See Section 6.1. 373 Address Vector 374 A vector of IPv6 addresses representing the route that the RREQ- 375 DIO has passed. It is only present when the H bit is set to 0. 376 The prefix of each address is elided according to the Compr field. 378 TargNode can join the RREQ instance at a Rank whose integer portion 379 is less than or equal to the RankLimit. Any other node MUST NOT join 380 a RREQ instance if its own Rank would be equal to or higher than 381 RankLimit. A router MUST discard a received RREQ if the integer part 382 of the advertised Rank equals or exceeds the RankLimit. 384 4.2. AODV-RPL RREP Option 386 TargNode sets one of its IPv6 addresses in the DODAGID field of the 387 RREP-DIO message. Exactly one RREP option MUST be present in a RREP- 388 DIO message, otherwise the message MUST be dropped. TargNode 389 supplies the following information in the RREP option: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Option Type | Option Length |G|H|X| Compr | L | RankLimit | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Delta |X X| | 397 +-+-+-+-+-+-+-+-+ | 398 | | 399 | | 400 | Address Vector (Optional, Variable Length) | 401 . . 402 . . 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 2: Format for AODV-RPL RREP option 407 Option Type 408 TBD3 410 Option Length 411 The length of the option in octets, excluding the Type and Length 412 fields. Variable due to the presence of the address vector and 413 the number of octets elided according to the Compr value. 415 G 416 Gratuitous route (see Section 7). 418 H 419 The H bit in the RREP option MUST be set to be the same as the H 420 bit in RREQ option. It requests either source routing (H=0) or 421 hop-by-hop (H=1) for the downstream route. 423 X 424 Reserved; MUST be initialized to zero and ignored upon reception. 426 Compr 427 4-bit unsigned integer. Same definition as in RREQ option. 429 L 430 2-bit unsigned integer defined as in RREQ option. The lifetime of 431 the RREP-Instance MUST be shorter than the lifetime of the RREQ- 432 Instance to which it is paired. 434 RankLimit 435 Similarly to RankLimit in the RREQ message, this field indicates 436 the upper limit on the integer portion of the Rank. A value of 0 437 in this field indicates the limit is infinity. 439 Delta 440 6-bit unsigned integer. This field is used to recover the RREQ- 441 InstanceID (see Section 6.3.3); 0 indicates that the RREQ- 442 InstanceID has the same value as the RPLInstanceID of the RREP 443 message. 445 X X 446 Reserved; MUST be initialized to zero and ignored upon reception. 448 Address Vector 449 Only present when the H bit is set to 0. For an asymmetric route, 450 the Address Vector represents the IPv6 addresses of the path 451 through the network the RREP-DIO has passed. For a symmetric 452 route, it is the Address Vector when the RREQ-DIO arrives at the 453 TargNode, unchanged during the transmission to the OrigNode. 455 4.3. AODV-RPL Target Option 457 The AODV-RPL Target (ART) Option is based on the Target Option in 458 core RPL [RFC6550]. The Flags field is replaced by the Destination 459 Sequence Number of the TargNode and the Prefix Length field is 460 reduced to 7 bits so that the value is limited to be no greater than 461 127. 463 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO 464 message MUST carry exactly one ART Option. Otherwise, the message 465 MUST be dropped. 467 OrigNode can include multiple TargNode addresses via multiple AODV- 468 RPL Target Options in the RREQ-DIO, for routes that share the same 469 requirement on metrics. This reduces the cost to building only one 470 DODAG. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Option Type | Option Length | Dest SeqNo |X|Prefix Length| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | | 478 + | 479 | Target Prefix / Address (Variable Length) | 480 . . 481 . . 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 3: ART Option format for AODV-RPL 486 Option Type 487 TBD4 489 Option Length 490 Length of the option in octets excluding the Type and Length 491 fields. 493 Dest SeqNo 495 In RREQ-DIO, if nonzero, it is the Sequence Number for the last 496 route that OrigNode stored to the TargNode for which a route is 497 desired. In RREP-DIO, it is the destination sequence number 498 associated to the route. Zero is used if there is no known 499 information about the sequence number of TargNode, and not used 500 otherwise. 502 X 503 A one-bit reserved field. This field MUST be initialized to zero 504 by the sender and MUST be ignored by the receiver. 506 Prefix Length 507 7-bit unsigned integer. Number of valid leading bits in the IPv6 508 Prefix. If Prefix Length is 0, then the value in the Target 509 Prefix / Address field represents an IPv6 address, not a prefix. 511 Target Prefix / Address 512 (variable-length field) An IPv6 destination address or prefix. 513 The Prefix Length field contains the number of valid leading bits 514 in the prefix. The Target Prefix / Address field contains the 515 least number of octets that can represent all of the bits of the 516 Prefix, in other words Ceil(Prefix Length/8) octets. The initial 517 bits in the Target Prefix / Address field preceding the prefix 518 length (if any) MUST be set to zero on transmission and MUST be 519 ignored on receipt. If Prefix Length is zero, the Address field 520 is 128 bits for IPv6 addresses. 522 5. Symmetric and Asymmetric Routes 524 Links are considered symmetric until indication to the contrary is 525 received. In Figure 4 and Figure 5, BR is the Border Router, O is 526 the OrigNode, each R is an intermediate router, and T is the 527 TargNode. If the RREQ-DIO arrives over an interface that is known to 528 be symmetric, and the S bit is set to 1, then it remains as 1, as 529 illustrated in Figure 4. If an intermediate router sends out RREQ- 530 DIO with the S bit set to 1, then each link en route from the 531 OrigNode O to this router has met the requirements of route 532 discovery, and the route can be used symmetrically. 534 BR 535 /----+----\ 536 / | \ 537 / | \ 538 R R R 539 _/ \ | / \ 540 / \ | / \ 541 / \ | / \ 542 R -------- R --- R ----- R -------- R 543 / \ <--S=1--> / \ <--S=1--> / \ 544 <--S=1--> \ / \ / <--S=1--> 545 / \ / \ / \ 546 O ---------- R ------ R------ R ----- R ----------- T 547 / \ / \ / \ / \ 548 / \ / \ / \ / \ 549 / \ / \ / \ / \ 550 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 552 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 553 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 555 Figure 4: AODV-RPL with Symmetric Instances 557 Upon receiving a RREQ-DIO with the S bit set to 1, a node determines 558 whether this link can be used symmetrically, i.e., both directions 559 meet the requirements of data transmission. If the RREQ-DIO arrives 560 over an interface that is not known to be symmetric, or is known to 561 be asymmetric, the S bit is set to 0. If the S bit arrives already 562 set to be '0', it is set to be '0' when the RREQ-DIO is propagated 563 (Figure 5). For an asymmetric route, there is at least one hop which 564 doesn't satisfy the Objective Function. Based on the S bit received 565 in RREQ-DIO, TargNode T determines whether or not the route is 566 symmetric before transmitting the RREP-DIO message upstream towards 567 the OrigNode O. 569 It is beyond the scope of this document to specify the criteria used 570 when determining whether or not each link is symmetric. As an 571 example, intermediate routers can use local information (e.g., bit 572 rate, bandwidth, number of cells used in 6tisch [RFC9030]), a priori 573 knowledge (e.g., link quality according to previous communication) or 574 use averaging techniques as appropriate to the application. Other 575 link metric information can be acquired before AODV-RPL operation, by 576 executing evaluation procedures; for instance test traffic can be 577 generated between nodes of the deployed network. During AODV-RPL 578 operation, OAM techniques for evaluating link state (see [RFC7548], 579 [RFC7276], [co-ioam]) MAY be used (at regular intervals appropriate 580 for the LLN). The evaluation procedures are out of scope for AODV- 581 RPL. 583 Appendix A describes an example method using the upstream Expected 584 Number of Transmissions (ETX) and downstream Received Signal Strength 585 Indicator (RSSI) to estimate whether the link is symmetric in terms 586 of link quality using an averaging technique. 588 BR 589 /----+----\ 590 / | \ 591 / | \ 592 R R R 593 / \ | / \ 594 / \ | / \ 595 / \ | / \ 596 R --------- R --- R ---- R --------- R 597 / \ --S=1--> / \ --S=0--> / \ 598 --S=1--> \ / \ / --S=0--> 599 / \ / \ / \ 600 O ---------- R ------ R------ R ----- R ----------- T 601 / \ / \ / \ / \ 602 / <--S=0-- / \ / \ / <--S=0-- 603 / \ / \ / \ / \ 604 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 605 <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- 607 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 608 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 609 Figure 5: AODV-RPL with Asymmetric Paired Instances 611 As illustrated in Figure 5, an intermediate router determines the S 612 bit value that the RREQ-DIO should carry using link asymmetry 613 detection methods as discussed earlier in this section. In many 614 cases the intermediate router has already made the link asymmetry 615 decision by the time RREQ-DIO arrives. 617 6. AODV-RPL Operation 619 6.1. Route Request Generation 621 The route discovery process is initiated when an application at the 622 OrigNode has data to be transmitted to the TargNode, but does not 623 have a route that satisfies the Objective Function for the target of 624 the application's data. In this case, the OrigNode builds a local 625 RPLInstance and a DODAG rooted at itself. Then it transmits a DIO 626 message containing exactly one RREQ option (see Section 4.1) to 627 multicast group all-RPL-nodes. The DIO MUST contain at least one ART 628 Option (see Section 4.3), which indicates the TargNode. The S bit in 629 RREQ-DIO sent out by the OrigNode is set to 1. 631 Each node maintains a sequence number; the operation is specified in 632 section 7.2 of [RFC6550]. When the OrigNode initiates a route 633 discovery process, it MUST increase its own sequence number to avoid 634 conflicts with previously established routes. The sequence number is 635 carried in the Orig SeqNo field of the RREQ option. 637 The address in the ART Option can be a unicast IPv6 address or a 638 prefix. The OrigNode can initiate the route discovery process for 639 multiple targets simultaneously by including multiple ART Options. 640 Within a RREQ-DIO the Objective Function for the routes to different 641 TargNodes MUST be the same. 643 OrigNode can maintain different RPLInstances to discover routes with 644 different requirements to the same targets. Using the RPLInstanceID 645 pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for 646 different RPLInstances can be generated. 648 The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If 649 the length of time specified by the L field has elapsed, the OrigNode 650 MUST leave the DODAG and stop sending RREQ-DIOs in the related 651 RPLInstance. 653 6.2. Receiving and Forwarding RREQ messages 654 6.2.1. Step 1: RREQ reception and evaluation 656 When a router X receives a RREQ message over a link from a neighbor 657 Y, X first determines whether or not the RREQ is valid. If so, X 658 then determines whether or not it has sufficient resources available 659 to maintain the state needed to process an eventual RREP if the RREP 660 were to be received. If not, then X MUST drop the packet and 661 discontinue processing of the RREQ. Otherwise, X next determines 662 whether the RREQ advertises a usable route to OrigNode, by checking 663 whether the link to Y can be used to tramsmit packets to OrigNode. 665 When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if 666 one of its addresses is present in the Address Vector. When H=1 in 667 the incoming RREQ, the router MUST drop the RREQ message if Orig 668 SeqNo field of the RREQ is older than the SeqNo value that X has 669 stored for a route to OrigNode. Otherwise, the router determines 670 whether to propagate the RREQ-DIO. It does this by determining 671 whether or not a route to OrigNode using the upstream direction of 672 the incoming link satisfies the Objective Function (OF). In order to 673 evaluate the OF, the router first determines the maximum useful rank 674 (MaxUsefulRank). If the router has previously joined the RREQ- 675 Instance associated with the RREQ-DIO, then MaxUsefulRank is set to 676 be the Rank value that was stored when the router processed the best 677 previous RREQ for the DODAG with the given RREQ-Instance. Otherwise, 678 MaxUsefulRank is set to be RankLimit. If OF cannot be satisfied 679 (i.e., the Rank evaluates to a value greater than MaxUsefulRank) the 680 RREQ-DIO MUST be dropped, and the following steps are not processed. 681 Otherwise, the router MUST join the RREQ-Instance and prepare to 682 propagate the RREQ-DIO, as follows. The upstream neighbor router 683 that transmitted the received RREQ-DIO is selected as the preferred 684 parent. 686 6.2.2. Step 2: TargNode and Intermediate Router determination 688 After determining that a received RREQ provides a usable route to 689 OrigNode, a router determines whether it is a TargNode, or a possible 690 intermediate router between OrigNode and a TargNode, or both. The 691 router is a TargNode if it finds one of its own addresses in a Target 692 Option in the RREQ. After possibly propagating the RREQ according to 693 the procedures in Steps 3, 4, and 5, the TargNode generates a RREP as 694 specified in Section 6.3. 696 If the OrigNode tries to reach multiple TargNodes in a single RREQ- 697 Instance, one of the TargNodes can be an intermediate router to other 698 TargNodes. In this case, before transmitting the RREQ-DIO to 699 multicast group all-RPL-nodes, a TargNode MUST delete the Target 700 Option encapsulating its own address, so that downstream routers with 701 higher Rank values do not try to create a route to this TargNode. 703 An intermediate router could receive several RREQ-DIOs from routers 704 with lower Rank values in the same RREQ-Instance with different lists 705 of Target Options. For the purposes of determining the intersection 706 with previous incoming RREQ-DIOs, the intermediate router maintains a 707 record of the targets that have been requested for a given RREQ- 708 Instance. An incoming RREQ-DIO message having multiple ART Options 709 coming from a router with higher Rank than the Rank of the stored 710 targets is ignored. When transmitting the RREQ-DIO, the intersection 711 of all received lists MUST be included if it is nonempty after 712 TargNode has deleted the Target Option encapsulating its own address. 713 If the intersection is empty, it means that all the targets have been 714 reached, and the router MUST NOT transmit any RREQ-DIO. Otherwise it 715 proceeds to Section 6.2.3. 717 For example, suppose two RREQ-DIOs are received with the same 718 RPLInstance and OrigNode. Suppose further that the first RREQ has 719 (T1, T2) as the targets, and the second one has (T2, T4) as targets. 720 Then only T2 needs to be included in the generated RREQ-DIO. 722 6.2.3. Step 3: Intermediate Router RREQ processing 724 The intermediate router establishes itself as a viable node for a 725 route to OrigNode as follows. If the H bit is set to 1, for hop-by- 726 hop routing, then the router MUST build or update its upward route 727 entry towards OrigNode, which includes at least the following items: 728 Source Address, RPLInstanceID, Destination Address, Next Hop, 729 Lifetime, and Sequence Number. The Destination Address and the 730 RPLInstanceID respectively can be learned from the DODAGID and the 731 RPLInstanceID of the RREQ-DIO. The Source Address is the address 732 used by the router to send data to the Next Hop, i.e., the preferred 733 parent. The lifetime is set according to DODAG configuration (not 734 the L field) and can be extended when the route is actually used. 735 The sequence number represents the freshness of the route entry; it 736 is copied from the Orig SeqNo field of the RREQ option. A route 737 entry with the same source and destination address, same 738 RPLInstanceID, but stale sequence number, MUST be deleted. 740 6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router 742 If the S bit of the incoming RREQ-DIO is 0, then the route cannot be 743 symmetric, and the S bit of the RREQ-DIO to be transmitted is set to 744 0. Otherwise, the router MUST determine whether the downward (i.e., 745 towards the TargNode) direction of the incoming link satisfies the 746 OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1. 747 Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0. 749 When a router joins the RREQ-Instance, it also associates within its 750 data structure for the RREQ-Instance the information about whether or 751 not the RREQ-DIO to be transmitted has the S-bit set to 1. This 752 information associated to RREQ-Instance is known as the S-bit of the 753 RREQ-Instance. It will be used later during the RREP-DIO message 754 processing Section 6.3.2. 756 Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit 757 of the RREQ-Instance is set to 1. In this case, the router MAY 758 optionally associate to the RREQ-Instance, the Address Vector of the 759 symmetric route back to OrigNode. This is useful if the router later 760 receives an RREP-DIO that is paired with the RREQ. 762 6.2.5. Step 5: RREQ propagation at an Intermediate Router 764 If the router is an intermediate router, then it transmits the RREQ- 765 DIO to the multicast group all-RPL-nodes; if the H bit is set to 0, 766 the intermediate router MUST append the address of its interface 767 receiving the RREQ-DIO into the address vector. 769 6.2.6. Step 6: RREQ reception at TargNode 771 If the router is a TargNode and was already associated with the RREQ- 772 Instance, it takes no further action and does not send an RREP-DIO. 773 If TargNode is not already associated with the RREQ-Instance, it 774 prepares and transmits a RREP-DIO, possibly after waiting for 775 RREP_WAIT_TIME, as detailed in (Section 6.3). 777 6.3. Generating Route Reply (RREP) at TargNode 779 When a TargNode receives a RREQ message over a link from a neighbor 780 Y, TargNode first follows the procedures in Section 6.2. If the link 781 to Y can be used to tramsmit packets to OrigNode, TargNode generates 782 a RREP according to the steps below. Otherwise TargNode drops the 783 RREQ and does not generate a RREP. 785 If the L field is not 0, the TargNode MAY delay transmitting the 786 RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower 787 Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the 788 duration determined by the L field. For L == 0, RREP_WAIT_TIME is 789 set by default to 0. Depending upon the application, RREP_WAIT_TIME 790 may be set to other values. Smaller values enable quicker formation 791 for the P2P route. Larger values enable formation of P2P routes with 792 better Rank values. 794 The address of the OrigNode MUST be encapsulated in the ART Option 795 and included in this RREP-DIO message along with the SeqNo of 796 TargNode. 798 6.3.1. RREP-DIO for Symmetric route 800 If the RREQ-Instance corresponding to the RREQ-DIO that arrived at 801 TargNode has the S bit set to 1, there is a symmetric route both of 802 whose directions satisfy the Objective Function. Other RREQ-DIOs 803 might later provide better upward routes. The method of selection 804 between a qualified symmetric route and an asymmetric route that 805 might have better performance is implementation-specific and out of 806 scope. 808 For a symmetric route, the RREP-DIO message is unicast to the next 809 hop according to the Address Vector (H=0) or the route entry (H=1); 810 the DODAG in RREP-Instance does not need to be built. The 811 RPLInstanceID in the RREP-Instance is paired as defined in 812 Section 6.3.3. In case the H bit is set to 0, the address vector 813 from the RREQ-DIO MUST be included in the RREP-DIO. 815 6.3.2. RREP-DIO for Asymmetric Route 817 When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the 818 TargNode MUST build a DODAG in the RREP-Instance corresponding to the 819 RREQ-DIO rooted at itself, in order to provide OrigNode with a 820 downstream route to the TargNode. The RREP-DIO message is 821 transmitted to multicast group all-RPL-nodes. 823 6.3.3. RPLInstanceID Pairing 825 Since the RPLInstanceID is assigned locally (i.e., there is no 826 coordination between routers in the assignment of RPLInstanceID), the 827 tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely 828 identify a discovered route. It is possible that multiple route 829 discoveries with dissimilar Objective Functions are initiated 830 simultaneously. Thus between the same pair of OrigNode and TargNode, 831 there can be multiple AODV-RPL route discovery instances. So that 832 OrigNode and Targnode can avoid any mismatch, they MUST pair the 833 RREQ-Instance and the RREP-Instance in the same route discovery by 834 using the RPLInstanceID. 836 When preparing the RREP-DIO, a TargNode could find the RPLInstanceID 837 candidate for the RREP-Instance is already occupied by another RPL 838 Instance from an earlier route discovery operation which is still 839 active. This unlikely case might happen if two distinct OrigNodes 840 need routes to the same TargNode, and they happen to use the same 841 RPLInstanceID for RREQ-Instance. In such cases, the RPLInstanceID of 842 an already active RREP-Instance MUST NOT be used again for assigning 843 RPLInstanceID for the later RREP-Instance. Reusing the same 844 RPLInstanceID for two distinct DODAGs originated with the same 845 DODAGID (TargNode address) would prevent intermediate routers from 846 distinguishing between these DODAGs (and their associated Objective 847 Functions). Instead, the RPLInstanceID MUST be replaced by another 848 value so that the two RREP-instances can be distinguished. In the 849 RREP-DIO option, the Delta field of the RREP-DIO message (Figure 2) 850 indicates the increment to be applied to the pre-existing 851 RPLInstanceID to obtain the value of the RPLInstanceID that is used 852 in the RREP-DIO message. When the new RPLInstanceID after 853 incrementation exceeds 255, it rolls over starting at 0. For 854 example, if the RREQ-InstanceID is 252, and incremented by 6, the new 855 RPLInstanceID will be 2. Related operations can be found in 856 Section 6.4. RPLInstanceID collisions do not occur across RREQ-DIOs; 857 the DODAGID equals the OrigNode address and is sufficient to 858 disambiguate between DODAGs. 860 6.4. Receiving and Forwarding Route Reply 862 Upon receiving a RREP-DIO, a router which already belongs to the 863 RREP-Instance SHOULD drop the DIO. Otherwise the router performs the 864 steps in the following subsections. 866 6.4.1. Step 1: Receiving and Evaluation 868 If the Objective Function is not satisfied, the router MUST NOT join 869 the DODAG; the router MUST discard the RREP-DIO, and does not execute 870 the remaining steps in this section. An Intermediate Router MUST 871 discard a RREP if one of its addresses is present in the Address 872 Vector, and does not execute the remaining steps in this section. 874 If the S bit of the associated RREQ-Instance is set to 1, the router 875 MUST proceed to Section 6.2.2. 877 If the S-bit of the RREQ-Instance is set to 0, the router MUST 878 determine whether the downward direction of the link (towards the 879 TargNode) over which the RREP-DIO is received satisfies the Objective 880 Function, and the router's Rank would not exceed the RankLimit. If 881 so, the router joins the DODAG of the RREP-Instance. The router that 882 transmitted the received RREP-DIO is selected as the preferred 883 parent. Afterwards, other RREP-DIO messages can be received. 885 6.4.2. Step 2: OrigNode or Intermediate Router 887 The router updates its stored value of the TargNode's sequence number 888 according to the value provided in the ART option. The router next 889 checks if one of its addresses is included in the ART Option. If so, 890 this router is the OrigNode of the route discovery. Otherwise, it is 891 an intermediate router. 893 6.4.3. Step 3: Build Route to TargNode 895 If the H bit is set to 1, then the router (OrigNode or intermediate) 896 MUST build a downward route entry towards TargNode which includes at 897 least the following items: OrigNode Address, RPLInstanceID, TargNode 898 Address as destination, Next Hop, Lifetime and Sequence Number. For 899 a symmetric route, the Next Hop in the route entry is the router from 900 which the RREP-DIO is received. For an asymmetric route, the Next 901 Hop is the preferred parent in the DODAG of RREP-Instance. The 902 RPLInstanceID in the route entry MUST be the RREQ-InstanceID (i.e., 903 after subtracting the Delta field value from the value of the 904 RPLInstanceID). The source address is learned from the ART Option, 905 and the destination address is learned from the DODAGID. The 906 lifetime is set according to DODAG configuration (i.e., not the L 907 field) and can be extended when the route is actually used. The 908 sequence number represents the freshness of the route entry, and is 909 copied from the Dest SeqNo field of the ART option of the RREP-DIO. 910 A route entry with same source and destination address, same 911 RPLInstanceID, but stale sequence number (i.e., incoming sequence 912 number is less than the currently stored sequence number of the route 913 entry), MUST be deleted. 915 6.4.4. Step 4: RREP Propagation 917 If the receiver is the OrigNode, it can start transmitting the 918 application data to TargNode along the path as provided in RREP- 919 Instance, and processing for the RREP-DIO is complete. Otherwise, 920 the RREP will be propagated towards OrigNode. If H=0, the 921 intermediate router MUST include the address of the interface 922 receiving the RREP-DIO into the address vector. If H=1, according to 923 the last step the intermediate router has set up a route entry for 924 TargNode. If the intermediate router has a route to OrigNode, it 925 uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in 926 case of a symmetric route, the RREP-DIO message is unicast to the 927 Next Hop according to the address vector in the RREP-DIO (H=0) or the 928 local route entry (H=1). Otherwise, in case of an asymmetric route, 929 the intermediate router transmits the RREP-DIO to multicast group 930 all-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the 931 same as the value in the received RREP-DIO. 933 7. Gratuitous RREP 935 In some cases, an Intermediate router that receives a RREQ-DIO 936 message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode 937 instead of continuing to multicast the RREQ-DIO towards TargNode. 938 The intermediate router effectively builds the RREP-Instance on 939 behalf of the actual TargNode. The G bit of the RREP option is 940 provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the 941 Intermediate router from the RREP-DIO sent by TargNode (G=0). 943 The gratuitous RREP-DIO MAY be sent out when an intermediate router 944 receives a RREQ-DIO for a TargNode, and the router has a pair of 945 downward and upward routes to the TargNode which also satisfy the 946 Objective Function and for which the destination sequence number is 947 at least as large as the sequence number in the RREQ-DIO message. 949 In case of source routing, the intermediate router MUST unicast the 950 received RREQ-DIO to TargNode including the address vector between 951 the OrigNode and the router. Thus the TargNode can have a complete 952 upward route address vector from itself to the OrigNode. Then the 953 router MUST include the address vector from the TargNode to the 954 router itself in the gratuitous RREP-DIO to be transmitted. 956 In case of hop-by-hop routing, the intermediate router MUST unicast 957 the received RREQ-DIO to the Next Hop on the route. The Next Hop 958 router along the route MUST build new route entries with the related 959 RPLInstanceID and DODAGID in the downward direction. The above 960 process will happen recursively until the RREQ-DIO arrives at the 961 TargNode. Then the TargNode MUST unicast recursively the RREP-DIO 962 hop-by-hop to the intermediate router, and the routers along the 963 route SHOULD build new route entries in the upward direction. Upon 964 receiving the unicast RREP-DIO, the intermediate router sends the 965 gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. 967 8. Operation of Trickle Timer 969 RREQ-Instance/RREP-Instance multicast uses trickle timer operations 970 [RFC6206] to control RREQ-DIO and RREP-DIO transmissions. The 971 Trickle control of these DIO transmissions follows the procedures 972 described in the Section 8.3 of [RFC6550] entitled "DIO 973 Transmission". If the route is symmetric, the RREP DIO does not need 974 the Trickle timer mechanism. 976 9. IANA Considerations 978 Note to RFC editor: 980 The sentence "The parenthesized numbers are only suggestions." is to 981 be removed prior publication. 983 A Subregistry in this section refers to a named sub-registry of the 984 "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. 986 AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) 987 with new Options as specified in this document. Please cite AODV-RPL 988 and this document as one of the protocols using MOP 4. 990 IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and 991 "ART", as described in Figure 6 from the "RPL Control Message 992 Options" Subregistry. The parenthesized numbers are only 993 suggestions. 995 +-------------+------------------------+---------------+ 996 | Value | Meaning | Reference | 997 +-------------+------------------------+---------------+ 998 | TBD2 (0x0B) | RREQ Option | This document | 999 +-------------+------------------------+---------------+ 1000 | TBD3 (0x0C) | RREP Option | This document | 1001 +-------------+------------------------+---------------+ 1002 | TBD4 (0x0D) | ART Option | This document | 1003 +-------------+------------------------+---------------+ 1005 Figure 6: AODV-RPL Options 1007 10. Security Considerations 1009 The security considerations for the operation of AODV-RPL are similar 1010 to those for the operation of RPL (as described in Section 19 of the 1011 RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] 1012 describe RPL's optional security framework, which AODV-RPL relies on 1013 to provide data confidentiality, authentication, replay protection, 1014 and delay protection services. Additional analysis for the security 1015 threats to RPL can be found in [RFC7416]. 1017 A router can join a temporary DAG created for a secure AODV-RPL route 1018 discovery only if it can support the security configuration in use 1019 (see Section 6.1 of [RFC6550]), which also specifies the key in use. 1020 It does not matter whether the key is preinstalled or dynamically 1021 acquired. The router must have the key in use before it can join the 1022 DAG being created for secure route discovery. 1024 If a rogue router knows the key for the security configuration in 1025 use, it can join the secure AODV-RPL route discovery and cause 1026 various types of damage. Such a rogue router could advertise false 1027 information in its DIOs in order to include itself in the discovered 1028 route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages 1029 carrying bad routes or maliciously modify genuine RREP-DIO messages 1030 it receives. A rogue router acting as the OrigNode could launch 1031 denial-of-service attacks against the LLN deployment by initiating 1032 fake AODV-RPL route discoveries. When rogue routers might be 1033 present, RPL's preinstalled mode of operation, where the key to use 1034 for route discovery is preinstalled, SHOULD be used. 1036 When a RREQ-DIO message uses the source routing option by setting the 1037 H bit to 0, a rogue router may populate the Address Vector field with 1038 a set of addresses that may result in the RREP-DIO traveling in a 1039 routing loop. 1041 If a rogue router is able to forge a gratuitous RREP, it could mount 1042 denial-of-service attacks. 1044 11. Acknowledgements 1046 The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for 1047 their support and valuable inputs. The authors specially thank 1048 Lavanya H.M for implementing AODV-RPl in Contiki and conducting 1049 extensive simulation studies. 1051 The authors would like to acknowledge the review, feedback and 1052 comments from the following people, in alphabetical order: Roman 1053 Danyliw, Lars Eggert, Benjamin Kaduk, Tero Kivinen, Erik Kline, 1054 Murray Kucherawy, Warren Kumari, Francesca Palombini, Alvaro Retana, 1055 Ines Robles, John Scudder, Meral Shirazipour, Peter Van der Stok, 1056 Eric Vyncke, and Robert Wilton. 1058 12. References 1060 12.1. Normative References 1062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1063 Requirement Levels", BCP 14, RFC 2119, 1064 DOI 10.17487/RFC2119, March 1997, 1065 . 1067 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1068 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1069 March 2011, . 1071 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1072 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1073 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1074 Low-Power and Lossy Networks", RFC 6550, 1075 DOI 10.17487/RFC6550, March 2012, 1076 . 1078 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1079 and D. Barthel, "Routing Metrics Used for Path Calculation 1080 in Low-Power and Lossy Networks", RFC 6551, 1081 DOI 10.17487/RFC6551, March 2012, 1082 . 1084 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1085 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1086 May 2017, . 1088 12.2. Informative References 1090 [co-ioam] Ballamajalu, Rashmi., S.V.R., Anand., and Malati Hegde, 1091 "Co-iOAM: In-situ Telemetry Metadata Transport for 1092 Resource Constrained Networks within IETF Standards 1093 Framework", 2018 10th International Conference on 1094 Communication Systems & Networks (COMSNETS) pp.573-576, 1095 January 2018. 1097 [contiki] Contiki contributors, "The Contiki Open Source OS for the 1098 Internet of Things (Contiki Version 2.7)", November 2013, 1099 . 1101 [Contiki-ng] 1102 Contiki-NG contributors, "Contiki-NG: The OS for Next 1103 Generation IoT Devices (Contiki-NG Version 4.6)", December 1104 2020, . 1106 [cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless 1107 Sensor Networks (Contiki/Cooja Version 2.7)", November 1108 2013, . 1111 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1112 Demand Distance Vector (AODV) Routing", RFC 3561, 1113 DOI 10.17487/RFC3561, July 2003, 1114 . 1116 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1117 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1118 in Low-Power and Lossy Networks", RFC 6997, 1119 DOI 10.17487/RFC6997, August 2013, 1120 . 1122 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, 1123 "A Mechanism to Measure the Routing Metrics along a Point- 1124 to-Point Route in a Low-Power and Lossy Network", 1125 RFC 6998, DOI 10.17487/RFC6998, August 2013, 1126 . 1128 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1129 Weingarten, "An Overview of Operations, Administration, 1130 and Maintenance (OAM) Tools", RFC 7276, 1131 DOI 10.17487/RFC7276, June 2014, 1132 . 1134 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1135 and M. Richardson, Ed., "A Security Threat Analysis for 1136 the Routing Protocol for Low-Power and Lossy Networks 1137 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1138 . 1140 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 1141 Sehgal, "Management of Networks with Constrained Devices: 1142 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 1143 . 1145 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 1146 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 1147 RFC 9030, DOI 10.17487/RFC9030, May 2021, 1148 . 1150 Appendix A. Example: Using ETX/RSSI Values to determine value of S bit 1152 The combination of Received Signal Strength Indication(downstream) 1153 (RSSI) and Expected Number of Transmissions(upstream) (ETX) has been 1154 tested to determine whether a link is symmetric or asymmetric at 1155 intermediate routers. We present two methods to obtain an ETX value 1156 from RSSI measurement. 1158 Method 1: In the first method, we constructed a table measuring RSSI 1159 vs ETX using the Cooja simulation [cooja] setup in the Contiki OS 1160 environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL 1161 protocol stack for the simulations. For approximating the number 1162 of packet drops based on the RSSI values, we implemented simple 1163 logic that drops transmitted packets with certain pre-defined 1164 ratios before handing over the packets to the receiver. The 1165 packet drop ratio is implemented as a table lookup of RSSI ranges 1166 mapping to different packet drop ratios with lower RSSI ranges 1167 resulting in higher values. While this table has been defined for 1168 the purpose of capturing the overall link behavior, it is highly 1169 recommended to conduct physical radio measurement experiments, in 1170 general. By keeping the receiving node at different distances, we 1171 let the packets experience different packet drops as per the 1172 described method. The ETX value computation is done by another 1173 module which is part of RPL Objective Function implementation. 1174 Since ETX value is reflective of the extent of packet drops, it 1175 allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI 1176 values obtained in this way may be used as explained below: 1178 Source---------->NodeA---------->NodeB------->Destination 1180 Figure 7: Communication link from Source to Destination 1182 +=========================+========================================+ 1183 | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | 1184 +=========================+========================================+ 1185 | > -60 | 150 | 1186 +-------------------------+----------------------------------------+ 1187 | -70 to -60 | 192 | 1188 +-------------------------+----------------------------------------+ 1189 | -80 to -70 | 226 | 1190 +-------------------------+----------------------------------------+ 1191 | -90 to -80 | 662 | 1192 +-------------------------+----------------------------------------+ 1193 | -100 to -90 | 3840 | 1194 +-------------------------+----------------------------------------+ 1196 Table 1: Selection of S bit based on Expected ETX value 1198 Method 2: One could also make use of the function 1199 guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of 1200 Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This 1201 function outputs ETX value ranging between 128 and 3840 for -60 <= 1202 rssi <= -89. The function description is beyond the scope of this 1203 document. 1205 We tested the operations in this specification by making the 1206 following experiment, using the above parameters. In our experiment, 1207 a communication link is considered as symmetric if the ETX value of 1208 NodeA->NodeB and NodeB->NodeA (see Figure 7) are within, say, a 1:3 1209 ratio. This ratio should be understood as determining the link's 1210 symmetric/asymmetric nature. NodeA can typically know the ETX value 1211 in the direction of NodeA -> NodeB but it has no direct way of 1212 knowing the value of ETX from NodeB->NodeA. Using physical testbed 1213 experiments and realistic wireless channel propagation models, one 1214 can determine a relationship between RSSI and ETX representable as an 1215 expression or a mapping table. Such a relationship in turn can be 1216 used to estimate ETX value at nodeA for link NodeB--->NodeA from the 1217 received RSSI from NodeB. Whenever nodeA determines that the link 1218 towards the nodeB is bi-directional asymmetric then the S bit is set 1219 to 0. Afterwards, the link from NodeA to Destination remains 1220 designated as asymmetric and the S bit remains set to 0. 1222 Determination of asymmetry versus bidirectionality remains a topic of 1223 lively discussion in the IETF. 1225 Appendix B. Changelog 1227 Note to the RFC Editor: please remove this section before 1228 publication. 1230 B.1. Changes from version 12 to version 13 1232 * Changed name of "Shift" field to be the "Delta" field. 1234 * Specified that if a node does not have resources, it MUST drop the 1235 RREQ. 1237 * Changed name of MaxUseRank to MaxUsefulRank. 1239 * Revised a sentence that was not clear about when a TargNode can 1240 delay transmission of the RREP in response to a RREQ. 1242 * Provided advice about running AODV-RPL at same time as P2P-RPL or 1243 native RPL. 1245 * Small reorganization and enlargement of the description of Trickle 1246 time operation in Section 8. 1248 * Added definition for "RREQ-InstanceID" to Terminology section. 1250 * Specified that once a node leaves an RREQ-Instance, it MUST NOT 1251 rejoin the same RREQ-Instance. 1253 B.2. Changes from version 11 to version 12 1255 * Defined RREP_WAIT_TIME for asymmetric as well as symmetric 1256 handling of RREP-DIO. 1258 * Clarifed link-local multicast transmission to use link-local 1259 multicast group all-RPL nodes. 1261 * Identified some security threats more explicitly. 1263 * Specified that the pairing between RREQ-DIO and RREP-DIO happens 1264 at OrigNode and TargNode. Intermediate routers do not necessarily 1265 maintain the pairing. 1267 * When RREQ-DIO is received with H=0 and S=1, specified that 1268 intermediate routers MAY store symmetric Address Vector 1269 information for possible use when a matchine RREP-DIO is received. 1271 * Specified that AODV-RPL uses the "P2P Route Discovery Mode of 1272 Operation" (MOP == 4), instead of requesting the allocation of a 1273 new MOP. Clarified that there is no conflict with [RFC6997]. 1275 * Fixed several important typos and improved language in numerous 1276 places. 1278 * Reorganized the steps in the specification for handling RREQ and 1279 RREP at an intermediate router, to more closely follow the order 1280 of processing actions to be taken by the router. 1282 B.3. Changes from version 10 to version 11 1284 * Numerous editorial improvements. 1286 * Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for 1287 simplicity and ease of understanding. 1289 * Use "L field" instead of "L bit" since L is a two-bit field. 1291 * Improved the procedures in section 6.2.1. 1293 * Define the S bit of the data structure a router uses to represent 1294 whether or not the RREQ instance is for a symmetric or an 1295 asymmetric route. This replaces text in the document that was a 1296 holdover from earlier versions in which the RREP had an S bit for 1297 that purpose. 1299 * Quote terminology from AODV that has been identified as possibly 1300 originating in language reflecting various kinds of bias against 1301 certain cultures. 1303 * Clarified the relationship of AODV-RPL to RPL. 1305 * Eliminated the "Point-to-Point" terminology to avoid suggesting 1306 only a single link. 1308 * Modified certain passages to better reflect the possibility that a 1309 router might have multiple IP addresses. 1311 * "Rsv" replaced by "X X" for reserved field. 1313 * Added mandates for reserved fields, and replaces some ambiguous 1314 language phraseology by mandates. 1316 * Replaced "retransmit" terminology by more correct "propagate" 1317 terminology. 1319 * Added text about determining link symmetry near Figure 5. 1321 * Mandated checking the Address Vector to avoid routing loops. 1323 * Improved specification for use of the Delta value in 1324 Section 6.3.3. 1326 * Corrected the wrong use of RREQ-Instance to be RREP-Instance. 1328 * Referred to Subregistry values instead of Registry values in 1329 Section 9. 1331 * Sharpened language in Section 10, eliminated misleading use of 1332 capitalization in the words "Security Configuration". 1334 * Added acknowledgements and contributors. 1336 B.4. Changes from version 09 to version 10 1338 * Changed the title for brevity and to remove acronyms. 1340 * Added "Note to the RFC Editor" in Section 9. 1342 * Expanded DAO and P2MP in Section 1. 1344 * Reclassified [RFC6998] and [RFC7416] as Informational. 1346 * SHOULD changed to MUST in Section 4.1 and Section 4.2. 1348 * Several editorial improvements and clarifications. 1350 B.5. Changes from version 08 to version 09 1352 * Removed section "Link State Determination" and put some of the 1353 relevant material into Section 5. 1355 * Cited security section of [RFC6550] as part of the RREP-DIO 1356 message description in Section 2. 1358 * SHOULD has been changed to MUST in Section 4.2. 1360 * Expanded the terms ETX and RSSI in Section 5. 1362 * Section 6.4 has been expanded to provide a more precise 1363 explanation of the handling of route reply. 1365 * Added [RFC7416] in the Security Considerations (Section 10) for 1366 RPL security threats. Cited [RFC6550] for authenticated mode of 1367 operation. 1369 * Appendix A has been mostly re-written to describe methods to 1370 determine whether or not the S bit should be set to 1. 1372 * For consistency, adjusted several mandates from SHOULD to MUST and 1373 from SHOULD NOT to MUST NOT. 1375 * Numerous editorial improvements and clarifications. 1377 B.6. Changes from version 07 to version 08 1379 * Instead of describing the need for routes to "fulfill the 1380 requirements", specify that routes need to "satisfy the Objective 1381 Function". 1383 * Removed all normative dependencies on [RFC6997] 1385 * Rewrote Section 10 to avoid duplication of language in cited 1386 specifications. 1388 * Added a new section "Link State Determination" with text and 1389 citations to more fully describe how implementations determine 1390 whether links are symmetric. 1392 * Modified text comparing AODV-RPL to other protocols to emphasize 1393 the need for AODV-RPL instead of the problems with the other 1394 protocols. 1396 * Clarified that AODV-RPL uses some of the base RPL specification 1397 but does not require an instance of RPL to run. 1399 * Improved capitalization, quotation, and spelling variations. 1401 * Specified behavior upon reception of a RREQ-DIO or RREP-DIO 1402 message for an already existing DODAGID (e.g, Section 6.4). 1404 * Fixed numerous language issues in IANA Considerations Section 9. 1406 * For consistency, adjusted several mandates from SHOULD to MUST and 1407 from SHOULD NOT to MUST NOT. 1409 * Numerous editorial improvements and clarifications. 1411 B.7. Changes from version 06 to version 07 1413 * Added definitions for all fields of the ART option (see 1414 Section 4.3). Modified definition of Prefix Length to prohibit 1415 Prefix Length values greater than 127. 1417 * Modified the language from [RFC6550] Target Option definition so 1418 that the trailing zero bits of the Prefix Length are no longer 1419 described as "reserved". 1421 * Reclassified [RFC3561] and [RFC6998] as Informative. 1423 * Added citation for [RFC8174] to Terminology section. 1425 B.8. Changes from version 05 to version 06 1427 * Added Security Considerations based on the security mechanisms 1428 defined in [RFC6550]. 1430 * Clarified the nature of improvements due to P2P route discovery 1431 versus bidirectional asymmetric route discovery. 1433 * Editorial improvements and corrections. 1435 B.9. Changes from version 04 to version 05 1437 * Add description for sequence number operations. 1439 * Extend the residence duration L in section 4.1. 1441 * Change AODV-RPL Target option to ART option. 1443 B.10. Changes from version 03 to version 04 1445 * Updated RREP option format. Remove the T bit in RREP option. 1447 * Using the same RPLInstanceID for RREQ and RREP, no need to update 1448 [RFC6550]. 1450 * Explanation of Delta field in RREP. 1452 * Multiple target options handling during transmission. 1454 B.11. Changes from version 02 to version 03 1456 * Include the support for source routing. 1458 * Import some features from [RFC6997], e.g., choice between hop-by- 1459 hop and source routing, the L field which determines the duration 1460 of residence in the DAG, RankLimit, etc. 1462 * Define new target option for AODV-RPL, including the Destination 1463 Sequence Number in it. Move the TargNode address in RREQ option 1464 and the OrigNode address in RREP option into ADOV-RPL Target 1465 Option. 1467 * Support route discovery for multiple targets in one RREQ-DIO. 1469 * New RPLInstanceID pairing mechanism. 1471 Appendix C. Contributors 1473 Abdur Rashid Sangi 1475 Huaiyin Institute of Technology 1477 No.89 North Beijing Road, Qinghe District 1479 Huaian 223001 1481 P.R. China 1483 Email: sangi_bahrian@yahoo.com 1485 Malati Hegde 1487 Indian Institute of Science 1489 Bangalore 560012 1490 India 1492 Email: malati@iisc.ac.in 1494 Mingui Zhang 1496 Huawei Technologies 1498 No. 156 Beiqing Rd. Haidian District 1500 Beijing 100095 1502 P.R. China 1504 Email: zhangmingui@huawei.com 1506 Authors' Addresses 1508 Charles E. Perkins 1509 Lupin Lodge 1510 Los Gatos, 95033 1511 United States 1512 Email: charliep@lupinlodge.com 1514 S.V.R Anand 1515 Indian Institute of Science 1516 Bangalore 560012 1517 India 1518 Email: anandsvr@iisc.ac.in 1520 Satish Anamalamudi 1521 SRM University-AP 1522 Amaravati Campus 1523 Amaravati, Andhra Pradesh 522 502 1524 India 1525 Email: satishnaidu80@gmail.com 1527 Bing Liu 1528 Huawei Technologies 1529 No. 156 Beiqing Rd. Haidian District 1530 Beijing 1531 100095 1532 China 1533 Email: remy.liubing@huawei.com