idnits 2.17.1 draft-ietf-6man-rpl-routing-header-07.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 16, 2011) is 4508 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 18, 2012 D. Culler 6 UC Berkeley 7 V. Manral 8 Hewlett Packard Co. 9 December 16, 2011 11 An IPv6 Routing Header for Source Routes with RPL 12 draft-ietf-6man-rpl-routing-header-07 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 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 . . . . . . . . . . . . . . . . . . . . . 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 original datagram's IPv6 Hop Limit value upon 355 forwarding. In the case that the source route is longer than the 356 original datagram's IPv6 Hop Limit, only the initial hops (determined 357 by the original datagram's IPv6 Hop Limit) should be included in the 358 SRH. If the RPL router is not the source of the original datagram, 359 the original datagram's IPv6 Hop Limit field is decremented before 360 generating the SRH. After generating the SRH, the RPL router 361 decrements the original datagram's IPv6 Hop Limit value by the SRH 362 Segments Left value. Processing the SRH Segments Left and original 363 datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time 364 Exceeded errors occur as would be expected on more traditional IPv6 365 networks that forward datagrams without tunneling. 367 To avoid fragmentation, it is desirable to employ MTU sizes that 368 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 369 header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path 370 length for a given RPL network. To take advantage of this, however, 371 the communicating endpoints need to be aware of the MTU along the 372 path (i.e. through Path MTU Discovery). Unfortunately, the larger 373 MTU size may not be available on all links (e.g. 1280 octets on 374 6LoWPAN links). However, it is expected that much of the traffic on 375 these types of networks consists of much smaller messages than the 376 MTU, so performance degradation through fragmentation would be 377 limited. 379 4.2. Processing Source Routing Headers 381 As specified in [RFC2460], a routing header is not examined or 382 processed until it reaches the node identified in the Destination 383 Address field of the IPv6 header. In that node, dispatching on the 384 Next Header field of the immediately preceding header causes the 385 Routing header module to be invoked. 387 The function of SRH is intended to be very similar to the Type 0 388 Routing Header defined in [RFC2460]. After the routing header has 389 been processed and the IPv6 datagram resubmitted to the IPv6 module 390 for processing, the IPv6 Destination Address contains the next hop's 391 address. When forwarding an IPv6 datagram that contains a SRH with a 392 non-zero Segments Left value, if the IPv6 Destination Address is not 393 on-link, a router MUST drop the datagram and SHOULD send an ICMP 394 Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set 395 to (TBD by IANA) to the packet's Source Address. This ICMPv6 Code 396 indicates that the IPv6 Destination Address is not on-link and the 397 router cannot satisfy the strict source route requirement. When 398 generating ICMPv6 error messages, the rules in Section 2.4 of 399 [RFC4443] must be observed. 401 To detect loops in the SRH, a router MUST determine if the SRH 402 includes multiple addresses assigned to any interface on that router. 403 If such addresses appear more than once and are separated by at least 404 one address not assigned to that router, the router MUST drop the 405 packet and SHOULD send an ICMP Parameter Problem, Code 0, to the 406 Source Address. While this loop check does add significant per- 407 packet processing overhead, it is required to mitigate bandwidth 408 exhaustion attacks that led to the deprecation of RH0 [RFC5095]. 410 The following describes the algorithm performed when processing a 411 SRH: 413 if Segments Left = 0 { 414 proceed to process the next header in the packet, whose type is 415 identified by the Next Header field in the Routing header 416 } 417 else { 418 compute n, the number of addresses in the Routing header, by 419 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 421 if Segments Left is greater than n { 422 send an ICMP Parameter Problem, Code 0, message to the Source 423 Address, pointing to the Segments Left field, and discard the 424 packet 425 } 426 else { 427 decrement Segments Left by 1 429 compute i, the index of the next address to be visited in 430 the address vector, by subtracting Segments Left from n 432 if Address[i] or the IPv6 Destination Address is multicast { 433 discard the packet 434 } 435 else if 2 or more entries in Address[1..n] are assigned to 436 local interface and are separated by at least one 437 address not assigned to local interface { 438 send an ICMP Parameter Problem (Code 0) and discard the 439 packet 440 } 441 else { 442 swap the IPv6 Destination Address and Address[i] 444 if the IPv6 Hop Limit is less than or equal to 1 { 445 send an ICMP Time Exceeded -- Hop Limit Exceeded in 446 Transit message to the Source Address and discard the 447 packet 448 } 449 else { 450 decrement the Hop Limit by 1 452 resubmit the packet to the IPv6 module for transmission 453 to the new destination 454 } 455 } 456 } 457 } 459 RPL routers are responsible for ensuring that a SRH is only used 460 between RPL routers: 462 1. For datagrams destined to a RPL router, the router processes the 463 packet in the usual way. For instance, if the SRH was included 464 using tunneled mode and the RPL router serves as the tunnel 465 endpoint, the router removes the outer IPv6 header, at the same 466 time removing the SRH as well. 468 2. Datagrams destined elsewhere within the same RPL Instance are 469 forwarded to the correct interface. 471 3. Datagrams destined to nodes outside the RPL Instance are dropped 472 if the outer-most IPv6 header contains a SRH not generated by the 473 RPL router forwarding the datagram. 475 5. Security Considerations 477 5.1. Source Routing Attacks 479 The RPL message security mechanisms defined in [I-D.ietf-roll-rpl] do 480 not apply to the RPL Source Route Header. This specification does 481 not provide any confidentiality, integrity, or authenticity 482 mechanisms to protect the SRH. 484 [RFC5095] deprecates the Type 0 Routing header due to a number of 485 significant attacks that are referenced in that document. Such 486 attacks include bypassing filtering devices, reaching otherwise 487 unreachable Internet systems, network topology discovery, bandwidth 488 exhaustion, and defeating anycast. 490 Because this document specifies that SRH is only for use within a RPL 491 Instance, such attacks cannot be mounted from outside a RPL Instance. 492 As specified in this document, RPL routers MUST drop datagrams 493 entering or exiting a RPL Instance that contain a SRH in the IPv6 494 Extension headers. 496 Such attacks, however, can be mounted from within a RPL Instance. To 497 mitigate bandwidth exhaustion attacks, this specification requires 498 RPL routers to check for loops in the SRH and drop datagrams that 499 contain such loops. Attacks that include bypassing filtering devices 500 and reaching otherwise unreachable Internet systems are not as 501 relevant in mesh networks since the topologies are, by their very 502 nature, highly dynamic. The RPL routing protocol is designed to 503 provide reachability to all devices within a RPL Instance and may 504 utilize routes that traverse any number of devices in any order. 505 Even so, these attacks and others (e.g. defeating anycast and routing 506 topology discovery) can occur within a RPL Instance when using this 507 specification. 509 5.2. ICMPv6 Attacks 511 The generation of ICMPv6 error messages may be used to attempt 512 denial-of-service attacks by sending error-causing SRH in back-to- 513 back datagrams. An implementation that correctly follows Section 2.4 514 of [RFC4443] would be protected by the ICMPv6 rate limiting 515 mechanism. 517 6. IANA Considerations 519 This document defines a new IPv6 Routing Type, the "RPL Source Route 520 Header", and has been assigned assigned number TBD by IANA. 522 This document defines a new ICMPv6 Destination Unreachable Code, the 523 "strict source route failed" error, and has been assigned number TBD 524 by IANA. 526 7. Acknowledgements 528 The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen 529 Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal 530 Thubert, Sean Turner, and Tim Winter for their comments and 531 suggestions that helped shape this document. 533 8. Changes 535 (This section to be removed by the RFC editor.) 537 Draft 06: 539 - Address IESG comments. 541 Draft 05: 543 - Address LC comments. 545 Draft 04: 547 - Updated text on recommendations for avoiding fragmentation. 549 - Clarify definition of CmprE where it is first mentioned. 551 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 553 - Update packet processing pseudocode to match the text on sending 554 back a parameter problem error. 556 - Recommend that non-RPL devices drop packets with SRH by default. 558 - Clarify packet structure figures. 560 - State that checking for cycles represents significant per-packet 561 processing. 563 Draft 03: 565 - Removed any presumed values that are TBD by IANA. 567 Draft 02: 569 - Updated to send ICMP Destination Unreachable error only after 570 the SRH has been processed. 572 - Updated pseudocode to reflect encoding changes in draft-01. 574 - Allow multiple addresses assigned to same node as long as they 575 are not separated by other addresses. 577 Draft 01: 579 - Allow Addresses[1..n-1] and Addresses[n] to have a different 580 number of bytes elided. 582 9. References 584 9.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 590 (IPv6) Specification", RFC 2460, December 1998. 592 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 593 IPv6 Specification", RFC 2473, December 1998. 595 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 596 Message Protocol (ICMPv6) for the Internet Protocol 597 Version 6 (IPv6) Specification", RFC 4443, March 2006. 599 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 600 of Type 0 Routing Headers in IPv6", RFC 5095, 601 December 2007. 603 9.2. Informative References 605 [I-D.ietf-roll-rpl] 606 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 607 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 608 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 609 Lossy Networks", draft-ietf-roll-rpl-19 (work in 610 progress), March 2011. 612 Authors' Addresses 614 Jonathan W. Hui 615 Cisco Systems, Inc 616 170 West Tasman Drive 617 San Jose, California 95134 618 USA 620 Phone: +408 424 1547 621 Email: jonhui@cisco.com 623 JP Vasseur 624 Cisco Systems, Inc 625 11, Rue Camille Desmoulins 626 Issy Les Moulineaux, 92782 627 France 629 Email: jpv@cisco.com 631 David E. Culler 632 UC Berkeley 633 465 Soda Hall 634 Berkeley, California 94720 635 USA 637 Phone: +510 643 7572 638 Email: culler@cs.berkeley.edu 640 Vishwas Manral 641 Hewlett Packard Co. 642 19111 Pruneridge Ave. 643 Cupertino, California 95014 644 USA 646 Email: vishwas.manral@hp.com