idnits 2.17.1 draft-ietf-6man-rpl-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 249 has weird spacing: '... act chg ...' -- The document date (February 8, 2011) is 4819 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) == Missing Reference: 'RFCthis' is mentioned on line 251, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-18 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN J. Hui 3 Internet-Draft Arch Rock Corporation 4 Intended status: Standards Track JP. Vasseur 5 Expires: August 12, 2011 Cisco Systems, Inc 6 February 8, 2011 8 RPL Option for Carrying RPL Information in Data-Plane Datagrams 9 draft-ietf-6man-rpl-option-02 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 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). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 12, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5 56 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 6 57 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 7 58 6. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 8 59 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 9 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 65 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 process 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. This dynamic 85 rate control operation is governed by the use of dynamic timers also 86 referred to as "Trickle" timers and defined in 87 [I-D.ietf-roll-trickle]. In contrast to other routing protocols (e.g 88 OSPF [RFC2328]), RPL detects routing inconsistencies using data-path 89 verification, by including routing information within the datagram 90 itself. In doing so, repair mechanisms operate only as needed, 91 allowing the control and data planes to operate on similar time 92 scales. The main motivation for data path verification in Low power 93 and Lossy Networks (LLNs) is that control plane traffic should be 94 carefully bounded with respect to the data traffic. Intuitively, 95 there is no need to solve routing issues (which may be temporary) in 96 the absence of data traffic. 98 The RPL protocol constructs a Directed Acyclic Graph (DAG) that 99 attempts to minimize path costs to the DAG root according to a set of 100 metric and objective functions. There are circumstances where loops 101 may occur, and RPL is designed to use a data-path loop detection 102 method. This is one of the known requirements of RPL and other data- 103 path usage might be defined in the future. 105 To that end, this document proposes a new IPv6 option, called the RPL 106 Option, to be carried within the IPv6 Hop-by-Hop header. The RPL 107 Option is only for use within a RPL domain. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Overview 117 Datagrams being forwarded within a RPL domain MUST include a RPL 118 Option. For datagrams sourced within a RPL domain, the RPL Option 119 MAY be included in the datagram itself. For datagrams sourced 120 outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in 121 [RFC2473] SHOULD be used to include a RPL Option. When tunneling, 122 the router MUST prepend a new IPv6 header and IPv6 Hop-by-Hop Options 123 header containing the RPL Option to the existing datagram. Use of 124 tunneling ensures that the datagram is delivered unmodified and that 125 ICMP errors return to the RPL Option source rather than the source of 126 the original datagram. 128 To help avoid IP-layer fragmentation, the RPL Option has a maximum 129 size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain 130 SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop 131 Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional 132 extension headers or options needed within RPL domain). 134 3. Format of the RPL Option 136 The RPL Option is carried in an IPv6 Hop-by-Hop Options header, 137 immediately following the IPv6 header. This option has an alignment 138 requirement of 2n. The option has the following format: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Option Type | Opt Data Len | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | (sub-TLVs) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: RPL Option 152 Option Type: TBD 154 Opt Data Len: 8-bit field indicating the length of the option, in 155 octets, excluding the Option Type and Opt Data Len fields. 157 Down 'O': 1-bit flag as defined in Section 11 of 158 [I-D.ietf-roll-rpl]. 160 Rank-Error 'R': 1-bit flag as defined in Section 11 of 161 [I-D.ietf-roll-rpl]. 163 Forwarding-Error 'F': 1-bit flag as defined in Section 11 of 164 [I-D.ietf-roll-rpl]. 166 RPLInstanceID: 8-bit field as defined in Section 11 of 167 [I-D.ietf-roll-rpl]. 169 SenderRank: 16-bit field as defined in Section 11 of 170 [I-D.ietf-roll-rpl]. 172 Values within the RPL Option are expected to change en-route. Nodes 173 that do not understand the RPL Option MUST discard the packet. Thus, 174 according to [RFC2460] the two high order bits of the Option Type 175 must be equal set to '01' and the third bit is equal to '1'. The RPL 176 Option Data Length is variable. 178 The action taken by using the RPL Option and the potential set of 179 sub-TLVs carried within the RPL Option MUST be specified by the RFC 180 of the protocol that use that option. No TLVs are defined in this 181 document. 183 4. RPL Router Behavior 185 RPL controls when and what information is to be placed in a packet. 186 If RPL requires a router to include a RPL Option where one does not 187 already exist, routers SHOULD use IPv6-in-IPv6 tunneling, as 188 specified in [RFC2473] to include a RPL Option in datagrams that are 189 sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures that 190 the original datagram is delivered unmodified. 192 Performing IP-in-IP encapsulation may grow the datagram to a size 193 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 194 fragmentation caused by IP-in-IP encapsulation, links within a RPL 195 domain SHOULD be configured with a MTU of at least 1280 + 44 (outer 196 IP header, Hop-by-Hop Option header, Option header) + 197 RPL_OPTION_MAX_SIZE + (additional extension headers or options needed 198 within RPL domain). 200 In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due 201 to the added cost and complexity required to process and carry a 202 datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes 203 how to avoid using IPv6-in-IPv6 tunneling in such specific cases and 204 the risks involved. 206 5. RPL Border Router Behavior 208 RPL Border Routers (referred to as LBRs in 209 [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL 210 Option is only used within a RPL domain. 212 For datagrams entering the RPL domain, RPL Border Routers MUST drop 213 received datagrams that contain a RPL Option in the IPv6 Extension 214 headers. 216 For datagrams exiting the RPL domain, RPL Border Routers MUST remove 217 the RPL Option from the datagram. If the RPL Option was included 218 using tunneled mode and the RPL Border Router serves as the tunnel 219 end-point, removing the outer IPv6 header serves to remove the RPL 220 Option as well. Otherwise, the RPL Border Router assumes that the 221 RPL Option was included using transport mode and MUST remove the RPL 222 Option from the IPv6 Hop-by-Hop Option header. 224 6. Usage of the RPL Option 226 The RPL Option is only for use within a RPL domain. RPL routers MUST 227 process and include the RPL Option when forwarding datagrams to other 228 nodes within the RPL domain. Routers on the edge of a RPL domain 229 MUST remove the RPL Option when forwarding datagrams to nodes outside 230 the RPL domain. 232 7. Protocol Constants 234 RPL_OPTION_MAX_SIZE 128 236 8. Acknowledgements 238 The authors thank Richard Kelsey, Suresh Krishnan, Vishwas Manral, 239 Erik Nordmark, Pascal Thubert, and Tim Winter, for their comments and 240 suggestions that helped shape this document. 242 9. IANA Considerations 244 IANA is requested to reserve a new value in the Destination Options 245 and Hop-by-Hop Options registry. The proposed value to be confirmed 246 by IANA is: 248 Hex Value Binary Value 249 act chg rest Description Reference 250 --------- --- --- ------- ----------------- ---------- 251 0x6b 01 1 01011 RPL Option [RFCthis] 253 As specified in [RFC2460], the first two bits indicate that the IPv6 254 node MUST discard the packet if it doesn't recognize the option type, 255 and the third bit indicates that the Option Data may change en-route. 256 The remaining bits serve to as the option type are are '01011' (to be 257 confirmed by IANA). 259 IANA is requested to create a registry called RPL-option-TLV, for the 260 TLVs carried in the RPL Option header. New codes may be allocated 261 only by IETF Review [RFC5226]. The type field is an 8-bit field 262 whose value be between 0 and 255, inclusive. 264 10. Security Considerations 266 This option may be used a several potential attacks since routers may 267 be flooded by bogus datagram containing the RPL option. It is thus 268 RECOMMENDED for routers to implement a rate limiter for datagrams 269 using the RPL Option. 271 11. References 273 11.1. Normative References 275 [I-D.ietf-roll-rpl] 276 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 277 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 278 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 279 Lossy Networks", draft-ietf-roll-rpl-18 (work in 280 progress), February 2011. 282 [I-D.ietf-roll-trickle] 283 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 284 "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work 285 in progress), January 2011. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 292 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 293 (IPv6) Specification", RFC 2460, December 1998. 295 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 296 IPv6 Specification", RFC 2473, December 1998. 298 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 299 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 300 May 2008. 302 11.2. Informative References 304 [I-D.hui-6man-rpl-headers] 305 Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers 306 Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in 307 progress), July 2010. 309 [I-D.ietf-roll-terminology] 310 Vasseur, J., "Terminology in Low power And Lossy 311 Networks", draft-ietf-roll-terminology-04 (work in 312 progress), September 2010. 314 Authors' Addresses 316 Jonathan W. Hui 317 Arch Rock Corporation 318 501 2nd St. Ste. 410 319 San Francisco, California 94107 320 USA 322 Phone: +415 692 0828 323 Email: jhui@archrock.com 325 JP Vasseur 326 Cisco Systems, Inc 327 11, Rue Camille Desmoulins 328 Issy Les Moulineaux, 92782 329 France 331 Email: jpv@cisco.com