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