6MAN J. Hui Internet-Draft Arch Rock Corporation Intended status: Standards Track JP. Vasseur Expires: April 26, 2011 Cisco Systems, Inc October 23, 2010 RPL Option for Carrying RPL Information in Data-Plane Datagrams draft-ietf-6man-rpl-option-01 Abstract The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. 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 April 26, 2011. Copyright Notice Copyright (c) 2010 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 April 26, 2011 [Page 1] Internet-Draft RPL Option October 2010 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. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 8 6. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 9 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Hui & Vasseur Expires April 26, 2011 [Page 2] Internet-Draft RPL Option October 2010 1. Introduction RPL is a distance vector IPv6 routing protocol designed for low power and lossy networks [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 approach 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. Such a dynamic rate of control packets operation is governed by the use of dynamic timers also referred to as "trickle" timers and defined in [I-D.ietf-roll-trickle]. By contrast with other routing protocols such as OSPF ([RFC2328]), RPL detects routing inconsistencies using data-path verification, by including routing information within the datagram itself. Data-path verification quickly detects and resolves inconsistencies when routes are needed by the data flow 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 Low power and Lossy Networks (LLNs) is that control plane traffic should be carefully bounded with respect to the data traffic: there is no need to solve a 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 proposes a new IPv6 option called the RPL Option to be carried within the IPv6 Hop-by-Hop header. The RPL Option is for use only within a RPL domain. 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 RFC 2119 [RFC2119]. Hui & Vasseur Expires April 26, 2011 [Page 3] Internet-Draft RPL Option October 2010 2. Overview Datagrams being forwarded within a RPL domain MUST include a RPL Option. For datagrams sourced within a RPL domain, the RPL Option MAY be included in the datagram itself. For datagrams sourced outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in [RFC2473] MUST be used to include a RPL Option. When forwarding the datagram, the router MUST prepend a new IPv6 header and IPv6 Hop-by- Hop Options header containing the RPL Option to the existing datagram. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the RPL Option source rather than the source of the original datagram. To help avoid IP-layer fragmentation, the RPL Option has a maximum size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional extension headers or options needed within RPL domain). Hui & Vasseur Expires April 26, 2011 [Page 4] Internet-Draft RPL Option October 2010 3. Format of the RPL Option The RPL option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. The RPL 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 Opt Data Len: Down 'O': 1-bit flag indicating whether the packet is expected to progress Up or Down. A router sets the 'O' flag when the packet is expected to progress Down (using DAO routes), and clears it when forwarding toward the DODAG root (to a node with a lower rank). A host or RPL leaf node MUST set the 'O' flag to 0. Rank-Error 'R': 1-bit flag indicating whether a rank error was detected. A rank error is detected when there is a mismatch in the relative ranks and the direction as indicated in the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to 0. Forwarding-Error 'F': 1-bit flag indicating that this node can not forward the packet further towards the destination. The 'F' bit might be set by a child node that does not have a route to destination for a packet with the Down 'O' bit set. A host or RPL leaf node MUST set the 'F' bit to 0. RPLInstanceID: 8-bit field indicating the DODAG instance along which the packet is sent. SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network. Values within the RPL option are expected to change en-route. Nodes that do not understand the RPL option MUST discard the packet. Thus, Hui & Vasseur Expires April 26, 2011 [Page 5] Internet-Draft RPL Option October 2010 according to [RFC2460] the two high order bits of the Option Type must be equal set to '01' and the third bit is equal to '1'. The 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 TLVs are currently defined. Hui & Vasseur Expires April 26, 2011 [Page 6] Internet-Draft RPL Option October 2010 4. RPL Router Behavior Routers MUST include a RPL Option when forwarding datagrams that do not already contain a RPL Option. If one does not already exist, routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a RPL Option in datagrams that are sourced by other nodes. This ensures that the original datagram is delivered unmodified. Performing IP-in-IP encapsulation may grow the datagram to a size larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer fragmentation caused by IP-in-IP encapsulation, links within a RPL domain SHOULD be configured with a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional extension headers or options needed within RPL domain). Hui & Vasseur Expires April 26, 2011 [Page 7] Internet-Draft RPL Option October 2010 5. RPL Border Router Behavior RPL Border Routers (referred to as LBRs in [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL Option is only used within a RPL domain. For datagrams entering the RPL domain, RPL Border Routers MUST drop received datagrams that contain a RPL Option in the IPv6 Extension headers. For datagrams exiting the RPL domain, RPL Border Routers MUST remove the RPL Option from the datagram and update the IPv6 Payload Length field accordingly. Hui & Vasseur Expires April 26, 2011 [Page 8] Internet-Draft RPL Option October 2010 6. Usage of the RPL Option The RPL option is only for use within a RPL domain. RPL routers MUST process and include the RPL option when forwarding datagrams to other nodes within the RPL domain. Routers on the edge of a RPL domain MUST remove the RPL option when forwarding datagrams to nodes outside the RPL domain. Hui & Vasseur Expires April 26, 2011 [Page 9] Internet-Draft RPL Option October 2010 7. Protocol Constants RPL_OPTION_MAX_SIZE 128 Hui & Vasseur Expires April 26, 2011 [Page 10] Internet-Draft RPL Option October 2010 8. Acknowledgements The authors thank Richard Kelsey, Vishwas Manral, Erik Nordmark, Pascal Thubert, and Tim Winter, for their comments and suggestions that helped shape this document. Hui & Vasseur Expires April 26, 2011 [Page 11] Internet-Draft RPL Option October 2010 9. IANA Considerations The RPL option requires an IPv6 Option Number. HEX act chg rest --- --- --- ----- 1 01 1 01011 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. This document also creates a new IANA registry for the sub-TLVs. No sub-TLVs are defined in this specification. The policy for this registry [RFC5226] is IETF Review. Hui & Vasseur Expires April 26, 2011 [Page 12] Internet-Draft RPL Option October 2010 10. Security Considerations This option may be used a several potential attacks since routers may be flooded by bogus datagram containing the RPL option. It is thus RECOMMENDED for routers to implement a rate limiter for datagrams using the RPL option. Hui & Vasseur Expires April 26, 2011 [Page 13] Internet-Draft RPL Option October 2010 11. Changes (This section to be removed by the RFC editor.) Draft 01: - Specify that a node must discard the packet if it doesn't recognize the RPL option. - Include RPL loop detection bits in the base header such that an IPv6 Hop-by-Hop Option header with the minimal RPL option consumes only 8 octets. Hui & Vasseur Expires April 26, 2011 [Page 14] Internet-Draft RPL Option October 2010 12. References 12.1. Normative References [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Networks, D., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-13 (work in progress), October 2010. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 12.2. Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. Hui & Vasseur Expires April 26, 2011 [Page 15] Internet-Draft RPL Option October 2010 Authors' Addresses Jonathan W. Hui Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, California 94107 USA Phone: +415 692 0828 Email: jhui@archrock.com JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Hui & Vasseur Expires April 26, 2011 [Page 16]