idnits 2.17.1 draft-ietf-6man-rpl-routing-header-05.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 (November 15, 2011) is 4546 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 (-13) exists of draft-ietf-roll-terminology-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN J. Hui 3 Internet-Draft JP. Vasseur 4 Intended status: Standards Track Cisco Systems, Inc 5 Expires: May 18, 2012 D. Culler 6 UC Berkeley 7 V. Manral 8 Hewlett Packard Co. 9 November 15, 2011 11 An IPv6 Routing Header for Source Routes with RPL 12 draft-ietf-6man-rpl-routing-header-05 14 Abstract 16 In Low power and Lossy Networks (LLNs), memory constraints on routers 17 may limit them to maintaining at most a few routes. In some 18 configurations, it is necessary to use these memory constrained 19 routers to deliver datagrams to nodes within the LLN. The Routing 20 for Low Power and Lossy Networks (RPL) protocol can be used in some 21 deployments to store most, if not all, routes on one (e.g. the 22 Directed Acyclic Graph (DAG) root) or few routers and forward the 23 IPv6 datagram using a source routing technique to avoid large routing 24 tables on memory constrained routers. This document specifies a new 25 IPv6 Routing header type for delivering datagrams within a RPL 26 Instance. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 18, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Format of the RPL Routing Header . . . . . . . . . . . . . . . 7 66 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Generating Source Routing Headers . . . . . . . . . . . . 9 68 4.2. Processing Source Routing Headers . . . . . . . . . . . . 9 69 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 6.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 13 72 6.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 75 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 Routing for Low Power and Lossy Networks (RPL) is a distance vector 84 IPv6 routing protocol designed for Low Power and Lossy networks (LLN) 85 [I-D.ietf-roll-rpl]. Such networks are typically constrained in 86 resources (limited communication data rate, processing power, energy 87 capacity, memory). In particular, some LLN configurations may 88 utilize LLN routers where memory constraints limit nodes to 89 maintaining only a small number of default routes and no other 90 destinations. However, it may be necessary to utilize such memory- 91 constrained routers to forward datagrams and maintain reachability to 92 destinations within the LLN. 94 To utilize paths that include memory-constrained routers, RPL relies 95 on source routing. In one deployment model of RPL, necessary 96 mechanisms are used to collect routing information at more capable 97 routers and form paths from those routers to arbitrary destinations 98 within a RPL Instance. However, a source routing mechanism supported 99 by IPv6 is needed to deliver datagrams. 101 This document specifies the Source Routing Header (SRH) for use 102 strictly between RPL routers in the same RPL Instance. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Overview 112 The format of SRH draws from that of the Type 0 Routing header (RH0) 113 [RFC2460]. However, SRH introduces mechanisms to compact the source 114 route entries when all entries share the same prefix with the IPv6 115 Destination Address of a packet carrying a SRH, a typical scenario in 116 LLNs using source routing. The compaction mechanism reduces 117 consumption of scarce resources such as channel capacity. 119 SRH also differs from RH0 in the processing rules to alleviate 120 security concerns that led to the deprecation of RH0 [RFC5095]. 121 First, RPL routers implement a strict source route policy where each 122 and every IPv6 hop is specified within the SRH. Second, a SRH is 123 only used between RPL routers within a RPL Instance. RPL Border 124 Routers, responsible for connecting other RPL Instances and IP 125 domains that use other routing protocols, do not allow datagrams 126 already carrying a SRH header to enter or exit a RPL Instance. 127 Third, a RPL router drops datagrams that includes multiple addresses 128 assigned to any interfaces on that router to avoid forwarding loops. 130 There are two cases that determine how to include a SRH when a RPL 131 router requires the use of a SRH to deliver a datagram to its 132 destination. 134 1. If the SRH specifies the complete path from source to 135 destination, the router places the SRH directly in the datagram 136 itself. 138 2. If the SRH only specifies a subset of the path from source to 139 destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and 140 places the SRH in the outer IPv6 header. Use of tunneling 141 ensures that the datagram is delivered unmodified and that ICMP 142 errors return to the source of the SRH rather than the source of 143 the original datagram. 145 In a RPL network, Case 1 occurs when both source and destinations are 146 within a RPL Instance and a single SRH is used to specify the entire 147 path from source to destination, as shown in the following figure: 149 +--------------------+ 150 | | 151 | (S) -------> (D) | 152 | | 153 +--------------------+ 154 RPL Instance 156 In the above scenario, datagrams traveling from source, S, to 157 destination, D, have the following packet structure: 159 +--------+---------+-------------//-+ 160 | IPv6 | Source | IPv6 | 161 | Header | Routing | Payload | 162 | | Header | | 163 +--------+---------+-------------//-+ 165 S's address is carried in the IPv6 Header's Source Address field. 166 D's address is carried in the last entry of SRH for all but the last 167 hop, when D's address is carried in the IPv6 Header's Destination 168 Address field of the packet carrying the SRH. 170 In a RPL network, Case 2 occurs for all datagrams that have either 171 source or destination outside the RPL Instance, as shown in the 172 following diagram: 174 +-----------------+ 175 | | 176 | (S) -------> (BR1) -------> (D) 177 | | 178 +-----------------+ 179 RPL Instance 181 +-----------------+ 182 | | 183 | (D) <------- (BR1) <------- (S) 184 | | 185 +-----------------+ 186 RPL Instance 188 In the above scenario, datagrams that include the SRH in tunneled 189 mode have the following packet structure when traveling within the 190 RPL Instance: 192 +--------+---------+--------+-------------//-+ 193 | Outer | Source | Inner | IPv6 | 194 | IPv6 | Routing | IPv6 | Payload | 195 | Header | Header | Header | | 196 +--------+---------+--------+-------------//-+ 197 <--- Original Packet ---> 198 <--- Tunneled Packet ---> 200 Note that the outer header (including the SRH) is added and removed 201 by the RPL Border Router. 203 Case 2 also occurs whenever a RPL router needs to insert a source 204 route when forwarding datagram. One such use case with RPL is to 205 have all RPL traffic flow through a Border Router and have the Border 206 Router use source routes to deliver datagrams to their final 207 destination. When including the SRH using tunneled mode, the Border 208 Router would encapsulate the received datagram unmodified using IPv6- 209 in-IPv6 and include a SRH in the outer IPv6 header. 211 +-----------------+ 212 | | 213 | (S) -------\ | 214 | \ | 215 | (BR1) 216 | / | 217 | (D) <------/ | 218 | | 219 +-----------------+ 220 RPL Domain 222 In the above scenario, datagrams travel from S to D through BR1. 223 Between S and BR1, the datagrams are routed using the DAG built by 224 RPL and do not contain a SRH. BR1 encapsulates received datagrams 225 unmodified using IPv6-in-IPv6 and the SRH is included in the outer 226 IPv6 header. 228 3. Format of the RPL Routing Header 230 The Source Routing Header has the following format: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | CmprI | CmprE | Pad | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 . . 241 . Addresses[1..n] . 242 . . 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Next Header 8-bit selector. Identifies the type of header 247 immediately following the Routing header. Uses 248 the same values as the IPv4 Protocol field 249 [RFC3232]. 251 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 252 header in 8-octet units, not including the first 253 8 octets. Note that when Addresses[1..n] are 254 compressed (i.e. value of CmprI or CmprE is not 255 0), Hdr Ext Len does not equal twice the number 256 of Addresses. 258 Routing Type 8-bit selector. TBD by IANA. 260 Segments Left 8-bit unsigned integer. Number of route segments 261 remaining, i.e., number of explicitly listed 262 intermediate nodes still to be visited before 263 reaching the final destination. 265 CmprI 4-bit unsigned integer. Number of prefix octets 266 from each segment, except than the last segment, 267 (i.e. segments 1 through n-1) that are elided. 268 For example, a SRH carrying full IPv6 addresses 269 in Addresses[1..n-1] sets CmprI to 0. 271 CmprE 4-bit unsigned integer. Number of prefix octets 272 from the last segment (i.e. segment n) that are 273 elided. For example, a SRH carrying a full IPv6 274 address in Addresses[n] sets CmprE to 0. 276 Pad 4-bit unsigned integer. Number of octets that 277 are used for padding after Address[n] at the end 278 of the SRH. 280 Address[1..n] Vector of addresses, numbered 1 to n. Each 281 vector element in [1..n-1] has size (16 - CmprI) 282 and element [n] has size (16-CmprE). 284 The SRH shares the same basic format as the Type 0 Routing header 285 [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and 286 Pad fields are set to 0 and the only difference between the SRH and 287 Type 0 encodings is the value of the Routing Type field. 289 A common network configuration for a RPL Instance is that all routers 290 within a RPL Instance share a common prefix. The SRH introduces the 291 CmprI, CmprE, 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 packet carrying the SRH. The CmprI and CmprE 294 field indicates the number of prefix octets that are shared with the 295 IPv6 Destination Address of the packet carrying the SRH. The shared 296 prefix octets are not carried within the Routing header and each 297 entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] 298 has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there 299 may exist unused octets between the last entry, Address[n], and the 300 end of the Routing header. The Pad field indicates the number of 301 unused octets that are used for padding. Note that when CmprI and 302 CmprE are both 0, Pad MUST carry a value of 0. 304 The SRH MUST NOT specify a path that visits a node more than once. 305 When generating a SRH, the source may not know the mapping between 306 IPv6 addresses and nodes. Minimally, the source MUST ensure that 307 IPv6 Addresses do not appear more than once and the IPv6 Source and 308 Destination addresses of the encapsulating datagram do not appear in 309 the SRH. 311 Multicast addresses MUST NOT appear in a SRH, or in the IPv6 312 Destination Address field of a datagram carrying a SRH. 314 4. RPL Router Behavior 316 4.1. Generating Source Routing Headers 318 To deliver an IPv6 datagram to its destination, a router may need to 319 generate a new SRH and specify a strict source route. When the 320 router is the source of the original packet and the destination is 321 known to be within the same RPL Instance, the router SHOULD include 322 the SRH directly within the original packet. Otherwise, the router 323 MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in the 324 tunnel header. Using IPv6-in-IPv6 tunneling ensures that the 325 delivered datagram remains unmodified and that ICMPv6 errors 326 generated by a SRH are sent back to the router that generated the 327 routing header. 329 To avoid fragmentation, it is desirable to employ MTU sizes that 330 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 331 header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path 332 length for a given RPL network. To take advantage of this, however, 333 the communicating endpoints need to be aware of the MTU along the 334 path (i.e. through Path MTU Discovery). Unfortunately, the larger 335 MTU size may not be available on all links (e.g. 1280 octets on 336 6LoWPAN links). However, it is expected that much of the traffic on 337 these types of networks consists of much smaller messages than the 338 MTU, so performance degradation through fragmentation would be 339 limited. 341 4.2. Processing Source Routing Headers 343 As specified in [RFC2460], a routing header is not examined or 344 processed until it reaches the node identified in the Destination 345 Address field of the IPv6 header. In that node, dispatching on the 346 Next Header field of the immediately preceding header causes the 347 Routing header module to be invoked. 349 The function of SRH is intended to be very similar to IPv4's Strict 350 Source and Record Route option [RFC0791]. After the routing header 351 has been processed and the IPv6 datagram resubmitted to the IPv6 352 module for processing, the IPv6 Destination Address contains the next 353 hop's address. When forwarding an IPv6 datagram that contains a SRH 354 with a non-zero Segments Left value, if the IPv6 Destination Address 355 is not on-link, a router SHOULD send an ICMP Destination Unreachable 356 (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the 357 packet's Source Address. This ICMPv6 Code indicates that the IPv6 358 Destination Address is not on-link and the router cannot satisfy the 359 strict source route requirement. When generating ICMPv6 error 360 messages, the rules in Section 2.4 of [RFC4443] must be observed. 362 To detect loops in the SRH, a router MUST determine if the SRH 363 includes multiple addresses assigned to any interface on that router. 364 If such addresses appear more than once and are separated by at least 365 one address not assigned to that router, the router MUST drop the 366 packet and SHOULD send an ICMP Parameter Problem, Code 0, to the 367 Source Address. While this loop check does add significant per- 368 packet processing overhead, it is required to mitigate traffic 369 amplification attacks that led to the deprecation of RH0 [RFC5095]. 371 The following describes the algorithm performed when processing a 372 SRH: 374 if Segments Left = 0 { 375 proceed to process the next header in the packet, whose type is 376 identified by the Next Header field in the Routing header 377 } 378 else { 379 compute n, the number of addresses in the Routing header, by 380 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 382 if Segments Left is greater than n { 383 send an ICMP Parameter Problem, Code 0, message to the Source 384 Address, pointing to the Segments Left field, and discard the 385 packet 386 } 387 else { 388 decrement Segments Left by 1 390 compute i, the index of the next address to be visited in 391 the address vector, by subtracting Segments Left from n 393 if Address[i] or the IPv6 Destination Address is multicast { 394 discard the packet 395 } 396 else if 2 or more entries in Address[1..n] are assigned to 397 local interface and are separated by at least one 398 address not assigned to local interface { 399 send an ICMP Parameter Problem (Code 0) and discard the 400 packet 401 } 402 else { 403 swap the IPv6 Destination Address and Address[i] 405 if the IPv6 Hop Limit is less than or equal to 1 { 406 send an ICMP Time Exceeded -- Hop Limit Exceeded in 407 Transit message to the Source Address and discard the 408 packet 409 } 410 else { 411 decrement the Hop Limit by 1 413 resubmit the packet to the IPv6 module for transmission 414 to the new destination 415 } 416 } 417 } 418 } 420 5. RPL Border Router Behavior 422 RPL Border Routers (referred to as LBRs in 423 [I-D.ietf-roll-terminology]) are responsible for ensuring that a SRH 424 is only used within the RPL Instance it was created. 426 For datagrams destined to the RPL Border Router, the router processes 427 the packet in the usual way. For instance, if the SRH was included 428 using tunneled mode and the RPL Border Router serves as the tunnel 429 endpoint, the router removes the outer IPv6 header, at the same time 430 removing the SRH as well. 432 Datagrams destined elsewhere within the same RPL Instance are 433 forwarded to the correct interface. 435 Datagrams destined to nodes outside the RPL Instance are dropped if 436 the outer-most IPv6 header contains a SRH. 438 6. Security Considerations 440 6.1. Source Routing Attacks 442 [RFC5095] deprecates the Type 0 Routing header due to a number of 443 significant attacks that are referenced in that document. Such 444 attacks include network discovery, bypassing filtering devices, 445 denial-of-service, and defeating anycast. 447 Because this document specifies that SRH is only for use within a RPL 448 Instance, such attacks cannot be mounted from outside a RPL Instance. 449 As described in Section 5, RPL Border Routers MUST drop datagrams 450 entering or exiting a RPL Instance that contain a SRH in the IPv6 451 Extension headers. 453 6.2. ICMPv6 Attacks 455 The generation of ICMPv6 error messages may be used to attempt 456 denial-of-service attacks by sending error-causing SRH in back-to- 457 back datagrams. An implementation that correctly follows Section 2.4 458 of [RFC4443] would be protected by the ICMPv6 rate limiting 459 mechanism. 461 7. IANA Considerations 463 This document defines a new IPv6 Routing Type of TBD by IANA. 465 This document defines a new ICMPv6 Destination Unreachable Code of 466 TBD by IANA to indicate that the router cannot satisfy the strict 467 source-route requirement. 469 8. Acknowledgements 471 The authors thank Jari Arkko, Richard Kelsey, Suresh Krishnan, Erik 472 Nordmark, Pascal Thubert, and Tim Winter for their comments and 473 suggestions that helped shape this document. 475 9. Changes 477 (This section to be removed by the RFC editor.) 479 Draft 05: 481 - Address LC comments. 483 Draft 04: 485 - Updated text on recommendations for avoiding fragmentation. 487 - Clarify definition of CmprE where it is first mentioned. 489 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 491 - Update packet processing pseudocode to match the text on sending 492 back a parameter problem error. 494 - Recommend that non-RPL devices drop packets with SRH by default. 496 - Clarify packet structure figures. 498 - State that checking for cycles represents significant per-packet 499 processing. 501 Draft 03: 503 - Removed any presumed values that are TBD by IANA. 505 Draft 02: 507 - Updated to send ICMP Destination Unreachable error only after 508 the SRH has been processed. 510 - Updated pseudocode to reflect encoding changes in draft-01. 512 - Allow multiple addresses assigned to same node as long as they 513 are not separated by other addresses. 515 Draft 01: 517 - Allow Addresses[1..n-1] and Addresses[n] to have a different 518 number of bytes elided. 520 10. References 522 10.1. Normative References 524 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 525 September 1981. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 531 (IPv6) Specification", RFC 2460, December 1998. 533 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 534 IPv6 Specification", RFC 2473, December 1998. 536 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 537 Message Protocol (ICMPv6) for the Internet Protocol 538 Version 6 (IPv6) Specification", RFC 4443, March 2006. 540 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 541 of Type 0 Routing Headers in IPv6", RFC 5095, 542 December 2007. 544 10.2. Informative References 546 [I-D.ietf-roll-rpl] 547 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 548 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 549 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 550 Lossy Networks", draft-ietf-roll-rpl-19 (work in 551 progress), March 2011. 553 [I-D.ietf-roll-terminology] 554 Vasseur, J., "Terminology in Low power And Lossy 555 Networks", draft-ietf-roll-terminology-06 (work in 556 progress), September 2011. 558 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 559 an On-line Database", RFC 3232, January 2002. 561 Authors' Addresses 563 Jonathan W. Hui 564 Cisco Systems, Inc 565 170 West Tasman Drive 566 San Jose, California 95134 567 USA 569 Phone: +408 424 1547 570 Email: jonhui@cisco.com 572 JP Vasseur 573 Cisco Systems, Inc 574 11, Rue Camille Desmoulins 575 Issy Les Moulineaux, 92782 576 France 578 Email: jpv@cisco.com 580 David E. Culler 581 UC Berkeley 582 465 Soda Hall 583 Berkeley, California 94720 584 USA 586 Phone: +510 643 7572 587 Email: culler@cs.berkeley.edu 589 Vishwas Manral 590 Hewlett Packard Co. 591 19111 Pruneridge Ave. 592 Cupertino, California 95014 593 USA 595 Email: vishwas.manral@hp.com