idnits 2.17.1 draft-ietf-6man-rpl-option-01.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 244 has weird spacing: '... act chg ...' -- The document date (October 23, 2010) is 4932 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-13 == Outdated reference: A later version (-08) exists of draft-ietf-roll-trickle-04 ** 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: April 26, 2011 Cisco Systems, Inc 6 October 23, 2010 8 RPL Option for Carrying RPL Information in Data-Plane Datagrams 9 draft-ietf-6man-rpl-option-01 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 26, 2011. 35 Copyright Notice 37 Copyright (c) 2010 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. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 9 59 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 10 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 66 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 RPL is a distance vector IPv6 routing protocol designed for low power 72 and lossy networks [I-D.ietf-roll-rpl]. Such networks are typically 73 constrained in energy and/or channel capacity. To conserve precious 74 resources, a routing protocol must generate control traffic 75 sparingly. However, this is at odds with the need to quickly 76 propagate any new routing information to resolve routing 77 inconsistencies quickly. 79 To help minimize resource consumption, RPL uses a slow proactive 80 process to construct and maintain a routing topology but a reactive 81 and dynamic approach to resolving routing inconsistencies. In the 82 steady state, RPL maintains the routing topology using a low-rate 83 beaconing process. However, when RPL detects inconsistencies that 84 may prevent proper datagram delivery, RPL temporarily increases the 85 beacon rate to quickly resolve those inconsistencies. Such a dynamic 86 rate of control packets operation is governed by the use of dynamic 87 timers also referred to as "trickle" timers and defined in 88 [I-D.ietf-roll-trickle]. By contrast with other routing protocols 89 such as OSPF ([RFC2328]), RPL detects routing inconsistencies using 90 data-path verification, by including routing information within the 91 datagram itself. Data-path verification quickly detects and resolves 92 inconsistencies when routes are needed by the data flow itself. In 93 doing so, repair mechanisms operate only as needed, allowing the 94 control and data planes to operate on similar time scales. The main 95 motivation for data path verification in Low power and Lossy Networks 96 (LLNs) is that control plane traffic should be carefully bounded with 97 respect to the data traffic: there is no need to solve a routing 98 issues (which may be temporary) in the absence of data traffic. 100 The RPL protocol constructs a Directed Acyclic Graph (DAG) that 101 attempts to minimize path costs to the DAG root according to a set of 102 metric and objective functions. There are circumstances where loops 103 may occur, and RPL is designed to use a data-path loop detection 104 method. This is one of the known requirements of RPL and other data- 105 path usage might be defined in the future. 107 To that end, this document proposes a new IPv6 option called the RPL 108 Option to be carried within the IPv6 Hop-by-Hop header. The RPL 109 Option is for use only within a RPL domain. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Overview 119 Datagrams being forwarded within a RPL domain MUST include a RPL 120 Option. For datagrams sourced within a RPL domain, the RPL Option 121 MAY be included in the datagram itself. For datagrams sourced 122 outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in 123 [RFC2473] MUST be used to include a RPL Option. When forwarding the 124 datagram, the router MUST prepend a new IPv6 header and IPv6 Hop-by- 125 Hop Options header containing the RPL Option to the existing 126 datagram. Use of tunneling ensures that the datagram is delivered 127 unmodified and that ICMP errors return to the RPL Option source 128 rather than the source of the original datagram. 130 To help avoid IP-layer fragmentation, the RPL Option has a maximum 131 size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain 132 SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop 133 Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional 134 extension headers or options needed within RPL domain). 136 3. Format of the RPL Option 138 The RPL option is carried in an IPv6 Hop-by-Hop Options header, 139 immediately following the IPv6 header. The RPL option has the 140 following format: 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Option Type | Opt Data Len | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | (sub-TLVs) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: RPL Option 154 Option Type: TBD 156 Opt Data Len: 158 Down 'O': 1-bit flag indicating whether the packet is expected to 159 progress Up or Down. A router sets the 'O' flag when the 160 packet is expected to progress Down (using DAO routes), and 161 clears it when forwarding toward the DODAG root (to a node with 162 a lower rank). A host or RPL leaf node MUST set the 'O' flag 163 to 0. 165 Rank-Error 'R': 1-bit flag indicating whether a rank error was 166 detected. A rank error is detected when there is a mismatch in 167 the relative ranks and the direction as indicated in the 'O' 168 bit. A host or RPL leaf node MUST set the 'R' bit to 0. 170 Forwarding-Error 'F': 1-bit flag indicating that this node can not 171 forward the packet further towards the destination. The 'F' 172 bit might be set by a child node that does not have a route to 173 destination for a packet with the Down 'O' bit set. A host or 174 RPL leaf node MUST set the 'F' bit to 0. 176 RPLInstanceID: 8-bit field indicating the DODAG instance along which 177 the packet is sent. 179 SenderRank: 16-bit field set to zero by the source and to 180 DAGRank(rank) by a router that forwards inside the RPL network. 182 Values within the RPL option are expected to change en-route. Nodes 183 that do not understand the RPL option MUST discard the packet. Thus, 184 according to [RFC2460] the two high order bits of the Option Type 185 must be equal set to '01' and the third bit is equal to '1'. The RPL 186 Option Data Length is variable. 188 The action taken by using the RPL Option and the potential set of 189 sub-TLVs carried within the RPL Option MUST be specified by the RFC 190 of the protocol that use that option. No TLVs are currently defined. 192 4. RPL Router Behavior 194 Routers MUST include a RPL Option when forwarding datagrams that do 195 not already contain a RPL Option. If one does not already exist, 196 routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to 197 include a RPL Option in datagrams that are sourced by other nodes. 198 This ensures that the original datagram is delivered unmodified. 200 Performing IP-in-IP encapsulation may grow the datagram to a size 201 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 202 fragmentation caused by IP-in-IP encapsulation, links within a RPL 203 domain SHOULD be configured with a MTU of at least 1280 + 44 (outer 204 IP header, Hop-by-Hop Option header, Option header) + 205 RPL_OPTION_MAX_SIZE + (additional extension headers or options needed 206 within RPL domain). 208 5. RPL Border Router Behavior 210 RPL Border Routers (referred to as LBRs in 211 [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL 212 Option is only used within a RPL domain. 214 For datagrams entering the RPL domain, RPL Border Routers MUST drop 215 received datagrams that contain a RPL Option in the IPv6 Extension 216 headers. 218 For datagrams exiting the RPL domain, RPL Border Routers MUST remove 219 the RPL Option from the datagram and update the IPv6 Payload Length 220 field accordingly. 222 6. Usage of the RPL Option 224 The RPL option is only for use within a RPL domain. RPL routers MUST 225 process and include the RPL option when forwarding datagrams to other 226 nodes within the RPL domain. Routers on the edge of a RPL domain 227 MUST remove the RPL option when forwarding datagrams to nodes outside 228 the RPL domain. 230 7. Protocol Constants 232 RPL_OPTION_MAX_SIZE 128 234 8. Acknowledgements 236 The authors thank Richard Kelsey, Vishwas Manral, Erik Nordmark, 237 Pascal Thubert, and Tim Winter, for their comments and suggestions 238 that helped shape this document. 240 9. IANA Considerations 242 The RPL option requires an IPv6 Option Number. 244 HEX act chg rest 245 --- --- --- ----- 246 1 01 1 01011 248 The first two bits indicate that the IPv6 node MUST discard the 249 packet if it doesn't recognize the option type, and the third bit 250 indicates that the Option Data may change en-route. 252 This document also creates a new IANA registry for the sub-TLVs. No 253 sub-TLVs are defined in this specification. The policy for this 254 registry [RFC5226] is IETF Review. 256 10. Security Considerations 258 This option may be used a several potential attacks since routers may 259 be flooded by bogus datagram containing the RPL option. It is thus 260 RECOMMENDED for routers to implement a rate limiter for datagrams 261 using the RPL option. 263 11. Changes 265 (This section to be removed by the RFC editor.) 267 Draft 01: 269 - Specify that a node must discard the packet if it doesn't 270 recognize the RPL option. 272 - Include RPL loop detection bits in the base header such that an 273 IPv6 Hop-by-Hop Option header with the minimal RPL option consumes 274 only 8 octets. 276 12. References 278 12.1. Normative References 280 [I-D.ietf-roll-rpl] 281 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 282 Kelsey, R., Levis, P., Networks, D., Struik, R., and J. 283 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 284 Lossy Networks", draft-ietf-roll-rpl-13 (work in 285 progress), October 2010. 287 [I-D.ietf-roll-trickle] 288 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 289 "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work 290 in progress), August 2010. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 297 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 298 (IPv6) Specification", RFC 2460, December 1998. 300 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 301 IPv6 Specification", RFC 2473, December 1998. 303 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 304 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 305 May 2008. 307 12.2. Informative References 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