RPL Option for Carrying RPL Information in Data-Plane Datagrams
Author(s): JP Vasseur, Jonathan Hui
The RPL protocol includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information....
6MAN J. Hui Internet-Draft JP. Vasseur Intended status: Standards Track Cisco Systems, Inc Expires: June 16, 2012 December 14, 2011 RPL Option for Carrying RPL Information in Data-Plane Datagrams draft-ietf-6man-rpl-option-06 Abstract The RPL protocol includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 16, 2012. Copyright Notice Copyright (c) 2011 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. Hui & Vasseur Expires June 16, 2012 [Page 1] Internet-Draft RPL Option December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. DAG Inconsistency Attacks . . . . . . . . . . . . . . . . 9 5.2. DAO Inconsistency Attacks . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Hui & Vasseur Expires June 16, 2012 [Page 2] Internet-Draft RPL Option December 2011 1. Introduction RPL is a distance vector IPv6 routing protocol designed for Low power and Lossy Networks (LLNs) [I-D.ietf-roll-rpl]. Such networks are typically constrained in energy and/or channel capacity. To conserve precious resources, a routing protocol must generate control traffic sparingly. However, this is at odds with the need to quickly propagate any new routing information to resolve routing inconsistencies quickly. To help minimize resource consumption, RPL uses a slow proactive process to construct and maintain a routing topology but a reactive and dynamic process to resolving routing inconsistencies. In the steady state, RPL maintains the routing topology using a low-rate beaconing process. However, when RPL detects inconsistencies that may prevent proper datagram delivery, RPL temporarily increases the beacon rate to quickly resolve those inconsistencies. This dynamic rate control operation is governed by the use of dynamic timers also referred to as "Trickle" timers and defined in [RFC6206]. In contrast to other routing protocols (e.g OSPF [RFC2328]), RPL detects routing inconsistencies using data-path verification, by including routing information within the datagram itself. In doing so, repair mechanisms operate only as needed, allowing the control and data planes to operate on similar time scales. The main motivation for data path verification in LLNs is that control plane traffic should be carefully bounded with respect to the data traffic. Intuitively, there is no need to solve routing issues (which may be temporary) in the absence of data traffic. The RPL protocol constructs a Directed Acyclic Graph (DAG) that attempts to minimize path costs to the DAG root according to a set of metric and objective functions. There are circumstances where loops may occur, and RPL is designed to use a data-path loop detection method. This is one of the known requirements of RPL and other data- path usage might be defined in the future. To that end, this document defines a new IPv6 option, called the RPL Option, to be carried within the IPv6 Hop-by-Hop header. The RPL Option is only for use between RPL routers participating in the same RPL Instance. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Hui & Vasseur Expires June 16, 2012 [Page 3] Internet-Draft RPL Option December 2011 2. Overview The RPL Option provides a mechanism to include routing information with each datagram that a router forwards. When receiving datagrams that include routing information, RPL routers process the routing information to help maintain the routing topology. Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. This draft also specifies the use of IPv6- in-IPv6 tunneling [RFC2473] when attaching a RPL option to a packet. Use of tunneling ensures that the original packet remains unmodified and that ICMP errors return to the RPL Option source rather than the source of the original packet. Hui & Vasseur Expires June 16, 2012 [Page 4] Internet-Draft RPL Option December 2011 3. Format of the RPL Option The RPL Option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. This option has an alignment requirement of 2n. The option has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RPL Option Option Type: TBD by IANA. Opt Data Len: 8-bit field indicating the length of the option, in octets, excluding the Option Type and Opt Data Len fields. Down 'O': 1-bit flag as defined in Section 11.2 of [I-D.ietf-roll-rpl]. The processing SHALL follow the rules described in Section 11.2 of [I-D.ietf-roll-rpl]. Rank-Error 'R': 1-bit flag as defined in Section 11.2 of [I-D.ietf-roll-rpl]. The processing SHALL follow the rules described in Section 11.2 of [I-D.ietf-roll-rpl]. Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of [I-D.ietf-roll-rpl]. The processing SHALL follow the rules described in Section 11.2 of [I-D.ietf-roll-rpl]. RPLInstanceID: 8-bit field as defined in Section 11.2 of [I-D.ietf-roll-rpl]. The processing SHALL follow the rules described in Section 11.2 of [I-D.ietf-roll-rpl]. SenderRank: 16-bit field as defined in Section 11.2 of [I-D.ietf-roll-rpl]. The processing SHALL follow the rules described in Section 11.2 of [I-D.ietf-roll-rpl]. The two high order bits of the Option Type MUST be set to '01' and the third bit is equal to '1'. With these bits, according to [RFC2460], nodes that do not understand this option on a received packet MUST discard the packet. Also, according to [RFC2460], the values within the RPL Option are expected to change en-route. The Hui & Vasseur Expires June 16, 2012 [Page 5] Internet-Draft RPL Option December 2011 RPL Option Data Length is variable. The action taken by using the RPL Option and the potential set of sub-TLVs carried within the RPL Option MUST be specified by the RFC of the protocol that use that option. No sub-TLVs are defined in this document. A RPL device MUST skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after. Hui & Vasseur Expires June 16, 2012 [Page 6] Internet-Draft RPL Option December 2011 4. RPL Router Behavior Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY include both. A datagram including a SRH does not need to include a RPL Option since both the source and intermediate routers ensure that the SRH does not contain loops. When the router is the source of the original packet and the destination is known to be within the same RPL Instance, the router SHOULD include the RPL Option directly within the original packet. Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL Option in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by a RPL Option are sent back to the router that generated the RPL Option. A RPL router chooses the next RPL router that should process the original packet as the tunnel exit-point. In some cases, the tunnel exit-point will be the final RPL router along a path towards the original packet's destination and the original packet will only traverse a single tunnel. One example is when the final destination or the destination's attachment router is known to be within the same RPL Instance. In other cases, the tunnel exit-point will not be the final RPL router along a path and the original packet may traverse multiple tunnels to reach the destination. One example is when a RPL router is simply forwarding a packet to one of its DODAG Parents. In this case, the RPL router sets the tunnel exit-point to a DODAG Parent. When forwarding the original packet hop-by-hop, the RPL router only makes a determination on the next hop towards the destination. A RPL router receiving an IPv6-in-IPv6 packet destined to it processes the tunnel packet as described in Section 3 of [RFC2473]. Before IPv6 decapsulation, the RPL router MUST process the RPL Option if one exists. After IPv6 decapsulation, if the router determines that it should forward the original packet to another RPL router it MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to include the RPL Option. Fields within the RPL Option that do not change hop-by-hop MUST remain the same as those received from the prior tunnel. RPL routers are responsible for ensuring that a RPL Option is only used between RPL routers: 1. For datagrams destined to a RPL router, the router processes the packet in the usual way. For instance, if the RPL Option was Hui & Vasseur Expires June 16, 2012 [Page 7] Internet-Draft RPL Option December 2011 included using tunneled mode and the RPL router serves as the tunnel endpoint, the router removes the outer IPv6 header, at the same time removing the RPL Option as well. 2. Datagrams destined elsewhere within the same RPL Instance are forwarded to the correct interface. 3. Datagrams destined to nodes outside the RPL Instance are dropped if the outer-most IPv6 header contains a RPL Option not generated by the RPL router forwarding the datagram. To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e. at least 1280 + 40 (outer IP header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the maximum RPL Option header size for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e. through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g. 1280 octets on 6LoWPAN links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited. Hui & Vasseur Expires June 16, 2012 [Page 8] Internet-Draft RPL Option December 2011 5. Security Considerations The RPL Option assists RPL routers in detecting routing inconsistencies. The RPL message security mechanisms defined in [I-D.ietf-roll-rpl] do not apply to the RPL Option. 5.1. DAG Inconsistency Attacks Using the Down 'O' flag and SenderRank field, an attacker can cause RPL routers to believe that a DAG inconsistency exists within the RPL instance identified by the RPLInstanceID field. This attack would cause a RPL router to reset its DIO Trickle timer and begin transmitting DIO messages more frequently. In order to avoid any unacceptable impact on network operations, an implementation MAY limit the number of triggers caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20. 5.2. DAO Inconsistency Attacks In storing mode, RPL routers maintain downward routing state. Under normal operation, the RPL Option assists RPL routers in cleaning up stale downward routing state by using the Forwarding-Error 'F' flag to indicate that a datagram could not be delivered by a child and is being sent back to try a different child. Using this flag, an attacker can cause a RPL router to discard downward routing state. In order to avoid any unacceptable impact on network operations, an implementation MAY limit the number of triggers caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_FORWARD_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_FORWARD_ERRORS is 20. In non-storing mode, only the LBR maintains downward routing state. Because RPL routers do not maintain downward routing state, the RPL Option cannot be used to mount such attacks. Hui & Vasseur Expires June 16, 2012 [Page 9] Internet-Draft RPL Option December 2011 6. IANA Considerations IANA is requested to reserve a new value in the Destination Options and Hop-by-Hop Options registry. The proposed value to be confirmed by IANA is: Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- TBD 01 1 TBD RPL Option [RFCthis] As specified in [RFC2460], the first two bits indicate that the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en-route. The remaining bits serve as the option type and are TBD by IANA. IANA is requested to create a registry called RPL-option-TLV, for the sub-TLVs carried in the RPL Option header. New codes may be allocated only by IETF Review [RFC5226]. The type field is an 8-bit field whose value be between 0 and 255, inclusive. Hui & Vasseur Expires June 16, 2012 [Page 10] Internet-Draft RPL Option December 2011 7. Acknowledgements The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their comments and suggestions that helped shape this document. Hui & Vasseur Expires June 16, 2012 [Page 11] Internet-Draft RPL Option December 2011 8. Changes (This section to be removed by the RFC editor.) Draft 06: - Address IESG comments. Draft 05: - Address LC comments. Draft 04: - Clarify when the RPL Option is used. - Updated text on recommendations for avoiding fragmentation. - Specify skip-over-and-continue policy for unrecognized sub-TLVs. - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. - Specify RPL Border Router operations in terms of forwarding decision outcomes. - Expand security section. Draft 03: - Removed any presumed values that are TBD by IANA. Hui & Vasseur Expires June 16, 2012 [Page 12] Internet-Draft RPL Option December 2011 9. References 9.1. Normative References [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC2328, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC2473, December 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC5226, May 2008. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC6206, March 2011. 9.2. Informative References [I-D.ietf-6man-rpl-routing-header] Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with RPL", draft-ietf-6man-rpl-routing-header-05 (work in progress), November 2011. Hui & Vasseur Expires June 16, 2012 [Page 13] Internet-Draft RPL Option December 2011 Authors' Addresses Jonathan W. Hui Cisco Systems, Inc 170 West Tasman Drive San Jose, California 95134 USA Phone: +408 424 1547 Email: email@example.com JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: firstname.lastname@example.org Hui & Vasseur Expires June 16, 2012 [Page 14]