I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies an IPv6 option for use in attaching RPL routing information to data packets within an RPL network. Initially (I believe) the information included in the option is for use only in loop avoidance and detection, but the syntax of the option is extensible and allows for arbitrary TLVs, for inclusion in RPL option, to be specified in a later document. There is no integrity protection for this option and so there exists a potential attack where a malicious party fabricates data packets with "bogus" information in the RPL option and sends them to an RPL router. The security considerations in this document describe such an attack and suggest a countermeasure. I believe that the principal secure concern (regarding an attack where a malicious party falsifies data in the RPL option) is that setting the 'O' bit and the 'Rank' field improperly can cause an RPL router to detect a "Rank Error" that does not exist. My understanding of RPL is that when a "Rank Error" is detected that the router resets its "DIO Trickle Timer" [see Note below]. The document suggests a potential counter-measure to such an attack where a router limits the rate at which it is willing to reset its DIO Trickle Timer in response to RPL option receipt to be less than some constant number of resets per hour. (This rate is a parameter of the system and the document suggests 20 as a reasonable parameter value). Personally, I believe that the counter-measure suggested is appropriate given the lack of integrity protection for the RPL option. However, I don't understand Trickle well enough to know what the ramifications would be (i.e., what an adversary would accomplish) by causing a router to reset its DIO Trickle Timer too often. (I assume that this generates some combination of churn in routing state and/or flood of additional RPL control traffic, which the adversary would use to effect a denial of service attack on the network.) Note: With regard to document clarity, it was somewhat difficult for me as reader to track down what happens when the Rank field in the RPL option is set improperly. In particular, the RPL option document refers to Section 11.2 in the RPL specification for information on the semantics of the data fields in the RPL option. Section 11.2 of the RPL specification describes (in particular) the Rank and 'O'-bits and indicates the circumstances in which a "rank inconsistency" occurs. However, Section 11.2 of the RPL specification does not specifically indicate what an RPL router does when such a rank inconsistency occurs. (That information is found in Section 8.3 of the RPL specification) Therefore, I would find it helpful to have in the security considerations section a reference to Section 8.3 of the RPL specification. Additionally, I find the use of the word "triggers" to be confusing in the Security Considerations section. (I believe the authors are using the word "triggers" to refer to triggering a reset of the DIO Trickle Timer, but that was not clear to me when I first read the document.)