idnits 2.17.1 draft-ietf-6man-rpl-option-04.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 237 has weird spacing: '... act chg ...' -- The document date (October 12, 2011) is 4573 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 239, but not defined == Unused Reference: 'I-D.hui-6man-rpl-headers' is defined on line 313, but no explicit reference was found in the text ** 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-06 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: April 14, 2012 Cisco Systems, Inc 6 October 12, 2011 8 RPL Option for Carrying RPL Information in Data-Plane Datagrams 9 draft-ietf-6man-rpl-option-04 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 April 14, 2012. 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 . . . . . . . . . . . . . . . . . . . . . 7 57 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 8 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 10.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 86 [I-D.ietf-roll-trickle]. In contrast to other routing protocols (e.g 87 OSPF [RFC2328]), RPL detects routing inconsistencies using data-path 88 verification, by including routing information within the datagram 89 itself. In doing so, repair mechanisms operate only as needed, 90 allowing the control and data planes to operate on similar time 91 scales. The main motivation for data path verification in LLNs is 92 that control plane traffic should be carefully bounded with respect 93 to the data traffic. Intuitively, there is no need to solve routing 94 issues (which may be temporary) in 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 proposes 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 within a RPL domain. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Overview 115 Datagrams sent between nodes within a RPL domain MUST include a RPL 116 Option or RPL Source Route Header (SRH) and MAY include both. When a 117 RPL Border Router inserts a RPL Option, it MUST do so by using IPv6- 118 in-IPv6 tunneling, as specified in [RFC2473]. Use of tunneling 119 ensures that the datagram is delivered unmodified and that ICMP 120 errors return to the RPL Option source rather than the source of the 121 original datagram. 123 3. Format of the RPL Option 125 The RPL Option is carried in an IPv6 Hop-by-Hop Options header, 126 immediately following the IPv6 header. This option has an alignment 127 requirement of 2n. The option has the following format: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Option Type | Opt Data Len | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | (sub-TLVs) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 1: RPL Option 141 Option Type: TBD by IANA. 143 Opt Data Len: 8-bit field indicating the length of the option, in 144 octets, excluding the Option Type and Opt Data Len fields. 146 Down 'O': 1-bit flag as defined in Section 11.2 of 147 [I-D.ietf-roll-rpl]. The processing shall follow the rules 148 described in Section 11.2 of [I-D.ietf-roll-rpl]. 150 Rank-Error 'R': 1-bit flag as defined in Section 11.2 of 151 [I-D.ietf-roll-rpl]. The processing shall follow the rules 152 described in Section 11.2 of [I-D.ietf-roll-rpl]. 154 Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of 155 [I-D.ietf-roll-rpl]. The processing shall follow the rules 156 described in Section 11.2 of [I-D.ietf-roll-rpl]. 158 RPLInstanceID: 8-bit field as defined in Section 11.2 of 159 [I-D.ietf-roll-rpl]. The processing shall follow the rules 160 described in Section 11.2 of [I-D.ietf-roll-rpl]. 162 SenderRank: 16-bit field as defined in Section 11.2 of 163 [I-D.ietf-roll-rpl]. The processing shall follow the rules 164 described in Section 11.2 of [I-D.ietf-roll-rpl]. 166 Values within the RPL Option are expected to change en-route. Nodes 167 that do not understand the RPL Option MUST discard the packet. Thus, 168 according to [RFC2460] the two high order bits of the Option Type 169 must be equal set to '01' and the third bit is equal to '1'. The RPL 170 Option Data Length is variable. 172 The action taken by using the RPL Option and the potential set of 173 sub-TLVs carried within the RPL Option MUST be specified by the RFC 174 of the protocol that use that option. No TLVs are defined in this 175 document. A RPL device MUST skip over any unrecognized sub-TLVs and 176 attempt to process any additional sub-TLVs that may appear after. 178 4. RPL Router Behavior 180 To deliver an IPv6 datagram to its destination, a router may need to 181 insert a new RPL Option. Routers MUST use IPv6-in-IPv6 tunneling, as 182 specified in [RFC2473] to include a new RPL Option in datagrams that 183 are sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures 184 that the delivered datagram remains unmodified and that ICMPv6 errors 185 generated by inserting the RPL Option are sent back to the router 186 that generated the routing header. 188 To avoid fragmentation, it is desirable to employ MTU sizes that 189 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 190 header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the 191 maximum RPL Option header size for a given RPL network. To take 192 advantage of this, however, the communicating endpoints need to be 193 aware of the MTU along the path (i.e. through Path MTU Discovery). 194 Unfortunately, the larger MTU size may not be available on all links 195 (e.g. 1280 octets on 6LoWPAN links). However, it is expected that 196 much of the traffic on these types of networks consists of much 197 smaller messages than the MTU, so performance degradation through 198 fragmentation would be limited. 200 5. RPL Border Router Behavior 202 RPL Border Routers (referred to as LBRs in 203 [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL 204 Option is only used within a RPL domain. 206 For datagrams destined to the RPL Border Router, the router processes 207 the packet in the usual way. For instance, if the RPL Option was 208 included using tunneled mode and the RPL Border Router serves as the 209 tunnel endpoint, the router removes the outer IPv6 header, at the 210 same time removing the RPL Option as well. 212 Datagrams destined elsewhere within the same RPL domain are forwarded 213 to the correct interface. 215 Datagrams destined to nodes outside the RPL domain are dropped if the 216 outer-most IPv6 header contains a RPL Option. 218 6. Security Considerations 220 This option may be used to mount several potential attacks since 221 routers may be flooded by bogus datagrams containing the RPL Option. 222 In particular, an inconsistent Rank value can cause a RPL router to 223 reset its DIO Trickle timer. 225 In order to avoid any unacceptable impact on network operations, an 226 implementation MAY limit the number of triggers caused by receiving a 227 RPL Option to no greater than MAX_RPL_OPTION_TRIGGERS per hour. A 228 RECOMMENDED value for MAX_RPL_OPTION_TRIGGERS is 20. 230 7. IANA Considerations 232 IANA is requested to reserve a new value in the Destination Options 233 and Hop-by-Hop Options registry. The proposed value to be confirmed 234 by IANA is: 236 Hex Value Binary Value 237 act chg rest Description Reference 238 --------- --- --- ------- ----------------- ---------- 239 TBD 01 1 TBD RPL Option [RFCthis] 241 As specified in [RFC2460], the first two bits indicate that the IPv6 242 node MUST discard the packet if it doesn't recognize the option type, 243 and the third bit indicates that the Option Data may change en-route. 244 The remaining bits serve as the option type and are TBD by IANA. 246 IANA is requested to create a registry called RPL-option-TLV, for the 247 TLVs carried in the RPL Option header. New codes may be allocated 248 only by IETF Review [RFC5226]. The type field is an 8-bit field 249 whose value be between 0 and 255, inclusive. 251 8. Acknowledgements 253 The authors thank Jari Arkko, Richard Kelsey, Suresh Krishnan, 254 Vishwas Manral, Erik Nordmark, Pascal Thubert, and Tim Winter, for 255 their comments and suggestions that helped shape this document. 257 9. Changes 259 (This section to be removed by the RFC editor.) 261 Draft 04: 263 - Clarify when the RPL Option is used. 265 - Updated text on recommendations for avoiding fragmentation. 267 - Specify skip-over-and-continue policy for unrecognized sub-TLVs. 269 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 271 - Specify RPL Border Router operations in terms of forwarding 272 decision outcomes. 274 - Expand security section. 276 Draft 03: 278 - Removed any presumed values that are TBD by IANA. 280 10. References 282 10.1. Normative References 284 [I-D.ietf-roll-rpl] 285 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 286 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 287 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 288 Lossy Networks", draft-ietf-roll-rpl-19 (work in 289 progress), March 2011. 291 [I-D.ietf-roll-trickle] 292 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 293 "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work 294 in progress), January 2011. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 301 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 302 (IPv6) Specification", RFC 2460, December 1998. 304 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 305 IPv6 Specification", RFC 2473, December 1998. 307 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 308 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 309 May 2008. 311 10.2. Informative References 313 [I-D.hui-6man-rpl-headers] 314 Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers 315 Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in 316 progress), July 2010. 318 [I-D.ietf-roll-terminology] 319 Vasseur, J., "Terminology in Low power And Lossy 320 Networks", draft-ietf-roll-terminology-06 (work in 321 progress), September 2011. 323 Authors' Addresses 325 Jonathan W. Hui 326 Arch Rock Corporation 327 501 2nd St. Ste. 410 328 San Francisco, California 94107 329 USA 331 Phone: +415 692 0828 332 Email: jhui@archrock.com 334 JP Vasseur 335 Cisco Systems, Inc 336 11, Rue Camille Desmoulins 337 Issy Les Moulineaux, 92782 338 France 340 Email: jpv@cisco.com