idnits 2.17.1 draft-hui-6man-rpl-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '... act chg ...' -- The document date (March 1, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-06 ** Downref: Normative reference to an Informational draft: draft-levis-roll-trickle (ref. 'I-D.levis-roll-trickle') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group J. Hui 3 Internet-Draft Arch Rock Corporation 4 Intended status: Standards Track JP. Vasseur 5 Expires: September 2, 2010 Cisco Systems, Inc 6 March 1, 2010 8 RPL Option for Carrying RPL Information in Data-Plane Datagrams 9 draft-hui-6man-rpl-option-00 11 Abstract 13 The RPL protocol requires data-plane datagrams to carry RPL routing 14 information that is processed by RPL routers when forwarding those 15 datagrams. This document describes the RPL option for use within a 16 RPL domain. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 2, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 60 2. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 4 61 3. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . . 4 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 RPL is a distance vector IPv6 routing protocol designed for low power 71 and lossy networks [I-D.ietf-roll-rpl]. Such networks are typically 72 constrained in energy and/or channel capacity. To conserve precious 73 resources, a routing protocol must generate control traffic 74 sparingly. However, this is at odds with the need to quickly 75 propagate any new routing information to resolve routing 76 inconsistencies quickly. 78 To help minimize resource consumption, RPL uses a slow proactive 79 process to construct and maintain a routing topology but a reactive 80 and dynamic approach to resolving routing inconsistencies. In the 81 steady state, RPL maintains the routing topology using a low-rate 82 beaconing process. However, when RPL detects inconsistencies that 83 may prevent proper datagram delivery, RPL temporarily increases the 84 beacon rate to quickly resolve those inconsistencies. Such a dynamic 85 rate of control packets operation is governed by the use of dynamic 86 timers also referred to as "trickle" timers and defined in 87 [I-D.levis-roll-trickle]. By contrast with other routing protocols 88 such as OSPF ([RFC2328]), RPL detects routing inconsistencies using 89 data-path verification, by including routing information within the 90 datagram itself. Data-path verification quickly detects and resolves 91 inconsistencies when routes are needed by the data flow itself. In 92 doing so, repair mechanisms operate only as needed, allowing the 93 control and data planes to operate on similar time scales. The main 94 motivation for data path verification in Low power and Lossy Networks 95 (LLNs) is that control plane traffic should be carefully bounded with 96 respect to the data traffic: there is no need to solve a routing 97 issues (which may be temporary) in the absence of data traffic. 99 The RPL protocol constructs a DAG that attempts to minimize path 100 costs to the DAG root according to a set of metric and objective 101 functions. There are circumstances where loops may occur, and RPL is 102 designed to use a data-path loop detection method. This is one of 103 the known requirements of RPL and other data-path usage might be 104 defined in the future. 106 To that end, this document proposes a new IPv6 option called the RPL 107 Option to be carried within the IPv6 Hop-by-Hop header. The RPL 108 Option is for use only within a RPL domain. Routers on the edge of 109 the domain MAY insert the RPL Option into datagrams entering the RPL 110 domain but MUST remove the RPL Option from datagrams exiting the RPL 111 domains, if one exists. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Format of the RPL Option 121 The RPL option is carried in an IPv6 Hop-by-Hop Options header, 122 immediately following the IPv6 header. The RPL option has the 123 following format: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Option Type | Opt Data Len | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | (sub-TLVs) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 1: RPL Option 135 The Option Data of the RPL option is expected to change en-route. 136 Nodes that do not understand the RPL option MUST skip over this 137 option and continue processing the header. Thus, according to 138 [RFC2460] the two high order bits of the Option Type must be equal 139 set to zero and the third bit is equal to 1. The RPL Option Data 140 Length is variable. 142 The action taken by using the RPL Option and the potential set of 143 sub-TLVs carried within the RPL Option MUST be specified by the RFC 144 of the protocol that use that option. No TLVs are currently defined. 146 3. Usage of the RPL Option 148 The RPL option is only for use within a RPL domain. RPL routers MUST 149 process and include the RPL option when forwarding datagrams to other 150 nodes within the RPL domain. Routers on the edge of a RPL domain 151 MUST remove the RPL option when forwarding datagrams to nodes outside 152 the RPL domain. The final destination of the datagram MAY ignore the 153 RPL option. 155 4. Acknowledgements 157 TODO. 159 5. IANA Considerations 161 The RPL option requires an IPv6 Option Number. 163 HEX act chg rest 164 --- --- --- ----- 165 1 00 1 01011 167 The first two bits indicate that the IPv6 node may skip over this 168 option and continue processing the header if it doesn't recognize the 169 option type, and the third bit indicates that the Option Data may 170 change en-route. 172 6. Security Considerations 174 This option may be used a several potential attacks since routers may 175 be flooded by bogus datagram containing the RPL option. It is thus 176 RECOMMENDED for routers to implement a rate limiter for datagrams 177 using the RPL option. 179 7. Normative References 181 [I-D.ietf-roll-rpl] 182 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 183 Protocol for Low power and Lossy Networks", 184 draft-ietf-roll-rpl-06 (work in progress), February 2010. 186 [I-D.levis-roll-trickle] 187 Levis, P. and T. Clausen, "The Trickle Algorithm", 188 draft-levis-roll-trickle-00 (work in progress), 189 February 2010. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 196 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 197 (IPv6) Specification", RFC 2460, December 1998. 199 Authors' Addresses 201 Jonathan W. Hui 202 Arch Rock Corporation 203 501 2nd St. Ste. 410 204 San Francisco, California 94107 205 USA 207 Phone: +415 692 0828 208 Email: jhui@archrock.com 210 JP Vasseur 211 Cisco Systems, Inc 212 11, Rue Camille Desmoulins 213 Issy Les Moulineaux, 92782 214 France 216 Email: jpv@cisco.com