idnits 2.17.1 draft-ietf-6man-rpl-routing-header-06.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 (December 14, 2011) is 4516 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) -- Looks like a reference, but probably isn't: '1' on line 305 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: June 16, 2012 D. Culler 6 UC Berkeley 7 V. Manral 8 Hewlett Packard Co. 9 December 14, 2011 11 An IPv6 Routing Header for Source Routes with RPL 12 draft-ietf-6man-rpl-routing-header-06 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 June 16, 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 . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Generating Source Routing Headers . . . . . . . . . . . . 10 68 4.2. Processing Source Routing Headers . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 5.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 14 71 5.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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, more capable 95 routers collect routing information and form paths to arbitrary 96 destinations within a RPL Instance. However, a source routing 97 mechanism supported by IPv6 is needed to deliver datagrams. 99 This document specifies the Source Routing Header (SRH) for use 100 strictly between RPL routers in the same RPL Instance. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Overview 110 The format of SRH draws from that of the Type 0 Routing header (RH0) 111 [RFC2460]. However, SRH introduces mechanisms to compact the source 112 route entries when all entries share the same prefix with the IPv6 113 Destination Address of a packet carrying a SRH, a typical scenario in 114 LLNs using source routing. The compaction mechanism reduces 115 consumption of scarce resources such as channel capacity. 117 SRH also differs from RH0 in the processing rules to alleviate 118 security concerns that led to the deprecation of RH0 [RFC5095]. 119 First, RPL routers implement a strict source route policy where each 120 and every IPv6 hop between the source and destination of the source 121 route is specified within the SRH. Note that the source route may be 122 a subset of the path between the actual source and destination and is 123 discussed further below. Second, a SRH is only used between RPL 124 routers within a RPL Instance. RPL Border Routers, responsible for 125 connecting other RPL Instances and IP domains that use other routing 126 protocols, do not allow datagrams already carrying a SRH header to 127 enter or exit a RPL Instance. Third, a RPL router drops datagrams 128 that includes multiple addresses assigned to any interfaces on that 129 router to avoid forwarding loops. 131 There are two cases that determine how to include a SRH when a RPL 132 router requires the use of a SRH to deliver a datagram to its 133 destination. 135 1. If the SRH specifies the complete path from source to 136 destination, the router places the SRH directly in the datagram 137 itself. 139 2. If the SRH only specifies a subset of the path from source to 140 destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and 141 places the SRH in the outer IPv6 header. Use of tunneling 142 ensures that the datagram is delivered unmodified and that ICMP 143 errors return to the source of the SRH rather than the source of 144 the original datagram. 146 In a RPL network, Case 1 occurs when both source and destinations are 147 within a RPL Instance and a single SRH is used to specify the entire 148 path from source to destination, as shown in the following figure: 150 +--------------------+ 151 | | 152 | (S) -------> (D) | 153 | | 154 +--------------------+ 155 RPL Instance 157 In the above scenario, datagrams traveling from source, S, to 158 destination, D, have the following packet structure: 160 +--------+---------+-------------//-+ 161 | IPv6 | Source | IPv6 | 162 | Header | Routing | Payload | 163 | | Header | | 164 +--------+---------+-------------//-+ 166 S's address is carried in the IPv6 Header's Source Address field. 167 D's address is carried in the last entry of SRH for all but the last 168 hop, when D's address is carried in the IPv6 Header's Destination 169 Address field of the packet carrying the SRH. 171 In a RPL network, Case 2 occurs for all datagrams that have source 172 and/or destination outside the RPL Instance, as shown in the 173 following diagram: 175 +-----------------+ 176 | | 177 | (S) --------> (R) --------> (D) 178 | | 179 +-----------------+ 180 RPL Instance 182 +-----------------+ 183 | | 184 (S) --------> (R) --------> (D) | 185 | | 186 +-----------------+ 187 RPL Instance 189 +-----------------+ 190 | | 191 (S) --------> (R) ------------> (R) --------> (D) 192 | | 193 +-----------------+ 194 RPL Instance 196 In the scenarios above, R may indicate a RPL Border Router (when 197 connecting to other routing domains) or a RPL Router (when connecting 198 to hosts). The datagrams have the following structure when traveling 199 within the RPL Instance: 201 +--------+---------+--------+-------------//-+ 202 | Outer | Source | Inner | IPv6 | 203 | IPv6 | Routing | IPv6 | Payload | 204 | Header | Header | Header | | 205 +--------+---------+--------+-------------//-+ 206 <--- Original Packet ---> 207 <--- Tunneled Packet ---> 209 Note that the outer header (including the SRH) is added and removed 210 by the RPL router. 212 Case 2 also occurs whenever a RPL router needs to insert a source 213 route when forwarding datagram. One such use case with RPL is to 214 have all RPL traffic flow through a Border Router and have the Border 215 Router use source routes to deliver datagrams to their final 216 destination. When including the SRH using tunneled mode, the Border 217 Router would encapsulate the received datagram unmodified using IPv6- 218 in-IPv6 and include a SRH in the outer IPv6 header. 220 +-----------------+ 221 | | 222 | (S) -------\ | 223 | \ | 224 | (LBR) 225 | / | 226 | (D) <------/ | 227 | | 228 +-----------------+ 229 RPL Instance 231 In the above scenario, datagrams travel from S to D through LBR. 232 Between S and LBR, the datagrams are routed using the DAG built by 233 RPL and do not contain a SRH. LBR encapsulates received datagrams 234 unmodified using IPv6-in-IPv6 and the SRH is included in the outer 235 IPv6 header. 237 3. Format of the RPL Routing Header 239 The Source Routing Header has the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | CmprI | CmprE | Pad | Reserved | RPLInstanceID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 . . 250 . Addresses[1..n] . 251 . . 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Next Header 8-bit selector. Identifies the type of header 256 immediately following the Routing header. Uses 257 the same values as the IPv6 Next Header field 258 [RFC2460]. 260 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 261 header in 8-octet units, not including the first 262 8 octets. Note that when Addresses[1..n] are 263 compressed (i.e. value of CmprI or CmprE is not 264 0), Hdr Ext Len does not equal twice the number 265 of Addresses. 267 Routing Type 8-bit selector. Identifies the particular 268 Routing header variant. A SRH should set the 269 Routing Type to TBD by IANA. 271 Segments Left 8-bit unsigned integer. Number of route segments 272 remaining, i.e., number of explicitly listed 273 intermediate nodes still to be visited before 274 reaching the final destination. The originator 275 of a SRH sets this field to n, the number of 276 addresses contained in Addresses[1..n]. 278 CmprI 4-bit unsigned integer. Number of prefix octets 279 from each segment, except than the last segment, 280 (i.e. segments 1 through n-1) that are elided. 281 For example, a SRH carrying full IPv6 addresses 282 in Addresses[1..n-1] sets CmprI to 0. 284 CmprE 4-bit unsigned integer. Number of prefix octets 285 from the last segment (i.e. segment n) that are 286 elided. For example, a SRH carrying a full IPv6 287 address in Addresses[n] sets CmprE to 0. 289 Pad 4-bit unsigned integer. Number of octets that 290 are used for padding after Address[n] at the end 291 of the SRH. 293 Reserved This field is unused. It MUST be initialized to 294 zero by the sender and MUST be ignored by the 295 receiver. 297 RPLInstanceID 8-bit unsigned integer. Indicates the RPL 298 Instance along which the packet is sent. 300 Address[1..n] Vector of addresses, numbered 1 to n. Each 301 vector element in [1..n-1] has size (16 - CmprI) 302 and element [n] has size (16-CmprE). The 303 originator of a SRH places the next-hop's IPv6 304 address as the first address in Address[1..n] 305 (i.e. Address[1]). 307 The SRH shares the same basic format as the Type 0 Routing header 308 [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and 309 Pad fields are set to 0 and the only difference between the SRH and 310 Type 0 encodings is the value of the Routing Type field. 312 A common network configuration for a RPL Instance is that all routers 313 within a RPL Instance share a common prefix. The SRH introduces the 314 CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n] 315 vector when all entries share the same prefix as the IPv6 Destination 316 Address field of the packet carrying the SRH. The CmprI and CmprE 317 field indicates the number of prefix octets that are shared with the 318 IPv6 Destination Address of the packet carrying the SRH. The shared 319 prefix octets are not carried within the Routing header and each 320 entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] 321 has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there 322 may exist unused octets between the last entry, Address[n], and the 323 end of the Routing header. The Pad field indicates the number of 324 unused octets that are used for padding. Note that when CmprI and 325 CmprE are both 0, Pad MUST carry a value of 0. 327 The SRH MUST NOT specify a path that visits a node more than once. 328 When generating a SRH, the source may not know the mapping between 329 IPv6 addresses and nodes. Minimally, the source MUST ensure that 330 IPv6 Addresses do not appear more than once and the IPv6 Source and 331 Destination addresses of the encapsulating datagram do not appear in 332 the SRH. 334 Multicast addresses MUST NOT appear in a SRH, or in the IPv6 335 Destination Address field of a datagram carrying a SRH. 337 4. RPL Router Behavior 339 4.1. Generating Source Routing Headers 341 To deliver an IPv6 datagram to its destination, a router may need to 342 generate a new SRH and specify a strict source route. When the 343 router is the source of the original packet and the destination is 344 known to be within the same RPL Instance, the router SHOULD include 345 the SRH directly within the original packet. Otherwise, the router 346 MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in the 347 tunnel header. Using IPv6-in-IPv6 tunneling ensures that the 348 delivered datagram remains unmodified and that ICMPv6 errors 349 generated by a SRH are sent back to the router that generated the 350 SRH. 352 In order to respect the IPv6 Hop Limit value of the original 353 datagram, a RPL router generating an SRH MUST set the Segments Left 354 to no greater than the IPv6 Hop Limit value of the original datagram 355 upon forwarding. If the RPL router is not the source of the original 356 datagram, the IPv6 Hop Limit field is decremented before genearting 357 the SRH. After generating the SRH, the RPL router decrements the 358 original datagram's IPv6 Hop Limit value by the SRH Segments Left 359 value. Processing the SRH Segments Left and IPv6 Hop Limit fields in 360 this way ensures that ICMPv6 Time Exceeded errors occur as expected 361 on more traditional IPv6 networks that forward datagrams without 362 tunneling. 364 To avoid fragmentation, it is desirable to employ MTU sizes that 365 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 366 header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path 367 length for a given RPL network. To take advantage of this, however, 368 the communicating endpoints need to be aware of the MTU along the 369 path (i.e. through Path MTU Discovery). Unfortunately, the larger 370 MTU size may not be available on all links (e.g. 1280 octets on 371 6LoWPAN links). However, it is expected that much of the traffic on 372 these types of networks consists of much smaller messages than the 373 MTU, so performance degradation through fragmentation would be 374 limited. 376 4.2. Processing Source Routing Headers 378 As specified in [RFC2460], a routing header is not examined or 379 processed until it reaches the node identified in the Destination 380 Address field of the IPv6 header. In that node, dispatching on the 381 Next Header field of the immediately preceding header causes the 382 Routing header module to be invoked. 384 The function of SRH is intended to be very similar to the Type 0 385 Routing Header defined in [RFC2460]. After the routing header has 386 been processed and the IPv6 datagram resubmitted to the IPv6 module 387 for processing, the IPv6 Destination Address contains the next hop's 388 address. When forwarding an IPv6 datagram that contains a SRH with a 389 non-zero Segments Left value, if the IPv6 Destination Address is not 390 on-link, a router SHOULD send an ICMP Destination Unreachable (ICMPv6 391 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the packet's 392 Source Address. This ICMPv6 Code indicates that the IPv6 Destination 393 Address is not on-link and the router cannot satisfy the strict 394 source route requirement. When generating ICMPv6 error messages, the 395 rules in Section 2.4 of [RFC4443] must be observed. 397 To detect loops in the SRH, a router MUST determine if the SRH 398 includes multiple addresses assigned to any interface on that router. 399 If such addresses appear more than once and are separated by at least 400 one address not assigned to that router, the router MUST drop the 401 packet and SHOULD send an ICMP Parameter Problem, Code 0, to the 402 Source Address. While this loop check does add significant per- 403 packet processing overhead, it is required to mitigate bandwidth 404 exhaustion attacks that led to the deprecation of RH0 [RFC5095]. 406 The following describes the algorithm performed when processing a 407 SRH: 409 if Segments Left = 0 { 410 proceed to process the next header in the packet, whose type is 411 identified by the Next Header field in the Routing header 412 } 413 else { 414 compute n, the number of addresses in the Routing header, by 415 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 417 if Segments Left is greater than n { 418 send an ICMP Parameter Problem, Code 0, message to the Source 419 Address, pointing to the Segments Left field, and discard the 420 packet 421 } 422 else { 423 decrement Segments Left by 1 425 compute i, the index of the next address to be visited in 426 the address vector, by subtracting Segments Left from n 428 if Address[i] or the IPv6 Destination Address is multicast { 429 discard the packet 430 } 431 else if 2 or more entries in Address[1..n] are assigned to 432 local interface and are separated by at least one 433 address not assigned to local interface { 434 send an ICMP Parameter Problem (Code 0) and discard the 435 packet 436 } 437 else { 438 swap the IPv6 Destination Address and Address[i] 440 if the IPv6 Hop Limit is less than or equal to 1 { 441 send an ICMP Time Exceeded -- Hop Limit Exceeded in 442 Transit message to the Source Address and discard the 443 packet 444 } 445 else { 446 decrement the Hop Limit by 1 448 resubmit the packet to the IPv6 module for transmission 449 to the new destination 450 } 451 } 452 } 453 } 455 RPL routers are responsible for ensuring that a SRH is only used 456 between RPL routers: 458 1. For datagrams destined to a RPL router, the router processes the 459 packet in the usual way. For instance, if the SRH was included 460 using tunneled mode and the RPL router serves as the tunnel 461 endpoint, the router removes the outer IPv6 header, at the same 462 time removing the SRH as well. 464 2. Datagrams destined elsewhere within the same RPL Instance are 465 forwarded to the correct interface. 467 3. Datagrams destined to nodes outside the RPL Instance are dropped 468 if the outer-most IPv6 header contains a SRH not generated by the 469 RPL router forwarding the datagram. 471 5. Security Considerations 473 5.1. Source Routing Attacks 475 The RPL message security mechanisms defined in [I-D.ietf-roll-rpl] do 476 not apply to the RPL Source Route Header. This specification does 477 not provide any confidentiality, integrity, or authenticity 478 mechanisms to protect the SRH. 480 [RFC5095] deprecates the Type 0 Routing header due to a number of 481 significant attacks that are referenced in that document. Such 482 attacks include bypassing filtering devices, reaching otherwise 483 unreachable Internet systems, network topology discovery, bandwidth 484 exhaustion, and defeating anycast. 486 Because this document specifies that SRH is only for use within a RPL 487 Instance, such attacks cannot be mounted from outside a RPL Instance. 488 As specified in this document, RPL routers MUST drop datagrams 489 entering or exiting a RPL Instance that contain a SRH in the IPv6 490 Extension headers. 492 Such attacks, however, can be mounted from within a RPL Instance. To 493 mitigate bandwidth exchaustion attacks, this specification requires 494 RPL routers to check for loops in the SRH and drop datagrams that 495 contain such loops. Attacks that include bypassing filtering devices 496 and reaching otherwise unreachable Internet systems are not as 497 relevant in mesh networks since the topologies are, by their very 498 nature, highly dynamic. The RPL routing protocol is designed to 499 provide reachability to all devices within a RPL Instance and may 500 utilize routes that traverse any number of devices in any order. 501 Even so, these attacks and others (e.g. defeating anycast and routing 502 topology discovery) can occur within a RPL Instance when using this 503 specification. 505 5.2. ICMPv6 Attacks 507 The generation of ICMPv6 error messages may be used to attempt 508 denial-of-service attacks by sending error-causing SRH in back-to- 509 back datagrams. An implementation that correctly follows Section 2.4 510 of [RFC4443] would be protected by the ICMPv6 rate limiting 511 mechanism. 513 6. IANA Considerations 515 This document defines a new IPv6 Routing Type, the "RPL Source Route 516 Header", and hass been assigned assigned number TBD by IANA. 518 This document defines a new ICMPv6 Destination Unreachable Code, the 519 "strict source route failed" error, and has been assigned number TBD 520 by IANA. 522 7. Acknowledgements 524 The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen 525 Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal 526 Thubert, Sean Turner, and Tim Winter for their comments and 527 suggestions that helped shape this document. 529 8. Changes 531 (This section to be removed by the RFC editor.) 533 Draft 06: 535 - Address IESG comments. 537 Draft 05: 539 - Address LC comments. 541 Draft 04: 543 - Updated text on recommendations for avoiding fragmentation. 545 - Clarify definition of CmprE where it is first mentioned. 547 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 549 - Update packet processing pseudocode to match the text on sending 550 back a parameter problem error. 552 - Recommend that non-RPL devices drop packets with SRH by default. 554 - Clarify packet structure figures. 556 - State that checking for cycles represents significant per-packet 557 processing. 559 Draft 03: 561 - Removed any presumed values that are TBD by IANA. 563 Draft 02: 565 - Updated to send ICMP Destination Unreachable error only after 566 the SRH has been processed. 568 - Updated pseudocode to reflect encoding changes in draft-01. 570 - Allow multiple addresses assigned to same node as long as they 571 are not separated by other addresses. 573 Draft 01: 575 - Allow Addresses[1..n-1] and Addresses[n] to have a different 576 number of bytes elided. 578 9. References 580 9.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 586 (IPv6) Specification", RFC 2460, December 1998. 588 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 589 IPv6 Specification", RFC 2473, December 1998. 591 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 592 Message Protocol (ICMPv6) for the Internet Protocol 593 Version 6 (IPv6) Specification", RFC 4443, March 2006. 595 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 596 of Type 0 Routing Headers in IPv6", RFC 5095, 597 December 2007. 599 9.2. Informative References 601 [I-D.ietf-roll-rpl] 602 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 603 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 604 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 605 Lossy Networks", draft-ietf-roll-rpl-19 (work in 606 progress), March 2011. 608 Authors' Addresses 610 Jonathan W. Hui 611 Cisco Systems, Inc 612 170 West Tasman Drive 613 San Jose, California 95134 614 USA 616 Phone: +408 424 1547 617 Email: jonhui@cisco.com 619 JP Vasseur 620 Cisco Systems, Inc 621 11, Rue Camille Desmoulins 622 Issy Les Moulineaux, 92782 623 France 625 Email: jpv@cisco.com 627 David E. Culler 628 UC Berkeley 629 465 Soda Hall 630 Berkeley, California 94720 631 USA 633 Phone: +510 643 7572 634 Email: culler@cs.berkeley.edu 636 Vishwas Manral 637 Hewlett Packard Co. 638 19111 Pruneridge Ave. 639 Cupertino, California 95014 640 USA 642 Email: vishwas.manral@hp.com