idnits 2.17.1 draft-hui-6man-rpl-headers-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 -- The document date (July 28, 2010) is 5021 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-00 == Outdated reference: A later version (-07) exists of draft-ietf-6man-rpl-routing-header-00 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-10 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-03 Summary: 1 error (**), 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 P. Thubert 5 Expires: January 29, 2011 JP. Vasseur 6 Cisco Systems, Inc 7 July 28, 2010 9 Using RPL Headers Without IP-in-IP 10 draft-hui-6man-rpl-headers-00 12 Abstract 14 Routing for Low Power and Lossy Networks (RPL) is a routing protocol 15 designed for Low power and Lossy Networks (LLNs). RPL includes 16 routing information in IPv6 data plane datagrams to help maintain the 17 routing topology. When forwarding a datagram into a RPL domain, a 18 RPL router may need to expand the datagram to include routing 19 information in IPv6 Extension headers. A generic solution has been 20 defined that uses IP-in-IP tunneling to include RPL routing 21 information. This document describes an alternative to inserting and 22 removing RPL information in datagrams without the use of IP-in-IP 23 tunneling. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 29, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Inserting Headers . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Removing Headers . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 Routing for Low Power and Lossy Networks (RPL) is a distance vector 73 IPv6 routing protocol designed for Low Power and Lossy networks 74 (LLNs) [I-D.ietf-roll-rpl]. Such networks are typically constrained 75 in resources (limited communication data rate, processing power, 76 energy capacity, memory). When forwarding datagrams within a RPL 77 domain, RPL requires those datagrams to carry routing information. 78 RPL routing information may be included using a RPL Option within an 79 IPv6 Hop-by-Hop Option header to perform routing loop detection and 80 repair [I-D.ietf-6man-rpl-option]. RPL may also use a strict source 81 route specified in an IPv6 Routing Header 82 [I-D.ietf-6man-rpl-routing-header]. RPL uses source routing in LLNs 83 composed of resource-constrained nodes that can maintain no more than 84 a few routing entries. 86 Because the RPL routing information is only useful within a RPL 87 domain, RPL Border Routers (referred to as LBRs in 88 [I-D.ietf-roll-terminology]) are responsible for inserting and 89 removing RPL information when forwarding datagrams into or out of a 90 RPL domain. However, to nodes outside the RPL domain, there must not 91 be any visible side effects of inserting RPL information. Unwanted 92 side effects include: 94 1. Mutations to the IPv6 packet headers being processed hop-by-hop 95 are not undone before exiting the RPL domain. Doing so affects 96 how non-RPL routers process the datagram. 98 2. Mutations to the datagram are not undone before being sent back 99 either partially or in whole to the source (e.g. in an ICMP 100 error). Doing so affects how the source handles the returned 101 datagram, such as examining the payload of an ICMP error. 103 3. Changing any values included in computing a security signature, 104 such as the IPv6 Payload Length and Next Header values for the 105 Integrity Check Value of the IP Authentication Header [RFC4302]. 107 4. Generating ICMP Packet Too Big errors that do not correctly 108 reflect the path MTU in the RPL domain due to inclusion of the 109 RPL information. 111 5. Not being capable of generating the correct path MTU because its 112 value is less than 1280 octets due to the size of RPL routing 113 information. 115 The default mechanism for inserting and removing RPL information is 116 by using IP-in-IP tunneling, encapsulating the existing packet with a 117 new IPv6 header and including the RPL Option and/or routing header in 118 the outer IPv6 header. By tunneling the datagram, the original 119 datagram is left unmodified. Furthermore, any ICMP errors return to 120 the RPL router that inserted RPL information into the datagram. IP- 121 in-IP tunneling avoids path MTU issues because the ICMP Packet Too 122 Big error will return to the RPL router that inserted the headers, 123 allowing it to perform IP fragmentation and requires no additional 124 action by nodes outside the RPL domain. 126 However, where LLNs are severely constrained in resources, IP-in-IP 127 tunneling may not be the most favorable solution. Use of IP-in-IP 128 requires datagrams to carry two IPv6 headers, increasing header 129 overhead and associated communication and memory requirements. 130 Expanding existing header compression techniques to efficiently 131 support IP-in-IP necessarily adds complexity. LLN nodes must also 132 implement packet processing code that supports IP-in-IP, further 133 increasing code complexity. 135 This document describes how to insert and remove RPL routing 136 information without IP-in-IP tunneling such that no side effects are 137 visible to nodes outside the RPL domain. This mode of forwarding 138 without IP-in-IP tunneling is defined as transport mode. Note that 139 transport mode is only provided as an option when IP-in-IP tunneling 140 is not possible. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2. Inserting Headers 150 This section specifies how a RPL router inserts RPL routing 151 information into an existing IPv6 datagram. We define rpl_info_size 152 as the number of octets required to carry RPL information in a 153 particular datagram and can vary between datagrams (e.g. due to 154 different lengths in source route). 156 1. If the source node is within the RPL domain, it MUST compute any 157 security integrity checks as if no RPL information was inserted 158 into the datagram. For example, the IPv6 Payload Length used for 159 computing the integrity check should not include the octets 160 required for carrying RPL information. 162 2. The RPL router SHOULD respect the IPv6 Extension header ordering 163 recommended in [RFC2460]. 165 3. If the datagram size after inserting RPL information exceeds the 166 MTU of the directly attached link used to reach the next hop, the 167 RPL router MUST send either an ICMP Packet Too Big error to the 168 source. The RPL router MUST subtract rpl_info_size from the MTU 169 value of the error-causing link and report that as the MTU value. 170 If the resulting MTU value is less than 1280 octets, the RPL 171 router MUST suppress the ICMP Packet Too Big error and send an 172 ICMP Destination Unreachable error back to the source instead. 174 3. Removing Headers 176 All RPL routing information MUST be removed in the following cases: 178 1. When forwarding datagrams outside the RPL domain. 180 2. Before computing any integrity check values for verification. 181 For example, the IPv6 Payload Length used for computing the 182 integrity check should not include the octets required for 183 carrying RPL information. 185 The remainder of this section specifies how a RPL router removes RPL 186 routing information in an existing IPv6 datagram. 188 1. Any RPL-specific IPv6 Extension headers MUST be removed from the 189 datagram, if any exist. The IPv6 Payload Length and 190 corresponding Next Header fields MUST be updated to reflect their 191 removal. 193 2. The RPL Option MUST be removed from the IPv6 Hop-by-Hop Options 194 header of the datagram, if one exists. 196 3. If the RPL router is generating an ICMP error, the RPL router 197 MUST remove any RPL information from the datagram in error before 198 including it in the ICMP error's payload. 200 4. If the RPL router is generating an ICMP Packet Too Big error, the 201 RPL router MUST subtract rpl_info_size from the MTU value of the 202 error-causing link and report that as the MTU value in the 203 message. If the resulting MTU value is less than 1280 octets, 204 the RPL router MUST suppress the ICMP Packet Too Big error and 205 send an ICMP Destination Unreachable error back to the source 206 instead. 208 4. Security Considerations 210 The generation of ICMPv6 error messages may be used to attempt 211 denial-of-service attacks by sending a large number of packets that 212 exceed the MTU of the RPL domain. It is RECOMMENDED that an 213 implementation correctly follows Section 2.4 of [RFC4443] to rate 214 limit the generation of ICMPv6 messages. 216 5. IANA Considerations 218 This document does not require any action from IANA. 220 6. References 222 6.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 228 (IPv6) Specification", RFC 2460, December 1998. 230 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 231 Message Protocol (ICMPv6) for the Internet Protocol 232 Version 6 (IPv6) Specification", RFC 4443, March 2006. 234 6.2. Informative References 236 [I-D.ietf-6man-rpl-option] 237 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 238 Information in Data-Plane Datagrams", 239 draft-ietf-6man-rpl-option-00 (work in progress), 240 July 2010. 242 [I-D.ietf-6man-rpl-routing-header] 243 Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing 244 Header for Source Routes with RPL", 245 draft-ietf-6man-rpl-routing-header-00 (work in progress), 246 July 2010. 248 [I-D.ietf-roll-rpl] 249 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 250 Protocol for Low power and Lossy Networks", 251 draft-ietf-roll-rpl-10 (work in progress), June 2010. 253 [I-D.ietf-roll-terminology] 254 Vasseur, J., "Terminology in Low power And Lossy 255 Networks", draft-ietf-roll-terminology-03 (work in 256 progress), March 2010. 258 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 259 December 2005. 261 Authors' Addresses 263 Jonathan W. Hui 264 Arch Rock Corporation 265 501 2nd St. Ste. 410 266 San Francisco, California 94107 267 USA 269 Phone: +415 692 0828 270 Email: jhui@archrock.com 272 Pascal Thubert 273 Cisco Systems, Inc 274 Village d'Entreprises Green Side 275 400, Avenue de Roumanille 276 Batiment T3 277 Biot - Sophia Antipolis 06410 278 FRANCE 280 Phone: +33 4 97 23 26 34 281 Email: pthubert@cisco.com 283 JP Vasseur 284 Cisco Systems, Inc 285 11, Rue Camille Desmoulins 286 Issy Les Moulineaux, 92782 287 France 289 Email: jpv@cisco.com