idnits 2.17.1 draft-ietf-roll-p2p-measurement-10.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 (April 1, 2013) is 4042 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1024 == Missing Reference: 'Index' is mentioned on line 967, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: October 3, 2013 E. Baccelli 6 INRIA 7 A. Brandt 8 Sigma Designs 9 J. Martocci 10 Johnson Controls 11 April 1, 2013 13 A Mechanism to Measure the Routing Metrics along a Point-to-point Route 14 in a Low Power and Lossy Network 15 draft-ietf-roll-p2p-measurement-10 17 Abstract 19 This document specifies a mechanism that enables an RPL router to 20 measure the aggregated values of given routing metrics along an 21 existing route towards another RPL router, thereby allowing the 22 router to decide if it wants to initiate the discovery of a better 23 route. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 3, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6 63 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6 64 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4. Originating a Measurement Request . . . . . . . . . . . . . . 11 66 4.1. When Measuring A Hop-by-hop Route with a Global 67 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2. When Measuring A Hop-by-hop Route with a Local 69 RPLInstanceID With Route Accumulation Off . . . . . . . . 13 70 4.3. When Measuring A Hop-by-hop Route with a Local 71 RPLInstanceID With Route Accumulation On . . . . . . . . . 14 72 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 16 73 5. Processing a Measurement Request at an Intermediate Point . . 17 74 5.1. When Measuring A Hop-by-hop Route with a Global 75 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2. When Measuring A Hop-by-hop Route with a Local 77 RPLInstanceID With Route Accumulation Off . . . . . . . . 19 78 5.3. When Measuring A Hop-by-hop Route with a Local 79 RPLInstanceID With Route Accumulation On . . . . . . . . . 20 80 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 21 81 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 21 82 6. Processing a Measurement Request at the End Point . . . . . . 22 83 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 23 84 7. Processing a Measurement Reply at the Start Point . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 Point to point (P2P) communication between arbitrary routers in a Low 96 power and Lossy Network (LLN) is a key requirement for many 97 applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs 98 (RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic 99 Graph (DAG) built to optimize the routing costs to reach the DAG's 100 root. The P2P routing functionality, available under RPL, has the 101 following key limitations: 103 o The P2P routes are restricted to use the DAG links only. Such P2P 104 routes may potentially be suboptimal and may lead to traffic 105 congestion near the DAG root. 107 o RPL is a proactive routing protocol and hence requires all P2P 108 routes to be established ahead of the time they are used. Many 109 LLN applications require the ability to establish P2P routes "on 110 demand". 112 To ameliorate situations where the core RPL's P2P routing 113 functionality does not meet the application requirements 114 [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. 115 P2P-RPL provides a reactive mechanism to discover P2P routes that 116 meet the specified routing constraints [RFC6551]. In some cases, the 117 application requirements or the LLN's topological features allow a 118 router to infer these routing constraints implicitly. For example, 119 the application may require the end-to-end loss rate and/or latency 120 along the route to be below certain thresholds or the LLN topology 121 may be such that a router can safely assume its destination to be 122 less than a certain number of hops away from itself. 124 When the existing routes are deemed unsatisfactory but the router 125 does not implicitly know the routing constraints to be used in P2P- 126 RPL route discovery, it may be necessary for the router to measure 127 the aggregated values of the routing metrics along the existing 128 route. This knowledge will allow the router to frame reasonable 129 routing constraints to discover a better route using P2P-RPL. For 130 example, if the router determines the aggregate ETX (Expected Number 131 of Transmissions) [RFC6551] along an existing route to be "x", it can 132 use "ETX < x*y", where y is a certain fraction, as the routing 133 constraint for use in P2P-RPL route discovery. Note that it is 134 important that the routing constraints not be overly strict; 135 otherwise, the P2P-RPL route discovery may fail even though a route 136 exists that is much better than the one currently being used. 138 This document specifies a mechanism that enables an RPL router to 139 measure the aggregated values of the routing metrics along an 140 existing route to another RPL router in an LLN, thereby allowing the 141 router to decide if it wants to discover a better route using P2P-RPL 142 and determine the routing constraints to be used for this purpose. 143 Thus, the utility of this mechanism is dependent on the existence of 144 P2P-RPL, which is targeting publication as an Experimental RFC. It 145 makes sense, therefore, for this document also to target publication 146 as an Experimental RFC. The hope is that experiments with P2P-RPL 147 and the mechanism defined in this document will result in feedback on 148 the utility and benefits of this document and it will be revised and 149 progressed on the Standards Track based on this feedback. 151 1.1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 [RFC2119]. 158 This document uses terminology from [RFC6550], 159 [I-D.ietf-roll-terminology] and [I-D.ietf-roll-p2p-rpl]. 160 Additionally, this document defines the following terms. 162 Start Point: The Start Point refers to the RPL router that initiates 163 the measurement process defined in this document and is the start 164 point of the P2P route being measured. 166 End Point: The End Point refers to the RPL router at the end point of 167 the P2P route being measured. 169 Intermediate Point: An RPL router, other than the Start Point and the 170 End Point, on the P2P route being measured. 172 The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have 173 been redefined in this document in the following manner. 175 Forward direction: The direction from the Start Point to the End 176 Point. 178 Reverse direction: The direction from the End Point to the Start 179 Point. 181 2. Overview 183 The mechanism described in this document can be used by a Start Point 184 in an LLN to measure the aggregated values of selected routing 185 metrics along a P2P route to an End Point within the LLN. The route 186 is measured in the Forward direction. Such a route could be a Source 187 Route or a Hop-by-hop Route established using RPL [RFC6550] or P2P- 188 RPL [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" 189 route with the initial part consisting of hop-by-hop ascent to the 190 root of a non-storing DAG [RFC6550] and the final part consisting of 191 a source-routed descent to the End Point. The Start Point decides 192 what metrics to measure and sends a Measurement Request message, 193 carrying the desired routing metric objects, along the route. If a 194 Source Route is being measured, the Measurement Request carries the 195 route inside an Address vector. If a Hop-by-hop Route is being 196 measured, the Measurement Request identifies the route by its 197 RPLInstanceID [RFC6550] (and, in case the RPLInstanceID is a local 198 value, the Start Point's IPv6 address associated with the route). On 199 receiving a Measurement Request, an Intermediate Point updates the 200 routing metric values inside the message and forwards it to the next 201 hop on the route. Thus, the Measurement Request accumulates the 202 values of the routing metrics for the complete route as it travels 203 towards the End Point. Upon receiving the Measurement Request, the 204 End Point unicasts a Measurement Reply message, carrying the 205 accumulated values of the routing metrics, back to the Start Point. 206 Optionally, the Start Point may allow an Intermediate Point to 207 generate the Measurement Reply if the Intermediate Point already 208 knows the relevant routing metric values along rest of the route. 210 The Measurement Request may include an Address vector that serves one 211 of the following functions: 213 o To accumulate a Source Route for End Point's use: If a Hop-by-hop 214 Route with a local RPLInstanceID is being measured, the Start 215 Point may require each Intermediate Point to add its global or 216 unique local IPv6 address to an Address vector inside the 217 Measurement Request. The Source Route, thus accumulated, can be 218 used by the End Point to reach the Start Point. In particular, 219 the End Point may use the accumulated Source Route to send the 220 Measurement Reply back to the Start Point. In this case, the 221 Start Point includes a suitably-sized Address vector in the 222 Measurement Request. The size of the Address vector puts a hard 223 limit on the length of the accumulated route. An Intermediate 224 Point is not allowed to modify the size of the Address vector and 225 must discard a received Measurement Request if the Address vector 226 is not large enough to contain the complete route. 228 o To carry the Source Route being measured: The Start Point may 229 insert an Address vector inside the Measurement Request to carry 230 the Source Route being measured. Also, the root of a global non- 231 storing DAG may insert an Address vector, carrying a Source Route 232 from itself to the End Point, inside a Measurement Request message 233 if this message had been traveling along this DAG so far. This 234 Source Route must consist of global or unique local IPv6 235 addresses. An Intermediate Point is not allowed to modify an 236 existing Address vector before forwarding the Measurement Request 237 further. In other words, an Intermediate Point must not modify 238 the Source Route along which the Measurement Request is currently 239 traveling. 241 3. The Measurement Object (MO) 243 This document defines two new RPL Control Message types, the 244 Measurement Object (MO), with code TBD1, and the Secure MO, with code 245 TBD2. An MO serves as both Measurement Request and Measurement 246 Reply. 248 3.1. Format of the base MO 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 . Start Point Address . 257 . . 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 . End Point Address . 262 . . 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 . Address[0..Num-1] . 267 . . 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 . Metric Container Option(s) . 272 . . 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: Format of the base Measurement Object (MO) 278 The format of a base MO is shown in Figure 1. A base MO consists of 279 the following fields: 281 o RPLInstanceID: This field specifies the RPLInstanceID of the Hop- 282 by-hop Route along which the Measurement Request travels (or 283 traveled initially until it switched over to a Source Route). 285 o Compr: In many LLN deployments, IPv6 addresses share a well known, 286 common prefix. In such cases, the common prefix can be elided 287 when specifying IPv6 addresses in the Start Point/End Point 288 Address fields and the Address vector. The "Compr" field, a 4-bit 289 unsigned integer, is set by the Start Point to specify the number 290 of prefix octets that are elided from the IPv6 addresses in Start 291 Point/End Point Address fields and the Address vector. The Start 292 Point will set the Compr value to zero if full IPv6 addresses are 293 to be carried in the Start Point Address/End Point Address fields 294 and the Address vector. 296 o Type (T): This flag is set to one if the MO represents a 297 Measurement Request. The flag is set to zero if the MO is a 298 Measurement Reply. 300 o Hop-by-hop (H): The Start Point MUST set this flag to one if (at 301 least the initial part of) the route being measured is hop-by-hop. 302 In that case, the Hop-by-hop Route is identified by the 303 RPLInstanceID, the End Point Address and, if the RPLInstanceID is 304 a local value, the Start Point Address fields inside the 305 Measurement Request. Here, the Start Point Address field is 306 required to be same as the DODAGID (the identifier of the 307 destination-oritented DAG root) [RFC6550] of the route being 308 measured. The Start Point MUST set the H flag to zero if the 309 route being measured is a Source Route specified in the Address 310 vector. An Intermediate Point MUST set the H flag in an outgoing 311 Measurement Request to the same value that it had in the 312 corresponding incoming Measurement Request unless it is the root 313 of the non-storing global DAG, identified by the RPLInstanceID, 314 along which the Measurement Request had been traveling so far and 315 the Intermediate Point intends to insert a Source Route inside the 316 Address vector to direct it towards the End Point. In that case, 317 the Intermediate Point MUST set the H flag to zero. 319 o Accumulate Route (A): A value 1 in this flag indicates that the 320 Measurement Request is accumulating a Source Route for use by the 321 End Point to send the Measurement Reply back to the Start Point. 322 Route accumulation MUST NOT be used (i.e., this flag MUST NOT be 323 set to 1) inside a Measurement Request unless it travels along a 324 Hop-by-hop Route represented by a local RPLInstanceID (i.e., H = 325 1, RPLInstanceID has a local value). Route accumulation MAY be 326 used (i.e., this flag MAY be set to 1) if the Measurement Request 327 is traveling along a Hop-by-hop Route with a local RPLInstanceID. 328 In this case if the route accumulation is on, an Intermediate 329 Point adds its unicast global/unique-local IPv6 address (after 330 eliding Compr number of prefix octets) to the Address vector in 331 the manner specified in Section 5.3. In other cases, this flag 332 MUST be set to zero on transmission and ignored on reception. 333 Route accumulation is not allowed when the Measurement Request 334 travels along a Hop-by-hop Route with a global RPLInstanceID, 335 i.e., along a global DAG, because: 337 * The DAG's root may need the Address vector to insert a Source 338 Route to the End Point; and 340 * The End Point can presumably reach the Start Point along this 341 global DAG (identified by the RPLInstanceID field). 343 o Reverse (R): A value 1 in this flag inside a Measurement Request 344 indicates that the Address vector contains a complete Source Route 345 from the Start Point to the End Point, which can be used, after 346 reversal, by the End Point to send the Measurement Reply back to 347 the Start Point. This flag MAY be set to one inside a Measurement 348 Request only if a Source Route, from the Start Point to the End 349 Point, is being measured. Otherwise, this flag MUST be set to 350 zero on transmission and ignored on reception. 352 o Back Request (B): A value 1 in this flag serves as a request to 353 the End Point to send a Measurement Request towards the Start 354 Point. On receiving a Measurement Request with the B flag set to 355 one, the End Point SHOULD generate a Measurement Request to 356 measure the cost of its current (or the most preferred) route to 357 the Start Point. Receipt of this Measurement Request would allow 358 the Start Point to know the cost of the back route from the End 359 Point to itself and thus determine the round-trip cost of reaching 360 the End Point. 362 o Intermediate Reply (I): A value 1 in this flag serves as a 363 permission to an Intermediate Point to generate a Measurement 364 Reply if it knows the aggregated values of the routing metrics 365 being measured for the rest of the route. Setting this flag to 366 one may be useful in scenarios where the Hop Count [RFC6551] is 367 the routing metric of interest and an Intermediate Point (e.g. the 368 root of a non-storing global DAG or a common ancestor of the Start 369 Point and the End Point in a storing global DAG) may know the Hop 370 Count of the remainder of the route to the End Point. This flag 371 MAY be set to one only if a Hop-by-hop Route with a global 372 RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a 373 global value). Otherwise, this flag MUST be set to zero on 374 transmission and ignored on reception. 376 o SeqNo: A 6-bit sequence number, assigned by the Start Point, that 377 allows the Start Point to uniquely identify a Measurement Request 378 and the corresponding Measurement Reply. 380 o Num: This field indicates the number of elements, each (16 - 381 Compr) octets in size, inside the Address vector. If the value of 382 this field is zero, the Address vector is not present in the MO. 384 o Index: If the Measurement Request is traveling along a Source 385 Route contained in the Address vector (i.e., H = 0), this field 386 indicates the index in the Address vector of the next hop on the 387 route. If the Measurement Request is traveling along a Hop-by-hop 388 Route with a local RPLInstanceID and the Route Accumulation is on 389 (i.e., H = 1, RPLInstanceID has a local value, A = 1), this field 390 indicates the index in the Address vector where an Intermediate 391 Point receiving the Measurement Request must store its IPv6 392 address. Otherwise, this field MUST be set to zero on 393 transmission and ignored on reception. 395 o Start Point Address: A unicast global or unique local IPv6 address 396 of the Start Point after eliding Compr number of prefix octets. 397 If the Measurement Request is traveling along a Hop-by-hop Route 398 and the RPLInstanceID field indicates a local value, the Start 399 Point Address field MUST specify the DODAGID value that, along 400 with the RPLInstanceID and the End Point Address, uniquely 401 identifies the Hop-by-hop Route being measured. 403 o End Point Address: A unicast global or unique local IPv6 address 404 of the End Point after eliding Compr number of prefix octets. 406 o Address[0..Num-1]: A vector of unicast global or unique local IPv6 407 addresses (with Compr number of prefix octets elided) representing 408 a Source Route: 410 * Each element in the vector has size (16 - Compr) octets. 412 * The total number of elements inside the Address vector is given 413 by the Num field. 415 * The Start Point and End Point addresses MUST NOT be included in 416 the Address vector. 418 * The Address vector MUST NOT contain any multicast addresses. 420 * If the Start Point wants to measure a Hop-by-hop Route with a 421 local RPLInstanceID and accumulate a Source Route for the End 422 Point's use (i.e., the Measurement Request has the H flag set 423 to 1, RPLInstanceID set to a local value and the A flag set to 424 1), it MUST include a suitably-sized Address vector in the 425 Measurement Request. As the Measurement Request travels over 426 the route being measured, the Address vector accumulates a 427 Source Route that can be used by the End Point, after reversal, 428 to reach (and, in particular, to send the Measurement Reply 429 back to) the Start Point. The route MUST be accumulated in the 430 Forward direction but the IPv6 addresses in the accumulated 431 route MUST be reachable in the Reverse direction. An 432 Intermediate Point MUST add only a global or unique local IPv6 433 address to the Address vector and MUST NOT modify the size of 434 the Address vector. 436 * If the Start Point wants to measure a Source Route, it MUST 437 include an Address vector, containing the route being measured, 438 inside the Measurement Request. Similarly, if the Measurement 439 Request had been traveling along a global non-storing DAG so 440 far, the root of this DAG may insert an Address vector, 441 containing a Source Route from itself to the End Point, inside 442 the Measurement Request. In both cases, the Source Route 443 inside the Address vector MUST consist only of global or unique 444 local IPv6 addresses that are reachable in the Forward 445 direction. Further, in both cases, an Intermediate Point MUST 446 NOT modify the contents of the existing Address vector before 447 forwarding the Measurement Request further. In other words, an 448 Intermediate Point MUST NOT modify the Source Route along which 449 the Measurement Request is currently traveling. The Start 450 Point MAY set the R flag in the Measurement Request to one if 451 the Source Route inside the Address vector can be used by the 452 End Point, after reversal, to reach (and, in particular, to 453 send the Measurement Reply back to) the Start Point. In other 454 words, the Start Point MAY set the R flag to one only if all 455 the IPv6 addresses in the Address vector are reachable in the 456 Reverse direction. 458 o Metric Container Options: A Measurement Request MUST contain one 459 or more Metric Container options [RFC6550] to accumulate the 460 values of the selected routing metrics in the manner described in 461 [RFC6551] for the route being measured. 463 Section 4 describes how a Start Point sets various fields inside a 464 Measurement Request in different cases. Section 5 describes how an 465 Intermediate Point processes a received Measurement Request before 466 forwarding it further. Section 6 describes how the End Point 467 processes a received Measurement Request and generate a Measurement 468 Reply. Finally, Section 7 describes how the Start Point processes a 469 received Measurement Reply. In the following discussion, any 470 reference to discarding a received Measurement Request/Reply with "no 471 further processing" does not preclude updating the appropriate error 472 counters or any similar actions. 474 3.2. Secure MO 476 A Secure MO follows the format in Figure 7 of [RFC6550], where the 477 base format is the base MO shown in Figure 1. Sections 6.1, 10 and 478 19 of [RFC6550] describe RPL security framework. These sections are 479 applicable to the use of Secure MO messages as well except as 480 constrained in this section. An LLN deployment MUST support the use 481 of Secure MO messages so that it has the ability to invoke RPL- 482 provided security mechanisms and prevent misuse of the measurement 483 mechanism by unauthorized routers. 485 The Start Point determines whether Secure MO messages are to be used 486 in a particular route measurement and if yes the Security 487 Configuration (see definition in [I-D.ietf-roll-p2p-rpl]) to be used 488 for the purpose. The Start Point MUST NOT set the "Key Identifier 489 Mode" field to value 1 inside this Security Configuration since this 490 setting indicates the use of a per-pair key which is not suitable for 491 securing the Measurement Request messages that travel over multiple 492 hops. A router (an Intermediate Point or the End Point), 493 participating in a particular route measurement, 495 o MUST generate a Secure MO message (a Measurement Request or a 496 Measurement Reply) if the received Measurement Request is a Secure 497 MO. The Security Configuration used in generating a Secure MO 498 message MUST be same as the one used in the received message. 500 o MUST NOT generate a Secure MO message if the received Measurement 501 Request is not a Secure MO. 503 A router MUST discard a received Measurement Request if it cannot 504 follow the above mentioned rules. If the Start Point sends a 505 Measurement Request in a Secure MO message using a particular 506 Security Configuration, it MUST discard the corresponding Measurement 507 Reply it receives with no further processing unless the Measurement 508 Reply is received in a Secure MO message generated with same Security 509 Configuration as the one used in the Measurement Request. 511 In the following discussion, any reference to an MO message is also 512 applicable to a Secure MO message unless noted otherwise. 514 4. Originating a Measurement Request 516 A Start Point sets various fields inside the Measurement Request it 517 generates in the manner described below. The Start Point MUST also 518 include the routing metric objects [RFC6551] of interest inside one 519 or more Metric Container options inside the Measurement Request. The 520 Start Point then determines the next hop on the route being measured. 521 If a Hop-by-hop route is being measured (i.e., H = 1), the next hop 522 is determined using the RPLInstanceID, the End Point Address and, if 523 RPLInstanceID is a local value, the Start Point Address fields in the 524 Measurement Request. If a Source Route is being measured (i.e., H = 525 0), the Address[0] element inside the Measurement Request contains 526 the next hop address. The Start Point MUST ensure that 528 o the next hop address is a unicast address; and 530 o the next hop is on-link; and 532 o the next hop is in the same RPL routing domain 533 [I-D.ietf-roll-terminology] as the Start Point; 535 failing which the Start Point MUST discard the Measurement Request 536 without sending. Depending on the routing metrics, the Start Point 537 must initiate the routing metric objects inside the Metric Container 538 options by including the routing metric values for the first hop on 539 the route being measured. Finally, the Start Point MUST unicast the 540 Measurement Request to the next hop on the route being measured. 542 The Start Point MUST maintain state for just transmitted Measurement 543 Request for a life time duration that is large enough to allow the 544 corresponding Measurement Reply to return. This state consists of 545 the RPLInstanceID, the SeqNo and the End Point Address fields of the 546 Measurement Request. The life time duration for this state is 547 locally determined by the Start Point and may be deployment specific. 548 This state expires when the corresponding Measurement Reply is 549 received or when the life time is over, whichever occurs first. 550 Failure to receive the corresponding Measurement Reply before the 551 expiry of a state may occur due to a number of reasons including 552 unwillingness on part of an Intermediate Point or the End Point to 553 process the Measurement Request. The Start Point should take such 554 possibilities in account when deciding whether to generate another 555 Measurement Request for this route. The Start Point MUST discard a 556 received Measurement Reply with no further processing if the state 557 for the corresponding Measurement Request has already expired. 559 4.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 561 If a Hop-by-hop Route with a global RPLInstanceID is being measured 562 (i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT 563 contain an Address vector and various MO fields MUST be set in the 564 following manner: 566 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 567 measured. 569 o Compr: MUST be set to specify the number of prefix octets that are 570 elided from the IPv6 addresses in Start Point/End Point Address 571 fields. 573 o Type (T): MUST be set to one since the MO represents a Measurement 574 Request. 576 o Hop-by-hop (H): MUST be set to one. 578 o Accumulate Route (A): This flag MUST be set to zero. 580 o Reverse (R): This flag MUST be set to zero. 582 o Back Request (B): This flag MAY be set to one to request the End 583 Point to send a Measurement Request to the Start Point. 585 o Intermediate Reply (I): This flag MAY be set to one if the Start 586 Point expects an Intermediate Point to know the values of the 587 routing metrics being measured for the remainder of the route. 589 o SeqNo: Assigned by the Start Point so that it can uniquely 590 identify the Measurement Request and the corresponding Measurement 591 Reply. 593 o Num: This field MUST be set to zero. 595 o Index: This field MUST be set to zero. 597 o Start Point Address: MUST be set to a unicast global/unique-local 598 IPv6 address of the Start Point after eliding Compr number of 599 prefix octets. 601 o End Point Address: MUST be set to a unicast global/unique-local 602 IPv6 address of the End Point after eliding Compr number of prefix 603 octets. 605 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 606 Route Accumulation Off 608 If a Hop-by-hop Route with a local RPLInstanceID is being measured 609 and the Start Point does not want the MO to accumulate a Source Route 610 for the End Point's use, the MO MUST NOT contain the Address vector 611 and various MO fields MUST be set in the following manner: 613 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 614 measured. 616 o Compr: MUST be set to specify the number of prefix octets that are 617 elided from the IPv6 addresses in Start Point/End Point Address 618 fields. 620 o Type (T): MUST be set to one since the MO represents a Measurement 621 Request. 623 o Hop-by-hop (H): MUST be set to one. 625 o Accumulate Route (A): This flag MUST be set to zero. 627 o Reverse (R): This flag MUST be set to zero. 629 o Back Request (B): This flag MAY be set to one to request the End 630 Point to send a Measurement Request to the Start Point. 632 o Intermediate Reply (I): This flag MUST be set to zero. 634 o SeqNo: Assigned by the Start Point so that it can uniquely 635 identify the Measurement Request and the corresponding Measurement 636 Reply. 638 o Num: This field MUST be set to zero. 640 o Index: This field MUST be set to zero. 642 o Start Point Address: This field MUST contain the DODAGID value 643 (after eliding Compr number of prefix octets) associated with the 644 route being measured. This DODAGID MUST also be a global or 645 unique local IPv6 address of the Start Point. 647 o End Point Address: MUST be set to a unicast global or unique local 648 IPv6 address of the End Point after eliding Compr number of prefix 649 octets. 651 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 652 Route Accumulation On 654 If a Hop-by-hop Route with a local RPLInstanceID is being measured 655 and the Start Point desires the MO to accumulate a Source Route for 656 the End Point to send the Measurement Reply message back, the MO MUST 657 contain a suitably-sized Address vector and various MO fields MUST be 658 set in the following manner: 660 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 661 measured. 663 o Compr: MUST be set to specify the number of prefix octets that are 664 elided from the IPv6 addresses in Start Point/End Point Address 665 fields and the Address vector. 667 o Type (T): MUST be set to one since the MO represents a Measurement 668 Request. 670 o Hop-by-hop (H): MUST be set to one. 672 o Accumulate Route (A): This flag MUST be set to one. 674 o Reverse (R): This flag MUST be set to zero. 676 o Back Request (B): This flag MAY be set to one to request the End 677 Point to send a Measurement Request to the Start Point. 679 o Intermediate Reply (I): This flag MUST be set to zero. 681 o SeqNo: Assigned by the Start Point so that it can uniquely 682 identify the Measurement Request and the corresponding Measurement 683 Reply. 685 o Num: This field MUST specify the number of address elements, each 686 (16 - Compr) octets in size, that can fit inside the Address 687 vector. 689 o Index: This field MUST be set to zero to indicate the position in 690 the Address vector where the next hop must store its IPv6 address. 692 o Start Point Address: This field MUST contain the DODAGID value 693 (after eliding Compr number of prefix octets) associated with the 694 route being measured. This DODAGID MUST also be a global or 695 unique local IPv6 address of the Start Point. 697 o End Point Address: MUST be set to a unicast global or unique local 698 IPv6 address of the End Point after eliding Compr number of prefix 699 octets. 701 o Address vector: The Address vector must be large enough to 702 accomodate a complete Source Route from the End Point to the Start 703 Point. All the bits in the Address vector field MUST be set to 704 zero. 706 4.4. When Measuring A Source Route 708 If a Source Route is being measured, the Start Point MUST set various 709 MO fields in the following manner: 711 o RPLInstanceID: This field does not have any significance when a 712 Source Route is being measured and hence can be set to any value. 714 o Compr: MUST be set to specify the number of prefix octets that are 715 elided from the IPv6 addresses in Start Point/End Point Address 716 fields and the Address vector. 718 o Type (T): MUST be set to one since the MO represents a Measurement 719 Request. 721 o Hop-by-hop (H): MUST be set to zero. 723 o Accumulate Route (A): This flag MUST be set to zero. 725 o Reverse (R): This flag SHOULD be set to one if the Source Route in 726 the Address vector can be reversed and used by the End Point to 727 send the Measurement Reply message back to the Start Point. 728 Otherwise, this flag MUST be set to zero. 730 o Back Request (B): This flag MAY be set to one to request the End 731 Point to send a Measurement Request to the Start Point. 733 o Intermediate Reply (I): This flag MUST be set to zero. 735 o SeqNo: Assigned by the Start Point so that it can uniquely 736 identify the Measurement Request and the corresponding Measurement 737 Reply. 739 o Num: This field MUST specify the number of address elements, each 740 (16 - Compr) octets in size, inside the Address vector. 742 o Index: This field MUST be set to zero to indicate the position in 743 the Address vector of the next hop on the route. 745 o Start Point Address: MUST be set to a unicast global or unique 746 local IPv6 address of the Start Point after eliding Compr number 747 of prefix octets. 749 o End Point Address: MUST be set to a unicast global or unique local 750 IPv6 address of the End Point after eliding Compr number of prefix 751 octets. 753 o Address vector: 755 * The Address vector MUST contain a complete Source Route from 756 the Start Point to the End Point (excluding the Start Point and 757 the End Point). 759 * Each address appearing in the Address vector MUST be a unicast 760 global or unique local IPv6 address. Further, each address 761 MUST have the same prefix as the Start Point Address and the 762 End Point Address. This prefix, whose length in octets is 763 specified in the Compr field, MUST be elided from each address. 765 * The IPv6 addresses in the Address vector MUST be reachable in 766 the Forward direction. 768 * If the R flag is set to one, the IPv6 addresses in the Address 769 vector MUST also be reachable in the Reverse direction. 771 5. Processing a Measurement Request at an Intermediate Point 773 A router (an Intermediate Point or the End Point) MAY discard a 774 received MO with no processing to meet any policy-related goal. Such 775 policy goals may include the need to reduce the router's CPU load or 776 to enhance its battery life or to prevent misuse of this mechanism by 777 unauthorized nodes. 779 A router MUST discard a received MO with no further processing if the 780 value in the Compr field inside the received message is more than 781 what the router considers the length of the common prefix used in 782 IPv6 addresses in the LLN to be. 784 On receiving an MO, if a router chooses to process the packet 785 further, it MUST check if one of its IPv6 addresses is listed as 786 either the Start Point or the End Point Address. If neither, the 787 router considers itself an Intermediate Point and MUST process the 788 received MO in the following manner. 790 An Intermediate Point MUST discard the packet with no further 791 processing if the received MO is not a Measurement Request (i.e., T = 792 0). This is because the End Point unicasts a Measurement Reply 793 directly to the Start Point. So, the Intermediate Point treats a 794 transiting Measurement Reply as a data packet and not an RPL control 795 message. 797 Next, the Intermediate Point determines the type of the route being 798 measured (by checking the values of the H flag and the RPLInstanceID 799 field) and processes the received MO accordingly in the manner 800 specified next. 802 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 804 If a Hop-by-hop Route with a global RPLInstanceID is being measured 805 (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate 806 Point MUST process the received Measurement Request in the following 807 manner. 809 If the Num field inside the received Measurement Request is not set 810 to zero, thereby implying that an Address vector is present, the 811 Intermediate Point MUST discard the received message with no further 812 processing. 814 If the Intermediate Reply (I) flag is set to one in the received 815 Measurement Request and the Intermediate Point knows the values of 816 the routing metrics, specified in the Metric Container options, for 817 the remainder of the route, it MAY generate a Measurement Reply on 818 the End Point's behalf in the manner specified in Section 6.1 (after 819 including in the Measurement Reply the relevant routing metric values 820 for the complete route being measured). Otherwise, the Intermediate 821 Point MUST process the received message in the following manner. 823 The Intermediate Point MUST determine the next hop on the route being 824 measured using the RPLInstanceID and the End Point Address. If the 825 Intermediate Point is the root of the non-storing global DAG along 826 which the received Measurement Request had been traveling so far, it 827 MUST process the received Measurement Request in the following 828 manner: 830 o If the router does not know how to reach the End Point, it MUST 831 discard the Measurement Request with no further processing and MAY 832 send an ICMPv6 Destination Unreachable (with Code 0 - No Route To 833 Destination) error message [RFC4443] to the Start Point. 835 o Otherwise, unless the router determines the End Point itself to be 836 the next hop, the router MUST make the following changes in the 837 received Measurement Request: 839 * Set the H, A, R and I flags to zero (the A and R flags should 840 already be zero in the received message). 842 * Leave remaining fields unchanged (the Num field would be 843 modified in next steps). Note that the RPLInstanceID field 844 identifies the non-storing global DAG along which the 845 Measurement Request traveled so far. This information MUST be 846 preserved so that the End Point may use this DAG to send the 847 Measurement Reply back to the Start Point. 849 * Insert a new Address vector inside the Measurement Request and 850 specify a Source Route to the End Point inside the Address 851 vector as per the following rules: 853 + The Address vector MUST contain a complete route from the 854 router to the End Point (excluding the router and the End 855 Point); 857 + Each address appearing in the Address vector MUST be a 858 unicast global or unique local IPv6 address. Further, each 859 address MUST have the same prefix as the Start Point Address 860 and the End Point Address. This prefix, whose length in 861 octets is specified in the Compr field, MUST be elided from 862 each address. 864 + The IPv6 addresses in the Address vector MUST be reachable 865 in the Forward direction; 867 If the router cannot insert an Address vector satisfying the 868 rules mentioned above, it MUST discard the Measurement Request 869 with no further processing and MAY send an ICMPv6 Destination 870 Unreachable (with Code 0 - No Route To Destination) error 871 message [RFC4443] to the Start Point. 873 * Specify in the Num field the number of address elements in the 874 Address vector. 876 * Set the Index field to zero to indicate the position in the 877 Address vector of the next hop on the route. Thus, Address[0] 878 element contains the address of the next hop on the route. 880 The Intermediate Point MUST then complete the processing of the 881 received Measurement Request as specified in Section 5.5. 883 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 884 Route Accumulation Off 886 If a Hop-by-hop Route with a local RPLInstanceID is being measured 887 and the route accumulation is off (i.e., H = 1, RPLInstanceID has a 888 local value, A = 0), the Intermediate Point MUST process the received 889 Measurement Request in the following manner. 891 If the Num field inside the received Measurement Request is not set 892 to zero, thereby implying that an Address vector is present, the 893 Intermediate Point MUST discard the received message with no further 894 processing. 896 The Intermediate Point MUST then determine the next hop on the route 897 being measured using the RPLInstanceID, the End Point Address and the 898 Start Point Address (which represents the DODAGID of the route being 899 measured). If the Intermediate Point can not determine the next hop, 900 it MUST discard the Measurement Request with no further processing 901 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 902 Route To Destination) error message [RFC4443] to the Start Point. 903 Otherwise, the Intermediate Point MUST complete the processing of the 904 received Measurement Request as specified in Section 5.5. 906 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 907 Route Accumulation On 909 If a Hop-by-hop Route with a local RPLInstanceID is being measured 910 and the route accumulation is on (i.e., H = 1, RPLInstanceID has a 911 local value, A = 1), the Intermediate Point MUST process the received 912 Measurement Request in the following manner. 914 If the Num field inside the received Measurement Request is set to 915 zero, thereby implying that an Address vector is not present, the 916 Intermediate Point MUST discard the received message with no further 917 processing. 919 The Intermediate Point MUST then determine the next hop on the route 920 being measured using the RPLInstanceID, the End Point Address and the 921 Start Point Address (which represents the DODAGID of the route being 922 measured). If the Intermediate Point can not determine the next hop, 923 it MUST discard the Measurement Request with no further processing 924 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 925 Route To Destination) error message [RFC4443] to the Start Point. If 926 the index field has value Num - 1 and the next hop is not same as the 927 End Point, the Intermediate Point MUST drop the received Measurement 928 Request with no further processing. In this case, the next hop would 929 have no space left in the Address vector to store its address. 930 Otherwise, the router MUST store one of its IPv6 addresses at 931 location Address[Index] and then increment the Index field. The IPv6 932 address added to the Address vector MUST have the following 933 properties: 935 o This address MUST be a unicast global or unique local address. 937 o This address MUST have the same prefix as the Start Point Address 938 and the End Point Address. This prefix, whose length in octets is 939 specified in the Compr field, MUST be elided before the address is 940 added to the Address vector. 942 o This address MUST be reachable in the Reverse direction. 944 If the router does not have an IPv6 address that satisfies the 945 properties mentioned above, it MUST discard the Measurement Request 946 with no further processing. 948 The Intermediate Point MUST then complete the processing of the 949 received Measurement Request as specified in Section 5.5. 951 5.4. When Measuring A Source Route 953 If a Source Route is being measured (i.e., H = 0), the Intermediate 954 Point MUST process the received Measurement Request in the following 955 manner. 957 If the Num field inside the received Measurement Request is set to 958 zero, thereby implying that an Address vector is not present, the 959 Intermediate Point MUST discard the received message with no further 960 processing. 962 The Intermediate Point MUST verify that the Address[Index] element 963 lists one of its unicast global or unique local IPv6 addresses (minus 964 the prefix whose length in octets is specified in the Compr field), 965 failing which it MUST discard the Measurement Request with no further 966 processing. The Intermediate Point MUST then increment the Index 967 field and use the Address[Index] element as the next hop (unless 968 Index value is now Num). If the Index value is now Num, the 969 Intermediate Point MUST use the End Point Address as the next hop. 971 The Intermediate Point MUST then complete the processing of the 972 received Measurement Request as specified in Section 5.5. 974 5.5. Final Processing 976 The Intermediate Point MUST drop the received Measurement Request 977 with no further processing: 979 o If the next hop address is not a unicast address; or 981 o If the next hop is not on-link; or 983 o If the next hop is not in the same RPL routing domain as the 984 Intermediate Point. 986 Next, the Intermediate Point MUST update the routing metric objects, 987 inside the Metric Container option(s) inside the Measurement Request, 988 either by updating the aggregated value for the routing metric or by 989 attaching the local values for the metric inside the object. An 990 Intermediate Point can only update the existing metric objects and 991 MUST NOT add any new routing metric object to the Metric Container. 992 An Intermediate Point MUST drop the Measurement Request with no 993 further processing if it cannot update a routing metric object 994 specified inside the Metric Container. 996 Finally, the Intermediate Point MUST unicast the Measurement Request 997 to the next hop. 999 6. Processing a Measurement Request at the End Point 1001 On receiving an MO, if a router chooses to process the message 1002 further and finds one of its unicast global or unique local IPv6 1003 addresses (minus the prefix whose length in octets is specified in 1004 the Compr field) listed as the End Point Address, the router 1005 considers itself the End Point and MUST process the received MO in 1006 the following manner. 1008 The End Point MUST discard the received message with no further 1009 processing if it is not a Measurement Request (i.e., T = 0). 1011 If the received Measurement Request traveled on a Hop-by-hop Route 1012 with a local RPLInstanceID with route accumulation on (i.e., H = 1, 1013 RPLInstanceID has a local value and A = 1), elements Address[0] 1014 through Address[Index - 1] in the Address vector contain a complete 1015 Source Route from the Start Point to the End Point, which the End 1016 Point MAY use, after reversal, to reach the Start Point. Note that 1017 the Source Route in the Address vector does not include the Start 1018 Point and the End Point addresses and the individual addresses do not 1019 include the common prefix whose length in octets is specified in the 1020 Compr field. 1022 If the received Measurement Request traveled on a Source Route and 1023 the Reverse flag is set to one (i.e., H = 0, R = 1), elements 1024 Address[0] through Address[Num - 1] in the Address vector contain a 1025 complete Source Route from the Start Point to the End Point, which 1026 the End Point MAY use, after reversal, to reach the Start Point. 1027 Again, the Source Route in the Address vector does not include the 1028 Start Point and the End Point addresses and the individual addresses 1029 do not include the common prefix whose length in octets is specified 1030 in the Compr field. 1032 The End Point MUST update the routing metric objects in the Metric 1033 Container options if required and MAY note the measured values for 1034 the complete route (especially, if the received Measurement Request 1035 is likely a response to an earlier Measurement Request that the End 1036 Point had sent to the Start Point with B flag set to one). 1038 The End Point MUST generate a Measurement Reply message as specified 1039 in Section 6.1. If the B flag is set to one in the received 1040 Measurement Request, the End Point SHOULD generate a new Measurement 1041 Request to measure the cost of its current (or the most preferred) 1042 route to the Start Point. The routing metrics used in the new 1043 Measurement Request MUST include the routing metrics specified in the 1044 received Measurement Request. 1046 6.1. Generating the Measurement Reply 1048 A Measurement Reply MUST have the Type (T) flag set to zero and need 1049 not contain the Address vector. The following fields inside a 1050 Measurement Reply MUST have the same values as they had inside the 1051 corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, Start 1052 Point Address, End Point Address and Metric Container Option(s). The 1053 remaining fields inside a Measurement Reply may have any value and 1054 MUST be ignored on reception at the Start Point; the received 1055 Measurement Request can, therefore, trivially be converted into a 1056 Measurement Reply by setting the Type (T) flag to zero. 1058 A Measurement Reply MUST be unicast back to the Start Point: 1060 o If the Measurement Request traveled along a global DAG, identified 1061 by the RPLInstanceID field, the Measurement Reply MAY be unicast 1062 back to the Start Point along the same DAG. 1064 o If the Measurement Request traveled along a Hop-by-hop Route with 1065 a local RPLInstanceID and accumulated a Source Route from the 1066 Start Point to the End Point, this Source Route MAY be used after 1067 reversal to send the Measurement Reply back to the Start Point. 1069 o If the Measurement Request traveled along a Source Route and the R 1070 flag inside the received message is set to one, the End Point MAY 1071 reverse the Source Route contained in the Address vector and use 1072 it to send the Measurement Reply back to the Start Point. 1074 7. Processing a Measurement Reply at the Start Point 1076 When a router receives an MO, it examines if one of its unicast IPv6 1077 addresses is listed as the Start Point Address. If yes, the router 1078 is the Start Point and MUST process the received message in the 1079 following manner. 1081 If the Start Point discovers that the received MO is not a 1082 Measurement Reply or if it no longer maintains state for the 1083 corresponding Measurement Request, it MUST discard the received 1084 message with no further processing. 1086 The Start Point can use the routing metric objects inside the Metric 1087 Container to evaluate the metrics for the measured P2P route. If a 1088 routing metric object contains local metric values recorded by 1089 routers on the route, the Start Point can make use of these local 1090 values by aggregating them into an end-to-end metric according to the 1091 aggregation rules for the specific metric. A Start Point is then 1092 free to interpret the metrics for the route according to its local 1093 policy. 1095 8. Security Considerations 1097 In general, the security considerations for the route measurement 1098 mechanism described in this document are similar to the ones for RPL 1099 (as described in Section 19 of [RFC6550]). Sections 6.1 and 10 of 1100 RPL specification [RFC6550] describe RPL's security framework that 1101 provides data confidentiality, authentication, replay protection and 1102 delay protection services. This security framework is applicable to 1103 the route measurement mechanism described here as well after taking 1104 in account the constraints specified in Section 3.2. 1106 This document requires all routers participating in a secure 1107 invocation of the route measurement process to use the Security 1108 Configuration decided by the Start Point. The intention is to avoid 1109 compromising the overall security of the route measurement due to 1110 some routers using a weaker Security Configuration. A router is 1111 allowed to participate in a "secure" route measurement only if it can 1112 support the Security Configuration in use, which also specifies the 1113 key in use. It does not matter whether the key is pre-installed or 1114 dynamically acquired after proper authentication. The router must 1115 have the key in use before it can process or generate Secure MO 1116 messages. Hence, from the perspective of the route measurement 1117 mechanism, there is no distinction between the "preinstalled" and 1118 "authenticated" security modes described in RPL specification 1119 [RFC6550]. Ofcourse if a compromised router has the key being used, 1120 it could cause the route measurement to fail, or worse, insert wrong 1121 information in Secure MO messages. 1123 A rogue router acting as the Start Point could use the route 1124 measurement mechanism defined in this document to measure routes from 1125 itself to other routers and thus find out key information about the 1126 LLN, e.g., the topological features of the LLN (such as the identity 1127 of the key routers in the topology) or the remaining energy levels 1128 [RFC6551] in the routers. This information can potentially be used 1129 to attack the LLN. A rogue router could also use this mechanism to 1130 send bogus Measurement Requests to arbitrary End Points. If 1131 sufficient Measurement Requests are sent, then it may cause CPU 1132 overload in the routers in the network, drain their batteries and 1133 cause traffic congestion in the network. Note that some of these 1134 problems would occur even if the compromised router were to generate 1135 bogus data traffic to arbitrary destinations. 1137 To protect against such misuse, this document allows RPL routers 1138 implementing this mechanism to not process MO messages (or process 1139 such messages selectively) based on a local policy. For example, an 1140 LLN deployment might require the use of Secure MO messages generated 1141 using a key that could be obtained only after proper authentication. 1142 Note that this document requires an LLN deployment to support Secure 1143 MO messages so that such policies can be enforced where considered 1144 essential. 1146 Since a Measurement Request can travel along a Source Route specified 1147 in the Address vector, some of the security concerns that led to the 1148 deprecation of Type 0 routing header [RFC5095] may be valid here. To 1149 address such concerns, the mechanism described in this document 1150 includes several remedies: 1152 o This document requires that a route inserted inside the Address 1153 vector must be a strict Source Route and must not include any 1154 multicast addresses. 1156 o This document requires that an MO message must not cross the 1157 boundaries of the RPL routing domain where it originated. A 1158 router must not forward a received MO message further if the next 1159 hop belongs to a different RPL routing domain. Hence, any 1160 security problems associated with the mechanism would be limited 1161 to one RPL routing domain. 1163 o This document requires that a router must drop a received 1164 Measurement Request if the next hop address is not on-link or if 1165 it is not a unicast address. 1167 9. IANA Considerations 1169 This document defines two new RPL messages: 1171 o "Measurement Object" (see Section 3.1), assigned a value TBD1 from 1172 the "RPL Control Codes" space [to be removed upon publication: 1173 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1174 [RFC6550]. IANA is requested to allocate TBD1 from the range 1175 0x00-0x7F to indicate a message without security enabled. The 1176 string TBD1 in this document should be replaced by the allocated 1177 value. These last two sentences should be removed before 1178 publication. 1180 o "Secure Measurement Object" (see Section 3.2), assigned a value 1181 TBD2 from the "RPL Control Codes" space [to be removed upon 1182 publication: 1183 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1184 [RFC6550]. IANA is requested to allocate TBD2 from the range 1185 0x80-0xFF to indicate a message with security enabled. The string 1186 TBD2 in this document should be replaced by the allocated value. 1187 These last two sentences should be removed before publication. 1189 +------+---------------------------+---------------+ 1190 | Code | Description | Reference | 1191 +------+---------------------------+---------------+ 1192 | TBD1 | Measurement Object | This document | 1193 | TBD2 | Secure Measurement Object | This document | 1194 +------+---------------------------+---------------+ 1196 RPL Control Codes 1198 10. Acknowledgements 1200 Authors gratefully acknowledge the contributions of Ralph Droms, 1201 Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert, 1202 Richard Kelsey and Zach Shelby in the development of this document. 1204 11. References 1206 11.1. Normative References 1208 [I-D.ietf-roll-p2p-rpl] 1209 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 1210 Martocci, "Reactive Discovery of Point-to-Point Routes in 1211 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 1212 (work in progress), March 2013. 1214 [I-D.ietf-roll-terminology] 1215 Vasseur, J., "Terminology in Low power And Lossy 1216 Networks", draft-ietf-roll-terminology-12 (work in 1217 progress), March 2013. 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, March 1997. 1222 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1223 Message Protocol (ICMPv6) for the Internet Protocol 1224 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1226 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1227 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1228 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1229 Lossy Networks", RFC 6550, March 2012. 1231 11.2. Informative References 1233 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1234 of Type 0 Routing Headers in IPv6", RFC 5095, 1235 December 2007. 1237 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1238 Routing Requirements in Low-Power and Lossy Networks", 1239 RFC 5826, April 2010. 1241 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1242 "Building Automation Routing Requirements in Low-Power and 1243 Lossy Networks", RFC 5867, June 2010. 1245 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1246 Barthel, "Routing Metrics Used for Path Calculation in 1247 Low-Power and Lossy Networks", RFC 6551, March 2012. 1249 Authors' Addresses 1251 Mukul Goyal (editor) 1252 University of Wisconsin Milwaukee 1253 3200 N Cramer St 1254 Milwaukee, WI 53211 1255 USA 1257 Phone: +1 414 2295001 1258 Email: mukul@uwm.edu 1260 Emmanuel Baccelli 1261 INRIA 1263 Phone: +33-169-335-511 1264 Email: Emmanuel.Baccelli@inria.fr 1265 URI: http://www.emmanuelbaccelli.org/ 1266 Anders Brandt 1267 Sigma Designs 1268 Emdrupvej 26A, 1. 1269 Copenhagen, Dk-2100 1270 Denmark 1272 Phone: +45 29609501 1273 Email: abr@sdesigns.dk 1275 Jerald Martocci 1276 Johnson Controls 1277 507 E Michigan Street 1278 Milwaukee 53202 1279 USA 1281 Phone: +1 414 524 4010 1282 Email: jerald.p.martocci@jci.com