idnits 2.17.1 draft-ietf-6man-rpl-option-00.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 219 has weird spacing: '... act chg ...' -- The document date (July 26, 2010) is 5016 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-10 ** 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) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-03 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 Arch Rock Corporation 4 Intended status: Standards Track JP. Vasseur 5 Expires: January 27, 2011 Cisco Systems, Inc 6 July 26, 2010 8 RPL Option for Carrying RPL Information in Data-Plane Datagrams 9 draft-ietf-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 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 January 27, 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 . . . . . . . . . . . . . . . . . . 4 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 6 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 65 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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. Overview 121 Datagrams being forwarded within a RPL domain MUST include a RPL 122 Option. For datagrams sourced within a RPL domain, the RPL Option 123 MAY be included in the datagram itself. For datagrams sourced 124 outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in 125 [RFC2473] MUST be used to include a RPL Option. When forwarding the 126 datagram, the router MUST prepend a new IPv6 header and IPv6 Hop-by- 127 Hop Options header containing the RPL Option to the existing 128 datagram. Use of tunneling ensures that the datagram is delivered 129 unmodified and that ICMP errors return to the RPL Option source 130 rather than the source of the original datagram. 132 To help avoid IP-layer fragmentation, the RPL Option has a maximum 133 size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain 134 SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop 135 Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional 136 extension headers or options needed within RPL domain). 138 3. Format of the RPL Option 140 The RPL option is carried in an IPv6 Hop-by-Hop Options header, 141 immediately following the IPv6 header. The RPL option has the 142 following format: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Option Type | Opt Data Len | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | (sub-TLVs) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: RPL Option 154 The Opt Data Len MUST NOT exceed RPL_OPTION_MAX_SIZE octets. 156 The Option Data of the RPL option is expected to change en-route. 157 Nodes that do not understand the RPL option MUST skip over this 158 option and continue processing the header. Thus, according to 159 [RFC2460] the two high order bits of the Option Type must be equal 160 set to zero and the third bit is equal to 1. The RPL Option Data 161 Length is variable. 163 The action taken by using the RPL Option and the potential set of 164 sub-TLVs carried within the RPL Option MUST be specified by the RFC 165 of the protocol that use that option. No TLVs are currently defined. 167 4. RPL Router Behavior 169 Routers MUST include a RPL Option when forwarding datagrams that do 170 not already contain a RPL Option. If one does not already exist, 171 routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to 172 include a RPL Option in datagrams that are sourced by other nodes. 173 This ensures that the original datagram is delivered unmodified. 175 Performing IP-in-IP encapsulation may grow the datagram to a size 176 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 177 fragmentation caused by IP-in-IP encapsulation, links within a RPL 178 domain SHOULD be configured with a MTU of at least 1280 + 44 (outer 179 IP header, Hop-by-Hop Option header, Option header) + 180 RPL_OPTION_MAX_SIZE + (additional extension headers or options needed 181 within RPL domain). 183 5. RPL Border Router Behavior 185 RPL Border Routers (referred to as LBRs in 186 [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL 187 Option is only used within a RPL domain. 189 For datagrams entering the RPL domain, RPL Border Routers MUST drop 190 received datagrams that contain a RPL Option in the IPv6 Extension 191 headers. 193 For datagrams exiting the RPL domain, RPL Border Routers MUST remove 194 the RPL Option from the datagram and update the IPv6 Payload Length 195 field accordingly. 197 6. Usage of the RPL Option 199 The RPL option is only for use within a RPL domain. RPL routers MUST 200 process and include the RPL option when forwarding datagrams to other 201 nodes within the RPL domain. Routers on the edge of a RPL domain 202 MUST remove the RPL option when forwarding datagrams to nodes outside 203 the RPL domain. The final destination of the datagram MAY ignore the 204 RPL option. 206 7. Protocol Constants 208 RPL_OPTION_MAX_SIZE 128 210 8. Acknowledgements 212 The authors thank Vishwas Manral and Erik Nordmark for their comments 213 and suggestions that helped shape this document. 215 9. IANA Considerations 217 The RPL option requires an IPv6 Option Number. 219 HEX act chg rest 220 --- --- --- ----- 221 1 00 1 01011 223 The first two bits indicate that the IPv6 node may skip over this 224 option and continue processing the header if it doesn't recognize the 225 option type, and the third bit indicates that the Option Data may 226 change en-route. 228 10. Security Considerations 230 This option may be used a several potential attacks since routers may 231 be flooded by bogus datagram containing the RPL option. It is thus 232 RECOMMENDED for routers to implement a rate limiter for datagrams 233 using the RPL option. 235 11. References 237 11.1. Normative References 239 [I-D.ietf-roll-rpl] 240 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 241 Protocol for Low power and Lossy Networks", 242 draft-ietf-roll-rpl-10 (work in progress), June 2010. 244 [I-D.levis-roll-trickle] 245 Levis, P. and T. Clausen, "The Trickle Algorithm", 246 draft-levis-roll-trickle-00 (work in progress), 247 February 2010. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 254 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 255 (IPv6) Specification", RFC 2460, December 1998. 257 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 258 IPv6 Specification", RFC 2473, December 1998. 260 11.2. Informative References 262 [I-D.ietf-roll-terminology] 263 Vasseur, J., "Terminology in Low power And Lossy 264 Networks", draft-ietf-roll-terminology-03 (work in 265 progress), March 2010. 267 Authors' Addresses 269 Jonathan W. Hui 270 Arch Rock Corporation 271 501 2nd St. Ste. 410 272 San Francisco, California 94107 273 USA 275 Phone: +415 692 0828 276 Email: jhui@archrock.com 278 JP Vasseur 279 Cisco Systems, Inc 280 11, Rue Camille Desmoulins 281 Issy Les Moulineaux, 92782 282 France 284 Email: jpv@cisco.com