idnits 2.17.1 draft-bormann-lwig-7228bis-08.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 April 2022) is 752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-cbor-time-tag-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational M. Ersue 5 Expires: 7 October 2022 6 A. Keranen 7 Ericsson 8 C. Gomez 9 Universitat Politecnica de Catalunya 10 5 April 2022 12 Terminology for Constrained-Node Networks 13 draft-bormann-lwig-7228bis-08 15 Abstract 17 The Internet Protocol Suite is increasingly used on small devices 18 with severe constraints on power, memory, and processing resources, 19 creating constrained-node networks. This document provides a number 20 of basic terms that have been useful in the standardization work for 21 constrained-node networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 7 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 60 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 61 2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6 62 2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 8 64 2.3.3. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 66 3.1. Firmware/Software upgradability . . . . . . . . . . . . . 12 67 3.2. Isolation functionality . . . . . . . . . . . . . . . . . 13 68 3.3. Shielded secrets . . . . . . . . . . . . . . . . . . . . 13 69 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 14 70 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 14 71 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 15 72 4.3. Strategies for Using Power for Communication . . . . . . 16 73 4.4. Strategies of Keeping Time over Power Events . . . . . . 17 74 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 20 75 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 20 76 5.2. Class of Internet Integration . . . . . . . . . . . . . . 21 77 5.3. Classes of physical layer bit rate . . . . . . . . . . . 21 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 8. Informative References . . . . . . . . . . . . . . . . . . . 23 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 84 1. Introduction 86 Small devices with limited CPU, memory, and power resources, so- 87 called "constrained devices" (often used as sensors/actuators, smart 88 objects, or smart devices) can form a network, becoming "constrained 89 nodes" in that network. Such a network may itself exhibit 90 constraints, e.g., with unreliable or lossy channels, limited and 91 unpredictable bandwidth, and a highly dynamic topology. 93 Constrained devices might be in charge of gathering information in 94 diverse settings, including natural ecosystems, buildings, and 95 factories, and sending the information to one or more server 96 stations. They might also act on information, by performing some 97 physical action, including displaying it. Constrained devices may 98 work under severe resource constraints such as limited battery and 99 computing power, little memory, and insufficient wireless bandwidth 100 and ability to communicate; these constraints often exacerbate each 101 other. Other entities on the network, e.g., a base station or 102 controlling server, might have more computational and communication 103 resources and could support the interaction between the constrained 104 devices and applications in more traditional networks. 106 Today, diverse sizes of constrained devices with different resources 107 and capabilities are becoming connected. Mobile personal gadgets, 108 building-automation devices, cellular phones, machine-to-machine 109 (M2M) devices, and other devices benefit from interacting with other 110 "things" nearby or somewhere in the Internet. With this, the 111 Internet of Things (IoT) becomes a reality, built up out of uniquely 112 identifiable and addressable objects (things). Over the next decade, 113 this could grow to large numbers of Internet-connected constrained 114 devices ([IoT-2025] predicts that by, 2025, more than 2500 devices 115 will be connected to the Internet per second), greatly increasing the 116 Internet's size and scope. 118 The present document provides a number of basic terms that have been 119 useful in the standardization work for constrained environments. The 120 intention is not to exhaustively cover the field but to make sure a 121 few core terms are used consistently between different groups 122 cooperating in this space. 124 The present document is a revision of [RFC7228]. 126 In this document, the term "byte" is used in its now customary sense 127 as a synonym for "octet". Where sizes of semiconductor memory are 128 given, the prefix "kibi" (1024) is combined with "byte" to 129 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. Powers of 10 130 are given as 10^100 where 100 is the exponent. 132 In computing, the term "power" is often used for the concept of 133 "computing power" or "processing power", as in CPU performance. In 134 this document, the term stands for electrical power unless explicitly 135 stated otherwise. "Mains-powered" is used as a shorthand for being 136 permanently connected to a stable electrical power grid. 138 2. Core Terminology 140 There are two important aspects to _scaling_ within the Internet of 141 Things: 143 * scaling up Internet technologies to a large number [IoT-2025] of 144 inexpensive nodes, while 146 * scaling down the characteristics of each of these nodes and of the 147 networks being built out of them, to make this scaling up 148 economically and physically viable. 150 The need for scaling down the characteristics of nodes leads to 151 "constrained nodes". 153 2.1. Constrained Nodes 155 The term "constrained node" is best defined by contrasting the 156 characteristics of a constrained node with certain widely held 157 expectations on more familiar Internet nodes: 159 Constrained Node: A node where some of the characteristics that are 160 otherwise pretty much taken for granted for Internet nodes at the 161 time of writing are not attainable, often due to cost constraints 162 and/or physical constraints on characteristics such as size, 163 weight, and available power and energy. The tight limits on 164 power, memory, and processing resources lead to hard upper bounds 165 on state, code space, and processing cycles, making optimization 166 of energy and network bandwidth usage a dominating consideration 167 in all design requirements. Also, some layer-2 services such as 168 full connectivity and broadcast/multicast may be lacking. 170 While this is not a rigorous definition, it is grounded in the state 171 of the art and clearly sets apart constrained nodes from server 172 systems, desktop or laptop computers, powerful mobile devices such as 173 smartphones, etc. There may be many design considerations that lead 174 to these constraints, including cost, size, weight, and other scaling 175 factors. 177 (An alternative term, when the properties as a network node are not 178 in focus, is "constrained device".) 180 There are multiple facets to the constraints on nodes, often applying 181 in combination, for example: 183 * constraints on the maximum code complexity (ROM/Flash), 185 * constraints on the size of state and buffers (RAM), 187 * constraints on the amount of computation feasible in a period of 188 time ("processing power"), 190 * constraints on the available power, and 192 * constraints on user interface and accessibility in deployment 193 (ability to set keys, update software, etc.). 195 Section 3 defines a number of interesting classes ("class-N") of 196 constrained nodes focusing on relevant combinations of the first two 197 constraints. With respect to available power, [RFC6606] 198 distinguishes "power-affluent" nodes (mains-powered or regularly 199 recharged) from "power-constrained nodes" that draw their power from 200 primary batteries or by using energy harvesting; more detailed power 201 terminology is given in Section 4. 203 The use of constrained nodes in networks often also leads to 204 constraints on the networks themselves. However, there may also be 205 constraints on networks that are largely independent of those of the 206 nodes. We therefore distinguish "constrained networks" from 207 "constrained-node networks". 209 2.2. Constrained Networks 211 We define "constrained network" in a similar way: 213 Constrained Network: A network where some of the characteristics 214 pretty much taken for granted with link layers in common use in 215 the Internet at the time of writing are not attainable. 217 Constraints may include: 219 * low achievable bitrate/throughput (including limits on duty 220 cycle), 222 * high packet loss and high variability of packet loss (delivery 223 rate), 225 * highly asymmetric link characteristics, 227 * severe penalties for using larger packets (e.g., high packet loss 228 due to link-layer fragmentation), 230 * limits on reachability over time (a substantial number of devices 231 may power off at any point in time but periodically "wake up" and 232 can communicate for brief periods of time), and 234 * lack of (or severe constraints on) advanced services such as IP 235 multicast. 237 More generally, we speak of constrained networks whenever at least 238 some of the nodes involved in the network exhibit these 239 characteristics. 241 Again, there may be several reasons for this: 243 * cost constraints on the network, 245 * constraints posed by the nodes (for constrained-node networks), 247 * physical constraints (e.g., power constraints, environmental 248 constraints, media constraints such as underwater operation, 249 limited spectrum for very high density, electromagnetic 250 compatibility), 252 * regulatory constraints, such as very limited spectrum availability 253 (including limits on effective radiated power and duty cycle) or 254 explosion safety, and 256 * technology constraints, such as older and lower-speed technologies 257 that are still operational and may need to stay in use for some 258 more time. 260 2.2.1. Challenged Networks 262 A constrained network is not necessarily a "challenged network" 263 [FALL]: 265 Challenged Network: A network that has serious trouble maintaining 266 what an application would today expect of the end-to-end IP model, 267 e.g., by: 269 * not being able to offer end-to-end IP connectivity at all, 271 * exhibiting serious interruptions in end-to-end IP connectivity, 272 or 274 * exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 275 defined by TCP [RFC0793]. 277 All challenged networks are constrained networks in some sense, but 278 not all constrained networks are challenged networks. There is no 279 well-defined boundary between the two, though. Delay-Tolerant 280 Networking (DTN) has been designed to cope with challenged networks 281 [RFC4838]. 283 2.3. Constrained-Node Networks 285 Constrained-Node Network: A network whose characteristics are 286 influenced by being composed of a significant portion of 287 constrained nodes. 289 A constrained-node network always is a constrained network because of 290 the network constraints stemming from the node constraints, but it 291 may also have other constraints that already make it a constrained 292 network. 294 The rest of this subsection introduces two additional terms that are 295 in active use in the area of constrained-node networks, without an 296 intent to define them: LLN and (6)LoWPAN. 298 2.3.1. LLN 300 A related term that has been used to describe the focus of the IETF 301 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL 302 (Routing Over Low-Power and Lossy) terminology document [RFC7102] 303 defines LLNs as follows: 305 LLN: Low-Power and Lossy Network. Typically composed of many 306 embedded devices with limited power, memory, and processing 307 resources interconnected by a variety of links, such as IEEE 308 802.15.4 or low-power Wi-Fi. There is a wide scope of application 309 areas for LLNs, including industrial monitoring, building 310 automation (heating, ventilation, and air conditioning (HVAC), 311 lighting, access control, fire), connected home, health care, 312 environmental monitoring, urban sensor networks, energy 313 management, assets tracking, and refrigeration. 315 Beyond that, LLNs often exhibit considerable loss at the physical 316 layer, with significant variability of the delivery rate, and some 317 short-term unreliability, coupled with some medium-term stability 318 that makes it worthwhile to both (1) construct directed acyclic 319 graphs that are medium-term stable for routing and (2) do 320 measurements on the edges such as Expected Transmission Count (ETX) 321 [RFC6551]. Not all LLNs comprise low-power nodes 322 [I-D.hui-vasseur-roll-rpl-deployment]. 324 LLNs typically are composed of constrained nodes; this leads to the 325 design of operation modes such as the "non-storing mode" defined by 326 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 327 [RFC6550]). So, in the terminology of the present document, an LLN 328 is a constrained-node network with certain network characteristics, 329 which include constraints on the network as well. 331 2.3.2. LoWPAN, 6LoWPAN 333 One interesting class of a constrained network often used as a 334 constrained-node network is "LoWPAN" [RFC4919], a term inspired from 335 the name of an IEEE 802.15.4 working group (low-rate wireless 336 personal area networks (LR-WPANs)). The expansion of the LoWPAN 337 acronym, "Low-Power Wireless Personal Area Network", contains a hard- 338 to-justify "Personal" that is due to the history of task group naming 339 in IEEE 802 more than due to an orientation of LoWPANs around a 340 single person. Actually, LoWPANs have been suggested for urban 341 monitoring, control of large buildings, and industrial control 342 applications, so the "Personal" can only be considered a vestige. 343 Occasionally, the term is read as "Low-Power Wireless Area Networks" 344 [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used 345 for IPv6, "6LoWPAN") also refers to networks built from similarly 346 constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428] 347 [RFC9159]. 349 2.3.3. LPWAN 351 An overview over Low-Power Wide Area Network (LPWAN) technologies is 352 provided by [RFC8376]. 354 3. Classes of Constrained Devices 356 Despite the overwhelming variety of Internet-connected devices that 357 can be envisioned, it may be worthwhile to have some succinct 358 terminology for different classes of constrained devices. 360 Before we get to that, let's first distinguish two big rough groups 361 of devices based on their CPU capabilities: 363 * Microcontroller-class devices (sometimes called "M-class"). These 364 often (but not always) include RAM and code storage on chip and 365 would struggle to support more powerful general-purpose operating 366 systems, e.g., they do not have an MMU (memory management unit). 367 They use most of their pins for interfaces to application hardware 368 such as digital in/out (the latter often Pulse Width Modulation 369 (PWM)-controllable), ADC/DACs (analog-to-digital and digital-to- 370 analog converters), etc. Where this hardware is specialized for 371 an application, we may talk about "Systems on a Chip" (SOC). 372 These devices often implement elaborate sleep modes to achieve 373 microwatt- or at least milliwatt-level sustained power usage (Ps, 374 see below). 376 * General-purpose-class devices (sometimes called "A-class"). These 377 usually have RAM and Flash storage on separate chips (not always 378 separate packages), and offer support for general-purpose 379 operating systems such as Linux, e.g. an MMU. Many of the pins on 380 the CPU chip are dedicated to interfacing with RAM and other 381 memory. Some general-purpose-class devices integrate some 382 application hardware such as video controllers, these are often 383 also called "Systems on a Chip" (SOC). While these chips also 384 include sleep modes, they are usually more on the watt side of 385 sustained power usage (Ps). 387 If the distinction between these groups needs to be made in this 388 document, we distinguish group "M" (microcontroller) from group "J" 389 (general purpose). 391 In this document, the class designations in Table 1 may be used as 392 rough indications of device capabilities. Note that the classes from 393 10 upwards are not really constrained devices in the sense of the 394 previous section; they may still be useful to discuss constraints in 395 larger devices: 397 +=======+=========+===================+===============+=============+ 398 | Group | Name | data size (e.g., | code size | Examples | 399 | | | RAM) | (e.g., Flash) | | 400 +=======+=========+===================+===============+=============+ 401 | M | Class | << 10 KiB | << 100 KiB | ATtiny | 402 | | 0, C0 | | | | 403 +-------+---------+-------------------+---------------+-------------+ 404 | M | Class | ~ 10 KiB | ~ 100 KiB | STM32F103CB | 405 | | 1, C1 | | | | 406 +-------+---------+-------------------+---------------+-------------+ 407 | M | Class | ~ 50 KiB | ~ 250 KiB | STM32F103RC | 408 | | 2, C2 | | | | 409 +-------+---------+-------------------+---------------+-------------+ 410 | M | Class | ~ 100 KiB | ~ 500..1000 | STM32F103RG | 411 | | 3, C3 | | KiB | | 412 +-------+---------+-------------------+---------------+-------------+ 413 | M | Class | ~ 300..1000 KiB | ~ 1000..2000 | "Luxury" | 414 | | 4, C4 | | KiB | | 415 +-------+---------+-------------------+---------------+-------------+ 416 | J | Class | (16..)32..64..128 | 4..8..16 MiB | OpenWRT | 417 | | 10, | MiB | | routers | 418 | | C10 | | | | 419 +-------+---------+-------------------+---------------+-------------+ 420 | J | Class | 0.5..1 GiB | (lots) | Raspberry | 421 | | 15, | | | PI | 422 | | C15 | | | | 423 +-------+---------+-------------------+---------------+-------------+ 424 | J | Class | 1..4 GiB | (lots) | Smartphones | 425 | | 16, | | | | 426 | | C16 | | | | 427 +-------+---------+-------------------+---------------+-------------+ 428 | J | Class | 4..32 GiB | (lots) | Laptops | 429 | | 17, | | | | 430 | | C17 | | | | 431 +-------+---------+-------------------+---------------+-------------+ 432 | J | Class | (lots) | (lots) | Servers | 433 | | 19, | | | | 434 | | C19 | | | | 435 +-------+---------+-------------------+---------------+-------------+ 437 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 439 As of the writing of this document, these characteristics correspond 440 to distinguishable clusters of commercially available chips and 441 design cores for constrained devices. While it is expected that the 442 boundaries of these classes will move over time, Moore's law tends to 443 be less effective in the embedded space than in personal computing 444 devices: gains made available by increases in transistor count and 445 density are more likely to be invested in reductions of cost and 446 power requirements than into continual increases in computing power. 447 (This effect is less pronounced in the multi-chip J-group 448 architectures; e.g., class 10 usage for OpenWRT has started at 4/16 449 MiB Flash/RAM, with an early lasting minimum at 4/32, to now 450 requiring 8/64 and preferring 16/128 for modern software releases 451 [W432].) 453 Class 0 devices are very constrained sensor-like motes. They are so 454 severely constrained in memory and processing capabilities that most 455 likely they will not have the resources required to communicate 456 directly with the Internet in a secure manner (rare heroic, narrowly 457 targeted implementation efforts notwithstanding). Class 0 devices 458 will participate in Internet communications with the help of larger 459 devices acting as proxies, gateways, or servers. Class 0 devices 460 generally cannot be secured or managed comprehensively in the 461 traditional sense. They will most likely be preconfigured (and will 462 be reconfigured rarely, if at all) with a very small data set. For 463 management purposes, they could answer keepalive signals and send on/ 464 off or basic health indications. 466 Class 1 devices are quite constrained in code space and processing 467 capabilities, such that they cannot easily talk to other Internet 468 nodes employing a full protocol stack such as using HTTP, Transport 469 Layer Security (TLS), and related security protocols and XML-based 470 data representations. However, they are capable enough to use a 471 protocol stack specifically designed for constrained nodes (such as 472 the Constrained Application Protocol (CoAP) over UDP [RFC7252]) and 473 participate in meaningful conversations without the help of a gateway 474 node. In particular, they can provide support for the security 475 functions required on a large network. Therefore, they can be 476 integrated as fully developed peers into an IP network, but they need 477 to be parsimonious with state memory, code space, and often power 478 expenditure for protocol and application usage. 480 Class 2 devices are less constrained and fundamentally capable of 481 supporting most of the same protocol stacks as used on notebooks or 482 servers. However, even these devices can benefit from lightweight 483 and energy-efficient protocols and from consuming less bandwidth. 484 Furthermore, using fewer resources for networking leaves more 485 resources available to applications. Thus, using the protocol stacks 486 defined for more constrained devices on Class 2 devices might reduce 487 development costs and increase the interoperability. 489 Constrained devices with capabilities significantly beyond Class 2 490 devices exist. They are less demanding from a standards development 491 point of view as they can largely use existing protocols unchanged. 492 The previous version of the present document therefore did not make 493 any attempt to define constrained classes beyond Class 2. These 494 devices, and to a certain extent even J-group devices, can still be 495 constrained by a limited energy supply. Class 3 and 4 devices are 496 less clearly defined than the lower classes; they are even less 497 constrained. In particular Class 4 devices are powerful enough to 498 quite comfortably run, say, JavaScript interpreters, together with 499 elaborate network stacks. Additional classes may need to be defined 500 based on protection capabilities, e.g., an MPU (memory protection 501 unit; true MMUs are typically only found in J-group devices). 503 With respect to examining the capabilities of constrained nodes, 504 particularly for Class 1 devices, it is important to understand what 505 type of applications they are able to run and which protocol 506 mechanisms would be most suitable. Because of memory and other 507 limitations, each specific Class 1 device might be able to support 508 only a few selected functions needed for its intended operation. In 509 other words, the set of functions that can actually be supported is 510 not static per device type: devices with similar constraints might 511 choose to support different functions. Even though Class 2 devices 512 have some more functionality available and may be able to provide a 513 more complete set of functions, they still need to be assessed for 514 the type of applications they will be running and the protocol 515 functions they would need. To be able to derive any requirements, 516 the use cases and the involvement of the devices in the application 517 and the operational scenario need to be analyzed. Use cases may 518 combine constrained devices of multiple classes as well as more 519 traditional Internet nodes. 521 3.1. Firmware/Software upgradability 523 Platforms may differ in their firmware or software upgradability. 524 The below is a first attempt at classifying this. 526 +======+============================================================+ 527 | Name | Firmware/Software upgradability | 528 +======+============================================================+ 529 | F0 | no (discard for upgrade) | 530 +------+------------------------------------------------------------+ 531 | F1 | replaceable, out of service during replacement, reboot | 532 +------+------------------------------------------------------------+ 533 | F2 | patchable during operation, reboot required | 534 +------+------------------------------------------------------------+ 535 | F3 | patchable during operation, restart not visible | 536 | | externally | 537 +------+------------------------------------------------------------+ 538 | F9 | app-level upgradability, no reboot required | 539 | | ("hitless") | 540 +------+------------------------------------------------------------+ 542 Table 2: Levels of software update capabilities 544 3.2. Isolation functionality 546 TBD. This section could discuss the ability of the platform to 547 isolate different components. The categories below are not mutually 548 exclusive; we need to build relevant clusters. 550 +======+===========================================================+ 551 | Name | Isolation functionality | 552 +======+===========================================================+ 553 | Is0 | no isolation | 554 +------+-----------------------------------------------------------+ 555 | Is2 | MPU (memory protection unit), at least boundary registers | 556 +------+-----------------------------------------------------------+ 557 | Is5 | MMU with Linux-style kernel/user | 558 +------+-----------------------------------------------------------+ 559 | Is7 | Virtualization-style isolation | 560 +------+-----------------------------------------------------------+ 561 | Is8 | Secure enclave isolation | 562 +------+-----------------------------------------------------------+ 564 Table 3: Levels of isolation capabilities 566 3.3. Shielded secrets 568 [Need to identify clusters] 570 Some platforms can keep shielded secrets (usually in conjunction with 571 secure enclave functionality). 573 +======+================================+ 574 | Name | Secret shielding functionality | 575 +======+================================+ 576 | Sh0 | no secret shielding | 577 +------+--------------------------------+ 578 | Sh1 | some secret shielding | 579 +------+--------------------------------+ 580 | Sh9 | perfect secret shielding | 581 +------+--------------------------------+ 583 Table 4: Levels of secret shielding 584 capabilities 586 4. Power Terminology 588 Devices not only differ in their computing capabilities but also in 589 available power and/or energy. While it is harder to find 590 recognizable clusters in this space, it is still useful to introduce 591 some common terminology. 593 4.1. Scaling Properties 595 The power and/or energy available to a device may vastly differ, from 596 kilowatts to microwatts, from essentially unlimited to hundreds of 597 microjoules. 599 Instead of defining classes or clusters, we simply state, using the 600 International System of Units (SI units), an approximate value for 601 one or both of the quantities listed in Table 5: 603 +======+============================================+=========+ 604 | Name | Definition | SI Unit | 605 +======+============================================+=========+ 606 | Ps | Sustainable average power available for | W | 607 | | the device over the time it is functioning | (Watt) | 608 +------+--------------------------------------------+---------+ 609 | Et | Total electrical energy available before | J | 610 | | the energy source is exhausted | (Joule) | 611 +------+--------------------------------------------+---------+ 613 Table 5: Quantities Relevant to Power and Energy 615 The value of Et may need to be interpreted in conjunction with an 616 indication over which period of time the value is given; see 617 Section 4.2. 619 Some devices enter a "low-power" mode before the energy available in 620 a period is exhausted or even have multiple such steps on the way to 621 exhaustion. For these devices, Ps would need to be given for each of 622 the modes/steps. 624 4.2. Classes of Energy Limitation 626 As discussed above, some devices are limited in available energy as 627 opposed to (or in addition to) being limited in available power. 628 Where no relevant limitations exist with respect to energy, the 629 device is classified as E9. The energy limitation may be in total 630 energy available in the usable lifetime of the device (e.g., a device 631 that is discarded when its non-replaceable primary battery is 632 exhausted), classified as E2. Where the relevant limitation is for a 633 specific period, the device is classified as E1, e.g., a solar- 634 powered device with a limited amount of energy available for the 635 night, a device that is manually connected to a charger and has a 636 period of time between recharges, or a device with a periodic 637 (primary) battery replacement interval. Finally, there may be a 638 limited amount of energy available for a specific event, e.g., for a 639 button press in an energy-harvesting light switch; such devices are 640 classified as E0. Note that, in a sense, many E1 devices are also 641 E2, as the rechargeable battery has a limited number of useful 642 recharging cycles. 644 Table 6 provides a summary of the classifications described above. 646 +======+========================+==============================+ 647 | Name | Type of energy | Example Power Source | 648 | | limitation | | 649 +======+========================+==============================+ 650 | E0 | Event energy-limited | Event-based harvesting | 651 +------+------------------------+------------------------------+ 652 | E1 | Period energy-limited | Battery that is periodically | 653 | | | recharged or replaced | 654 +------+------------------------+------------------------------+ 655 | E2 | Lifetime energy- | Non-replaceable primary | 656 | | limited | battery | 657 +------+------------------------+------------------------------+ 658 | E9 | No direct quantitative | Mains-powered | 659 | | limitations to | | 660 | | available energy | | 661 +------+------------------------+------------------------------+ 663 Table 6: Classes of Energy Limitation 665 4.3. Strategies for Using Power for Communication 667 Especially when wireless transmission is used, the radio often 668 consumes a big portion of the total energy consumed by the device. 669 Design parameters, such as the available spectrum, the desired range, 670 and the bitrate aimed for, influence the power consumed during 671 transmission and reception; the duration of transmission and 672 reception (including potential reception) influence the total energy 673 consumption. 675 Different strategies for power usage and network attachment may be 676 used, based on the type of the energy source (e.g., battery or mains- 677 powered) and the frequency with which a device needs to communicate. 679 The general strategies for power usage can be described as follows: 681 Always-on: This strategy is most applicable if there is no reason 682 for extreme measures for power saving. The device can stay on in 683 the usual manner all the time. It may be useful to employ power- 684 friendly hardware or limit the number of wireless transmissions, 685 CPU speeds, and other aspects for general power-saving and cooling 686 needs, but the device can be connected to the network all the 687 time. 689 Normally-off: Under this strategy, the device sleeps such long 690 periods at a time that once it wakes up, it makes sense for it to 691 not pretend that it has been connected to the network during 692 sleep: the device reattaches to the network as it is woken up. 693 The main optimization goal is to minimize the effort during the 694 reattachment process and any resulting application communications. 696 If the device sleeps for long periods of time and needs to 697 communicate infrequently, the relative increase in energy 698 expenditure during reattachment may be acceptable. 700 Low-power: This strategy is most applicable to devices that need to 701 operate on a very small amount of power but still need to be able 702 to communicate on a relatively frequent basis. This implies that 703 extremely low-power solutions need to be used for the hardware, 704 chosen link-layer mechanisms, and so on. Typically, given the 705 small amount of time between transmissions, despite their sleep 706 state, these devices retain some form of attachment to the 707 network. Techniques used for minimizing power usage for the 708 network communications include minimizing any work from re- 709 establishing communications after waking up and tuning the 710 frequency of communications (including "duty cycling", where 711 components are switched on and off in a regular cycle) and other 712 parameters appropriately. 714 Table 7 provides a summary of the strategies described above. 716 +======+==============+===========================+ 717 | Name | Strategy | Ability to communicate | 718 +======+==============+===========================+ 719 | P0 | Normally-off | Reattach when required | 720 +------+--------------+---------------------------+ 721 | P1 | Low-power | Appears connected, | 722 | | | perhaps with high latency | 723 +------+--------------+---------------------------+ 724 | P9 | Always-on | Always connected | 725 +------+--------------+---------------------------+ 727 Table 7: Strategies of Using Power for 728 Communication 730 Note that the discussion above is at the device level; similar 731 considerations can apply at the communications-interface level. This 732 document does not define terminology for the latter. 734 A term often used to describe power-saving approaches is "duty- 735 cycling". This describes all forms of periodically switching off 736 some function, leaving it on only for a certain percentage of time 737 (the "duty cycle"). 739 [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node 740 as a node that always remains in a fully powered-on state (always 741 awake) where it has the capability to perform communication (P9) and 742 a Sleepy Node as a node that may sometimes go into a sleep mode (a 743 low-power state to conserve power) and temporarily suspend protocol 744 communication (P0); there is no explicit mention of P1. 746 4.4. Strategies of Keeping Time over Power Events 748 Many applications for a device require it to keep some concept of 749 time. 751 Time-keeping can be relative to a previous event (last packet 752 received), absolute on a device-specific scale (e.g., last reboot), 753 or absolute on a world-wide scale ("wall-clock time"). 755 Some devices lose the concept of time when going to sleep: after 756 wakeup, they don't know how long they slept. Some others do keep 757 some concept of time during sleep, but not precise enough to use as a 758 basis for keeping absolute time. Some devices have a continuously 759 running source of a reasonably accurate time (often a 32,768 Hz watch 760 crystal). Finally, some devices can keep their concept of time even 761 during a battery change, e.g., by using a backup battery or a 762 supercapacitor to power the real-time clock (RTC). 764 The actual accuracy of time may vary, with errors ranging from tens 765 of percent from on-chip RC oscillators (not useful for keeping 766 absolute time, but still useful for, e.g., timing out some state) to 767 approximately 10^-4 to 10^-5 ("watch crystal") of error. More 768 precise timing is available with temperature compensated crystal 769 oscillators (TCXO). Further improvement requires significantly 770 higher power usage, bulk, fragility, and device cost, e.g. oven- 771 controlled crystal oscillators (OCXO) can reach 10^-8 accuracy, and 772 Rubidium frequency sources can reach 10^-11 over the short term and 773 10^-9 over the long term. 775 A device may need to fire up a more accurate frequency source during 776 wireless communication, this may also allow it to keep more precise 777 time during the period. 779 The various time sources available on the device can be assisted by 780 external time input, e.g. via the network using the NTP protocol 781 [RFC5905]. Information from measuring the deviation between external 782 input and local time source can be used to increase the accuracy of 783 maintaining time even during periods of no network use. 785 Errors of the frequency source can be compensated if known 786 (calibrated against a known better source, or even predicted, e.g., 787 in a software TCXO). Even with errors partially compensated, an 788 uncertainty remains, which is the more fundamental characteristic to 789 discuss. 791 Battery solutions may allow the device to keep a wall-clock time 792 during its entire life, or the wall-clock time may need to be reset 793 after a battery change. Even devices that have a battery lasting for 794 their lifetime may not be set to wall-clock time at manufacture time, 795 possibly because the battery is only activated at installation time 796 where time sources may be questionable or because setting the clock 797 during manufacture is deemed too much effort. 799 Devices that keep a good approximation of wall-clock time during 800 their life may be in a better position to securely validate external 801 time inputs than devices that need to be reset episodically, which 802 can possibly be tricked by their environment into accepting a long- 803 past time, for instance with the intent of exploiting expired 804 security assertions such as certificates. 806 From a practical point of view, devices can be divided at least on 807 the two dimensions proposed in Table 8 and Table 9. Corrections to 808 the local time of a device performed over the network can be used to 809 improve the uncertainty exhibited by these basic device classes. 811 +======+===========================+=============================+ 812 | Name | Type | Uncertainty (roughly) | 813 +======+===========================+=============================+ 814 | T0 | no concept of time | infinite | 815 +------+---------------------------+-----------------------------+ 816 | T1 | relative time while awake | (usually high) | 817 +------+---------------------------+-----------------------------+ 818 | T2 | relative time | (usually high during sleep) | 819 +------+---------------------------+-----------------------------+ 820 | T3 | relative time | 10^-4 or better | 821 +------+---------------------------+-----------------------------+ 822 | T5 | absolute time (e.g., | 10^-4 or better | 823 | | since boot) | | 824 +------+---------------------------+-----------------------------+ 825 | T7 | wall-clock time | 10^-4 or better | 826 +------+---------------------------+-----------------------------+ 827 | T8 | wall-clock time | 10^-5 or better | 828 +------+---------------------------+-----------------------------+ 829 | T9 | wall-clock time | 10^-6 or better (TCXO) | 830 +------+---------------------------+-----------------------------+ 831 | T10 | wall-clock time | 10^-7 or better (OCXO or | 832 | | | Rb) | 833 +------+---------------------------+-----------------------------+ 835 Table 8: Strategies of Keeping Time over Power Events 837 +======+====================================+=================+ 838 | Name | Permanency (from type T5 upwards): | Uncertainty | 839 +======+====================================+=================+ 840 | TP0 | time needs to be reset on certain | | 841 | | occasions | | 842 +------+------------------------------------+-----------------+ 843 | TP1 | time needs to be set during | (possibly | 844 | | installation | reduced... | 845 +------+------------------------------------+-----------------+ 846 | TP9 | reliable time is maintained during | ...by using | 847 | | lifetime | external input) | 848 +------+------------------------------------+-----------------+ 850 Table 9: Permanency of Keeping Time 852 Further parameters that can be used to discuss clock quality can be 853 found in Section 3.5 of [I-D.ietf-cbor-time-tag]. 855 5. Classes of Networks 857 5.1. Classes of link layer MTU size 859 Link layer technologies used by constrained devices can be 860 categorized on the basis of link layer MTU size. Depending on this 861 parameter, the fragmentation techniques needed (if any) to support 862 the IPv6 MTU requirement may vary. 864 We define the following classes of link layer MTU size: 866 +======+=====================+====================================+ 867 | Name | L2 MTU size (bytes) | 6LoWPAN Fragmentation applicable*? | 868 +======+=====================+====================================+ 869 | S0 | 3 - 12 | need new kind of fragmentation | 870 +------+---------------------+------------------------------------+ 871 | S1 | 13 - 127 | yes | 872 +------+---------------------+------------------------------------+ 873 | S2 | 128 - 1279 | yes | 874 +------+---------------------+------------------------------------+ 875 | S3 | >= 1280 | no fragmentation needed | 876 +------+---------------------+------------------------------------+ 878 Table 10 880 * if no link layer fragmentation is available (note: 'Sx' stands for 881 'Size x') 882 S0 technologies require fragmentation to support the IPv6 MTU 883 requirement. If no link layer fragmentation is available, 884 fragmentation is needed at the adaptation layer below IPv6. However, 885 6LoWPAN fragmentation [RFC4944] cannot be used for these 886 technologies, given the extremely reduced link layer MTU. In this 887 case, lightweight fragmentation formats must be used (e.g. 888 [RFC8724]). 890 S1 and S2 technologies require fragmentation at the subnetwork level 891 to support the IPv6 MTU requirement. If link layer fragmentation is 892 unavailable or insufficient, fragmentation is needed at the 893 adaptation layer below IPv6. 6LoWPAN fragmentation [RFC4944] can be 894 used to carry 1280-byte IPv6 packets over these technologies. 896 S3 technologies do not require fragmentation to support the IPv6 MTU 897 requirement. 899 5.2. Class of Internet Integration 901 The term "Internet of Things" is sometimes confusingly used for 902 connected devices that are not actually employing Internet 903 technology. Some devices do use Internet technology, but only use it 904 to exchange packets with a fixed communication partner ("device-to- 905 cloud" scenarios, see also Section 2.2 of [RFC7452]). More general 906 devices are prepared to communicate with other nodes in the Internet 907 as well. 909 We define the following classes of Internet technology level: 911 +======+======================================+ 912 | Name | Internet technology | 913 +======+======================================+ 914 | I0 | none (local interconnect only) | 915 +------+--------------------------------------+ 916 | I1 | device-to-cloud only | 917 +------+--------------------------------------+ 918 | I9 | full Internet connectivity supported | 919 +------+--------------------------------------+ 921 Table 11 923 5.3. Classes of physical layer bit rate 925 [This section is a trial balloon. We could also talk about burst 926 rate, sustained rate; bits/s, messages/s, ...] 927 Physical layer technologies used by constrained devices can be 928 categorized on the basis of physical layer (PHY) bit rate. The PHY 929 bit rate class of a technology has important implications with regard 930 to compatibility with existing protocols and mechanisms on the 931 Internet, responsiveness to frame transmissions and need for header 932 compression techniques. 934 We define the following classes of PHY bit rate: 936 +======+==============+============================================+ 937 | Name | PHY bit rate | Comment | 938 | | (bit/s) | | 939 +======+==============+============================================+ 940 | B0 | < 10 | Transmission time of 150-byte frame > MSL | 941 +------+--------------+--------------------------------------------+ 942 | B1 | 10 -- 10^3 | Unresponsiveness if human expects reaction | 943 | | | to sent frame (frame size > 62.5 byte) | 944 +------+--------------+--------------------------------------------+ 945 | B2 | 10^3 -- 10^6 | Responsiveness if human expects reaction | 946 | | | to sent frame, but header compression | 947 | | | still needed | 948 +------+--------------+--------------------------------------------+ 949 | B3 | > 10^6 | Header compression yields relatively low | 950 | | | performance benefits | 951 +------+--------------+--------------------------------------------+ 953 Table 12 955 (note: 'Bx' stands for 'Bit rate x') 957 B0 technologies lead to very high transmission times, which may be 958 close to or even greater than the Maximum Segment Lifetime (MSL) 959 assumed on the Internet [RFC0793]. Many Internet protocols and 960 mechanisms will fail when transmit times are greater than the MSL. 961 B0 technologies lead to a frame transmission time greater than the 962 MSL for a frame size greater than 150 bytes. 964 B1 technologies offer transmission times which are lower than the MSL 965 (for a frame size greater than 150 bytes). However, transmission 966 times for B1 technologies are still significant if a human expects a 967 reaction to the transmission of a frame. With B1 technologies, the 968 transmission time of a frame greater than 62.5 bytes exceeds 0.5 969 seconds, i.e. a threshold time beyond which any response or reaction 970 to a frame transmission will appear not to be immediate [RFC5826]. 972 B2 technologies do not incur responsiveness problems, but still 973 benefit from using header compression techniques (e.g. [RFC6282]) to 974 achieve performance improvements. 976 Over B3 technologies, the relative performance benefits of header 977 compression are low. For example, in a duty-cycled technology 978 offering B3 PHY bit rates, energy consumption decrease due to header 979 compression may be comparable with the energy consumed while in a 980 sleep interval. On the other hand, for B3 PHY bit rates, a human 981 user will not be able to perceive whether header compression has been 982 used or not in a frame transmission. 984 6. IANA Considerations 986 This document makes no requests to IANA. 988 7. Security Considerations 990 This document introduces common terminology that does not raise any 991 new security issues. Security considerations arising from the 992 constraints discussed in this document need to be discussed in the 993 context of specific protocols. For instance, Section 11.6 of 994 [RFC7252], "Constrained node considerations", discusses implications 995 of specific constraints on the security mechanisms employed. 996 [RFC7416] provides a security threat analysis for the RPL routing 997 protocol. Implementation considerations for security protocols on 998 constrained nodes are discussed in [RFC7815] and 999 [I-D.ietf-lwig-tls-minimal]. A wider view of security in 1000 constrained-node networks is provided in [RFC8576]. 1002 8. Informative References 1004 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 1005 Challenged Internets", SIGCOMM 2003, 1006 DOI 10.1145/863955.863960, 2003, 1007 . 1009 [I-D.hui-vasseur-roll-rpl-deployment] 1010 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 1011 deployment experience in large scale networks", Work in 1012 Progress, Internet-Draft, draft-hui-vasseur-roll-rpl- 1013 deployment-01, 5 July 2012, 1014 . 1017 [I-D.ietf-cbor-time-tag] 1018 Bormann, C., Gamari, B., and H. Birkholz, "Concise Binary 1019 Object Representation (CBOR) Tags for Time, Duration, and 1020 Period", Work in Progress, Internet-Draft, draft-ietf- 1021 cbor-time-tag-00, 19 May 2021, 1022 . 1025 [I-D.ietf-lwig-tls-minimal] 1026 Kumar, S. S., Keoh, S. L., and H. Tschofenig, "A 1027 Hitchhiker's Guide to the (Datagram) Transport Layer 1028 Security Protocol for Smart Objects and Constrained Node 1029 Networks", Work in Progress, Internet-Draft, draft-ietf- 1030 lwig-tls-minimal-01, 7 March 2014, 1031 . 1034 [IoT-2025] Rosen, M. and IDC, "Driving the Digital Agenda Requires 1035 Strategic Architecture", 16 November 2016, . Slide 11 1039 [ISQ-13] International Electrotechnical Commission, "International 1040 Standard -- Quantities and units -- Part 13: Information 1041 science and technology", IEC 80000-13, March 2008. 1043 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1044 RFC 793, DOI 10.17487/RFC0793, September 1981, 1045 . 1047 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1048 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1049 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1050 April 2007, . 1052 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1053 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1054 Overview, Assumptions, Problem Statement, and Goals", 1055 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1056 . 1058 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1059 "Transmission of IPv6 Packets over IEEE 802.15.4 1060 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1061 . 1063 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1064 Routing Requirements in Low-Power and Lossy Networks", 1065 RFC 5826, DOI 10.17487/RFC5826, April 2010, 1066 . 1068 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1069 "Network Time Protocol Version 4: Protocol and Algorithms 1070 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1071 . 1073 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1074 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1075 DOI 10.17487/RFC6282, September 2011, 1076 . 1078 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1079 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1080 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1081 Low-Power and Lossy Networks", RFC 6550, 1082 DOI 10.17487/RFC6550, March 2012, 1083 . 1085 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1086 and D. Barthel, "Routing Metrics Used for Path Calculation 1087 in Low-Power and Lossy Networks", RFC 6551, 1088 DOI 10.17487/RFC6551, March 2012, 1089 . 1091 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1092 Statement and Requirements for IPv6 over Low-Power 1093 Wireless Personal Area Network (6LoWPAN) Routing", 1094 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1095 . 1097 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1098 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1099 2014, . 1101 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1102 Constrained-Node Networks", RFC 7228, 1103 DOI 10.17487/RFC7228, May 2014, 1104 . 1106 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1107 Application Protocol (CoAP)", RFC 7252, 1108 DOI 10.17487/RFC7252, June 2014, 1109 . 1111 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1112 and M. Richardson, Ed., "A Security Threat Analysis for 1113 the Routing Protocol for Low-Power and Lossy Networks 1114 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1115 . 1117 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1118 over ITU-T G.9959 Networks", RFC 7428, 1119 DOI 10.17487/RFC7428, February 2015, 1120 . 1122 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1123 "Architectural Considerations in Smart Object Networking", 1124 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1125 . 1127 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1128 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1129 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1130 . 1132 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 1133 (IKEv2) Initiator Implementation", RFC 7815, 1134 DOI 10.17487/RFC7815, March 2016, 1135 . 1137 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1138 M., and D. Barthel, "Transmission of IPv6 Packets over 1139 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1140 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1141 2017, . 1143 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1144 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1145 . 1147 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1148 Things (IoT) Security: State of the Art and Challenges", 1149 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1150 . 1152 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1153 Zuniga, "SCHC: Generic Framework for Static Context Header 1154 Compression and Fragmentation", RFC 8724, 1155 DOI 10.17487/RFC8724, April 2020, 1156 . 1158 [RFC9159] Gomez, C., Darroudi, S.M., Savolainen, T., and M. Spoerk, 1159 "IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet 1160 Protocol Support Profile (IPSP)", RFC 9159, 1161 DOI 10.17487/RFC9159, December 2021, 1162 . 1164 [W432] "Warning about 4/32 devices", OpenWRT wiki, last accessed 1165 2021-12-01, 1166 . 1168 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1169 Internet", Wiley-Blackwell monograph, 1170 DOI 10.1002/9780470686218, ISBN 9780470747995, 2009, 1171 . 1173 Acknowledgements 1175 TBD 1177 Authors' Addresses 1179 Carsten Bormann 1180 Universität Bremen TZI 1181 Postfach 330440 1182 D-28359 Bremen 1183 Germany 1184 Phone: +49-421-218-63921 1185 Email: cabo@tzi.org 1187 Mehmet Ersue 1188 Munich 1189 Germany 1190 Email: mersue@gmail.com 1192 Ari Keranen 1193 Ericsson 1194 Hirsalantie 11 1195 FI-02420 Jorvas 1196 Finland 1197 Email: ari.keranen@ericsson.com 1199 Carles Gomez 1200 Universitat Politecnica de Catalunya 1201 C/Esteve Terradas, 7 1202 08860 Castelldefels 1203 Spain 1204 Phone: +34-93-413-7206 1205 Email: carlesgo@entel.upc.edu