--- 1/draft-ietf-roll-p2p-measurement-07.txt 2013-01-21 22:58:11.660207445 +0100 +++ 2/draft-ietf-roll-p2p-measurement-08.txt 2013-01-21 22:58:11.700207649 +0100 @@ -1,25 +1,25 @@ Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee -Expires: June 27, 2013 E. Baccelli +Expires: July 25, 2013 E. Baccelli INRIA A. Brandt Sigma Designs J. Martocci Johnson Controls - December 24, 2012 + January 21, 2013 A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network - draft-ietf-roll-p2p-measurement-07 + draft-ietf-roll-p2p-measurement-08 Abstract This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. Status of this Memo @@ -30,71 +30,71 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 27, 2013. + This Internet-Draft will expire on July 25, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5 + 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4. Originating a Measurement Request . . . . . . . . . . . . . . 10 + 4. Originating a Measurement Request . . . . . . . . . . . . . . 11 4.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 11 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation Off . . . . . . . . 12 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation On . . . . . . . . . 13 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14 5. Processing a Measurement Request at an Intermediate Point . . 15 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 16 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation Off . . . . . . . . 17 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation On . . . . . . . . . 18 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 19 6. Processing a Measurement Request at the End Point . . . . . . 20 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 20 7. Processing a Measurement Reply at the Start Point . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Point to point (P2P) communication between arbitrary routers in a Low power and Lossy Network (LLN) is a key requirement for many applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs (RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic Graph (DAG) built to optimize the routing costs to reach the DAG's root. The P2P routing functionality, available under RPL, has the @@ -185,33 +185,66 @@ metrics along a P2P route to an End Point within the LLN. The route is measured in the Forward direction. Such a route could be a Source Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route with the initial part consisting of hop-by-hop ascent to the root of a non-storing DAG [RFC6550] and the final part consisting of a source-routed descent to the End Point. The Start Point decides what metrics to measure and sends a Measurement Request message, carrying - the desired routing metric objects, along the route. On receiving a + the desired routing metric objects, along the route. If a Source + Route is being measured, the Measurement Request carries the route + inside an Address vector. If a Hop-by-hop Route is being measured, + the Measurement Request identifies the route by its RPLInstanceID + [RFC6550] (and, in case the RPLInstanceID is a local value, the Start + Point's IPv6 address associated with the route). On receiving a Measurement Request, an Intermediate Point updates the routing metric values inside the message and forwards it to the next hop on the route. Thus, the Measurement Request accumulates the values of the routing metrics for the complete route as it travels towards the End - Point. The Measurement Request may also accumulate a Source Route - that the End Point may use to reach the Start Point. Upon receiving - the Measurement Request, the End Point unicasts a Measurement Reply - message, carrying the accumulated values of the routing metrics, back - to the Start Point. Optionally, the Start Point may allow an - Intermediate Point to generate the Measurement Reply if the - Intermediate Point already knows the relevant routing metric values - along rest of the route. + Point. Upon receiving the Measurement Request, the End Point + unicasts a Measurement Reply message, carrying the accumulated values + of the routing metrics, back to the Start Point. Optionally, the + Start Point may allow an Intermediate Point to generate the + Measurement Reply if the Intermediate Point already knows the + relevant routing metric values along rest of the route. + + The Measurement Request may include an Address vector that serves one + of the following functions: + + o To accumulate a Source Route for End Point's use: If a Hop-by-hop + Route with a local RPLInstanceID is being measured, the Start + Point may require each Intermediate Point to add its IPv6 address + to an Address vector inside the Measurement Request. The Source + Route, thus accumulated, can be used by the End Point to reach the + Start Point. In particular, the End Point may use the accumulated + Source Route to send the Measurement Reply back to the Start + Point. In this case, the Start Point includes a suitably-sized + Address vector in the Measurement Request. The size of the + Address vector puts a hard limit on the length of the accumulated + route. An Intermediate Point is not allowed to modify the size of + the Address vector and must discard a received Measurement Request + if the Address vector is not large enough to contain the complete + route. + + o To carry the Source Route being measured: The Start Point may + insert an Address vector inside the Measurement Request to carry + the Source Route being measured. Also, the root of a global non- + storing DAG may insert an Address vector, carrying a Source Route + from itself to the End Point, inside a Measurement Request message + if this message had been traveling along this DAG so far. In both + cases, an Intermediate Point is not allowed to modify an existing + Address vector before forwarding the Measurement Request further. + In other words, an Intermediate Point is not allowed to modify the + Source Route along which the Measurement Request is currently + traveling. 3. The Measurement Object (MO) This document defines two new RPL Control Message types, the Measurement Object (MO), with code TBD1, and the Secure MO, with code TBD2. An MO serves as both Measurement Request and Measurement Reply. 3.1. Format of the base MO @@ -224,21 +257,21 @@ | Start Point Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | End Point Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | - . Address[1..Num] . + . Address[0..Num-1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Metric Container Option(s) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the base Measurement Object (MO) @@ -367,65 +400,76 @@ eliding Compr number of prefix octets. o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr number of prefix octets elided) representing a Source Route: * Each element in the vector has size (16 - Compr) octets. * The total number of elements inside the Address vector is given by the Num field. - * When the Measurement Request is traveling along a Hop-by-hop - Route with local RPLInstanceID and has the A flag set to one - (i.e., H = 1, RPLInstanceID has a local value, A = 1), the - Address vector is used to accumulate a Source Route that can be - used by the End Point, after reversal, to send the Measurement - Reply back to the Start Point. The route MUST be accumulated - in the Forward direction but the IPv6 addresses in the - accumulated route MUST be reachable in the Backward direction. - An Intermediate Point adding its address to the Address vector - MUST ensure that a routing loop involving this router does not - exist in the accumulated route. - - * When the Measurement Request is traveling along a Source Route - (i.e., H = 0), the Address vector MUST contain a complete route - to the End Point and the IPv6 addresses in the Address vector - MUST be reachable in the Forward direction. A router (the - Start Point or an Intermediate Point) inserting an Address - vector inside a Measurement Request MUST ensure that no address - appears more than once inside the vector. Each router on the - way MUST ensure that a routing loop involving this router does - not exist within the Source Route. The Start Point MAY set the - R flag in the Measurement Request if the route in the Address - vector represents a complete route from the Start Point to the - End Point and this route can be used by the End Point, after - reversal, to send the Measurement Reply message back to the - Start Point (i.e., the IPv6 addresses in the Address vector are - reachable in the Backward direction). - * The Start Point and End Point addresses MUST NOT be included in the Address vector. * The Address vector MUST NOT contain any multicast addresses. + * If the Start Point wants to measure a Hop-by-hop Route with a + local RPLInstanceID and accumulate a Source Route for the End + Point's use (i.e., the Measurement Request has the H flag set + to 1, RPLInstanceID set to a local value and the A flag set to + 1), it MUST include a suitably-sized Address vector in the + Measurement Request. As the Measurement Request travels over + the route being measured, the Address vector accumulates a + Source Route that can be used by the End Point, after reversal, + to reach (and, in particular, to send the Measurement Reply + back to) the Start Point. The route MUST be accumulated in the + Forward direction but the IPv6 addresses in the accumulated + route MUST be reachable in the Backward direction. An + Intermediate Point adding its address to the Address vector + MUST NOT modify the size of the Address vector. + + * If the Start Point wants to measure a Source Route, it MUST + include an Address vector, containing the route being measured, + inside the Measurement Request. Similarly, if the Measurement + Request had been traveling along a global non-storing DAG so + far, the root of this DAG may insert an Address vector, + containing a Source Route from itself to the End Point, inside + the Measurement Request. In both cases, the Source Route + inside the Address vector MUST consist of IPv6 addresses + reachable in the Forward direction. Further, in both cases, an + Intermediate Point MUST NOT modify the contents of the existing + Address vector before forwarding the Measurement Request + further. In other words, an Intermediate Point MUST NOT modify + the Source Route along which the Measurement Request is + currently traveling. The Start Point MAY set the R flag in the + Measurement Request to one if the Source Route inside the + Address vector can be used by the End Point, after reversal, to + reach (and, in particular, to send the Measurement Reply back + to) the Start Point. In other words, the Start Point MAY set + the R flag to one only if all the IPv6 addresses in the Address + vector are reachable in the Backward direction. + o Metric Container Options: A Measurement Request MUST contain one or more Metric Container options [RFC6550] to accumulate the values of the selected routing metrics in the manner described in [RFC6551] for the route being measured. Section 4 describes how does a Start Point set various fields inside a Measurement Request in different cases. Section 5 describes how does an Intermediate Point process a received Measurement Request before forwarding it further. Section 6 describes how does the End Point process a received Measurement Request and generate a Measurement Reply. Finally, Section 7 describes how does the Start - Point process a received Measurement Reply. + Point process a received Measurement Reply. In the following + discussion, any reference to discarding a received Measurement + Request/Reply with "no further processing" does not preclude updating + the appropriate error counters or any similar actions. 3.2. Secure MO A Secure MO follows the format in Figure 7 of [RFC6550], where the base format is the base MO shown in Figure 1. 4. Originating a Measurement Request A Start Point sets various fields inside the Measurement Request it generates in the manner described below. The Start Point MUST also @@ -540,22 +584,22 @@ o End Point Address: MUST be set to a unicast IPv6 address of the End Point after eliding Compr number of prefix octets. 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation On If a Hop-by-hop Route with a local RPLInstanceID is being measured and the Start Point desires the MO to accumulate a Source Route for the End Point to send the Measurement Reply message back, the MO MUST - contain an Address vector and various MO fields MUST be set in the - following manner: + contain a suitably-sized Address vector and various MO fields MUST be + set in the following manner: o RPLInstanceID: MUST be set to the RPLInstanceID of the route being measured. o Compr: MUST be set to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/End Point Address fields and the Address vector. o Type (T): MUST be set to one since the MO represents a Measurement Request. @@ -644,30 +688,20 @@ the Start Point to the End Point (excluding the Start Point and the End Point). * The IPv6 addresses (with Compr prefix octets elided) in the Address vector MUST be reachable in the Forward direction. * If the R flag is set to one, the IPv6 addresses (with Compr prefix octets elided) in the Address vector MUST also be reachable in the Backward direction. - * To avoid loops in the Source Route, the Start Point MUST ensure - compliance to the following rules: - - + Any IPv6 address MUST NOT appear more than once in the - Address vector. - - + If the Address vector includes multiple IPv6 addresses - assigned to the Start Point's interfaces, such addresses - MUST appear back to back inside the Address vector. - * Each address appearing in the Address vector MUST be a unicast address. 5. Processing a Measurement Request at an Intermediate Point A router (an Intermediate Point or the End Point) MAY discard a received MO with no processing to meet any policy-related goal. Such policy goals may include the need to reduce the router's CPU load or to enhance its battery life or to prevent misuse of this mechanism by unauthorized nodes. @@ -692,44 +726,45 @@ field) and processes the received MO accordingly in the manner specified next. 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID If a Hop-by-hop Route with a global RPLInstanceID is being measured (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate Point MUST process the received Measurement Request in the following manner. - The Intermediate Point MUST discard the received Measurement Request - with no further processing if the Num field is not set to zero or if - the Address vector is present in the received message. + If the Num field inside the received Measurement Request is not set + to zero, thereby implying that an Address vector is present, the + Intermediate Point MUST discard the received message with no further + processing. If the Intermediate Reply (I) flag is set to one in the received Measurement Request and the Intermediate Point knows the values of the routing metrics, specified in the Metric Container options, for the remainder of the route, it MAY generate a Measurement Reply on the End Point's behalf in the manner specified in Section 6.1 (after including in the Measurement Reply the relevant routing metric values for the complete route being measured). Otherwise, the Intermediate Point MUST process the received message in the following manner. The Intermediate Point MUST then determine the next hop on the route being measured using the RPLInstanceID and the End Point Address. If the Intermediate Point is the root of the non-storing global DAG along which the received Measurement Request had been traveling so far, it MUST process the received Measurement Request in the following manner: - o The router MUST discard the Measurement Request with no further - processing and MAY send an ICMPv6 Destination Unreachable (with - Code 0 - No Route To Destination) error message to the Start Point - if it does not know how to reach the End Point. + o If the router does not know how to reach the End Point, it MUST + discard the Measurement Request with no further processing and MAY + send an ICMPv6 Destination Unreachable (with Code 0 - No Route To + Destination) error message to the Start Point. o Otherwise, unless the router determines the End Point itself to be the next hop, the router MUST make the following changes in the received Measurement Request: * Set the H, A, R and I flags to zero (the A and R flags should already be zero in the received message). * Leave remaining fields unchanged (the Num field would be modified in next steps). Note that the RPLInstanceID field @@ -742,30 +777,20 @@ specify a Source Route to the End Point inside the Address vector as per the following rules: + The Address vector MUST contain a complete route from the router to the End Point (excluding the router and the End Point); + The IPv6 addresses (with Compr prefix octets elided) in the Address vector MUST be reachable in the Forward direction; - + To avoid loops in the Source Route, the router MUST ensure - that - - - Any IPv6 address MUST NOT appear more than once in the - Address vector; - - - If the Address vector includes multiple IPv6 addresses - assigned to the router's interfaces, such addresses MUST - appear back to back inside the Address vector. - + Each address appearing in the Address vector MUST be a unicast address. * Specify in the Num field the number of address elements in the Address vector. * Set the Index field to zero to indicate the position in the Address vector of the next hop on the route. Thus, Address[0] element contains the address of the next hop on the route. @@ -773,92 +798,85 @@ received Measurement Request as specified in Section 5.5. 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation Off If a Hop-by-hop Route with a local RPLInstanceID is being measured and the route accumulation is off (i.e., H = 1, RPLInstanceID has a local value, A = 0), the Intermediate Point MUST process the received Measurement Request in the following manner. - The Intermediate Point MUST discard the received Measurement Request - with no further processing if the Num field is not zero or if the - Address vector is present in the received message. + If the Num field inside the received Measurement Request is not set + to zero, thereby implying that an Address vector is present, the + Intermediate Point MUST discard the received message with no further + processing. The Intermediate Point MUST then determine the next hop on the route being measured using the RPLInstanceID, the End Point Address and the Start Point Address (which represents the DODAGID of the route being - measured). The Intermediate Point MUST discard the Measurement - Request with no further processing and MAY send an ICMPv6 Destination - Unreachable (with Code 0 - No Route To Destination) error message to - the Start Point if it can not determine the next hop. Otherwise, the - Intermediate Point MUST complete the processing of the received + measured). If the Intermediate Point can not determine the next hop, + it MUST discard the Measurement Request with no further processing + and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No + Route To Destination) error message to the Start Point. Otherwise, + the Intermediate Point MUST complete the processing of the received Measurement Request as specified in Section 5.5. 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With Route Accumulation On If a Hop-by-hop Route with a local RPLInstanceID is being measured and the route accumulation in on (i.e., H = 1, RPLInstanceID has a local value, A = 1), the Intermediate Point MUST process the received Measurement Request in the following manner. - The Intermediate Point MUST discard the received Measurement Request - with no further processing if the Num field is set to zero or if the - Address vector is not present in the received message. + If the Num field inside the received Measurement Request is set to + zero, thereby implying that an Address vector is not present, the + Intermediate Point MUST discard the received message with no further + processing. The Intermediate Point MUST then determine the next hop on the route being measured using the RPLInstanceID, the End Point Address and the Start Point Address (which represents the DODAGID of the route being - measured). The Intermediate Point MUST discard the Measurement - Request with no further processing and MAY send an ICMPv6 Destination - Unreachable (with Code 0 - No Route To Destination) error message to - the Start Point if it can not determine the next hop. The - Intermediate Point MUST drop the received Measurement Request with no - further processing if the index field has value Num - 1 and the next - hop is not same as the End Point. In this case, the next hop would + measured). If the Intermediate Point can not determine the next hop, + it MUST discard the Measurement Request with no further processing + and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No + Route To Destination) error message to the Start Point. If the index + field has value Num - 1 and the next hop is not same as the End + Point, the Intermediate Point MUST drop the received Measurement + Request with no further processing. In this case, the next hop would have no space left in the Address vector to store its address. - - Otherwise, the Intermediate Point MUST check if adding one of its - IPv6 addresses to the the Address vector would create a routing loop - in the accumulated route. If yes, the router MUST discard the packet - with no further processing. Otherwise, the router MUST store one of - its unicast IPv6 addresses (after eliding Compr prefix octets) at - location Address[Index] and then increment the Index field. The IPv6 - address added to the Address vector MUST be reachable in the Backward - direction. + Otherwise, the router MUST store one of its unicast IPv6 addresses + (after eliding Compr prefix octets) at location Address[Index] and + then increment the Index field. The IPv6 address added to the + Address vector MUST be reachable in the Backward direction. The Intermediate Point MUST then complete the processing of the received Measurement Request as specified in Section 5.5. 5.4. When Measuring A Source Route If a Source Route is being measured (i.e., H = 0), the Intermediate Point MUST process the received Measurement Request in the following manner. - The Intermediate Point MUST discard the received Measurement Request - with no further processing if the Num field is set to zero or if the - Address vector is not present in the received message. + If the Num field inside the received Measurement Request is set to + zero, thereby implying that an Address vector is not present, the + Intermediate Point MUST discard the received message with no further + processing. - The Intermediate Point MUST then determine the next hop on the route - being measured in the manner described below. The Intermediate Point - MUST verify that the Address[Index] element lists one of its unicast - IPv6 addresses, failing which it MUST discard the Measurement Request - with no further processing. To prevent loops, the Intermediate Point - MUST discard the Measurement Request with no further processing if - the Address vector includes multiple IPv6 addresses assigned to its - interfaces and if such addresses do not appear back to back inside - the Address vector. The Intermediate Point MUST then increment the - Index field and use the Address[Index] element as the next hop - (unless Index value is now Num). If the Index value is now Num, the - Intermediate Point MUST use the End Point Address as the next hop. + The Intermediate Point MUST verify that the Address[Index] element + lists one of its unicast IPv6 addresses, failing which it MUST + discard the Measurement Request with no further processing. The + Intermediate Point MUST then increment the Index field and use the + Address[Index] element as the next hop (unless Index value is now + Num). If the Index value is now Num, the Intermediate Point MUST use + the End Point Address as the next hop. The Intermediate Point MUST then complete the processing of the received Measurement Request as specified in Section 5.5. 5.5. Final Processing The Intermediate Point MUST drop the received Measurement Request with no further processing: o If the next hop address is not a unicast address; or @@ -948,23 +966,24 @@ reverse the Source Route contained in the Address vector and use it to send the Measurement Reply back to the Start Point. 7. Processing a Measurement Reply at the Start Point When a router receives an MO, it examines if one of its unicast IPv6 addresses is listed as the Start Point Address. If yes, the router is the Start Point and MUST process the received message in the following manner. - The Start Point MUST discard the packet with no further processing if - the received MO is not a Measurement Reply or if the Start Point has - no recollection of sending the corresponding Measurement Request. + If the Start Point discovers that the received MO is not a + Measurement Reply or if it has no recollection of sending the + corresponding Measurement Request, it MUST discard the received + message with no further processing. The Start Point can use the routing metric objects inside the Metric Container to evaluate the metrics for the measured P2P route. If a routing metric object contains local metric values recorded by routers on the route, the Start Point can make use of these local values by aggregating them into an end-to-end metric according to the aggregation rules for the specific metric. A Start Point is then free to interpret the metrics for the route according to its local policy. @@ -988,31 +1007,23 @@ vector must be a strict Source Route and must not include any multicast addresses. o This document requires that an MO message must not cross the boundaries of the RPL routing domain where it originated. A router must not forward a received MO message further if the next hop belongs to a different RPL routing domain. Hence, any security problems associated with the mechanism would be limited to one RPL routing domain. - o This document requires that a router must drop a received MO - message if the next hop address is not on-link or if it is not a - unicast address. - - o This document requires that a router must check the Source Route - inside the Address vector of each received MO message to ensure - that it does not contain a loop involving the router. The router - must drop the received packet if the Source Route does contain - such a loop. This and the previous two rules protect the network - against some of the security concerns even if a compromised node - inserts a malformed Address vector inside the MO message. + o This document requires that a router must drop a received + Measurement Request if the next hop address is not on-link or if + it is not a unicast address. The measurement mechanism described in this document may potentially be used by a rogue node to find out key information about the LLN, e.g., the topological features of the LLN (such as the identity of the key nodes in the topology) or the remaining energy levels [RFC6551] in the LLN routers. This information can potentially be used to attack the LLN. To protect against such misuse, this document allows RPL routers implementing this mechanism to not process MO messages (or process such messages selectively) based on a local policy. Further, an LLN deployment may use Secure MO @@ -1045,23 +1056,23 @@ | Code | Description | Reference | +------+---------------------------+---------------+ | TBD1 | Measurement Object | This document | | TBD2 | Secure Measurement Object | This document | +------+---------------------------+---------------+ RPL Control Codes 10. Acknowledgements - Authors gratefully acknowledge the contributions of Matthias Philipp, - Pascal Thubert, Richard Kelsey and Zach Shelby in the development of - this document. + Authors gratefully acknowledge the contributions of Adrian Farrel, + Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and + Zach Shelby in the development of this document. 11. References 11.1. Normative References [I-D.ietf-roll-p2p-rpl] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-15 (work in progress), December 2012.