From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6998.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc6998.txt (limited to 'doc/rfc/rfc6998.txt') diff --git a/doc/rfc/rfc6998.txt b/doc/rfc/rfc6998.txt new file mode 100644 index 0000000..b8ed024 --- /dev/null +++ b/doc/rfc/rfc6998.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Goyal, Ed. +Request for Comments: 6998 Univ. of Wisconsin Milwaukee +Category: Experimental E. Baccelli +ISSN: 2070-1721 INRIA + A. Brandt + Sigma Designs + J. Martocci + Johnson Controls + August 2013 + + +A Mechanism to Measure the Routing Metrics along a Point-to-Point Route + in a Low-Power and Lossy Network + +Abstract + + This document specifies a mechanism that enables a Routing Protocol + for Low-power and Lossy Networks (RPL) router to measure the + aggregated values of given routing metrics along an existing route + towards another RPL router, thereby allowing the router to decide if + it wants to initiate the discovery of a better route. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6998. + + + + + + + + + + + + +Goyal, et al. Experimental [Page 1] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +Copyright Notice + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 2] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................5 + 2. Overview ........................................................6 + 3. The Measurement Object (MO) .....................................7 + 3.1. Format of the Base MO ......................................8 + 3.2. Secure MO .................................................12 + 4. Originating a Measurement Request ..............................13 + 4.1. When Measuring a Hop-by-Hop Route with a Global + RPLInstanceID .............................................14 + 4.2. When Measuring a Hop-by-Hop Route with a Local + RPLInstanceID with Route Accumulation Off .................15 + 4.3. When Measuring a Hop-by-Hop Route with a Local + RPLInstanceID with Route Accumulation On ..................16 + 4.4. When Measuring a Source Route .............................17 + 5. Processing a Measurement Request at an Intermediate Point ......19 + 5.1. When Measuring a Hop-by-Hop Route with a Global + RPLInstanceID .............................................19 + 5.2. When Measuring a Hop-by-Hop Route with a Local + RPLInstanceID with Route Accumulation Off .................21 + 5.3. When Measuring a Hop-by-Hop Route with a Local + RPLInstanceID with Route Accumulation On ..................21 + 5.4. When Measuring a Source Route .............................22 + 5.5. Final Processing ..........................................23 + 6. Processing a Measurement Request at the End Point ..............23 + 6.1. Generating the Measurement Reply ..........................24 + 7. Processing a Measurement Reply at the Start Point ..............25 + 8. Security Considerations ........................................25 + 9. IANA Considerations ............................................27 + 10. Acknowledgements ..............................................27 + 11. References ....................................................28 + 11.1. Normative References .....................................28 + 11.2. Informative References ...................................28 + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 3] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +1. Introduction + + Point-to-point (P2P) communication between arbitrary routers in a + Low-power and Lossy Network (LLN) is a key requirement for many home + and commercial building automation 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 following key + limitations: + + o The P2P routes are restricted to use the DAG links only. Such P2P + routes may potentially be suboptimal and may lead to traffic + congestion near the DAG root. + + o RPL is a proactive routing protocol and hence requires that all + P2P routes be established ahead of the time they are used. Many + LLN applications require the ability to establish P2P routes "on + demand". + + To ameliorate situations where the core RPL's P2P routing + functionality does not meet an application's requirements, [RFC6997] + describes P2P-RPL, an extension to core RPL. P2P-RPL provides a + reactive mechanism to discover P2P routes that meet the specified + routing constraints [RFC6551]. In some cases, the application's + requirements or the LLN's topological features allow a router to + infer these routing constraints implicitly. For example, the + application may require that the end-to-end loss rate and/or latency + along the route be below certain thresholds, or the LLN topology may + be such that a router can safely assume that its destination is less + than a certain number of hops away from itself. + + When the existing routes are deemed unsatisfactory but the router + does not implicitly know the routing constraints to be used in + P2P-RPL route discovery, it may be necessary for the router to + measure the aggregated values of the routing metrics along the + existing route. This knowledge will allow the router to frame + reasonable routing constraints to discover a better route using + P2P-RPL. For example, if the router determines the aggregate ETX + (expected transmission count) [RFC6551] along an existing route to be + "x", it can use "ETX < x*y", where y is a certain fraction, as the + routing constraint for use in P2P-RPL route discovery. Note that it + is important that the routing constraints not be overly strict; + otherwise, the P2P-RPL route discovery may fail even though a route + exists that is much better than the one currently being used. + + + + + + +Goyal, et al. Experimental [Page 4] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + This document specifies a mechanism that enables a RPL router to + measure the aggregated values of the routing metrics along an + existing route to another RPL router in an LLN, thereby allowing the + router to decide if it wants to discover a better route using P2P-RPL + and determine the routing constraints to be used for this purpose. + Thus, the utility of this mechanism is dependent on the existence of + P2P-RPL [RFC6997]. The hope is that experiments with P2P-RPL and the + mechanism defined in this document will result in feedback on the + utility and benefits of this document, so that a Standards Track + version of this document can then be developed. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + Additionally, this document uses terminology from [RFC6550], + [RFC6554], and [RFC6997]. Further terminology may be found in + [ROLL-TERMS]. This document defines the following terms: + + Start Point: The RPL router that initiates the measurement process + defined in this document and that is the start point of the P2P + route being measured. + + End Point: The RPL router at the end point of the P2P route being + measured. + + Intermediate Point: A RPL router, other than the Start Point and the + End Point, on the P2P route being measured. + + The following terms, as already defined in [RFC6997], are redefined + in this document in the following manner: + + Forward direction: The direction from the Start Point to the + End Point. + + Reverse direction: The direction from the End Point to the + Start Point. + + + + + + + + + + + +Goyal, et al. Experimental [Page 5] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +2. Overview + + The mechanism described in this document can be used by a Start Point + in an LLN to measure the aggregated values of selected routing + 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 or a Hop-by-hop Route established using RPL [RFC6550] or + P2P-RPL [RFC6997]. 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. 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, if 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. 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 the 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 the End Point's use: If a Hop-by- + hop Route with a local RPLInstanceID is being measured, the + Start Point may require that each Intermediate Point add its + global or unique-local 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. + + + + + +Goyal, et al. Experimental [Page 6] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + 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. + This Source Route must consist of global or unique-local IPv6 + addresses. An Intermediate Point is not allowed to modify an + 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. + +3. The Measurement Object (MO) + + This document defines two new RPL control message types: the + Measurement Object (MO), with code 0x06; and the Secure MO, with + code 0x86. An MO serves as both Measurement Request and + Measurement Reply. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 7] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +3.1. Format of the Base MO + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Start Point Address . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . End Point Address . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Address[0..Num-1] . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Metric Container Option(s) . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Format of the Base Measurement Object (MO) + + The format of a base MO is shown in Figure 1. A base MO consists of + the following fields: + + o RPLInstanceID: This field specifies the RPLInstanceID of the + Hop-by-hop Route along which the Measurement Request travels + (or traveled initially until it switched over to a Source Route). + + o Compr: In many LLN deployments, IPv6 addresses share a well-known, + common prefix. In such cases, the common prefix can be elided + when specifying IPv6 addresses in the Start Point/End Point + Address fields and the Address vector. The "Compr" field, a 4-bit + unsigned integer, is set by the Start Point 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. The + Start Point will set the Compr value to zero if full IPv6 + addresses are to be carried in the Start Point Address/End Point + Address fields and the Address vector. + + + + +Goyal, et al. Experimental [Page 8] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Type (T): This flag is set to one if the MO represents a + Measurement Request. The flag is set to zero if the MO is a + Measurement Reply. + + o Hop-by-hop (H): The Start Point MUST set this flag to one if (at + least the initial part of) the route being measured is hop by hop. + In that case, the Hop-by-hop Route is identified by the + RPLInstanceID, the End Point Address, and, if the RPLInstanceID is + a local value, the Start Point Address fields inside the + Measurement Request. Here, the Start Point Address field is + required to be the same as the DODAGID (the identifier of the + Destination-Oriented DAG (DODAG) root) [RFC6550] of the route + being measured. The Start Point MUST set the H flag to zero if + the route being measured is a Source Route specified in the + Address vector. An Intermediate Point MUST set the H flag in an + outgoing Measurement Request to the same value that it had in the + corresponding incoming Measurement Request, except under the + following circumstance: If the Intermediate Point is the root of + the non-storing global DAG along which the Measurement Request had + been traveling so far and it intends to insert a Source Route + inside the Address vector to direct the Measurement Request + towards the End Point, then it MUST set the H flag to zero. + + o Accumulate Route (A): A value of 1 in this flag indicates that the + Measurement Request is accumulating a Source Route for use by the + End Point to send the Measurement Reply back to the Start Point. + Route accumulation MUST NOT be used (i.e., this flag MUST NOT be + set to one) inside a Measurement Request, unless it travels along + a Hop-by-hop Route represented by a local RPLInstanceID (i.e., H = + 1 and RPLInstanceID has a local value). Route accumulation MAY be + used (i.e., this flag MAY be set to one) if the Measurement + Request is traveling along a Hop-by-hop Route with a local + RPLInstanceID. In this case, if the route accumulation is on, an + Intermediate Point adds its unicast global/unique-local IPv6 + address (after eliding Compr number of prefix octets) to the + Address vector in the manner specified in Section 5.3. In other + cases, this flag MUST be set to zero on transmission and ignored + on reception. Route accumulation is not allowed when the + Measurement Request travels along a Hop-by-hop Route with a global + RPLInstanceID, i.e., along a global DAG, because: + + * The DAG's root may need the Address vector to insert a Source + Route to the End Point; and + + * The End Point can presumably reach the Start Point along this + global DAG (identified by the RPLInstanceID field). + + + + + +Goyal, et al. Experimental [Page 9] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Reverse (R): A value of 1 in this flag inside a Measurement + Request indicates that the Address vector contains a complete + Source Route from the Start Point to the End Point, which can be + used, after reversal, by the End Point to send the Measurement + Reply back to the Start Point. This flag MAY be set to one inside + a Measurement Request only if a Source Route, from the Start Point + to the End Point, is being measured. Otherwise, this flag MUST be + set to zero on transmission and ignored on reception. + + o Back Request (B): A value of 1 in this flag serves as a request to + the End Point to send a Measurement Request towards the + Start Point. On receiving a Measurement Request with the B flag + set to one, the End Point SHOULD generate a Measurement Request to + measure the cost of its current (or the most preferred) route to + the Start Point. Receipt of this Measurement Request would allow + the Start Point to know the cost of the back route from the + End Point to itself and thus determine the round-trip cost of + reaching the End Point. + + o Intermediate Reply (I): A value of 1 in this flag serves as + permission to an Intermediate Point to generate a Measurement + Reply if it knows the aggregated values of the routing metrics + being measured for the rest of the route. Setting this flag to + one may be useful in scenarios where the Hop Count [RFC6551] is + the routing metric of interest and an Intermediate Point (e.g., + the root of a non-storing global DAG or a common ancestor of the + Start Point and the End Point in a storing global DAG) may know + the Hop Count of the remainder of the route to the End Point. + This flag MAY be set to one only if a Hop-by-hop Route with a + global RPLInstanceID is being measured (i.e., H = 1 and + RPLInstanceID has a global value). Otherwise, this flag MUST be + set to zero on transmission and ignored on reception. + + o SeqNo: This is a 6-bit sequence number, assigned by the + Start Point, that allows the Start Point to uniquely identify a + Measurement Request and the corresponding Measurement Reply. + + o Num: This field indicates the number of elements, each + (16 - Compr) octets in size, inside the Address vector. If the + value of this field is zero, the Address vector is not present in + the MO. + + o Index: If the Measurement Request is traveling along a Source + Route contained in the Address vector (i.e., H = 0), this field + indicates the index in the Address vector of the next hop on the + route. If the Measurement Request is traveling along a Hop-by-hop + Route with a local RPLInstanceID and the route accumulation is on + (i.e., H = 1, RPLInstanceID has a local value, and A = 1), this + + + +Goyal, et al. Experimental [Page 10] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + field indicates the index in the Address vector where an + Intermediate Point receiving the Measurement Request must store + its IPv6 address. Otherwise, this field MUST be set to zero on + transmission and ignored on reception. + + o Start Point Address: This is a unicast global or unique-local IPv6 + address of the Start Point after eliding Compr number of prefix + octets. If the Measurement Request is traveling along a Hop-by- + hop Route and the RPLInstanceID field indicates a local value, the + Start Point Address field MUST specify the DODAGID value that, + along with the RPLInstanceID and the End Point Address, uniquely + identifies the Hop-by-hop Route being measured. + + o End Point Address: This is a unicast global or unique-local IPv6 + address of the End Point after eliding Compr number of prefix + octets. + + o Address[0..Num-1]: This field is a vector of unicast global or + unique-local 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. + + * 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 one, RPLInstanceID set to a local value, and the A flag + set to one), 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 Reverse direction. An + Intermediate Point MUST add only a global or unique-local IPv6 + address to the Address vector and MUST NOT modify the size of + the Address vector. + + + + + +Goyal, et al. Experimental [Page 11] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + * 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 only of global or + unique-local IPv6 addresses that are 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 Reverse 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 a Start Point sets various fields inside a + Measurement Request in different cases. Section 5 describes how an + Intermediate Point processes a received Measurement Request before + forwarding it further. Section 6 describes how the End Point + processes a received Measurement Request and generates a Measurement + Reply. Finally, Section 7 describes how the Start Point processes 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 shown in Figure 7 of [RFC6550], where + the base format is the base MO shown in Figure 1. Sections 6.1, 10, + and 19 of [RFC6550] describe the RPL security framework. These + sections are applicable to the use of Secure MO messages as well, + except as constrained in this section. An LLN deployment MUST + support the use of Secure MO messages so that it has the ability to + invoke RPL-provided security mechanisms and prevent misuse of the + measurement mechanism by unauthorized routers. + + + +Goyal, et al. Experimental [Page 12] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + The Start Point determines whether Secure MO messages are to be used + in a particular route measurement and, if yes, the Security + Configuration (see definition in [RFC6997]) to be used for that + purpose. The Start Point MUST NOT set the "Key Identifier Mode" + field to a value of 1 inside this Security Configuration, since this + setting indicates the use of a per-pair key, which is not suitable + for securing the Measurement Request messages that travel over + multiple hops. A router (an Intermediate Point or the End Point) + participating in a particular route measurement + + o MUST generate a Secure MO message (a Measurement Request or a + Measurement Reply) if the received Measurement Request is a Secure + MO. The Security Configuration used in generating a Secure MO + message MUST be the same as the one used in the received message. + + o MUST NOT generate a Secure MO message if the received Measurement + Request is not a Secure MO. + + A router MUST discard a received Measurement Request if it cannot + follow the above-mentioned rules. If the Start Point sends a + Measurement Request in a Secure MO message using a particular + Security Configuration, it MUST discard the corresponding Measurement + Reply it receives with no further processing, unless the Measurement + Reply is received in a Secure MO message generated with the same + Security Configuration as the one used in the Measurement Request. + + In the following discussion, any reference to an MO message is also + applicable to a Secure MO message, unless noted otherwise. + +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 + include the routing metric objects [RFC6551] of interest inside one + or more Metric Container options inside the Measurement Request. The + Start Point then determines the next hop on the route being measured. + If a Hop-by-hop Route is being measured (i.e., H = 1), the next hop + is determined using the RPLInstanceID, the End Point Address, and, if + RPLInstanceID is a local value, the Start Point Address fields in the + Measurement Request. If a Source Route is being measured (i.e., + H = 0), the Address[0] element inside the Measurement Request + contains the next-hop address. The Start Point MUST ensure that + + o the next-hop address is a unicast address, and + + o the next hop is on-link, and + + + + + +Goyal, et al. Experimental [Page 13] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o the next hop is in the same RPL routing domain [RFC6554] as the + Start Point, + + failing which the Start Point MUST discard the Measurement Request + without sending. Depending on the routing metrics, the Start Point + must initiate the routing metric objects inside the Metric Container + options by including the routing metric values for the first hop on + the route being measured. Finally, the Start Point MUST unicast the + Measurement Request to the next hop on the route being measured. + + The Start Point MUST maintain state for a just-transmitted + Measurement Request, for a lifetime duration that is large enough to + allow the corresponding Measurement Reply to return. This state + consists of the RPLInstanceID, the SeqNo, and the End Point Address + fields of the Measurement Request. The lifetime duration for this + state is locally determined by the Start Point and may be deployment + specific. This state expires when the corresponding Measurement + Reply is received or when the lifetime is over, whichever occurs + first. Failure to receive the corresponding Measurement Reply before + the expiry of a state may occur due to a number of reasons, including + the unwillingness on the part of an Intermediate Point or the + End Point to process the Measurement Request. The Start Point should + take such possibilities into account when deciding whether to + generate another Measurement Request for this route. The Start Point + MUST discard a received Measurement Reply with no further processing + if the state for the corresponding Measurement Request has already + expired. + +4.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 MO MUST NOT + contain an Address vector, and various MO fields MUST be set in the + following manner: + + o RPLInstanceID: This field MUST be set to the RPLInstanceID of the + route being measured. + + o Compr: This field MUST be set to specify the number of prefix + octets that are elided from the IPv6 addresses in Start Point/ + End Point Address fields. + + o Type (T): This flag MUST be set to one, since the MO represents a + Measurement Request. + + o Hop-by-hop (H): This flag MUST be set to one. + + o Accumulate Route (A): This flag MUST be set to zero. + + + +Goyal, et al. Experimental [Page 14] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Reverse (R): This flag MUST be set to zero. + + o Back Request (B): This flag MAY be set to one to request that the + End Point send a Measurement Request to the Start Point. + + o Intermediate Reply (I): This flag MAY be set to one if the + Start Point expects an Intermediate Point to know the values of + the routing metrics being measured for the remainder of the route. + + o SeqNo: This is assigned by the Start Point so that it can uniquely + identify the Measurement Request and the corresponding + Measurement Reply. + + o Num: This field MUST be set to zero. + + o Index: This field MUST be set to zero. + + o Start Point Address: This field MUST be set to a unicast + global/unique-local IPv6 address of the Start Point after eliding + Compr number of prefix octets. + + o End Point Address: This field MUST be set to a unicast + global/unique-local IPv6 address of the End Point after eliding + Compr number of prefix octets. + +4.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 Start Point does not want the MO to accumulate a Source Route + for the End Point's use, the MO MUST NOT contain the Address vector, + and various MO fields MUST be set in the following manner: + + o RPLInstanceID: This field MUST be set to the RPLInstanceID of the + route being measured. + + o Compr: This field MUST be set to specify the number of prefix + octets that are elided from the IPv6 addresses in Start Point/ + End Point Address fields. + + o Type (T): This flag MUST be set to one, since the MO represents a + Measurement Request. + + o Hop-by-hop (H): This flag MUST be set to one. + + o Accumulate Route (A): This flag MUST be set to zero. + + o Reverse (R): This flag MUST be set to zero. + + + +Goyal, et al. Experimental [Page 15] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Back Request (B): This flag MAY be set to one to request that the + End Point send a Measurement Request to the Start Point. + + o Intermediate Reply (I): This flag MUST be set to zero. + + o SeqNo: This is assigned by the Start Point so that it can uniquely + identify the Measurement Request and the corresponding + Measurement Reply. + + o Num: This field MUST be set to zero. + + o Index: This field MUST be set to zero. + + o Start Point Address: This field MUST contain the DODAGID value + (after eliding Compr number of prefix octets) associated with the + route being measured. This DODAGID MUST also be a global or + unique-local IPv6 address of the Start Point. + + o End Point Address: This field MUST be set to a unicast global or + unique-local 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 a suitably sized Address vector, and various MO fields MUST + be set in the following manner: + + o RPLInstanceID: This field MUST be set to the RPLInstanceID of the + route being measured. + + o Compr: This field 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): This flag MUST be set to one, since the MO represents a + Measurement Request. + + o Hop-by-hop (H): This flag MUST be set to one. + + o Accumulate Route (A): This flag MUST be set to one. + + o Reverse (R): This flag MUST be set to zero. + + + + + +Goyal, et al. Experimental [Page 16] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Back Request (B): This flag MAY be set to one to request that the + End Point send a Measurement Request to the Start Point. + + o Intermediate Reply (I): This flag MUST be set to zero. + + o SeqNo: This is assigned by the Start Point so that it can uniquely + identify the Measurement Request and the corresponding + Measurement Reply. + + o Num: This field MUST specify the number of address elements, each + (16 - Compr) octets in size, that can fit inside the Address + vector. + + o Index: This field MUST be set to zero to indicate the position in + the Address vector where the next hop must store its IPv6 address. + + o Start Point Address: This field MUST contain the DODAGID value + (after eliding Compr number of prefix octets) associated with the + route being measured. This DODAGID MUST also be a global or + unique-local IPv6 address of the Start Point. + + o End Point Address: This field MUST be set to a unicast global or + unique-local IPv6 address of the End Point after eliding Compr + number of prefix octets. + + o Address vector: The Address vector must be large enough to + accommodate a complete Source Route from the End Point to the + Start Point. All the bits in the Address vector field MUST be set + to zero. + +4.4. When Measuring a Source Route + + If a Source Route is being measured, the Start Point MUST set various + MO fields in the following manner: + + o RPLInstanceID: This field does not have any significance when a + Source Route is being measured and hence can be set to any value. + + o Compr: This field 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): This flag MUST be set to one, since the MO represents a + Measurement Request. + + o Hop-by-hop (H): This flag MUST be set to zero. + + o Accumulate Route (A): This flag MUST be set to zero. + + + +Goyal, et al. Experimental [Page 17] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o Reverse (R): This flag SHOULD be set to one if the Source Route in + the Address vector can be reversed and used by the End Point to + send the Measurement Reply message back to the Start Point. + Otherwise, this flag MUST be set to zero. + + o Back Request (B): This flag MAY be set to one to request that the + End Point send a Measurement Request to the Start Point. + + o Intermediate Reply (I): This flag MUST be set to zero. + + o SeqNo: This is assigned by the Start Point so that it can uniquely + identify the Measurement Request and the corresponding + Measurement Reply. + + o Num: This field MUST specify the number of address elements, each + (16 - Compr) octets in size, inside the Address vector. + + o Index: This field MUST be set to zero to indicate the position in + the Address vector of the next hop on the route. + + o Start Point Address: This field MUST be set to a unicast global or + unique-local IPv6 address of the Start Point after eliding Compr + number of prefix octets. + + o End Point Address: This field MUST be set to a unicast global or + unique-local IPv6 address of the End Point after eliding Compr + number of prefix octets. + + o Address vector: + + * The Address vector MUST contain a complete Source Route from + the Start Point to the End Point (excluding the Start Point and + the End Point). + + * Each address appearing in the Address vector MUST be a unicast + global or unique-local IPv6 address. Further, each address + MUST have the same prefix as the Start Point Address and the + End Point Address. This prefix, whose length in octets is + specified in the Compr field, MUST be elided from each address. + + * The IPv6 addresses in the Address vector MUST be reachable in + the Forward direction. + + * If the R flag is set to one, the IPv6 addresses in the Address + vector MUST also be reachable in the Reverse direction. + + + + + + +Goyal, et al. Experimental [Page 18] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +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, in order to meet any policy-related + goals. Such policy goals may include the need to reduce the router's + CPU load, or to enhance its battery life, or to prevent the misuse of + this mechanism by unauthorized nodes. + + A router MUST discard a received MO with no further processing if the + value in the Compr field inside the received message is more than + what the router considers to be the length of the common prefix used + in IPv6 addresses in the LLN. + + On receiving an MO, if a router chooses to process the packet + further, it MUST determine whether or not one of its IPv6 addresses + is listed as either the Start Point or the End Point Address. If + not, the router considers itself an Intermediate Point and MUST + process the received MO in the following manner. + + An Intermediate Point MUST discard the packet with no further + processing if the received MO is not a Measurement Request (i.e., + T = 0). This is because the End Point unicasts a Measurement Reply + directly to the Start Point. So, the Intermediate Point treats a + transiting Measurement Reply as a data packet and not a RPL control + message. + + Next, the Intermediate Point determines the type of the route being + measured (by checking the values of the H flag and the RPLInstanceID + 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. + + 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 (as 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 + + + +Goyal, et al. Experimental [Page 19] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + (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 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 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 [RFC4443] 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 the remaining fields unchanged (the Num field would be + modified in the next steps). Note that the RPLInstanceID field + identifies the non-storing global DAG along which the + Measurement Request traveled so far. This information MUST be + preserved so that the End Point may use this DAG to send the + Measurement Reply back to the Start Point. + + * Insert a new Address vector inside the Measurement Request, and + 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). + + + Each address appearing in the Address vector MUST be a + unicast global or unique-local IPv6 address. Further, each + address MUST have the same prefix as the Start Point Address + and the End Point Address. This prefix, whose length in + octets is specified in the Compr field, MUST be elided from + each address. + + + The IPv6 addresses in the Address vector MUST be reachable + in the Forward direction. + + + +Goyal, et al. Experimental [Page 20] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + If the router cannot insert an Address vector satisfying the + rules mentioned above, 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 [RFC4443] to the Start Point. + + * 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, the + Address[0] element contains the address of the next hop on the + route. + + The Intermediate Point MUST then complete the processing of the + 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, and A = 0), the Intermediate Point MUST process the + received Measurement Request in the following manner. + + 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). If the Intermediate Point cannot 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 [RFC4443] 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 is on (i.e., H = 1, RPLInstanceID has a + local value, and A = 1), the Intermediate Point MUST process the + received Measurement Request in the following manner. + + + +Goyal, et al. Experimental [Page 21] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + 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). If the Intermediate Point cannot 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 [RFC4443] to the + Start Point. If the index field has value Num - 1 and the next hop + is not the 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 router MUST store one of its IPv6 + addresses at location Address[Index] and then increment the Index + field. The IPv6 address added to the Address vector MUST have the + following properties: + + o This address MUST be a unicast global or unique-local address. + + o This address MUST have the same prefix as the Start Point Address + and the End Point Address. This prefix, whose length in octets is + specified in the Compr field, MUST be elided before the address is + added to the Address vector. + + o This address MUST be reachable in the Reverse direction. + + If the router does not have an IPv6 address that satisfies the + properties mentioned above, it MUST discard the Measurement Request + with no further processing. + + 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. + + 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. + + + + +Goyal, et al. Experimental [Page 22] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + The Intermediate Point MUST verify that the Address[Index] element + lists one of its unicast global or unique-local IPv6 addresses (minus + the prefix whose length in octets is specified in the Compr field), + 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 the + 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 + + o if the next hop is not on-link; or + + o if the next hop is not in the same RPL routing domain as the + Intermediate Point. + + Next, the Intermediate Point MUST update the routing metric objects, + inside the Metric Container option(s) inside the Measurement Request, + either by updating the aggregated value for the routing metric or by + attaching the local values for the metric inside the object. An + Intermediate Point can only update the existing metric objects and + MUST NOT add any new routing metric objects to the Metric Container. + An Intermediate Point MUST drop the Measurement Request with no + further processing if it cannot update a routing metric object + specified inside the Metric Container. + + Finally, the Intermediate Point MUST unicast the Measurement Request + to the next hop. + +6. Processing a Measurement Request at the End Point + + On receiving an MO, if a router chooses to process the message + further and finds one of its unicast global or unique-local IPv6 + addresses (minus the prefix whose length in octets is specified in + the Compr field) listed as the End Point Address, the router + considers itself the End Point and MUST process the received MO in + the following manner. + + The End Point MUST discard the received message with no further + processing if it is not a Measurement Request (i.e., T = 0). + + + +Goyal, et al. Experimental [Page 23] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + If the received Measurement Request traveled on a Hop-by-hop Route + with a local RPLInstanceID with route accumulation on (i.e., H = 1, + RPLInstanceID has a local value, and A = 1), elements Address[0] + through Address[Index - 1] in the Address vector contain a complete + Source Route from the Start Point to the End Point, which the + End Point MAY use, after reversal, to reach the Start Point. Note + that the Source Route in the Address vector does not include the + Start Point and the End Point addresses, and that the individual + addresses do not include the common prefix whose length in octets is + specified in the Compr field. + + If the received Measurement Request traveled on a Source Route and + the Reverse flag is set to one (i.e., H = 0 and R = 1), elements + Address[0] through Address[Num - 1] in the Address vector contain a + complete Source Route from the Start Point to the End Point, which + the End Point MAY use, after reversal, to reach the Start Point. + Again, the Source Route in the Address vector does not include the + Start Point and the End Point addresses, and the individual addresses + do not include the common prefix whose length in octets is specified + in the Compr field. + + The End Point MUST update the routing metric objects in the Metric + Container options if required and MAY note the measured values for + the complete route (especially if the received Measurement Request is + likely a response to an earlier Measurement Request that the + End Point had sent to the Start Point with the B flag set to one). + + The End Point MUST generate a Measurement Reply message as specified + in Section 6.1. If the B flag is set to one in the received + Measurement Request, the End Point SHOULD generate a new Measurement + Request to measure the cost of its current (or the most preferred) + route to the Start Point. The routing metrics used in the new + Measurement Request MUST include the routing metrics specified in the + received Measurement Request. + +6.1. Generating the Measurement Reply + + A Measurement Reply MUST have the Type (T) flag set to zero and need + not contain the Address vector. The following fields inside a + Measurement Reply MUST have the same values as they had inside the + corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, + Start Point Address, End Point Address, and Metric Container + option(s). The remaining fields inside a Measurement Reply may have + any value and MUST be ignored on reception at the Start Point; the + received Measurement Request can, therefore, trivially be converted + into a Measurement Reply by setting the Type (T) flag to zero. + + + + + +Goyal, et al. Experimental [Page 24] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + A Measurement Reply MUST be unicast back to the Start Point: + + o If the Measurement Request traveled along a global DAG, identified + by the RPLInstanceID field, the Measurement Reply MAY be unicast + back to the Start Point along the same DAG. + + o If the Measurement Request traveled along a Hop-by-hop Route with + a local RPLInstanceID and accumulated a Source Route from the + Start Point to the End Point, this Source Route MAY be used after + reversal to send the Measurement Reply back to the Start Point. + + o If the Measurement Request traveled along a Source Route and the + R flag inside the received message is set to one, the End Point + MAY 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 the MO to see 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. + + If the Start Point discovers that the received MO is not a + Measurement Reply, or if it no longer maintains state for 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. + +8. Security Considerations + + In general, the security considerations for the route measurement + mechanism described in this document are similar to those for RPL (as + described in Section 19 of the RPL specification [RFC6550]). + Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, + which provides data confidentiality, authentication, replay + protection, and delay protection services. This security framework + is applicable to the route measurement mechanism described here as + well, after taking into account the constraints specified in + Section 3.2. + + + +Goyal, et al. Experimental [Page 25] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + This document requires that all routers participating in a secure + invocation of the route measurement process use the Security + Configuration chosen by the Start Point. The intention is to avoid + compromising the overall security of the route measurement due to + some routers using a weaker Security Configuration. A router is + allowed to participate in a "secure" route measurement only if it can + support the Security Configuration in use, which also specifies the + key in use. It does not matter whether the key is preinstalled or + dynamically acquired after proper authentication. The router must + have the key in use before it can process or generate Secure MO + messages. Hence, from the perspective of the route measurement + mechanism, there is no distinction between the "preinstalled" and + "authenticated" security modes described in the RPL specification + [RFC6550]. Of course, if a compromised router has the key being + used, it could cause the route measurement to fail, or worse, insert + wrong information in Secure MO messages. + + A rogue router acting as the Start Point could use the route + measurement mechanism defined in this document to measure routes from + itself to other routers and thus find out key information about the + LLN, e.g., the topological features of the LLN (such as the identity + of the key routers in the topology) or the remaining energy levels + [RFC6551] in the routers. This information can potentially be used + to attack the LLN. A rogue router could also use this mechanism to + send bogus Measurement Requests to arbitrary End Points. If + sufficient Measurement Requests are sent, then it may cause CPU + overload in the routers in the network, drain their batteries, and + cause traffic congestion in the network. Note that some of these + problems would occur even if the compromised router were to generate + bogus data traffic to arbitrary destinations. + + 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. For example, an + LLN deployment might require the use of Secure MO messages generated + using a key that could be obtained only after proper authentication. + Note that this document requires that an LLN deployment support + Secure MO messages so that such policies can be enforced where + considered essential. + + Since a Measurement Request can travel along a Source Route specified + in the Address vector, some of the security concerns that led to the + deprecation of Type 0 routing headers [RFC5095] may be valid here. + To address such concerns, the mechanism described in this document + includes several remedies, in the form of the following requirements: + + o A route inserted inside the Address vector must be a strict Source + Route and must not include any multicast addresses. + + + +Goyal, et al. Experimental [Page 26] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + + o 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 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. + +9. IANA Considerations + + This document defines two new RPL messages: + + o "Measurement Object" (see Section 3.1), assigned a value of 0x06 + from the "RPL Control Codes" space [RFC6550]. + + o "Secure Measurement Object" (see Section 3.2), assigned a value of + 0x86 from the "RPL Control Codes" space [RFC6550]. + + +------+---------------------------+---------------+ + | Code | Description | Reference | + +------+---------------------------+---------------+ + | 0x06 | Measurement Object | This document | + | 0x86 | Secure Measurement Object | This document | + +------+---------------------------+---------------+ + + RPL Control Codes + +10. Acknowledgements + + The authors gratefully acknowledge the contributions of Ralph Droms, + Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert, + Richard Kelsey, and Zach Shelby in the development of this document. + + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 27] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + Message Protocol (ICMPv6) for the Internet Protocol + Version 6 (IPv6) Specification", RFC 4443, March 2006. + + [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., + Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. + Alexander, "RPL: IPv6 Routing Protocol for Low-Power and + Lossy Networks", RFC 6550, March 2012. + + [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 + Routing Header for Source Routes with the Routing Protocol + for Low-Power and Lossy Networks (RPL)", RFC 6554, + March 2012. + + [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and + J. Martocci, "Reactive Discovery of Point-to-Point Routes + in Low-Power and Lossy Networks", RFC 6997, August 2013. + +11.2. Informative References + + [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation + of Type 0 Routing Headers in IPv6", RFC 5095, + December 2007. + + [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation + Routing Requirements in Low-Power and Lossy Networks", + RFC 5826, April 2010. + + [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, + "Building Automation Routing Requirements in Low-Power and + Lossy Networks", RFC 5867, June 2010. + + [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. + Barthel, "Routing Metrics Used for Path Calculation in + Low-Power and Lossy Networks", RFC 6551, March 2012. + + [ROLL-TERMS] + Vasseur, JP., "Terminology in Low power And Lossy + Networks", Work in Progress, March 2013. + + + + + +Goyal, et al. Experimental [Page 28] + +RFC 6998 Measurement of Routing Metrics in LLNs August 2013 + + +Authors' Addresses + + Mukul Goyal (editor) + University of Wisconsin Milwaukee + 3200 N. Cramer St. + Milwaukee, WI 53201 + USA + + Phone: +1-414-229-5001 + EMail: mukul@uwm.edu + + + Emmanuel Baccelli + INRIA + + Phone: +33-169-335-511 + EMail: Emmanuel.Baccelli@inria.fr + URI: http://www.emmanuelbaccelli.org/ + + + Anders Brandt + Sigma Designs + Emdrupvej 26A, 1. + Copenhagen, Dk-2100 + Denmark + + Phone: +45-29609501 + EMail: abr@sdesigns.dk + + + Jerald Martocci + Johnson Controls + 507 E. Michigan Street + Milwaukee, WI 53202 + USA + + Phone: +1-414-524-4010 + EMail: jerald.p.martocci@jci.com + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 29] + -- cgit v1.2.3