idnits 2.17.1 draft-ietf-6man-rpl-routing-header-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 26, 2010) is 5023 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 (-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 (~~), 3 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 D. Culler 7 UC Berkeley 8 July 26, 2010 10 An IPv6 Routing Header for Source Routes with RPL 11 draft-ietf-6man-rpl-routing-header-00 13 Abstract 15 In Low power and Lossy Networks (LLNs), memory constraints on routers 16 may limit them to maintaining at most a few routes. In some 17 configurations, it is necessary to use these memory constrained 18 routers to deliver datagrams to nodes within the LLN. The Routing 19 for Low Power and Lossy Networks (RPL) protocol can be used in some 20 deployments to store most, if not all, routes on one (e.g. the 21 Directed Acyclic Graph (DAG) root) or few routers and forward the 22 IPv6 datagram using a source routing technique to avoid large routing 23 tables on memory constrained routers. This document specifies a new 24 IPv6 Routing header type for delivering datagrams within a RPL 25 domain. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 27, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Format of the RPL Routing Header . . . . . . . . . . . . . . . 7 65 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. Generating Type 4 Routing Headers . . . . . . . . . . . . 9 67 4.2. Processing Type 4 Routing Headers . . . . . . . . . . . . 9 68 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 6.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 12 71 6.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Routing for Low Power and Lossy Networks (RPL) is a distance vector 83 IPv6 routing protocol designed for Low Power and Lossy networks (LLN) 84 [I-D.ietf-roll-rpl]. Such networks are typically constrained in 85 resources (limited communication data rate, processing power, energy 86 capacity, memory). In particular, some LLN configurations may 87 utilize LLN routers where memory constraints limit nodes to 88 maintaining only a small number of default routes and no other 89 destinations. However, it may be necessary to utilize such memory- 90 constrained routers to forward datagrams and maintain reachability to 91 destinations within the LLN. 93 To utilize paths that include memory-constrained routers, RPL relies 94 on source routing. In one deployment model of RPL, necessary 95 mechanisms are used to collect routing information at more capable 96 routers and form paths from those routers to arbitrary destinations 97 within the RPL domain. However, a source routing mechanism supported 98 by IPv6 is needed to deliver datagrams. 100 This document specifies the Type 4 Routing header (RH4) (to be 101 confirmed by IANA) for use strictly within a RPL domain. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Overview 111 The basic format of RH4 draws from that of the Type 0 Routing header 112 (RH0) [RFC2460]. However, RH4 introduces mechanisms to compact the 113 source route entries when all entries share the same prefix with the 114 IPv6 Destination Address of the encapsulating header, a typical 115 scenario in LLNs using source routing. The compaction mechanism 116 reduces consumption of scarce resources such as bandwidth. 118 RH4 also differs from RH0 in the processing rules to alleviate 119 security concerns that lead to the deprecation of RH0 [RFC5095]. 120 First, routers processing RH4 MUST implement a strict source route 121 policy where each and every IPv6 hop is specified within the datagram 122 itself. Second, a RH4 header MUST only be used within a RPL domain. 123 RPL Border Routers, responsible for connecting RPL domains and IP 124 domains that use other routing protocols, MUST NOT allow datagrams 125 already carrying a RH4 header to enter or exit the RPL domain. 126 Third, to avoid some attacks that lead to the deprecation of RH0, 127 routers along the way MUST verify that loops do not exist with in the 128 source route. 130 To deliver a datagram, a router MAY specify a source route to reach 131 the destination using a RH4. There are two cases that determine how 132 to include an RH4 with a datagram. 134 1. If the RH4 specifies the complete path from source to 135 destination, the RH4 should be included directly within the 136 datagram itself. 138 2. If the RH4 only specifies a subset of the path from source to 139 destination, IPv6-in-IPv6 tunneling MUST be used as specified in 140 [RFC2473]. The router MUST prepend a new IPv6 header and RH4 to 141 the original datagram. Use of tunneling ensures that the 142 datagram is delivered unmodified and that ICMP errors return to 143 the source of the RH4 rather than the source of the original 144 datagram. 146 In a RPL network, Case 1 occurs when both source and destinations are 147 within a RPL domain and a single RH4 header is used to specify the 148 entire path from source to destination, as shown in the following 149 figure: 151 +--------------------+ 152 | | 153 | (S) -------> (D) | 154 | | 155 +--------------------+ 156 RPL Domain 158 In the above scenario, datagrams traveling from source, S, to 159 destination, D, have the following packet structure: 161 +------+------+------+--------//-+ 162 | IPv6 | IPv6 | IPv6 | Packet | 163 | Src | Dst | RH4 | Payload | 164 +------+------+------+--------//-+ 166 S's address is carried in the IPv6 Source Address field. D's address 167 is carried in the last entry of RH4 for all but the last hop, when 168 D's address is carried in the IPv6 Destination Address field. 170 In a RPL network, Case 2 occurs for all datagrams that have either 171 source or destination outside the RPL domain, as shown in the 172 following diagram: 174 +-----------------+ 175 | | 176 | (S) -------> (BR1) -------> (D) 177 | | 178 +-----------------+ 179 RPL Domain 181 +-----------------+ 182 | | 183 | (D) <------- (BR1) <------- (S) 184 | | 185 +-----------------+ 186 RPL Domain 188 In the above scenario, datagrams traveling within the RPL domain have 189 the following packet structure: 191 +------+------+------+------+------+--------//-+ 192 | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | Packet | 193 | Src | Dst | RH4 | Src | Dst | Payload | 194 +------+------+------+------+------+--------//-+ 195 <--- Original Packet ---> 196 <--- Tunneled Packet ---> 198 Note that the outer header (including the RH4) is added and removed 199 by the RPL Border Router. 201 Case 2 also occurs whenever a RPL router needs to insert a source 202 route when forwarding datagram. One such use case with RPL is to 203 have all RPL traffic flow through a Border Router and have the Border 204 Router use source routes to deliver datagrams to their final 205 destination. The Border Router in this case would encapsulate the 206 received datagram unmodified using IPv6-in-IPv6 and include a RH4 in 207 the outer IPv6 header. 209 +-----------------+ 210 | | 211 | (S) -------\ | 212 | \ | 213 | (BR1) 214 | / | 215 | (D) <------/ | 216 | | 217 +-----------------+ 218 RPL Domain 220 In the above scenario, datagrams travel from S to D through BR1. 221 Between S and BR1, the datagrams are routed using the DAG built by 222 RPL and do not contain a RH4. BR1 encapsulates received datagrams 223 unmodified using IPv6-in-IPv6 and the RH4 is included in the outer 224 IPv6 header. 226 To help avoid IP-layer fragmentation, the RH4 header has a maximum 227 size of RH4_MAX_SIZE octets and links within a RPL domain SHOULD have 228 a MTU of at least 1280 + 40 (outer IP header) + RH4_MAX_SIZE (+ 229 additional extension headers or options needed within RPL domain) 230 octets. 232 3. Format of the RPL Routing Header 234 The Type 4 Routing header has the following format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Next Header | Hdr Ext Len | Routing Type=4| Segments Left | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Compr | Pad | Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 . . 245 . Addresses[1..n] . 246 . . 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Next Header 8-bit selector. Identifies the type of header 251 immediately following the Routing header. Uses 252 the same values as the IPv4 Protocol field 253 [RFC3232]. 255 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 256 header in 8-octet units, not including the first 257 8 octets. Hdr Ext Len MUST NOT exceed 258 RH4_MAX_SIZE / 8. Note that when Addresses[1..n] 259 are compressed (i.e. value of Compr is not 0), 260 Hdr Ext Len does not equal twice the number of 261 Addresses. 263 Routing Type 8-bit selector. Set to 4 (to be confirmed by 264 IANA). 266 Segments Left 8-bit unsigned integer. Number of route segments 267 remaining, i.e., number of explicitly listed 268 intermediate nodes still to be visited before 269 reaching the final destination. Value MUST be 270 between 0 and Segments, inclusive. 272 Compr 4-bit unsigned integer. Number of prefix octets 273 from each segment that is elided. For example, a 274 Type 4 Routing header carrying full IPv6 275 addresses sets Compr to 0. 277 Pad 4-bit unsigned integer. Number of octets that 278 are used to for padding after Address[n] and the 279 end of the Type 4 Routing header. 281 Address[1..n] Vector of addresses, numbered 1 to n. Each 282 vector element has size (16 - Compr). 284 The Type 4 Routing header shares the same basic format as the Type 0 285 Routing header [RFC2460]. When carrying full IPv6 addresses, the 286 Compr and Pad fields are set to 0 and the only difference between the 287 Type 4 and Type 0 encodings is the value of the Routing Type field. 289 A common network configuration for a RPL domain is that all nodes 290 within a LLN share a common prefix. Type 4 Routing header introduces 291 the Compr and Pad fields to allow compaction of the Address[1..n] 292 vector when all entries share the same prefix as the IPv6 Destination 293 Address field of the encapsulating datagram. The Compr field 294 indicates the number of prefix octets that are shared with the IPv6 295 Destination Address of the encapsulating header. The shared prefix 296 octets are not carried within the Routing header and each entry in 297 Address[1..n] has size (16 - Compr) octets. When Compr is non-zero, 298 there may exists unused octets between the last entry, Address[n], 299 and the end of the Routing header. The Pad field indicates the 300 number of unused octets that are used for padding. Note that when 301 Compr is 0, Pad MUST be null and carry a value of 0. 303 The Type 4 Routing header MUST NOT specify a path that visits a node 304 more than once. When generating a Type 4 Routing header, the source 305 may not know the mapping between IPv6 addresses and nodes. 306 Minimally, the source MUST ensure that IPv6 Addresses do not appear 307 more than once and the IPv6 Source and Destination addresses of the 308 encapsulating datagram do not appear in the Type 4 Routing header. 310 Multicast addresses MUST NOT appear in a Type 4 Routing header, or in 311 the IPv6 Destination Address field of a datagram carrying a Type 4 312 Routing header. 314 4. RPL Router Behavior 316 4.1. Generating Type 4 Routing Headers 318 To deliver an IPv6 datagram to its destination, a router may need to 319 generate a new Type 4 Routing header and specify a strict source 320 route. Routers MUST use IPv6-in-IPv6 tunneling, as specified in 321 [RFC2473] to include a new Type 4 Routing header in datagrams that 322 are sourced by other nodes. This ensures that the delivered datagram 323 remains unmodified and that ICMPv6 errors generated by a Type 4 324 Routing header are sent back to the router that generated the routing 325 header. 327 Performing IP-in-IP encapsulation may grow the datagram to a size 328 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 329 fragmentation caused by IP-in-IP encapsulation, links within a RPL 330 domain SHOULD be configured with a MTU of at least 1280 + 40 (outer 331 IP header) + RH4_MAX_SIZE (+ additional extension headers or options 332 needed within RPL domain) octets. 334 4.2. Processing Type 4 Routing Headers 336 As specified in [RFC2460], a routing header is not examined or 337 processed until it reaches the node identified in the Destination 338 Address field of the IPv6 header. In that node, dispatching on the 339 Next Header field of the immediately preceding header causes the 340 Routing header module to be invoked. 342 The function of Type 4 Routing header is intended to be very similar 343 to IPv4's Strict Source and Record Route option [RFC0791]. When 344 processing the Type 4 Routing header, a router MUST drop the packet 345 if the next entry is not on-link and SHOULD send an ICMP Destination 346 Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to 7 (to be 347 confirmed by IANA) to the packet's Source Address. An ICMPv6 Code of 348 7 indicates that the next Address entry is not on-link and the router 349 cannot satisfy the strict source route. When generating ICMPv6 error 350 messages, the rules in Section 2.4 of [RFC4443] must be observed. 352 To detect loops in the Type 4 Routing headers, a router MUST 353 determine if the Type 4 Routing header includes more than one address 354 assigned any interface on that router. If such addresses appear more 355 than once, the router MUST drop the packet and SHOULD send an ICMP 356 Parameter Problem, Code 0, to the Source Address. 358 The following describes the algorithm performed when processing a 359 Type 4 Routing header: 361 if Segments Left = 0 { 362 proceed to process the next header in the packet, whose type is 363 identified by the Next Header field in the Routing header 364 } 365 else { 366 compute n, the number of addresses in the Routing header, by 367 n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp) 369 if Segments Left is greater than n { 370 send an ICMP Parameter Problem, Code 0, message to the Source 371 Address, pointing to the Segments Left field, and discard the 372 packet 373 } 374 else { 375 decrement Segments Left by 1; 376 compute i, the index of the next address to be visited in 377 the address vector, by subtracting Segments Left from n 379 if Address[i] or the IPv6 Destination Address is multicast { 380 discard the packet 381 } 382 else if 2 entries in Address[1..n] are assigned to local 383 interface and are separated by an address not assigned 384 to local interface { 385 discard the packet 386 } 387 else if i < n and Address[i] is not on-link { 388 send an ICMP Destination Unreachable, Code 7, message to 389 the Source Address and discard the packet 390 } 391 else { 392 swap the IPv6 Destination Address and Address[i] 394 if the IPv6 Hop Limit is less than or equal to 1 { 395 send an ICMP Time Exceeded -- Hop Limit Exceeded in 396 Transit message to the Source Address and discard the 397 packet 398 } 399 else { 400 decrement the Hop Limit by 1 402 resubmit the packet to the IPv6 module for transmission 403 to the new destination 404 } 405 } 406 } 407 } 409 5. RPL Border Router Behavior 411 RPL Border Routers (referred to as LBRs in 412 [I-D.ietf-roll-terminology]) are responsible for ensuring that a Type 413 4 Routing header is only used within the RPL domain it was created. 415 For datagrams entering the RPL domain, RPL Border Routers MUST drop 416 received datagrams that contain a Type 4 Routing header in the IPv6 417 Extension headers. 419 For datagrams exiting the RPL domain, RPL Border Routers MUST check 420 for a Type 4 Routing header. If Segments Left is 0, the router MUST 421 remove the RH4 header from the datagram and update the IPv6 Payload 422 Length field accordingly. If Segments Left is non-zero, the router 423 MUST drop the datagram. 425 6. Security Considerations 427 6.1. Source Routing Attacks 429 [RFC5095] deprecates the Type 0 Routing header due to a number of 430 significant attacks that are referenced in that document. Such 431 attacks include network discovery, bypassing filtering devices, 432 denial-of-service, and defeating anycast. 434 Because this document specifies that Type 4 Routing headers are only 435 for use within a RPL domain, such attacks cannot be mounted from 436 outside the RPL domain. As described in Section 5, RPL Border 437 Routers MUST drop datagrams entering or exiting the RPL domain that 438 contain a Type 4 Routing header in the IPv6 Extension headers. 440 6.2. ICMPv6 Attacks 442 The generation of ICMPv6 error messages may be used to attempt 443 denial-of-service attacks by sending error-causing Type 4 Routing 444 headers in back-to-back datagrams. An implementation that correctly 445 follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 446 rate limiting mechanism. 448 7. IANA Considerations 450 This document defines a new IPv6 Routing Type of 4 (to be confirmed). 452 This document defines a new ICMPv6 Destination Unreachable Code of 7 453 to indicate that the router does not have the next Address element as 454 a neighbor and could not satisfy the strict source route. 456 8. Protocol Constants 458 RH4_MAX_SIZE 136 460 With a base header size of 8 octets, 136 octets will allow for up to 461 8 16-octet address entries in the Type 4 Routing header. More 462 entries are possible within 136 octets when compression is used. 464 9. Acknowledgements 466 The authors thank Vishwas Manral and Erik Nordmark for their comments 467 and suggestions that helped shape this document. 469 10. References 471 10.1. Normative References 473 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 474 September 1981. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 480 (IPv6) Specification", RFC 2460, December 1998. 482 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 483 IPv6 Specification", RFC 2473, December 1998. 485 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 486 Message Protocol (ICMPv6) for the Internet Protocol 487 Version 6 (IPv6) Specification", RFC 4443, March 2006. 489 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 490 of Type 0 Routing Headers in IPv6", RFC 5095, 491 December 2007. 493 10.2. Informative References 495 [I-D.ietf-roll-rpl] 496 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 497 Protocol for Low power and Lossy Networks", 498 draft-ietf-roll-rpl-10 (work in progress), June 2010. 500 [I-D.ietf-roll-terminology] 501 Vasseur, J., "Terminology in Low power And Lossy 502 Networks", draft-ietf-roll-terminology-03 (work in 503 progress), March 2010. 505 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 506 an On-line Database", RFC 3232, January 2002. 508 Authors' Addresses 510 Jonathan W. Hui 511 Arch Rock Corporation 512 501 2nd St. Ste. 410 513 San Francisco, California 94107 514 USA 516 Phone: +415 692 0828 517 Email: jhui@archrock.com 519 JP Vasseur 520 Cisco Systems, Inc 521 11, Rue Camille Desmoulins 522 Issy Les Moulineaux, 92782 523 France 525 Email: jpv@cisco.com 527 David E. Culler 528 UC Berkeley 529 465 Soda Hall 530 Berkeley, California 94720 531 USA 533 Phone: +510 643 7572 534 Email: culler@cs.berkeley.edu