idnits 2.17.1 draft-ietf-6lo-routing-dispatch-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 20 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2016) is 3025 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) == Missing Reference: 'RFCthis' is mentioned on line 766, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-09 == Outdated reference: A later version (-08) exists of draft-thubert-6lo-forwarding-fragments-02 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 4944 (if approved) C. Bormann 5 Intended status: Standards Track Uni Bremen TZI 6 Expires: July 15, 2016 L. Toutain 7 IMT-TELECOM Bretagne 8 R. Cragie 9 ARM 10 January 12, 2016 12 6LoWPAN Routing Header And Paging Dispatches 13 draft-ietf-6lo-routing-dispatch-01 15 Abstract 17 This specification introduces a new context switch mechanism for 18 6LoWPAN compression, expressed in terms of Pages and signaled by a 19 new Paging Dispatch. A new 6LoWPAN dispatch type is proposed in a 20 new Page 1 for use in 6LoWPAN Route-Over topologies, that initially 21 covers the needs of RPL (RFC6550) data packets compression. This 22 specification defines a method to compress RPL Option (RFC6553) 23 information and Routing Header type 3 (RFC6554), an efficient IP-in- 24 IP technique and is extensible for more applications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 15, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. New Page 1 Paging Dispatch . . . . . . . . . . . . . . . 6 64 3.2. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 7 65 4. Placement Of The New Dispatch Types . . . . . . . . . . . . . 7 66 4.1. Placement Of The Page 1 Paging Dispatch . . . . . . . . . 7 67 4.2. Placement Of The 6LoRH . . . . . . . . . . . . . . . . . 8 68 5. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 8 69 5.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 9 71 6. The Routing Header Type 3 (RH3) 6LoRH . . . . . . . . . . . . 9 72 7. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 11 73 7.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 12 74 7.2. Compressing the SenderRank . . . . . . . . . . . . . . . 13 75 7.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 13 76 8. The IP-in-IP 6LoRH . . . . . . . . . . . . . . . . . . . . . 15 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 The design of Low Power and Lossy Networks (LLNs) is generally 89 focused on saving energy, a very constrained resource in most cases. 90 The other constraints, such as the memory capacity and the duty 91 cycling of the LLN devices, derive from that primary concern. Energy 92 is often available from primary batteries that are expected to last 93 for years, or is scavenged from the environment in very limited 94 quantities. Any protocol that is intended for use in LLNs must be 95 designed with the primary concern of saving energy as a strict 96 requirement. 98 Controlling the amount of data transmission is one possible venue to 99 save energy. In a number of LLN standards, the frame size is limited 100 to much smaller values than the IPv6 maximum transmission unit (MTU) 101 of 1280 bytes. In particular, an LLN that relies on the classical 102 Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is limited to 127 103 bytes per frame. The need to compress IPv6 packets over IEEE 104 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work 105 (6LoWPAN-HC). 107 Innovative Route-over techniques have been and are still being 108 developed for routing inside a LLN. In a general fashion, such 109 techniques require additional information in the packet to provide 110 loop prevention and to indicate information such as flow 111 identification, source routing information, etc. 113 For reasons such as security and the capability to send ICMP errors 114 back to the source, an original packet must not be tampered with, and 115 any information that must be inserted in or removed from an IPv6 116 packet must be placed in an extra IP-in-IP encapsulation. This is 117 the case when the additional routing information is inserted by a 118 router on the path of a packet, for instance a mesh root, as opposed 119 to the source node. This is also the case when some routing 120 information must be removed from a packet that flows outside the LLN. 121 When to use RFC 6553, 6554 and IPv6-in-IPv6 122 [I-D.robles-roll-useofrplinfo] details different cases where RFC 123 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the 124 bases to help defining the compression of RPL routing information in 125 LLN environments. 127 When using [RFC6282] the outter IP header of an IP-in-IP 128 encapsulation may be compressed down to 2 octets in stateless 129 compression and down to 3 octets in case of a stateful compression 130 when a context information must be added. 132 0 1 133 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 134 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 135 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 136 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 138 Figure 1: LOWPAN_IPHC base Encoding (RFC6282). 140 The Stateless Compression of an IPv6 addresses can only happen if the 141 IPv6 address can de deduced from the MAC addresses, meaning that the 142 IP end point is also the MAC-layer endpoint. This is generally not 143 the case in a RPL network which is generally a multi-hop route-over 144 (operated at Layer-3) network. A better compression, that does not 145 involve variable compressions depending on the hop in the mesh, can 146 be achieved based on the fact that the outter encapsulation is 147 usually between the source (or destination) of the inner packet and 148 the root. Also, the inner IP header can only be compressed by 149 [RFC6282] if all the fields up to it are also compressed. This 150 specification makes it so that the inner IP header is the first 151 header that is compressed by [RFC6282], and conserves the inner 152 packet encoded the same way whether it is encapsulated or not, 153 conserving existing implementation. 155 As an example, the Routing Protocol for Low Power and Lossy Networks 156 [RFC6550] (RPL) is designed to optimize the routing operations in 157 constrained LLNs. As part of this optimization, RPL requires the 158 addition of RPL Packet Information (RPI) in every packet, as defined 159 in Section 11.2 of [RFC6550]. 161 The RPL Option for Carrying RPL Information in Data-Plane Datagrams 162 [RFC6553] specification indicates how the RPI can be placed in a RPL 163 Option for use in an IPv6 Hop-by-Hop header. This representation 164 demands a total of 8 bytes when in most cases the actual RPI payload 165 requires only 19 bits. Since the Hop-by-Hop header must not flow 166 outside of the RPL domain, it must be removed from packets that leave 167 the domain, and be inserted in packets entering the domain. In both 168 cases, this operation implies an IP-in-IP encapsulation. 170 ------+--------- ^ 171 | Internet | 172 | | Native IPv6 173 +-----+ | 174 | | Border Router (RPL Root) ^ | ^ 175 | | | | | 176 +-----+ | | | IPv6 in 177 | | | | IPv6 178 o o o o | | | + RPI 179 o o o o o o o o o | | | or RH3 180 o o o o o o o o o o | | | 181 o o o o o o o o o | | | 182 o o o o o o o o v v v 183 o o o o 184 LLN 186 Figure 2: IP-in-IP Encapsulation within the LLN. 188 Additionally, in the case of the Non-Storing Mode of Operation (MOP), 189 RPL requires a Routing Header type 3 (RH3) as defined in the IPv6 190 Routing Header for Source Routes with RPL [RFC6554] specification, 191 for all packets that are routed down a RPL graph. With Non-Storing 192 RPL, even if the source is a node in the same LLN, the packet must 193 first reach up the graph to the root so that the root can insert the 194 RH3 to go down the graph. In any fashion, whether the packet was 195 originated in a node in the LLN or outside the LLN, and regardless of 196 whether the packet stays within the LLN or not, as long as the source 197 of the packet is not the root itself, the source-routing operation 198 also implies an IP-in-IP encapsulation at the root in order to insert 199 the RH3. 201 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 202 over the TimeSlotted Channel Hopping [RFC7554] (TSCH) mode of 203 operation of IEEE 802.15.4. The architecture requires the use of 204 both RPL and the 6lo adaptation layer framework ([RFC4944], 205 [RFC6282]) over IEEE 802.15.4. Because it inherits the constraints 206 on the frame size from the MAC layer, 6TiSCH cannot afford to spend 8 207 bytes per packet on the RPI. Hence the requirement for a 6LoWPAN 208 header compression of the RPI. 210 An extensible compression technique is required that simplifies IP- 211 in-IP encapsulation when it is needed, and optimally compresses 212 existing routing artifacts found in RPL LLNs. 214 This specification extends the 6lo adaptation layer framework 215 ([RFC4944],[RFC6282]) so as to carry routing information for route- 216 over networks based on RPL. The specification includes the formats 217 necessary for RPL and is extensible for additional formats. 219 2. Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in 224 [RFC2119]. 226 The Terminology used in this document is consistent with and 227 incorporates that described in `Terminology in Low power And Lossy 228 Networks' [RFC7102] and [RFC6550]. 230 The terms Route-over and Mesh-under are defined in [RFC6775]. 232 Other terms in use in LLNs are found in [RFC7228]. 234 The term "byte" is used in its now customary sense as a synonym for 235 "octet". 237 3. Updating RFC 4944 239 This draft adapts 6LoWPAN while maintaining backward compatibility 240 with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of 241 "context" in the 6LoWPAN parser, a context being identified by a Page 242 number. This specification defines 16 Pages. 244 Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value 245 that indicates the next current Page. The Page number is encoded in 246 a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx 247 is the Page number, 0 to 15, as described in Figure 3: 249 0 250 0 1 2 3 4 5 6 7 251 +-+-+-+-+-+-+-+-+ 252 |1|1|1|1|Page Nb| 253 +-+-+-+-+-+-+-+-+ 255 Figure 3: Paging Dispatch with Page Number Encoding. 257 Values of the Dispatch byte defined in [RFC4944] are considered as 258 belonging to the Page 0 parsing context, which is the default and 259 does not need to be signaled explicitly at the beginning of a 6LoWPAN 260 packet. This ensures backward compatibility with existing 261 implementations of 6LoWPAN. 263 Note: This specification does not use the Escape Dispatch, which 264 extends Page 0 to more values, but rather allocates another Dispatch 265 Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in 266 all Pages, including Page 0 and Pages defined in future 267 specifications, to indicate the next parsing context represented by 268 its Page number. The rationale for avoiding that approach is that 269 there will be multiple occurrences of a new header indexed by this 270 specification in a single frame and the overhead on an octet each 271 time for the Escape Dispatch would be prohibitive. 273 3.1. New Page 1 Paging Dispatch 275 This draft defines a new Page 1 Paging Dispatch (Dispatch Value of 276 11110001), which indicates a context switch in the 6LoWPAN parser to 277 a Page 1. 279 The Dispatch bits defined in Page 0 by [RFC4944] are free to be 280 reused in Pages 1 to 15. 282 On the other hand, the Dispatch bits defined in Page 0 for the 283 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 284 Networks [RFC6282] are defined with the same values in Page 1 so 285 there is no need to switch context back from Page 1 to Page 0 to 286 address LOWPAN_IPHC and LOWPAN_NHC. 288 3.2. New Routing Header Dispatch (6LoRH) 290 This specification introduces a new 6LoWPAN Routing Header (6LoRH) to 291 carry IPv6 routing information. The 6LoRH may contain source routing 292 information such as a compressed form of RH3, as well as other sorts 293 of routing information such as the RPL Packet Information and IP-in- 294 IP encapsulation. 296 The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value 297 (TLV) field, which is extensible for future use. 299 This specification uses the bit pattern 10xxxxxx in Page 1 for the 300 new 6LoRH Dispatch and Section 5 describes how RPL artifacts in data 301 packets can be compressed as 6LoRH headers. 303 4. Placement Of The New Dispatch Types 305 4.1. Placement Of The Page 1 Paging Dispatch 307 In a zone of a packet where Page 1 is active, which means once a Page 308 1 Paging Dispatch is parsed, and as long as no other Paging Dispatch 309 is parsed, the parsing of the packet MUST follow this specification 310 if the 6LoRH Bit Pattern Section 3.2 is found. 312 Mesh Headers represent Layer-2 information and are processed before 313 any Layer-3 information that is encoded in Page 1. If a 6LoWPAN 314 packet requires a Mesh header, the Mesh Header MUST always be placed 315 in the packet before the first Page 1 Paging Dispatch, if any. 317 For the same reason, Fragment Headers as defined in [RFC4944] MUST 318 always be placed in the packet before the first Page 1 Paging 319 Dispatch, if any. 321 The NALP Dispatch Bit Pattern as defined in [RFC4944] is only defined 322 for the first octet in the packet. Switching back to Page 0 for NALP 323 inside a 6LoWPAN packet does not make sense. 325 parsing context after a context was switched to Page 1, so the value 326 for the Page 0 Paging Dispatch of 11110000 may not actually be seen 327 in packets following the 6LoWPAN specifications that are available at 328 the time of writing. 330 4.2. Placement Of The 6LoRH 332 With this specification, the 6LoRH Dispatch is only defined in Page 333 context is active. 335 One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet. A 336 6LoRH header MUST always be placed before the LOWPAN_IPHC as defined 337 in 6LoWPAN Header Compression [RFC6282]. 339 A 6LoRH header being always placed in a Page 1 context, it MUST 340 always be placed after any Fragmentation Header and/or Mesh Header 341 [RFC4944]. 343 5. 6LoWPAN Routing Header General Format 345 The 6LoRH reuses in Page 1 the Dispatch Value Bit Pattern of 346 10xxxxxx. 348 The Dispatch Value Bit Pattern is split in two forms of 6LoRH: 350 Elective (6LoRHE) that may skipped if not understood 352 Critical (6LoRHC) that may not be ignored 354 5.1. Elective Format 356 The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. A 6LoRHE 357 may be ignored and skipped in parsing. If it is ignored, the 6LoRHE 358 is forwarded with no change inside the LLN. 360 0 1 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 363 |1|0|1| Length | Type | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 365 <-- Length --> 367 Figure 4: Elective 6LoWPAN Routing Header. 369 Length: 370 Length of the 6LoRHE expressed in bytes, excluding the first 2 371 bytes. This enables a node to skip a 6LoRHE header that it does 372 not support and/or cannot parse, for instance if the Type is not 373 known. 375 Type: 376 Type of the 6LoRHE 378 5.2. Critical Format 380 The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx. 382 A node which does not support the 6LoRHC Type MUST silently discard 383 the packet. 385 Note: The situation where a node receives a message with a Critical 386 6LoWPAN Routing Header that it does not understand is a critical 387 administrative error whereby the wrong device is placed in a network. 388 It makes no sense to overburden the constrained device with code that 389 would cause ICMP error to the source. Rather, it is expected that 390 the device will raise some management alert indicating that it cannot 391 operate in this network for that reason. It results that there is no 392 provision for the exchange of error messages for this situation; it 393 should be avoided by judicious use of administrative control and/or 394 capability indications by the device manufacturer. 396 0 1 397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 399 |1|0|0| TSE | Type | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 401 <-- Length implied by Type/TSE --> 403 Figure 5: Critical 6LoWPAN Routing Header. 405 TSE: 406 Type Specific Extension. The meaning depends on the Type, which 407 must be known in all of the nodes. The interpretation of the TSE 408 depends on the Type field that follows. For instance, it may be 409 used to transport control bits, the number of elements in an 410 array, or the length of the remainder of the 6LoRHC expressed in a 411 unit other than bytes. 413 Type: 414 Type of the 6LoRHC 416 6. The Routing Header Type 3 (RH3) 6LoRH 418 The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) is a Critical 419 6LoWPAN Routing Header that provides a compressed form for the RH3, 420 as defined in [RFC6554] for use by RPL routers. Routers that need to 421 forward a packet with a RH3-6LoRH are expected to be RPL routers and 422 are expected to support this specification. If a non-RPL router 423 receives a packet with a RH3-6LoRH, this means that there was a 424 routing error and the packet should be dropped so the Type cannot be 425 ignored. 427 0 1 428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 430 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 433 Size indicates the number of compressed addresses 435 Figure 6: The RH3-6LoRH. 437 The values for the RH3-6LoRH Type are an enumeration, 0 to 4. The 438 form of compression is indicated by the Type. The unit (as a number 439 of bytes) in which the Size is expressed depends on the Type as 440 described in Figure 7: 442 +-----------+-----------+ 443 | Type | Size Unit | 444 +-----------+-----------+ 445 | 0 | 1 | 446 | 1 | 2 | 447 | 2 | 4 | 448 | 3 | 8 | 449 | 4 | 16 | 450 +-----------+-----------+ 452 Figure 7: The RH3-6LoRH Types. 454 In the case of a RH3-6LoRH, the TSE field is used as a Size, which 455 encodes the number of hops minus 1; so a Size of 0 means one hop, and 456 the maximum that can be encoded is 32 hops. (If more than 32 hops 457 need to be expressed, a sequence of RH3-6LoRH can be employed.) 459 The Next Hop is indicated in the first entry of the first RH3-6LoRH. 460 Upon reception, the router checks whether it owns the address 461 indicated as Next Hop, which MUST be the case in a strict source 462 routing environment. If it is so, the entry is removed from the 463 RH3-6LoRH and the Size is decremented. If the Size is now zero, the 464 whole RH3-6LoRH is removed. If there is no more RH3-6LoRH, the 465 processing node is the last router on the way, which may or may not 466 be collocated with the final destination. 468 The last hop in the last RH3-6LoRH is the last router on the way to 469 the destination in the LLN. In a classical RPL network, all nodes 470 are routers so the last hop is effectively the destination as well. 471 But in the general case, even when there is a RH3-6LoRH header 472 present, the address of the final destination is always indicated in 473 the LoWPAN_IPHC [RFC6282]. 475 If some bits of the first address in the RH3-6LoRH can be derived 476 from the final destination in the LoWPAN_IPHC, then that address may 477 be compressed, otherwise it is expressed as a full IPv6 address of 478 128 bits. Next addresses only need to express the delta from the 479 previous address. 481 All addresses in a given RH3-6LoRH header are compressed in a same 482 fashion, down to the same number of bytes per address. In order to 483 get different forms of compression, multiple consecutive RH3-6LoRH 484 must be used. 486 7. The RPL Packet Information 6LoRH 488 [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) 489 as a set of fields that are placed by RPL routers in IP packets for 490 the purpose of Instance Identification, as well as Loop Avoidance and 491 Detection. 493 In particular, the SenderRank, which is the scalar metric computed by 494 an specialized Objective Function such as [RFC6552], indicates the 495 Rank of the sender and is modified at each hop. The SenderRank field 496 is used to validate that the packet progresses in the expected 497 direction, either upwards or downwards, along the DODAG. 499 RPL defines the RPL Option for Carrying RPL Information in Data-Plane 500 Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 501 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes 502 per packet. 504 With [RFC6553], the RPL option is encoded as six Octets; it must be 505 placed in a Hop-by-Hop header that consumes two additional octets for 506 a total of eight. In order to limit its range to the inside the RPL 507 domain, the Hop-by-Hop header must be added to (or removed from) 508 packets that cross the border of the RPL domain. 510 The 8-byte overhead is detrimental to the LLN operation, in 511 particular with regards to bandwidth and battery constraints. These 512 bytes may cause a containing frame to grow above maximum frame size, 513 leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn 514 causes even more energy spending and issues discussed in the LLN 515 Fragment Forwarding and Recovery 516 [I-D.thubert-6lo-forwarding-fragments]. 518 An additional overhead comes from the need, in certain cases, to add 519 an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is 520 needed when the router that inserts the Hop-by-Hop header is not the 521 source of the packet, so that an error can be returned to the router. 522 This is also the case when a packet originated by a RPL node must be 523 stripped from the Hop-by-Hop header to be routed outside the RPL 524 domain. 526 This specification defines an IPinIP-6LoRH in Section 8 for that 527 purpose, but it must be noted that stripping a 6LoRH does not require 528 a manipulation of the packet in the LOWPAN_IPHC, and thus, if the 529 source address in the LOWPAN_IPHC is the node that inserted the 530 IPinIP-6LoRH then this alone does not mandate an IPinIP-6LoRH. 532 Note: A typical packet in RPL non-storing mode going down the RPL 533 graph requires an IP-in-IP encapsulating the RH3, whereas the RPI is 534 usually (and quite illegally) omitted, unless it is important to 535 indicate the RPLInstanceID. To match this structure, an optimized 536 IP-in-IP 6LoRH is defined in Section 8. 538 As a result, a RPL packet may bear only an RPI-6LoRH and no IPinIP- 539 6LoRH. In that case, the source and destination of the packet are 540 located in the LOWPAN_IPHC. 542 As with [RFC6553], the fields in the RPI include an 'O', an 'R', and 543 an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), 544 and a 16-bit SenderRank. 546 The remainder of this section defines the RPI-6LoRH, a Critical 547 6LoWPAN Routing Header that is designed to transport the RPI in 548 6LoWPAN LLNs. 550 7.1. Compressing the RPLInstanceID 552 RPL Instances are discussed in [RFC6550], Section 5. A number of 553 simple use cases do not require more than one instance, and in such 554 cases, the instance is expected to be the global Instance 0. A 555 global RPLInstanceID is encoded in a RPLInstanceID field as follows: 557 0 1 2 3 4 5 6 7 558 +-+-+-+-+-+-+-+-+ 559 |0| ID | Global RPLInstanceID in 0..127 560 +-+-+-+-+-+-+-+-+ 562 Figure 8: RPLInstanceID Field Format for Global Instances. 564 For the particular case of the global Instance 0, the RPLInstanceID 565 field is all zeros. This specification allows to elide a 566 RPLInstanceID field that is all zeros, and defines a I flag that, 567 when set, signals that the field is elided. 569 7.2. Compressing the SenderRank 571 The SenderRank is the result of the DAGRank operation on the rank of 572 the sender; here the DAGRank operation is defined in [RFC6550], 573 Section 3.5.1, as: 575 DAGRank(rank) = floor(rank/MinHopRankIncrease) 577 If MinHopRankIncrease is set to a multiple of 256, the least 578 significant 8 bits of the SenderRank will be all zeroes; by eliding 579 those, the SenderRank can be compressed into a single byte. This 580 idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE 581 as 256 and in [RFC6552] that defaults MinHopRankIncrease to 582 DEFAULT_MIN_HOP_RANK_INCREASE. 584 This specification allows to encode the SenderRank as either one or 585 two bytes, and defines a K flag that, when set, signals that a single 586 byte is used. 588 7.3. The Overall RPI-6LoRH encoding 590 The RPI-6LoRH provides a compressed form for the RPL RPI. Routers 591 that need to forward a packet with a RPI-6LoRH are expected to be RPL 592 routers and expected to support this specification. If a non-RPL 593 router receives a packet with a RPI-6LoRH, this means that there was 594 a routing error and the packet should be dropped so the Type cannot 595 be ignored. 597 Since the I flag is not set, the TSE field does not need to be a 598 length expressed in bytes. The field is fully reused for control 599 bits so as to encode the O, R and F flags from the RPI, and the I and 600 K flags that indicate the compression that is taking place. 602 The Type for the RPI-6LoRH is 5. 604 The RPI-6LoRH is immediately followed by the RPLInstanceID field, 605 unless that field is fully elided, and then the SenderRank, which is 606 either compressed into one byte or fully in-lined as the whole 2 607 bytes. The I and K flags in the RPI-6LoRH indicate whether the 608 RPLInstanceID is elided and/or the SenderRank is compressed and 609 depending on these bits, the Length of the RPI-6LoRH may vary as 610 described hereafter. 612 0 1 2 613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 615 |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 618 Figure 9: The Generic RPI-6LoRH Format. 620 O, R, and F bits: 621 The O, R, and F bits as defined in [RFC6550], Section 11.2. 623 I bit: 624 If it is set, the Instance ID is elided and the RPLInstanceID 625 is the Global RPLInstanceID 0. If it is not set, the octet 626 immediately following the type field contains the RPLInstanceID 627 as specified in [RFC6550] section 5.1. 629 K bit: 630 If it is set, the SenderRank is be compressed into one octet, 631 and the lowest significant octet is elided. If it is not set, 632 the SenderRank, is fully inlined as 2 octets. 634 In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and 635 the MinHopRankIncrease is a multiple of 256 so the least significant 636 byte is all zeros and can be elided: 638 0 1 2 639 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 I=1, K=1 645 Figure 10: The most compressed RPI-6LoRH. 647 In Figure 11, the RPLInstanceID is the Global RPLInstanceID 0, but 648 both bytes of the SenderRank are significant so it can not be 649 compressed: 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 I=1, K=0 658 Figure 11: Eliding the RPLInstanceID. 660 In Figure 12, the RPLInstanceID is not the Global RPLInstanceID 0, 661 and the MinHopRankIncrease is a multiple of 256: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 I=0, K=1 670 Figure 12: Compressing SenderRank. 672 In Figure 13, the RPLInstanceID is not the Global RPLInstanceID 0, 673 and both bytes of the SenderRank are significant: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-... 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 ...-Rank | 681 +-+-+-+-+-+-+-+-+ 682 I=0, K=0 684 Figure 13: Least compressed form of RPI-6LoRH. 686 8. The IP-in-IP 6LoRH 688 The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN Routing 689 Header that provides a compressed form for the encapsulating IPv6 690 Header in the case of an IP-in-IP encapsulation. 692 An IP-in-IP encapsulation is used to insert a field such as a Routing 693 Header or an RPI at a router that is not the source of the packet. 694 In order to send an error back regarding the inserted field, the 695 address of the router that performs the insertion must be provided. 697 The encapsulation can also enable the last router prior to 698 Destination to remove a field such as the RPI, but this can be done 699 in the compressed form by removing the RPI-6LoRH, so an IPinIP-6LoRH 700 encapsulation is not required for that sole purpose. 702 This field is not critical for routing so the Type can be ignored, 703 and the TSE field contains the Length in bytes. 705 0 1 2 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 708 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 711 Figure 14: The IPinIP-6LoRH. 713 The Length of an IPinIP-6LoRH is expressed in bytes and MUST be at 714 least 1, to indicate a Hop Limit (HL), that is decremented at each 715 hop. When the HL reaches 0, the packet is dropped per [RFC2460] 717 If the Length of an IPinIP-6LoRH is exactly 1, then the Encapsulator 718 Address is elided, which means that the Encapsulator is a well-known 719 router, for instance the root in a RPL graph. 721 If the Length of an IPinIP-6LoRH is strictly more than 1, then an 722 Encapsulator Address is placed in a compressed form after the Hop 723 Limit field. The value of the Length indicates which compression is 724 performed on the Encapsulator Address. For instance, a Size of 3 725 indicates that the Encapsulator Address is compressed to 2 bytes. 727 When it cannot be elided, the destination IP address of the IP-in-IP 728 header is transported in a RH3-6LoRH as the first address of the 729 list. 731 With RPL, the destination address in the IP-in-IP header is 732 implicitly the root in the RPL graph for packets going upwards, and 733 the destination address in the IPHC for packets going downwards. If 734 the implicit value is correct, the destination IP address of the IP- 735 in-IP encapsulation can be elided. 737 If the final destination of the packet is a leaf that does not 738 support this specification, then the chain of 6LoRH must be stripped 739 by the RPL/6LR router to which the leaf is attached. In that 740 example, the destination IP address of the IP-in-IP header cannot be 741 elided. 743 In the special case where the 6LoRH is used to route 6LoWPAN 744 fragments, the destination address is not accessible in the IPHC on 745 all fragments and can be elided only for the first fragment and for 746 packets going upwards. 748 9. Security Considerations 750 The security considerations of [RFC4944], [RFC6282], and [RFC6553] 751 apply. 753 Using a compressed format as opposed to the full in-line format is 754 logically equivalent and does not create an opening for a new threat 755 when compared to [RFC6550], [RFC6553] and [RFC6554]. 757 10. IANA Considerations 759 This document creates a IANA registry for the 6LoWPAN Routing Header 760 Type, and assigns the following values: 762 0..4 : RH3-6LoRH [RFCthis] 764 5 : RPI-6LoRH [RFCthis] 766 6 : IPinIP-6LoRH [RFCthis] 768 11. Acknowledgments 770 The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin 771 Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel 772 Montenegro and Ralph Droms for constructive reviews to the design in 773 the 6lo Working Group. The overall discussion involved participants 774 to the 6MAN, 6TiSCH and ROLL WGs, thank you all. Special thanks to 775 the chairs of the ROLL WG, Michael Richardson and Ines Robles, and 776 Brian Haberman, Internet Area A-D, and Adrian Farrel, Routing Area 777 A-D, for driving this complex effort across Working Groups and Areas. 779 12. References 781 12.1. Normative References 783 [IEEE802154] 784 IEEE standard for Information Technology, "IEEE std. 785 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 786 and Physical Layer (PHY) Specifications for Low-Rate 787 Wireless Personal Area Networks", 2015. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 791 RFC2119, March 1997, 792 . 794 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 795 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 796 December 1998, . 798 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 799 "Transmission of IPv6 Packets over IEEE 802.15.4 800 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 801 . 803 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 804 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 805 DOI 10.17487/RFC6282, September 2011, 806 . 808 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 809 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 810 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 811 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 812 RFC6550, March 2012, 813 . 815 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 816 Protocol for Low-Power and Lossy Networks (RPL)", RFC 817 6552, DOI 10.17487/RFC6552, March 2012, 818 . 820 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 821 Power and Lossy Networks (RPL) Option for Carrying RPL 822 Information in Data-Plane Datagrams", RFC 6553, DOI 823 10.17487/RFC6553, March 2012, 824 . 826 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 827 Routing Header for Source Routes with the Routing Protocol 828 for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 829 10.17487/RFC6554, March 2012, 830 . 832 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 833 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 834 2014, . 836 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 837 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 838 RFC7228, May 2014, 839 . 841 12.2. Informative References 843 [I-D.ietf-6tisch-architecture] 844 Thubert, P., "An Architecture for IPv6 over the TSCH mode 845 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 846 in progress), November 2015. 848 [I-D.robles-roll-useofrplinfo] 849 Robles, I., Richardson, M., and P. Thubert, "When to use 850 RFC 6553, 6554 and IPv6-in-IPv6", draft-robles-roll- 851 useofrplinfo-02 (work in progress), October 2015. 853 [I-D.thubert-6lo-forwarding-fragments] 854 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 855 Recovery", draft-thubert-6lo-forwarding-fragments-02 (work 856 in progress), November 2014. 858 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 859 Bormann, "Neighbor Discovery Optimization for IPv6 over 860 Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 861 6775, DOI 10.17487/RFC6775, November 2012, 862 . 864 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 865 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 866 Internet of Things (IoT): Problem Statement", RFC 7554, 867 DOI 10.17487/RFC7554, May 2015, 868 . 870 Appendix A. Examples 872 The example in Figure 15 illustrates the 6LoRH compression of a 873 classical packet in Storing Mode in all directions, as well as in 874 non-Storing mode for a packet going up the DODAG following the 875 default route to the root. In this particular example, a 876 fragmentation process takes place per [RFC4944], and the fragment 877 headers must be placed in Page 0 before switching to Page 1: 879 +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+- ... 880 |Frag type|Frag hdr |11110001| IPinIP | RPI | Dispatch + LOWPAN_IPHC 881 |RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | RFC 6282 882 +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+- ... 883 <- RFC 6282 -> 884 No RPL artifact 886 Figure 15: Example Compressed Packet with RPI. 888 The example illustrated in Figure 16 is a classical packet in non- 889 Storing mode for a packet going down the DODAG following a source 890 routed path from the root; in this particular example, addresses in 891 the DODAG are assigned to share a same /112 prefix, for instance 892 taken from a /64 subnet with the first 6 octets of the suffix set to 893 a constant such as all zeroes. In that case, all addresses but the 894 first can be compressed to 2 octets, which means that there will be 2 895 RH3_6LoRH headers, one to store the first complete address and the 896 one to store the sequence of addresses compressed to 2 octets (in 897 this example, 3 of them): 899 +- ... -+- ... -+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+- ... 900 |11110001| IPinIP | RH3(128bits)| RH3(3*16bits)| Dispatch + LOWPAN_IPHC 901 |Page 1 | 6LoRH | 6LoRH | 6LoRH | RFC 6282 902 +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+- ... 903 <- RFC 6282 -> 904 No RPL artifact 906 Figure 16: Example Compressed Packet with RH3. 908 Note: the RPI is not represented since most implementations actually 909 refrain from placing it in a source routed packet though [RFC6550] 910 generally expects it. 912 Authors' Addresses 914 Pascal Thubert (editor) 915 Cisco Systems 916 Building D - Regus 917 45 Allee des Ormes 918 BP1200 919 MOUGINS - Sophia Antipolis 06254 920 FRANCE 922 Phone: +33 4 97 23 26 34 923 Email: pthubert@cisco.com 925 Carsten Bormann 926 Universitaet Bremen TZI 927 Postfach 330440 928 Bremen D-28359 929 Germany 931 Phone: +49-421-218-63921 932 Email: cabo@tzi.org 933 Laurent Toutain 934 Institut MINES TELECOM; TELECOM Bretagne 935 2 rue de la Chataigneraie 936 CS 17607 937 Cesson-Sevigne Cedex 35576 938 France 940 Email: Laurent.Toutain@telecom-bretagne.eu 942 Robert Cragie 943 ARM Ltd. 944 110 Fulbourn Road 945 Cambridge CB1 9NJ 946 UK 948 Email: robert.cragie@gridmerge.com