idnits 2.17.1 draft-ietf-6man-rpl-option-06.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 301 has weird spacing: '... act chg ...' -- The document date (December 14, 2011) is 4517 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 303, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-6man-rpl-routing-header-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN J. Hui 3 Internet-Draft JP. Vasseur 4 Intended status: Standards Track Cisco Systems, Inc 5 Expires: June 16, 2012 December 14, 2011 7 RPL Option for Carrying RPL Information in Data-Plane Datagrams 8 draft-ietf-6man-rpl-option-06 10 Abstract 12 The RPL protocol includes routing information in data-plane datagrams 13 to quickly identify inconsistencies in the routing topology. This 14 document describes the RPL Option for use among RPL routers to 15 include such routing information. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 16, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5 55 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 5.1. DAG Inconsistency Attacks . . . . . . . . . . . . . . . . 9 58 5.2. DAO Inconsistency Attacks . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 RPL is a distance vector IPv6 routing protocol designed for Low power 70 and Lossy Networks (LLNs) [I-D.ietf-roll-rpl]. Such networks are 71 typically constrained in energy and/or channel capacity. To conserve 72 precious resources, a routing protocol must generate control traffic 73 sparingly. However, this is at odds with the need to quickly 74 propagate any new routing information to resolve routing 75 inconsistencies quickly. 77 To help minimize resource consumption, RPL uses a slow proactive 78 process to construct and maintain a routing topology but a reactive 79 and dynamic process to resolving routing inconsistencies. In the 80 steady state, RPL maintains the routing topology using a low-rate 81 beaconing process. However, when RPL detects inconsistencies that 82 may prevent proper datagram delivery, RPL temporarily increases the 83 beacon rate to quickly resolve those inconsistencies. This dynamic 84 rate control operation is governed by the use of dynamic timers also 85 referred to as "Trickle" timers and defined in [RFC6206]. In 86 contrast to other routing protocols (e.g OSPF [RFC2328]), RPL detects 87 routing inconsistencies using data-path verification, by including 88 routing information within the datagram itself. In doing so, repair 89 mechanisms operate only as needed, allowing the control and data 90 planes to operate on similar time scales. The main motivation for 91 data path verification in LLNs is that control plane traffic should 92 be carefully bounded with respect to the data traffic. Intuitively, 93 there is no need to solve routing issues (which may be temporary) in 94 the absence of data traffic. 96 The RPL protocol constructs a Directed Acyclic Graph (DAG) that 97 attempts to minimize path costs to the DAG root according to a set of 98 metric and objective functions. There are circumstances where loops 99 may occur, and RPL is designed to use a data-path loop detection 100 method. This is one of the known requirements of RPL and other data- 101 path usage might be defined in the future. 103 To that end, this document defines a new IPv6 option, called the RPL 104 Option, to be carried within the IPv6 Hop-by-Hop header. The RPL 105 Option is only for use between RPL routers participating in the same 106 RPL Instance. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Overview 116 The RPL Option provides a mechanism to include routing information 117 with each datagram that a router forwards. When receiving datagrams 118 that include routing information, RPL routers process the routing 119 information to help maintain the routing topology. 121 Every RPL router along a packet's delivery path processes and updates 122 the RPL Option. If the received packet does not already contain a 123 RPL Option, the RPL router must insert a RPL Option before forwarding 124 it to another RPL router. This draft also specifies the use of IPv6- 125 in-IPv6 tunneling [RFC2473] when attaching a RPL option to a packet. 126 Use of tunneling ensures that the original packet remains unmodified 127 and that ICMP errors return to the RPL Option source rather than the 128 source of the original packet. 130 3. Format of the RPL Option 132 The RPL Option is carried in an IPv6 Hop-by-Hop Options header, 133 immediately following the IPv6 header. This option has an alignment 134 requirement of 2n. The option has the following format: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Option Type | Opt Data Len | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | (sub-TLVs) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: RPL Option 148 Option Type: TBD by IANA. 150 Opt Data Len: 8-bit field indicating the length of the option, in 151 octets, excluding the Option Type and Opt Data Len fields. 153 Down 'O': 1-bit flag as defined in Section 11.2 of 154 [I-D.ietf-roll-rpl]. The processing SHALL follow the rules 155 described in Section 11.2 of [I-D.ietf-roll-rpl]. 157 Rank-Error 'R': 1-bit flag as defined in Section 11.2 of 158 [I-D.ietf-roll-rpl]. The processing SHALL follow the rules 159 described in Section 11.2 of [I-D.ietf-roll-rpl]. 161 Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of 162 [I-D.ietf-roll-rpl]. The processing SHALL follow the rules 163 described in Section 11.2 of [I-D.ietf-roll-rpl]. 165 RPLInstanceID: 8-bit field as defined in Section 11.2 of 166 [I-D.ietf-roll-rpl]. The processing SHALL follow the rules 167 described in Section 11.2 of [I-D.ietf-roll-rpl]. 169 SenderRank: 16-bit field as defined in Section 11.2 of 170 [I-D.ietf-roll-rpl]. The processing SHALL follow the rules 171 described in Section 11.2 of [I-D.ietf-roll-rpl]. 173 The two high order bits of the Option Type MUST be set to '01' and 174 the third bit is equal to '1'. With these bits, according to 175 [RFC2460], nodes that do not understand this option on a received 176 packet MUST discard the packet. Also, according to [RFC2460], the 177 values within the RPL Option are expected to change en-route. The 178 RPL Option Data Length is variable. 180 The action taken by using the RPL Option and the potential set of 181 sub-TLVs carried within the RPL Option MUST be specified by the RFC 182 of the protocol that use that option. No sub-TLVs are defined in 183 this document. A RPL device MUST skip over any unrecognized sub-TLVs 184 and attempt to process any additional sub-TLVs that may appear after. 186 4. RPL Router Behavior 188 Datagrams sent between RPL routers MUST include a RPL Option or RPL 189 Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY 190 include both. A datagram including a SRH does not need to include a 191 RPL Option since both the source and intermediate routers ensure that 192 the SRH does not contain loops. 194 When the router is the source of the original packet and the 195 destination is known to be within the same RPL Instance, the router 196 SHOULD include the RPL Option directly within the original packet. 197 Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and 198 place the RPL Option in the tunnel header. Using IPv6-in-IPv6 199 tunneling ensures that the delivered datagram remains unmodified and 200 that ICMPv6 errors generated by a RPL Option are sent back to the 201 router that generated the RPL Option. 203 A RPL router chooses the next RPL router that should process the 204 original packet as the tunnel exit-point. In some cases, the tunnel 205 exit-point will be the final RPL router along a path towards the 206 original packet's destination and the original packet will only 207 traverse a single tunnel. One example is when the final destination 208 or the destination's attachment router is known to be within the same 209 RPL Instance. 211 In other cases, the tunnel exit-point will not be the final RPL 212 router along a path and the original packet may traverse multiple 213 tunnels to reach the destination. One example is when a RPL router 214 is simply forwarding a packet to one of its DODAG Parents. In this 215 case, the RPL router sets the tunnel exit-point to a DODAG Parent. 216 When forwarding the original packet hop-by-hop, the RPL router only 217 makes a determination on the next hop towards the destination. 219 A RPL router receiving an IPv6-in-IPv6 packet destined to it 220 processes the tunnel packet as described in Section 3 of [RFC2473]. 221 Before IPv6 decapsulation, the RPL router MUST process the RPL Option 222 if one exists. After IPv6 decapsulation, if the router determines 223 that it should forward the original packet to another RPL router it 224 MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to 225 include the RPL Option. Fields within the RPL Option that do not 226 change hop-by-hop MUST remain the same as those received from the 227 prior tunnel. 229 RPL routers are responsible for ensuring that a RPL Option is only 230 used between RPL routers: 232 1. For datagrams destined to a RPL router, the router processes the 233 packet in the usual way. For instance, if the RPL Option was 234 included using tunneled mode and the RPL router serves as the 235 tunnel endpoint, the router removes the outer IPv6 header, at the 236 same time removing the RPL Option as well. 238 2. Datagrams destined elsewhere within the same RPL Instance are 239 forwarded to the correct interface. 241 3. Datagrams destined to nodes outside the RPL Instance are dropped 242 if the outer-most IPv6 header contains a RPL Option not generated 243 by the RPL router forwarding the datagram. 245 To avoid fragmentation, it is desirable to employ MTU sizes that 246 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 247 header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the 248 maximum RPL Option header size for a given RPL network. To take 249 advantage of this, however, the communicating endpoints need to be 250 aware of the MTU along the path (i.e. through Path MTU Discovery). 251 Unfortunately, the larger MTU size may not be available on all links 252 (e.g. 1280 octets on 6LoWPAN links). However, it is expected that 253 much of the traffic on these types of networks consists of much 254 smaller messages than the MTU, so performance degradation through 255 fragmentation would be limited. 257 5. Security Considerations 259 The RPL Option assists RPL routers in detecting routing 260 inconsistencies. The RPL message security mechanisms defined in 261 [I-D.ietf-roll-rpl] do not apply to the RPL Option. 263 5.1. DAG Inconsistency Attacks 265 Using the Down 'O' flag and SenderRank field, an attacker can cause 266 RPL routers to believe that a DAG inconsistency exists within the RPL 267 instance identified by the RPLInstanceID field. This attack would 268 cause a RPL router to reset its DIO Trickle timer and begin 269 transmitting DIO messages more frequently. 271 In order to avoid any unacceptable impact on network operations, an 272 implementation MAY limit the number of triggers caused by receiving a 273 RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS per hour. A 274 RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20. 276 5.2. DAO Inconsistency Attacks 278 In storing mode, RPL routers maintain downward routing state. Under 279 normal operation, the RPL Option assists RPL routers in cleaning up 280 stale downward routing state by using the Forwarding-Error 'F' flag 281 to indicate that a datagram could not be delivered by a child and is 282 being sent back to try a different child. Using this flag, an 283 attacker can cause a RPL router to discard downward routing state. 285 In order to avoid any unacceptable impact on network operations, an 286 implementation MAY limit the number of triggers caused by receiving a 287 RPL Option to no greater than MAX_RPL_OPTION_FORWARD_ERRORS per hour. 288 A RECOMMENDED value for MAX_RPL_OPTION_FORWARD_ERRORS is 20. 290 In non-storing mode, only the LBR maintains downward routing state. 291 Because RPL routers do not maintain downward routing state, the RPL 292 Option cannot be used to mount such attacks. 294 6. IANA Considerations 296 IANA is requested to reserve a new value in the Destination Options 297 and Hop-by-Hop Options registry. The proposed value to be confirmed 298 by IANA is: 300 Hex Value Binary Value 301 act chg rest Description Reference 302 --------- --- --- ------- ----------------- ---------- 303 TBD 01 1 TBD RPL Option [RFCthis] 305 As specified in [RFC2460], the first two bits indicate that the IPv6 306 node MUST discard the packet if it doesn't recognize the option type, 307 and the third bit indicates that the Option Data may change en-route. 308 The remaining bits serve as the option type and are TBD by IANA. 310 IANA is requested to create a registry called RPL-option-TLV, for the 311 sub-TLVs carried in the RPL Option header. New codes may be 312 allocated only by IETF Review [RFC5226]. The type field is an 8-bit 313 field whose value be between 0 and 255, inclusive. 315 7. Acknowledgements 317 The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen 318 Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik 319 Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their 320 comments and suggestions that helped shape this document. 322 8. Changes 324 (This section to be removed by the RFC editor.) 326 Draft 06: 328 - Address IESG comments. 330 Draft 05: 332 - Address LC comments. 334 Draft 04: 336 - Clarify when the RPL Option is used. 338 - Updated text on recommendations for avoiding fragmentation. 340 - Specify skip-over-and-continue policy for unrecognized sub-TLVs. 342 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 344 - Specify RPL Border Router operations in terms of forwarding 345 decision outcomes. 347 - Expand security section. 349 Draft 03: 351 - Removed any presumed values that are TBD by IANA. 353 9. References 355 9.1. Normative References 357 [I-D.ietf-roll-rpl] 358 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 359 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 360 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 361 Lossy Networks", draft-ietf-roll-rpl-19 (work in 362 progress), March 2011. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 369 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 370 (IPv6) Specification", RFC 2460, December 1998. 372 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 373 IPv6 Specification", RFC 2473, December 1998. 375 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 376 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 377 May 2008. 379 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 380 "The Trickle Algorithm", RFC 6206, March 2011. 382 9.2. Informative References 384 [I-D.ietf-6man-rpl-routing-header] 385 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 386 Routing Header for Source Routes with RPL", 387 draft-ietf-6man-rpl-routing-header-05 (work in progress), 388 November 2011. 390 Authors' Addresses 392 Jonathan W. Hui 393 Cisco Systems, Inc 394 170 West Tasman Drive 395 San Jose, California 95134 396 USA 398 Phone: +408 424 1547 399 Email: jonhui@cisco.com 401 JP Vasseur 402 Cisco Systems, Inc 403 11, Rue Camille Desmoulins 404 Issy Les Moulineaux, 92782 405 France 407 Email: jpv@cisco.com