idnits 2.17.1 draft-hudson-ayers-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 682: '... following bytes MUST be encoded using...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 204 has weird spacing: '...ciently via...' -- The document date (June 29, 2018) is 2127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6282' is mentioned on line 120, but not defined == Missing Reference: 'RFC 6775' is mentioned on line 120, but not defined == Missing Reference: 'RFC4861' is mentioned on line 799, but not defined == Unused Reference: 'RFC4919' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RIOT' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'CONTIKI' is defined on line 839, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Hudson Ayers 3 Intended Status: Informational Paul Crews 4 Expires: December 31, 2018 Hubert Teo 5 Conor McAvity 6 Amit Levy 7 Philip Levis 8 Stanford University 9 June 29, 2018 11 Design Considerations For Low Power Internet Protocols 12 draft-hudson-ayers-00 14 Abstract 16 This document discusses guidelines for specifying low-power Internet 17 protocols in order to improve implementation interoperability. These 18 guidelines are based around the importance of balancing memory usage 19 and energy efficiency, and the importance of not relying on Postel's 20 law when dealing with low resource devices. This document applies 21 these guidelines to the IPv6 over low-power wireless personal area 22 networks (6LoWPAN) Internet Standard, suggesting changes that would 23 make it more likely for implementations to interoperate. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on 48 Copyright and License Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. 6LoWPAN Interoperability Study . . . . . . . . . . . . . . . . 4 68 2.1 Incomplete Implementations . . . . . . . . . . . . . . . . 5 69 2.2 Unrealistic Bounds . . . . . . . . . . . . . . . . . . . . 6 70 2.2.1 Maximum Header Decompression . . . . . . . . . . . . . . 6 71 2.2.2 Arbitrary Next Header Compression . . . . . . . . . . . 6 72 2.3 No Pairing Interoperates . . . . . . . . . . . . . . . . . 7 73 3 Implementation Concerns . . . . . . . . . . . . . . . . . . . . 9 74 3.1 Processor Resources . . . . . . . . . . . . . . . . . . . . 9 75 5 Contributing Factors . . . . . . . . . . . . . . . . . . . . . . 11 76 6 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1 Guideline 1: Capability Spectrum . . . . . . . . . . . . . . 11 78 6.1.1 Guideline 1 Application to 6LoWPAN . . . . . . . . . . . 12 79 6.2 Guideline 2: Capability Discovery . . . . . . . . . . . . . 13 80 6.2.1 Guideline 2 Application to 6LoWPAN . . . . . . . . . . . 13 81 6.3 Guideline 3: Provide Reasonable Bounds . . . . . . . . . . . 14 82 6.3.1 Guideline 3 Application to 6LoWPAN . . . . . . . . . . . 14 83 6.4 Guideline 4: Don't Break Layering . . . . . . . . . . . . . 15 84 6.4.1 Guideline 4 Application to 6LoWPAN . . . . . . . . . . . 16 85 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 86 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 87 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 9.1 Normative References . . . . . . . . . . . . . . . . . . . 18 89 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 92 1 Introduction 94 Interoperability is critical for the Internet. Not only do edge- 95 devices need to interoperate with the broader Internet, they should 96 also interoperate with other devices in the same network. 97 Historically, though, embedded systems and sensor networks have been 98 vertical silos of proprietary technologies, each using custom network 99 protocols and homogeneous implementations. Networks typically require 100 specialized gateways and cannot easily include devices from different 101 vendors for a variety of applications. 103 Interoperability is just as important in the Internet of Things, but 104 end hosts in the Internet of Things are less resourceful, more 105 diverse in capability, and less well audited than typical Internet 106 end hosts. Using IP allows devices from different manufacturers, 107 running completely different software stacks, to interoperate, share 108 services, and compose into larger, more complex applications. This 109 interoperability should exist not only between IoT devices 110 communicating with hosts across the broader Internet, but also 111 between IoT devices in the same low power wireless network. The 112 presence of such interoperability precludes the need for multiple 113 gateways to support different devices, simplifies network management, 114 and allows for efficient, logical communication between nearby 115 devices. 117 To address this problem, the IETF published a series of RFCs 118 detailing a standard format for transmitting IPv6 packets over low- 119 power wireless link layers such as IEEE 802.15.4 {RFC 4919][RFC 120 4944][RFC 6282][RFC 6775]. The 6LoWPAN RFCs define a fragmentation 121 format, a compression format, and more. These 6LoWPAN standards have 122 been adopted by a number of popular embedded operating systems, 123 including Contiki {CONTIKI], RiotOS {RIOT], OpenThread [OPENTHREAD], 124 mbedOS [ARM], and TinyOS [TINYOS]. 126 Unfortunately, none of these implementations are complete. Each 127 implementation supports different subsets of 6LoWPAN. As a result, 128 devices built using different embedded operating systems cannot 129 interoperate. In fact, for every possible pairing, one implementation 130 is likely to transmit 6LoWPAN packets which the other cannot process. 132 This paper explores the reasons behind the lack of interoperability 133 in practice, and argues that this results from the protocol too 134 heavily prioritizing radio efficiency over processor resources, and 135 failing to consider the broad range of devices which embedded 136 operating systems will attempt to support. This document proposes 137 four guidelines for designing interoperable protocols for low-power 138 wireless networks, and explain them through an example application to 139 two 6LoWPAN standards - RFC 4944 and RFC 6282. These guidelines are 140 informed by an empirical analysis of existing 6LoWPAN implementations 141 as well as experience implementing a full 6LoWPAN stack for the Tock 142 operating system [TOCK]. 144 1.1 Terminology 146 Readers are expected to be familiar with all terms and concepts 147 discussed in "IPv6 over Low-Power Wireless Personal Area Networks 148 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", 149 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 150 "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 151 Networks". 153 Readers would benefit from reading 6LoWPAN Neighbor Discovery (ND), 154 6LoWPAN routing requirements, and 6LoWPAN design/application spaces 155 for additional details of 6LoWPAN work. 157 2. 6LoWPAN Interoperability Study 159 The IETF's 6LoWPAN working group has been concerned with 160 interoperability between implementation since inception [6LO-CHART]. 161 Indeed, members of the working group have organized ``Plugtests'', 162 where vendors verified correct implementation of the 6LowPAN 163 specifications and tested interoperability with other vendors. 164 Unfortunately, detailed results of these plugtests are not publicly 165 available. 167 A node sending IPv6 packets using 6LoWPAN may fragment the packet or 168 compress headers in a large number of ways permitted by the 169 specification. These choices depend both on the properties of the 170 packet (e.g. whether it is a UDP packet or if the origin and 171 destinations are in the same subnet) as well as on which compression 172 and fragmentation options the sender chooses to use. For two nodes to 173 interoperate, the 6LoWPAN implementation on each node must be able to 174 receive any packet the other node might send. 176 This document investigates the interoperability of 6LoWPAN 177 implementations from five common embedded software platforms: Riot 178 OS, Contiki, OpenThread, TinyOS, and ARM Mbed. This study is 179 concerned, specifically, with each implementation's ability to 180 receive and decode 6LoWPAN packets sent from other implementations. 181 This document does not explore whether devices built using these 182 implementations could form a network in the first place, since 183 6LoWPAN leaves much of the network formation process (e.g. discovery 184 and joining) unspecified. 186 The compatibility analysis in this document, between five common 187 embedded software frameworks with 6LoWPAN implementations, is based 188 in three discoveries. First, a determination of how completely each 189 implementation implements the 6LoWPAN specification was obtained by 190 directly examining their source code. Second, this code analysis was 191 extended to verify that under some circumstances, each implementation 192 sends packets using compression or fragmentation options which 193 another implementation cannot decode. Finally, it was discovered that 194 even in cases where two implementations use compatible compression 195 and fragmentation options, different implementation choices, such as 196 header decompression bounds, limit their interoperability. 198 As a result, no pairing of these five implementations is fully 199 interoperable. 201 2.1 Incomplete Implementations 203 The 6LoWPAN protocol consists of a large number of complex and mostly 204 independent features which use the link-layer frame efficiently via 205 compression and fragmentation optimizations. Examining the code and 206 documentation for each of the aforementioned 6LoWPAN stacks reveals 207 that the stacks do not uniformly implement the specification. In 208 fact, each specification implements a different subset of the 209 requirements in the 6LoWPAN specification, and none implements the 210 entire specification to the letter. A visualization of the 211 mismatched feature support across different 6LoWPAN implementations 212 can be found in Table 1. Note that OT is an abbreviation used 213 throughout this document to refer to OpenThread. 215 +----------------------------------------+-------+--+----+---+------+ 216 | Feature | Stack | 217 +----------------------------------------+-------+--+----+---+------+ 218 | |Contiki|OT|Riot|Arm|TinyOS| 219 +----------------------------------------+-------+--+----+---+------+ 220 | Uncompressed IPv6 | o | | o | o | o | 221 | 6LoWPAN Fragmentation | o |o | o | o | o | 222 | 1280 byte packets | o |o | o | o | o | 223 | Dispatch_IPHC header prefix | o |o | o | o | o | 224 | IPv6 Stateless Address Compression | o |o | o | o | o | 225 | Stateless multicast address compression| o |o | o | o | o | 226 | 802.15.4 16 bit short address support | |o | o | o | o | 227 | IPv6 Address Autoconfiguration | o |o | o | o | o | 228 | IPv6 Stateful Address Compression | o |o | o | o | o | 229 | Stateful multicast address compression | |o | o | o | | 230 | IPv6 TC and Flow label compression | o |o | o | o | o | 231 | IPv6 NH Compression: Tunneled IPv6 | |o | | o | o | 232 | IPv6 NH Compression: UDP | o |o | o | o | o | 233 | UDP port compression | o |o | o | o | o | 234 | UDP checksum elision | | | | | o | 235 | Compression + headers past first frag | | | | | | 236 +----------------------------------------+-------+--+----+---+------ 238 Table 1: 6LoWPAN Interoperability Matrix 240 2.2 Unrealistic Bounds 242 Beyond the variation in what portions of the 6LoWPAN specification 243 each stack implements, there also exists significant variation in how 244 each stack handles certain implementation-specific details. Some of 245 these details have little impact on interoperability, such as 246 decisions regarding how many fragments a stack holds for a given 247 packet before dropping all of them, whether to allow for 248 reconstruction of multiple packets simultaneously, and how long to 249 hold onto fragments for which the rest of the packet has not yet 250 arrived. Other details, however, differ in ways that significantly 251 affect interoperability between stacks. A discussion of two such 252 details follows: 254 2.2.1 Maximum Header Decompression 256 Each of the stacks analyzed imposes some limit on the maximum amount 257 of header decompression possible for a received packet. Such a limit 258 is necessary to ensure that packet and fragment buffers within a 259 stack are large enough for received packets. The maximum amount of 260 header decompression allowed by the 6LoWPAN specification is about 261 1200 bytes, basically, if an entire MSS IPv6 packet was sent 262 containing only compressed headers. Some of the stacks analyzed 263 decompress fragments directly into the MSS buffer which will 264 eventually contain the entire IPv6 packet, and thus support this 265 bound. Other stacks impose significantly lower limits - limits low 266 enough that packets could easily be constructed within the 6LoWPAN 267 specification that would exceed these limits. For example, Contiki's 268 limit of 38 bytes of header decompression is exceeded by any packet 269 for which the IP header is maximally compressed (38 bytes) and the 270 UDP header is compressed at all. Accordingly, certain stacks would 271 send packets with a significant amount of header compression, but 272 other stacks would silently drop these packets due to lacking buffer 273 space for fragments requiring that much decompression. Furthermore, 274 these stacks do not given any indication back to the sender that a 275 packet has been dropped for this reason, making it difficult for the 276 sending stack to identify how to adjust its transmission to 277 successfully deliver data. 279 2.2.2 Arbitrary Next Header Compression 281 Several of the 6LoWPAN stacks also impose limits on the arbitrary 282 compression/decompression of IPv6 extension headers and next headers 283 required by the specification. The headers which must be handled are 284 as follows: 286 - IPv6 Hop-By-Hop Options Header 288 - IPv6 Routing Header 290 - IPv6 Fragment Header 292 - IPv6 Destination Options Header 294 - IPv6 Mobility Header 296 - IPv6 Next Header 298 - UDP Next Header 300 Further, 6LoWPAN implementations are expected to be able to 301 decompress at least one of each of these headers, and up to two 302 Destination Options headers, in almost any order. Handling all of 303 these possible cases can result in complex state machines, convoluted 304 code, and increase in code size and RAM use. Therefore, several of 305 the stacks examined impose a limit on this arbitrary next header 306 decompression - namely, Contiki and Riot. Both of these stacks only 307 check for the UDP Next Header. This greatly simplifies the code 308 required for decompression of next headers in these stacks as 309 compared to the others, which require recursion to handle this 310 arbitrary compression. The offshoot of this simplified code, however, 311 is that these stacks will drop packets with certain compressed 312 extension header configurations when other stacks send such messages. 314 2.3 No Pairing Interoperates 316 These interoperability concerns are more than theoretical: existing 317 6LoWPAN stacks generate valid packets that other stacks discard. This 318 proves that missing receive functionality is not simply a case of 319 limited 6LoWPAN stacks abstaining from handling packets which no 320 existing stacks ever generate. 322 What follows is a listing of each of the 10 possible combinations of 323 6LoWPAN stacks, accompanied by a single example packet which can be 324 generated by one of the stacks in the pairing which the other stack 325 would not receive. 327 Contiki, OpenThread : Contiki generated message using uncompressed 328 IPv6 329 Contiki, Riot: Riot generated message using stateful multicast 330 address compression 332 Contiki, Mbed: Mbed generated message using compresesd, tunneled IPv6 334 Contiki, TinyOS: TinyOS generated message containing compressed IPv6 335 extension headers 337 OpenThread, Riot: OpenThread generated message containing any of the 338 IPv6 extension headers, which the OpenThread stack automatically 339 compresses 341 OpenThread, Mbed: Mbed generated IPv6 packet containing the IPv6 342 mobility header 344 OpenThread, TinyOS: OpenThread generated message for which the 345 destination address is compressed using stateful multicast 346 compression 348 Riot, Mbed: Mbed generated IPv6 message containing any compressed 349 next header other than the UDP header 351 Riot, TinyOS: Riot generated message for which the destination 352 address is compressed using stateful multicast compression 354 Mbed, TinyOS: Mbed generated Neighbor Discovery message using the 355 6LoWPAN context option as specified in RFC 6775. 357 This is a non-exhaustive listing, and for most of these pairings 358 several message formats exist which could be generated by one that 359 would be dropped by the other. Each instance for which a claim is 360 made that packets could be easily generated has been verified via 361 code analysis. 363 In addition to this code analysis, tests were performed to present 364 further evidence that several of these packets formats could easily 365 be generated via typical use of these 6LoWPAN stacks. 367 These tests involved slightly modifying basic example networking apps 368 on each stack, such that the existing 6LoWPAN interface could be used 369 to send certain packets. These modified examples were flashed onto 370 embedded hardware platforms supported by each. The transmitted 371 packets were captured using a wireless packet sniffer, and the 372 sniffed packets analyzed using Wireshark. This exercise verified that 373 these non-interoperable packets could in fact be sent. Further 374 description of this hardware generation of select packets can be 375 found in [DESIGN]. 377 3 Implementation Concerns 379 The 6LoWPAN specification was created with a clear goal---to allow 380 for IPv6 connectivity over a link-layer with an order of magnitude 381 smaller frame sizes than Ethernet. Unfortunately, fragmented IPv6 on 382 its own requires header overhead much greater than typical wireless 383 protocols designed for low power devices. As a result, the 384 specification places an extreme focus on minimizing protocol overhead 385 and, thus, radio utilization. 387 The primary problem with 6LoWPAN is that this focus was taken too 388 far. This focus has resulted in complex implementations that require 389 significant processor resources. In order for devices to 390 interoperate, they must be able to parse any valid received 6LoWPAN 391 packet that might be sent by others. 393 In practice, many 6LoWPAN implementations do not implement the entire 394 specification and, therefore, are not interoperable. This is not a 395 result of poor software design, but rather intentional choices to 396 implement different subsets of the specification that favor limited 397 RAM and code size, security concerns, and minimizing engineering 398 effort. 400 In fact, in some cases even these incomplete 6LoWPAN implementations 401 systems are too resource intensive for some devices. As a result, 402 several implementations allow the developer to remove portions of the 403 6LoWPAN stack during compilation. Even when implementations use 404 overlapping portions of the specification, additional 405 interoperability conflicts arise from different choices of memory 406 bounds for decompression. 408 3.1 Processor Resources 410 Evidence that developers of these 6LoWPAN stacks were concerned about 411 6LoWPAN's consumption of processor resources is baked into the design 412 of each. One of the primary indicators that each implementation was 413 concerned with code size is the prevalence of options to compile 414 limited subsets of the 6LoWPAN stack. For example, Contiki defines 415 the SICSLOWPAN_CONF_COMPRESSION compilation flag, which can be set to 416 force all Contiki packets (sent and received!) to be processed as 417 uncompressed IPv6. Riot presents extensive compilation options for 418 6LoWPAN, allowing for the exclusion of all IPHC compression, the 419 exclusion of context based compression alone, the exclusion of 420 fragmentation, the exclusion of ND, and the exclusion of next header 421 compression. The Mbed stack allows users to exclude elements of the 422 IPv6 stack such as security features, routing specific features, 423 link-layer features, and more. Further, Mbed defines macros which can 424 be used to save RAM at the expense of flash, or vice-versa. TinyOS by 425 default removes all code in a stack that is not being used by an 426 application, and this can easily be observed by compiling different 427 6LoWPAN application binaries. 429 Table 2 shows the code size overhead of each of the five 430 implementations broken into independent overheads for compression, 431 fragmentation, mesh and broadcast headers, as well as totals for 432 6LoWPAN and the entire networking stack including physical layer 433 drivers, IPv6, UDP, ICMP, etc. 435 +----------+--------+---------+-------------+------+----------------+ 436 | Stack | Code Size Measurements (Bytes) | 437 +----------+--------+---------+-------------+------+----------------+ 438 | | IP-All | 6Lo-All | Compression | Frag | Mesh/Bcast Hdr | 439 +----------+--------+---------+-------------+------+----------------+ 440 | Contiki | 37538 | 11262 | 5952 | 3319 | N/A | 441 | OT | 42262 | 26375 | 4146-20000 | 1310 | 4500 | 442 | Riot | 30942 | 7500 | >4712 | 1514 | N/A | 443 | Arm Mbed | 46030 | 22061 | 17900 | 3104 | 1331 | 444 | TinyOS | 37312 | 16174 | ---- | ---- | 600 | 445 +----------+--------+---------+-------------+------+----------------+ 447 Table 2: 6LoWPAN Stack Code Size 449 The methodology use to collect these values can be found in [DESIGN]. 450 These results likely overestimate the overhead of fragmentation and 451 underestimate the overhead of certain kinds of compression since some 452 of the complexity of compression is born on the fragmentation logic. 453 Moreover, for OpenThread and Arm Mbed, which required manual 454 examination of binaries, the results almost certainly underestimate 455 the overhead of all 6LoWPAN components since we only counted 456 procedures which unambiguously implemented particular functionality, 457 though some of the complexity is implemented in other portions of the 458 stack. In summary: 460 - 6LoWPAN stack developers were concerned with processor resource 461 requirements of the protocol. 463 - Fragmentation, the only portion of 6LoWPAN that's strictly 464 necessary for sending IPv6 packets, consumes significantly less 465 ROM than compression. 467 - Implementations with more complete adherence to compression 468 specification consume more code for compression 470 - Mesh and broadcast headers are relatively expensive given that 471 few real-world applications use them 473 5 Contributing Factors 475 Several fundamental factors contributed to 6LoWPAN's interoperability 476 problems. 478 When writing low power networking specifications, an important 479 "slider'' exists - the tradeoff between code size and protocol 480 efficiency. This tradeoff is similar to the historically significant 481 tradeoff between RAM and code size. Techniques such as advanced MAC 482 and physical layers, and tracking the state of a network can reduce 483 packet sizes and, thus, radio energy consumption. However, these 484 techniques typically require larger and more complex 485 implementations. 487 Even moving beyond the constraints of code size, added complexity 488 harms interoperability in the general case, and complex 489 implementations are undesirable in the space of low power embedded 490 devices. Finally, 6LoWPAN failed to consider the reality that some 491 implementations of the protocol may be incomplete, and accordingly 492 failed to include any affirmative indications of interoperability 493 failures, with interoperability failures instead only being visible 494 as silent packet drops. All of these factors contributed to 6LoWPAN's 495 interoperability problems, and inspire the guidelines that follow. 497 6 Design Guidelines 499 This section describes four protocol design guidelines which, if 500 followed, lead to low-power protocols that are more likely to have 501 interoperable implementations. In the next section, these are 502 further explained by showing how each can be applied to 6LoWPAN. 504 6.1 Guideline 1: Capability Spectrum 506 A low power protocol should be implementable on devices which are at 507 the low end of code and RAM resources. Rather than require every 508 device pay the potential energy costs of fewer optimizations, a 509 protocol should support a spectrum of device capabilities. This 510 spectrum defines a clear ordering via which especially resource 511 constrained devices can reduce code size or RAM use by eliding 512 features. Such a spectrum makes a protocol usable by extremely low 513 resource devices without forcing more resourceful devices to 514 communicate inefficiently. 516 This capability spectrum should be a linear scale. For a device to 517 support capability level N, it must also support all lower capability 518 levels. More complex configuration approaches (e.g., a set of 519 independent options) would allow for a particular application or 520 implementation to be more efficient, picking the features that give 521 the most benefit at the least complexity cost. However, this sort of 522 optimization then makes interoperability more difficult, as two 523 devices must negotiate which features to use. 525 6.1.1 Guideline 1 Application to 6LoWPAN 527 Application of this guideline would require replacing the large 528 collection of "MUST'' requirements - those "features'' in Table 1 - 529 into 6 levels of functionality. These levels prioritize features that 530 provide the best packet size savings given the resulting 531 implementation complexity. For example, the greatest savings results 532 from compressing 128-bit IPv6 addresses. 534 0. Uncompressed IPv6 536 0a. Uncompressed IPv6 538 0b. 6LoWPAN Fragmentation and the Fragment Header 540 0c.1280 Byte Packets 542 1. IPv6 Compression Basics + Stateless Address Compression 544 1a. Support for the Dispatch_IPHC Header Prefix 546 1b. Correctly handle elision of IPv6 length and version 548 1c. Stateless compression of unicast addresses 550 1d. Stateless compression of multicast addresses 552 1e. Compression even when 16 bit addresses are used at the link 553 layer 555 1f. IPv6 address autoconfiguration 557 2. Stateful IPv6 Address Compression 559 2a. Stateful compression of unicast addresses 561 2b. Stateful compression of multicast addresses 563 3. IPv6 Traffic Class and Flow Label Compression 565 3a. Traffic Class compression 3b. Flow Label Compression 3c. Hop 566 Limit Compression 568 4. IPv6 and UDP NH Compression + UDP Port Compression 569 4a. Handle Tunneled IPv6 correctly 571 4b. Handle the compression of the UDP Next Header 573 4c. Correctly handle elision of the UDP length field 575 4d. Correctly handle the compression of UDP ports 577 4e. Correctly handle messages for which headers go on 578 longer than the first fragment, and the headers in the first 579 fragment are compressed. 581 5. Entire Specification 583 5a. Support the broadcast header and the mesh header as 584 described in RFC 4944 586 5b Support compression of all IPv6 Extension headers 588 The classes in this scale do not precisely reflect the current 589 feature support of the implementations described above. For example, 590 Contiki supports UDP port compression (level 5) but does not support 591 802.15.4 short addresses (level 2) or tunneled IPv6 (level 5): 592 following this formulation, Contiki only provides level 1 support. If 593 Contiki supported 16-bit addresses, it would provide level 4 support. 595 The specific spectrum presented here is based off of measurements of 596 code size, the saved bits that each additional level of compression 597 allows for, and observations of existing 6LoWPAN implementations. 599 6.2 Guideline 2: Capability Discovery 601 The second guideline immediately follows from the first: if two 602 implementations may have different capability levels, there should be 603 an explicit mechanism by which two devices can efficiently discover 604 what level to use when they communicate 606 If two devices wish to communicate, they default to the lower of 607 their supported capability levels. For example, suppose a TinyOS 608 device supports level 2 and a Contiki device supports level 4; 609 Contiki must operate at level 2 when communicating with the TinyOS 610 device. This requires keeping only a few bits of state for any device 611 to communicate with. Also, note that this state is per-hop; for a 612 layer 3 protocol like IP, it is stored for link-layer neighbors (not 613 IP endpoints) and so does not require knowledge of the whole network. 615 6.2.1 Guideline 2 Application to 6LoWPAN 616 6lowpan could implement capability discovery using two mechanisms: 617 neighbor discovery (ND) and ICMP. Neighbor discovery allows devices 618 to probe and determine capability levels, while ICMP allows devices 619 to determine when incompatible features are used, or when ND is not 620 available. 622 Neighbor discovery: 6LoWPAN ND should add an option that allows a 623 device to communicate its capability class during association with a 624 network. The inclusion of a few extra bits in ND messages would allow 625 all devices that learn neighbor addresses via ND to also know how to 626 send packets which that neighbor can receive. This option minimizes 627 the energy cost of communicating capabilities. It is worth noting 628 that [RFC7400] already employs a similar method for communicating 629 whether devices implement General Header Compression: adding such an 630 option is clearly viable. 632 ICMP: All IPv6 devices are already required to support ICMP. A new 633 ICMPv6 message type - 6LoWPAN Class Unsupported - should be added, 634 which could be sent in response to messages received encoded using a 635 6LoWPAN class higher than the class of the receiving host. This 636 would allow for communication of capabilities even in networks not 637 constructed using IPv6 ND. This ICMPv6 message would allow hosts to 638 indicate exactly what class the receiving host does support, 639 preventing any need for repeated retransmissions using different 640 compression or fragmentation formats. 642 6.3 Guideline 3: Provide Reasonable Bounds 644 Specifications should impose reasonable bounds on recursive or 645 variable features so implementations can bound RAM use. These bounds 646 have two benefits. First, it allows implementations to safely limit 647 their RAM use without silent interoperability failures. E.g., today, 648 if an mbed device sends a 6lowpan packet whose compression is greater 649 than 38 bytes to a Contiki device, Contiki will silently drop the 650 packet. Second, it ensures that capability discovery is sufficient to 651 interoperate. 653 The original designers of a specification may not know exactly what 654 these values should be. This is not a new problem: TCP congestion 655 control, for example, had to specify initial congestion window 656 values. The bounds should initially be very conservative. Over time, 657 if increasing resources or knowledge suggests they should grow, then 658 future devices will have the onus of using fewer resources to 659 interoperate with earlier ones. 661 6.3.1 Guideline 3 Application to 6LoWPAN 663 Section 2 discussed two unreasonable bounds which affect 6LoWPAN 664 interoperability. The first is the 1280 byte bound on maximum header 665 decompression (the amount a header will grow when decompressed). A 666 bound allows implementations to conserve RAM. As a result, some 667 implementations impose their own lower bounds, but these bounds do 668 not agree so some stacks cannot decompress some packets sent by other 669 stacks. The lack of a bound on arbitrary next header compression was 670 demonstrated as adding significant complexity to implementations to 671 service packets which should rarely be used. 673 To address this, maximum header decompression in 6LoWPAN packets 674 should be bounded to 50 bytes. This bound allows for significant RAM 675 savings in implementations that decompress first fragments into the 676 same buffer in which the fragment was originally held prior to any 677 copying into a 1280 byte buffer. 679 Second, the requirement for compression of interior headers for 680 tunneled IPv6 should be removed. Currently, section 4.2 of RFC 6282 681 states "When the identified next header is an IPv6 Header...The 682 following bytes MUST be encoded using LOWPAN_IPHC''. This is 683 problematic because it places no bound on how many tunneled IPv6 684 headers may need to be compressed or decompressed, creating locations 685 in code that require unbounded amounts of recursion. Implementations 686 should adjust their path MTU constraints and responses to support 687 inserting source routing headers, rather than tunnel IPv6. 689 This change would limit the complexity of arbitrary next header 690 compression slightly. In addition, an ordering should be imposed on 691 the order of IPv6 extension options if they are to be compressed. 692 This would allow for implementations to avoid recursive functions to 693 decompress these headers, and instead use simple if/else statements. 694 If for some reason IPv6 extension headers must be placed in a 695 different order for a particular packet, those options must be sent 696 uncompressed. 698 6.4 Guideline 4: Don't Break Layering 700 Designers should ensure that interoperability is a central priority 701 for specifications throughout the design process, and that 702 interoperability is not simply assumed from the fact that devices 703 will be communicating via a shared protocol. In particular, 704 specifications should be careful that considerations introduced to 705 save energy in certain scenarios should not make assumptions about 706 the rest of the stack. Layering is a foundational network design 707 principle. As the difficulty NATs introduced to Internet connectivity 708 in the early 2000s demonstrated, breaking layering can introduce 709 unforeseen and extremely difficult to fix interoperability problems. 711 The appeal of cross-layer optimization in embedded systems is even 712 stronger than in traditional computers. Designed for a specific 713 application, a developer can understand and know exactly how the 714 entire system works, from hardware to application code. However, 715 while this whole-system knowledge makes sense for a particular device 716 or iteration of an application, long-lived systems will evolve and 717 change. This is especially true if the device will need to 718 interoperate with new gateways or application devices. Furthermore, 719 as embedded systems have grown more complex, their software has begun 720 to resemble more traditional systems. Rather than write software from 721 scratch every time, systems use and draw on existing operating 722 systems as well as libraries. By breaking layering, cross-layer 723 optimizations require that developers own and customize the entire 724 software stack. 726 6.4.1 Guideline 4 Application to 6LoWPAN 728 UDP checksum compression, as defined in section 4.3.2 of RFC 6282, 729 should be removed from the 6LoWPAN specification. The RFC says that a 730 higher layer may request the checksum be elided if it has an 731 integrity mechanism that covers the UDP header. At first glance, this 732 seems sufficient: if the UDP header is covered by a message integrity 733 code (MIC) or other checksum, then corrupted packets will be 734 correctly dropped. 736 However, it misses an important error case: if the UDP ports are 737 corrupted, then a packet missing a checksum may be delivered to the 738 wrong application, and this incorrect application may not impose a 739 replacement integrity measure or know one exists. It therefore cannot 740 verify the MIC. Furthermore, protecting the header with a link-layer 741 MIC is insufficient, as it only protects packets against sub-link 742 corruption. 744 The end-to-end principle [E2E], foundational to all modern network 745 design, says that only endpoints can verify correct communication. 746 The only place that can safely verify the UDP header is the UDP 747 stack. It is worth noting that the seminal example that led to 748 definition of the end-to-end principle was a memory corruption: 749 packets held in memory to be sent were corrupted before being sent. 750 The recommended workarounds in RFC 6282 are vulnerable to such an 751 event. A packet sent by an application that elides the UDP checksum 752 could be corrupted in memory before the link-layer MIC is computed. 753 Such a packet would be successfully received by the destination and 754 dispatched to the wrong application, which would not check the 755 application-level MIC. 757 The payoff of UDP checksum compression is not even significant - 2 758 bytes of checksum is a small portion of a 127 byte frame. The 759 problematic nature of UDP checksum compression is further 760 demonstrated by the fact that only one of the five stacks analyzed in 761 this document implements the feature. 763 7 Security Considerations 765 This informational document does have some implications for security 766 if followed. 768 First, capability advertisements of the type recommended in this 769 document are liable to leak some information regarding the type of 770 device sending those advertisements. In any situation for which this 771 information is priveleged, such advertisements must be suppressed. 773 Second, implementations should be careful not to take for granted 774 that the suggestions in this document will be implemented by all 775 other transmitting devices. Accordingly, though this document 776 recommends reasonable bounds, receivers still must be careful to 777 prevent buffer overflows in the event these bounds are not followed. 779 Finally, it is worth noting that breaking layering has clear security 780 implications, and that the recommendation in this document to avoid 781 this practice should be expected to improve security by allowing the 782 security protocols in place at individual layers to work as intended. 784 8 IANA Considerations 786 This is an informational document, and accordingly does not formally 787 request any IANA changes. However, it is worth noting that the 788 example application of the guidelines to 6LoWPAN would require some 789 changes by IANA, if actually implemented. 791 Namely, IANA would be requested to update some of the "6LoWPAN 792 Capability Bits" under the "Internet Control Message Protocol Version 793 6 (ICMPv6) Parameters" registry such that some of the unassigned bits 794 could be repurposed for capability advertisements as described in 795 this document. 797 Additionally, IANA would be requested to update the "IPv6 Neighbor 798 Discovery Option Formats" registry to include a new ND option format 799 for capability advertisements [RFC4861]. 801 9 References 803 9.1 Normative References 805 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 806 over Low-Power Wireless Personal Area Networks (6LoWPANs): 807 Overview, Assumptions, Problem Statement, and Goals", RFC 808 4919, DOI 10.17487/RFC4919, August 2007, . 811 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 812 "Transmission of IPv6 Packets over IEEE 802.15.4 813 Networks", RFC 4944, September 2007, . 816 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 817 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 818 September 2011, . 820 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 821 "Neighbor Discovery Optimization for IPv6 over Low-Power 822 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 823 November 2012, . 825 9.2 Informative References 827 [DESIGN] Ayers, H. et al., "Design Considerations for Low Power 828 Internet Protocols", Arxiv, June 2018. 830 [TINYOS] TinyOS Alliance, "TinyOS", 2018, 831 . 833 [ARM] ARM Mbed, "ARM Mbed OS", 2018, 834 . 836 [RIOT] FU Berlin, "Riot OS", 2018, . 839 [CONTIKI] Dunkels, A., "Contiki OS", 2018, 840 . 842 [OPENTHREAD] Nest, "OpenThread", 2018, 843 . 845 [TOCK] Levy, A., Campbell, B., Pannuto, P., Dutta, P., Levis, P., 846 "The Case for Writing a Kernel in Rust", APSys, 2017, 847 . 849 [6LO-CHART] Lemon, T., "IPv6 over Low power WPAN WG Charter", IETF, 850 2005, . 853 [E2E] Saltzer, J. H., Reed, D. P., Clark, D. D., "End-to-end 854 Arguments in System Design", ACM Trans. Comput. Syst., 855 November 1984. 857 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 858 IPv6 over Low-Power Wireless Personal Area Networks 859 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 860 2014, . 862 Authors' Addresses 864 Hudson Ayers 865 Stanford University 867 EMail: hayers@stanford.edu 869 Paul Crews 870 Stanford University 872 EMail: ptcrews@stanford.edu 874 Hubert Hua Kian Teo 875 Stanford University 877 EMail: hteo@stanford.edu 879 Conor McAvity 880 Stanford University 882 EMail: cmcavity@stanford.edu 884 Amit Levy 885 Stanford University 887 EMail: levya@cs.stanford.edu 889 Philip Levis 890 Stanford University 892 EMail: pal@stanford.edu