idnits 2.17.1 draft-ietf-6lo-routing-dispatch-00.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 19 form feeds but 22 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 (December 4, 2015) is 3063 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: 'Section 5' is mentioned on line 305, but not defined == Missing Reference: 'RFCthis' is mentioned on line 739, but not defined == Unused Reference: 'I-D.bergmann-bier-ccast' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'I-D.wijnands-bier-architecture' is defined on line 837, but no explicit reference was found in the text -- 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 (-02) exists of draft-bergmann-bier-ccast-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-08 == Outdated reference: A later version (-08) exists of draft-thubert-6lo-forwarding-fragments-02 Summary: 3 errors (**), 0 flaws (~~), 9 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: June 6, 2016 L. Toutain 7 IMT-TELECOM Bretagne 8 R. Cragie 9 ARM 10 December 4, 2015 12 6LoWPAN Routing Header And Paging Dispatches 13 draft-ietf-6lo-routing-dispatch-00 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 June 6, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. New Page 1 Paging Dispatch {#Page 1} . . . . . . . . . . 6 64 3.2. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 7 68 5. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 7 69 5.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 8 71 6. The Routing Header Type 3 (RH3) 6LoRH . . . . . . . . . . . . 9 72 7. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 10 73 7.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 12 74 7.2. Compressing the SenderRank . . . . . . . . . . . . . . . 12 75 7.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 12 76 8. The IP-in-IP 6LoRH . . . . . . . . . . . . . . . . . . . . . 15 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The design of Low Power and Lossy Networks (LLNs) is generally 88 focused on saving energy, which is the most constrained resource of 89 all. The other constraints, such as the memory capacity and the duty 90 cycling of the LLN devices, derive from that primary concern. Energy 91 is often available from primary batteries that are expected to last 92 for years, or is scavenged from the environment in very limited 93 quantities. Any protocol that is intended for use in LLNs must be 94 designed with the primary concern of saving energy as a strict 95 requirement. 97 Controlling the amount of data transmission is one possible venue to 98 save energy. In a number of LLN standards, the frame size is limited 99 to much smaller values than the IPv6 maximum transmission unit (MTU) 100 of 1280 bytes. In particular, an LLN that relies on the classical 101 Physical Layer (PHY) of IEEE 802.14.5 [IEEE802154] is limited to 127 102 bytes per frame. The need to compress IPv6 packets over IEEE 103 802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work 104 (6LoWPAN-HC). 106 Innovative Route-over techniques have been and are still being 107 developed for routing inside a LLN. In a general fashion, such 108 techniques require additional information in the packet to provide 109 loop prevention and to indicate information such as flow 110 identification, source routing information, etc. 112 For reasons such as security and the capability to send ICMP errors 113 back to the source, an original packet must not be tampered with, and 114 any information that must be inserted in or removed from an IPv6 115 packet must be placed in an extra IP-in-IP encapsulation. This is 116 the case when the additional routing information is inserted by a 117 router on the path of a packet, for instance a mesh root, as opposed 118 to the source node. This is also the case when some routing 119 information must be removed from a packet that will flow outside the 120 LLN. 122 As an example, the Routing Protocol for Low Power and Lossy Networks 123 [RFC6550] (RPL) is designed to optimize the routing operations in 124 constrained LLNs. As part of this optimization, RPL requires the 125 addition of RPL Packet Information (RPI) in every packet, as defined 126 in Section 11.2 of [RFC6550]. 128 The RPL Option for Carrying RPL Information in Data-Plane Datagrams 129 [RFC6553] specification indicates how the RPI can be placed in a RPL 130 Option for use in an IPv6 Hop-by-Hop header. This representation 131 demands a total of 8 bytes when in most cases the actual RPI payload 132 requires only 19 bits. Since the Hop-by-Hop header must not flow 133 outside of the RPL domain, it must be removed from packets that leave 134 the domain, and be inserted in packets entering the domain. In both 135 cases, this operation implies an IP-in-IP encapsulation. 137 ------+--------- ^ 138 | Internet | 139 | | Native IPv6 140 +-----+ | 141 | | Border Router (RPL Root) ^ | ^ 142 | | | | | 143 +-----+ | | | IPv6 in 144 | | | | IPv6 145 o o o o | | | + RPI 146 o o o o o o o o o | | | or RH3 147 o o o o o o o o o o | | | 148 o o o o o o o o o | | | 149 o o o o o o o o v v v 150 o o o o 151 LLN 153 Figure 1: IP-in-IP Encapsulation within the LLN 155 Additionally, in the case of the Non-Storing Mode of Operation (MOP), 156 RPL requires a Routing Header type 3 (RH3) as defined in the IPv6 157 Routing Header for Source Routes with RPL [RFC6554] specification, 158 for all packets that are routed down a RPL graph. With Non-Storing 159 RPL, even if the source is a node in the same LLN, the packet must 160 first reach up the graph to the root so that the root can insert the 161 RH3 to go down the graph. In any fashion, whether the packet was 162 originated in a node in the LLN or outside the LLN, and regardless of 163 whether the packet stays within the LLN or not, as long as the source 164 of the packet is not the root itself, the source-routing operation 165 also implies an IP-in-IP encapsulation at the root to insert the RH3. 167 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 168 over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) 169 mode of operation of IEEE 802.14.5. The architecture requires the 170 use of both RPL and the 6lo adaptation layer framework ([RFC4944], 171 [RFC6282]) over IEEE 802.14.5. Because it inherits the constraints 172 on the frame size from the MAC layer, 6TiSCH cannot afford to spend 8 173 bytes per packet on the RPI. Hence the requirement for a 6LoWPAN 174 header compression of the RPI. 176 The type of information that needs to be present in a packet inside 177 the LLN but not outside of the LLN varies with the routing operation, 178 but there is overall a need for an extensible compression technique 179 that would simplify the IP-in-IP encapsulation, when needed, and 180 optimally compress existing routing artifacts found in LLNs. 182 This specification extends the 6lo adaptation layer framework so as 183 to carry routing information for Route-over use cases. The 184 specification includes the formats necessary for RPL and is 185 extensible for additional formats. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 [RFC2119]. 194 The Terminology used in this document is consistent with and 195 incorporates that described in `Terminology in Low power And Lossy 196 Networks' [RFC7102] and [RFC6550]. 198 The terms Route-over and Mesh-under are defined in [RFC6775]. 200 Other terms in use in LLNs are found in [RFC7228]. 202 The term "byte" is used in its now customary sense as a synonym for 203 "octet". 205 3. Updating RFC 4944 207 This draft adapts 6LoWPAN while maintaining backward compatibility 208 with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of 209 context in the 6LoWPAN parser, a context being identified by a Page 210 number, and defines 16 Pages. 212 Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value 213 that indicates the next current Page. The Page number is encoded in 214 a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx 215 is the Page number, 0 to 15, as follows: 217 0 218 0 1 2 3 4 5 6 7 219 +-+-+-+-+-+-+-+-+ 220 |1|1|1|1|Page Nb| 221 +-+-+-+-+-+-+-+-+ 223 Figure 2: Paging Dispatch with Page Number Encoding 225 Values of the Dispatch byte defined in [RFC4944] are considered as 226 belonging to a Page 0 parsing context, which is the default and does 227 not need to be signaled explicitly at the beginning of a 6LoWPAN 228 packet. That way, backward compatibility with existing 229 implementations in ensured. 231 Note: This specification does not use the Escape Dispatch, which 232 extends Page 0 to more values, but rather allocates another Dispatch 233 Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in 234 all Pages, including Page 0 and Pages defined in future 235 specifications, to indicate the next parsing context represented by 236 its Page number. 238 3.1. New Page 1 Paging Dispatch {#Page 1} 240 This draft defines a new Page 1 Paging Dispatch with a Dispatch Value 241 of 11110001 that indicates a context switch in the 6LoWPAN parser to 242 a Page 1. 244 The Dispatch bits defined in Page 0 by [RFC4944] are free to be 245 reused in the next Pages, 1 to 15. 247 On the other hand, the Dispatch bits defined in Page 0 for the 248 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 249 Networks [RFC6282] are defined with the same values in Page 1 so 250 there is no need to switch context back from Page 1 to Page 0 to 251 address LOWPAN_IPHC and LOWPAN_NHC. 253 3.2. New Routing Header Dispatch (6LoRH) 255 This specification introduces a new 6LoWPAN Routing Header (6LoRH) to 256 carry IPv6 routing information. The 6LoRH may contain source routing 257 information such as a compressed form of RH3, as well as other sorts 258 of routing information such as the RPL Packet Information and IP-in- 259 IP encapsulation. 261 The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value 262 (TLV) field, which is extensible for future uses. 264 This specification uses the bit pattern 10xxxxxx in Page 1 for the 265 new 6LoRH Dispatch. 267 The 6LoRH uses on a 1/4th of the Dispatch space in Page 1, and this 268 specification only uses a limited portion of the TLV space in the 269 6LoRH to encode RPL artifacts as detailed in Section 5. 271 It is expected that in the future, other specification with extend 272 the 6LoRH for other features related to packet routing and forwarding 273 in 6LoWPAN networks. 275 4. Placement Of The New Dispatch Types 277 4.1. Placement Of The Page 1 Paging Dispatch 279 In a zone of a packet where Page 1 is active, which means once a Page 280 1 Paging Dispatch is parsed, and as long as no other Paging Dispatch 281 is parsed, the parsing of the packet MUST follow this specification 282 if the 6LoRH Bit Pattern [Section 5] is found. 284 Mesh Headers represent Layer-2 information and are processed before 285 any Layer-3 information that is encoded in Page 1. If a 6LoWPAN 286 packet requires a Mesh header, the Mesh Header MUST always be placed 287 in the packet before the first Page 1 Paging Dispatch, if any. 289 For the same reason, Fragments Headers as defined in [RFC4944] MUST 290 always be placed in the packet before the first Page 1 Paging 291 Dispatch, if any. 293 It must be noted that the NALP Dispatch Bit Pattern as defined in 294 [RFC4944] is only defined for the first octet in the packet. 295 Switching back to Page 0 for NALP inside a 6LoWPAN packet appears 296 non-sensical. 298 parsing context after a context was switched to Page 1, so the value 299 for the Page 0 Paging Dispatch of 11110000 may not actually be seen 300 in packets following the 6LoWPAN specifications that are available at 301 the time of this writing. 303 4.2. Placement Of The 6LoRH 305 With this specification, the 6LoRH [Section 5] is only defined in 306 context is active. 308 One or more 6LoRHs MAY be placed in a 6LoWPAN packet and MUST always 309 be placed before the LOWPAN_IPHC [RFC6282]. 311 A 6LoRH being placed in a Page 1 context, it MUST always be placed 312 after any Fragmentation Header and/or Mesh Header [RFC4944], even if 313 a sur-compression mechanism is used that elides the Paging 314 Dispatches. 316 5. 6LoWPAN Routing Header General Format 318 In its canonical form, the 6LoRH reuses in Page 1 the Dispatch Value 319 Bit Pattern of 10xxxxxx that is defined in Page 0 for the Mesh Header 320 in [RFC4944]. 322 The Dispatch Value Bit Pattern is split in two forms of 6LoRH: 324 Elective (6LoRHE) that may skipped if not understood 326 Critical (6LoRHC) that may not be ignored 328 5.1. Elective Format 330 In its canonical form, the 6LoRHE uses the Dispatch Value Bit Pattern 331 of 101xxxxx. A 6LoRHE may be ignored and skipped in parsing. If it 332 is ignored, the 6LoRHE is forwarded with no change inside the LLN. 334 0 1 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 337 |1|0|1| Length | Type | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 339 <-- Length --> 341 Figure 3: Elective 6LoWPAN Routing Header 343 Length: 344 Length of the 6LoRHE expressed in bytes, excluding the first 2 345 bytes. This is done to enable a node to skip a 6LoRH that it does 346 not support and/or cannot parse, for instance if the Type is not 347 known. 349 Type: 350 Type of the 6LoRHE 352 5.2. Critical Format 354 In its canonical form, the 6LoRHC uses the Dispatch Value Bit Pattern 355 of 100xxxxx. 357 A node which does not support the 6LoRHC Type MUST silently discard 358 the packet. 360 Note: there is no provision for the exchange of error messages; such 361 a situation should be avoided by judicious use of administrative 362 control and/or capability indications. 364 0 1 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 367 |1|0|0| TSE | Type | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 369 <-- Length implied by Type/TSE --> 371 Figure 4: Critical 6LoWPAN Routing Header 373 TSE: 374 Type Specific Extension. The meaning depends on the Type, which 375 must be known in all of the nodes. The interpretation of the TSE 376 depends on the Type field that follows. For instance, it may be 377 used to transport control bits, the number of elements in an 378 array, or the length of the remainder of the 6LoRHC expressed in a 379 unit other than bytes. 381 Type: 382 Type of the 6LoRHC 384 6. The Routing Header Type 3 (RH3) 6LoRH 386 The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) is a Critical 387 6LoWPAN Routing Header that provides a compressed form for the RH3, 388 as defined in [RFC6554] for use by RPL routers. Routers that need to 389 forward a packet with a RH3-6LoRH are expected to be RPL routers and 390 expected to support this specification. If a non-RPL router receives 391 a packet with a RPI-6LoRH, this means that there was a routing error 392 and the packet should be dropped so the Type cannot be ignored. 394 0 1 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 397 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 400 Size indicates the number of compressed addresses 402 Figure 5: The RH3-6LoRH 404 The values for the RH3-6LoRH Type are an enumeration, 0 to 4. The 405 form of compression is indicated by the Type as follows: 407 +-----------+-----------+ 408 | Type | Size Unit | 409 +-----------+-----------+ 410 | 0 | 1 | 411 | 1 | 2 | 412 | 2 | 4 | 413 | 3 | 8 | 414 | 4 | 16 | 415 +-----------+-----------+ 417 Figure 6: The RH3-6LoRH Types 419 In the case of a RH3-6LoRH, the TSE field is used as a Size, which 420 encodes the number of hops minus 1; so a Size of 0 means one hop, and 421 the maximum that can be encoded is 32 hops. (If more than 32 hops 422 need to be expressed, a sequence of RH3-6LoRH can be employed.) 424 The next Hop is indicated in the first entry of the first RH3-6LoRH. 425 Upon reception, the entry is checked whether it refers to the 426 processing router itself. If it so, the entry is removed from the 427 RH3-6LoRH and the Size is decremented. If the Size is now zero, the 428 whole RH3-6LoRH is removed. If there is no more RH3-6LoRH, the 429 processing node is the last router on the way, which may or may not 430 be collocated with the final destination. 432 The last hop in the last RH3-6LoRH is the last router prior to the 433 destination in the LLN. So even when there is a RH3-6LoRH in the 434 frame, the address of the final destination is in the LoWPAN_IPHC 435 [RFC6282]. 437 If some bits of the first address in the RH3-6LoRH can be derived 438 from the final destination is in the LoWPAN_IPHC, then that address 439 may be compressed, otherwise is is expressed in full. Next addresses 440 only need to express the delta from the previous address. 442 All addresses in a RH3-6LoRH are compressed in a same fashion, down 443 to the same number of bytes per address. In order to get different 444 forms of compression, multiple consecutive RH3-6LoRH must be used. 446 7. The RPL Packet Information 6LoRH 448 [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) 449 as a set of fields that are to be added to the IP packets for the 450 purpose of Instance Identification, as well as Loop Avoidance and 451 Detection. 453 In particular, the SenderRank, which is the scalar metric computed by 454 an specialized Objective Function such as [RFC6552], indicates the 455 Rank of the sender and is modified at each hop. The SenderRank 456 allows to validate that the packet progresses in the expected 457 direction, either upwards or downwards, along the DODAG. 459 RPL defines the RPL Option for Carrying RPL Information in Data-Plane 460 Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 461 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes 462 per packet. 464 With [RFC6553], the RPL option is encoded as six Octets; it must be 465 placed in a Hop-by-Hop header that consumes two additional octets for 466 a total of eight. In order to limit its range to the inside the RPL 467 domain, the Hop-by-Hop header must be added to (or removed from) 468 packets that cross the border of the RPL domain. 470 The 8-bytes overhead is detrimental to the LLN operation, in 471 particular with regards to bandwidth and battery constraints. These 472 bytes may cause a containing frame to grow above maximum frame size, 473 leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn 474 cause even more energy spending and issues discussed in the LLN 475 Fragment Forwarding and Recovery 476 [I-D.thubert-6lo-forwarding-fragments]. 478 An additional overhead comes from the need, in certain cases, to add 479 an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is 480 needed when the router that inserts the Hop-by-Hop header is not the 481 source of the packet, so that an error can be returned to the router. 482 This is also the case when a packet originated by a RPL node must be 483 stripped from the Hop-by-Hop header to be routed outside the RPL 484 domain. 486 This specification defines an IPinIP-6LoRH in Section 8 for that 487 purpose, but it must be noted that stripping a 6LoRH does not require 488 a manipulation of the packet in the LOWPAN_IPHC, and thus, if the 489 source address in the LOWPAN_IPHC is the node that inserted the 490 IPinIP-6LoRH then this alone does not mandate an IPinIP-6LoRH. 492 As a result, a RPL packet may bear only a RPI-6LoRH and no IPinIP- 493 6LoRH. In that case, the source and destination of the packet are 494 located in the LOWPAN_IPHC. 496 As with [RFC6553], the fields in the RPI include an 'O', an 'R', and 497 an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), 498 and a 16-bit SenderRank. 500 The remainder of this section defines the RPI-6LoRH, a Critical 501 6LoWPAN Routing Header that is designed to transport the RPI in 502 6LoWPAN LLNs. 504 7.1. Compressing the RPLInstanceID 506 RPL Instances are discussed in [RFC6550], Section 5. A number of 507 simple use cases will not require more than one instance, and in such 508 a case, the instance is expected to be the global Instance 0. A 509 global RPLInstanceID is encoded in a RPLInstanceID field as follows: 511 0 1 2 3 4 5 6 7 512 +-+-+-+-+-+-+-+-+ 513 |0| ID | Global RPLInstanceID in 0..127 514 +-+-+-+-+-+-+-+-+ 516 Figure 7: RPLInstanceID Field Format for Global Instances 518 For the particular case of the global Instance 0, the RPLInstanceID 519 field is all zeros. This specification allows to elide a 520 RPLInstanceID field that is all zeros, and defines a I flag that, 521 when set, signals that the field is elided. 523 7.2. Compressing the SenderRank 525 The SenderRank is the result of the DAGRank operation on the rank of 526 the sender; here the DAGRank operation is defined in [RFC6550], 527 Section 3.5.1, as: 529 DAGRank(rank) = floor(rank/MinHopRankIncrease) 531 If MinHopRankIncrease is set to a multiple of 256, the least 532 significant 8 bits of the SenderRank will be all zeroes; by eliding 533 those, the SenderRank can be compressed into a single byte. This 534 idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE 535 as 256 and in [RFC6552] that defaults MinHopRankIncrease to 536 DEFAULT_MIN_HOP_RANK_INCREASE. 538 This specification allows to encode the SenderRank as either one or 539 two bytes, and defines a K flag that, when set, signals that a single 540 byte is used. 542 7.3. The Overall RPI-6LoRH encoding 544 The RPI-6LoRH provides a compressed form for the RPL RPI. Routers 545 that need to forward a packet with a RPI-6LoRH are expected to be RPL 546 routers and expected to support this specification. If a non-RPL 547 router receives a packet with a RPI-6LoRH, this means that there was 548 a routing error and the packet should be dropped so the Type cannot 549 be ignored. 551 Since the I flag is not set, the TSE field does not need to be a 552 length expressed in bytes. The field is fully reused for control 553 bits so as to encode the O, R and F flags from the RPI, and the I and 554 K flags that indicate the compression that is taking place. 556 The Type for the RPI-6LoRH is 5. 558 The RPI-6LoRH is immediately followed by the RPLInstanceID field, 559 unless that field is fully elided, and then the SenderRank, which is 560 either compressed into one byte or fully in-lined as the whole 2 561 bytes. The I and K flags in the RPI-6LoRH indicate whether the 562 RPLInstanceID is elided and/or the SenderRank is compressed and 563 depending on these bits, the Length of the RPI-6LoRH may vary as 564 described hereafter. 566 0 1 2 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 569 |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 572 Figure 8: The Generic RPI-6LoRH Format 574 O, R, and F bits: 575 The O, R, and F bits as defined in [RFC6550], Section 11.2. 577 I bit: 578 If it is set, the Instance ID is elided and the RPLInstanceID 579 is the Global RPLInstanceID 0. If it is not set, the octet 580 immediately following the type field contains the RPLInstanceID 581 as specified in [RFC6550] section 5.1. 583 K bit: 584 If it is set, the SenderRank is be compressed into one octet, 585 and the lowest significant octet is elided. If it is not set, 586 the SenderRank, is fully inlined as 2 octets. 588 In Figure 9, the RPLInstanceID is the Global RPLInstanceID 0, and the 589 MinHopRankIncrease is a multiple of 256 so the least significant byte 590 is all zeros and can be elided: 592 0 1 2 593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 I=1, K=1 599 Figure 9: The most compressed RPI-6LoRH 601 In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, but 602 both bytes of the SenderRank are significant so it can not be 603 compressed: 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 I=1, K=0 612 Figure 10: Eliding the RPLInstanceID 614 In Figure 11, the RPLInstanceID is not the Global RPLInstanceID 0, 615 and the MinHopRankIncrease is a multiple of 256: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 I=0, K=1 624 Figure 11: Compressing SenderRank 626 In Figure 12, the RPLInstanceID is not the Global RPLInstanceID 0, 627 and both bytes of the SenderRank are significant: 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-... 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 ...-Rank | 635 +-+-+-+-+-+-+-+-+ 636 I=0, K=0 638 Figure 12: Least compressed form of RPI-6LoRH 640 A typical packet in RPL non-storing mode going down the RPL graph 641 requires an IPinIP encapsulating the RH3, whereas the RPI is usually 642 omitted, unless it is important to indicate the RPLInstanceID. To 643 match this structure, an optimized IPinIP 6LoRH is defined in 644 Section 8. 646 And the types include the setting of I and K as follows: 648 +-----------+-------+-------+ 649 | Type | I | K | 650 +-----------+-------+-------+ 651 | 5 | 0 | 0 | 652 | 6 | 0 | 1 | 653 | 7 | 1 | 0 | 654 | 8 | 1 | 1 | 655 +-----------+-------+-------+ 657 Figure 13: The RPI-6LoRH Types 659 8. The IP-in-IP 6LoRH 661 The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN Routing 662 Header that provides a compressed form for the encapsulating IPv6 663 Header in the case of an IP-in-IP encapsulation. 665 An IPinIP encapsulation is used to insert a field such as a Routing 666 Header or an RPI at a router that is not the source of the packet. 667 In order to send an error back regarding the inserted field, the 668 address of the router that performs the insertion must be provided. 670 The encapsulation can also enable a router down the path removing a 671 field such as the RPI, but this can be done in the compressed form by 672 removing the RPI-6LoRH, so an IPinIP-6LoRH encapsulation is not 673 required for that sole purpose. 675 This field is not critical for routing so the Type can be ignored, 676 and the TSE field contains the Length in bytes. 678 0 1 2 679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 681 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 684 Figure 14: The IPinIP-6LoRH 686 The Length of an IPinIP-6LoRH is expressed in bytes and MUST be at 687 least 1, to indicate a Hop Limit (HL), that is decremented at each 688 hop. When the HL reaches 0, the packet is dropped per [RFC2460] 690 If the Length of an IPinIP-6LoRH is exactly 1, then the Encapsulator 691 Address is elided, which means that the Encapsulator is a well-known 692 router, for instance the root in a RPL graph. 694 If the Length of an IPinIP-6LoRH is strictly more than 1, then an 695 Encapsulator Address is placed in a compressed form after the Hop 696 Limit field. The value of the Length indicates which compression is 697 performed on the Encapsulator Address. For instance, a Size of 3 698 indicates that the Encapsulator Address is compressed to 2 bytes. 700 When it cannot be elided, the destination IP address of the IP-in-IP 701 header is transported in a RH3-6LoRH as the first address of the 702 list. 704 With RPL, the destination address in the IP-in-IP header is 705 implicitly the root in the RPL graph for packets going upwards, and 706 the destination address in the IPHC for packets going downwards. If 707 the implicit value is correct, the destination IP address of the IP- 708 in-IP encapsulation can be elided. 710 If the final destination of the packet is a leaf that does not 711 support this specification, then the chain of 6LoRH must be stripped 712 by the RPL/6LR router to which the leaf is attached. In that 713 example, the destination IP address of the IP-in-IP header cannot be 714 elided. 716 In the special case where the 6LoRH is used to route 6LoWPAN 717 fragments, the destination address is not accessible in the IPHC on 718 all fragments and can be elided only for the first fragment and for 719 packets going upwards. 721 9. Security Considerations 723 The security considerations of [RFC4944], [RFC6282], and [RFC6553] 724 apply. 726 Using a compressed format as opposed to the full in-line format is 727 logically equivalent and does not create an opening for a new threat 728 when compared to [RFC6550], [RFC6553] and [RFC6554]. 730 10. IANA Considerations 732 This document creates a IANA registry for the 6LoWPAN Routing Header 733 Type, and assigns the following values: 735 0..4 : RH3-6LoRH [RFCthis] 737 5 : RPI-6LoRH [RFCthis] 739 6 : IPinIP-6LoRH [RFCthis] 741 11. Acknowledgments 743 The authors wish to thank Martin Turon, James Woodyatt, Samita 744 Chakrabarti, Jonathan Hui, Gabriel Montenegro and Ralph Droms for 745 constructive reviews to the design in the 6lo Working Group. The 746 overall discussion involved participants to the 6MAN, 6TiSCH and ROLL 747 WGs, thank you all. Special thanks to the chairs of the ROLL WG, 748 Michael Richardson and Ines Robles, and Brian Haberman, Internet Area 749 A-D, and Adrian Farrel, Routing Area A-D, for driving this complex 750 effort across Working Groups and Areas. 752 12. References 754 12.1. Normative References 756 [IEEE802154] 757 IEEE standard for Information Technology, "IEEE std. 758 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 759 and Physical Layer (PHY) Specifications for Low-Rate 760 Wireless Personal Area Networks", 2015. 762 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 763 Requirement Levels", BCP 14, RFC 2119, 764 DOI 10.17487/RFC2119, March 1997, 765 . 767 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 768 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 769 December 1998, . 771 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 772 "Transmission of IPv6 Packets over IEEE 802.15.4 773 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 774 . 776 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 777 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 778 DOI 10.17487/RFC6282, September 2011, 779 . 781 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 782 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 783 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 784 Low-Power and Lossy Networks", RFC 6550, 785 DOI 10.17487/RFC6550, March 2012, 786 . 788 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 789 Protocol for Low-Power and Lossy Networks (RPL)", 790 RFC 6552, DOI 10.17487/RFC6552, March 2012, 791 . 793 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 794 Power and Lossy Networks (RPL) Option for Carrying RPL 795 Information in Data-Plane Datagrams", RFC 6553, 796 DOI 10.17487/RFC6553, March 2012, 797 . 799 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 800 Routing Header for Source Routes with the Routing Protocol 801 for Low-Power and Lossy Networks (RPL)", RFC 6554, 802 DOI 10.17487/RFC6554, March 2012, 803 . 805 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 806 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 807 2014, . 809 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 810 Constrained-Node Networks", RFC 7228, 811 DOI 10.17487/RFC7228, May 2014, 812 . 814 12.2. Informative References 816 [I-D.bergmann-bier-ccast] 817 Bergmann, O., Bormann, C., and S. Gerdes, "Constrained- 818 Cast: Source-Routed Multicast for RPL", draft-bergmann- 819 bier-ccast-00 (work in progress), November 2014. 821 [I-D.ietf-6tisch-architecture] 822 Thubert, P., "An Architecture for IPv6 over the TSCH mode 823 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 824 in progress), May 2015. 826 [I-D.ietf-6tisch-tsch] 827 Watteyne, T., Palattella, M., and L. Grieco, "Using 828 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 829 Statement and Goals", draft-ietf-6tisch-tsch-06 (work in 830 progress), March 2015. 832 [I-D.thubert-6lo-forwarding-fragments] 833 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 834 Recovery", draft-thubert-6lo-forwarding-fragments-02 (work 835 in progress), November 2014. 837 [I-D.wijnands-bier-architecture] 838 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 839 S. Aldrin, "Multicast using Bit Index Explicit 840 Replication", draft-wijnands-bier-architecture-05 (work in 841 progress), March 2015. 843 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 844 Bormann, "Neighbor Discovery Optimization for IPv6 over 845 Low-Power Wireless Personal Area Networks (6LoWPANs)", 846 RFC 6775, DOI 10.17487/RFC6775, November 2012, 847 . 849 Authors' Addresses 851 Pascal Thubert (editor) 852 Cisco Systems 853 Village d'Entreprises Green Side 854 400, Avenue de Roumanille 855 Batiment T3 856 Biot - Sophia Antipolis 06410 857 FRANCE 859 Phone: +33 4 97 23 26 34 860 Email: pthubert@cisco.com 861 Carsten Bormann 862 Universitaet Bremen TZI 863 Postfach 330440 864 Bremen D-28359 865 Germany 867 Phone: +49-421-218-63921 868 Email: cabo@tzi.org 870 Laurent Toutain 871 Institut MINES TELECOM; TELECOM Bretagne 872 2 rue de la Chataigneraie 873 CS 17607 874 Cesson-Sevigne Cedex 35576 875 France 877 Email: Laurent.Toutain@telecom-bretagne.eu 879 Robert Cragie 880 ARM Ltd. 881 110 Fulbourn Road 882 Cambridge CB1 9NJ 883 UK 885 Email: robert.cragie@gridmerge.com