idnits 2.17.1 draft-ietf-roll-p2p-rpl-17.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 (March 20, 2013) is 4047 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NH' is mentioned on line 1247, but not defined == Unused Reference: 'RFC5226' is defined on line 1690, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-10 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-roll-p2p-measurement-09 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Goyal, Ed. 3 Internet-Draft University of Wisconsin 4 Intended status: Experimental Milwaukee 5 Expires: September 21, 2013 E. Baccelli 6 M. Philipp 7 INRIA 8 A. Brandt 9 Sigma Designs 10 J. Martocci 11 Johnson Controls 12 March 20, 2013 14 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy 15 Networks 16 draft-ietf-roll-p2p-rpl-17 18 Abstract 20 This document specifies a point-to-point route discovery mechanism, 21 complementary to the RPL core functionality. This mechanism allows 22 an IPv6 router to discover "on demand" routes to one or more IPv6 23 routers in the LLN such that the discovered routes meet specified 24 metrics constraints. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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 http://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 September 21, 2013. 43 Copyright Notice 45 Copyright (c) 2013 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 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Known Issues/Future Work . . . . . . . . . . . . . . . . . 4 62 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 8 66 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 10 67 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 11 68 7. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . . . 14 69 8. The P2P Discovery Reply Object (P2P-DRO) . . . . . . . . . . . 18 70 8.1. Secure P2P-DRO . . . . . . . . . . . . . . . . . . . . . . 20 71 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply 72 Object . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 21 74 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 21 75 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 22 76 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 24 77 9.4. Additional Processing of a P2P Mode DIO At An 78 Intermediate Router . . . . . . . . . . . . . . . . . . . 25 79 9.5. Additional Processing of a P2P Mode DIO At The Target . . 26 80 9.6. Processing a P2P-DRO At An Intermediate Router . . . . . . 27 81 9.7. Processing a P2P-DRO At The Origin . . . . . . . . . . . . 29 82 10. The P2P Discovery Reply Object Acknowledgement 83 (P2P-DRO-ACK) . . . . . . . . . . . . . . . . . . . . . . . . 30 84 11. Secure P2P-RPL Operation . . . . . . . . . . . . . . . . . . . 31 85 12. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 32 86 13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 33 87 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 88 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 89 15.1. Additions to Mode of Operation . . . . . . . . . . . . . . 35 90 15.2. Additions to RPL Control Message Options . . . . . . . . . 35 91 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 36 92 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 93 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 95 17.2. Informative References . . . . . . . . . . . . . . . . . . 38 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 99 1. Introduction 101 Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing 102 Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed 103 Acyclic Graph (DAG) rooted at a single router in the network. 104 Establishment and maintenance of a DAG is performed by routers in the 105 LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) 106 messages. When two arbitrary routers (neither of which is the DAG's 107 root) need to communicate, the data packets are restricted to travel 108 only along the links in the DAG. Such point-to-point (P2P) routing 109 functionality may not be sufficient for several Home and Building 110 Automation applications [RFC5826] [RFC5867] due to the following 111 reasons: 113 o The need to pre-establish routes: each potential destination in 114 the network must declare itself as such ahead of the time a source 115 needs to reach it. 117 o The need to route only along the links in the DAG: A DAG is built 118 to optimize the routing cost to reach the root. Restricting P2P 119 routes to use only the in-DAG links may result in significantly 120 suboptimal routes and severe traffic congestion near the DAG root. 122 This document describes an extension to core RPL (i.e., the RPL 123 functionality described in [RFC6550]) that enables an IPv6 router in 124 the LLN to discover routes to one or more IPv6 routers in the LLN "on 125 demand". The discovered routes may not be the best available but are 126 guaranteed to meet the specified routing metric constraints. Thus, 127 such routes are considered "good enough" from the application's 128 perspective. This reactive P2P route discovery mechanism is 129 henceforth referred to as P2P-RPL. 131 A mechanism to measure the end-to-end cost of an existing route is 132 specified in [I-D.ietf-roll-p2p-measurement]. As discussed in 133 Section 4, measuring the end-to-end cost of an existing route may 134 help decide whether to initiate the discovery of a better route using 135 P2P-RPL and the metric constraints to be used for this purpose. 137 1.1. Known Issues/Future Work 139 This document is presented as an Experimental specification to 140 facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P 141 route discovery is considered useful or necessary. It is anticipated 142 that, once sufficient operational experience has been gained, this 143 specification will be revised to progress it on to the Standards 144 Track. Experience reports regarding P2P-RPL implementation and 145 deployment are encouraged particularly with respect to: 147 o Secure P2P-RPL operation (Section 11); 149 o Rules governing Trickle operation (Section 9.2); 151 o Values in the default DODAG Configuration Option (Section 6.1); 153 o The RPLInstanceID reuse policy (Section 6.1); 155 o Utility and implementation complexity of allowing multiple Target 156 addresses in a P2P-RPL route discovery. 158 2. The Use Cases 160 One use case, common in home [RFC5826] and commercial building 161 [RFC5867] environments, involves a device (say a remote control) that 162 suddenly needs to communicate with another device (say a lamp) to 163 which it does not already have a route (and whose network address it 164 knows apriory). In this case, the remote control must be able to 165 discover a route to the lamp "on demand". 167 Another use case, common in a commercial building environment, 168 involves a large LLN deployment where P2P communication along a 169 particular DAG among hundreds (or thousands) of routers creates 170 severe traffic congestion near that DAG's root. In this case, it is 171 desirable to discover direct routes between various source- 172 destination pairs that do not pass through the DAG's root. 174 Other use cases involve scenarios where energy or latency constraints 175 are not satisfied by the P2P routes along an existing DAG because 176 they involve traversing many more intermediate routers than necessary 177 to reach the destination. 179 3. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 [RFC2119]. 186 Additionally, this document uses terminology from [RFC6550] and 187 [I-D.ietf-roll-terminology]. This document introduces the following 188 terms: 190 Origin : The IPv6 router initiating the P2P-RPL route discovery. 192 Target : The IPv6 router at the other end point of the P2P route(s) 193 to be discovered. A P2P-RPL route discovery can discover routes to 194 multiple Targets at the same time. 196 Intermediate Router: An IPv6 router that is neither the Origin nor a 197 Target. 199 Forward direction: The direction from the Origin to the Target. 201 Reverse direction: The direction from the Target to the Origin. 203 Forward Route: A route in the Forward direction. 205 Reverse Route: A route in the Reverse direction. 207 Bidirectional Route: A route that can be used in both Forward and 208 Reverse directions. 210 Ingress-only Interface: A network interface that can only receive 211 packets. 213 Egress-only Interface: A network interface that can only send 214 packets. 216 Source Route: A complete and ordered list of routers that can be used 217 by a packet to travel from a source to a destination node. 219 Hop-by-hop Route: The route characterized by each router on the route 220 using its routing table to determine the next hop on the route. 222 RPL Security Configuration: The values for Counter is Time, Security 223 Algorithm, Key Identifier Mode and Security Level fields, defined in 224 Section 6.1 of [RFC6550], inside the Security section of a secure RPL 225 control message. 227 4. Applicability 229 A route discovery using P2P-RPL may be performed by an Origin when no 230 route exists between itself and the Target(s) or when the existing 231 routes do not satisfy the application requirements. P2P-RPL is 232 designed to discover Hop-by-hop or Source Routes to one or more 233 Targets such that the discovered routes meet the specified 234 constraints. In some application contexts, the constraints that the 235 discovered routes must satisfy are intrinsically known or can be 236 specified by the application. For example, an Origin that expects 237 its Targets to be less than 5 hops away may use "hop-count < 5" as 238 the constraint. In other application contexts, the Origin may need 239 to measure the cost of the existing route to a Target to determine 240 the constraints. For example, an Origin that measures the total ETX 241 along its current route to a Target to be 20 may use "ETX < x*20", 242 where x is a fraction that the Origin decides, as the constraint. A 243 mechanism to measure the cost of an existing route between two IPv6 244 routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is 245 no existing route between the Origin and the Target(s) or the cost 246 measurement for the existing routes fails, the Origin will have to 247 guess the constraints to be used in the initial route discovery. 248 Once, the initial route discovery succeeds or fails, the Origin will 249 have a better estimate for the constraints to be used in the 250 subsequent route discovery. 252 P2P-RPL may result in discovery of better P2P routes than the ones 253 available along a global DAG designed to optimize routing cost to the 254 DAG's root. The improvement in route quality depends on a number of 255 factors including the network topology, the "distance" between the 256 Origin and the Target (in terms of the routing metrics in use) and 257 the prevalent conditions in the network. In general, a P2P-RPL route 258 may be better than the one along a global DAG if the Origin and the 259 Target are nearby. Similarly, a P2P-RPL route may not be much better 260 than the one along a global DAG if the Origin and the Target are far 261 apart. Note that, even when P2P-RPL routes are not much better than 262 those along a global DAG, P2P-RPL routes may still be able to avoid 263 congestion that might occur near the root if the routing takes place 264 only along a global DAG. In general, the costs associated with a 265 P2P-RPL route discovery (in terms of the control messages, mostly 266 DIOs, generated) increases with the distance between the Origin and 267 the Target. However, it is possible to limit the cost of route 268 discovery by carefully setting the routing constraints, the Trickle 269 parameters (that govern the DIO generation) and the time duration for 270 which a router maintains its membership in the temporary DAG created 271 for the route discovery. A network designer may take into 272 consideration both the benefits (potentially better routes; no need 273 to maintain routes proactively; avoid congestion near the global 274 DAG's root) and costs when using P2P-RPL. The latency associated 275 with a P2P-RPL route discovery again depends on the distance between 276 the Origin and the Target and the Trickle parameters. 278 Like core RPL [RFC6550], P2P-RPL operation requires links to have 279 bidirectional reachability. For this reason, the routers 280 participating in a P2P-RPL route discovery must ensure that 282 o Links that do not have bidirectional reachability do not become 283 part of the route being discovered; and 285 o IPv6 addresses belonging to Ingress-only (or Egress-only) 286 Interfaces do not become part of the route being discovered. 288 5. Functional Overview 290 This section contains a high level description of P2P-RPL. 292 A P2P-RPL route discovery takes place by forming a DAG rooted at the 293 Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local 294 multicast DIO messages to establish a DAG. However, unlike core RPL, 295 this DAG is temporary in nature. The routes are discovered and 296 installed while the DAG is alive. Once the specified duration of 297 their membership in the DAG is over, the routers leave the DAG and 298 hence the DAG ceases to exist. However, the installed routes are 299 retained for their specified life time (which is different than the 300 specified duration of a router's membership in the DAG) even though 301 the DAG that caused their installation no longer exists. In P2P-RPL, 302 the sole purpose of DAG creation is to discover routes to the 303 Target(s) and DIOs serve as the route discovery messages. Each 304 router joining the DAG determines a rank for itself in the DAG and 305 ignores the subsequent DIOs received from lower (higher in numerical 306 value) ranked neighbors. Thus, the route discovery messages 307 propagate away from the Origin rather than return back to it. As in 308 core RPL, DIO generation at a router is controlled by a Trickle timer 309 [RFC6206] that allows a router to avoid generating unnecessary 310 messages while providing protection against packet loss. P2P-RPL 311 also uses the routing metrics [RFC6551], objective functions and 312 packet forwarding framework [RFC6554][RFC6553] developed for core 313 RPL. 315 An Origin may use P2P-RPL to discover routes to one or more Target(s) 316 identified by one or more unicast/multicast addresses. P2P-RPL 317 allows for the discovery of one Hop-by-hop Route or up to four Source 318 Routes per Target. The discovered routes are guaranteed to meet the 319 specified routing metric constraints but may not be the best 320 available. P2P-RPL may fail to discover any route if the specified 321 routing constraints are overly strict. 323 The Origin initiates a P2P-RPL route discovery by forming a temporary 324 DAG rooted at itself. The DIOs used to create the temporary DAG are 325 identified by a new Mode of Operation (P2P Route Discovery mode 326 defined in Section 6). The DIOs listing the P2P Route Discovery mode 327 as the Mode of Operation are henceforth referred to as the P2P mode 328 DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery 329 Option (P2P-RDO, defined in Section 7) in which the Origin specifies 330 the following information: 332 o The IPv6 address of a Target. This could be a unicast address or 333 a multicast address. Any additional Targets may be specified by 334 including one or more RPL Target Options [RFC6550] inside the DIO. 336 o The nature of the route(s) to be discovered: Hop-by-hop or Source 337 Routes. This specification allows for the discovery of one Hop- 338 by-hop Route or up to four Source Routes per Target. 340 o The desired number of routes (if Source Routes are being 341 discovered). 343 o Whether the Target(s) should send P2P Discovery Reply Object (P2P- 344 DRO) messages (defined in Section 8) back to the Origin on 345 receiving a DIO message. A P2P-DRO message carries a discovered 346 Source Route back to the Origin or establishes a Hop-by-hop Route 347 between the Origin and the Target. 349 A P2P-RDO also includes the best route from the Origin that the 350 router, generating the P2P mode DIO, has seen so far. 352 A P2P mode DIO MAY also carry: 354 o One or more Metric Container Options to specify: 356 * The relevant routing metrics. 358 * The constraints that the discovered route must satisfy. These 359 constraints also limit how far the DIOs message may travel. 361 o One or more RPL Target options to specify additional unicast or 362 multicast Targets. 364 As the routers join the temporary DAG, they keep track of the best 365 route(s) (so far from the Origin) they have seen and advertise these 366 routes, along with the corresponding routing metrics, in their P2P 367 mode DIOs. A router, including the Target(s), discards a received 368 P2P mode DIO if the aggregated routing metrics on the route 369 advertised by the DIO do not satisfy the listed constraints. These 370 constraints can be used to limit the propagation of P2P mode DIO 371 messages. A router may also discard a received P2P mode DIO if it 372 does not wish to be a part of the discovered route due to limited 373 resources or due to policy reasons. 375 When a Target receives a P2P mode DIO, it contains inside the P2P-RDO 376 a complete Source Route from the Origin to this Target. Since the 377 links in the discovered route have bidirectional reachability 378 (Section 7), the Target may use the discovered route to reach the 379 Origin. Thus, a router that provides a particular service in the LLN 380 (e.g. an outside temperature server) could initiate a P2P-RPL route 381 discovery listing all its potential clients as Targets, thereby 382 allowing the clients to discover a Source Route back to the server. 383 In this case, the Origin (the server) might want to disable the 384 generation of P2P-DRO messages by the Targets (the clients). If the 385 Origin has requested P2P-DRO messages to be sent back, the Target may 386 select the discovered route in the received DIO for further 387 processing as described next. This document does not specify a 388 particular method for the Target to use to select a route for further 389 processing. Example methods include selecting any route that meets 390 the constraints or selecting the best route(s) discovered over a 391 certain time period. 393 If one or more Source Route(s) are being discovered, the Target sends 394 the selected Source Route(s) to the Origin via P2P-DRO messages with 395 one P2P-DRO message carrying one discovered route. On receiving a 396 P2P-DRO message, the Origin stores the discovered route in its 397 memory. This specification allows the Origin to discover up to four 398 Source Routes per Target, thereby allowing the Origin to have 399 sufficient ready-to-use alternatives should one or more of these 400 routes fail. If a Hop-by-hop Route is being discovered, the Target 401 sends a P2P-DRO message containing the selected route to the Origin. 402 The P2P-DRO message travels back to the Origin along the selected 403 route, establishing state for the Forward Route in the routers on the 404 path. 406 The Target may request the Origin to acknowledge the receipt of a 407 P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO- 408 ACK) message (defined in Section 10). The Origin unicasts a P2P-DRO- 409 ACK message to the Target. If the Target does not receive the 410 requested P2P-DRO-ACK within a certain time interval of sending a 411 P2P-DRO, it resends the P2P-DRO message (up to a certain number of 412 times) carrying the same route as before. 414 The use of trickle timers to delay the propagation of DIO messages 415 may cause some nodes to generate these messages even when the desired 416 routes have already been discovered. In order to preempt the 417 generation of such unnecessary messages, the Target may set a "Stop" 418 flag in the P2P-DRO message to let the nodes in the LLN know about 419 the completion of the route discovery process. The routers receiving 420 such a P2P-DRO should not generate any more DIOs for this temporary 421 DAG. Neither should they process any received DIOs for this 422 temporary DAG in future. However, such routers must still process 423 the P2P-DROs received for this temporary DAG. 425 6. P2P Route Discovery Mode Of Operation 427 This section specifies a new RPL Mode of Operation (MOP), P2P Route 428 Discovery Mode (or P2P mode, for short), with value TBD1. A DIO 429 message, listing P2P mode as the MOP, is identified as performing a 430 P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO 431 MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified 432 in Section 7). 434 6.1. Setting a P2P Mode DIO 436 The Base Object in a P2P mode DIO message MUST be set in the 437 following manner: 439 o RPLInstanceID: RPLInstanceID MUST be a local value as described in 440 Section 5.1 of [RFC6550]. The Origin chooses the RPLInstanceID to 441 be used for a particular route discovery in accordance with the 442 following rules: 444 * The Origin SHOULD NOT reuse an RPLInstanceID for a route 445 discovery if some routers might still maintain membership in 446 the DAG the Origin had initiated for the previous route 447 discovery using this RPLInstanceID. As described in Section 7, 448 a router's membership in a DAG created for a P2P-RPL route 449 discovery lasts for the time duration (say 'l' seconds) 450 indicated by the L field inside the P2P-RDO. In general, there 451 is no upper bound on the time duration by when all the routers 452 have left the DAG created for a P2P-RPL route discovery. In 453 the specific case where the discovered route must be at most 454 'n' hops in length, all the routers must have left the DAG 455 "(n+1)*l" seconds after its initiation by the Origin. In 456 practice, all the routers should have joined the DAG within 'l' 457 seconds of its initiation (since the route discovery must 458 complete while the Origin still belongs to the DAG) and hence 459 all the routers should have left the DAG within "2*l" seconds 460 of its initiation. Hence, it is usually sufficient that the 461 Origin wait for twice the duration indicated by the L field 462 inside the P2P-RDO used for the previous route discovery before 463 reusing the RPLInstanceID for a new route discovery. 464 Individual P2P-RPL deployments are encouraged to share their 465 experience with various RPLInstanceID reuse policies to help 466 guide the development of standards track version of the 467 protocol. 469 * When initiating a new route discovery to a particular Target, 470 the Origin MUST NOT reuse the RPLInstanceID used in a previous 471 route discovery to this Target if the state created during the 472 previous route discovery might still exist in some routers. 473 Note that it is possible that the previous route discovery did 474 not succeed yet some routers still ended up creating state. 475 The Default Lifetime and Lifetime Unit parameters in the DODAG 476 Configuration Option specify the lifetime of the state the 477 routers, including the Origin and the Target, maintain for a 478 Hop-by-hop or a Source Route discovered using P2P-RPL. Suppose 479 this lifetime is 'X' seconds. As discussed above, any state 480 created during the previous route discovery was likely created 481 within "2*l" seconds of its initiation. Hence, it is 482 sufficient that the Origin lets a time duration equal to 483 "X+2*l" seconds pass since the initiation of the previous route 484 discovery before initiating a new route discovery to the same 485 Target using the same RPLInstanceID. 487 o Version Number: MUST be set to zero. The temporary DAG used for 488 P2P-RPL route discovery does not exist long enough to have new 489 versions. 491 o Grounded (G) Flag: This flag MUST be set to one. Unlike a global 492 RPL instance, the concept of a floating DAG, used to provide 493 connectivity within a sub-DAG detached from a grounded DAG, does 494 not apply to a local RPL instance. Hence, an Origin MUST always 495 set the G flag to one when initiating a P2P-RPL route discovery. 496 Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply 497 and a node MUST NOT initiate a new DAG if it does not have any 498 parent left in a P2P-RPL DAG. 500 o Mode of Operation (MOP): MUST be set to TBD1, corresponding to P2P 501 Route Discovery mode. 503 o DTSN: MUST be set to zero on transmission and ignored on 504 reception. 506 o DODAGPreference (Prf): This field MUST be set to zero (least 507 preferred). 509 o DODAGID: This field MUST be set to an IPv6 address of the Origin. 511 o The other fields in the DIO Base Object can be set in the desired 512 fashion as per the rules described in [RFC6550]. 514 A received P2P mode DIO MUST be discarded if it does not follow the 515 above-listed rules regarding the RPLInstanceID, Version Number, G 516 flag, MOP and Prf fields inside the base object. 518 The DODAG Configuration Option, inside a P2P mode DIO MUST be set in 519 the following manner: 521 o The Origin MUST set the MaxRankIncrease parameter to zero to 522 disable local repair of the temporary DAG. A received P2P mode 523 DIO MUST be discarded if the MaxRankIncrease parameter inside the 524 DODAG Configuration Option is not zero. 526 o The Origin SHOULD set the Trickle parameters 527 (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as 528 recommended in Section 9.2. 530 o The Origin sets the Default Lifetime and Lifetime Unit parameters 531 to indicate the lifetime of the state the routers, including the 532 Origin and the Target(s), maintain for a Hop-by-hop or a Source 533 Route discovered using P2P-RPL. 535 o The Origin sets the other fields in the DODAG Configuration 536 Option, including the OCP identifying the Objective function, in 537 the desired fashion as per the rules described in [RFC6550]. 539 o An Intermediate Router (or a Target) MUST set various fields in 540 the DODAG Configuration Option in the outgoing P2P mode DIOs to 541 the values they had in the incoming P2P mode DIOs for this DAG. 543 A default DODAG Configuration Option comes in effect if a P2P mode 544 DIO does not carry an explicit one. The default DODAG Configuration 545 Option has the following parameter values: 547 o Authentication Enabled: 0 549 o DIOIntervalMin: 6, which translates to 64ms as the value for Imin 550 parameter in Trickle operation. This value is roughly one order 551 of magnitude larger than the typical transmission delay on IEEE 552 802.15.4 links and corresponds to the recommendation in 553 Section 9.2 for well-connected topologies. 555 o DIORedundancyConstant: 1. See the discussion in Section 9.2. 557 o MaxRankIncrease: 0 (to disable local repair of the temporary DAG). 559 o Default Lifetime: 0xFF, to correspond to infinity. 561 o Lifetime Unit: 0xFFFF, to correspond to infinity. 563 o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default 564 objective function. 566 o The remaining parameters have default values as specified in 567 [RFC6550]. 569 Individual P2P-RPL deployments are encouraged to share their 570 experience with these default values to help guide the development of 571 standards track version of the protocol. 573 The routing metrics and constraints [RFC6551] used in P2P-RPL route 574 discovery are included in one or more Metric Container Options 575 [RFC6550] inside the P2P mode DIO. Note that a DIO need not include 576 a Metric Container if OF0 is the objective function in effect. In 577 that case, a P2P mode DIO may still specify an upper limit on the 578 maximum rank, that a router may have in the temporary DAG, inside the 579 P2P-RDO. 581 A P2P mode DIO: 583 o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the 584 specification of one unicast or multicast address for the Target. 585 A received P2P mode DIO MUST be discarded if it does not contain 586 exactly one P2P-RDO. 588 o MAY carry one or more RPL Target Options to specify additional 589 unicast/multicast addresses for the Target. If a unicast address 590 is specified, it MUST be a global address or a unique local 591 address. 593 o MAY carry one or more Metric Container Options to specify routing 594 metrics and constraints. 596 o MAY carry one or more Route Information Options [RFC6550]. In the 597 context of P2P-RPL, a Route Information Option advertizes to the 598 Target(s) the Origin's connectivity to the prefix specified in the 599 option. 601 An RPL Option, besides the ones listed above, MUST be ignored when 602 found inside a received P2P mode DIO and MUST NOT be included in the 603 P2P mode DIOs the receiving router generates. 605 In accordance with core RPL, a P2P mode DIO MUST propagate via link- 606 local multicast. The IPv6 source address in a P2P mode DIO MUST be a 607 link-local address and the IPv6 destination address MUST be the link- 608 local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO MUST 609 be transmitted on all interfaces the router has in this RPL domain 610 [I-D.ietf-roll-terminology]. 612 7. P2P Route Discovery Option (P2P-RDO) 614 This section defines a new RPL control message option: the P2P Route 615 Discovery Option (P2P-RDO). 617 - 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 | TargetAddr | 625 | | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | 629 | Address[1..n] | 630 | | 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 1: Format of P2P Route Discovery Option (P2P-RDO) 636 The format of a P2P Route Discovery Option (P2P-RDO) is illustrated 637 in Figure 1. A P2P mode DIO and a P2P-DRO (defined in Section 8) 638 message MUST carry exactly one P2P-RDO. A P2P-RDO consists of the 639 following fields: 641 o Option Type: TBD2. 643 o Option Length: 8-bit unsigned integer, representing the length in 644 octets of the option, not including the Option Type and Option 645 Length fields. 647 o Reply (R): The Origin sets this flag to one to allow the Target(s) 648 to send P2P-DRO messages back to the Origin. If this flag is 649 zero, a Target MUST NOT generate any P2P-DRO message. 651 o Hop-by-hop (H): This flag is valid only if the R flag is set to 652 one. The Origin sets this flag to one if it desires Hop-by-hop 653 Routes. The Origin sets this flag to zero if it desires Source 654 Routes. This specification allows for the establishment of one 655 Hop-by-hop route or up to four Source Routes per Target. The Hop- 656 by-hop Route is established in the Forward direction, i.e. from 657 the Origin to the Target. This specification does not allow for 658 the establishment of Hop-by-hop Routes in the Reverse direction. 660 o Number of Routes (N): This field is valid only if the R flag is 661 one and H flag is zero, i.e. the Targets are allowed to generate 662 P2P-DRO messages carrying discovered Source Routes back to the 663 Origin. In this case, the value in the N field plus one indicates 664 the number of Source Routes that each Target should convey to the 665 Origin. When Hop-by-hop Routes are being discovered, the N field 666 MUST be set to zero on transmission and ignored on reception. 668 o Compr: 4-bit unsigned integer indicating the number of prefix 669 octets that are elided from the Target field and the Address 670 vector. For example, Compr value will be zero if full IPv6 671 addresses are carried in the Target field and the Address vector. 673 o Life Time (L): A 2-bit field that indicates the exact duration a 674 router joining the temporary DAG, including the Origin and the 675 Target(s), MUST maintain its membership in the DAG. A router MUST 676 leave the temporary DAG once the time elapsed since it joined 677 reaches the value indicated by this field. The mapping between 678 the value in this field and the duration of the router's 679 membership in the temporary DAG is as follows: 681 * 0x00: 1 second; 683 * 0x01: 4 seconds; 685 * 0x02: 16 seconds; 687 * 0x03: 64 seconds; 689 The Origin sets this field based on its expectation regarding the 690 time required for the route discovery to complete, which includes 691 the time required for the DIOs to reach the Target(s) and the P2P- 692 DROs to travel back to the Origin. The time required for the DIOs 693 to reach the Target(s) would in turn depend on the Trickle 694 parameters (Imin and the redundancy constant) as well as the 695 expected distance (in terms of hops and/or ETX) to the Target(s). 696 While deciding the value in this field, the Origin should also 697 take in account the fact that all routers joining the temporary 698 DAG would need to stay in the DAG for this much time. 700 o MaxRank/NH: 702 * When a P2P-RDO is included in a P2P mode DIO, this field 703 indicates the upper limit on the integer portion of the rank 704 (calculated using the DAGRank() macro defined in [RFC6550]) 705 that a router may have in the temporary DAG being created. An 706 Intermediate Router MUST NOT join a temporary DAG being created 707 by a P2P mode DIO if the integer portion of its rank would be 708 equal to or higher (in numerical value) than the MaxRank limit. 709 A Target can join the temporary DAG at a rank whose integer 710 portion is equal to the MaxRank. A router MUST discard a 711 received P2P mode DIO if the integer part of the advertized 712 rank equals or exceeds the MaxRank limit. A value 0 in this 713 field indicates that the MaxRank is infinity. 715 * When a P2P-RDO is included in a P2P-DRO message, this field 716 indicates the index of the next hop address inside the Address 717 vector. 719 o TargetAddr: An IPv6 address of the Target after eliding Compr 720 number of prefix octets. When the P2P-RDO is included in a P2P 721 mode DIO, this field may contain a unicast address or a multicast 722 address. If a unicast address is specified, it MUST be a global 723 address or a unique local address. Any additional Target 724 addresses can be specified by including one or more RPL Target 725 Options [RFC6550] in the DIO. When the P2P-RDO is included in a 726 P2P-DRO, this field MUST contain a unicast global or unique local 727 IPv6 address of the Target generating the P2P-DRO. 729 o Address[1..n]: A vector of IPv6 addresses representing a complete 730 route so far in the Forward direction: 732 * Each element in the Address vector has size (16 - Compr) octets 733 and MUST contain a valid global or unique local IPv6 address 734 with first Compr octets elided. 736 * The total number of elements inside the Address vector is given 737 by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). 739 * The IPv6 address that a router adds to the vector MUST belong 740 to the interface on which the router received the DIO 741 containing this P2P-RDO. Further, this interface MUST NOT be 742 an Ingress-only Interface. This allows the route accumulated 743 in the Address vector to be a Bidirectional Route that can be 744 used by a Target to send a P2P-DRO message to the Origin. 746 * The Address vector MUST carry the accumulated route in the 747 Forward direction, i.e., the first element in the Address 748 vector must contain the IPv6 address of the router next to the 749 Origin and so on. 751 * The Origin and Target addresses MUST NOT be included in the 752 Address vector. 754 * A router adding its address to the vector MUST ensure that any 755 of its addresses do not already exist in the vector. A Target 756 specifying a complete route in the Address vector MUST ensure 757 that the vector does not contain any address more than once. 759 * The Address vector MUST NOT contain any multicast addresses. 761 8. The P2P Discovery Reply Object (P2P-DRO) 763 This section defines two new RPL Control Message types, the P2P 764 Discovery Reply Object (P2P-DRO), with code TBD3, and the Secure P2P- 765 DRO, with code TBD4. A P2P-DRO serves one of the following 766 functions: 768 o Carry a discovered Source Route from a Target to the Origin; 770 o Establish a Hop-by-hop Route as it travels from a Target to the 771 Origin. 773 A P2P-DRO message can also serve the function of letting the routers 774 in the LLN know that a P2P-RPL route discovery is complete and no 775 more DIO messages need to be generated for the corresponding 776 temporary DAG. A P2P-DRO message MUST carry one (and only one) P2P- 777 RDO whose TargetAddr field MUST contain a unicast IPv6 address of the 778 Target that generates the P2P-DRO. A P2P-DRO message MUST travel 779 from the Target to the Origin via link-local multicast along the 780 route specified inside the Address vector in the P2P-RDO, as included 781 in the P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be 782 a link-local address and the IPv6 destination address MUST be the 783 link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO 784 message MUST be transmitted on all interfaces the router has in this 785 RPL domain [I-D.ietf-roll-terminology]. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | RPLInstanceID | Version |S|A|Seq| Reserved | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | | 793 | DODAGID | 794 | | 795 | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Option(s)... 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 800 Figure 2: Format of the base P2P Discovery Reply Object (P2P-DRO) 802 The format of the base P2P Discovery Reply Object (P2P-DRO) is shown 803 in Figure 2. A base P2P-DRO consists of the following fields: 805 o RPLInstanceID: The RPLInstanceID of the temporary DAG used for 806 route discovery. 808 o Version: The Version of the temporary DAG used for route 809 discovery. Since a temporary DAG always has value zero for the 810 Version, this field MUST always be set to zero. 812 o Stop (S): This flag, when set to one by a Target, indicates that 813 the P2P-RPL route discovery is over. All the routers receiving 814 such a P2P-DRO, including the ones not listed in the route carried 815 inside P2P-RDO, 817 * SHOULD NOT process any more DIOs received for this temporary 818 DAG; 820 * SHOULD NOT generate any more DIOs for this temporary DAG; 822 * SHOULD cancel any pending DIO transmission for this temporary 823 DAG. 825 Note that the Stop flag serves to stop further DIO generation/ 826 processing for a P2P-RPL route discovery but it does not affect 827 the processing of P2P-DRO messages at either the Origin or the 828 Intermediate Routers. In other words, a router (the Origin or an 829 Intermediate Router) MUST continue to process the P2P-DRO messages 830 even if an earlier P2P-DRO message (with the same RPLInstanceID 831 and DODAGID fields) had the Stop flag set to one. When set to 832 zero, this flag does not imply any thing and MUST be ignored on 833 reception. 835 o Ack Required (A): This flag, when set to one by the Target, 836 indicates that the Origin MUST unicast a P2P-DRO-ACK message 837 (defined in Section 10) to the Target when it receives the P2P- 838 DRO. 840 o Sequence Number (Seq): This 2-bit field indicates the sequence 841 number for the P2P-DRO. This field is relevant when the A flag is 842 set to one, i.e., the Target requests an acknowledgement from the 843 Origin for a received P2P-DRO. The Origin includes the 844 RPLInstanceID, the DODAGID and the Sequence Number of the received 845 P2P-DRO inside the P2P-DRO-ACK message it sends back to the 846 Target. 848 o Reserved: These bits are reserved for future use. These bits MUST 849 be set to zero on transmission and MUST be ignored on reception. 851 o DODAGID: The DODAGID of the temporary DAG used for route 852 discovery. The DODAGID also identifies the Origin. The 853 RPLInstanceID, the Version and the DODAGID together uniquely 854 identify the temporary DAG used for route discovery and can be 855 copied from the DIO message advertizing the temporary DAG. 857 o Options: The P2P-DRO message: 859 * MUST carry one (and only one) P2P-RDO that MUST specify a 860 complete route between the Target and the Origin. A received 861 P2P-DRO message MUST be discarded if it does not contain 862 exactly one P2P-RDO. 864 * MAY carry one or more Metric Container Options that contains 865 the aggregated routing metrics values for the route specified 866 in P2P-RDO. 868 An RPL Option, besides the ones listed above, MUST be ignored when 869 found inside a received P2P-DRO message. 871 8.1. Secure P2P-DRO 873 A Secure P2P-DRO message follows the format in Figure 7 of [RFC6550], 874 where the base format is the base P2P-DRO shown in Figure 2. 876 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object 878 A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, 879 which MUST be set as defined in Section 7. Specifically, the 880 following fields MUST be set as specified next: 882 o Reply (R): This flag MUST be set to zero on transmission and 883 ignored on reception. 885 o Hop-by-Hop (H): The H flag in the P2P-RDO included in a P2P-DRO 886 message MUST have the same value as the H flag in the P2P-RDO 887 inside the corresponding DIO message. 889 o Number of Routes (N): This field MUST be set to zero on 890 transmission and ignored on reception. 892 o Life Time (L): This field MUST be set to zero on transmission and 893 ignored on reception. 895 o MaxRank/NH: This field indicates the index of the next hop address 896 in the Address vector. When a Target generates a P2P-DRO message, 897 the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 898 - Compr). 900 o TargetAddr: This field MUST contain a unicast global or unique 901 local IPv6 address of the Target generating the P2P-DRO. 903 o Address[1..n]: The Address vector MUST contain a complete route 904 between the Origin and the Target such that the first element in 905 the vector contains the IPv6 address of the router next to the 906 Origin and the last element contains the IPv6 address of the 907 router next to the Target. 909 9. P2P-RPL Route Discovery By Creating a Temporary DAG 911 This section details the P2P-RPL route discovery operation. 913 9.1. Joining a Temporary DAG 915 All the routers participating in a P2P-RPL route discovery, including 916 the Origin and the Target(s), MUST join the temporary DAG being 917 created for the purpose. When a router joins a temporary DAG 918 advertized by a P2P mode DIO, it MUST maintain its membership in the 919 temporary DAG for the duration indicated by the L field inside the 920 P2P-RDO. The only purpose of a temporary DAG's existence is to 921 facilitate the P2P-RPL route discovery process. The temporary DAG 922 MUST NOT be used to route data packets. In other words, joining a 923 temporary DAG does not allow a router to provision routing table 924 entries listing the router's parents in the temporary DAG as the next 925 hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is 926 not applicable when the DAG is a temporary DAG created for the 927 purpose of a P2P-RPL route discovery.). 929 Given the nature of a temporary DAG created for a P2P-RPL route 930 discovery, this document disallows the solicitation of P2P mode DIOs 931 using DODAG Information Solicitation (DIS) messages as described in 932 [RFC6550]. A router participating in a P2P-RPL route discovery MUST 933 NOT reset its Trickle timer that controls the transmission of P2P 934 mode DIOs in response to a multicast DIS. Also, the router MUST NOT 935 send a P2P mode DIO in response to a unicast DIS. In other words, 936 the rules in Section 8.3 of [RFC6550] regarding a router's response 937 to a multicast/unicast DIS are not applicable for P2P mode DIOs. 939 A router MUST detach from the temporary DAG created for a P2P-RPL 940 route discovery once the duration of its membership in the DAG has 941 reached the value indicated by the L field inside the P2P-RDO. After 942 receiving a P2P-DRO with the Stop flag set to one, a router SHOULD 943 NOT send or process any more DIOs for this temporary DAG and SHOULD 944 also cancel any pending DIO transmission. 946 9.2. Trickle Operation For P2P Mode DIOs 948 An RPL router uses a Trickle timer [RFC6206] to control DIO 949 transmissions. The Trickle control of DIO transmissions provides 950 quick resolution of any "inconsistency" while avoiding redundant DIO 951 transmissions. The Trickle algorithm also imparts protection against 952 loss of DIOs due to inherent lack of reliability in LLNs. When 953 controlling the transmissions of a P2P mode DIO, a Trickle timer 954 SHOULD follow the following rules: 956 o The receipt of a P2P mode DIO, that allows the router to advertise 957 a better route (in terms of the routing metrics and the OF in use) 958 than before, is considered "inconsistent" and hence resets the 959 Trickle timer. Note that the first receipt of a P2P mode DIO 960 advertising a particular temporary DAG is always considered an 961 "inconsistent" event. 963 o The receipt of a P2P mode DIO from a parent in the temporary DAG 964 is considered neither "consistent" nor "inconsistent" if it does 965 not allow the router to advertise a better route than before. 966 Thus, the receipt of such DIOs has no impact on the Trickle 967 operation. Note that this document does not impose any 968 requirements on how a router might choose its parents in the 969 temporary DAG. 971 o The receipt of a P2P mode DIO is considered "consistent" if the 972 source of the DIO is not a parent in the temporary DAG and either 973 of the following conditions is true: 975 * The DIO advertises a better route than the router but does not 976 allow the router to advertise a better route itself; or 978 * The DIO advertises a route as good as the route (to be) 979 advertised by the router. 981 Note that the Trickle algorithm's DIO suppression rules are in 982 effect at all times. Hence, a P2P-RPL router may suppress a DIO 983 transmission even if it has not made any DIO transmission yet. 985 o The receipt of a P2P mode DIO, that advertises a worse route than 986 what the router advertises (or would advertise when it gets a 987 chance to generate its DIO), is considered neither "consistent" 988 nor "inconsistent", i.e., the receipt of such a DIO has no impact 989 on the Trickle operation. 991 o The Imin parameter SHOULD be set taking in account the 992 connectivity within the network. For highly connected networks, a 993 small Imin value (of the order of the typical transmission delay 994 for a DIO) may lead to congestion in the network as a large number 995 of routers reset their Trickle timers in response to the first 996 receipt of a DIO from the Origin. These routers would generate 997 their DIOs within Imin interval and cause additional routers to 998 reset their trickle timers and generate more DIOs. Thus, for 999 highly connected networks, the Imin parameter SHOULD be set to a 1000 value at least one order of magnitude larger than the typical 1001 transmission delay for a DIO. For sparsely connected networks, 1002 the Imin parameter can be set to a value that is a small multiple 1003 of the typical transmission delay for a DIO. Note that the Imin 1004 value has a direct impact on the time required for a P2P-RPL route 1005 discovery to complete. In general, the time required for a P2P- 1006 RPL route discovery would increase approximately linearly with the 1007 value of the Imin parameter. Since the route discovery must 1008 complete while the Origin still belongs to the temporary DAG 1009 created for the purpose, the Origin should set the time duration a 1010 router maintains its membership in the temporary DAG (indicated by 1011 the L field inside the P2P-RDO) to a large enough value taking in 1012 account the Imin value as well as the expected distance (in terms 1013 of hops and/or ETX) to the Target(s). 1015 o The Imax parameter SHOULD be set to a large value (several orders 1016 of magnitude higher than the Imin value) and is unlikely to be 1017 critical for P2P-RPL operation. This is because the first receipt 1018 of a P2P mode DIO for a particular temporary DAG is considered an 1019 inconsistent event and would lead to resetting of Trickle timer 1020 duration to the Imin value. Given the temporary nature of the 1021 DAGs used in P2P-RPL, Trickle timer may not get a chance to 1022 increase much. 1024 o The recommended value of redundancy constant "k" is 1. With this 1025 value of "k", a DIO transmission will be suppressed if the router 1026 receives even a single "consistent" DIO during a timer interval. 1027 This setting for the redundancy constant is designed to reduce the 1028 number of messages generated during a route discovery process and 1029 is suitable for the environments with low or moderate packet loss 1030 rates. However, this setting may result in an increase in the 1031 time required for the route discovery process to complete. A 1032 higher value for the redundancy constant may be more suitable in 1034 * Environments with high packet loss rates; or 1036 * Deployments where the time required for the route discovery 1037 process to complete needs to be as small as possible; or 1039 * Deployments where specific destinations are reachable only 1040 through specific intermediate routers (and hence these 1041 intermediate routers should not suppress their DIOs). 1043 A particular deployment should take in account the above mentioned 1044 factors when deciding the value of the redundancy constant. 1046 Individual P2P-RPL deployments are encouraged to share their 1047 experience with these rules to help guide the development of 1048 standards track version of the protocol. Applicability Statements 1049 that specify the use of P2P-RPL MUST provide guidance for setting 1050 Trickle parameters, particularly Imin and the redundancy constant. 1052 9.3. Processing a P2P Mode DIO 1054 The rules for DIO processing and transmission, described in Section 8 1055 of RPL [RFC6550], apply to P2P mode DIOs as well except as modified 1056 in this document. In particular, in accordance with Section 8.2.3 of 1057 RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is 1058 malformed according to the rules specified in this document and in 1059 [RFC6550]. 1061 The following rules for processing a received P2P mode DIO apply to 1062 both Intermediate Routers and the Target. 1064 A router SHOULD discard a received P2P mode DIO with no further 1065 processing if it does not have bidirectional reachability with the 1066 neighbor that generated the received DIO. Note that bidirectional 1067 reachability does not mean that the link must have the same values 1068 for a routing metric in both directions. A router SHOULD calculate 1069 the values of the link-level routing metrics included in the received 1070 DIO taking in account the metric's value in both Forward and Reverse 1071 directions. Bidirectional reachability along a discovered route 1072 allows the Target to use this route to reach the Origin. In 1073 particular, the P2P-DRO messages travel from the Target to the Origin 1074 along a discovered route. 1076 A router MUST discard a received P2P mode DIO with no further 1077 processing: 1079 o If the DIO advertises INFINITE_RANK as defined in Section 17 of 1080 [RFC6550]. 1082 o If the integer part of the rank advertised in the DIO equals or 1083 exceeds the MaxRank limit listed in the P2P Route Discovery 1084 Option. 1086 o If the routing metric values do not satisfy one or more of the 1087 mandatory route constraints listed in the DIO or if the router 1088 cannot evaluate the mandatory route constraints, e.g., if the 1089 router does not support the metrics used in the constraints. 1091 o If the router previously received a P2P-DRO message with the same 1092 RPLInstanceID and DODAGID as the received DIO and with the Stop 1093 flag set to one. 1095 The router MUST check the Target addresses listed in the P2P-RDO and 1096 any RPL Target Options included in the received DIO. If one of its 1097 IPv6 addresses is listed as a Target address or if it belongs to the 1098 multicast group specified as one of the Target addresses, the router 1099 considers itself a Target and processes the received DIO as specified 1100 in Section 9.5. Otherwise, the router considers itself an 1101 Intermediate Router and processes the received DIO as specified in 1102 Section 9.4. 1104 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 1106 An Intermediate Router MUST discard a received P2P mode DIO with no 1107 further processing 1109 o if the DIO is received on an Ingress-only Interface; or 1111 o if the receiving interface does not have a global or unique local 1112 IPv6 address configured with the address prefix implied by the 1113 Compr field in the P2P-RDO inside the received DIO; or 1115 o if the router can not uniquely identify the address prefix implied 1116 by the Compr field in the P2P-RDO (this might happen if the 1117 receiving interface has multiple global/unique-local IPv6 1118 addresses, each configured with a different address prefix); or 1120 o if adding its IPv6 address to the route in the Address vector 1121 inside the P2P-RDO would result in the route containing multiple 1122 addresses belonging to this router. 1124 On receiving a P2P mode DIO, an Intermediate Router MUST do the 1125 following. The router MUST determine whether this DIO advertises a 1126 better route than the router itself and whether the receipt of the 1127 DIO would allow the router to advertise a better route than before. 1128 Accordingly, the router SHOULD consider this DIO as consistent/ 1129 inconsistent from Trickle perspective as described in Section 9.2. 1130 Note that the route comparison in a P2P-RPL route discovery is 1131 performed using the parent selection rules of the OF in use as 1132 specified in Section 14 of RPL [RFC6550]. If the received DIO would 1133 allow the router to advertise a better route, the router MUST add a 1134 unicast IPv6 address of the receiving interface (after eliding Compr 1135 prefix octets) to the route in the Address vector inside the P2P-RDO 1136 and remember this route for inclusion in its future DIOs. 1138 When an Intermediate Router adds an IPv6 address to a route, it MUST 1139 ensure that 1141 o the IPv6 address is a unicast global or unique local IPv6 address 1142 assigned to the interface on which the DIO containing the route 1143 was received; 1145 o the IPv6 address was configured with the address prefix implied by 1146 the Compr field in the P2P-RDO inside the received DIO; 1148 To improve the diversity of the routes being discovered, an 1149 Intermediate Router SHOULD keep track of multiple routes (as long as 1150 all these routes are the best seen so far), one of which SHOULD be 1151 selected in a uniform random manner for inclusion in the P2P-RDO 1152 inside the router's next DIO. Note that the route accumulation in a 1153 P2P mode DIO MUST take place even if the Origin does not want any 1154 P2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO 1155 is set to zero). This is because the Target may still be able to use 1156 the accumulated route as a source route to reach the Origin. 1158 9.5. Additional Processing of a P2P Mode DIO At The Target 1160 The Target MAY remember the discovered route contained in the P2P-RDO 1161 in the received DIO for use as a Source Route to reach the Origin. 1162 The lifetime of this Source Route is specified by the Default 1163 Lifetime and Lifetime Unit parameters inside the DODAG Configuration 1164 Option currently in effect. This lifetime can be extended (or 1165 shortened) appropriately following a hint from an upper-layer 1166 protocol. 1168 If the Reply flag inside the P2P-RDO in the received DIO is set to 1169 one, the Target MUST select one or more discovered routes and send 1170 one or more P2P-DRO messages, carrying one discovered route each, 1171 back to the Origin. If the H flag inside the P2P-RDO is set to one, 1172 the Target needs to select one route and send a P2P-DRO message along 1173 this route back to the Origin. As this P2P-DRO message travels back 1174 to the Origin, the routers on the path establish hop-by-hop routing 1175 state, thereby establishing a Hop-by-hop Route in the Forward 1176 direction. If the H flag is set to zero, the number of Source Routes 1177 to be selected (and the number of P2P-DRO messages to be sent back) 1178 is given by one plus the value of the N field in the P2P-RDO. The 1179 Target may select the discovered route inside the received DIO as 1180 (one of) the route(s) that would be carried inside a P2P-DRO message 1181 back to the Origin. This document does not prescribe a particular 1182 method for the Target to select the routes. Example methods include 1183 selecting each route that meets the specified routing constraints 1184 until the desired number have been selected or selecting the best 1185 routes discovered over a certain time period. If multiple routes are 1186 to be selected, the Target SHOULD avoid selecting routes that have 1187 large segments in common. 1189 If the Target selects the route contained in the P2P-RDO in the 1190 received DIO, it sends a P2P-DRO message back to the Origin 1191 (identified by the DODAGID field in the DIO). The P2P-DRO message 1192 MUST include a P2P-RDO that contains the selected route inside the 1193 Address vector. Various fields inside the P2P-RDO MUST be set as 1194 specified in Section 8.2. The Target MAY set the A flag inside the 1195 P2P-DRO message to one if it desires the Origin to send back a P2P- 1196 DRO-ACK message on receiving the P2P-DRO. In this case, the Target 1197 waits for P2P_DRO_ACK_WAIT_TIME duration for the P2P-DRO-ACK message 1198 to arrive. Failure to receive the P2P-DRO-ACK message within this 1199 time duration causes the Target to retransmit the P2P-DRO message. 1200 The Target MAY retransmit the P2P-DRO message in this fashion up to 1201 MAX_P2P_DRO_RETRANSMISSIONS times. Both P2P_DRO_ACK_WAIT_TIME and 1202 MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be decided 1203 based on the characteristics of individual deployments. Note that 1204 all P2P-DRO transmissions and retransmissions MUST take place while 1205 the Target is still a part of the temporary DAG created for the route 1206 discovery. A Target MUST NOT transmit a P2P-DRO if it no longer 1207 belongs to this DAG. 1209 The Target MAY set the Stop flag inside the P2P-DRO message to one if 1211 o this router is the only Target specified in the corresponding DIO, 1212 i.e., the corresponding DIO specified a unicast address of the 1213 router as the TargetAddr inside the P2P-RDO with no additional 1214 Targets specified via RPL Target Options; and 1216 o the Target has already selected the desired number of routes. 1218 The Target MAY include a Metric Container Option in the P2P-DRO 1219 message. This Metric Container contains the end-to-end routing 1220 metric values for the route specified in the P2P-RDO. The Target 1221 MUST transmit the P2P-DRO message via a link-local multicast. 1223 A Target MUST NOT forward a P2P mode DIO any further if no other 1224 Targets are to be discovered, i.e., if a unicast IPv6 address (of 1225 this Target) is specified as the TargetAddr inside the P2P-RDO and no 1226 additional Targets are specified via RPL Target Options inside the 1227 DIOs for this route discovery. Otherwise, the Target MUST generate 1228 DIOs for this route discovery as an Intermediate Router would. 1230 9.6. Processing a P2P-DRO At An Intermediate Router 1232 If the DODAGID field in the received P2P-DRO does not list a router's 1233 own IPv6 address, the router considers itself an Intermediate Router 1234 and MUST process the received message in the following manner: 1236 o The router MUST discard the received P2P-DRO with no further 1237 processing if it does not belong to the temporary DAG identified 1238 by the RPLInstanceID and the DODAGID fields in the P2P-DRO. 1240 o If the Stop flag inside the received P2P-DRO is set to one, the 1241 router SHOULD NOT send or receive any more DIOs for this temporary 1242 DAG and SHOULD cancel any pending DIO transmission. 1244 o The router MUST ignore any Metric Container Options contained in 1245 the P2P-DRO message. 1247 o If Address[NH] element inside the P2P-RDO lists the router's own 1248 unicast IPv6 address, the router is a part of the route carried in 1249 the P2P-RDO. In this case, the router MUST do the following: 1251 * To prevent loops, the router MUST discard the P2P-DRO message 1252 with no further processing if the Address vector in the P2P-RDO 1253 includes multiple IPv6 addresses assigned to the router's 1254 interfaces. 1256 * If the H flag inside the P2P-RDO is one, the router MUST store 1257 the state for the Forward Hop-by-hop route carried inside the 1258 P2P-RDO. This state consists of: 1260 + The RPLInstanceID and the DODAGID fields of the P2P-DRO. 1262 + The route's destination, the Target (identified by 1263 TargetAddr field inside P2P-RDO). 1265 + The IPv6 address of the next hop, Address[NH+1] (unless NH 1266 value equals the number of elements in the Address vector, 1267 in which case the Target itself is the next hop). 1269 This Hop-by-hop routing state MUST expire at the end of the 1270 lifetime specified by the Default Lifetime and Lifetime Unit 1271 parameters inside the DODAG Configuration Option used in P2P 1272 mode DIOs for this route discovery. 1274 * If the router already maintains a Hop-by-hop state listing the 1275 Target as the destination and carrying same RPLInstanceID and 1276 DODAGID fields as the received P2P-DRO and the next hop 1277 information in the state does not match the next hop indicated 1278 in the received P2P-DRO, the router MUST discard the P2P-DRO 1279 message with no further processing. Note that this situation 1280 would occur in the following two cases: 1282 + When the route listed in the Address vector inside the P2P- 1283 RDO contains a previously undetected loop. In this case, 1284 the rule above causes the P2P-DRO messages to be discarded. 1286 + When a Hop-by-hop Route between the Origin and the Target, 1287 previously established using the same RPLInstanceID and 1288 DODAGID as the route currently being established, still 1289 exists and at least partially overlaps the route currently 1290 being established. 1292 * The router MUST decrement the NH field inside the P2P-RDO and 1293 send the P2P-DRO message further via link-local multicast. 1295 9.7. Processing a P2P-DRO At The Origin 1297 When a router receives a P2P-DRO message that lists its IPv6 address 1298 in the DODAGID field, the router recognizes itself as the Origin for 1299 the corresponding P2P-RPL route discovery, notes the Target that 1300 originated this message (from the TargetAddr field inside the P2P- 1301 RDO) and processes the message in the following manner: 1303 o The Origin MUST discard the received P2P-DRO with no further 1304 processing if it no longer belongs to the temporary DAG identified 1305 by the RPLInstanceID and the DODAGID fields in the P2P-DRO. 1307 o If the Stop flag inside the received P2P-DRO is set to one, the 1308 Origin SHOULD NOT generate any more DIOs for this temporary DAG 1309 and SHOULD cancel any pending DIO transmission. 1311 o If the P2P-RDO inside the P2P-DRO has the H flag set to 0, the 1312 Address vector inside the P2P-RDO contains a Source Route to this 1313 Target. The Origin MUST set the lifetime of this Source Route to 1314 the value specified by the Default Lifetime and Lifetime Unit 1315 parameters inside the DODAG Configuration Option in the P2P mode 1316 DIOs used for this route discovery. This lifetime could be 1317 extended (or shortened) appropriately following a hint from an 1318 upper-layer protocol. 1320 o If the P2P-RDO inside the P2P-DRO has the H flag set to 1, the 1321 P2P-DRO message is establishing a Hop-by-hop Route to this Target 1322 and the Origin MUST store in its memory the state for this Hop-by- 1323 hop Route in the manner described in Section 9.6. This Hop-by-hop 1324 routing state MUST expire at the end of the lifetime specified by 1325 the Default Lifetime and Lifetime Unit parameters inside the DODAG 1326 Configuration Option used in P2P mode DIOs for this route 1327 discovery. The standards track version of P2P-RPL may consider 1328 specifying a signaling mechanism that will allow the Origin to 1329 extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route 1330 following a suitable hint from an upper-layer protocol. 1332 o If the received P2P-DRO message contains one or more Metric 1333 Container Options, the Origin MAY store the values of the routing 1334 metrics associated with the discovered route in its memory. This 1335 information may be useful in formulating the constraints for any 1336 future P2P-RPL route discovery to this Target. 1338 o If the A flag is set to one in the received P2P-DRO message, the 1339 Origin MUST generate a P2P-DRO-ACK message as described in 1340 Section 10 and unicast the message to the Target. The Origin MAY 1341 use the route just discovered to send the P2P-DRO-ACK message to 1342 the Target. Section 12 describes how a packet may be forwarded 1343 along a Source/Hop-by-hop Route discovered using P2P-RPL. 1345 10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) 1347 0 1 2 3 1348 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 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | RPLInstanceID | Version |Seq| Reserved | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | | 1353 | DODAGID | 1354 | | 1355 | | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 Figure 3: Format of the base P2P Discovery Reply Object 1359 Acknowledgement (P2P-DRO-ACK) 1361 A P2P-DRO message may fail to reach the Origin due to a number of 1362 reasons. Unlike the DIO messages that benefit from Trickle- 1363 controlled retransmissions, the P2P-DRO messages are prone to loss 1364 due to unreliable packet transmission in LLNs. Since a P2P-DRO 1365 message travels via link-local multicast, it cannot use link-level 1366 acknowledgements to improve the reliability of its transmission. 1367 Also, an Intermediate Router may drop the P2P-DRO message (e.g., 1368 because of its inability to store the state for the Hop-by-hop Route 1369 the P2P-DRO is establishing). To protect against the potential 1370 failure of a P2P-DRO message to reach the Origin, the Target MAY 1371 request the Origin to send back a P2P-DRO Acknowledgement (P2P-DRO- 1372 ACK) message on receiving a P2P-DRO message. Failure to receive such 1373 an acknowledgement within the P2P_DRO_ACK_WAIT_TIME interval of 1374 sending the P2P-DRO message forces the Target to resend the message 1375 (as described in Section 9.5). 1377 This section defines two new RPL Control Message types: P2P-DRO 1378 Acknowledgement (P2P-DRO-ACK; with code TBD5) and Secure P2P-DRO-ACK 1379 (with code TBD6). A P2P-DRO-ACK message MUST travel as a unicast 1380 message from the Origin to the Target. The IPv6 source and 1381 destination addresses used in a P2P-DRO-ACK message MUST be global or 1382 unique local. The format of a base P2P-DRO-ACK message is shown in 1383 Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same 1384 values as the corresponding fields in the P2P-DRO message. The field 1385 marked as "Reserved" MUST be set to zero on transmission and MUST be 1386 ignored on reception. A Secure P2P-DRO-ACK message follows the 1387 format in Figure 7 of [RFC6550], where the base format is same as the 1388 base P2P-DRO-ACK shown in Figure 3. 1390 11. Secure P2P-RPL Operation 1392 Each RPL control message type, including the ones defined in this 1393 document, has a secure version. A secure RPL control message is 1394 identified by the value 1 in the most significant bit of the Code 1395 field. Each secure RPL control message contains a security section 1396 (see Figure 7 of [RFC6550]), whose contents are described in Section 1397 6.1 of [RFC6550]. Sections 6.1, 10 and 19 of [RFC6550] describe core 1398 RPL's security apparatus. These sections are applicable to P2P-RPL's 1399 secure operation as well except as constrained in this section. 1401 Core RPL allows a router to decide locally on a per-packet basis 1402 whether to use security and if yes what Security Configuration (see 1403 definition in Section 3) to use (the only exception being the 1404 requirement to send a Secure DIO in response to a Secure DIS; see 1405 Section 10.2 of [RFC6550]). In contrast, this document requires 1406 routers participating in a P2P-RPL route discovery to follow the 1407 Origin's lead regarding security. The Origin decides whether to use 1408 security and the particular Security Configuration to be used for 1409 this purpose. All the routers participating in this route discovery 1410 MUST generate only secure control messages if the Origin decides so 1411 and MUST use for this purpose the Security Configuration that the 1412 Origin chose. The Origin MUST NOT set the "Key Identifier Mode" 1413 field inside the chosen Security Configuration to value 1 since this 1414 setting indicates the use of a per-pair key which is not suitable for 1415 securing messages that travel by (link local) multicast (e.g. DIOs) 1416 or that travel over multiple hops (e.g. P2P-DROs). The Origin MUST 1417 use the chosen Security Configuration to secure all the control 1418 messages (DIOs and P2P-DRO-ACKs) it generates. 1420 A router MUST NOT join the temporary DAG being created for a P2P-RPL 1421 route discovery if: 1423 o it receives both secure and unsecure DIOs or Secure DIOs with 1424 different Security Configurations pertaining to this route 1425 discovery (i.e., referring to the same RPLInstanceID and DODAGID 1426 combination) prior to joining; or 1428 o it can not use the Security Configuration found in the Secure DIOs 1429 pertaining to this route discovery. 1431 When a router (an Intermediate Router or a Target) joins a temporary 1432 DAG being created using Secure DIOs, it MUST remember the common 1433 Security Configuration used in the received Secured DIOs and MUST use 1434 this configuration to secure all the control messages (DIOs and P2P- 1435 DROs) it generates. 1437 If an Intermediate Router (or a Target) encounters a control message 1438 (a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route 1439 discovery that is either not secure or does not follow the Security 1440 Configuration the router remembers for this route discovery, the 1441 router MUST enter the "lock down" mode for the remainder of its stay 1442 in this temporary DAG. An Intermediate Router (or a Target) in the 1443 "lock down" mode MUST NOT generate or process any control message 1444 (irrespective of the Security Configuration used) pertaining to this 1445 route discovery. If the Origin receives a control message (a P2P- 1446 DRO) that does not follow the Security Configuration the Origin has 1447 chosen for this route discovery, it MUST discard the received message 1448 with no further processing. 1450 12. Packet Forwarding Along a Route Discovered Using P2P-RPL 1452 An Origin uses the Source Routing Header (SRH) [RFC6554] to send a 1453 packet along a Source Route discovered using P2P-RPL. 1455 Travel along a Hop-by-hop Route, established using P2P-RPL, requires 1456 specifying the RPLInstanceID and the DODAGID (of the temporary DAG 1457 used for the route discovery) to identify the route. This is because 1458 a P2P-RPL route discovery does not use globally unique RPLInstanceID 1459 values and hence both the RPLInstanceID (a local value assigned by 1460 the Origin) and the DODAGID (an IPv6 address of the Origin) are 1461 required to uniquely identify a P2P-RPL Hop-by-hop Route to a 1462 particular destination. 1464 An Origin includes an RPL option [RFC6553] inside the IPv6 hop-by-hop 1465 options header of a packet to send it along a Hop-by-hop Route 1466 established using P2P-RPL. For this purpose, the Origin MUST set the 1467 DODAGID of the temporary DAG used for the route discovery as the 1468 source IPv6 address of the packet. Further, the Origin MUST specify 1469 inside the RPL option the RPLInstanceID of the temporary DAG used for 1470 the route discovery and set the O flag inside the RPL option to one. 1471 On receiving this packet, an Intermediate Router checks the O flag 1472 and correctly infer the source IPv6 address of the packet as the 1473 DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, 1474 the RPLInstanceID and the destination address to identify the routing 1475 state to be used to forward the packet further. 1477 13. Interoperability with Core RPL 1479 This section describes how RPL routers that implement P2P-RPL 1480 interact with RPL routers that do not. In general, P2P-RPL operation 1481 does not affect core RPL operation and vice versa. However, core RPL 1482 does allow a router to join a DAG as a leaf node even if it does not 1483 understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL 1484 router that does not implement P2P-RPL may conceivably join a 1485 temporary DAG being created for a P2P-RPL route discovery as a leaf 1486 node and maintain its membership even though the DAG no longer 1487 exists. This may impose a drain on the router's memory. However, 1488 such RPL-only leaf nodes do not interfere with P2P-RPL route 1489 discovery since a leaf node may only generate a DIO advertising an 1490 INFINITE_RANK and all routers implementing P2P-RPL are required to 1491 discard such DIOs. Note that core RPL does not require a router to 1492 join a DAG whose MOP it does not understand. Moreover, RPL routers 1493 in a particular deployment may have strict restrictions on the DAGs 1494 they may join, thereby mitigating the problem. 1496 The P2P-RPL mechanism described in this document works best when all 1497 the RPL routers in the LLN implement P2P-RPL. In general, the 1498 ability to discover routes as well as the quality of discovered 1499 routes would deteriorate with the fraction of RPL routers that 1500 implement P2P-RPL. 1502 14. Security Considerations 1504 In general, the security considerations for the operation of P2P-RPL 1505 are similar to the ones for the operation of RPL (as described in 1506 Section 19 of [RFC6550]). Sections 6.1 and 10 of RPL specification 1507 [RFC6550] describe RPL's security framework that provides data 1508 confidentiality, authentication, replay protection and delay 1509 protection services. This security framework can also be used in 1510 P2P-RPL after taking in account the constraints specified in 1511 Section 11. P2P-RPL requires all routers participating in a secure 1512 route discovery to use the Security Configuration decided by the 1513 Origin. The intention is to avoid compromising the overall security 1514 of a route discovery due to some routers using a weaker Security 1515 Configuration. With "lock down" mechanism, described in Section 11, 1516 in effect, it is unlikely that an Origin would accept a route 1517 discovered under a Security Configuration other than the one it 1518 intended. Any attempt to use a different Security Configuration 1519 (than the one the Origin intended) is likely to result, in the worst 1520 case, in the failure of the route discovery process. In the best 1521 case scenario, any such attempt by a rogue router would result in its 1522 neighbors entering the "lock down" mode and acting as firewalls to 1523 allow the route discovery to proceed in the remaining network. 1525 RPL specification describes three modes of security: unsecured, pre- 1526 installed and authenticated. In the unsecured mode, secure control 1527 messages are not used and the only available security is the one 1528 provided by the link layer protocols. In the pre-installed mode, all 1529 the nodes use a pre-installed group key to join a secure DAG as the 1530 "routers" or "hosts", where the term "router" means a node that is 1531 capable of forwarding packets received from its parents or children 1532 in the DAG and the term "host" refers to nodes that can not function 1533 as "routers". In the authenticated mode, the nodes can join a secure 1534 DAG as "hosts" using the pre-installed key but then need to 1535 authenticate themselves to a key server to obtain the key that will 1536 allow them to work as "routers". The temporary DAG created for a 1537 P2P-RPL discovery can not be used for routing packets. Hence, it is 1538 not meaningful to say that a node joins this DAG as a "router" or a 1539 "host" in the sense defined above. Hence, in P2P-RPL, there is no 1540 distinction between the pre-installed and authenticated modes. A 1541 router can join a temporary DAG created for a secure P2P-RPL route 1542 discovery only if it can support the Security Configuration in use, 1543 which also specifies the key in use. It does not matter whether the 1544 key is pre-installed or dynamically acquired. The router must have 1545 the key in use before it can join the DAG beiing created for a secure 1546 P2P-RPL route discovery. 1548 If a rogue router can support the Security Configuration in use (in 1549 particular, it knows the key in use), it can join the secure P2P-RPL 1550 route discovery and cause a variety of damage. Such a rogue router 1551 could advertise false information in its DIOs in order to include 1552 itself in the discovered route(s). It could generate bogus P2P-DRO 1553 messages carrying bad routes or maliciously modify genuine P2P-DRO 1554 messages it receives. A rogue router acting as the Origin could 1555 launch denial of service attacks against the LLN deployment by 1556 initiating fake P2P-RPL route discoveries. Here, RPL's authenticated 1557 mode operation would be useful, where a node can obtain the key to 1558 use for a P2P-RPL route discovery only after proper authentication. 1560 Since a P2P-DRO message travels along a Source Route specified inside 1561 the message, some of the security concerns that led to the 1562 deprecation of Type 0 routing header [RFC5095] may apply. To avoid 1563 the possibility of a P2P-DRO message traveling in a routing loop, 1564 this document requires each Intermediate Router to confirm that the 1565 Source Route listed inside the message does not contain any routing 1566 loop involving itself before the router could forward the message 1567 further. As specified in Section 9.6, this check involves the router 1568 making sure that its IPv6 addresses do not appear multiple times 1569 inside the Source Route with one or more other IPv6 addresses in 1570 between. 1572 15. IANA Considerations 1574 15.1. Additions to Mode of Operation 1576 This document defines a new Mode of Operation, entitled "P2P Route 1577 Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode 1578 of Operation" space [to be removed upon publication: 1579 http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is 1580 requested to allocate a suitable value to TBD1. The string TBD1 in 1581 this document should be replaced by the allocated value. The 1582 previous two sentences should be removed before publication. 1584 +-------+---------------------------------------+---------------+ 1585 | Value | Description | Reference | 1586 +-------+---------------------------------------+---------------+ 1587 | TBD1 | P2P Route Discovery Mode of Operation | This document | 1588 +-------+---------------------------------------+---------------+ 1590 Mode of Operation 1592 15.2. Additions to RPL Control Message Options 1594 This document defines a new RPL option: "P2P Route Discovery Option" 1595 (see Section 7), assigned a value TBD2 from the "RPL Control Message 1596 Options" space [to be removed upon publication: 1597 http://www.iana.org/assignments/rpl/rpl.xml#control-message-options] 1598 [RFC6550]. IANA is requested to allocate a suitable value to TBD2. 1599 The string TBD2 in this document should be replaced by the allocated 1600 value. The previous two sentences should be removed before 1601 publication. 1603 +-------+---------------------+---------------+ 1604 | Value | Meaning | Reference | 1605 +-------+---------------------+---------------+ 1606 | TBD2 | P2P Route Discovery | This document | 1607 +-------+---------------------+---------------+ 1609 RPL Control Message Options 1611 15.3. Additions to RPL Control Codes 1613 This document defines the following new RPL messages: 1615 o "P2P Discovery Reply Object" (see Section 8), assigned a value 1616 TBD3 from the "RPL Control Codes" space [to be removed upon 1617 publication: 1618 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1619 [RFC6550]. IANA is requested to allocate TBD3 from the range 1620 0x00-0x7F to indicate a message without security enabled. The 1621 string TBD3 in this document should be replaced by the allocated 1622 value. The previous two sentences should be removed before 1623 publication. 1625 o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a 1626 value TBD4 from the "RPL Control Codes" space [to be removed upon 1627 publication: 1628 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1629 [RFC6550]. IANA is requested to allocate TBD4 from the range 1630 0x80-0xFF to indicate a message with security enabled. The string 1631 TBD4 in this document should be replaced by the allocated value. 1632 The previous two sentences should be removed before publication. 1634 o "P2P Discovery Reply Object Acknowledgement" (see Section 10), 1635 assigned a value TBD5 from the "RPL Control Codes" space [to be 1636 removed upon publication: 1637 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1638 [RFC6550]. IANA is requested to allocate TBD5 from the range 1639 0x00-0x7F to indicate a message without security enabled. The 1640 string TBD5 in this document should be replaced by the allocated 1641 value. The previous two sentences should be removed before 1642 publication. 1644 o "Secure P2P Discovery Reply Object Acknowledgement" (see 1645 Section 10), assigned a value TBD6 from the "RPL Control Codes" 1646 space [to be removed upon publication: 1647 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1648 [RFC6550]. IANA is requested to allocate TBD6 from the range 1649 0x80-0xFF to indicate a message with security enabled. The string 1650 TBD6 in this document should be replaced by the allocated value. 1651 The previous two sentences should be removed before publication. 1653 +------+---------------------------------------------+--------------+ 1654 | Code | Description | Reference | 1655 +------+---------------------------------------------+--------------+ 1656 | TBD3 | P2P Discovery Reply Object | This | 1657 | | | document | 1658 | TBD4 | Secure P2P Discovery Reply Object | This | 1659 | | | document | 1660 | TBD5 | P2P Discovery Reply Object Acknowledgement | This | 1661 | | | document | 1662 | TBD6 | Secure P2P Discovery Reply Object | This | 1663 | | Acknowledgement | document | 1664 +------+---------------------------------------------+--------------+ 1666 RPL Control Codes 1668 16. Acknowledgements 1670 Authors gratefully acknowledge the contributions of the following 1671 individuals (in alphabetical order) in the development of this 1672 document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas 1673 Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, 1674 Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles 1675 Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin 1676 Stiemerling, Pascal Thubert, Hristo Valev and JP Vasseur. 1678 17. References 1680 17.1. Normative References 1682 [I-D.ietf-roll-terminology] 1683 Vasseur, J., "Terminology in Low power And Lossy 1684 Networks", draft-ietf-roll-terminology-10 (work in 1685 progress), January 2013. 1687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1688 Requirement Levels", BCP 14, RFC 2119, March 1997. 1690 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1691 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1692 May 2008. 1694 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1695 "The Trickle Algorithm", RFC 6206, March 2011. 1697 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1698 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1700 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1701 Lossy Networks", RFC 6550, March 2012. 1703 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1704 Barthel, "Routing Metrics Used for Path Calculation in 1705 Low-Power and Lossy Networks", RFC 6551, March 2012. 1707 17.2. Informative References 1709 [I-D.ietf-roll-p2p-measurement] 1710 Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A 1711 Mechanism to Measure the Routing Metrics along a Point-to- 1712 point Route in a Low Power and Lossy Network", 1713 draft-ietf-roll-p2p-measurement-09 (work in progress), 1714 February 2013. 1716 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1717 of Type 0 Routing Headers in IPv6", RFC 5095, 1718 December 2007. 1720 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1721 Routing Requirements in Low-Power and Lossy Networks", 1722 RFC 5826, April 2010. 1724 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1725 "Building Automation Routing Requirements in Low-Power and 1726 Lossy Networks", RFC 5867, June 2010. 1728 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1729 Protocol for Low-Power and Lossy Networks (RPL)", 1730 RFC 6552, March 2012. 1732 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1733 Power and Lossy Networks (RPL) Option for Carrying RPL 1734 Information in Data-Plane Datagrams", RFC 6553, 1735 March 2012. 1737 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1738 Routing Header for Source Routes with the Routing Protocol 1739 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1740 March 2012. 1742 Authors' Addresses 1744 Mukul Goyal (editor) 1745 University of Wisconsin Milwaukee 1746 3200 N Cramer St 1747 Milwaukee, WI 53201 1748 USA 1750 Phone: +1 414 2295001 1751 Email: mukul@uwm.edu 1753 Emmanuel Baccelli 1754 INRIA 1756 Phone: +33-169-335-511 1757 Email: Emmanuel.Baccelli@inria.fr 1758 URI: http://www.emmanuelbaccelli.org/ 1760 Matthias Philipp 1761 INRIA 1763 Phone: +33-169-335-511 1764 Email: Matthias.Philipp@inria.fr 1766 Anders Brandt 1767 Sigma Designs 1768 Emdrupvej 26A, 1. 1769 Copenhagen, Dk-2100 1770 Denmark 1772 Phone: +45-29609501 1773 Email: abr@sdesigns.dk 1775 Jerald Martocci 1776 Johnson Controls 1777 507 E Michigan St 1778 Milwaukee, WI 53202 1779 USA 1781 Phone: +1 414-524-4010 1782 Email: jerald.p.martocci@jci.com